Open Stack

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 <dnikishov at 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 <dnikishov at 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 <dnikishov at 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 <
>>> sbogatkin at 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 <
>>>> dnikishov at 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 <
>>>>> sbogatkin at 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 <
>>>>>> dnikishov at 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 <
>>>>>>> sbogatkin at 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 <
>>>>>>>> dnikishov at 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 <
>>>>>>>>> dnikishov at 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 <
>>>>>>>>>> sbogatkin at 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 <
>>>>>>>>>>> dnikishov at 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 <
>>>>>>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Matthew,
>>>>>>>>>>>>>
>>>>>>>>>>>>> sorry, didn't mean to butcher your name :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>>>>>>>>>>>> dnikishov at 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 <
>>>>>>>>>>>>>> mmosesohn at 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 <
>>>>>>>>>>>>>>> dnikishov at 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 <
>>>>>>>>>>>>>>>> sbogatkin at 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 <
>>>>>>>>>>>>>>>>> dnikishov at 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 <
>>>>>>>>>>>>>>>>>> dnikishov at 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 <
>>>>>>>>>>>>>>>>>>> sbogatkin at 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
>>>>>>>>>>>>>>>>>>>> <bpiotrowski at 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 <
>>>>>>>>>>>>>>>>>>>>> aheczko at 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 <
>>>>>>>>>>>>>>>>>>>>>> dnikishov at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151207/ff424074/attachment.html>