<div dir="ltr"><div>Would you attach local.conf you're using?<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 11:51 AM, 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"><div>Hello everyone<span style="font-size:14px">,</span><br></div><div><div><span style="font-size:14px"> </span><span style="font-size:14px">I am running the devstack with patch Tricircle,according to steps given by official net page,</span><a href="https://github.com/openstack/tricircle#play-with-devstack" style="font-size:14px" target="_blank">https://github.com/openstack/tricircle#play-with-devstack</a><span style="font-size:14px">.But it always failed at the same place.The errors are listed as follows.(according to the stack.sh.logs)</span></div><div><br style="font-size:14px"><span style="font-size:14px">Request body: {u'network': {u'router:external': True,</span><br style="font-size:14px"><span style="font-size:14px">u'provider:network_type': u'flat', u'name': u'public',</span><br style="font-size:14px"><span style="font-size:14px">u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m</span><br style="font-size:14px"><span style="font-size:14px">^[[00;33mfrom (pid=29980) prepare_request_body</span><br style="font-size:14px"><span style="font-size:14px">/opt/stack/neutron/neutron/</span><span style="font-size:14px">api/v2/base.py:674^[[00m</span><br style="font-size:14px"><span style="font-size:14px">2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver</span><br style="font-size:14px"><span style="font-size:14px">[^[[01;36mreq-e97f6276-8e19-</span><span style="font-size:14px">408b-829a-004a31256453 ^[[00;36madmin</span><br style="font-size:14px"><span style="font-size:14px">13869ba8005b480bbcbe17b2695fd5</span><span style="font-size:14px">e2^[[00;32m] ^[[01;35m^[[00;32mResources</span><br style="font-size:14px"><span style="font-size:14px">subnetpool have unlimited quota limit. It is not required to calculate</span><br style="font-size:14px"><span style="font-size:14px">headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation</span><br style="font-size:14px"><span style="font-size:14px">/opt/stack/neutron/neutron/db/</span><span style="font-size:14px">quota/driver.py:191^[[00m</span><br style="font-size:14px"><span style="font-size:14px">2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver</span><br style="font-size:14px"><span style="font-size:14px">[^[[01;36mreq-e97f6276-8e19-</span><span style="font-size:14px">408b-829a-004a31256453 ^[[00;36madmin</span><br style="font-size:14px"><span style="font-size:14px">13869ba8005b480bbcbe17b2695fd5</span><span style="font-size:14px">e2^[[00;32m] ^[[01;35m^[[00;32mAttempting to</span><br style="font-size:14px"><span style="font-size:14px">reserve 1 items for resource network. Total usage: 0; quota limit: 10;</span><br style="font-size:14px"><span style="font-size:14px">headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation</span><br style="font-size:14px"><span style="font-size:14px">/opt/stack/neutron/neutron/db/</span><span style="font-size:14px">quota/driver.py:223^[[00m</span><br style="font-size:14px"><span style="font-size:14px">2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">[^[[01;36mreq-e97f6276-8e19-</span><span style="font-size:14px">408b-829a-004a31256453 ^[[00;36madmin</span><br style="font-size:14px"><span style="font-size:14px">13869ba8005b480bbcbe17b2695fd5</span><span style="font-size:14px">e2^[[01;31m] ^[[01;35m^[[01;31mcreate</span><br style="font-size:14px"><span style="font-size:14px">failed^[[00m</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00mTraceback (most recent call last):</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File "/opt/stack/neutron/neutron/</span><span style="font-size:14px">api/v2/resource.py", line</span><br style="font-size:14px"><span style="font-size:14px">78, in resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m result = method(request=request, **args)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File "/opt/stack/neutron/neutron/</span><span style="font-size:14px">api/v2/base.py", line</span><br style="font-size:14px"><span style="font-size:14px">424, in create</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m return self._create(request, body, **kwargs)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File</span><br style="font-size:14px"><span style="font-size:14px">"/usr/local/lib/python2.7/</span><span style="font-size:14px">dist-packages/oslo_db/api.py", line 148, in</span><br style="font-size:14px"><span style="font-size:14px">wrapper</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m ectxt.value = e.inner_exc</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File</span><br style="font-size:14px"><span style="font-size:14px">"/usr/local/lib/python2.7/</span><span style="font-size:14px">dist-packages/oslo_utils/</span><span style="font-size:14px">excutils.py", line 221,</span><br style="font-size:14px"><span style="font-size:14px">in __exit__</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m self.force_reraise()</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File</span><br style="font-size:14px"><span style="font-size:14px">"/usr/local/lib/python2.7/</span><span style="font-size:14px">dist-packages/oslo_utils/</span><span style="font-size:14px">excutils.py", line 197,</span><br style="font-size:14px"><span style="font-size:14px">in force_reraise</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m six.reraise(self.type_, self.value, self.tb)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File</span><br style="font-size:14px"><span style="font-size:14px">"/usr/local/lib/python2.7/</span><span style="font-size:14px">dist-packages/oslo_db/api.py", line 138, in</span><br style="font-size:14px"><span style="font-size:14px">wrapper</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m return f(*args, **kwargs)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File "/opt/stack/neutron/neutron/</span><span style="font-size:14px">api/v2/base.py", line</span><br style="font-size:14px"><span style="font-size:14px">535, in _create</span><br style="font-size:14px"><span style="font-size:14px">[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m return obj_creator(request.context, **kwargs)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File "/opt/stack/tricircle/</span><span style="font-size:14px">tricircle/network/plugin.py",</span><br style="font-size:14px"><span style="font-size:14px">line 238, in create_network</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m is_external =</span><br style="font-size:14px"><span style="font-size:14px">self._ensure_az_set_for_</span><span style="font-size:14px">external_network(net_data)</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m File "/opt/stack/tricircle/</span><span style="font-size:14px">tricircle/network/plugin.py",</span><br style="font-size:14px"><span style="font-size:14px">line 184, in _ensure_az_set_for_external_</span><span style="font-size:14px">network</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m raise t_exceptions.</span><span style="font-size:14px">ExternalNetPodNotSpecify()</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[</span><span style="font-size:14px">00mExternalNetPodNotSpecify: Pod for external network not</span><br style="font-size:14px"><span style="font-size:14px">specified</span><br style="font-size:14px"><span style="font-size:14px">^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource</span><br style="font-size:14px"><span style="font-size:14px">^[[01;35m^[[00m</span><br style="font-size:14px"><span style="font-size:14px">2016-06-29 17:56:04.439 ^[[00;36mINFO neutron.wsgi</span><br style="font-size:14px"><span style="font-size:14px">[^[[01;36mreq-e97f6276-8e19-</span><span style="font-size:14px">408b-829a-004a31256453 ^[[00;36madmin</span><br style="font-size:14px"><span style="font-size:14px">13869ba8005b480bbcbe17b2695fd5</span><span style="font-size:14px">e2^[[00;36m] ^[[01;35m^[[00;36m127.0.0.1 - -</span><br style="font-size:14px"><span style="font-size:14px">[29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368</span><br style="font-size:14px"><span style="font-size:14px">0.147805^[[00m</span><br style="font-size:14px"><br style="font-size:14px"><span style="font-size:14px">Part of the final printed errors on terminal are:</span><br style="font-size:14px"><br style="font-size:14px"><span style="font-size:14px">Request Failed: internal server error while processing your request.</span><br style="font-size:14px"><span style="font-size:14px">Neutron server returns request_ids:</span><br style="font-size:14px"><span style="font-size:14px">['req-e97f6276-8e19-408b-829a-</span><span style="font-size:14px">004a31256453']</span><br style="font-size:14px"><span style="font-size:14px">lib/neutron_plugins/services/</span><span style="font-size:14px">l3:create_neutron_initial_</span><span style="font-size:14px">network:203</span><br style="font-size:14px"><span style="font-size:14px">lib/neutron_plugins/services/</span><span style="font-size:14px">l3:create_neutron_initial_</span><span style="font-size:14px">network:207</span><br style="font-size:14px"><span style="font-size:14px">[ERROR] /home/sword/DevStack/</span><span style="font-size:14px">functions-common:207 Failure creating</span><br style="font-size:14px"><span style="font-size:14px">EXT_NET_ID for public</span><span style="font-size:14px"><br></span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">I run it several times but still failed. I was in China main land but I bought a VPN. So it may not be due to the </span></div><div><span style="font-size:14px">network. @</span><span style="font-size:14px">Fawaz Mohammed,</span><span style="font-size:14px">Also, I conducted your suggestions and failed at last.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">I wish someone could help me with this question.thanks!</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Best,</span></div><div><span style="font-size:14px">Dongfeng</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-04 17:36 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: [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 leave the<br>
> >>>>> finish to the other BP, by this way, I can use updated_at for the<br>
> >>>>> timestamp filter I added and it don't need to change again 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 options we<br>
> >>> talked about in the API meeting were:<br>
> >>><br>
> >>> 1. Setting updated_at = created_at when the instance action record is<br>
> >>> created. Laski likes this, I'm not crazy about it, especially 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 record<br>
> > is an update of that record. So take my comments as applying to Nova<br>
> > overall and not just this issue.<br>
><br>
> Agree. Also it just simplifies a number of things. We should just start<br>
> doing this going forward, and probably put some online data migrations<br>
> in place next cycle to update all the old records. Once updated_at 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 events<br>
> >>> are created. I like this since the instance action is like a parent<br>
> >>> resource and the event is the child, so when we create/modify an event<br>
> >>> we can consider it an update to the parent. Laski thought this might be<br>
> >>> weird UX given we don't expose instance action events in the REST API<br>
> >>> unless you're an admin. This is also probably not something we'd do for<br>
> >>> other related resources like server groups and server group 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 based<br>
> > on events happening which are not visible to the user. However thinking<br>
> > about it further we don't really allow multiple actions at once, except<br>
> > for a few special cases like delete, so this may not end up 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 updated_at<br>
> >>> isn't set for older records, created_at will be used. I think 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 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 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>
> 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>
><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>
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>> 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 against my<br>
> devstack kilo cloud. I followed installation and configuration instructions<br>
> provided at the openstack syntribos repo .Unfortunately, I received some errors<br>
> after running the command : syntribos keystone.config .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: 'tuple' object<br>
> has no attribute 'headers'. ' I have not been successful at discovering what<br>
> could be wrong or how to resolve this issue, even after googling. Does anyone<br>
> have a hint as to how to resolve this issue. Many thanks for your 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. <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>
<<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 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>
> 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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=<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>
> 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 <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>
> 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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>
<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 default:<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: <<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>
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=<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>
<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 <<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>> 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>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<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>
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: <<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>
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>
<<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 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 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>
<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: <<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>
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 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>
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=<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>
<<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 exceptions<br>
> >> for now (so releasenotes and grenade scripts).<br>
> ><br>
> > That is definitely the fall back if there is no better idea. However, 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 examples. Any<br>
corresponding code changes that rely on these new filters will also need 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: <<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>
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=<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 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>
<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: <<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>
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=<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>
> 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>
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: <<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>
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>
<<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 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 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 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 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 the<br>
> recipient. Any dissemination, distribution or copying of the enclosed<br>
> material is prohibited. If you receive this transmission in error, 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>
> 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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 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=<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 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>
> 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>
> 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/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>
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=<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 <<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 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 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 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 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 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 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 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 REST<br>
>> API<br>
>> >>> unless you're an admin. This is also probably not something 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 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 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 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>
>> <<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>
>> 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>
> 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/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>
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. The changes were really minimal. If it creates some problems for us we can 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>> wrote:<br>
><br>
> The crux of this, as Dean stated, is if the library wants OSC to always be pulled in (along with its many dependencies). We've seen folks include it in requirements, test-requirements, or even not at all (just document that OSC needs to be installed).<br>
><br>
> I tossed up the idea with the ironic team of leveraging "extras" field 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 or mistralclient, they would do $ pip install python-ironicclient; if a 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> <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 <<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>>> wrote:<br>
> Regarding osc-lib we have mainly two changes.<br>
><br>
> 1) Used "utils" which is moved from openstackclient.common.utils to 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 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 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 entirely on the plugin team, and that will usually be determined by the answer to the question "Do you want all users of your library to have OSc installed even if they do not use it?" or alternatively "Do you want to 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 OSC-like stand-alone binary for plugins that would theoretically make installing OSC optional for stand-alone client users. This is not complete yet, and as I said above, one reason I wish osc-lib had not been merged into plugin requirements yet. That said, as long as you don't use those bits yet you will be fine, the utils, command, etc bits are stable, it is 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>
> 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/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>
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 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>
> 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>
/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>
<<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 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", 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: <<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>
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 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=<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>
<<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>
There is also an overview presentation<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>
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>
> 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 <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>
> 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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=<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>> 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 some<br>
> > > oslo things and had to step away from them because of some pretty weird<br>
> > > and horrible breakage issues.<br>
> > [...]<br>
> ><br>
> > Or read the associated Oslo spec from when that was done:<br>
> ><br>
> > <URL:<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>
> 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/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>
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>
<<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 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 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 well<br>
> as enabling sorting/pagination for all installations. All those are tracked<br>
> under:<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: <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 getting<br>
> voting for the DVR job. This is something that I plan to tackle in the 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>
> <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>
> 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/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>
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=<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>> 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 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 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 should<br>
> provide images with regards to cinder, using existing SAN gear with 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 the<br>
> system into an operational state. The things listed above are outside 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 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 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 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>
>>>> ><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>
>>>> ><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 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 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 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 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 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>
>>>> >> <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>
>>>> >> 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>
>>>> 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>
>>> 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<br>
>>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>
>>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>
> 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>
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 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>
<<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>
> 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: <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 (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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>
<<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>
<<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>
> 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: <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 (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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 runs<br>
> ssh validation + neutron + config drive + metadata service, which will 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 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>
> <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 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 admin<br>
> sees) is sufficient here. This isn't something that's discoverable from the<br>
> API either, it's really host configuration / capability (something we still<br>
> need to tackle).<br>
<br>
Won't the user provided files also get made available by the config drive /<br>
metadata service ? I think that's the primary reason for file injection not<br>
being a fatal problem. Oh that and the fact that we've wanted to kill it 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- <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- <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- <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- <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 to<br>
> know if there are any plans to support asynchronous HTTP API client in 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: <<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>
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=<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>> 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 <<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>
>> 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>
>>>> 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 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 and #2<br>
>>>> >> > contributor with 28 commits for last 90 days [1][2].<br>
>>>> >> ><br>
>>>> >> > Fuelers, please vote with +1/-1 for approval/objection. Voting<br>
>>>> will<br>
>>>> >> > be open until July of 4th. This will go forward after 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>
>>>> <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>
>>>> >> > 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>
>>>> >> Best regards,<br>
>>>> >> Bogdan Dobrelya,<br>
>>>> >> Irc #bogdando<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>
>>>> 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>
>> 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>
> 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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<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>
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=<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 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: <<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>
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>
</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>