Stanislaw, proposing patches could be a viable option long-term, however, by the time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <sbogat...@mirantis.com> wrote: > 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 <dnikis...@mirantis.com> > 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 < >> sbogat...@mirantis.com> 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 <dnikis...@mirantis.com >>> > 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 < >>>> sbogat...@mirantis.com> 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 < >>>>> dnikis...@mirantis.com> 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 < >>>>>> dnikis...@mirantis.com> 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 < >>>>>>> sbogat...@mirantis.com> 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 < >>>>>>>> dnikis...@mirantis.com> 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 < >>>>>>>>> dnikis...@mirantis.com> wrote: >>>>>>>>> >>>>>>>>>> Matthew, >>>>>>>>>> >>>>>>>>>> sorry, didn't mean to butcher your name :( >>>>>>>>>> >>>>>>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov < >>>>>>>>>> dnikis...@mirantis.com> 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 < >>>>>>>>>>> mmoses...@mirantis.com> 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 < >>>>>>>>>>>> dnikis...@mirantis.com> 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 < >>>>>>>>>>>>> sbogat...@mirantis.com> 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 < >>>>>>>>>>>>>> dnikis...@mirantis.com> 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 < >>>>>>>>>>>>>>> dnikis...@mirantis.com> 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 < >>>>>>>>>>>>>>>> sbogat...@mirantis.com> 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 < >>>>>>>>>>>>>>>>> bpiotrow...@mirantis.com> 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 < >>>>>>>>>>>>>>>>>> ahec...@mirantis.com> 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 < >>>>>>>>>>>>>>>>>>> dnikis...@mirantis.com> 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: >>>>>>>>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?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: >>>>>>>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage >>>>>>>>>>>>>>>>>> questions) >>>>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage >>>>>>>>>>>>>>>>> questions) >>>>>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?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: >>>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?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: >>>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> __________________________________________________________________________ >>>>>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>>>>> Unsubscribe: >>>>>>>>>>>> openstack-dev-requ...@lists.openstack.org?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: >>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> __________________________________________________________________________ >>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>> Unsubscribe: >>>>>>>> openstack-dev-requ...@lists.openstack.org?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: >>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?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: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?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: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
