Folks, there is another spec update, please take a look: https://review.openstack.org/#/c/243340
I'm also considering splitting the blueprint/spec into smaller pieces: 1. Non-root accounts on slave nodes. 2. Non-root user account (fueladmin) on master node. 3. Running fuel services as non-superuser. 4. Running mcollective as non-root (tentative, still need a POC). Let me know what you think. On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > Folks, I have updated a spec, please review: > https://review.openstack.org/#/c/243340 > > On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov <dnikis...@mirantis.com> > wrote: > >> 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. >> > > > > -- > 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
