Hi Dmitry, thank you for an update. I personally think that 2 and 3 must be done in one blueprint as it related to master node only and 2 shouldn't be a rocket science. What you mean by "Non-root accounts on slave nodes"? If we speak about disabling root for ssh, creating new user and adding needed commands for him in sudoers - I believe that it can be done in that blueprint too. If it is something much bigger - it worth to be in separate blueprint.
On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > 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 > >
__________________________________________________________________________ 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