<div dir="ltr"><div>Thank you for your clarification.<br><br></div>Would you file a bug on this when you get a chance?<br><br><a href="https://bugs.launchpad.net/tricircle/">https://bugs.launchpad.net/tricircle/</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 8:39 PM, Luck Dog <span dir="ltr"><<a href="mailto:dfhuangg@gmail.com" target="_blank">dfhuangg@gmail.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"><p class="MsoNormal"><span lang="EN-US">Hello,</span></p>
<p class="MsoNormal"><span lang="EN-US">The problem has been solved now. I add a
new line to </span></p>
<p class="MsoNormal"><span lang="EN-US">the file local.conf. The content of the
added line is </span></p>
<p class="MsoNormal"><span lang="EN-US">“NEUTRON_CREATE_INITIAL_NETWORKS=False”, By
adding this line </span></p>
<p class="MsoNormal"><span lang="EN-US">Devstack won’t create default network, and
it will use the configuration</span></p>
<p class="MsoNormal"><span lang="EN-US">set manually. Without this line, Devstack
will create initial network </span></p>
<p class="MsoNormal"><span lang="EN-US">elements including external network.
However, This external network</span></p>
<p class="MsoNormal"><span lang="EN-US">is not supported by single node. If it runs
on a single node then </span></p>
<p class="MsoNormal"><span lang="EN-US">some errors will turn up. It is exactly the
error I met. </span></p><p class="MsoNormal"><span lang="EN-US"><br></span></p><p class="MsoNormal">@<span style="font-size:14px"> </span><span style="font-size:14px">Shinobu, </span>The attachment is the old local.conf. it is from the official </p><p class="MsoNormal">net page, and the URL is <a href="https://github.com/openstack/tricircle/blob/master/devstack/local.conf.sample" target="_blank">https://github.com/openstack/tricircle/blob/master/devstack/local.conf.sample</a></p><p class="MsoNormal">thanks for your kindness!</p></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-05 14:58 GMT+08:00 <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<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>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org" target="_blank">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [kuryr] kuryr-libnetwork split (Vikas Choudhary)<br>
2. Re: [mistral] [murano] [yaql] yaqluator bug (Renat Akhmerov)<br>
3. Re: [mistral] [murano] [yaql] yaqluator bug (Stan Lagun)<br>
4. Re: [nova] Non-priority feature freeze and FFEs (Claudiu Belu)<br>
5. Re: OpenStack-dev Digest, Vol 51, Issue 6 (Shinobu Kinjo)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 5 Jul 2016 10:11:04 +0530<br>
From: Vikas Choudhary <<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>><br>
To: Antoni Segura Puimedon <<a href="mailto:toni%2Bopenstackml@midokura.com" target="_blank">toni+openstackml@midokura.com</a>><br>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, Irena Berezovsky<br>
<<a href="mailto:irena@midokura.com" target="_blank">irena@midokura.com</a>><br>
Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split<br>
Message-ID:<br>
<<a href="mailto:CABJxuZrVDTaTHHBxs4RNuLq30n04KBbhuk7gKEdWXDCC8ggvxA@mail.gmail.com" target="_blank">CABJxuZrVDTaTHHBxs4RNuLq30n04KBbhuk7gKEdWXDCC8ggvxA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Everybody !!!<br>
<br>
As we discussed in the meeting yesterday, I have submitted restructured<br>
patches now in kuryr-lib and kuryr-libnetwork to address only dropping<br>
non-relevant code and adding kuryr-lib as dependency to kuryr-libnetwork.<br>
<br>
Please provide review comments so that i quickly reiterate over patches and<br>
eventually we will be able to move our existing under review patches also<br>
from kuryr to kuryr-libnetwork.<br>
<br>
Since RPC support is also ready, will be submitting the same in both repos<br>
as seperate patches(linked with dependency)<br>
<br>
Here is the link for base patchsets:<br>
Kuryr-libnetwork: <a href="https://review.openstack.org/#/c/337350/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/337350/</a><br>
kuryr-lib: <a href="https://review.openstack.org/#/c/336784/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336784/</a><br>
<br>
<br>
<br>
Regards<br>
Vikas<br>
<br>
On Fri, Jul 1, 2016 at 6:40 PM, Antoni Segura Puimedon <<br>
<a href="mailto:toni%2Bopenstackml@midokura.com" target="_blank">toni+openstackml@midokura.com</a>> wrote:<br>
<br>
> Hi fellow kuryrs!<br>
><br>
> In order to proceed with the split of kuryr into a main lib and it's kuryr<br>
> libnetwork component, we've cloned the contents of openstack/kuryr over to<br>
> openstack/kuryr-libnetwork.<br>
><br>
> The idea is that after this, the patches that will go to openstack/kuryr<br>
> will be to trim out the kuryr/kuryr-libnetwork specific parts and make a<br>
> release of the common parts so that openstack/kuryr-libnetwork can start<br>
> using it.<br>
><br>
> I propose that we use python namespaces and the current common code in<br>
> kuryr is moved to:<br>
> kuryr/lib/<br>
><br>
><br>
> which openstack/kuryr-libnetwork would import like so:<br>
><br>
> from kuryr.lib import binding<br>
><br>
> So, right now, patches in review that are for the Docker ipam or remote<br>
> driver, should be moved to openstack/kuryr-libnetwork and soon we should<br>
> make openstack/kuryr-libnetwork add kuryr-lib to the requirements.<br>
><br>
> Regards,<br>
><br>
> Toni<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/0d032a4c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/0d032a4c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 5 Jul 2016 12:07:25 +0700<br>
From: Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com" target="_blank">renat.akhmerov@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
Message-ID: <<a href="mailto:E9ADF691-7387-47EB-86F5-2A3EEFCF3291@gmail.com" target="_blank">E9ADF691-7387-47EB-86F5-2A3EEFCF3291@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
If I understand the meaning of ?join? function correctly then from user perspective this behavior in Mistral and Yaqluator is a bug because we?re joining two collections similar to how it works in SQL so the correct result should be:<br>
<br>
[[1, 3], [2, 3]]<br>
<br>
I.e. collection consisting of two collections where each element if the first one is combined with each element of the second one.<br>
<br>
If so, we need to fix this in both Mistral and Yaqluator.<br>
<br>
<br>
Alex, Stan, do you agree?<br>
<br>
Renat Akhmerov<br>
@Nokia<br>
<br>
> On 28 Jun 2016, at 23:46, Elisha, Moshe (Nokia - IL) <<a href="mailto:moshe.elisha@nokia.com" target="_blank">moshe.elisha@nokia.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Thank you for the kind words, Alexey.<br>
><br>
> I was able to reproduce your bug and I have also found the issue.<br>
><br>
> The problem is that we did not create the parser with the engine_options used in the yaql library by default when using the CLI.<br>
> Specifically, the "yaql.limitIterators" was missing? I am not sure that this settings should have this affect but maybe the Yaql guys can comment on that.<br>
><br>
> If we will change yaqluator to use this setting it will mean that yaqluator will not be consistent with Mistral because Mistral is using YAQL without this engine option (If I use your example in a workflow, Mistral returns exactly like the yaqluator returns)<br>
><br>
><br>
> Workflow:<br>
><br>
>> ---<br>
>> version: '2.0'<br>
>><br>
>> test_yaql:<br>
>> tasks:<br>
>> test_yaql:<br>
>> action: std.noop<br>
>> publish:<br>
>> output_expr: <% [1,2].join([3], true, [$1, $2]) %><br>
><br>
> Workflow result:<br>
><br>
><br>
> [root@s53-19 ~(keystone_admin)]# mistral task-get-published 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7<br>
> {<br>
> "output_expr": [<br>
> [<br>
> 1,<br>
> 3<br>
> ]<br>
> ]<br>
> }<br>
><br>
><br>
> As Matthews pointed out, the yaqluator is indeed OpenSource and contributions are welcomed.<br>
><br>
> [1] <a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a> <<a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a>><br>
><br>
><br>
><br>
> From: Dougal Matthews <<a href="mailto:dougal@redhat.com" target="_blank">dougal@redhat.com</a> <mailto:<a href="mailto:dougal@redhat.com" target="_blank">dougal@redhat.com</a>>><br>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a> <mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>><br>
> Date: Monday, 27 June 2016 at 16:44<br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a> <mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>><br>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
><br>
> On 27 June 2016 at 14:30, Alexey Khivin <<a href="mailto:akhivin@gmail.com" target="_blank">akhivin@gmail.com</a> <mailto:<a href="mailto:akhivin@gmail.com" target="_blank">akhivin@gmail.com</a>>> wrote:<br>
>> Hello, Moshe<br>
>><br>
>> Tomorrow I discovered <a href="http://yaqluator.com" rel="noreferrer" target="_blank">yaqluator.com</a> <<a href="http://yaqluator.com/" rel="noreferrer" target="_blank">http://yaqluator.com/</a>> for myself! Thanks for the useful tool!<br>
>><br>
>> But suddenly I was said that the expression<br>
>> [1,2].join([3], true, [$1, $2])<br>
>> evaluated to [[1,3]] on the yaqluator<br>
>><br>
>> A the same time this expression evaluated right when I using raw yaql interpreter.<br>
>><br>
>> Could we fix this issue?<br>
>><br>
>> By the way, don't you want to make yaqluator opensource? If you would transfer yaqluator to Openstack Foundation, then community will be able to fix such kind of bugs<br>
><br>
> It looks like it is open source, there is a link in the footer: <a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a> <<a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a>><br>
><br>
>><br>
>> Thank you!<br>
>> Best regards, Alexey Khivin<br>
>><br>
>><br>
>><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> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://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> <<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>
><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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4977ab22/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4977ab22/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 4 Jul 2016 22:12:55 -0700<br>
From: Stan Lagun <<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>><br>
To: "Elisha, Moshe (Nokia - IL)" <<a href="mailto:moshe.elisha@nokia.com" target="_blank">moshe.elisha@nokia.com</a>><br>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
Message-ID:<br>
<CAOCoZia=zLQqn54mwjk2me0H2KXfeqa-J6=<a href="mailto:x3iAKz%2BsxO%2Bk3Pg@mail.gmail.com" target="_blank">x3iAKz+sxO+k3Pg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi!<br>
<br>
The issue with join is just a yaql bug that is already fixed. The problem<br>
with yaqluator is that it doesn't use the latest yaql library.<br>
<br>
Another problem is that it does't sets options correctly. As a result it is<br>
possible to bring the site down with a query that produces endless<br>
collection<br>
<br>
Sincerely yours,<br>
Stan Lagun<br>
Principal Software Engineer @ Mirantis<br>
<br>
<<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>><br>
<br>
On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <<br>
<a href="mailto:moshe.elisha@nokia.com" target="_blank">moshe.elisha@nokia.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Thank you for the kind words, Alexey.<br>
><br>
> I was able to reproduce your bug and I have also found the issue.<br>
><br>
> The problem is that we did not create the parser with the engine_options<br>
> used in the yaql library by default when using the CLI.<br>
> Specifically, the "yaql.limitIterators" was missing? I am not sure that<br>
> this settings should have this affect but maybe the Yaql guys can comment<br>
> on that.<br>
><br>
> If we will change yaqluator to use this setting it will mean that<br>
> yaqluator will not be consistent with Mistral because Mistral is using YAQL<br>
> without this engine option (If I use your example in a workflow, Mistral<br>
> returns exactly like the yaqluator returns)<br>
><br>
><br>
> Workflow:<br>
><br>
> ---<br>
> version: '2.0'<br>
><br>
> test_yaql:<br>
> tasks:<br>
> test_yaql:<br>
> action: std.noop<br>
> publish:<br>
> output_expr: <% [1,2].join([3], true, [$1, $2]) %><br>
><br>
><br>
> Workflow result:<br>
><br>
><br>
> [root@s53-19 ~(keystone_admin)]# mistral task-get-published<br>
> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7<br>
> {<br>
> "output_expr": [<br>
> [<br>
> 1,<br>
> 3<br>
> ]<br>
> ]<br>
> }<br>
><br>
><br>
> As Matthews pointed out, the yaqluator is indeed OpenSource and<br>
> contributions are welcomed.<br>
><br>
> [1]<br>
> <a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a><br>
><br>
><br>
><br>
> From: Dougal Matthews <<a href="mailto:dougal@redhat.com" target="_blank">dougal@redhat.com</a>><br>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<br>
> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
> Date: Monday, 27 June 2016 at 16:44<br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<br>
> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
><br>
> On 27 June 2016 at 14:30, Alexey Khivin <<a href="mailto:akhivin@gmail.com" target="_blank">akhivin@gmail.com</a>> wrote:<br>
><br>
>> Hello, Moshe<br>
>><br>
>> Tomorrow I discovered <a href="http://yaqluator.com" rel="noreferrer" target="_blank">yaqluator.com</a> for myself! Thanks for the useful<br>
>> tool!<br>
>><br>
>> But suddenly I was said that the expression<br>
>> [1,2].join([3], true, [$1, $2])<br>
>> evaluated to [[1,3]] on the yaqluator<br>
>><br>
>> A the same time this expression evaluated right when I using raw yaql<br>
>> interpreter.<br>
>><br>
>> Could we fix this issue?<br>
>><br>
>> By the way, don't you want to make yaqluator opensource? If you would<br>
>> transfer yaqluator to Openstack Foundation, then community will be able to<br>
>> fix such kind of bugs<br>
>><br>
><br>
> It looks like it is open source, there is a link in the footer:<br>
> <a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a><br>
><br>
><br>
>><br>
>> Thank you!<br>
>> Best regards, Alexey Khivin<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <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>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/fe707c06/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/fe707c06/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 5 Jul 2016 06:26:38 +0000<br>
From: Claudiu Belu <<a href="mailto:cbelu@cloudbasesolutions.com" target="_blank">cbelu@cloudbasesolutions.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and<br>
FFEs<br>
Message-ID:<br>
<FBEE3301F14DA946B921457EF854C37742E82761@CBSEX1.cloudbase.local><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
The Hyper-V implementation of the bp virt-device-role-tagging is mergeable [1]. The patch is quite simple, it got some reviews, and the tempest test test_device_tagging [2] passed. [3]<br>
<br>
[1] <a href="https://review.openstack.org/#/c/331889/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/331889/</a><br>
[2] <a href="https://review.openstack.org/#/c/305120/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/305120/</a><br>
[3] <a href="http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz" rel="noreferrer" target="_blank">http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz</a><br>
<br>
Best regards,<br>
<br>
Claudiu Belu<br>
<br>
________________________________________<br>
From: Markus Zoeller [<a href="mailto:mzoeller@linux.vnet.ibm.com" target="_blank">mzoeller@linux.vnet.ibm.com</a>]<br>
Sent: Monday, July 04, 2016 2:24 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs<br>
<br>
On 01.07.2016 23:03, Matt Riedemann wrote:<br>
> We're now past non-priority feature freeze. I've started going through<br>
> some blueprints and -2ing them if they still have outstanding changes. I<br>
> haven't gone through the full list yet (we started with 100).<br>
><br>
> I'm also building a list of potential FFE candidates based on:<br>
><br>
> 1. How far along the change is (how ready is it?), e.g. does it require<br>
> a lot of change yet? Does it require a Tempest test and is that passing<br>
> already? How much of the series has already merged and what's left?<br>
><br>
> 2. How much core reviewer attention has it already gotten?<br>
><br>
> 3. What kind of priority does it have, i.e. if we don't get it done in<br>
> Newton do we miss something in Ocata? Think things that start<br>
> deprecation/removal timers.<br>
><br>
> The plan is for the nova core team to have an informal meeting in the<br>
> #openstack-nova IRC channel early next week, either Tuesday or<br>
> Wednesday, and go through the list of potential FFE candidates.<br>
><br>
> Blueprints that get exceptions will be checked against the above<br>
> criteria and who on the core team is actually going to push the changes<br>
> through.<br>
><br>
> I'm looking to get any exceptions completed within a week, so targeting<br>
> Wednesday 7/13. That leaves a few days for preparing for the meetup.<br>
><br>
<br>
FWIW, bp "libvirt-virtlogd" [1] is basically ready to merge. The two<br>
changes [2] and [3] did already get a lot of attention from danpb.<br>
<br>
References:<br>
[1] <a href="https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd</a><br>
[2] <a href="https://review.openstack.org/#/c/334480/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334480/</a><br>
[3] <a href="https://review.openstack.org/#/c/323765/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/323765/</a><br>
<br>
--<br>
Regards, Markus Zoeller (markus_z)<br>
<br>
<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>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 5 Jul 2016 15:58:24 +0900<br>
From: Shinobu Kinjo <<a href="mailto:shinobu.kj@gmail.com" target="_blank">shinobu.kj@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] OpenStack-dev Digest, Vol 51, Issue 6<br>
Message-ID:<br>
<CAFdRU713mdpLDwbdD=xaRMkOPO=<a href="mailto:UVFF0YQY9x_Ef2dqZmXEp6A@mail.gmail.com" target="_blank">UVFF0YQY9x_Ef2dqZmXEp6A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Would you attach local.conf you're using?<br>
<br>
<br>
On Tue, Jul 5, 2016 at 11:51 AM, Luck Dog <<a href="mailto:dfhuangg@gmail.com" target="_blank">dfhuangg@gmail.com</a>> wrote:<br>
<br>
> Hello everyone,<br>
> I am running the devstack with patch Tricircle,according to steps<br>
> given by official net page,<br>
> <a href="https://github.com/openstack/tricircle#play-with-devstack.But" rel="noreferrer" target="_blank">https://github.com/openstack/tricircle#play-with-devstack.But</a> it always<br>
> failed at the same place.The errors are listed as follows.(according to<br>
> the stack.sh.logs)<br>
><br>
> Request body: {u'network': {u'router:external': True,<br>
> u'provider:network_type': u'flat', u'name': u'public',<br>
> u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m<br>
> ^[[00;33mfrom (pid=29980) prepare_request_body<br>
> /opt/stack/neutron/neutron/api/v2/base.py:674^[[00m<br>
> 2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver<br>
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources<br>
> subnetpool have unlimited quota limit. It is not required to calculate<br>
> headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
> /opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m<br>
> 2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver<br>
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to<br>
> reserve 1 items for resource network. Total usage: 0; quota limit: 10;<br>
> headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
> /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m<br>
> 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource<br>
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
> 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate<br>
> failed^[[00m<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00mTraceback (most recent call last):<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/resource.py",<br>
> line<br>
> 78, in resource<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m result = method(request=request, **args)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
> 424, in create<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m return self._create(request, body, **kwargs)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File<br>
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in<br>
> wrapper<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m ectxt.value = e.inner_exc<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File<br>
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221,<br>
> in __exit__<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m self.force_reraise()<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File<br>
> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197,<br>
> in force_reraise<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m six.reraise(self.type_, self.value, self.tb)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File<br>
> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in<br>
> wrapper<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m return f(*args, **kwargs)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
> 535, in _create<br>
> [[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m return obj_creator(request.context, **kwargs)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File "/opt/stack/tricircle/tricircle/network/plugin.py",<br>
> line 238, in create_network<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m is_external =<br>
> self._ensure_az_set_for_external_network(net_data)<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m File "/opt/stack/tricircle/tricircle/network/plugin.py",<br>
> line 184, in _ensure_az_set_for_external_network<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m raise t_exceptions.ExternalNetPodNotSpecify()<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00mExternalNetPodNotSpecify: Pod for external network not<br>
> specified<br>
> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
> ^[[01;35m^[[00m<br>
> 2016-06-29 17:56:04.439 ^[[00;36mINFO neutron.wsgi<br>
> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
> 13869ba8005b480bbcbe17b2695fd5e2^[[00;36m] ^[[01;35m^[[00;36m127.0.0.1 - -<br>
> [29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368<br>
> 0.147805^[[00m<br>
><br>
> Part of the final printed errors on terminal are:<br>
><br>
> Request Failed: internal server error while processing your request.<br>
> Neutron server returns request_ids:<br>
> ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
> lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
> lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
> [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
> EXT_NET_ID for public<br>
><br>
> I run it several times but still failed. I was in China main land but I<br>
> bought a VPN. So it may not be due to the<br>
> network. @Fawaz Mohammed,Also, I conducted your suggestions and failed at<br>
> last.<br>
><br>
> I wish someone could help me with this question.thanks!<br>
><br>
> Best,<br>
> Dongfeng<br>
><br>
> 2016-07-04 17:36 GMT+08:00 <<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>>:<br>
><br>
>> Send OpenStack-dev mailing list submissions to<br>
>> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<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>
>> or, via email, send a message with subject or body 'help' to<br>
>> <a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a href="mailto:openstack-dev-owner@lists.openstack.org" target="_blank">openstack-dev-owner@lists.openstack.org</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of OpenStack-dev digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: [Nova] Questions about instance actions' update and<br>
>> finish (Matt Riedemann)<br>
>> 2. Re: [manila][stable] liberty periodic bitrot jobs have been<br>
>> failing more than a week (Matt Riedemann)<br>
>> 3. Re: Syntribos Error : AttributeError: 'tuple' object has no<br>
>> attribute 'headers' (David Stanek)<br>
>> 4. Re: [tricircle] Error when running Devstack (Fawaz Mohammed)<br>
>> 5. Re: Openstack Mitaka Neutron LBaaS Question (Fawaz Mohammed)<br>
>> 6. [nova] Fail build request if we can't inject files?<br>
>> (Matt Riedemann)<br>
>> 7. Re: Syntribos Error : AttributeError: 'tuple' object has no<br>
>> attribute 'headers' (OpenStack Mailing List Archive)<br>
>> 8. Re: [manila][stable] liberty periodic bitrot jobs have been<br>
>> failing more than a week (Valeriy Ponomaryov)<br>
>> 9. Re: New Python35 Jobs coming (Henry Gessau)<br>
>> 10. [kolla][horizon] Out of branch horizon plugins? (Dave Walker)<br>
>> 11. Re: New Python35 Jobs coming (Clint Byrum)<br>
>> 12. [Kolla] [docker] Storage-driver and loopback usage? (Gerard Braad)<br>
>> 13. Re: [grenade] upgrades vs rootwrap (Angus Lees)<br>
>> 14. [keystone] spec freeze on july 8th, 2016 (Steve Martinelli)<br>
>> 15. Re: [Kolla] [docker] Storage-driver and loopback usage?<br>
>> (Jeffrey Zhang)<br>
>> 16. Re: [stable][all] Tagging kilo-eol for "the world"<br>
>> (Joshua Hesketh)<br>
>> 17. Re: New Python35 Jobs coming (Andreas Jaeger)<br>
>> 18. Re: New Python35 Jobs coming (Denis Makogon)<br>
>> 19. Re: [Nova] Questions about instance actions' update and<br>
>> finish (Zhenyu Zheng)<br>
>> 20. Re: [mistral][osc-lib][openstackclient] is it too early for<br>
>> orc-lib? (Renat Akhmerov)<br>
>> 21. Re: [nova][infra][ci] bulk repeating a test job on a single<br>
>> review in parallel ? (Kashyap Chamarthy)<br>
>> 22. [tricircle] (Luck Dog)<br>
>> 23. Re: New Python35 Jobs coming (Victor Stinner)<br>
>> 24. Re: Openstack Mitaka Neutron LBaaS Question (Elena Ezhova)<br>
>> 25. Re: [kuryr] kuryr-libnetwork split (Antoni Segura Puimedon)<br>
>> 26. Re: [neutron][upgrades] Bi-weekly upgrades work status.<br>
>> 6/20/2016 (Damon Wang)<br>
>> 27. Re: [kolla][ironic] My thoughts on Kolla + BiFrost<br>
>> integration (Stephen Hindle)<br>
>> 28. Re: [daisycloud-core] [kolla] Kolla Mitaka<br>
>> requirementssupported by CentOS (<a href="mailto:hu.zhijiang@zte.com.cn" target="_blank">hu.zhijiang@zte.com.cn</a>)<br>
>> 29. Re: [daisycloud-core] [kolla] Kolla Mitaka<br>
>> requirementssupported by CentOS (Gerard Braad)<br>
>> 30. ??: [probably forge email???????]Re: [daisycloud-core] Kolla<br>
>> Mitaka requirementssupported by CentOS (<a href="mailto:hu.zhijiang@zte.com.cn" target="_blank">hu.zhijiang@zte.com.cn</a>)<br>
>> 31. Re: [Openstack-operators] [nova] Fail build request if we<br>
>> can't inject files? (Daniel P. Berrange)<br>
>> 32. Re: [all][Python 3.4-3.5] Async python clients (Julien Danjou)<br>
>> 33. Re: [Fuel] - Nominate Maksim Malchuk to Fuel Library Core<br>
>> (Sergii Golovatiuk)<br>
>> 34. Re: [all][Python 3.4-3.5] Async python clients (Denis Makogon)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Sun, 3 Jul 2016 08:05:06 -0500<br>
>> From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] [Nova] Questions about instance actions'<br>
>> update and finish<br>
>> Message-ID: <<a href="mailto:d53105c4-4184-a737-a27c-f8b981cabb8b@linux.vnet.ibm.com" target="_blank">d53105c4-4184-a737-a27c-f8b981cabb8b@linux.vnet.ibm.com</a>><br>
>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>
>><br>
>> On 7/3/2016 6:21 AM, Alex Xu wrote:<br>
>> ><br>
>> ><br>
>> > 2016-07-02 2:32 GMT+08:00 Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
>> > <mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>>:<br>
>> ><br>
>> > On 06/30/2016 08:31 AM, Andrew Laski wrote:<br>
>> > ><br>
>> > ><br>
>> > > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:<br>
>> > >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:<br>
>> > >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:<br>
>> > >>>><br>
>> > >>>><br>
>> > >>>><br>
>> > >>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:<br>
>> > >>>>> How about I sync updated_at and created_at in my patch, and<br>
>> leave the<br>
>> > >>>>> finish to the other BP, by this way, I can use updated_at for<br>
>> the<br>
>> > >>>>> timestamp filter I added and it don't need to change again<br>
>> once the<br>
>> > >>>>> finish BP is complete.<br>
>> > >>>><br>
>> > >>>> Sounds good to me.<br>
>> > >>>><br>
>> > >>><br>
>> > >>> It's been a long day so my memory might be fried, but the<br>
>> options we<br>
>> > >>> talked about in the API meeting were:<br>
>> > >>><br>
>> > >>> 1. Setting updated_at = created_at when the instance action<br>
>> record is<br>
>> > >>> created. Laski likes this, I'm not crazy about it, especially<br>
>> since we<br>
>> > >>> don't do that for anything else.<br>
>> > ><br>
>> > > I would actually like for us to do this generally. I have the same<br>
>> > > thinking as Ed does elsewhere in this thread, the creation of a<br>
>> record<br>
>> > > is an update of that record. So take my comments as applying to<br>
>> Nova<br>
>> > > overall and not just this issue.<br>
>> ><br>
>> > Agree. Also it just simplifies a number of things. We should just<br>
>> start<br>
>> > doing this going forward, and probably put some online data<br>
>> migrations<br>
>> > in place next cycle to update all the old records. Once updated_at<br>
>> can't<br>
>> > be null, we can handle things like this a bit better.<br>
>> ><br>
>> ><br>
>> > The marker should be a column with UniqueConstraint, the updated_at is<br>
>> > not. But if we say the accuracy is ok, there will have problem with<br>
>> > updated_at as None.<br>
>><br>
>> Yeah I thought about this later, we don't use a timestamp field as a<br>
>> marker for anything else, and as noted it's not a non-nullable unique<br>
>> field, plus it's mutable which worries me for a marker field (created_at<br>
>> wouldn't change, but updated_at could).<br>
>><br>
>> ><br>
>> > Anyway, we already freeze... probably we can begin to fix the updated_at<br>
>> > problem first.<br>
>> ><br>
>> ><br>
>> > >>> 2. Update the instance action's updated_at when instance action<br>
>> events<br>
>> > >>> are created. I like this since the instance action is like a<br>
>> parent<br>
>> > >>> resource and the event is the child, so when we create/modify<br>
>> an event<br>
>> > >>> we can consider it an update to the parent. Laski thought this<br>
>> might be<br>
>> > >>> weird UX given we don't expose instance action events in the<br>
>> REST API<br>
>> > >>> unless you're an admin. This is also probably not something<br>
>> we'd do for<br>
>> > >>> other related resources like server groups and server group<br>
>> members (but<br>
>> > >>> we don't page on those either right now).<br>
>> > ><br>
>> > > Right. My concern is just that the ordering of actions can change<br>
>> based<br>
>> > > on events happening which are not visible to the user. However<br>
>> thinking<br>
>> > > about it further we don't really allow multiple actions at once,<br>
>> except<br>
>> > > for a few special cases like delete, so this may not end up<br>
>> affecting<br>
>> > > any ordering as actions are mostly serial. I think this is a fine<br>
>> > > solution for the issue at hand. I just think #1 is a more general<br>
>> > > solution.<br>
>> > ><br>
>> > >>><br>
>> > >>> 3. Order the results by updated_at,created_at so that if<br>
>> updated_at<br>
>> > >>> isn't set for older records, created_at will be used. I think<br>
>> we all<br>
>> > >>> agreed in the meeting to do this regardless of #1 or #2 above.<br>
>> ><br>
>> > I kind of hate that as the order, because then the marker is going<br>
>> to<br>
>> > have to be really funny double timestamp, right?<br>
>> ><br>
>> ><br>
>> > The marker only needs to fill with the unique value. There isn't any<br>
>> > problem order with multiple column. Some time we need order with<br>
>> > mulitple column for stable order when the first order column is<br>
>> > without UniqueConstraint.<br>
>> ><br>
>> ><br>
>> ><br>
>> > I guess that's the one thing I don't see in this patch is a<br>
>> functional<br>
>> > test that actually loads up instance actions and iterates through<br>
>> > demonstrating the pagination.<br>
>> ><br>
>> > -Sean<br>
>> ><br>
>> > --<br>
>> > Sean Dague<br>
>> > <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <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>
>> > <<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>><br>
>><br>
>> --<br>
>><br>
>> Thanks,<br>
>><br>
>> Matt Riedemann<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Sun, 3 Jul 2016 08:19:55 -0500<br>
>> From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] [manila][stable] liberty periodic bitrot<br>
>> jobs have been failing more than a week<br>
>> Message-ID: <<a href="mailto:37858941-062c-8fd7-9794-9f4d9588a446@linux.vnet.ibm.com" target="_blank">37858941-062c-8fd7-9794-9f4d9588a446@linux.vnet.ibm.com</a>><br>
>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>
>><br>
>> On 7/1/2016 8:18 PM, Ravi, Goutham wrote:<br>
>> > Thanks Matt.<br>
>> ><br>
>> > <a href="https://review.openstack.org/#/c/334220" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334220</a> adds the upper constraints.<br>
>> ><br>
>> > --<br>
>> > Goutham<br>
>> ><br>
>> ><br>
>> > On 7/1/16, 5:08 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> wrote:<br>
>> ><br>
>> > The manila periodic stable/liberty jobs have been failing for at least a<br>
>> > week.<br>
>> ><br>
>> > It looks like manila isn't using upper-constraints when running unit<br>
>> > tests, not even on stable/mitaka or master. So in liberty it's pulling<br>
>> > in uncapped oslo.utils even though the upper constraint for oslo.utils<br>
>> > in liberty is 3.2.<br>
>> ><br>
>> > Who from the manila team is going to be working on fixing this, either<br>
>> > via getting upper-constraints in place in the tox.ini for manila (on all<br>
>> > supported branches) or performing some kind of workaround in the code?<br>
>> ><br>
>><br>
>> Thanks.<br>
>><br>
>> I noticed that there is no Tempest / devstack job run against the<br>
>> stable/liberty change - why is there no integration testing of Manila in<br>
>> stable/liberty outside of 3rd party CI (which is not voting)?<br>
>><br>
>> --<br>
>><br>
>> Thanks,<br>
>><br>
>> Matt Riedemann<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Sun, 3 Jul 2016 09:23:07 -0400<br>
>> From: David Stanek <<a href="mailto:dstanek@dstanek.com" target="_blank">dstanek@dstanek.com</a>><br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'<br>
>> object has no attribute 'headers'<br>
>> Message-ID: <20160703132307.GA45453@mba><br>
>> Content-Type: text/plain; charset=us-ascii<br>
>><br>
>> On 07/02 at 15:52, OpenStack Mailing List Archive wrote:<br>
>> > Link: <a href="https://openstack.nimeyo.com/89478/?show=89478#q89478" rel="noreferrer" target="_blank">https://openstack.nimeyo.com/89478/?show=89478#q89478</a><br>
>> > From: run2obtain <<a href="mailto:run2obtain@gmail.com" target="_blank">run2obtain@gmail.com</a>><br>
>> ><br>
>> ><br>
>> > Hi... I tried to use OpenStack Syntribos today for security testing<br>
>> against my<br>
>> > devstack kilo cloud. I followed installation and configuration<br>
>> instructions<br>
>> > provided at the openstack syntribos repo .Unfortunately, I received<br>
>> some errors<br>
>> > after running the command : syntribos keystone.config<br>
>> .opencafe/templates/<br>
>> > keystone/roles_get.txt . The errors are File "/usr/local/lib/python2.7/<br>
>> > dist-packages/syntribos/extensions/identity/client.py", line 146, in<br>
>> > get_token_v3 return r.headers["X-Subject-Token"] AttributeError:<br>
>> 'tuple' object<br>
>> > has no attribute 'headers'. ' I have not been successful at discovering<br>
>> what<br>
>> > could be wrong or how to resolve this issue, even after googling. Does<br>
>> anyone<br>
>> > have a hint as to how to resolve this issue. Many thanks for your<br>
>> anticipated<br>
>> > response.<br>
>> ><br>
>><br>
>> A quick look at the code[1] show that the HTTP client used by the identity<br>
>> client actually returns a tuple instead of a response object. The tuple<br>
>> contains two items: a response object and a signal handler object.<br>
>><br>
>> This is the first I've heard of this project, so I was very disappointed<br>
>> to not find any docs for it.<br>
>><br>
>> 1.<br>
>> <a href="https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143" rel="noreferrer" target="_blank">https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143</a><br>
>><br>
>> --<br>
>> David Stanek<br>
>> web: <a href="http://dstanek.com" rel="noreferrer" target="_blank">http://dstanek.com</a><br>
>> blog: <a href="http://traceback.org" rel="noreferrer" target="_blank">http://traceback.org</a><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 4<br>
>> Date: Sun, 3 Jul 2016 17:59:25 +0400<br>
>> From: Fawaz Mohammed <<a href="mailto:fawaz.moh.ibraheem@gmail.com" target="_blank">fawaz.moh.ibraheem@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [tricircle] Error when running Devstack<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CA%2BNahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5%2BLEsyTMvNsh3g-A@mail.gmail.com" target="_blank">CA+NahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5+LEsyTMvNsh3g-A@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi Dongfeng,<br>
>><br>
>> I've noted in the title [Tricircle], but in your body mail, nothing<br>
>> related<br>
>> to Tricircle!<br>
>><br>
>> It's not recommended to use the sample configuration file as it's, make<br>
>> sure that you edit it as per your preferred configuration.<br>
>><br>
>> Also, note that it's good to run stack.sh as stack user, you can create<br>
>> stack user by running:<br>
>> $sudo /devstack/tools/create-stack-user.sh<br>
>> Then, move the devstack folder to stack home user, or clone it again:<br>
>> stack@Host$cd ~<br>
>> stack@host$git clone <a href="https://git.openstack.org/openstack-dev/devstack" rel="noreferrer" target="_blank">https://git.openstack.org/openstack-dev/devstack</a><br>
>> Edit your local.conf configuration file, then run stack.sh script.<br>
>><br>
>><br>
>><br>
>> On Sun, Jul 3, 2016 at 3:41 PM, Luck Dog <<a href="mailto:dfhuangg@gmail.com" target="_blank">dfhuangg@gmail.com</a>> wrote:<br>
>><br>
>> > Hello everyone,<br>
>> ><br>
>> > I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An<br>
>> > error turns up before it successfully starts. My steps are:<br>
>> > 1), Git clone DevStack,<br>
>> > 2), Copy devstack/local.conf.sample to DevStack folder and rename it to<br>
>> > local.conf.<br>
>> > The errors are as follows?<br>
>> > Request Failed: internal server error while processing your request.<br>
>> > Neutron server returns request_ids:<br>
>> > ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
>> > lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
>> > lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
>> > [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
>> > EXT_NET_ID for public<br>
>> ><br>
>> > I don't know whether it is my wrong configuration of computer or the<br>
>> > server error, I wish someone can help me with the problem. thanks!<br>
>> ><br>
>> > Best regards,<br>
>> > Dongfeng<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/8584112c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/8584112c/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 5<br>
>> Date: Sun, 3 Jul 2016 18:10:02 +0400<br>
>> From: Fawaz Mohammed <<a href="mailto:fawaz.moh.ibraheem@gmail.com" target="_blank">fawaz.moh.ibraheem@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Cc: "<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question<br>
>> Message-ID:<br>
>> <CA+NahOUMgiNoKAnzrZKrOgo=Eigrpv8VHaSZzPxwC=<br>
>> <a href="mailto:WLtQCnEQ@mail.gmail.com" target="_blank">WLtQCnEQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi Wally,<br>
>><br>
>> Make sure that neutron-server is running. Check neutron-server, and<br>
>> neutron-l3-agent logs.<br>
>><br>
>> ---<br>
>> Regards,<br>
>> Fawaz Mohammed<br>
>> .<br>
>><br>
>><br>
>><br>
>> On Sat, Jul 2, 2016 at 2:24 AM, zhihao wang <<a href="mailto:wangzhihaocom@hotmail.com" target="_blank">wangzhihaocom@hotmail.com</a>><br>
>> wrote:<br>
>><br>
>> > Dear OpenStack Dev member:<br>
>> ><br>
>> > May I ask you some question about neutron lbaaS?<br>
>> ><br>
>> > How to install the neutron LBaaS with Octavia in Mitaka?<br>
>> > I followed these two guide ,but which one I should use? (My openstack is<br>
>> > Mitaka , 1 controller, 2 compute nodes)<br>
>> ><br>
>> > <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun</a> -- Ubuntu<br>
>> > Packages Setup<br>
>> > <a href="http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html" rel="noreferrer" target="_blank">http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html</a><br>
>> > -- Configuring LBaaS v2 with Octavia<br>
>> ><br>
>> > Here is what I did:<br>
>> ><br>
>> > pip install octavia<br>
>> ><br>
>> > and then :<br>
>> > vim /etc/neutron/neutron.conf<br>
>> > service_plugins =<br>
>> > router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2<br>
>> ><br>
>> > [service_providers]<br>
>> > service_provider =<br>
>> ><br>
>> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default<br>
>> ><br>
>> > /etc/openstack-dashboard/local_settings.py<br>
>> ><br>
>> ><br>
>> > OPENSTACK_NEUTRON_NETWORK = {<br>
>> > 'enable_lb': True<br>
>> > }<br>
>> ><br>
>> ><br>
>> > And then I restart all the neutron service and apache server<br>
>> > service neutron-server restart<br>
>> > service neutron-dhcp-agent restart<br>
>> > service neutron-metadata-agent restart<br>
>> > service neutron-l3-agent restart<br>
>> ><br>
>> > but and then i ran the command neutron agent-list, it return this. I am<br>
>> > wondering what is wrong with this? how can I install Neutron LaaS?<br>
>> ><br>
>> > root@controller:~# neutron agent-list<br>
>> > Unable to establish connection to<br>
>> <a href="http://controller:9696/v2.0/agents.json" rel="noreferrer" target="_blank">http://controller:9696/v2.0/agents.json</a><br>
>> ><br>
>> ><br>
>> > Please help<br>
>> ><br>
>> > Thanks so much<br>
>> ><br>
>> > Thanks<br>
>> > Wally<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/c3bd39ba/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/c3bd39ba/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 6<br>
>> Date: Sun, 3 Jul 2016 10:08:04 -0500<br>
>> From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>,<br>
>> "<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>><br>
>> Subject: [openstack-dev] [nova] Fail build request if we can't inject<br>
>> files?<br>
>> Message-ID: <<a href="mailto:3e959d6e-09b3-4047-ff31-c44efab981f3@linux.vnet.ibm.com" target="_blank">3e959d6e-09b3-4047-ff31-c44efab981f3@linux.vnet.ibm.com</a>><br>
>> Content-Type: text/plain; charset=utf-8; format=flowed<br>
>><br>
>> I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it<br>
>> runs ssh validation + neutron + config drive + metadata service, which<br>
>> will test the virtual device tagging 2.32 microversion API (added last<br>
>> week).<br>
>><br>
>> The job has a file injection test that fails consistently which is<br>
>> keeping it from being voting.<br>
>><br>
>> After debugging, the problem is the files to inject are silently ignored<br>
>> because n-cpu is configured with libvirt.inject_partition=-2 by default.<br>
>> That disables file injection:<br>
>><br>
>><br>
>> <a href="https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030</a><br>
>><br>
>> We don't even log a warning if the user requested files to inject and we<br>
>> can't honor it. If I were a user and tried to inject files when creating<br>
>> a server but they didn't show up in the guest, I'd open a support ticket<br>
>> against my cloud provider. So I don't think a warning (that only the<br>
>> admin sees) is sufficient here. This isn't something that's discoverable<br>
>> from the API either, it's really host configuration / capability<br>
>> (something we still need to tackle).<br>
>><br>
>> So I propose that we fail the server create request in this case since<br>
>> the user asked nova to inject files but n-cpu is configured to not allow<br>
>> that.<br>
>><br>
>> I'd also think that this should trigger a reschedule to another compute.<br>
>> However, if all computes have disabled file injection, which is the<br>
>> default:<br>
>><br>
>><br>
>> <a href="https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66</a><br>
>><br>
>> Then they'll retry 3 times and fail with an instance in error state. So<br>
>> I'm not sure if rescheduling in this case is useful. I'd think that<br>
>> deployments are either allowing file injection globally (if using<br>
>> libvirt) of they aren't, but would need some operators to chime in here.<br>
>><br>
>> --<br>
>><br>
>> Thanks,<br>
>><br>
>> Matt Riedemann<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 7<br>
>> Date: Sun, 3 Jul 2016 09:09:20 -0700<br>
>> From: OpenStack Mailing List Archive <<a href="mailto:corpqa@gmail.com" target="_blank">corpqa@gmail.com</a>><br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple'<br>
>> object has no attribute 'headers'<br>
>> Message-ID: <<a href="mailto:1d1282b2e4d7eb4d4c701c0ed0b55551@openstack.nimeyo.com" target="_blank">1d1282b2e4d7eb4d4c701c0ed0b55551@openstack.nimeyo.com</a>><br>
>> Content-Type: text/plain; charset="us-ascii"<br>
>><br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/3013a3a5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/3013a3a5/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 8<br>
>> Date: Sun, 3 Jul 2016 19:54:19 +0300<br>
>> From: Valeriy Ponomaryov <<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [manila][stable] liberty periodic bitrot<br>
>> jobs have been failing more than a week<br>
>> Message-ID:<br>
>> <CAPnpNOVTxe6PcuLbZ_3uu-fGZeReVw0G=<br>
>> <a href="mailto:pko8KTP3AKWQx-8sQ@mail.gmail.com" target="_blank">pko8KTP3AKWQx-8sQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Matt, it is not related to branch. Tempest jobs do run only when specific<br>
>> files are changed. See [1].<br>
>><br>
>> [1]<br>
>><br>
>> <a href="https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066</a><br>
>><br>
>> On Sun, Jul 3, 2016 at 4:19 PM, Matt Riedemann <<br>
>> <a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> wrote:<br>
>><br>
>> > On 7/1/2016 8:18 PM, Ravi, Goutham wrote:<br>
>> ><br>
>> >> Thanks Matt.<br>
>> >><br>
>> >> <a href="https://review.openstack.org/#/c/334220" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334220</a> adds the upper constraints.<br>
>> >><br>
>> >> --<br>
>> >> Goutham<br>
>> >><br>
>> >><br>
>> >> On 7/1/16, 5:08 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> wrote:<br>
>> >><br>
>> >> The manila periodic stable/liberty jobs have been failing for at least<br>
>> a<br>
>> >> week.<br>
>> >><br>
>> >> It looks like manila isn't using upper-constraints when running unit<br>
>> >> tests, not even on stable/mitaka or master. So in liberty it's pulling<br>
>> >> in uncapped oslo.utils even though the upper constraint for oslo.utils<br>
>> >> in liberty is 3.2.<br>
>> >><br>
>> >> Who from the manila team is going to be working on fixing this, either<br>
>> >> via getting upper-constraints in place in the tox.ini for manila (on<br>
>> all<br>
>> >> supported branches) or performing some kind of workaround in the code?<br>
>> >><br>
>> >><br>
>> > Thanks.<br>
>> ><br>
>> > I noticed that there is no Tempest / devstack job run against the<br>
>> > stable/liberty change - why is there no integration testing of Manila in<br>
>> > stable/liberty outside of 3rd party CI (which is not voting)?<br>
>> ><br>
>> ><br>
>> > --<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Matt Riedemann<br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>><br>
>><br>
>><br>
>> --<br>
>> Kind Regards<br>
>> Valeriy Ponomaryov<br>
>> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
>> <a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/b9601a80/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/b9601a80/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 9<br>
>> Date: Sun, 3 Jul 2016 15:26:23 -0400<br>
>> From: Henry Gessau <<a href="mailto:HenryG@gessau.net" target="_blank">HenryG@gessau.net</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> Message-ID: <<a href="mailto:314a3c1e-7111-38ab-3545-d3cb302a4d02@gessau.net" target="_blank">314a3c1e-7111-38ab-3545-d3cb302a4d02@gessau.net</a>><br>
>> Content-Type: text/plain; charset=utf-8<br>
>><br>
>> Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
>> > The infra team is working on taking advantage of the new Ubuntu Xenial<br>
>> > release including running unittests on python35. The current plan is to<br>
>> > get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday (July<br>
>> > 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> > master/Newton on all projects that had python34 testing.<br>
>> ><br>
>> > The expectation is that in many cases python35 tests will just work if<br>
>> > python34 testing was also working. If this is the case for your project<br>
>> > you can propose a change to openstack-infra/project-config to make these<br>
>> > jobs voting against your project. You should only need to edit<br>
>> > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> > portion of the python35 jobs to do this.<br>
>> ><br>
>> > We do however expect that there will be a large group of failed tests<br>
>> > too. If your project has a specific tox.ini py34 target to restrict<br>
>> > python3 testing to a specific list of tests you will need to add a tox<br>
>> > target for py35 that does the same thing as the py34 target. We have<br>
>> > also seen bug reports against some projects whose tests rely on stable<br>
>> > error messages from Python itself which isn't always the case across<br>
>> > version changes so these tests will need to be updated as well.<br>
>> ><br>
>> > Note this change will not add python35 jobs for cases where projects<br>
>> > have special tox targets. This is restricted just to the default py35<br>
>> > unittesting.<br>
>> ><br>
>> > As always let us know if you questions,<br>
>> > Clark<br>
>><br>
>> How soon can projects replace py34 with py35?<br>
>><br>
>> I tried py35 for neutron locally, and it ran without errors.<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 10<br>
>> Date: Sun, 3 Jul 2016 21:15:37 +0100<br>
>> From: Dave Walker <<a href="mailto:email@daviey.com" target="_blank">email@daviey.com</a>><br>
>> To: OpenStack Development Mailing List<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: [openstack-dev] [kolla][horizon] Out of branch horizon<br>
>> plugins?<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CACyjiAhWiOTvZjAKyibSC4wpHyK6c9%2BcNK0dzy_dFxSgX%2BckAA@mail.gmail.com" target="_blank">CACyjiAhWiOTvZjAKyibSC4wpHyK6c9+cNK0dzy_dFxSgX+ckAA@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi,<br>
>><br>
>> Whilst writing a Kolla plugin, I noticed some issues with the way Horizon<br>
>> is configured in Kolla.<br>
>><br>
>> Horizon is increasingly embracing a plugin architecture with UI's and<br>
>> Dashboards being maintained outside of Horizon's tree.<br>
>><br>
>> These can be found with the type:horizon-plugin tag in<br>
>> openstack/governance<br>
>> [0], with 16 projects at current.<br>
>><br>
>> This isn't really addressed in Kolla, and is a little awkward to integrate<br>
>> as the horizon docker image is pure horizon.<br>
>><br>
>> Some projects have a tools/register_plugin.sh which performs the grunt<br>
>> work, where as others require a workflow similar to:<br>
>><br>
>> cp /path/to/projects/new/panel openstack_dashboard/local/enabled/<br>
>> cp /path/to/local/defualt/settings<br>
>> openstack_dashboard/local/local_settings.d/<br>
>> cp /path/to/*policy.json openstack_dashboard/conf/<br>
>> # compress if environment wants it<br>
>> ./manage.py collectstatic<br>
>> ./manage.py compress<br>
>><br>
>> (Separately, it would be nice if this was standardised.. but not the topic<br>
>> of this thread)<br>
>><br>
>> It would seem logical to pack all of these into the horizon docker image,<br>
>> and add a symlink into dashboard/local/enabled via ansible, policy.json<br>
>> and<br>
>> default settings with some conditionals if enabled_$service... but this<br>
>> will make the horizon docker image larger and more complicated.<br>
>><br>
>> What are your thoughts?<br>
>><br>
>> [0]<br>
>><br>
>> <a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml</a><br>
>><br>
>> --<br>
>> Kind Regards,<br>
>> Dave Walker<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/dd00980b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/dd00980b/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 11<br>
>> Date: Sun, 03 Jul 2016 17:20:42 -0700<br>
>> From: Clint Byrum <<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>><br>
>> To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> Message-ID: <<a href="mailto:1467591512-sup-6679@fewbar.com" target="_blank">1467591512-sup-6679@fewbar.com</a>><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>> Excerpts from Henry Gessau's message of 2016-07-03 15:26:23 -0400:<br>
>> > Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
>> > > The infra team is working on taking advantage of the new Ubuntu Xenial<br>
>> > > release including running unittests on python35. The current plan is<br>
>> to<br>
>> > > get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday<br>
>> (July<br>
>> > > 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> > > master/Newton on all projects that had python34 testing.<br>
>> > ><br>
>> > > The expectation is that in many cases python35 tests will just work if<br>
>> > > python34 testing was also working. If this is the case for your<br>
>> project<br>
>> > > you can propose a change to openstack-infra/project-config to make<br>
>> these<br>
>> > > jobs voting against your project. You should only need to edit<br>
>> > > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> > > portion of the python35 jobs to do this.<br>
>> > ><br>
>> > > We do however expect that there will be a large group of failed tests<br>
>> > > too. If your project has a specific tox.ini py34 target to restrict<br>
>> > > python3 testing to a specific list of tests you will need to add a tox<br>
>> > > target for py35 that does the same thing as the py34 target. We have<br>
>> > > also seen bug reports against some projects whose tests rely on stable<br>
>> > > error messages from Python itself which isn't always the case across<br>
>> > > version changes so these tests will need to be updated as well.<br>
>> > ><br>
>> > > Note this change will not add python35 jobs for cases where projects<br>
>> > > have special tox targets. This is restricted just to the default py35<br>
>> > > unittesting.<br>
>> > ><br>
>> > > As always let us know if you questions,<br>
>> > > Clark<br>
>> ><br>
>> > How soon can projects replace py34 with py35?<br>
>> ><br>
>> > I tried py35 for neutron locally, and it ran without errors.<br>
>> ><br>
>><br>
>> I think we should be aggressive on python 3.5 vs. 3.4, since anywhere<br>
>> that shipped 3.4 also shipped 2.7. Otherwise we end up wasting time on<br>
>> whatever subtle differences there are.<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 12<br>
>> Date: Mon, 4 Jul 2016 11:00:50 +0800<br>
>> From: Gerard Braad <<a href="mailto:me@gbraad.nl" target="_blank">me@gbraad.nl</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: [openstack-dev] [Kolla] [docker] Storage-driver and loopback<br>
>> usage?<br>
>> Message-ID:<br>
>> <CAGrH30WswSoHyeSOSNse3kJcPwkZOdLxu=<br>
>> <a href="mailto:Fd9ki7UGGu3Xw_ww@mail.gmail.com" target="_blank">Fd9ki7UGGu3Xw_ww@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>> Hi guys,<br>
>><br>
>><br>
>> This weekend I have been looking into some issues I encountered with<br>
>> `ostree` inside a Docker container, and this seemed to have been<br>
>> caused by the use of loopback storage with device mapper. After this<br>
>> experience I was wondering what Kolla did...<br>
>><br>
>> Usually for development purpose, or on a laptop, it is easy to just<br>
>> work out-of-the-box. But I would not consider using devicemapper after<br>
>> this experience as a pleasant experience. I moved to all development<br>
>> environment using OverlayFS, and will evaluate this for the time<br>
>> being...<br>
>><br>
>> What do you guys think or use? And what about the quickstart? I was<br>
>> unable to find a statement about this. I did find a change of the<br>
>> storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what<br>
>> is used in CI?<br>
>><br>
>> regards,<br>
>><br>
>><br>
>> Gerard<br>
>><br>
>> --<br>
>><br>
>> Gerard Braad | <a href="http://gbraad.nl" rel="noreferrer" target="_blank">http://gbraad.nl</a><br>
>> [ Doing Open Source Matters ]<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 13<br>
>> Date: Mon, 04 Jul 2016 03:25:06 +0000<br>
>> From: Angus Lees <<a href="mailto:gus@inodes.org" target="_blank">gus@inodes.org</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [grenade] upgrades vs rootwrap<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CAPA_H3fkw%2BMB_AjHVAmS29%2BviS07PJXdM3RukK0fhx-gv2fyRw@mail.gmail.com" target="_blank">CAPA_H3fkw+MB_AjHVAmS29+viS07PJXdM3RukK0fhx-gv2fyRw@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> On Sat, 2 Jul 2016 at 01:02 Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> wrote:<br>
>><br>
>> > On 6/28/2016 4:56 PM, Sean Dague wrote:<br>
>> > > On 06/28/2016 01:46 AM, Angus Lees wrote:<br>
>> > >> Ok, thanks for the in-depth explanation.<br>
>> > >><br>
>> > >> My take away is that we need to file any rootwrap updates as<br>
>> exceptions<br>
>> > >> for now (so releasenotes and grenade scripts).<br>
>> > ><br>
>> > > That is definitely the fall back if there is no better idea. However,<br>
>> we<br>
>> > > should try really hard to figure out if there is a non manual way<br>
>> > > through this. Even if that means some compat code that we keep for a<br>
>> > > release to just bridge the gap.<br>
>> > ><br>
>> > > -Sean<br>
>> > ><br>
>> ><br>
>> > Walter had this for os-brick:<br>
>> ><br>
>> > <a href="https://review.openstack.org/#/c/329586/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/329586/</a><br>
>> ><br>
>> > That would fallback to rootwrap if privsep doesn't work / not available.<br>
>> > That could be a workaround for upgrading with os-brick for Newton, with<br>
>> > a big fat warning logged if we use it, and then drop it in Ocata and<br>
>> > require privsep.<br>
>> ><br>
>><br>
>> Yes, this is basically a version of "submit the rootwrap filter, then wait<br>
>> 6 months before submitting the code that needs it". If we don't wish to<br>
>> use the exception mechanism (or adjust the policy to upgrade conf before<br>
>> code as I described earlier), then we can certainly do this. Rather than<br>
>> log a big fat warning if we use privsep, we may as well just revert the<br>
>> privsep change for os-brick and then resubmit it next cycle.<br>
>><br>
>> This thread topic isn't actually about privsep however, although a<br>
>> migration to privsep will mostly mitigate this in the future which is<br>
>> perhaps why it is causing topic collisions for everyone.<br>
>><br>
>> I see there are already a few other additions to the rootwrap filters in<br>
>> nova/cinder (the comments suggest (nova) libvirt/imagebackend.py, (cinder)<br>
>> remotefs.py, and (both) vzstorage.py). The various privsep-only<br>
>> suggestions about fallback strategies don't help in these other<br>
>> examples. Any<br>
>> corresponding code changes that rely on these new filters will also need<br>
>> to<br>
>> be reverted and resubmitted during next cycle - or do what usually happens<br>
>> and slip under the radar as they are not exercised by grenade.<br>
>><br>
>> - Gus<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b8832f07/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b8832f07/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 14<br>
>> Date: Sun, 3 Jul 2016 23:41:22 -0400<br>
>> From: Steve Martinelli <<a href="mailto:s.martinelli@gmail.com" target="_blank">s.martinelli@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: [openstack-dev] [keystone] spec freeze on july 8th, 2016<br>
>> Message-ID:<br>
>> <CAHc_MXHV+bj-c36=bDxUZ1SU=<br>
>> <a href="mailto:FFy-jy2ssSnaVEHFxd3fLGFag@mail.gmail.com" target="_blank">FFy-jy2ssSnaVEHFxd3fLGFag@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> The keystone spec freeze is on july 8th. I am in the process of going<br>
>> through the open specs [1]<br>
>><br>
>> I will be commenting if I think it is a potential candidate for the Newton<br>
>> based on how far along the spec is, its complexity, core reviewer<br>
>> attention<br>
>> and priority. (Thanks Matt R for the wording)<br>
>><br>
>> I'd like spend the bulk of the next keystone meeting on Tuesday discussing<br>
>> the open specs. If you are authoring one, please try to attend.<br>
>><br>
>> [1]<br>
>><br>
>> <a href="https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open</a><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/046649b3/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/046649b3/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 15<br>
>> Date: Mon, 4 Jul 2016 11:58:40 +0800<br>
>> From: Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com" target="_blank">zhang.lei.fly@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Kolla] [docker] Storage-driver and<br>
>> loopback usage?<br>
>> Message-ID:<br>
>> <CAATxhGftHC_oJMkX-vabJugNCK+DBom6m3qGZj_051tZS=<br>
>> <a href="mailto:7fHg@mail.gmail.com" target="_blank">7fHg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi Gerard,<br>
>><br>
>> Here is what the docker official recommend[0]. In the prod env, the they<br>
>> recommend<br>
>> using the direct-lvm driver.<br>
>><br>
>> Kolla has no recommendation now. In the dev process, i know someone use<br>
>> overlayfs,<br>
>> some use btrfs. These two are both faster than others.<br>
>><br>
>><br>
>> [0] <a href="https://docs.docker.com/engine/userguide/storagedriver/selectadriver/" rel="noreferrer" target="_blank">https://docs.docker.com/engine/userguide/storagedriver/selectadriver/</a><br>
>><br>
>> On Mon, Jul 4, 2016 at 11:00 AM, Gerard Braad <<a href="mailto:me@gbraad.nl" target="_blank">me@gbraad.nl</a>> wrote:<br>
>><br>
>> > Hi guys,<br>
>> ><br>
>> ><br>
>> > This weekend I have been looking into some issues I encountered with<br>
>> > `ostree` inside a Docker container, and this seemed to have been<br>
>> > caused by the use of loopback storage with device mapper. After this<br>
>> > experience I was wondering what Kolla did...<br>
>> ><br>
>> > Usually for development purpose, or on a laptop, it is easy to just<br>
>> > work out-of-the-box. But I would not consider using devicemapper after<br>
>> > this experience as a pleasant experience. I moved to all development<br>
>> > environment using OverlayFS, and will evaluate this for the time<br>
>> > being...<br>
>> ><br>
>> > What do you guys think or use? And what about the quickstart? I was<br>
>> > unable to find a statement about this. I did find a change of the<br>
>> > storage-driver in `kolla/tools/setup_RedHat.sh` to btrfs... and what<br>
>> > is used in CI?<br>
>> ><br>
>> > regards,<br>
>> ><br>
>> ><br>
>> > Gerard<br>
>> ><br>
>> > --<br>
>> ><br>
>> > Gerard Braad | <a href="http://gbraad.nl" rel="noreferrer" target="_blank">http://gbraad.nl</a><br>
>> > [ Doing Open Source Matters ]<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>><br>
>><br>
>><br>
>> --<br>
>> Regards,<br>
>> Jeffrey Zhang<br>
>> Blog: <a href="http://xcodest.me" rel="noreferrer" target="_blank">http://xcodest.me</a><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/cf4c7da8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/cf4c7da8/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 16<br>
>> Date: Mon, 4 Jul 2016 14:33:08 +1000<br>
>> From: Joshua Hesketh <<a href="mailto:joshua.hesketh@gmail.com" target="_blank">joshua.hesketh@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the<br>
>> world"<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CA%2BDTi5w-azo949HhOnp7gufu0Lsov77C1dUnHaBG_8SVneGD%2Bg@mail.gmail.com" target="_blank">CA+DTi5w-azo949HhOnp7gufu0Lsov77C1dUnHaBG_8SVneGD+g@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> On Fri, Jul 1, 2016 at 9:26 PM, Jesse Pretorius <<br>
>> <a href="mailto:Jesse.Pretorius@rackspace.co.uk" target="_blank">Jesse.Pretorius@rackspace.co.uk</a>> wrote:<br>
>><br>
>> > Hi all,<br>
>> ><br>
>> > Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented<br>
>> > we?ve requested a final tag [1]. Once that merges we are ready to have<br>
>> our<br>
>> > kilo-eol tag implemented and the ?kilo? branch removed.<br>
>> ><br>
>><br>
>> I assume you want to wait for the tag to merge before removing the branch?<br>
>><br>
>><br>
>> ><br>
>> > Just to make life interesting, we still have leftover ?juno? and<br>
>> > ?icehouse? branches and would like to implement eol tags for them too. I<br>
>> > think we have the appropriate skips in place for the juno branch so<br>
>> there<br>
>> > should be no funky post-tag jobs kicking off for them, but the icehouse<br>
>> > branch may end up with some unknown jobs kicking off. If you can help<br>
>> > identify the changes we need to get implemented into project-config<br>
>> then we<br>
>> > can be rid of the old cruft.<br>
>> ><br>
>><br>
>> The only tag job I can see for openstack-ansible* projects is the<br>
>> releasenotes one. This should be harmless as it just generates the notes<br>
>> for mitaka and liberty branches. I'm going to hold off until the final tag<br>
>> has merged anyway if you want to confirm this first.<br>
>><br>
>> Cheers,<br>
>> Josh<br>
>><br>
>><br>
>><br>
>> > Thanks,<br>
>> ><br>
>> > Jesse<br>
>> ><br>
>> > ------------------------------<br>
>> > Rackspace Limited is a company registered in England & Wales (company<br>
>> > registered number 03897010) whose registered office is at 5 Millington<br>
>> > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy<br>
>> policy<br>
>> > can be viewed at <a href="http://www.rackspace.co.uk/legal/privacy-policy" rel="noreferrer" target="_blank">www.rackspace.co.uk/legal/privacy-policy</a> - This e-mail<br>
>> > message may contain confidential or privileged information intended for<br>
>> the<br>
>> > recipient. Any dissemination, distribution or copying of the enclosed<br>
>> > material is prohibited. If you receive this transmission in error,<br>
>> please<br>
>> > notify us immediately by e-mail at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a> and delete the<br>
>> > original message. Your cooperation is appreciated.<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/dfba39e6/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/dfba39e6/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 17<br>
>> Date: Mon, 4 Jul 2016 07:18:41 +0200<br>
>> From: Andreas Jaeger <<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> Message-ID: <<a href="mailto:5779F1B1.3080500@suse.com" target="_blank">5779F1B1.3080500@suse.com</a>><br>
>> Content-Type: text/plain; charset="windows-1252"<br>
>><br>
>> On 07/03/2016 09:26 PM, Henry Gessau wrote:<br>
>> > Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
>> >> The infra team is working on taking advantage of the new Ubuntu Xenial<br>
>> >> release including running unittests on python35. The current plan is to<br>
>> >> get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday (July<br>
>> >> 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> >> master/Newton on all projects that had python34 testing.<br>
>> >><br>
>> >> The expectation is that in many cases python35 tests will just work if<br>
>> >> python34 testing was also working. If this is the case for your project<br>
>> >> you can propose a change to openstack-infra/project-config to make<br>
>> these<br>
>> >> jobs voting against your project. You should only need to edit<br>
>> >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> >> portion of the python35 jobs to do this.<br>
>> >><br>
>> >> We do however expect that there will be a large group of failed tests<br>
>> >> too. If your project has a specific tox.ini py34 target to restrict<br>
>> >> python3 testing to a specific list of tests you will need to add a tox<br>
>> >> target for py35 that does the same thing as the py34 target. We have<br>
>> >> also seen bug reports against some projects whose tests rely on stable<br>
>> >> error messages from Python itself which isn't always the case across<br>
>> >> version changes so these tests will need to be updated as well.<br>
>> >><br>
>> >> Note this change will not add python35 jobs for cases where projects<br>
>> >> have special tox targets. This is restricted just to the default py35<br>
>> >> unittesting.<br>
>> >><br>
>> >> As always let us know if you questions,<br>
>> >> Clark<br>
>> ><br>
>> > How soon can projects replace py34 with py35?<br>
>><br>
>> As soon as you think your project is ready, you can replace py34 with<br>
>> py35 for master.<br>
>><br>
>> ><br>
>> > I tried py35 for neutron locally, and it ran without errors.<br>
>><br>
>> Then let it run for a day or two in our CI, discuss with neutron team,<br>
>> and send a patch for project-config to change the setup,<br>
>><br>
>> Andreas<br>
>> --<br>
>> Andreas Jaeger aj@{<a href="http://suse.com" rel="noreferrer" target="_blank">suse.com</a>,<a href="http://opensuse.org" rel="noreferrer" target="_blank">opensuse.org</a>} Twitter/Identica: jaegerandi<br>
>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany<br>
>> GF: Felix Imend?rffer, Jane Smithard, Graham Norton,<br>
>> HRB 21284 (AG N?rnberg)<br>
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 18<br>
>> Date: Mon, 4 Jul 2016 08:59:50 +0300<br>
>> From: Denis Makogon <<a href="mailto:lildee1991@gmail.com" target="_blank">lildee1991@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> Message-ID:<br>
>> <CALzSdtnL==UYr7-WS54G=<br>
>> <a href="mailto:HJrFxSHwESdF-W-W6Sz8F7jKe1wfQ@mail.gmail.com" target="_blank">HJrFxSHwESdF-W-W6Sz8F7jKe1wfQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> 2016-07-04 8:18 GMT+03:00 Andreas Jaeger <<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>>:<br>
>><br>
>> > On 07/03/2016 09:26 PM, Henry Gessau wrote:<br>
>> > > Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
>> > >> The infra team is working on taking advantage of the new Ubuntu<br>
>> Xenial<br>
>> > >> release including running unittests on python35. The current plan is<br>
>> to<br>
>> > >> get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday<br>
>> (July<br>
>> > >> 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> > >> master/Newton on all projects that had python34 testing.<br>
>> > >><br>
>> > >> The expectation is that in many cases python35 tests will just work<br>
>> if<br>
>> > >> python34 testing was also working. If this is the case for your<br>
>> project<br>
>> > >> you can propose a change to openstack-infra/project-config to make<br>
>> these<br>
>> > >> jobs voting against your project. You should only need to edit<br>
>> > >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> > >> portion of the python35 jobs to do this.<br>
>> > >><br>
>> > >> We do however expect that there will be a large group of failed tests<br>
>> > >> too. If your project has a specific tox.ini py34 target to restrict<br>
>> > >> python3 testing to a specific list of tests you will need to add a<br>
>> tox<br>
>> > >> target for py35 that does the same thing as the py34 target. We have<br>
>> > >> also seen bug reports against some projects whose tests rely on<br>
>> stable<br>
>> > >> error messages from Python itself which isn't always the case across<br>
>> > >> version changes so these tests will need to be updated as well.<br>
>> > >><br>
>> > >> Note this change will not add python35 jobs for cases where projects<br>
>> > >> have special tox targets. This is restricted just to the default py35<br>
>> > >> unittesting.<br>
>> > >><br>
>> > >> As always let us know if you questions,<br>
>> > >> Clark<br>
>> > ><br>
>> > > How soon can projects replace py34 with py35?<br>
>> ><br>
>> > As soon as you think your project is ready, you can replace py34 with<br>
>> > py35 for master.<br>
>> ><br>
>> > ><br>
>> > > I tried py35 for neutron locally, and it ran without errors.<br>
>> ><br>
>> > Then let it run for a day or two in our CI, discuss with neutron team,<br>
>> > and send a patch for project-config to change the setup,<br>
>> ><br>
>> ><br>
>> Can confirm that nova, glance, cinder, heat clients are py35 compatible.<br>
>><br>
>><br>
>> > Andreas<br>
>> > --<br>
>> > Andreas Jaeger aj@{<a href="http://suse.com" rel="noreferrer" target="_blank">suse.com</a>,<a href="http://opensuse.org" rel="noreferrer" target="_blank">opensuse.org</a>} Twitter/Identica: jaegerandi<br>
>> > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany<br>
>> > GF: Felix Imend?rffer, Jane Smithard, Graham Norton,<br>
>> > HRB 21284 (AG N?rnberg)<br>
>> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126<br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8da19224/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8da19224/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 19<br>
>> Date: Mon, 4 Jul 2016 14:12:01 +0800<br>
>> From: Zhenyu Zheng <<a href="mailto:zhengzhenyulixi@gmail.com" target="_blank">zhengzhenyulixi@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Nova] Questions about instance actions'<br>
>> update and finish<br>
>> Message-ID:<br>
>> <CAO0b__-CoU9UDaVQEFrtL9=<br>
>> <a href="mailto:L92TbZhJUwkYfs9iA7R-xVM%2Bpwg@mail.gmail.com" target="_blank">L92TbZhJUwkYfs9iA7R-xVM+pwg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> I'm willing to work on this, should this be a Blueprint for O?<br>
>><br>
>> On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann <<br>
>> <a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> wrote:<br>
>><br>
>> > On 7/3/2016 6:21 AM, Alex Xu wrote:<br>
>> ><br>
>> >><br>
>> >><br>
>> >> 2016-07-02 2:32 GMT+08:00 Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
>> >> <mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>>:<br>
>> >><br>
>> >><br>
>> >> On 06/30/2016 08:31 AM, Andrew Laski wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:<br>
>> >> >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:<br>
>> >> >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:<br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:<br>
>> >> >>>>> How about I sync updated_at and created_at in my patch, and<br>
>> >> leave the<br>
>> >> >>>>> finish to the other BP, by this way, I can use updated_at for<br>
>> >> the<br>
>> >> >>>>> timestamp filter I added and it don't need to change again<br>
>> once<br>
>> >> the<br>
>> >> >>>>> finish BP is complete.<br>
>> >> >>>><br>
>> >> >>>> Sounds good to me.<br>
>> >> >>>><br>
>> >> >>><br>
>> >> >>> It's been a long day so my memory might be fried, but the<br>
>> options<br>
>> >> we<br>
>> >> >>> talked about in the API meeting were:<br>
>> >> >>><br>
>> >> >>> 1. Setting updated_at = created_at when the instance action<br>
>> >> record is<br>
>> >> >>> created. Laski likes this, I'm not crazy about it, especially<br>
>> >> since we<br>
>> >> >>> don't do that for anything else.<br>
>> >> ><br>
>> >> > I would actually like for us to do this generally. I have the<br>
>> same<br>
>> >> > thinking as Ed does elsewhere in this thread, the creation of a<br>
>> >> record<br>
>> >> > is an update of that record. So take my comments as applying to<br>
>> Nova<br>
>> >> > overall and not just this issue.<br>
>> >><br>
>> >> Agree. Also it just simplifies a number of things. We should just<br>
>> >> start<br>
>> >> doing this going forward, and probably put some online data<br>
>> migrations<br>
>> >> in place next cycle to update all the old records. Once updated_at<br>
>> >> can't<br>
>> >> be null, we can handle things like this a bit better.<br>
>> >><br>
>> >><br>
>> >> The marker should be a column with UniqueConstraint, the updated_at is<br>
>> >> not. But if we say the accuracy is ok, there will have problem with<br>
>> >> updated_at as None.<br>
>> >><br>
>> ><br>
>> > Yeah I thought about this later, we don't use a timestamp field as a<br>
>> > marker for anything else, and as noted it's not a non-nullable unique<br>
>> > field, plus it's mutable which worries me for a marker field (created_at<br>
>> > wouldn't change, but updated_at could).<br>
>> ><br>
>> ><br>
>> >> Anyway, we already freeze... probably we can begin to fix the<br>
>> updated_at<br>
>> >> problem first.<br>
>> >><br>
>> >><br>
>> >> >>> 2. Update the instance action's updated_at when instance action<br>
>> >> events<br>
>> >> >>> are created. I like this since the instance action is like a<br>
>> >> parent<br>
>> >> >>> resource and the event is the child, so when we create/modify<br>
>> an<br>
>> >> event<br>
>> >> >>> we can consider it an update to the parent. Laski thought this<br>
>> >> might be<br>
>> >> >>> weird UX given we don't expose instance action events in the<br>
>> REST<br>
>> >> API<br>
>> >> >>> unless you're an admin. This is also probably not something<br>
>> we'd<br>
>> >> do for<br>
>> >> >>> other related resources like server groups and server group<br>
>> >> members (but<br>
>> >> >>> we don't page on those either right now).<br>
>> >> ><br>
>> >> > Right. My concern is just that the ordering of actions can change<br>
>> >> based<br>
>> >> > on events happening which are not visible to the user. However<br>
>> >> thinking<br>
>> >> > about it further we don't really allow multiple actions at once,<br>
>> >> except<br>
>> >> > for a few special cases like delete, so this may not end up<br>
>> >> affecting<br>
>> >> > any ordering as actions are mostly serial. I think this is a fine<br>
>> >> > solution for the issue at hand. I just think #1 is a more general<br>
>> >> > solution.<br>
>> >> ><br>
>> >> >>><br>
>> >> >>> 3. Order the results by updated_at,created_at so that if<br>
>> >> updated_at<br>
>> >> >>> isn't set for older records, created_at will be used. I think<br>
>> we<br>
>> >> all<br>
>> >> >>> agreed in the meeting to do this regardless of #1 or #2 above.<br>
>> >><br>
>> >> I kind of hate that as the order, because then the marker is going<br>
>> to<br>
>> >> have to be really funny double timestamp, right?<br>
>> >><br>
>> >><br>
>> >> The marker only needs to fill with the unique value. There isn't any<br>
>> >> problem order with multiple column. Some time we need order with<br>
>> >> mulitple column for stable order when the first order column is<br>
>> >> without UniqueConstraint.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> I guess that's the one thing I don't see in this patch is a<br>
>> functional<br>
>> >> test that actually loads up instance actions and iterates through<br>
>> >> demonstrating the pagination.<br>
>> >><br>
>> >> -Sean<br>
>> >><br>
>> >> --<br>
>> >> Sean Dague<br>
>> >> <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
>> >><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <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>
>> >> <<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> ><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>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <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>
>> >><br>
>> ><br>
>> > --<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Matt Riedemann<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 20<br>
>> Date: Mon, 4 Jul 2016 13:17:11 +0700<br>
>> From: Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com" target="_blank">renat.akhmerov@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [mistral][osc-lib][openstackclient] is it<br>
>> too early for orc-lib?<br>
>> Message-ID: <<a href="mailto:08997983-1194-4693-AD10-0DF81D014289@gmail.com" target="_blank">08997983-1194-4693-AD10-0DF81D014289@gmail.com</a>><br>
>> Content-Type: text/plain; charset="us-ascii"<br>
>><br>
>> Ok, based on what has been said here I suggest we keep this code for now.<br>
>> The changes were really minimal. If it creates some problems for us we can<br>
>> always easily revert.<br>
>><br>
>> Renat Akhmerov<br>
>> @Nokia<br>
>><br>
>> > On 01 Jul 2016, at 04:57, Steve Martinelli <<a href="mailto:s.martinelli@gmail.com" target="_blank">s.martinelli@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> > The crux of this, as Dean stated, is if the library wants OSC to always<br>
>> be pulled in (along with its many dependencies). We've seen folks include<br>
>> it in requirements, test-requirements, or even not at all (just document<br>
>> that OSC needs to be installed).<br>
>> ><br>
>> > I tossed up the idea with the ironic team of leveraging "extras" field<br>
>> to list OSC as optional, the change would look like:<br>
>> ><br>
>> > --- a/setup.cfg<br>
>> > +++ b/setup.cfg<br>
>> > @@ -22,6 +22,10 @@ classifier =<br>
>> ><br>
>> > +[extras]<br>
>> > +cli =<br>
>> > + python-openstackclient>=3.0.0 # Apache-2.0<br>
>> > +<br>
>> ><br>
>> > So, if a user wanted to install just the python binding of ironicclient<br>
>> or mistralclient, they would do $ pip install python-ironicclient; if a<br>
>> user wanted the CLI as well.. $ pip install python-ironicclient[cli]<br>
>> ><br>
>> > Just an idea, it may be overkill and completely horrible.<br>
>> ><br>
>> > On Thu, Jun 30, 2016 at 5:29 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br>
>> <mailto:<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>>> wrote:<br>
>> > On Thu, Jun 30, 2016 at 8:38 AM, Hardik <<br>
>> <a href="mailto:hardik.parekh@nectechnologies.in" target="_blank">hardik.parekh@nectechnologies.in</a> <mailto:<a href="mailto:hardik.parekh@nectechnologies.in" target="_blank">hardik.parekh@nectechnologies.in</a>>><br>
>> wrote:<br>
>> > Regarding osc-lib we have mainly two changes.<br>
>> ><br>
>> > 1) Used "utils" which is moved from openstackclient.common.utils to<br>
>> osc_lib.utils<br>
>> > 2) We used "command" which wrapped in osc_lib from cliff.<br>
>> ><br>
>> > So I think there is no harm in keeping osc_lib.<br>
>> ><br>
>> > Admittedly the change to include osc-lib is a little early, I would<br>
>> have preferred until the other parts of it were a bit more stable.<br>
>> ><br>
>> > Also, I guess we do not need openstackclient to be installed with<br>
>> mistralclient as if mistral is used in standalone mode<br>
>> > there is no need of openstackclient.<br>
>> ><br>
>> > The choice to include OSC as a dependency of a plugin/library rests<br>
>> entirely on the plugin team, and that will usually be determined by the<br>
>> answer to the question "Do you want all users of your library to have OSc<br>
>> installed even if they do not use it?" or alternatively "Do you want to<br>
>> make your users remember to install OSC after installing the plugin?"<br>
>> ><br>
>> > Note that we do intend to have the capability on osc-lib to build an<br>
>> OSC-like stand-alone binary for plugins that would theoretically make<br>
>> installing OSC optional for stand-alone client users. This is not complete<br>
>> yet, and as I said above, one reason I wish osc-lib had not been merged<br>
>> into plugin requirements yet. That said, as long as you don't use those<br>
>> bits yet you will be fine, the utils, command, etc bits are stable, it is<br>
>> the clientmanager and shell parts that are still being developed.<br>
>> ><br>
>> > dt<br>
>> ><br>
>> > --<br>
>> ><br>
>> > Dean Troyer<br>
>> > <a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a> <mailto:<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
>> <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>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 21<br>
>> Date: Mon, 4 Jul 2016 08:22:11 +0200<br>
>> From: Kashyap Chamarthy <<a href="mailto:kchamart@redhat.com" target="_blank">kchamart@redhat.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [nova][infra][ci] bulk repeating a test<br>
>> job on a single review in parallel ?<br>
>> Message-ID: <20160704062211.hunhz5zexs42lh43@eukaryote><br>
>> Content-Type: text/plain; charset=us-ascii<br>
>><br>
>> On Fri, Jul 01, 2016 at 02:35:34PM +0000, Jeremy Stanley wrote:<br>
>> > On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote:<br>
>> > > [Snip description of some nice debugging.]<br>
>> > ><br>
>> > > > I'd really love it if there was<br>
>> > > ><br>
>> > > > 1. the ability to request checking of just specific jobs eg<br>
>> > > ><br>
>> > > > "recheck gate-tempest-dsvm-multinode-full"<br>
>> > ><br>
>> > > Yes, this would really be desirable. I recall once asking this exact<br>
>> > > question on #openstack-infra, but can't find Infra team's response to<br>
>> > > that.<br>
>> ><br>
>> > The challenge here is that you want to make sure it can't be used to<br>
>> > recheck individual jobs until you have them all passing (like<br>
>> > picking a pin and tumbler lock). The temptation to recheck-spam<br>
>> > nondeterministically failing changes is already present, but this<br>
>> > would make it considerably easier still for people to introduce new<br>
>> > nondeterministic failures in projects. Maybe if it were tied to a<br>
>> > special pipeline type, and then we set it only for the experimental<br>
>> > pipeline or something?<br>
>><br>
>> If it reduces nondeterministic spam for the CI Infra, and makes us<br>
>> achieve the task at hand, sure. [/me need to educate himself a<br>
>> bit more on the Zuul pipeline infrastructure.]<br>
>><br>
>> Worth filing this (and your 'idle pipeline' thought below) in the Zuul<br>
>> tracker here?<br>
>><br>
>> <a href="https://storyboard.openstack.org/#!/project/679" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/project/679</a><br>
>><br>
>> > > > 2. the ability to request this recheck to run multiple<br>
>> > > > times in parallel. eg if i just repeat the 'recheck'<br>
>> > > > command many times on the same patchset # without<br>
>> > > > waiting for results<br>
>> > ><br>
>> > > Yes, this too, would be _very_ useful for all the reasons you<br>
>> described.<br>
>> > [...]<br>
>> ><br>
>> > In the past we've discussed the option of having an "idle pipeline"<br>
>> > which repeatedly runs specified jobs only when there are unused<br>
>> > resources available, so that it doesn't significantly cut into our<br>
>> > resource pool when we're under high demand but still allows to<br>
>> > automatically collect a large amount of statistical data.<br>
>> ><br>
>> > Anyway, hopefully James Blair can weigh in on this, since Zuul is<br>
>> > basically in a feature freeze for a while to limit the number of<br>
>> > significant changes we'll need to forward-port into the v3 branch.<br>
>> > We'd want to discuss these new features in the context of Zuul v3<br>
>> > instead.<br>
>><br>
>> > --<br>
>> > Jeremy Stanley<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> --<br>
>> /kashyap<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 22<br>
>> Date: Mon, 4 Jul 2016 15:10:47 +0800<br>
>> From: Luck Dog <<a href="mailto:dfhuangg@gmail.com" target="_blank">dfhuangg@gmail.com</a>><br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
>> Subject: [openstack-dev] [tricircle]<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CAL-y67hjWJ7XrOUjLiMZGV2va_5z_921jxMN3YL1a-GCh%2Bi58w@mail.gmail.com" target="_blank">CAL-y67hjWJ7XrOUjLiMZGV2va_5z_921jxMN3YL1a-GCh+i58w@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hello everyone,<br>
>><br>
>> I am trying to run DevStack on Ubuntu 14.04 in a single VirtualBox. An<br>
>> error turns up before it successfully starts. Yesterday I clarified this<br>
>> question not clearly enough?so I make a supplication for it. My steps<br>
>> are:<br>
>> 1), Git clone DevStack,<br>
>> 2), Copy devstack/local.conf.sample to DevStack folder and rename it to<br>
>> local.conf.<br>
>><br>
>> the finished steps before the error turns up are listed as follows:<br>
>><br>
>> 2016-06-29 09:11:53.081 | stack.sh log<br>
>> /opt/stack/logs/stack.sh.log.2016-06-29-171152<br>
>> 2016-06-29 09:12:19.797 | Installing package prerequisites<br>
>> 2016-06-29 09:15:27.224 | Installing OpenStack project source<br>
>> 2016-06-29 09:24:43.323 | Installing Tricircle<br>
>> 2016-06-29 09:24:55.979 | Starting RabbitMQ<br>
>> 2016-06-29 09:25:00.731 | Configuring and starting MySQL<br>
>> 2016-06-29 09:25:20.143 | Starting Keystone<br>
>> 2016-06-29 09:43:18.591 | Configuring Glance<br>
>> 2016-06-29 09:43:59.667 | Configuring Neutron<br>
>> 2016-06-29 09:46:30.646 | Configuring Cinder<br>
>> 2016-06-29 09:46:54.719 | Configuring Nova<br>
>> 2016-06-29 09:48:23.175 | Configuring Tricircle<br>
>> 2016-06-29 09:51:24.143 | Starting Glance<br>
>> 2016-06-29 09:52:11.133 | Uploading images<br>
>> 2016-06-29 09:52:45.460 | Starting Nova API<br>
>> 2016-06-29 09:53:27.511 | Starting Neutron<br>
>> 2016-06-29 09:54:21.476 | Creating initial neutron network elements<br>
>><br>
>> The last errors when it stops running are:<br>
>><br>
>> Request body: {u'network': {u'router:external': True,<br>
>> u'provider:network_type': u'flat', u'name': u'public',<br>
>> u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m<br>
>> ^[[00;33mfrom (pid=29980) prepare_request_body<br>
>> /opt/stack/neutron/neutron/api/v2/base.py:674^[[00m<br>
>> 2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver<br>
>> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources<br>
>> subnetpool have unlimited quota limit. It is not required to calculate<br>
>> headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
>> /opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m<br>
>> 2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver<br>
>> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to<br>
>> reserve 1 items for resource network. Total usage: 0; quota limit: 10;<br>
>> headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
>> /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m<br>
>> 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource<br>
>> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate<br>
>> failed^[[00m<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00mTraceback (most recent call last):<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/resource.py",<br>
>> line<br>
>> 78, in resource<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m result = method(request=request, **args)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
>> 424, in create<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m return self._create(request, body, **kwargs)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File<br>
>> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in<br>
>> wrapper<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m ectxt.value = e.inner_exc<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File<br>
>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221,<br>
>> in __exit__<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m self.force_reraise()<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File<br>
>> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197,<br>
>> in force_reraise<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m six.reraise(self.type_, self.value, self.tb)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File<br>
>> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in<br>
>> wrapper<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m return f(*args, **kwargs)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
>> 535, in _create<br>
>> [[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m return obj_creator(request.context, **kwargs)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File "/opt/stack/tricircle/tricircle/network/plugin.py",<br>
>> line 238, in create_network<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m is_external =<br>
>> self._ensure_az_set_for_external_network(net_data)<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m File "/opt/stack/tricircle/tricircle/network/plugin.py",<br>
>> line 184, in _ensure_az_set_for_external_network<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m raise t_exceptions.ExternalNetPodNotSpecify()<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00mExternalNetPodNotSpecify: Pod for external network not<br>
>> specified<br>
>> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> ^[[01;35m^[[00m<br>
>> 2016-06-29 17:56:04.439 ^[[00;36mINFO neutron.wsgi<br>
>> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> 13869ba8005b480bbcbe17b2695fd5e2^[[00;36m] ^[[01;35m^[[00;36m127.0.0.1 - -<br>
>> [29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368<br>
>> 0.147805^[[00m<br>
>><br>
>> the final printed errors on terminal are:<br>
>><br>
>> Request Failed: internal server error while processing your request.<br>
>> Neutron server returns request_ids:<br>
>> ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
>> lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
>> lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
>> [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
>> EXT_NET_ID for public<br>
>><br>
>> I don't know whether it is my wrong configuration of computer or the<br>
>> server error, I wish someone can help me with the problem. thanks!<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a5c3d6b4/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a5c3d6b4/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 23<br>
>> Date: Mon, 4 Jul 2016 09:14:00 +0200<br>
>> From: Victor Stinner <<a href="mailto:vstinner@redhat.com" target="_blank">vstinner@redhat.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> Message-ID: <<a href="mailto:dd699b65-c199-2ec5-4e4a-70236971d5d4@redhat.com" target="_blank">dd699b65-c199-2ec5-4e4a-70236971d5d4@redhat.com</a>><br>
>> Content-Type: text/plain; charset=windows-1252; format=flowed<br>
>><br>
>> Le 04/07/2016 ? 07:59, Denis Makogon a ?crit :<br>
>> > Then let it run for a day or two in our CI, discuss with neutron<br>
>> team,<br>
>> > and send a patch for project-config to change the setup,<br>
>> ><br>
>> > Can confirm that nova, glance, cinder, heat clients are py35 compatible.<br>
>><br>
>> tox.ini of Nova, Swift and Trove need to be modified to copy/paste the<br>
>> whitelist of tests running on Python 3. Fix for Nova:<br>
>><br>
>> <a href="https://review.openstack.org/#/c/336432/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336432/</a><br>
>><br>
>> Victor<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 24<br>
>> Date: Mon, 4 Jul 2016 10:25:07 +0300<br>
>> From: Elena Ezhova <<a href="mailto:eezhova@mirantis.com" target="_blank">eezhova@mirantis.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Cc: "<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question<br>
>> Message-ID:<br>
>> <CAFZxAhh=S0QfS+K=<br>
>> <a href="mailto:Jtgmx26TMH_goxYFEibKkBmVWLowL7FGUQ@mail.gmail.com" target="_blank">Jtgmx26TMH_goxYFEibKkBmVWLowL7FGUQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi!<br>
>><br>
>> You also have to configure Octavia on your controller. The most<br>
>> straightforward way would be to follow the steps that are done in Octavia<br>
>> DevStack plugin<br>
>> <<br>
>> <a href="https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh" rel="noreferrer" target="_blank">https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh</a><br>
>> >.<br>
>> There is also an overview presentation<br>
>> <<br>
>> <a href="https://docs.google.com/presentation/d/1AqmF3BnKLLu1W1n-XT5MSfVYrGue1JIwKSvjbWgGA6s/edit#slide=id.p4" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1AqmF3BnKLLu1W1n-XT5MSfVYrGue1JIwKSvjbWgGA6s/edit#slide=id.p4</a><br>
>> ><br>
>> which<br>
>> has some troubleshooting tips.<br>
>><br>
>> Thanks,<br>
>> Elena<br>
>><br>
>> On Sat, Jul 2, 2016 at 1:24 AM, zhihao wang <<a href="mailto:wangzhihaocom@hotmail.com" target="_blank">wangzhihaocom@hotmail.com</a>><br>
>> wrote:<br>
>><br>
>> > Dear OpenStack Dev member:<br>
>> ><br>
>> > May I ask you some question about neutron lbaaS?<br>
>> ><br>
>> > How to install the neutron LBaaS with Octavia in Mitaka?<br>
>> > I followed these two guide ,but which one I should use? (My openstack is<br>
>> > Mitaka , 1 controller, 2 compute nodes)<br>
>> ><br>
>> > <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun</a> -- Ubuntu<br>
>> > Packages Setup<br>
>> > <a href="http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html" rel="noreferrer" target="_blank">http://docs.openstack.org/mitaka/networking-guide/adv-config-lbaas.html</a><br>
>> > -- Configuring LBaaS v2 with Octavia<br>
>> ><br>
>> > Here is what I did:<br>
>> ><br>
>> > pip install octavia<br>
>> ><br>
>> > and then :<br>
>> > vim /etc/neutron/neutron.conf<br>
>> > service_plugins =<br>
>> > router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2<br>
>> ><br>
>> > [service_providers]<br>
>> > service_provider =<br>
>> ><br>
>> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default<br>
>> ><br>
>> > /etc/openstack-dashboard/local_settings.py<br>
>> ><br>
>> ><br>
>> > OPENSTACK_NEUTRON_NETWORK = {<br>
>> > 'enable_lb': True<br>
>> > }<br>
>> ><br>
>> ><br>
>> > And then I restart all the neutron service and apache server<br>
>> > service neutron-server restart<br>
>> > service neutron-dhcp-agent restart<br>
>> > service neutron-metadata-agent restart<br>
>> > service neutron-l3-agent restart<br>
>> ><br>
>> > but and then i ran the command neutron agent-list, it return this. I am<br>
>> > wondering what is wrong with this? how can I install Neutron LaaS?<br>
>> ><br>
>> > root@controller:~# neutron agent-list<br>
>> > Unable to establish connection to<br>
>> <a href="http://controller:9696/v2.0/agents.json" rel="noreferrer" target="_blank">http://controller:9696/v2.0/agents.json</a><br>
>> ><br>
>> ><br>
>> > Please help<br>
>> ><br>
>> > Thanks so much<br>
>> ><br>
>> > Thanks<br>
>> > Wally<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/26f31912/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/26f31912/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 25<br>
>> Date: Mon, 4 Jul 2016 09:38:19 +0200<br>
>> From: Antoni Segura Puimedon <<a href="mailto:toni%2Bopenstackml@midokura.com" target="_blank">toni+openstackml@midokura.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split<br>
>> Message-ID:<br>
>> <CAP8JW8DxfO+KMPKriHST2w-3k_zRKi_yKu6j=8j2En=<br>
>> <a href="mailto:QqR3u4A@mail.gmail.com" target="_blank">QqR3u4A@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> On Fri, Jul 1, 2016 at 7:58 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>><br>
>> wrote:<br>
>><br>
>> > Excerpts from Jeremy Stanley's message of 2016-07-01 15:05:30 +0000:<br>
>> > > On 2016-07-01 08:26:13 -0500 (-0500), Monty Taylor wrote:<br>
>> > > [...]<br>
>> > > > Check with Doug Hellman about namespaces. We used to use them in<br>
>> some<br>
>> > > > oslo things and had to step away from them because of some pretty<br>
>> weird<br>
>> > > > and horrible breakage issues.<br>
>> > > [...]<br>
>> > ><br>
>> > > Or read the associated Oslo spec from when that was done:<br>
>> > ><br>
>> > > <URL:<br>
>> ><br>
>> <a href="https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html</a><br>
>> > ><br>
>> > ><br>
>> ><br>
>> > Yes, please don't use python namespaces. It's a cool feature, as you<br>
>> > say, but the setuptools implementation available for Python 2 has some<br>
>> > buggy edge cases that we hit on a regular basis before moving back to<br>
>> > regular packages. It might be something we could look into again when<br>
>> > we're running only on Python 3, since at that point the feature is built<br>
>> > into the language.<br>
>> ><br>
>><br>
>> For kuryr-kubernetes we target only Python3, I wonder if we could move<br>
>> kuryr-libnetwork<br>
>> to be python3 only and, if that were the case, how this alters the<br>
>> situation for namespace<br>
>> packages.<br>
>><br>
>><br>
>> ><br>
>> > Doug<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/15cceea8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/15cceea8/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 26<br>
>> Date: Mon, 4 Jul 2016 16:13:28 +0800<br>
>> From: Damon Wang <<a href="mailto:damon.devops@gmail.com" target="_blank">damon.devops@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades<br>
>> work status. 6/20/2016<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CABZYMH4S8tc3XxAQbgRsuE2YyDwo6rf5v2u7u0KF%2BwFtceRaWw@mail.gmail.com" target="_blank">CABZYMH4S8tc3XxAQbgRsuE2YyDwo6rf5v2u7u0KF+wFtceRaWw@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Very glad to see *Bi-weekly Upgrades Work Status*, besides, we<br>
>> (UnitedStack) are also writing a Chinese version of weekly neutron status:<br>
>><br>
>> <a href="http://bit.ly/29nTorX" rel="noreferrer" target="_blank">http://bit.ly/29nTorX</a><br>
>><br>
>> We wrote from 4.3 and now have wrote 12 pieces. :-D<br>
>><br>
>> Wei Wang<br>
>><br>
>> 2016-06-20 21:58 GMT+08:00 Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>>:<br>
>><br>
>> > Hi all,<br>
>> ><br>
>> > (It?s not really bi-weekly since I missed it the previous week. This<br>
>> > report is for the last 3 weeks. I will try to keep a more regular<br>
>> schedule<br>
>> > for those updates in the future.)<br>
>> ><br>
>> > OK. What?s new in neutron upgrades since last update?<br>
>> ><br>
>> > 1. For the most part, the team works on migrating existing code base to<br>
>> > using versioned objects.<br>
>> ><br>
>> > What landed:<br>
>> ><br>
>> > - base db plugin switched to objects for subnetpools:<br>
>> > <a href="https://review.openstack.org/300056" rel="noreferrer" target="_blank">https://review.openstack.org/300056</a><br>
>> > - get_object(s) API now allows to pass renamed fields as filters:<br>
>> > <a href="https://review.openstack.org/327249" rel="noreferrer" target="_blank">https://review.openstack.org/327249</a><br>
>> ><br>
>> > What?s in the queue:<br>
>> > - utilizing DNSNameServer object in the code:<br>
>> > <a href="https://review.openstack.org/326477" rel="noreferrer" target="_blank">https://review.openstack.org/326477</a><br>
>> > - security groups object: <a href="https://review.openstack.org/284738" rel="noreferrer" target="_blank">https://review.openstack.org/284738</a><br>
>> > - *PortSecurity objects: <a href="https://review.openstack.org/327257" rel="noreferrer" target="_blank">https://review.openstack.org/327257</a><br>
>> ><br>
>> > There are things still crafting worth mentioning:<br>
>> > - subnet adoption in db code: <a href="https://review.openstack.org/321001" rel="noreferrer" target="_blank">https://review.openstack.org/321001</a><br>
>> > - subnet object adjustments: <a href="https://review.openstack.org/331009" rel="noreferrer" target="_blank">https://review.openstack.org/331009</a><br>
>> > - address scope adoption: <a href="https://review.openstack.org/#/c/308005/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/308005/</a><br>
>> ><br>
>> > A lot of api test coverage for sorting and pagination happened. That is<br>
>> > something that we push for before we switch resources to using objects<br>
>> to<br>
>> > avoid potential regressions. Things that landed:<br>
>> > - next/prev href links tests: <a href="https://review.openstack.org/318270" rel="noreferrer" target="_blank">https://review.openstack.org/318270</a><br>
>> > - subnet tests: <a href="https://review.openstack.org/329340" rel="noreferrer" target="_blank">https://review.openstack.org/329340</a><br>
>> > - subnetpools tests: <a href="https://review.openstack.org/327081" rel="noreferrer" target="_blank">https://review.openstack.org/327081</a><br>
>> ><br>
>> > We have a lot more related patches though, including test coverage as<br>
>> well<br>
>> > as enabling sorting/pagination for all installations. All those are<br>
>> tracked<br>
>> > under:<br>
>> ><br>
>> ><br>
>> ><br>
>> <a href="https://review.openstack.org/#/q/status:open++(topic:bug/1566514+OR+topic:bug/1591981)" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open++(topic:bug/1566514+OR+topic:bug/1591981)</a><br>
>> ><br>
>> > Reviews for ^ are highly welcome!<br>
>> ><br>
>> > There were other related changes that landed in master:<br>
>> > - migrated code from using private ._context attributes to .obj_context:<br>
>> > <a href="https://review.openstack.org/283616" rel="noreferrer" target="_blank">https://review.openstack.org/283616</a><br>
>> > - added type information to ObjectNotFound exception:<br>
>> > <a href="https://review.openstack.org/327582" rel="noreferrer" target="_blank">https://review.openstack.org/327582</a><br>
>> > - NetworkDhcpAgentBinding model moved to a separate module:<br>
>> > <a href="https://review.openstack.org/328452" rel="noreferrer" target="_blank">https://review.openstack.org/328452</a><br>
>> > - get_object() switched to using _query_model to support RBAC filtering:<br>
>> > <a href="https://review.openstack.org/#/c/326361/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/326361/</a><br>
>> > - query filter hook added to objects:<br>
>> <a href="https://review.openstack.org/328304" rel="noreferrer" target="_blank">https://review.openstack.org/328304</a><br>
>> > - qos policy filtering by ?shared? field is fixed by utilizing ^:<br>
>> > <a href="https://review.openstack.org/328313" rel="noreferrer" target="_blank">https://review.openstack.org/328313</a><br>
>> ><br>
>> > 2. As for multinode grenade testing, there was little progress on<br>
>> getting<br>
>> > voting for the DVR job. This is something that I plan to tackle in the<br>
>> near<br>
>> > future.<br>
>> ><br>
>> > ===<br>
>> ><br>
>> > Team info:<br>
>> > Upgrades Subteam has the weekly meetings on Mondays, 2PM UTC, wiki page:<br>
>> > <a href="https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</a><br>
>> ><br>
>> > New patches are generally tracked under the following topic:<br>
>> ><br>
>> <a href="https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db</a><br>
>> ><br>
>> > Ihar<br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e0472273/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e0472273/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 27<br>
>> Date: Mon, 4 Jul 2016 01:17:29 -0700<br>
>> From: Stephen Hindle <<a href="mailto:shindle@llnw.com" target="_blank">shindle@llnw.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +<br>
>> BiFrost integration<br>
>> Message-ID:<br>
>> <CANPbtN_EUx_PV8FYEvQCaTR5XEKp98wik2USYfF=<br>
>> <a href="mailto:EugBFXL2jg@mail.gmail.com" target="_blank">EugBFXL2jg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>> Hi Steve<br>
>><br>
>> I'm just suggesting the bi-frost stuff allow sufficient 'hooks' for<br>
>> operators to insert site specific setup. Not that Kolla/Bi-Frost try<br>
>> to handle 'everything'.<br>
>><br>
>> For instance LDAP... Horizon integration with LDAP would certainly<br>
>> be within Kolla's perview. However, operators also use LDAP for login<br>
>> access to the host via PAM. This is site-specific, and outside of<br>
>> Kolla's mission.<br>
>><br>
>> As an example of 'respecting existing configuration' - some sites<br>
>> may use OpenVSwitch for host level networking. Kolla currently starts<br>
>> a new openvswitchdb container without checking if OpenVSwitch is<br>
>> already running - this kills the host networking.<br>
>><br>
>> If you'll pardon the pun, there are a 'host' of situations like<br>
>> this, where operators will have to provide<br>
>> (possibly many/detailed) site specific configurations to a bare metal<br>
>> host. Networking, Security, Backups, Monitoring/Logging, etc. These<br>
>> may all be subject to corporate wide policies that are non-negotiable<br>
>> and have to be followed.<br>
>><br>
>> Again, I realize Kolla/BiFrost can not be everything for everyone.<br>
>> I just want to suggest that we provide well documented methods for<br>
>> operators to insert site-specific roles/plays/whatever, and that we<br>
>> take care to avoid 'stepping on' things.<br>
>><br>
>> I have no idea as to what/how-many 'hooks' would be required. I<br>
>> tend to think a simple 'before-bifrost' role and 'after-bifrost' role<br>
>> would be enough. However, others may have more input on that...<br>
>> I like the idea of using roles, as that would allow you to centralize<br>
>> all your 'site-specific' bits. This way operators don't have to<br>
>> modify the existing kolla/BiFrost stuff.<br>
>><br>
>><br>
>> On Sat, Jul 2, 2016 at 3:10 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>><br>
>> wrote:<br>
>> > Stephen,<br>
>> ><br>
>> > Responses inline.<br>
>> ><br>
>> > On 7/1/16, 11:35 AM, "Stephen Hindle" <<a href="mailto:shindle@llnw.com" target="_blank">shindle@llnw.com</a>> wrote:<br>
>> ><br>
>> >>Maybe I missed it - but is there a way to provide site specific<br>
>> >>configurations? Things we will run into in the wild include:<br>
>> >> Configuring multiple non-openstack nics<br>
>> ><br>
>> > We don?t have anything like this at present or planned. Would you mind<br>
>> > explaining the use case? Typically we in the Kolla community expect a<br>
>> > production deployment to only deploy OpenStack, and not other stacks on<br>
>> > top of the bare metal hardware. This is generally considered best<br>
>> > practice at this time, unless of course your deploying something on top<br>
>> of<br>
>> > OpenStack that may need these nics. The reason is that OpenStack itself<br>
>> > managed alongside another application doesn?t know what it doesn't know<br>
>> > and can't handle capacity management or any of a number of other things<br>
>> > required to make an OpenStack cloud operate.<br>
>> ><br>
>> >> IPMI configuration<br>
>> ><br>
>> > BiFrost includes IPMI integration - assumption being we will just use<br>
>> > whatever BiFrost requires here for configuration.<br>
>> ><br>
>> >> Password integration with Corporate LDAP etc.<br>
>> ><br>
>> > We have been asked several times for this functionality, and it will<br>
>> come<br>
>> > naturally during either Newton or Occata.<br>
>> ><br>
>> >> Integration with existing SANs<br>
>> ><br>
>> > Cinder integrates with SANs, and in Newton, we have integration with<br>
>> > iSCSI. Unfortunately because of some controversy around how glance<br>
>> should<br>
>> > provide images with regards to cinder, using existing SAN gear with<br>
>> iSCSI<br>
>> > integration as is done by Cinder may not work as expected in a HA setup.<br>
>> ><br>
>> >> Integration with existing corporate IPAM<br>
>> ><br>
>> > No idea<br>
>> ><br>
>> >> Corporate Security policy (firewall rules, sudo groups,<br>
>> >>hosts.allow, ssh configs,etc)<br>
>> ><br>
>> > This is environmental specific and its hard to make a promise on what we<br>
>> > could deliver in a generic way that would be usable by everyone.<br>
>> > Therefore our generic implementation will be the "bare minimum" to get<br>
>> the<br>
>> > system into an operational state. The things listed above are outside<br>
>> the<br>
>> > "bare minimum" iiuc.<br>
>> ><br>
>> >><br>
>> >>Thats just off the top of my head - I'm sure we'll run into others. I<br>
>> >>tend to think the best way<br>
>> >>to approach this is to allow some sort of 'bootstrap' role, that could<br>
>> >>be populated by the<br>
>> >>operators. This should initially be empty (Kolla specific 'bootstrap'<br>
>> ><br>
>> > Our bootstrap playbook is for launching BiFrost and bringing up the bare<br>
>> > metal machines with an SSH credential. It appears from this thread we<br>
>> > will have another playbook to do the bare metal initialization (thiings<br>
>> > like turning off firewalld, turning on chrony, I.e. Making the bare<br>
>> metal<br>
>> > environment operational for OpenStack)<br>
>> ><br>
>> > I think what you want is a third playbook which really belongs in the<br>
>> > domain of the operators to handle site-specific configuration as<br>
>> required<br>
>> > by corporate rules and the like.<br>
>> ><br>
>> ><br>
>> >>actions should be<br>
>> >>in another role) to prevent confusion.<br>
>> >><br>
>> >>We also have to be careful that kolla doesn't stomp on any non-kolla<br>
>> >>configuration...<br>
>> ><br>
>> > Could you expand here. Kolla currently expects the machines under its<br>
>> > control to be only OpenStack machines, and not have other applications<br>
>> > running on them.<br>
>> ><br>
>> > Hope that was helpful.<br>
>> ><br>
>> > Regards<br>
>> > -steve<br>
>> ><br>
>> >><br>
>> >><br>
>> >>On Thu, Jun 30, 2016 at 12:43 PM, Mooney, Sean K<br>
>> >><<a href="mailto:sean.k.mooney@intel.com" target="_blank">sean.k.mooney@intel.com</a>> wrote:<br>
>> >>><br>
>> >>><br>
>> >>>> -----Original Message-----<br>
>> >>>> From: Steven Dake (stdake) [mailto:<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>]<br>
>> >>>> Sent: Monday, June 27, 2016 9:21 PM<br>
>> >>>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> >>>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +<br>
>> >>>> BiFrost integration<br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> On 6/27/16, 11:19 AM, "Devananda van der Veen"<br>
>> >>>> <<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>><br>
>> >>>> wrote:<br>
>> >>>><br>
>> >>>> >At a quick glance, this sequence diagram matches what I<br>
>> >>>> >envisioned/expected.<br>
>> >>>> ><br>
>> >>>> >I'd like to suggest a few additional steps be called out, however<br>
>> I'm<br>
>> >>>> >not sure how to edit this so I'll write them here.<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> >As part of the installation of Ironic, and assuming this is done<br>
>> >>>> >through Bifrost, the Actor should configure Bifrost for their<br>
>> >>>> >particular network environment. For instance: what eth device is<br>
>> >>>> >connected to the IPMI network; what IP ranges can Bifrost assign to<br>
>> >>>> >physical servers; and so on.<br>
>> >>>> ><br>
>> >>>> >There are a lot of other options during the install that can be<br>
>> >>>> >changed, but the network config is the most important. Full defaults<br>
>> >>>> >for this roles' config options are here:<br>
>> >>>> ><br>
>> >>>> ><br>
>> <a href="https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro" rel="noreferrer" target="_blank">https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro</a><br>
>> >>>> s<br>
>> >>>> >t-i<br>
>> >>>> >ronic-install/defaults/main.yml<br>
>> >>>> ><br>
>> >>>> >and documentation is here:<br>
>> >>>> ><br>
>> >>>> ><br>
>> <a href="https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro" rel="noreferrer" target="_blank">https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro</a><br>
>> >>>> s<br>
>> >>>> >t-i<br>
>> >>>> >ronic-install<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> >Immediately before "Ironic PXE boots..." step, the Actor must<br>
>> perform<br>
>> >>>> >an action to "enroll" hardware (the "deployment targets") in Ironic.<br>
>> >>>> >This could be done in several ways: passing a YAML file to Bifrost;<br>
>> >>>> >using the Ironic CLI; or something else.<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> >"Ironic reports success to the bootstrap operation" is ambiguous.<br>
>> >>>> >Ironic does not currently support notifications, so, to learn the<br>
>> >>>> >status of the deployments, you will need to poll the Ironic API (eg,<br>
>> >>>> >"ironic node-list").<br>
>> >>>> ><br>
>> >>>><br>
>> >>>> Great,<br>
>> >>>><br>
>> >>>> Thanks for the feedback. I'll integrate your changes into the<br>
>> sequence<br>
>> >>>> diagram when I have a free hour or so - whenever that is :)<br>
>> >>>><br>
>> >>>> Regards<br>
>> >>>> -steve<br>
>> >>> [Mooney, Sean K] I agree with most of devananda points and had come to<br>
>> >>>similar<br>
>> >>> Conlcutions.<br>
>> >>><br>
>> >>> At a highlevel I think the workflow from 0 to cloud would be as<br>
>> follow.<br>
>> >>> Assuming you have one linux system.<br>
>> >>> - clone <a href="http://github.com/openstack/kolla" rel="noreferrer" target="_blank">http://github.com/openstack/kolla</a> && cd kolla<br>
>> >>> - tools/kolla-host build-host-deploy<br>
>> >>> This will install ansible if not installed then invoke a<br>
>> >>>playbook to install<br>
>> >>> All build dependencies and generate the kolla-build.conf<br>
>> >>>passwords.yml and global.yml.<br>
>> >>> Install kolla python package<br>
>> >>> - configure kolla-build.conf as required<br>
>> >>> - tools/build.py or kolla-build to build image<br>
>> >>> - configure global.yml and or biforst specific file<br>
>> >>> This would involve specifying a file that can be used with bifrost<br>
>> >>>dynamic inventory.<br>
>> >>> Configuring network interface for bifrost to use.<br>
>> >>> Enable ssh-key generate or supply one to use as the key to us when<br>
>> >>>connecting to the servers post deploy.<br>
>> >>> Configure diskimage builder options or supply path to a file on the<br>
>> >>>system to use as your os image.<br>
>> >>> - tools/kolla-host deploy-bifrost<br>
>> >>> Deploys bifrost container.<br>
>> >>> Copies images/keys<br>
>> >>> Bootstraps bifrost and start services.<br>
>> >>> - tools/kolla-host deploy-servers<br>
>> >>> Invokes bifrost enroll and deploy dynamic then polls until all<br>
>> >>> Servers are provisioned or a server fails.<br>
>> >>> - tools/kolla-hosts bootstrap-servers<br>
>> >>> Installs all kolla deploy dependencies<br>
>> >>> Docker ect. This will also optionally do things such as<br>
>> >>> Configure hugepages, configure cpu isolation, firewall settings<br>
>> >>> Or any other platform level config for example apply labels to ceph<br>
>> >>> Disks .<br>
>> >>> This role will reboot the remote server at the end of the role if<br>
>> >>>required<br>
>> >>> e.g. after installing The wily kernel on Ubuntu 14.04<br>
>> >>> - configure global.yml as normal<br>
>> >>> - tools/kolla-ansible prechecks (this should now pass)<br>
>> >>> - tools/kolla-ansible deploy<br>
>> >>> - profit<br>
>> >>><br>
>> >>> I think this largely agrees with the diagram you proposed but has a<br>
>> >>>couple of extra steps/details.<br>
>> >>><br>
>> >>>><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> >Cheers,<br>
>> >>>> >--Devananda<br>
>> >>>> ><br>
>> >>>> >On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:<br>
>> >>>> >> Hey folks,<br>
>> >>>> >><br>
>> >>>> >> I created the following sequence diagram to show my thinking on<br>
>> >>>> >>Ironic integration. I recognize some internals of the recently<br>
>> >>>> >>merged bifrost changes are not represented in this diagram. I<br>
>> would<br>
>> >>>> >>like to see a bootstrap action do all of the necessary things to<br>
>> >>>> >>bring up BiFrost in a container using Sean's WIP Kolla patch<br>
>> >>>> followed<br>
>> >>>> >>by bare metal minimal OS load followed by Kolla dependency<br>
>> software<br>
>> >>>> >>(docker-engine, docker-py, and ntpd) loading and initialization.<br>
>> >>>> >><br>
>> >>>> >> This diagram expects ssh keys to be installed on the deployment<br>
>> >>>> >>targets via BiFrost.<br>
>> >>>> >><br>
>> >>>> >><br>
>> <a href="https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D" rel="noreferrer" target="_blank">https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D</a><br>
>> >>>> >><br>
>> >>>> >> Thoughts welcome, especially from folks in the Ironic community or<br>
>> >>>> >>Sean who is leading this work in Kolla.<br>
>> >>>> >><br>
>> >>>> >> Regards,<br>
>> >>>> >> -steve<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>><br>
>> >>_____________________________________________________________________<br>
>> >>>> _<br>
>> >>>> >>___<br>
>> >>>> >>_<br>
>> >>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> >> Unsubscribe:<br>
>> >>>> >><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>
>> >>>> ><br>
>> >>>><br>
>> >______________________________________________________________________<br>
>> >>>> _<br>
>> >>>> >___ OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> >Unsubscribe:<br>
>> >>>> ><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>
>> >>>><br>
>> >>>><br>
>> _______________________________________________________________________<br>
>> >>>> ___<br>
>> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> Unsubscribe: OpenStack-dev-<br>
>> >>>> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">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>
>> >>><br>
>><br>
>> >>>_________________________________________________________________________<br>
>> >>>_<br>
>> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>> Unsubscribe:<br>
>> >>><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>
>> >><br>
>> >><br>
>> >>--<br>
>> >>Stephen Hindle - Senior Systems Engineer<br>
>> >><a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a> <a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a><br>
>> >><a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
>> >><br>
>> >>Join the conversation<br>
>> >><br>
>> >>at Limelight Connect<br>
>> >><br>
>> >>--<br>
>> >>The information in this message may be confidential. It is intended<br>
>> >>solely<br>
>> >>for<br>
>> >>the addressee(s). If you are not the intended recipient, any<br>
>> disclosure,<br>
>> >>copying or distribution of the message, or any action or omission taken<br>
>> >>by<br>
>> >>you<br>
>> >>in reliance on it, is prohibited and may be unlawful. Please<br>
>> immediately<br>
>> >>contact the sender if you have received this message in error.<br>
>> >><br>
>> >><br>
>><br>
>> >>__________________________________________________________________________<br>
>> >>OpenStack Development Mailing List (not for usage questions)<br>
>> >>Unsubscribe:<br>
>> <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>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>><br>
>><br>
>> --<br>
>> Stephen Hindle - Senior Systems Engineer<br>
>> <a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a> <a href="tel:480.807.8189" value="+14808078189" target="_blank">480.807.8189</a><br>
>> <a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
>><br>
>> Join the conversation<br>
>><br>
>> at Limelight Connect<br>
>><br>
>> --<br>
>> The information in this message may be confidential. It is intended<br>
>> solely<br>
>> for<br>
>> the addressee(s). If you are not the intended recipient, any disclosure,<br>
>> copying or distribution of the message, or any action or omission taken by<br>
>> you<br>
>> in reliance on it, is prohibited and may be unlawful. Please immediately<br>
>> contact the sender if you have received this message in error.<br>
>><br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 28<br>
>> Date: Mon, 4 Jul 2016 16:02:53 +0800<br>
>> From: <a href="mailto:hu.zhijiang@zte.com.cn" target="_blank">hu.zhijiang@zte.com.cn</a><br>
>> To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka<br>
>> requirementssupported by CentOS<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:OF685C0E9F.8AD230D6-ON48257FE6.002BD37A-48257FE6.002C2309@zte.com.cn" target="_blank">OF685C0E9F.8AD230D6-ON48257FE6.002BD37A-48257FE6.002C2309@zte.com.cn</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> > As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> > It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> > updates to fit OpenStack requirements.<br>
>><br>
>> > Actually, all the dependency above but ansible, docker and git python<br>
>> > modules are in CentOS Cloud SIG repositories.<br>
>> > If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> > dependencies in our repositories.<br>
>><br>
>> I added [kolla] key word in the mail subject. Hope can get response from<br>
>> Kolla team about how to choose repos.<br>
>><br>
>><br>
>> Thanks,<br>
>> Zhijiang<br>
>><br>
>><br>
>><br>
>> ???: Ha?kel <<a href="mailto:hguemar@fedoraproject.org" target="_blank">hguemar@fedoraproject.org</a>><br>
>> ???: "OpenStack Development Mailing List (not for usage<br>
>> questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>,<br>
>> ??: 2016-07-03 05:18<br>
>> ??: [probably forge email???????]Re: [openstack-dev]<br>
>> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS<br>
>><br>
>><br>
>><br>
>> 2016-07-02 20:42 GMT+02:00 jason <<a href="mailto:huzhijiang@gmail.com" target="_blank">huzhijiang@gmail.com</a>>:<br>
>> > Pip Package Name Supported By Centos CentOS Name Repo Name<br>
>> ><br>
>><br>
>> ======================================================================================================================<br>
>> > ansible yes<br>
>> > ansible1.9.noarch epel<br>
>> > docker-py yes<br>
>> > python-docker-py.noarch extras<br>
>> > gitdb yes<br>
>> > python-gitdb.x86_64 epel<br>
>> > GitPython yes<br>
>> > GitPython.noarch epel<br>
>> > oslo.config yes<br>
>> > python2-oslo-config.noarch centos-openstack-mitaka<br>
>> > pbr yes<br>
>> > python-pbr.noarch epel<br>
>> > setuptools yes<br>
>> > python-setuptools.noarch base<br>
>> > six yes<br>
>> > python-six.noarch base<br>
>> > pycrypto yes<br>
>> > python2-crypto epel<br>
>> > graphviz no<br>
>> > Jinja2 no (Note: Jinja2 2.7.2 will be installed as<br>
>> > dependency by ansible)<br>
>> ><br>
>><br>
>> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> updates to fit OpenStack requirements.<br>
>><br>
>> Actually, all the dependency above but ansible, docker and git python<br>
>> modules are in CentOS Cloud SIG repositories.<br>
>> If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> dependencies in our repositories.<br>
>><br>
>><br>
>> ><br>
>> > As above table shows, only two (graphviz and Jinja2) are not supported<br>
>> > by centos currently. As those not supported packages are definitly not<br>
>> > used by OpenStack as well as Daisy. So basicaly we can use pip to<br>
>> > install them after installing other packages by yum. But note that<br>
>> > Jinja2 2.7.2 will be installed as dependency while yum install<br>
>> > ansible, so we need to using pip to install jinja2 2.8 after that to<br>
>> > overide the old one. Also note that we must make sure pip is ONLY used<br>
>> > for installing those two not supported packages.<br>
>> ><br>
>> > But before you trying to use pip, please consider these:<br>
>> ><br>
>> > 1) graphviz is just for saving image depend graph text file and is not<br>
>> > used by default and only used in build process if it is configured to<br>
>> > be used.<br>
>> ><br>
>> > 2) Jinja2 rpm can be found at<br>
>> > <a href="http://koji.fedoraproject.org/koji/packageinfo?packageID=6506" rel="noreferrer" target="_blank">http://koji.fedoraproject.org/koji/packageinfo?packageID=6506</a>, which I<br>
>> > think is suitable for CentOS. I have tested it.<br>
>> ><br>
>> > So, as far as Kolla deploy process concerned, there is no need to use<br>
>> > pip to install graphviz and Jinja2. Further more, if we do not install<br>
>> > Kolla either then we can get ride of pip totally!<br>
>> ><br>
>> > I encourage all of you to think about not using pip any more for<br>
>> > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files<br>
>> > may be overide back and force if not using them carefully. So not<br>
>> > using pip will make things easier and make jump server more cleaner.<br>
>> > Any ideas?<br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> > Zhijiang<br>
>> ><br>
>> > --<br>
>> > Yours,<br>
>> > Jason<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <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>
>><br>
>> --------------------------------------------------------<br>
>> ZTE Information Security Notice: The information contained in this mail<br>
>> (and any attachment transmitted herewith) is privileged and confidential<br>
>> and is intended for the exclusive use of the addressee(s). If you are not<br>
>> an intended recipient, any disclosure, reproduction, distribution or other<br>
>> dissemination or use of the information contained is strictly prohibited.<br>
>> If you have received this mail in error, please delete it and notify us<br>
>> immediately.<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/5317a4dc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/5317a4dc/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 29<br>
>> Date: Mon, 4 Jul 2016 16:36:30 +0800<br>
>> From: Gerard Braad <<a href="mailto:me@gbraad.nl" target="_blank">me@gbraad.nl</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka<br>
>> requirementssupported by CentOS<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CAGrH30XrpdS2D8UvPdcSMfMdJM1ExsKysaX_f0gLa4miUyf6oQ@mail.gmail.com" target="_blank">CAGrH30XrpdS2D8UvPdcSMfMdJM1ExsKysaX_f0gLa4miUyf6oQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset=UTF-8<br>
>><br>
>> Hi,<br>
>><br>
>> > ???: Ha?kel <<a href="mailto:hguemar@fedoraproject.org" target="_blank">hguemar@fedoraproject.org</a>><br>
>> > As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> > It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> > updates to fit OpenStack requirements.<br>
>> > Actually, all the dependency above but ansible, docker and git python<br>
>> > modules are in CentOS Cloud SIG repositories.<br>
>> > If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> > dependencies in our repositories.<br>
>><br>
>> Interesting point, as currently the preference is to use docker<br>
>> project's provided<br>
>> packages for installing. This means that `docker-storage-setup` is not<br>
>> available.<br>
>> This can actually be very helpful for CentOS-based deployments to get a<br>
>> production-ready environment setup.<br>
>><br>
>><br>
>> Gerard<br>
>><br>
>> --<br>
>><br>
>> Gerard Braad | <a href="http://gbraad.nl" rel="noreferrer" target="_blank">http://gbraad.nl</a><br>
>> [ Doing Open Source Matters ]<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 30<br>
>> Date: Mon, 4 Jul 2016 16:35:00 +0800<br>
>> From: <a href="mailto:hu.zhijiang@zte.com.cn" target="_blank">hu.zhijiang@zte.com.cn</a><br>
>> To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: [openstack-dev] ??: [probably forge email???????]Re:<br>
>> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:OFCB261F89.4C7A08C6-ON48257FE6.002EC1D3-48257FE6.002F1386@zte.com.cn" target="_blank">OFCB261F89.4C7A08C6-ON48257FE6.002EC1D3-48257FE6.002F1386@zte.com.cn</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi Ha?kel<br>
>><br>
>> > Actually, all the dependency above but ansible, docker and git python<br>
>> > modules are in CentOS Cloud SIG repositories.<br>
>> > If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> > dependencies in our repositories.<br>
>><br>
>> So currently Jinja2 version >= 2.8 is already in the CentOS Cloud SIG<br>
>> repository. could you please point a way to get it? That will be a great<br>
>> help for us to use kolla, because currenly we are using fedora repo<br>
>> <a href="http://koji.fedoraproject.org/koji/packageinfo?packageID=6506" rel="noreferrer" target="_blank">http://koji.fedoraproject.org/koji/packageinfo?packageID=6506</a> to get<br>
>> Jinja2 version >= 2.8, but we are sure that CentOS Cloud SIG repository<br>
>> will be a more better choise than fedora repo.<br>
>><br>
>><br>
>><br>
>><br>
>> ???: Ha?kel <<a href="mailto:hguemar@fedoraproject.org" target="_blank">hguemar@fedoraproject.org</a>><br>
>> ???: "OpenStack Development Mailing List (not for usage<br>
>> questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>,<br>
>> ??: 2016-07-03 05:18<br>
>> ??: [probably forge email???????]Re: [openstack-dev]<br>
>> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS<br>
>><br>
>><br>
>><br>
>> 2016-07-02 20:42 GMT+02:00 jason <<a href="mailto:huzhijiang@gmail.com" target="_blank">huzhijiang@gmail.com</a>>:<br>
>> > Pip Package Name Supported By Centos CentOS Name Repo Name<br>
>> ><br>
>><br>
>> ======================================================================================================================<br>
>> > ansible yes<br>
>> > ansible1.9.noarch epel<br>
>> > docker-py yes<br>
>> > python-docker-py.noarch extras<br>
>> > gitdb yes<br>
>> > python-gitdb.x86_64 epel<br>
>> > GitPython yes<br>
>> > GitPython.noarch epel<br>
>> > oslo.config yes<br>
>> > python2-oslo-config.noarch centos-openstack-mitaka<br>
>> > pbr yes<br>
>> > python-pbr.noarch epel<br>
>> > setuptools yes<br>
>> > python-setuptools.noarch base<br>
>> > six yes<br>
>> > python-six.noarch base<br>
>> > pycrypto yes<br>
>> > python2-crypto epel<br>
>> > graphviz no<br>
>> > Jinja2 no (Note: Jinja2 2.7.2 will be installed as<br>
>> > dependency by ansible)<br>
>> ><br>
>><br>
>> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> updates to fit OpenStack requirements.<br>
>><br>
>> Actually, all the dependency above but ansible, docker and git python<br>
>> modules are in CentOS Cloud SIG repositories.<br>
>> If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> dependencies in our repositories.<br>
>><br>
>><br>
>> ><br>
>> > As above table shows, only two (graphviz and Jinja2) are not supported<br>
>> > by centos currently. As those not supported packages are definitly not<br>
>> > used by OpenStack as well as Daisy. So basicaly we can use pip to<br>
>> > install them after installing other packages by yum. But note that<br>
>> > Jinja2 2.7.2 will be installed as dependency while yum install<br>
>> > ansible, so we need to using pip to install jinja2 2.8 after that to<br>
>> > overide the old one. Also note that we must make sure pip is ONLY used<br>
>> > for installing those two not supported packages.<br>
>> ><br>
>> > But before you trying to use pip, please consider these:<br>
>> ><br>
>> > 1) graphviz is just for saving image depend graph text file and is not<br>
>> > used by default and only used in build process if it is configured to<br>
>> > be used.<br>
>> ><br>
>> > 2) Jinja2 rpm can be found at<br>
>> > <a href="http://koji.fedoraproject.org/koji/packageinfo?packageID=6506" rel="noreferrer" target="_blank">http://koji.fedoraproject.org/koji/packageinfo?packageID=6506</a>, which I<br>
>> > think is suitable for CentOS. I have tested it.<br>
>> ><br>
>> > So, as far as Kolla deploy process concerned, there is no need to use<br>
>> > pip to install graphviz and Jinja2. Further more, if we do not install<br>
>> > Kolla either then we can get ride of pip totally!<br>
>> ><br>
>> > I encourage all of you to think about not using pip any more for<br>
>> > Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files<br>
>> > may be overide back and force if not using them carefully. So not<br>
>> > using pip will make things easier and make jump server more cleaner.<br>
>> > Any ideas?<br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> > Zhijiang<br>
>> ><br>
>> > --<br>
>> > Yours,<br>
>> > Jason<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <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>
>><br>
>> --------------------------------------------------------<br>
>> ZTE Information Security Notice: The information contained in this mail<br>
>> (and any attachment transmitted herewith) is privileged and confidential<br>
>> and is intended for the exclusive use of the addressee(s). If you are not<br>
>> an intended recipient, any disclosure, reproduction, distribution or other<br>
>> dissemination or use of the information contained is strictly prohibited.<br>
>> If you have received this mail in error, please delete it and notify us<br>
>> immediately.<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a220fac9/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a220fac9/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 31<br>
>> Date: Mon, 4 Jul 2016 09:40:22 +0100<br>
>> From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
>> To: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>><br>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>,<br>
>> "<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>"<br>
>> <<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Openstack-operators] [nova] Fail build<br>
>> request if we can't inject files?<br>
>> Message-ID: <<a href="mailto:20160704084021.GA3763@redhat.com" target="_blank">20160704084021.GA3763@redhat.com</a>><br>
>> Content-Type: text/plain; charset=utf-8<br>
>><br>
>> On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote:<br>
>> > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it<br>
>> runs<br>
>> > ssh validation + neutron + config drive + metadata service, which will<br>
>> test<br>
>> > the virtual device tagging 2.32 microversion API (added last week).<br>
>> ><br>
>> > The job has a file injection test that fails consistently which is<br>
>> keeping<br>
>> > it from being voting.<br>
>> ><br>
>> > After debugging, the problem is the files to inject are silently ignored<br>
>> > because n-cpu is configured with libvirt.inject_partition=-2 by default.<br>
>> > That disables file injection:<br>
>> ><br>
>> ><br>
>> <a href="https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030</a><br>
>> ><br>
>> > We don't even log a warning if the user requested files to inject and we<br>
>> > can't honor it. If I were a user and tried to inject files when<br>
>> creating a<br>
>> > server but they didn't show up in the guest, I'd open a support ticket<br>
>> > against my cloud provider. So I don't think a warning (that only the<br>
>> admin<br>
>> > sees) is sufficient here. This isn't something that's discoverable from<br>
>> the<br>
>> > API either, it's really host configuration / capability (something we<br>
>> still<br>
>> > need to tackle).<br>
>><br>
>> Won't the user provided files also get made available by the config drive<br>
>> /<br>
>> metadata service ? I think that's the primary reason for file injection<br>
>> not<br>
>> being a fatal problem. Oh that and the fact that we've wanted to kill it<br>
>> for<br>
>> at least 3 years now :-)<br>
>><br>
>> Regards,<br>
>> Daniel<br>
>> --<br>
>> |: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o-<br>
>> <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
>> |: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o-<br>
>> <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
>> |: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o-<br>
>> <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
>> |: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o-<br>
>> <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
>><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 32<br>
>> Date: Mon, 04 Jul 2016 11:16:09 +0200<br>
>> From: Julien Danjou <<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>><br>
>> To: Denis Makogon <<a href="mailto:lildee1991@gmail.com" target="_blank">lildee1991@gmail.com</a>><br>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python<br>
>> clients<br>
>> Message-ID: <<a href="mailto:m04m85bw6e.fsf@danjou.info" target="_blank">m04m85bw6e.fsf@danjou.info</a>><br>
>> Content-Type: text/plain; charset="us-ascii"<br>
>><br>
>> On Sun, Jun 26 2016, Denis Makogon wrote:<br>
>><br>
>> > I know that some work in progress to bring Python 3.4 compatibility to<br>
>> > backend services and it is kinda hard question to answer, but i'd like<br>
>> to<br>
>> > know if there are any plans to support asynchronous HTTP API client in<br>
>> the<br>
>> > nearest future using aiohttp [1] (PEP-3156)?<br>
>><br>
>> I don't think there is unfortunately. Most clients now relies on<br>
>> `requests', and unfortunately it's not async not it seems ready to be<br>
>> last time I checked.<br>
>><br>
>> --<br>
>> Julien Danjou<br>
>> // Free Software hacker<br>
>> // <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
>> -------------- next part --------------<br>
>> A non-text attachment was scrubbed...<br>
>> Name: signature.asc<br>
>> Type: application/pgp-signature<br>
>> Size: 800 bytes<br>
>> Desc: not available<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a07dc24c/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a07dc24c/attachment-0001.pgp</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 33<br>
>> Date: Mon, 4 Jul 2016 11:17:40 +0200<br>
>> From: Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel<br>
>> Library Core<br>
>> Message-ID:<br>
>> <CA+HkNVup=8XN9cRU-Te7B13G5TM8LP=c7FLWskqte=<br>
>> <a href="mailto:fyOBQMBg@mail.gmail.com" target="_blank">fyOBQMBg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi,<br>
>><br>
>> Please welcome Maksim as he's just joined fuel-library Core Team!<br>
>><br>
>> --<br>
>> Best regards,<br>
>> Sergii Golovatiuk,<br>
>> Skype #golserge<br>
>> IRC #holser<br>
>><br>
>> On Tue, Jun 28, 2016 at 1:06 PM, Adam Heczko <<a href="mailto:aheczko@mirantis.com" target="_blank">aheczko@mirantis.com</a>><br>
>> wrote:<br>
>><br>
>> > Although I'm not Fuel core, +1 from me to Maksim. Maksim is not only<br>
>> > excellent engineer but also very friendly and helpful folk.<br>
>> ><br>
>> > On Tue, Jun 28, 2016 at 12:19 PM, Georgy Kibardin <<br>
>> <a href="mailto:gkibardin@mirantis.com" target="_blank">gkibardin@mirantis.com</a>><br>
>> > wrote:<br>
>> ><br>
>> >> +1<br>
>> >><br>
>> >> On Tue, Jun 28, 2016 at 1:12 PM, Kyrylo Galanov <<a href="mailto:kgalanov@mirantis.com" target="_blank">kgalanov@mirantis.com</a><br>
>> ><br>
>> >> wrote:<br>
>> >><br>
>> >>> +1<br>
>> >>><br>
>> >>> On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn <<br>
>> >>> <a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>> wrote:<br>
>> >>><br>
>> >>>> +1. Maksim is an excellent reviewer.<br>
>> >>>><br>
>> >>>> On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz <<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a><br>
>> ><br>
>> >>>> wrote:<br>
>> >>>> > +1<br>
>> >>>> ><br>
>> >>>> > On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya <<br>
>> >>>> <a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>><br>
>> >>>> > wrote:<br>
>> >>>> >><br>
>> >>>> >> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:<br>
>> >>>> >> > I am very sorry for sending without subject. I am adding<br>
>> subject to<br>
>> >>>> >> > voting and my +1<br>
>> >>>> >><br>
>> >>>> >> +1 from my side!<br>
>> >>>> >><br>
>> >>>> >> ><br>
>> >>>> >> > --<br>
>> >>>> >> > Best regards,<br>
>> >>>> >> > Sergii Golovatiuk,<br>
>> >>>> >> > Skype #golserge<br>
>> >>>> >> > IRC #holser<br>
>> >>>> >> ><br>
>> >>>> >> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk<br>
>> >>>> >> > <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a> <mailto:<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>>><br>
>> >>>> wrote:<br>
>> >>>> >> ><br>
>> >>>> >> > Hi,<br>
>> >>>> >> ><br>
>> >>>> >> > I would like to nominate Maksim Malchuk to Fuel-Library Core<br>
>> >>>> team.<br>
>> >>>> >> > He?s been doing a great job so far [0]. He?s #2 reviewer<br>
>> and #2<br>
>> >>>> >> > contributor with 28 commits for last 90 days [1][2].<br>
>> >>>> >> ><br>
>> >>>> >> > Fuelers, please vote with +1/-1 for approval/objection.<br>
>> Voting<br>
>> >>>> will<br>
>> >>>> >> > be open until July of 4th. This will go forward after<br>
>> voting is<br>
>> >>>> >> > closed if there are no objections.<br>
>> >>>> >> ><br>
>> >>>> >> > Overall contribution:<br>
>> >>>> >> > [0] <a href="http://stackalytics.com/?user_id=mmalchuk" rel="noreferrer" target="_blank">http://stackalytics.com/?user_id=mmalchuk</a><br>
>> >>>> >> > Fuel library contribution for last 90 days:<br>
>> >>>> >> > [1]<br>
>> >>>> >> > <<a href="http://stackalytics.com/report/contribution/fuel-library/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/fuel-library/90</a>><br>
>> >>>> <a href="http://stackalytics.com/report/contribution/fuel-library/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/fuel-library/90</a><br>
>> >>>> >> > <a href="http://stackalytics.com/report/users/mmalchuk" rel="noreferrer" target="_blank">http://stackalytics.com/report/users/mmalchuk</a><br>
>> >>>> >> > List of reviews:<br>
>> >>>> >> > [2]<br>
>> >>>> >> ><br>
>> >>>><br>
>> <a href="https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z</a><br>
>> >>>> >> > --<br>
>> >>>> >> > Best regards,<br>
>> >>>> >> > Sergii Golovatiuk,<br>
>> >>>> >> > Skype #golserge<br>
>> >>>> >> > IRC #holser<br>
>> >>>> >> ><br>
>> >>>> >> ><br>
>> >>>> >> ><br>
>> >>>> >> ><br>
>> >>>> >> ><br>
>> >>>> >> ><br>
>> >>>><br>
>> __________________________________________________________________________<br>
>> >>>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> >> > Unsubscribe:<br>
>> >>>> >> > <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>
>> >>>> >> ><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>
>> >>>> >><br>
>> >>>> >><br>
>> >>>> >> --<br>
>> >>>> >> Best regards,<br>
>> >>>> >> Bogdan Dobrelya,<br>
>> >>>> >> Irc #bogdando<br>
>> >>>> >><br>
>> >>>> >><br>
>> >>>><br>
>> __________________________________________________________________________<br>
>> >>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> >> Unsubscribe:<br>
>> >>>> <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>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>><br>
>> __________________________________________________________________________<br>
>> >>>> > OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> > Unsubscribe:<br>
>> >>>> <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>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> __________________________________________________________________________<br>
>> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> Unsubscribe:<br>
>> >>>> <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>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> __________________________________________________________________________<br>
>> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>> Unsubscribe:<br>
>> >>> <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>
>> >>><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <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>
>> >><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Adam Heczko<br>
>> > Security Engineer @ Mirantis Inc.<br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <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>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8cbfe82f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8cbfe82f/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 34<br>
>> Date: Mon, 4 Jul 2016 12:36:30 +0300<br>
>> From: Denis Makogon <<a href="mailto:lildee1991@gmail.com" target="_blank">lildee1991@gmail.com</a>><br>
>> To: Denis Makogon <<a href="mailto:lildee1991@gmail.com" target="_blank">lildee1991@gmail.com</a>>, "OpenStack Development<br>
>> Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python<br>
>> clients<br>
>> Message-ID:<br>
>> <CALzSdtnQtzUNCjP+6u4GO=qNesD0q+KZPDZ7=<br>
>> <a href="mailto:QmSGcrG7oqr9A@mail.gmail.com" target="_blank">QmSGcrG7oqr9A@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> 2016-07-04 12:16 GMT+03:00 Julien Danjou <<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>>:<br>
>><br>
>> > On Sun, Jun 26 2016, Denis Makogon wrote:<br>
>> ><br>
>> > > I know that some work in progress to bring Python 3.4 compatibility to<br>
>> > > backend services and it is kinda hard question to answer, but i'd<br>
>> like to<br>
>> > > know if there are any plans to support asynchronous HTTP API client in<br>
>> > the<br>
>> > > nearest future using aiohttp [1] (PEP-3156)?<br>
>> ><br>
>> > I don't think there is unfortunately. Most clients now relies on<br>
>> > `requests', and unfortunately it's not async not it seems ready to be<br>
>> > last time I checked.<br>
>> ><br>
>> ><br>
>> Unfortunately, it is what it is. So, i guess this is something that is<br>
>> worth considering discuss during summit and find the way and capacity to<br>
>> support async HTTP API during next release. I'll start work on general<br>
>> concept that would satisfy both 2.7 and 3.4 or greater Python versions.<br>
>><br>
>> What would be the best place to submit spec?<br>
>><br>
>><br>
>> --<br>
>> > Julien Danjou<br>
>> > // Free Software hacker<br>
>> > // <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
>> ><br>
>><br>
>> Kind regards,<br>
>> Denys Makogon<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e88a5547/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e88a5547/attachment.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
>><br>
>> End of OpenStack-dev Digest, Vol 51, Issue 6<br>
>> ********************************************<br>
>><br>
><br>
><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>
><br>
<br>
<br>
--<br>
Email:<br>
<a href="mailto:shinobu@linux.com" target="_blank">shinobu@linux.com</a><br>
<a href="mailto:shinobu@redhat.com" target="_blank">shinobu@redhat.com</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/51fe3162/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/51fe3162/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
<br>
End of OpenStack-dev Digest, Vol 51, Issue 9<br>
********************************************<br>
</blockquote></div><br></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"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Email:<br><a href="mailto:shinobu@linux.com" target="_blank">shinobu@linux.com</a><br><a href="mailto:shinobu@redhat.com" target="_blank">shinobu@redhat.com</a></div>
</div>