Dmitry, as we work on opensource - it would be really nice to propose patches to upstream for non-Fuel services. But if it is not an option - using puppet make sense to me.
On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <[email protected]> wrote: > Stanislaw, > > I want to clarify: there are 2 types of services, run on the Fuel node: > - Those, which are a part of Fuel (astute, nailgun etc) > - Those, which are not (e.g. atop) > > Capabilities for the former can easily be managed via post-install > scripts, embedded in respective package spec file (since specs are a part > of fuel-* repo). This is a very good idea. > Capabilities for the latter will have to be taken care of via either > a. some external utility (puppet) > b. rebuilding respective package with updated spec > > I'd say that (a) is still more convinient. > > Another option would be to have a fine-grained control only on Fuel > services and leave all the other at their defaults. > > On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin < > [email protected]> wrote: > >> Dmitry, I just propose the way I think is right, because it's strange >> enough - install package from *.deb file and then set any privileges to it >> by third-party utility. Set permissions for app now mostly managed by >> post-install scripts. Moreover - if it isn't - it should, cause if you set >> capabilities by puppet there always will be a gap between installation and >> setting permissions, so you will must bound package installation process >> with setting permissions by puppet - other way you will have no way to use >> your app. >> >> Setting setuid bits on apps is not a good idea - it is why linux >> capabilities were introduced. >> >> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <[email protected]> >> wrote: >> >>> Stanislaw, >>> >>> In my opinion the whole feature shouldn't be in the separate package >>> simply because it will actually affect the code of many, if not all, >>> components of Fuel. >>> >>> The only services whose capabilities will have to be managed by puppet >>> are those, which are installed from upstream packages (e.g. atop) -- not >>> built from fuel-* repos. >>> >>> Supervisord doesn't seem to use Linux capabilities, id does setuid >>> instead: >>> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326 >>> >>> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin < >>> [email protected]> wrote: >>> >>>> Dmitry, I mean whole feature. >>>> Btw, why do you want to grant capabilities via puppet? It should be >>>> done by post-install package section, I believe. >>>> >>>> Also I doesn't know if supervisord can bound process capabilities like >>>> systemd can - we could use this opportunity too. >>>> >>>> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov < >>>> [email protected]> wrote: >>>> >>>>> My main concern with using linux capabilities/acls on files is >>>>> actually puppet support or, actually, the lack of it. ACLs are possible >>>>> AFAIK, but we'd need to write a custom type/provider for capabilities. I >>>>> suggest to wait with capabilities support till systemd support. >>>>> >>>>> On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov < >>>>> [email protected]> wrote: >>>>> >>>>>> Stanislaw, do you mean the whole feature, or just a user? Since >>>>>> feature would require actually changing puppet code. >>>>>> >>>>>> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Dmitry, I believe it should be done via package spec as a part of >>>>>>> installation. >>>>>>> >>>>>>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello folks, >>>>>>>> >>>>>>>> I have updated the spec, please review and share your thoughts on >>>>>>>> it: https://review.openstack.org/#/c/243340/ >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Matthew, >>>>>>>>> >>>>>>>>> sorry, didn't mean to butcher your name :( >>>>>>>>> >>>>>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Matther, >>>>>>>>>> >>>>>>>>>> I totally agree that each daemon should have it's own user which >>>>>>>>>> should be created during installation of the relevant package. >>>>>>>>>> Probably I >>>>>>>>>> didn't state this clear enough in the spec. >>>>>>>>>> >>>>>>>>>> However, there are security requirements in place that root >>>>>>>>>> should not be used at all. This means that there should be a some >>>>>>>>>> kind of >>>>>>>>>> maintenance or system user ('fueladmin'), which would have enough >>>>>>>>>> privileges to configure and manage Fuel node (e.g. run "sudo puppet >>>>>>>>>> apply" >>>>>>>>>> without password, create mirrors etc). This also means that certain >>>>>>>>>> fuel- >>>>>>>>>> packages would be required to have their files accessible to that >>>>>>>>>> user. >>>>>>>>>> That's the idea behind having a package which would create >>>>>>>>>> 'fueladmin' user >>>>>>>>>> and including it into other fuel- packages requirements lists. >>>>>>>>>> >>>>>>>>>> So this part of the feature comes down to having a non-root user >>>>>>>>>> with sudo privileges and passwordless sudo for certain commands (like >>>>>>>>>> 'puppet apply <path-to-host-only.pp>') for scripting. >>>>>>>>>> >>>>>>>>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Dmitry, >>>>>>>>>>> >>>>>>>>>>> We really shouldn't put "user" creation into a single package >>>>>>>>>>> and then depend on it for daemons. If we want nailgun service to >>>>>>>>>>> run as >>>>>>>>>>> nailgun user, it should be created in the fuel-nailgun package. >>>>>>>>>>> I think it makes the most sense to create multiple users, one >>>>>>>>>>> for each service. >>>>>>>>>>> >>>>>>>>>>> Lastly, it makes a lot of sense to tie a "fuel" CLI user to >>>>>>>>>>> python-fuelclient package. >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Stanislaw, >>>>>>>>>>>> >>>>>>>>>>>> I agree that this approch would work well. However, does Puppet >>>>>>>>>>>> allow managing capabilities and/or file ACLs? Or can they be >>>>>>>>>>>> easily set up >>>>>>>>>>>> when installing RPM package? (is there a way to specify >>>>>>>>>>>> capabilities/ACLs >>>>>>>>>>>> in the RPM spec file?) This doesn't seem to be supported out of >>>>>>>>>>>> the box. >>>>>>>>>>>> >>>>>>>>>>>> I'm going to research if it is possible to manage capabilities >>>>>>>>>>>> and ACLs with what we have out of the box (RPM, Puppet). >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Dmitry, I propose to give needed linux capabilities >>>>>>>>>>>>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs >>>>>>>>>>>>> them and >>>>>>>>>>>>> then start these processes from non-privileged user. It will give >>>>>>>>>>>>> you >>>>>>>>>>>>> ability to run each process without 'sudo' at all with well >>>>>>>>>>>>> fine-grained >>>>>>>>>>>>> permissions. >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Stanislaw, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've been experimenting with 'capsh' on the 6.1 master node >>>>>>>>>>>>>> and it doesn't seem to preserve any capabilities when setting >>>>>>>>>>>>>> SECURE_NOROOT >>>>>>>>>>>>>> bit, even if explicitely told to do so (via either --keep=1 or >>>>>>>>>>>>>> "SECURE_KEEP_CAPS" bit). >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bartolomiej, Adam, >>>>>>>>>>>>>>> Stanislaw is correct. And this is going to be ported to >>>>>>>>>>>>>>> master. The goal currently is to reach an agreement on the >>>>>>>>>>>>>>> implementation >>>>>>>>>>>>>>> so that there's going to be a some kinf of compatibility during >>>>>>>>>>>>>>> upgrades. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Stanislaw, >>>>>>>>>>>>>>> Do I understand correctly that you propose using something >>>>>>>>>>>>>>> like sucap to launch from root, switch to a different user and >>>>>>>>>>>>>>> then drop >>>>>>>>>>>>>>> capabilities which are not required? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bartolomiej, it's customer-related patches, they, I think, >>>>>>>>>>>>>>>> have to be done for 6.1 prior to 8+ release. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dmitry, it's nice to hear about it. Did you consider to use >>>>>>>>>>>>>>>> linux capabilities on fuel-related processes instead of just >>>>>>>>>>>>>>>> using >>>>>>>>>>>>>>>> non-extended POSIX privileged/non-privileged permission checks? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We don't develop features for already released versions… >>>>>>>>>>>>>>>>> It should be done for master instead. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BP >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Dmitry, >>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do you plan to port your patchset to future Fuel releases? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hey guys. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've been working on making Fuel not to rely on >>>>>>>>>>>>>>>>>>> superuser privileges >>>>>>>>>>>>>>>>>>> at least for day-to-day operations. These include: >>>>>>>>>>>>>>>>>>> a) running Fuel services (nailgun, astute etc) >>>>>>>>>>>>>>>>>>> b) user operations (create env, deploy, update, log in) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The reason for this is that many security policies >>>>>>>>>>>>>>>>>>> simply do not >>>>>>>>>>>>>>>>>>> allow root access (especially remote) to >>>>>>>>>>>>>>>>>>> servers/environments. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This feature/enhancement means that anything that >>>>>>>>>>>>>>>>>>> currently is being >>>>>>>>>>>>>>>>>>> run under root, will be evaluated and, if possible, put >>>>>>>>>>>>>>>>>>> under a non-privileged >>>>>>>>>>>>>>>>>>> user. This also means that remote root access will be >>>>>>>>>>>>>>>>>>> disabled. >>>>>>>>>>>>>>>>>>> Instead, users will have to log in with "fueladmin" user. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Together with Omar <gomarivera> we've put together a >>>>>>>>>>>>>>>>>>> blueprint[0] and a >>>>>>>>>>>>>>>>>>> spec[1] for this feature. I've been developing this for >>>>>>>>>>>>>>>>>>> Fuel 6.1, so there >>>>>>>>>>>>>>>>>>> are two patches into fuel-main[2] and fuel-library[3] >>>>>>>>>>>>>>>>>>> that can give you an >>>>>>>>>>>>>>>>>>> impression of current approach. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> These patches do following: >>>>>>>>>>>>>>>>>>> - Add fuel-admin-user package, which creates 'fueladmin' >>>>>>>>>>>>>>>>>>> - Make all other fuel-* packages depend on >>>>>>>>>>>>>>>>>>> fuel-admin-user >>>>>>>>>>>>>>>>>>> - Put supervisord under 'fueladmin' user. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review the spec/patches and let's have a >>>>>>>>>>>>>>>>>>> discussion on the approach to >>>>>>>>>>>>>>>>>>> this feature. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [0] >>>>>>>>>>>>>>>>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser >>>>>>>>>>>>>>>>>>> [1] https://review.openstack.org/243340 >>>>>>>>>>>>>>>>>>> [2] https://review.openstack.org/243337 >>>>>>>>>>>>>>>>>>> [3] https://review.openstack.org/243313 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Dmitry Nikishov, >>>>>>>>>>>>>>>>>>> Deployment Engineer, >>>>>>>>>>>>>>>>>>> Mirantis, Inc. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage >>>>>>>>>>>>>>>>>>> questions) >>>>>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Adam Heczko >>>>>>>>>>>>>>>>>> Security Engineer @ Mirantis Inc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage >>>>>>>>>>>>>>>>>> questions) >>>>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage >>>>>>>>>>>>>>>>> questions) >>>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Dmitry Nikishov, >>>>>>>>>>>>>>> Deployment Engineer, >>>>>>>>>>>>>>> Mirantis, Inc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Dmitry Nikishov, >>>>>>>>>>>>>> Deployment Engineer, >>>>>>>>>>>>>> Mirantis, Inc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Nikishov, >>>>>>>>>>>> Deployment Engineer, >>>>>>>>>>>> Mirantis, Inc. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>>> >>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>> Unsubscribe: >>>>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dmitry Nikishov, >>>>>>>>>> Deployment Engineer, >>>>>>>>>> Mirantis, Inc. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dmitry Nikishov, >>>>>>>>> Deployment Engineer, >>>>>>>>> Mirantis, Inc. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Nikishov, >>>>>>>> Deployment Engineer, >>>>>>>> Mirantis, Inc. >>>>>>>> >>>>>>>> >>>>>>>> __________________________________________________________________________ >>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>> Unsubscribe: >>>>>>>> [email protected]?subject:unsubscribe >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> __________________________________________________________________________ >>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>> Unsubscribe: >>>>>>> [email protected]?subject:unsubscribe >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Nikishov, >>>>>> Deployment Engineer, >>>>>> Mirantis, Inc. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dmitry Nikishov, >>>>> Deployment Engineer, >>>>> Mirantis, Inc. >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Dmitry Nikishov, >>> Deployment Engineer, >>> Mirantis, Inc. >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Dmitry Nikishov, > Deployment Engineer, > Mirantis, Inc. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
