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.
__________________________________________________________________________ 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
