Stanislaw, the reason why I'm considering splitting the blueprint is that along with implementing the feature, CI jobs and OSTF must be fixed as well.
On Mon, Dec 7, 2015 at 4:03 AM, Stanislaw Bogatkin <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected] >> > 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 <[email protected] >>> > 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 < >>>> [email protected]> 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 < >>>>> [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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
