<div dir="ltr">Folks, I have updated a spec, please review: <a href="https://review.openstack.org/#/c/243340">https://review.openstack.org/#/c/243340</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>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.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>I want to clarify: there are 2 types of services, run on the Fuel node:</div><div>- Those, which are a part of Fuel (astute, nailgun etc)</div><div>- Those, which are not (e.g. atop)</div><div><br></div><div>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.</div><div>Capabilities for the latter will have to be taken care of via either</div><div>a. some external utility (puppet)</div><div>b. rebuilding respective package with updated spec</div><div><br></div><div>I'd say that (a) is still more convinient.</div><div><br></div><div>Another option would be to have a fine-grained control only on Fuel services and leave all the other at their defaults.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Setting setuid bits on apps is not a good idea - it is why linux capabilities were introduced.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Supervisord doesn't seem to use Linux capabilities, id does setuid instead: <a href="https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326" target="_blank">https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326</a></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry, I mean whole feature.<div>Btw, why do you want to grant capabilities via puppet? It should be done by post-install package section, I believe.</div><div><br></div><div>Also I doesn't know if supervisord can bound process capabilities like systemd can - we could use this opportunity too.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw, do you mean the whole feature, or just a user? Since feature would require actually changing puppet code.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry, I believe it should be done via package spec as a part of installation.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello folks,<div><br></div><div>I have updated the spec, please review and share your thoughts on it: <a href="https://review.openstack.org/#/c/243340/" target="_blank">https://review.openstack.org/#/c/243340/</a></div><div><br></div><div>Thanks.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Matthew,<div><br></div><div>sorry, didn't mean to butcher your name :(</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Matther,<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Dmitry,<br><br></div>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.<br></div><div>I think it makes the most sense to create multiple users, one for each service.<br><br></div><div>Lastly, it makes a lot of sense to tie a "fuel" CLI user to python-fuelclient package. <br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>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.</div><div><br></div><div>I'm going to research if it is possible to manage capabilities and  ACLs with what we have out of the box (RPM, Puppet).</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stanislaw,<div><br></div><div>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).</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bartolomiej, Adam,<div>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.<br></div><div><br></div><div>Stanislaw,</div><div>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?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bartolomiej, it's customer-related patches, they, I think, have to be done for 6.1 prior to 8+ release.<div><br></div><div>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?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <span dir="ltr"><<a href="mailto:bpiotrowski@mirantis.com" target="_blank">bpiotrowski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We don't develop features for already released versions… It should be done for master instead.<span><font color="#888888"><div><br></div><div>BP</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <span dir="ltr"><<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dmitry,<div>+1</div><div><br></div><div>Do you plan to port your patchset to future Fuel releases?</div><div><br></div><div>A.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <span dir="ltr"><<a href="mailto:dnikishov@mirantis.com" target="_blank">dnikishov@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hey guys.</div><div><br></div><div>I've been working on making Fuel not to rely on superuser privileges</div><div>at least for day-to-day operations. These include:</div><div>a) running Fuel services (nailgun, astute etc)</div><div>b) user operations (create env, deploy, update, log in)</div><div><br></div><div>The reason for this is that many security policies simply do not</div><div>allow root access (especially remote) to servers/environments.</div><div><br></div><div>This feature/enhancement means that anything that currently is being</div><div>run under root, will be evaluated and, if possible, put under a non-privileged</div><div>user. This also means that remote root access will be disabled.</div><div>Instead, users will have to log in with "fueladmin" user.</div><div><br></div><div>Together with Omar <gomarivera> we've put together a blueprint[0] and a</div><div>spec[1] for this feature. I've been developing this for Fuel 6.1, so there</div><div>are two patches into fuel-main[2] and fuel-library[3] that can give you an</div><div>impression of current approach.</div><div><br></div><div>These patches do following:</div><div>- Add fuel-admin-user package, which creates 'fueladmin'</div><div>- Make all other fuel-* packages depend on fuel-admin-user</div><div>- Put supervisord under 'fueladmin' user.</div><div><br></div><div>Please review the spec/patches and let's have a discussion on the approach to</div><div>this feature.</div><div><br></div><div>Thank you.</div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser</a></div><div>[1] <a href="https://review.openstack.org/243340" target="_blank">https://review.openstack.org/243340</a></div><div>[2] <a href="https://review.openstack.org/243337" target="_blank">https://review.openstack.org/243337</a></div><div>[3] <a href="https://review.openstack.org/243313" target="_blank">https://review.openstack.org/243313</a></div><span><font color="#888888"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</font></span></div></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div><font color="#888888"><span><font color="#888888">Dmitry Nikishov,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Deployment Engineer,<br></font></span></font></div><font color="#888888"><span><font color="#888888">Mirantis, Inc.</font></span></font><font color="#888888"><span></span></font></div></div>
</div>