This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I20b64b32819d62a2b710987c040edf407d7406f7
Add a mode option, which is passed through to mlock to set the modes
on channels. Individual channels can override the global setting.
Because you must be an operator in the channel you are forwarding to
when using the +f mode, add a op_channel option that pre-joins a given
channel and promotes ourselves to ops in there.
[1] https://wiki.swiftirc.net/wiki/Chanserv#Mlock
Change-Id: Ic3ea018f1dd3032a628030ed56cfd863de2f159d
By design, accessbot doesn't *remove* access when you remove yourself
from the access lists; you are just limited to a lower level. This is
noted in the configuration file:
# The label 'mask' is special: anyone with perms on a channel that
# isn't otherwise listed for the channel or in the global list will
# have their access limited to the mask but otherwise left alone.
However I'm feel like it's reasonable to assume that when you remove
yourself you are giving up your permissions; and in the *very*
unlikely case of a bad actor, we would want to know we did actually
remove them from all channels.
To make this clearer, but still allow for unlisted users to maintain
whatever permissions they have, this adds an "alumni" section to the
configuration, and allows for alumni to be set on individual channels.
If your nick appears in this list, your access is removed.
Obviously once this has run once, people could be removed from alumni
if there is a need to cater for something tricky like removing global
access but then adding permissions. But in general I think it will
work to just keep a record of contributors in the common case of
"moved on from openstack work and no longer want to admin things".
Change-Id: I0858e963cdf4bc90c30f9d60ea524d778ae3d150
The logic in the Gemfile was relying on Zuulv2 variables to find out
whether the spec helper gem was already available on disk, and since
Zuulv3 has changed things it was failing to find it and downloading the
master version instead. This patch ensures the Gemfile looks for the gem
in the right place when running in CI.
Change-Id: I60f52ea0589a5b4a1d40b71d3d757a08705a964a
Instead of keeping a local copy of spec_helper_acceptance.rb and
requiring updates to all modules for any change, we can move it into the
common helper gem and require it from there. This will make it easier to
create and review changes that affect all puppet modules. Also change
the Gemfile to look for the gem in the local workspace if running in a
zuul environment.
Change-Id: Ib1db911eafec6b208c9f0375d22d0cf8a18cc48b
Since the beaker jobs are being run on xenial, we need a special nodeset
for it, otherwise beaker gives an error:
beaker-hostgenerator was not able to use this value as input.
Exiting with an Error.
We also want to install puppet from the Ubuntu repos rather than from
puppetlabs, since puppetlabs doesn't support puppet 3 for Xenial. For
centos we can keep the install process the same.
This patch includes additional fixes for issues that were probably
present when the tests were first merged:
- make sure the irc pip package is installed by the puppet class
- use double quotes for the channels.yaml fixture so properly render the
newline characters
- add "access" and "global" sections to the channels.yaml fixture since
accessbot will otherwise be unable to parse the file
- remove spec assertions about the accessbot process, because if it was
successful it should have exited during the puppet run, and in fact if
it didn't exit the puppet run would have failed.
- correct the group name the spec is asserting of the config file
Additionally, out of band from this patch, the nick 'accessbot-test' is
nowregistered on freenode. If it's not registered, it becomes stuck in
the irc infinite loop without performing any actions. This does not mean
it has any permissions to make any real access changes.
Change-Id: Ifd2244ae9dd212b2475f9cd6adb994bc058a4769
Depends-On: I23d0a9c0f4b6ecbb3403447adb03e845d2695366
Bindep is a tool for checking the presence of binary packages needed
to use an application / library. It started life as a way to make it
easier to set up a development environment for OpenStack projects.
Change-Id: I23d0a9c0f4b6ecbb3403447adb03e845d2695366
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Order of those parameters is changed
to follow Puppet Style Guide recommendation [0].
Moreover, it will allow to an user to find much faster
a variable in a list of variables.
[0]. https://docs.puppetlabs.com/guides/style_guide.html
Change-Id: I4dc302b7d1aa13b5bd02eb5c5c52b79fd4beebdc
Use same target directory for zuul-cloner and
the regular git command.
Change-Id: Iaf5c5b1e463757c2d2054f488411a5bf1b78b145
Co-Authored-By: Fabien Boucher <fabien.boucher@enovance.com>
Variables with numbers for names are valid as regex capture groups in
puppet 4[1], so this check is not beneficial and can be
counterproductive when we do actually want to have numeric variables.
[1] https://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#naming
Change-Id: I937a3fef10987d7283b14feb79ee8b814422a468
In anticipation of puppet 4, start trying to deal with puppet 4 things
that can be helpfully predicted by puppet lint plugins.
Change-Id: Ib8655114a83c58d0901ba930e48da0f9f23463b6
In preparation for puppet 4, the puppet-lint-empty_string-check gem
helps find where empty strings are assigned to variables because how
empty strings are evaluated changes in puppet 4, so the easiest thing
is to just remove usage of them.
More importantly, it is not appropriate to set defaults for parameters
that are, realistically, required. If the users leaves these parameters
blank, puppet will apply most resources successfully but fail
mysteriously on the Exec['run_accessbot'] resource, causing the user to
spend additional time debugging. If no defaults are provided in the
puppet class, puppet fill fail with a message stating that the user
must supply values. This "fail fast" approach is much preferred to
debugging obtuse python tracebacks.
This change is technically backwards-incompatible. However, it will not
break Infra because we are already supplying these parameters via
system-config/modules/openstack_project/manifests/eavesdrop.pp. If
there are other users using this module and they are not passing in
these parameters, then their accessbots cannot possibly be running.
An alternative approach is to supply undef as parameter defaults. This
will allow the puppet-lint gem to pass, but does not help the user at
all.
Change-Id: I046340b852e7e8983b741e5bad415678977bea0d
Using methods to access in-scope variables from puppet templates has
been deprecated since puppet 3.2.0[1] and causes warnings to be emitted
in logs. In puppet 4 this functionality was removed entirely. This
patch updates the accessbot.confg template to use instance variables as
recommended in the puppet documentation[2].
[1] https://projects.puppetlabs.com/issues/19058
[2] https://docs.puppetlabs.com/guides/templating.html#referencing-variables
Change-Id: I7af52e32322333879eef946443620e09a726dd57
The http://ci.openstack.org/ documentation site has been deprecated,
replaced by redirects to corresponding paths within
http://docs.openstack.org/infra/ where other Project Infrastructure
documentation already resides.
Change-Id: I145e4b3078a263d909c898629346258aab9171ad
Run it whenever there is a change to the YAML channel config.
The script will ensure everyone listed in global has those perms
and anyone else found with access on a channel will be left as-is
except that their access will be limited to the relevant mask.
Move it and the previous change to add a permission checking
script into a new module, 'accessbot'.
Support SSL in both scripts.
Add a 1 second sleep in the check script to avoid flood protection.
Add all known channels to the channel config.
Closes-Bug: 1190296
Change-Id: I5072cb56ae83a70f4fa955362b8db909b2956d70