<div dir="ltr">fine, thanks for your help throughout those days. I will conduct as you<div> suggested. Today I can't successfully log onto the lanuchpad. There </div><div>may be something wrong with the server. But I will try again tomorrow </div><div>or later.</div><div><br></div><div>Best Regards,</div><div>Dongfeng</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-06 5:55 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">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">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">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: [magnum][heat] Global stack-list for Magnum service user<br>
(Fox, Kevin M)<br>
2. Quesion about Openstack Magnum (zhihao wang)<br>
3. Re: Quesion about Openstack Magnum (Adrian Otto)<br>
4. Re: New Python35 Jobs coming (Andreas Jaeger)<br>
5. [neutron][taas] IRC Meeting Canceled (week of 7/4/2016) (Anil Rao)<br>
6. [Charm][Congress] Upstreaming JuJu Charm for Openstack<br>
Congress (SULLIVAN, BRYAN L)<br>
7. Re: [Cinder] Nominating Scott D'Angelo to Cinder core<br>
(Walter A. Boring IV)<br>
8. Re: [Openstack-operators] [nova] Fail build request if we<br>
can't inject files? (Matt Riedemann)<br>
9. Re: [Openstack-operators] [nova] Fail build request if we<br>
can't inject files? (Matt Riedemann)<br>
10. Re: OpenStack-dev Digest, Vol 51, Issue 9 (Shinobu Kinjo)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 5 Jul 2016 18:02:43 +0000<br>
From: "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [magnum][heat] Global stack-list for<br>
Magnum service user<br>
Message-ID:<br>
<<a href="mailto:1A3C52DFCD06494D8528644858247BF01B989C6E@EX10MBOX03.pnnl.gov">1A3C52DFCD06494D8528644858247BF01B989C6E@EX10MBOX03.pnnl.gov</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
+1. Id like to see a similar thing for keystone validate user tokens.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________<br>
From: Johannes Grassler<br>
Sent: Monday, July 04, 2016 2:43:47 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [magnum][heat] Global stack-list for Magnum service user<br>
<br>
Hello,<br>
<br>
Magnum has a periodic task that checks the state of the Heat stacks it creates<br>
for its bays. It does this across all users/tenants that have Magnum bays.<br>
Currently it uses a global stack-list operation to query these Heat stacks:<br>
<br>
<a href="https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/blob/master/magnum/service/periodic.py#L83</a><br>
<br>
Now the Magnum service user does not normally have permission to perform this operation,<br>
hence the Magnum documentation currently suggests the following change to<br>
Heat's policy.json:<br>
<br>
| stacks:global_index: "role:admin",<br>
<br>
This is less than optimal since it allows any tenant's admin user to perform a<br>
global stack-list. Would it be an option to have something like this in Heat's<br>
default policy.json?<br>
<br>
| stacks:global_index: "role:service",<br>
<br>
That way the global stack-list would be restricted to service users and seting<br>
Magnum (or other services that use Heat internally) wouldn't need a change to<br>
Heat's policy.json.<br>
<br>
If that kind of approach is feasible I'd be happy to submit a change.<br>
<br>
Cheers,<br>
<br>
Johannes<br>
<br>
--<br>
Johannes Grassler, Cloud Developer<br>
SUSE Linux GmbH, HRB 21284 (AG N?rnberg)<br>
GF: Felix Imend?rffer, Jane Smithard, Graham Norton<br>
Maxfeldstr. 5, 90409 N?rnberg, Germany<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/90780405/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/90780405/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 5 Jul 2016 18:47:29 +0000<br>
From: zhihao wang <<a href="mailto:wangzhihaocom@hotmail.com">wangzhihaocom@hotmail.com</a>><br>
To: "<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>>,<br>
"<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Quesion about Openstack Magnum<br>
Message-ID: <SNT148-W64BABE4E415E25555F8795AC390@phx.gbl><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Dear Magnum team member<br>
<br>
May I ask you some question about Magnum<br>
I have Openstack mistaka (1 controller and 2 compute nodes(I have installed all the components for Magnum, also install the lbaaS V2.<br>
I have install the Magnum followed this guide <a href="http://docs.openstack.org/developer/magnum/install-guide-from-source.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/magnum/install-guide-from-source.html</a><br>
and then I try to use Magnum, but I am not sure how to use it to create k8s<br>
when I try to list the bay model list, it return this, I source admin-openrc, but still the same..<br>
root@controller:/var/lib/magnum/magnum# magnum --version2.0.0root@controller:/var/lib/magnum/magnum# magnum servie-listERROR: You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID]root@controller:/var/lib/magnum/magnum#<br>
also , I saw lots of error from the magnum-api.log<br>
2016-07-05 11:45:47.239 85426 WARNING oslo_reports.guru_meditation_report [-] Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports.2016-07-05 11:45:47.240 85426 INFO magnum.api.app [-] Full WSGI config used: /etc/magnum/api-paste.ini2016-07-05 11:45:47.303 85426 CRITICAL magnum [-] ConfigFileValueError: Value for option host is not valid: controller is not IPv4 or IPv6 address2016-07-05 11:45:47.303 85426 ERROR magnum Traceback (most recent call last):2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/bin/magnum-api", line 10, in <module>2016-07-05 11:45:47.303 85426 ERROR magnum sys.exit(main())2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/magnum/cmd/api.py", line 46, in main2016-07-05 11:45:47.303 85426 ERROR magnum host, port = cfg.CONF.api.host, cfg.CONF.api.port2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3004, in __getattr__2016-07-05 11:45:47.303 85426 ERROR magnum return self._conf._get(name, self._group)2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2615, in _get2016-07-05 11:45:47.303 85426 ERROR magnum value = self._do_get(name, group, namespace)2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2658, in _do_get2016-07-05 11:45:47.303 85426 ERROR magnum % (<a href="http://opt.name" rel="noreferrer" target="_blank">opt.name</a>, str(ve)))2016-07-05 11:45:47.303 85426 ERROR magnum ConfigFileValueError: Value for option host is not valid: controller is not IPv4 or IPv6 address2016-07-05 11:45:47.303 85426 ERROR magnum ^C<br>
I am wondering is there anything for configure the magnum?<br>
thanks so much<br>
wally<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/7ba9a50f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/7ba9a50f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 5 Jul 2016 19:38:40 +0000<br>
From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: "<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Quesion about Openstack Magnum<br>
Message-ID: <<a href="mailto:378870E8-9145-4F6B-A768-E42AEA7CA1E0@rackspace.com">378870E8-9145-4F6B-A768-E42AEA7CA1E0@rackspace.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Wally,<br>
<br>
We can help you by IRC in #openstack-containers on Freenode. I see you?re in there getting help now. This mailing list is for development discussion, so we?ll end this thread, and engage with you on IRC instead.<br>
<br>
Thanks,<br>
<br>
Adrian<br>
<br>
On Jul 5, 2016, at 11:47 AM, zhihao wang <<a href="mailto:wangzhihaocom@hotmail.com">wangzhihaocom@hotmail.com</a><mailto:<a href="mailto:wangzhihaocom@hotmail.com">wangzhihaocom@hotmail.com</a>>> wrote:<br>
<br>
Dear Magnum team member<br>
<br>
May I ask you some question about Magnum<br>
<br>
I have Openstack mistaka (1 controller and 2 compute nodes(<br>
I have installed all the components for Magnum, also install the lbaaS V2.<br>
<br>
I have install the Magnum followed this guide <a href="http://docs.openstack.org/developer/magnum/install-guide-from-source.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/magnum/install-guide-from-source.html</a><br>
<br>
and then I try to use Magnum, but I am not sure how to use it to create k8s<br>
<br>
when I try to list the bay model list, it return this, I source admin-openrc, but still the same..<br>
<br>
root@controller:/var/lib/magnum/magnum# magnum --version<br>
2.0.0<br>
root@controller:/var/lib/magnum/magnum# magnum servie-list<br>
ERROR: You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID]<br>
root@controller:/var/lib/magnum/magnum#<br>
<br>
also , I saw lots of error from the magnum-api.log<br>
<br>
2016-07-05 11:45:47.239 85426 WARNING oslo_reports.guru_meditation_report [-] Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports.<br>
2016-07-05 11:45:47.240 85426 INFO magnum.api.app [-] Full WSGI config used: /etc/magnum/api-paste.ini<br>
2016-07-05 11:45:47.303 85426 CRITICAL magnum [-] ConfigFileValueError: Value for option host is not valid: controller is not IPv4 or IPv6 address<br>
2016-07-05 11:45:47.303 85426 ERROR magnum Traceback (most recent call last):<br>
2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/bin/magnum-api", line 10, in <module><br>
2016-07-05 11:45:47.303 85426 ERROR magnum sys.exit(main())<br>
2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/magnum/cmd/api.py", line 46, in main<br>
2016-07-05 11:45:47.303 85426 ERROR magnum host, port = cfg.CONF.api.host, cfg.CONF.api.port<br>
2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 3004, in __getattr__<br>
2016-07-05 11:45:47.303 85426 ERROR magnum return self._conf._get(name, self._group)<br>
2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2615, in _get<br>
2016-07-05 11:45:47.303 85426 ERROR magnum value = self._do_get(name, group, namespace)<br>
2016-07-05 11:45:47.303 85426 ERROR magnum File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_config/cfg.py", line 2658, in _do_get<br>
2016-07-05 11:45:47.303 85426 ERROR magnum % (<a href="http://opt.name" rel="noreferrer" target="_blank">opt.name</a>, str(ve)))<br>
2016-07-05 11:45:47.303 85426 ERROR magnum ConfigFileValueError: Value for option host is not valid: controller is not IPv4 or IPv6 address<br>
2016-07-05 11:45:47.303 85426 ERROR magnum<br>
^C<br>
<br>
I am wondering is there anything for configure the magnum?<br>
<br>
thanks so much<br>
<br>
wally<br>
________________________________<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4e40e301/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4e40e301/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 5 Jul 2016 21:38:36 +0200<br>
From: Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
Message-ID: <<a href="mailto:577C0CBC.5010506@suse.com">577C0CBC.5010506@suse.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
On 07/05/2016 02:52 PM, Andreas Jaeger wrote:<br>
> [...]<br>
> The change has merged and the python35 non-voting tests are run as part<br>
> of new changes now.<br>
><br>
> The database setup for the python35-db variant is not working yet, and<br>
> needs adjustment on the infra side.<br>
<br>
<br>
The python35-db jobs are working now as well.<br>
<br>
Happy Python35 testing,<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: 5<br>
Date: Tue, 5 Jul 2016 20:09:45 +0000<br>
From: Anil Rao <<a href="mailto:anil.rao@gigamon.com">anil.rao@gigamon.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [neutron][taas] IRC Meeting Canceled (week of<br>
7/4/2016)<br>
Message-ID:<br>
<<a href="mailto:BY2PR1201MB10134409D11B9ABAFDFEF8B789390@BY2PR1201MB1013.namprd12.prod.outlook.com">BY2PR1201MB10134409D11B9ABAFDFEF8B789390@BY2PR1201MB1013.namprd12.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
This week's TaaS IRC meeting is being canceled since some of the team members are planning to attend OpenStack Days in Tokyo. We will reconvene next week as usual.<br>
<br>
Thanks,<br>
Anil<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/2c850dcc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/2c850dcc/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 5 Jul 2016 20:19:53 +0000<br>
From: "SULLIVAN, BRYAN L" <<a href="mailto:bs3131@att.com">bs3131@att.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Charm][Congress] Upstreaming JuJu Charm for<br>
Openstack Congress<br>
Message-ID:<br>
<<a href="mailto:59A39E87EA9F964A836299497B686C354990A7F6@CAFRFD1MSGUSRJD.ITServices.sbc.com">59A39E87EA9F964A836299497B686C354990A7F6@CAFRFD1MSGUSRJD.ITServices.sbc.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
I've been working in the OPNFV (<a href="https://wiki.opnfv.org/" rel="noreferrer" target="_blank">https://wiki.opnfv.org/</a>) on a JuJu Charm to install the OpenStack Congress service on the OPNFV reference platform. This charm should be useful for anyone that wants to install Congress for use with an OpenStack deployment, using the JuJu tool. I want to get the charm upstreamed as an official <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a> git repo similar to the other repos for JuJu Charms for OpenStack services. I participate in the Congress team in OpenStack, who don't know the process for getting this charm upstreamed into an OpenStack repo, so I am reaching out to anyone on this list for help.<br>
<br>
I have been working with gnuoy on #juju and narindergupta on #opnfv-joid on this. The charm has been tested and used to successfully install Congress on the OPNFV Colorado release (Mitaka-based, re OpenStack). While there are some features we need to continue to work on (e.g. Horizon integration), the charm is largely complete and stable. We are currently integrating it into the OPNFV CI/CD system through which it will be regularly/automatically tested in any OPNFV JuJu-based deployment (with this charm, Congress will become a default service deployed in OPNFV thru JuJu).<br>
<br>
Any pointers on how to get started toward creating an OpenStack git repo for this are appreciated.<br>
<br>
Thanks,<br>
Bryan Sullivan | AT&T<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 5 Jul 2016 14:06:53 -0700<br>
From: "Walter A. Boring IV" <<a href="mailto:walter.boring@hpe.com">walter.boring@hpe.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to<br>
Cinder core<br>
Message-ID: <<a href="mailto:577C216D.9060809@hpe.com">577C216D.9060809@hpe.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
This is great! I know I'm a bit late to replying to this on the ML,<br>
due to my vacation,<br>
but I whole heartedly agree!<br>
<br>
+1<br>
<br>
Walt<br>
On 06/27/2016 10:27 AM, Sean McGinnis wrote:<br>
> I would like to nominate Scott D'Angelo to core. Scott has been very<br>
> involved in the project for a long time now and is always ready to help<br>
> folks out on IRC. His contributions [1] have been very valuable and he<br>
> is a thorough reviewer [2].<br>
><br>
> Please let me know if there are any objects to this within the next<br>
> week. If there are none I will switch Scott over by next week, unless<br>
> all cores approve prior to then.<br>
><br>
> Thanks!<br>
><br>
> Sean McGinnis (smcginnis)<br>
><br>
> [1] <a href="https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged</a><br>
> [2] <a href="http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt" rel="noreferrer" target="_blank">http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt</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>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 5 Jul 2016 16:36:50 -0500<br>
From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@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:bb7726ee-7981-83a5-71af-84a891a1558d@linux.vnet.ibm.com">bb7726ee-7981-83a5-71af-84a891a1558d@linux.vnet.ibm.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 7/4/2016 8:45 AM, Matt Riedemann wrote:<br>
> On 7/4/2016 3:40 AM, Daniel P. Berrange wrote:<br>
>><br>
>> Won't the user provided files also get made available by the config<br>
>> drive /<br>
>> metadata service ? I think that's the primary reason for file<br>
>> injection not<br>
>> being a fatal problem. Oh that and the fact that we've wanted to kill<br>
>> it for<br>
>> at least 3 years now :-)<br>
>><br>
>> Regards,<br>
>> Daniel<br>
>><br>
><br>
> Ugh, good point, except force_config_drive defaults to False and running<br>
> the metadata service is optional.<br>
><br>
> In the case of this failing in the tempest-dsvm-neutron-full-ssh job,<br>
> the instance is not created with a config drive, but the metadata<br>
> service is running. Tempest doesn't check for the files there though<br>
> because it's configured to expect file injection to work, so it ssh's<br>
> into the guest and looks for the files.<br>
><br>
> I have several changes up related to this:<br>
><br>
> <a href="https://review.openstack.org/#/q/topic:bug/1598581" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bug/1598581</a><br>
><br>
> One is making Tempest disable file injection tests by default since Nova<br>
> disables file injection by default (at least for the libvirt driver).<br>
><br>
> Another is changing devstack to actually configure nova/tempest for file<br>
> injection which is what the job should have been doing anyway.<br>
><br>
> My nova fix is not going to fly because of config drive (which I could<br>
> check from the virt driver) and the metadata service (which I can't from<br>
> the virt driver). So I guess the best we can do is log something...<br>
><br>
<br>
I think I can still fail the server create from the libvirt driver if we<br>
can't honor the request.<br>
<br>
For config drive, I can just check configdrive.required_by(instance)<br>
like we normally do.<br>
<br>
For the metadata API, it's a bit uglier, but I could check if 'metadata'<br>
is in CONF.enabled_apis and if not, and no config drive and files were<br>
requested for injection but it's disabled, then we fail.<br>
<br>
How terrible is that?<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 5 Jul 2016 16:41:12 -0500<br>
From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@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:e8917a02-e4be-6da8-78fe-4858585f0abc@linux.vnet.ibm.com">e8917a02-e4be-6da8-78fe-4858585f0abc@linux.vnet.ibm.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 7/5/2016 4:36 PM, Matt Riedemann wrote:<br>
> On 7/4/2016 8:45 AM, Matt Riedemann wrote:<br>
>> On 7/4/2016 3:40 AM, Daniel P. Berrange wrote:<br>
>>><br>
>>> Won't the user provided files also get made available by the config<br>
>>> drive /<br>
>>> metadata service ? I think that's the primary reason for file<br>
>>> injection not<br>
>>> being a fatal problem. Oh that and the fact that we've wanted to kill<br>
>>> it for<br>
>>> at least 3 years now :-)<br>
>>><br>
>>> Regards,<br>
>>> Daniel<br>
>>><br>
>><br>
>> Ugh, good point, except force_config_drive defaults to False and running<br>
>> the metadata service is optional.<br>
>><br>
>> In the case of this failing in the tempest-dsvm-neutron-full-ssh job,<br>
>> the instance is not created with a config drive, but the metadata<br>
>> service is running. Tempest doesn't check for the files there though<br>
>> because it's configured to expect file injection to work, so it ssh's<br>
>> into the guest and looks for the files.<br>
>><br>
>> I have several changes up related to this:<br>
>><br>
>> <a href="https://review.openstack.org/#/q/topic:bug/1598581" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bug/1598581</a><br>
>><br>
>> One is making Tempest disable file injection tests by default since Nova<br>
>> disables file injection by default (at least for the libvirt driver).<br>
>><br>
>> Another is changing devstack to actually configure nova/tempest for file<br>
>> injection which is what the job should have been doing anyway.<br>
>><br>
>> My nova fix is not going to fly because of config drive (which I could<br>
>> check from the virt driver) and the metadata service (which I can't from<br>
>> the virt driver). So I guess the best we can do is log something...<br>
>><br>
><br>
> I think I can still fail the server create from the libvirt driver if we<br>
> can't honor the request.<br>
><br>
> For config drive, I can just check configdrive.required_by(instance)<br>
> like we normally do.<br>
><br>
> For the metadata API, it's a bit uglier, but I could check if 'metadata'<br>
> is in CONF.enabled_apis and if not, and no config drive and files were<br>
> requested for injection but it's disabled, then we fail.<br>
<br>
mtreinish pointed out that this would rely on having enabled_apis<br>
configured in nova.conf on the nova-compute nodes, which might not be<br>
the case, and I'm not sure we have a way to tell with oslo.config if an<br>
option is not present vs getting the default value when not specified.<br>
So I probably can't rely on that.<br>
<br>
><br>
> How terrible is that?<br>
><br>
<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 6 Jul 2016 06:55:20 +0900<br>
From: Shinobu Kinjo <<a href="mailto:shinobu.kj@gmail.com">shinobu.kj@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] OpenStack-dev Digest, Vol 51, Issue 9<br>
Message-ID:<br>
<<a href="mailto:CAFdRU70bbDfmGxh5Tvbd5tRyripCjQ-Ty4pqtrwVEAdjzYY5yg@mail.gmail.com">CAFdRU70bbDfmGxh5Tvbd5tRyripCjQ-Ty4pqtrwVEAdjzYY5yg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thank you for your clarification.<br>
<br>
Would you file a bug on this when you get a chance?<br>
<br>
<a href="https://bugs.launchpad.net/tricircle/" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tricircle/</a><br>
<br>
On Tue, Jul 5, 2016 at 8:39 PM, Luck Dog <<a href="mailto:dfhuangg@gmail.com">dfhuangg@gmail.com</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> The problem has been solved now. I add a new line to<br>
><br>
> the file local.conf. The content of the added line is<br>
><br>
> ?NEUTRON_CREATE_INITIAL_NETWORKS=False?, By adding this line<br>
><br>
> Devstack won?t create default network, and it will use the configuration<br>
><br>
> set manually. Without this line, Devstack will create initial network<br>
><br>
> elements including external network. However, This external network<br>
><br>
> is not supported by single node. If it runs on a single node then<br>
><br>
> some errors will turn up. It is exactly the error I met.<br>
><br>
><br>
> @ Shinobu, The attachment is the old local.conf. it is from the official<br>
><br>
> net page, and the URL is<br>
> <a href="https://github.com/openstack/tricircle/blob/master/devstack/local.conf.sample" rel="noreferrer" target="_blank">https://github.com/openstack/tricircle/blob/master/devstack/local.conf.sample</a><br>
><br>
> thanks for your kindness!<br>
><br>
> 2016-07-05 14:58 GMT+08:00 <<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a>>:<br>
><br>
>> Send OpenStack-dev mailing list submissions to<br>
>> <a href="mailto:openstack-dev@lists.openstack.org">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">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">openstack-dev-owner@lists.openstack.org</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of OpenStack-dev digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: [kuryr] kuryr-libnetwork split (Vikas Choudhary)<br>
>> 2. Re: [mistral] [murano] [yaql] yaqluator bug (Renat Akhmerov)<br>
>> 3. Re: [mistral] [murano] [yaql] yaqluator bug (Stan Lagun)<br>
>> 4. Re: [nova] Non-priority feature freeze and FFEs (Claudiu Belu)<br>
>> 5. Re: OpenStack-dev Digest, Vol 51, Issue 6 (Shinobu Kinjo)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Tue, 5 Jul 2016 10:11:04 +0530<br>
>> From: Vikas Choudhary <<a href="mailto:choudharyvikas16@gmail.com">choudharyvikas16@gmail.com</a>><br>
>> To: Antoni Segura Puimedon <<a href="mailto:toni%2Bopenstackml@midokura.com">toni+openstackml@midokura.com</a>><br>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Irena Berezovsky<br>
>> <<a href="mailto:irena@midokura.com">irena@midokura.com</a>><br>
>> Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:CABJxuZrVDTaTHHBxs4RNuLq30n04KBbhuk7gKEdWXDCC8ggvxA@mail.gmail.com">CABJxuZrVDTaTHHBxs4RNuLq30n04KBbhuk7gKEdWXDCC8ggvxA@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hello Everybody !!!<br>
>><br>
>> As we discussed in the meeting yesterday, I have submitted restructured<br>
>> patches now in kuryr-lib and kuryr-libnetwork to address only dropping<br>
>> non-relevant code and adding kuryr-lib as dependency to kuryr-libnetwork.<br>
>><br>
>> Please provide review comments so that i quickly reiterate over patches<br>
>> and<br>
>> eventually we will be able to move our existing under review patches also<br>
>> from kuryr to kuryr-libnetwork.<br>
>><br>
>> Since RPC support is also ready, will be submitting the same in both repos<br>
>> as seperate patches(linked with dependency)<br>
>><br>
>> Here is the link for base patchsets:<br>
>> Kuryr-libnetwork: <a href="https://review.openstack.org/#/c/337350/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/337350/</a><br>
>> kuryr-lib: <a href="https://review.openstack.org/#/c/336784/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336784/</a><br>
>><br>
>><br>
>><br>
>> Regards<br>
>> Vikas<br>
>><br>
>> On Fri, Jul 1, 2016 at 6:40 PM, Antoni Segura Puimedon <<br>
>> <a href="mailto:toni%2Bopenstackml@midokura.com">toni+openstackml@midokura.com</a>> wrote:<br>
>><br>
>> > Hi fellow kuryrs!<br>
>> ><br>
>> > In order to proceed with the split of kuryr into a main lib and it's<br>
>> kuryr<br>
>> > libnetwork component, we've cloned the contents of openstack/kuryr over<br>
>> to<br>
>> > openstack/kuryr-libnetwork.<br>
>> ><br>
>> > The idea is that after this, the patches that will go to openstack/kuryr<br>
>> > will be to trim out the kuryr/kuryr-libnetwork specific parts and make a<br>
>> > release of the common parts so that openstack/kuryr-libnetwork can start<br>
>> > using it.<br>
>> ><br>
>> > I propose that we use python namespaces and the current common code in<br>
>> > kuryr is moved to:<br>
>> > kuryr/lib/<br>
>> ><br>
>> ><br>
>> > which openstack/kuryr-libnetwork would import like so:<br>
>> ><br>
>> > from kuryr.lib import binding<br>
>> ><br>
>> > So, right now, patches in review that are for the Docker ipam or remote<br>
>> > driver, should be moved to openstack/kuryr-libnetwork and soon we should<br>
>> > make openstack/kuryr-libnetwork add kuryr-lib to the requirements.<br>
>> ><br>
>> > Regards,<br>
>> ><br>
>> > Toni<br>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/0d032a4c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/0d032a4c/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Tue, 5 Jul 2016 12:07:25 +0700<br>
>> From: Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com">renat.akhmerov@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
>> Message-ID: <<a href="mailto:E9ADF691-7387-47EB-86F5-2A3EEFCF3291@gmail.com">E9ADF691-7387-47EB-86F5-2A3EEFCF3291@gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> If I understand the meaning of ?join? function correctly then from user<br>
>> perspective this behavior in Mistral and Yaqluator is a bug because we?re<br>
>> joining two collections similar to how it works in SQL so the correct<br>
>> result should be:<br>
>><br>
>> [[1, 3], [2, 3]]<br>
>><br>
>> I.e. collection consisting of two collections where each element if the<br>
>> first one is combined with each element of the second one.<br>
>><br>
>> If so, we need to fix this in both Mistral and Yaqluator.<br>
>><br>
>><br>
>> Alex, Stan, do you agree?<br>
>><br>
>> Renat Akhmerov<br>
>> @Nokia<br>
>><br>
>> > On 28 Jun 2016, at 23:46, Elisha, Moshe (Nokia - IL) <<br>
>> <a href="mailto:moshe.elisha@nokia.com">moshe.elisha@nokia.com</a>> wrote:<br>
>> ><br>
>> > Hi,<br>
>> ><br>
>> > Thank you for the kind words, Alexey.<br>
>> ><br>
>> > I was able to reproduce your bug and I have also found the issue.<br>
>> ><br>
>> > The problem is that we did not create the parser with the<br>
>> engine_options used in the yaql library by default when using the CLI.<br>
>> > Specifically, the "yaql.limitIterators" was missing? I am not sure that<br>
>> this settings should have this affect but maybe the Yaql guys can comment<br>
>> on that.<br>
>> ><br>
>> > If we will change yaqluator to use this setting it will mean that<br>
>> yaqluator will not be consistent with Mistral because Mistral is using YAQL<br>
>> without this engine option (If I use your example in a workflow, Mistral<br>
>> returns exactly like the yaqluator returns)<br>
>> ><br>
>> ><br>
>> > Workflow:<br>
>> ><br>
>> >> ---<br>
>> >> version: '2.0'<br>
>> >><br>
>> >> test_yaql:<br>
>> >> tasks:<br>
>> >> test_yaql:<br>
>> >> action: std.noop<br>
>> >> publish:<br>
>> >> output_expr: <% [1,2].join([3], true, [$1, $2]) %><br>
>> ><br>
>> > Workflow result:<br>
>> ><br>
>> ><br>
>> > [root@s53-19 ~(keystone_admin)]# mistral task-get-published<br>
>> 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7<br>
>> > {<br>
>> > "output_expr": [<br>
>> > [<br>
>> > 1,<br>
>> > 3<br>
>> > ]<br>
>> > ]<br>
>> > }<br>
>> ><br>
>> ><br>
>> > As Matthews pointed out, the yaqluator is indeed OpenSource and<br>
>> contributions are welcomed.<br>
>> ><br>
>> > [1]<br>
>> <a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a><br>
>> <<br>
>> <a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > From: Dougal Matthews <<a href="mailto:dougal@redhat.com">dougal@redhat.com</a> <mailto:<a href="mailto:dougal@redhat.com">dougal@redhat.com</a>>><br>
>> > Reply-To: "OpenStack Development Mailing List (not for usage<br>
>> questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a> <mailto:<br>
>> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
>> > Date: Monday, 27 June 2016 at 16:44<br>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <<br>
>> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a> <mailto:<br>
>> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
>> > Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
>> ><br>
>> > On 27 June 2016 at 14:30, Alexey Khivin <<a href="mailto:akhivin@gmail.com">akhivin@gmail.com</a> <mailto:<br>
>> <a href="mailto:akhivin@gmail.com">akhivin@gmail.com</a>>> wrote:<br>
>> >> Hello, Moshe<br>
>> >><br>
>> >> Tomorrow I discovered <a href="http://yaqluator.com" rel="noreferrer" target="_blank">yaqluator.com</a> <<a href="http://yaqluator.com/" rel="noreferrer" target="_blank">http://yaqluator.com/</a>> for<br>
>> myself! Thanks for the useful tool!<br>
>> >><br>
>> >> But suddenly I was said that the expression<br>
>> >> [1,2].join([3], true, [$1, $2])<br>
>> >> evaluated to [[1,3]] on the yaqluator<br>
>> >><br>
>> >> A the same time this expression evaluated right when I using raw yaql<br>
>> interpreter.<br>
>> >><br>
>> >> Could we fix this issue?<br>
>> >><br>
>> >> By the way, don't you want to make yaqluator opensource? If you would<br>
>> transfer yaqluator to Openstack Foundation, then community will be able to<br>
>> fix such kind of bugs<br>
>> ><br>
>> > It looks like it is open source, there is a link in the footer:<br>
>> <a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a> <<br>
>> <a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a>><br>
>> ><br>
>> >><br>
>> >> Thank you!<br>
>> >> Best regards, Alexey Khivin<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> <<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a> <<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>> >><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4977ab22/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4977ab22/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Mon, 4 Jul 2016 22:12:55 -0700<br>
>> From: Stan Lagun <<a href="mailto:slagun@mirantis.com">slagun@mirantis.com</a>><br>
>> To: "Elisha, Moshe (Nokia - IL)" <<a href="mailto:moshe.elisha@nokia.com">moshe.elisha@nokia.com</a>><br>
>> Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
>> Message-ID:<br>
>> <CAOCoZia=zLQqn54mwjk2me0H2KXfeqa-J6=<br>
>> <a href="mailto:x3iAKz%2BsxO%2Bk3Pg@mail.gmail.com">x3iAKz+sxO+k3Pg@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Hi!<br>
>><br>
>> The issue with join is just a yaql bug that is already fixed. The problem<br>
>> with yaqluator is that it doesn't use the latest yaql library.<br>
>><br>
>> Another problem is that it does't sets options correctly. As a result it<br>
>> is<br>
>> possible to bring the site down with a query that produces endless<br>
>> collection<br>
>><br>
>> Sincerely yours,<br>
>> Stan Lagun<br>
>> Principal Software Engineer @ Mirantis<br>
>><br>
>> <<a href="mailto:slagun@mirantis.com">slagun@mirantis.com</a>><br>
>><br>
>> On Tue, Jun 28, 2016 at 9:46 AM, Elisha, Moshe (Nokia - IL) <<br>
>> <a href="mailto:moshe.elisha@nokia.com">moshe.elisha@nokia.com</a>> wrote:<br>
>><br>
>> > Hi,<br>
>> ><br>
>> > Thank you for the kind words, Alexey.<br>
>> ><br>
>> > I was able to reproduce your bug and I have also found the issue.<br>
>> ><br>
>> > The problem is that we did not create the parser with the engine_options<br>
>> > used in the yaql library by default when using the CLI.<br>
>> > Specifically, the "yaql.limitIterators" was missing? I am not sure that<br>
>> > this settings should have this affect but maybe the Yaql guys can<br>
>> comment<br>
>> > on that.<br>
>> ><br>
>> > If we will change yaqluator to use this setting it will mean that<br>
>> > yaqluator will not be consistent with Mistral because Mistral is using<br>
>> YAQL<br>
>> > without this engine option (If I use your example in a workflow, Mistral<br>
>> > returns exactly like the yaqluator returns)<br>
>> ><br>
>> ><br>
>> > Workflow:<br>
>> ><br>
>> > ---<br>
>> > version: '2.0'<br>
>> ><br>
>> > test_yaql:<br>
>> > tasks:<br>
>> > test_yaql:<br>
>> > action: std.noop<br>
>> > publish:<br>
>> > output_expr: <% [1,2].join([3], true, [$1, $2]) %><br>
>> ><br>
>> ><br>
>> > Workflow result:<br>
>> ><br>
>> ><br>
>> > [root@s53-19 ~(keystone_admin)]# mistral task-get-published<br>
>> > 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7<br>
>> > {<br>
>> > "output_expr": [<br>
>> > [<br>
>> > 1,<br>
>> > 3<br>
>> > ]<br>
>> > ]<br>
>> > }<br>
>> ><br>
>> ><br>
>> > As Matthews pointed out, the yaqluator is indeed OpenSource and<br>
>> > contributions are welcomed.<br>
>> ><br>
>> > [1]<br>
>> ><br>
>> <a href="https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > From: Dougal Matthews <<a href="mailto:dougal@redhat.com">dougal@redhat.com</a>><br>
>> > Reply-To: "OpenStack Development Mailing List (not for usage<br>
>> questions)" <<br>
>> > <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> > Date: Monday, 27 June 2016 at 16:44<br>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <<br>
>> > <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> > Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug<br>
>> ><br>
>> > On 27 June 2016 at 14:30, Alexey Khivin <<a href="mailto:akhivin@gmail.com">akhivin@gmail.com</a>> wrote:<br>
>> ><br>
>> >> Hello, Moshe<br>
>> >><br>
>> >> Tomorrow I discovered <a href="http://yaqluator.com" rel="noreferrer" target="_blank">yaqluator.com</a> for myself! Thanks for the useful<br>
>> >> tool!<br>
>> >><br>
>> >> But suddenly I was said that the expression<br>
>> >> [1,2].join([3], true, [$1, $2])<br>
>> >> evaluated to [[1,3]] on the yaqluator<br>
>> >><br>
>> >> A the same time this expression evaluated right when I using raw yaql<br>
>> >> interpreter.<br>
>> >><br>
>> >> Could we fix this issue?<br>
>> >><br>
>> >> By the way, don't you want to make yaqluator opensource? If you would<br>
>> >> transfer yaqluator to Openstack Foundation, then community will be<br>
>> able to<br>
>> >> fix such kind of bugs<br>
>> >><br>
>> ><br>
>> > It looks like it is open source, there is a link in the footer:<br>
>> > <a href="https://github.com/ALU-CloudBand/yaqluator" rel="noreferrer" target="_blank">https://github.com/ALU-CloudBand/yaqluator</a><br>
>> ><br>
>> ><br>
>> >><br>
>> >> Thank you!<br>
>> >> Best regards, Alexey Khivin<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/fe707c06/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/fe707c06/attachment-0001.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 4<br>
>> Date: Tue, 5 Jul 2016 06:26:38 +0000<br>
>> From: Claudiu Belu <<a href="mailto:cbelu@cloudbasesolutions.com">cbelu@cloudbasesolutions.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and<br>
>> FFEs<br>
>> Message-ID:<br>
>> <FBEE3301F14DA946B921457EF854C37742E82761@CBSEX1.cloudbase.local><br>
>> Content-Type: text/plain; charset="us-ascii"<br>
>><br>
>> Hi,<br>
>><br>
>> The Hyper-V implementation of the bp virt-device-role-tagging is<br>
>> mergeable [1]. The patch is quite simple, it got some reviews, and the<br>
>> tempest test test_device_tagging [2] passed. [3]<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/331889/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/331889/</a><br>
>> [2] <a href="https://review.openstack.org/#/c/305120/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/305120/</a><br>
>> [3]<br>
>> <a href="http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz" rel="noreferrer" target="_blank">http://64.119.130.115/debug/nova/331889/8/04-07-2016_19-43/results.html.gz</a><br>
>><br>
>> Best regards,<br>
>><br>
>> Claudiu Belu<br>
>><br>
>> ________________________________________<br>
>> From: Markus Zoeller [<a href="mailto:mzoeller@linux.vnet.ibm.com">mzoeller@linux.vnet.ibm.com</a>]<br>
>> Sent: Monday, July 04, 2016 2:24 PM<br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> Subject: Re: [openstack-dev] [nova] Non-priority feature freeze and FFEs<br>
>><br>
>> On 01.07.2016 23:03, Matt Riedemann wrote:<br>
>> > We're now past non-priority feature freeze. I've started going through<br>
>> > some blueprints and -2ing them if they still have outstanding changes. I<br>
>> > haven't gone through the full list yet (we started with 100).<br>
>> ><br>
>> > I'm also building a list of potential FFE candidates based on:<br>
>> ><br>
>> > 1. How far along the change is (how ready is it?), e.g. does it require<br>
>> > a lot of change yet? Does it require a Tempest test and is that passing<br>
>> > already? How much of the series has already merged and what's left?<br>
>> ><br>
>> > 2. How much core reviewer attention has it already gotten?<br>
>> ><br>
>> > 3. What kind of priority does it have, i.e. if we don't get it done in<br>
>> > Newton do we miss something in Ocata? Think things that start<br>
>> > deprecation/removal timers.<br>
>> ><br>
>> > The plan is for the nova core team to have an informal meeting in the<br>
>> > #openstack-nova IRC channel early next week, either Tuesday or<br>
>> > Wednesday, and go through the list of potential FFE candidates.<br>
>> ><br>
>> > Blueprints that get exceptions will be checked against the above<br>
>> > criteria and who on the core team is actually going to push the changes<br>
>> > through.<br>
>> ><br>
>> > I'm looking to get any exceptions completed within a week, so targeting<br>
>> > Wednesday 7/13. That leaves a few days for preparing for the meetup.<br>
>> ><br>
>><br>
>> FWIW, bp "libvirt-virtlogd" [1] is basically ready to merge. The two<br>
>> changes [2] and [3] did already get a lot of attention from danpb.<br>
>><br>
>> References:<br>
>> [1]<br>
>> <a href="https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/openstack/?searchtext=libvirt-virtlogd</a><br>
>> [2] <a href="https://review.openstack.org/#/c/334480/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334480/</a><br>
>> [3] <a href="https://review.openstack.org/#/c/323765/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/323765/</a><br>
>><br>
>> --<br>
>> Regards, Markus Zoeller (markus_z)<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<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>
>> Message: 5<br>
>> Date: Tue, 5 Jul 2016 15:58:24 +0900<br>
>> From: Shinobu Kinjo <<a href="mailto:shinobu.kj@gmail.com">shinobu.kj@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] OpenStack-dev Digest, Vol 51, Issue 6<br>
>> Message-ID:<br>
>> <CAFdRU713mdpLDwbdD=xaRMkOPO=<br>
>> <a href="mailto:UVFF0YQY9x_Ef2dqZmXEp6A@mail.gmail.com">UVFF0YQY9x_Ef2dqZmXEp6A@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Would you attach local.conf you're using?<br>
>><br>
>><br>
>> On Tue, Jul 5, 2016 at 11:51 AM, Luck Dog <<a href="mailto:dfhuangg@gmail.com">dfhuangg@gmail.com</a>> wrote:<br>
>><br>
>> > Hello everyone,<br>
>> > I am running the devstack with patch Tricircle,according to steps<br>
>> > given by official net page,<br>
>> > <a href="https://github.com/openstack/tricircle#play-with-devstack.But" rel="noreferrer" target="_blank">https://github.com/openstack/tricircle#play-with-devstack.But</a> it<br>
>> always<br>
>> > failed at the same place.The errors are listed as follows.(according<br>
>> to<br>
>> > the stack.sh.logs)<br>
>> ><br>
>> > Request body: {u'network': {u'router:external': True,<br>
>> > u'provider:network_type': u'flat', u'name': u'public',<br>
>> > u'provider:physical_network': u'public', u'admin_state_up': True}}^[[00m<br>
>> > ^[[00;33mfrom (pid=29980) prepare_request_body<br>
>> > /opt/stack/neutron/neutron/api/v2/base.py:674^[[00m<br>
>> > 2016-06-29 17:56:04.359 ^[[00;32mDEBUG neutron.db.quota.driver<br>
>> > [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> > 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mResources<br>
>> > subnetpool have unlimited quota limit. It is not required to calculate<br>
>> > headroom ^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
>> > /opt/stack/neutron/neutron/db/quota/driver.py:191^[[00m<br>
>> > 2016-06-29 17:56:04.381 ^[[00;32mDEBUG neutron.db.quota.driver<br>
>> > [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> > 13869ba8005b480bbcbe17b2695fd5e2^[[00;32m] ^[[01;35m^[[00;32mAttempting<br>
>> to<br>
>> > reserve 1 items for resource network. Total usage: 0; quota limit: 10;<br>
>> > headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
>> > /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m<br>
>> > 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource<br>
>> > [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> > 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate<br>
>> > failed^[[00m<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00mTraceback (most recent call last):<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/resource.py",<br>
>> > line<br>
>> > 78, in resource<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m result = method(request=request, **args)<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
>> > 424, in create<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m return self._create(request, body, **kwargs)<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m File<br>
>> > "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in<br>
>> > wrapper<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m ectxt.value = e.inner_exc<br>
>> > ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> > ^[[01;35m^[[00m File<br>
>> > "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line<br>
>> 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<br>
>> 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<br>
>> "/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<br>
>> "/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>
>> - -<br>
>> > [29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368<br>
>> > 0.147805^[[00m<br>
>> ><br>
>> > Part of the final printed errors on terminal are:<br>
>> ><br>
>> > Request Failed: internal server error while processing your request.<br>
>> > Neutron server returns request_ids:<br>
>> > ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
>> > lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
>> > lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
>> > [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
>> > EXT_NET_ID for public<br>
>> ><br>
>> > I run it several times but still failed. I was in China main land but<br>
>> I<br>
>> > bought a VPN. So it may not be due to the<br>
>> > network. @Fawaz Mohammed,Also, I conducted your suggestions and failed<br>
>> at<br>
>> > last.<br>
>> ><br>
>> > I wish someone could help me with this question.thanks!<br>
>> ><br>
>> > Best,<br>
>> > Dongfeng<br>
>> ><br>
>> > 2016-07-04 17:36 GMT+08:00 <<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a>>:<br>
>> ><br>
>> >> Send OpenStack-dev mailing list submissions to<br>
>> >> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> >><br>
>> >> To subscribe or unsubscribe via the World Wide Web, visit<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>
>> >> or, via email, send a message with subject or body 'help' to<br>
>> >> <a href="mailto:openstack-dev-request@lists.openstack.org">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">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<br>
>> 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">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">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">mriedem@linux.vnet.ibm.com</a>><br>
>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">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">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">sean@dague.net</a><br>
>> >> > <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>>:<br>
>> >> ><br>
>> >> > On 06/30/2016 08:31 AM, Andrew Laski wrote:<br>
>> >> > ><br>
>> >> > ><br>
>> >> > > On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:<br>
>> >> > >> On 6/29/2016 10:10 PM, Matt Riedemann wrote:<br>
>> >> > >>> On 6/29/2016 6:40 AM, Andrew Laski wrote:<br>
>> >> > >>>><br>
>> >> > >>>><br>
>> >> > >>>><br>
>> >> > >>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:<br>
>> >> > >>>>> How about I sync updated_at and created_at in my patch, and<br>
>> >> leave the<br>
>> >> > >>>>> finish to the other BP, by this way, I can use updated_at<br>
>> for<br>
>> >> the<br>
>> >> > >>>>> timestamp filter I added and it don't need to change again<br>
>> >> once the<br>
>> >> > >>>>> finish BP is complete.<br>
>> >> > >>>><br>
>> >> > >>>> Sounds good to me.<br>
>> >> > >>>><br>
>> >> > >>><br>
>> >> > >>> It's been a long day so my memory might be fried, but the<br>
>> >> options we<br>
>> >> > >>> talked about in the API meeting were:<br>
>> >> > >>><br>
>> >> > >>> 1. Setting updated_at = created_at when the instance action<br>
>> >> record is<br>
>> >> > >>> created. Laski likes this, I'm not crazy about it, especially<br>
>> >> since we<br>
>> >> > >>> don't do that for anything else.<br>
>> >> > ><br>
>> >> > > I would actually like for us to do this generally. I have the<br>
>> same<br>
>> >> > > thinking as Ed does elsewhere in this thread, the creation of a<br>
>> >> record<br>
>> >> > > is an update of that record. So take my comments as applying to<br>
>> >> Nova<br>
>> >> > > overall and not just this issue.<br>
>> >> ><br>
>> >> > Agree. Also it just simplifies a number of things. We should just<br>
>> >> start<br>
>> >> > doing this going forward, and probably put some online data<br>
>> >> migrations<br>
>> >> > in place next cycle to update all the old records. Once<br>
>> 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<br>
>> 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<br>
>> (created_at<br>
>> >> wouldn't change, but updated_at could).<br>
>> >><br>
>> >> ><br>
>> >> > Anyway, we already freeze... probably we can begin to fix the<br>
>> updated_at<br>
>> >> > problem first.<br>
>> >> ><br>
>> >> ><br>
>> >> > >>> 2. Update the instance action's updated_at when instance<br>
>> action<br>
>> >> events<br>
>> >> > >>> are created. I like this since the instance action is like a<br>
>> >> parent<br>
>> >> > >>> resource and the event is the child, so when we create/modify<br>
>> >> an event<br>
>> >> > >>> we can consider it an update to the parent. Laski thought<br>
>> this<br>
>> >> might be<br>
>> >> > >>> weird UX given we don't expose instance action events in the<br>
>> >> REST API<br>
>> >> > >>> unless you're an admin. This is also probably not something<br>
>> >> we'd do for<br>
>> >> > >>> other related resources like server groups and server group<br>
>> >> members (but<br>
>> >> > >>> we don't page on those either right now).<br>
>> >> > ><br>
>> >> > > Right. My concern is just that the ordering of actions can<br>
>> 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<br>
>> 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<br>
>> fine<br>
>> >> > > solution for the issue at hand. I just think #1 is a more<br>
>> general<br>
>> >> > > solution.<br>
>> >> > ><br>
>> >> > >>><br>
>> >> > >>> 3. Order the results by updated_at,created_at so that if<br>
>> >> updated_at<br>
>> >> > >>> isn't set for older records, created_at will be used. I think<br>
>> >> we all<br>
>> >> > >>> agreed in the meeting to do this regardless of #1 or #2<br>
>> above.<br>
>> >> ><br>
>> >> > I kind of hate that as the order, because then the marker is<br>
>> going<br>
>> >> to<br>
>> >> > have to be really funny double timestamp, right?<br>
>> >> ><br>
>> >> ><br>
>> >> > The marker only needs to fill with the unique value. There isn't any<br>
>> >> > problem order with multiple column. Some time we need order with<br>
>> >> > mulitple column for stable order when the first order column is<br>
>> >> > without UniqueConstraint.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > I guess that's the one thing I don't see in this patch is a<br>
>> >> functional<br>
>> >> > test that actually loads up instance actions and iterates through<br>
>> >> > demonstrating the pagination.<br>
>> >> ><br>
>> >> > -Sean<br>
>> >> ><br>
>> >> > --<br>
>> >> > Sean Dague<br>
>> >> > <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
>> >> ><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >><br>
>> >> Thanks,<br>
>> >><br>
>> >> Matt Riedemann<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 2<br>
>> >> Date: Sun, 3 Jul 2016 08:19:55 -0500<br>
>> >> From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>
>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">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">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">mriedem@linux.vnet.ibm.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> > The manila periodic stable/liberty jobs have been failing for at<br>
>> 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<br>
>> pulling<br>
>> >> > in uncapped oslo.utils even though the upper constraint for<br>
>> oslo.utils<br>
>> >> > in liberty is 3.2.<br>
>> >> ><br>
>> >> > Who from the manila team is going to be working on fixing this,<br>
>> either<br>
>> >> > via getting upper-constraints in place in the tox.ini for manila (on<br>
>> all<br>
>> >> > supported branches) or performing some kind of workaround in the<br>
>> 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<br>
>> 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">dstanek@dstanek.com</a>><br>
>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">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">run2obtain@gmail.com</a>><br>
>> >> ><br>
>> >> ><br>
>> >> > Hi... I tried to use OpenStack Syntribos today for security testing<br>
>> >> against my<br>
>> >> > devstack kilo cloud. I followed installation and configuration<br>
>> >> instructions<br>
>> >> > provided at the openstack syntribos repo .Unfortunately, I received<br>
>> >> some errors<br>
>> >> > after running the command : syntribos keystone.config<br>
>> >> .opencafe/templates/<br>
>> >> > keystone/roles_get.txt . The errors are File<br>
>> "/usr/local/lib/python2.7/<br>
>> >> > dist-packages/syntribos/extensions/identity/client.py", line 146, in<br>
>> >> > get_token_v3 return r.headers["X-Subject-Token"] AttributeError:<br>
>> >> 'tuple' object<br>
>> >> > has no attribute 'headers'. ' I have not been successful at<br>
>> discovering<br>
>> >> what<br>
>> >> > could be wrong or how to resolve this issue, even after googling.<br>
>> Does<br>
>> >> anyone<br>
>> >> > have a hint as to how to resolve this issue. Many thanks for your<br>
>> >> anticipated<br>
>> >> > response.<br>
>> >> ><br>
>> >><br>
>> >> A quick look at the code[1] show that the HTTP client used by the<br>
>> 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<br>
>> disappointed<br>
>> >> to not find any docs for it.<br>
>> >><br>
>> >> 1.<br>
>> >><br>
>> <a href="https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143" rel="noreferrer" target="_blank">https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_client.py#L143</a><br>
>> >><br>
>> >> --<br>
>> >> David Stanek<br>
>> >> web: <a href="http://dstanek.com" rel="noreferrer" target="_blank">http://dstanek.com</a><br>
>> >> blog: <a href="http://traceback.org" rel="noreferrer" target="_blank">http://traceback.org</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 4<br>
>> >> Date: Sun, 3 Jul 2016 17:59:25 +0400<br>
>> >> From: Fawaz Mohammed <<a href="mailto:fawaz.moh.ibraheem@gmail.com">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">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [tricircle] Error when running Devstack<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CA%2BNahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5%2BLEsyTMvNsh3g-A@mail.gmail.com">CA+NahOWJZ_mrZz7G7X-M0Nfwxvwf0G0yLS5+LEsyTMvNsh3g-A@mail.gmail.com</a>><br>
>> >> Content-Type: text/plain; charset="utf-8"<br>
>> >><br>
>> >> Hi Dongfeng,<br>
>> >><br>
>> >> I've noted in the title [Tricircle], but in your body mail, nothing<br>
>> >> related<br>
>> >> to Tricircle!<br>
>> >><br>
>> >> It's not recommended to use the sample configuration file as it's, make<br>
>> >> sure that you edit it as per your preferred configuration.<br>
>> >><br>
>> >> Also, note that it's good to run stack.sh as stack user, you can create<br>
>> >> stack user by running:<br>
>> >> $sudo /devstack/tools/create-stack-user.sh<br>
>> >> Then, move the devstack folder to stack home user, or clone it again:<br>
>> >> stack@Host$cd ~<br>
>> >> stack@host$git clone <a href="https://git.openstack.org/openstack-dev/devstack" rel="noreferrer" target="_blank">https://git.openstack.org/openstack-dev/devstack</a><br>
>> >> Edit your local.conf configuration file, then run stack.sh script.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Sun, Jul 3, 2016 at 3:41 PM, Luck Dog <<a href="mailto:dfhuangg@gmail.com">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.<br>
>> 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<br>
>> to<br>
>> >> > local.conf.<br>
>> >> > The errors are as follows?<br>
>> >> > Request Failed: internal server error while processing your request.<br>
>> >> > Neutron server returns request_ids:<br>
>> >> > ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
>> >> > lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
>> >> > lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
>> >> > [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
>> >> > EXT_NET_ID for public<br>
>> >> ><br>
>> >> > I don't know whether it is my wrong configuration of computer or the<br>
>> >> > server error, I wish someone can help me with the problem. thanks!<br>
>> >> ><br>
>> >> > Best regards,<br>
>> >> > Dongfeng<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/8584112c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/8584112c/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 5<br>
>> >> Date: Sun, 3 Jul 2016 18:10:02 +0400<br>
>> >> From: Fawaz Mohammed <<a href="mailto:fawaz.moh.ibraheem@gmail.com">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">openstack-dev@lists.openstack.org</a>><br>
>> >> Cc: "<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question<br>
>> >> Message-ID:<br>
>> >> <CA+NahOUMgiNoKAnzrZKrOgo=Eigrpv8VHaSZzPxwC=<br>
>> >> <a href="mailto:WLtQCnEQ@mail.gmail.com">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">wangzhihaocom@hotmail.com</a><br>
>> ><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<br>
>> 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>
>> >> ><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>
>> >> ><br>
>> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2<br>
>> >> ><br>
>> >> > [service_providers]<br>
>> >> > service_provider =<br>
>> >> ><br>
>> >><br>
>> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default<br>
>> >> ><br>
>> >> > /etc/openstack-dashboard/local_settings.py<br>
>> >> ><br>
>> >> ><br>
>> >> > OPENSTACK_NEUTRON_NETWORK = {<br>
>> >> > 'enable_lb': True<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> > And then I restart all the neutron service and apache server<br>
>> >> > service neutron-server restart<br>
>> >> > service neutron-dhcp-agent restart<br>
>> >> > service neutron-metadata-agent restart<br>
>> >> > service neutron-l3-agent restart<br>
>> >> ><br>
>> >> > but and then i ran the command neutron agent-list, it return this. I<br>
>> am<br>
>> >> > wondering what is wrong with this? how can I install Neutron LaaS?<br>
>> >> ><br>
>> >> > root@controller:~# neutron agent-list<br>
>> >> > Unable to establish connection to<br>
>> >> <a href="http://controller:9696/v2.0/agents.json" rel="noreferrer" target="_blank">http://controller:9696/v2.0/agents.json</a><br>
>> >> ><br>
>> >> ><br>
>> >> > Please help<br>
>> >> ><br>
>> >> > Thanks so much<br>
>> >> ><br>
>> >> > Thanks<br>
>> >> > Wally<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/c3bd39ba/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/c3bd39ba/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 6<br>
>> >> Date: Sun, 3 Jul 2016 10:08:04 -0500<br>
>> >> From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">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">openstack-dev@lists.openstack.org</a>>,<br>
>> >> "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>"<br>
>> >> <<a href="mailto:openstack-operators@lists.openstack.org">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">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<br>
>> ignored<br>
>> >> because n-cpu is configured with libvirt.inject_partition=-2 by<br>
>> default.<br>
>> >> That disables file injection:<br>
>> >><br>
>> >><br>
>> >><br>
>> <a href="https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030</a><br>
>> >><br>
>> >> We don't even log a warning if the user requested files to inject and<br>
>> we<br>
>> >> can't honor it. If I were a user and tried to inject files when<br>
>> creating<br>
>> >> a server but they didn't show up in the guest, I'd open a support<br>
>> 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<br>
>> 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<br>
>> allow<br>
>> >> that.<br>
>> >><br>
>> >> I'd also think that this should trigger a reschedule to another<br>
>> compute.<br>
>> >> However, if all computes have disabled file injection, which is the<br>
>> >> default:<br>
>> >><br>
>> >><br>
>> >><br>
>> <a href="https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/0c0f60031acba11d0bab0617f68b95d9b5eb8d1d/nova/conf/libvirt.py#L66</a><br>
>> >><br>
>> >> Then they'll retry 3 times and fail with an instance in error state. So<br>
>> >> I'm not sure if rescheduling in this case is useful. I'd think that<br>
>> >> deployments are either allowing file injection globally (if using<br>
>> >> libvirt) of they aren't, but would need some operators to chime in<br>
>> 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">corpqa@gmail.com</a>><br>
>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">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">1d1282b2e4d7eb4d4c701c0ed0b55551@openstack.nimeyo.com</a>><br>
>> >> Content-Type: text/plain; charset="us-ascii"<br>
>> >><br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/3013a3a5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/3013a3a5/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 8<br>
>> >> Date: Sun, 3 Jul 2016 19:54:19 +0300<br>
>> >> From: Valeriy Ponomaryov <<a href="mailto:vponomaryov@mirantis.com">vponomaryov@mirantis.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [manila][stable] liberty periodic bitrot<br>
>> >> jobs have been failing more than a week<br>
>> >> Message-ID:<br>
>> >> <CAPnpNOVTxe6PcuLbZ_3uu-fGZeReVw0G=<br>
>> >> <a href="mailto:pko8KTP3AKWQx-8sQ@mail.gmail.com">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<br>
>> specific<br>
>> >> files are changed. See [1].<br>
>> >><br>
>> >> [1]<br>
>> >><br>
>> >><br>
>> <a href="https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/f269e732/zuul/layout.yaml#L1066</a><br>
>> >><br>
>> >> On Sun, Jul 3, 2016 at 4:19 PM, Matt Riedemann <<br>
>> >> <a href="mailto:mriedem@linux.vnet.ibm.com">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">mriedem@linux.vnet.ibm.com</a>><br>
>> >> wrote:<br>
>> >> >><br>
>> >> >> The manila periodic stable/liberty jobs have been failing for at<br>
>> least<br>
>> >> a<br>
>> >> >> week.<br>
>> >> >><br>
>> >> >> It looks like manila isn't using upper-constraints when running unit<br>
>> >> >> tests, not even on stable/mitaka or master. So in liberty it's<br>
>> pulling<br>
>> >> >> in uncapped oslo.utils even though the upper constraint for<br>
>> oslo.utils<br>
>> >> >> in liberty is 3.2.<br>
>> >> >><br>
>> >> >> Who from the manila team is going to be working on fixing this,<br>
>> either<br>
>> >> >> via getting upper-constraints in place in the tox.ini for manila (on<br>
>> >> all<br>
>> >> >> supported branches) or performing some kind of workaround in the<br>
>> 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<br>
>> Manila in<br>
>> >> > stable/liberty outside of 3rd party CI (which is not voting)?<br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> ><br>
>> >> > Matt Riedemann<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Kind Regards<br>
>> >> Valeriy Ponomaryov<br>
>> >> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
>> >> <a href="mailto:vponomaryov@mirantis.com">vponomaryov@mirantis.com</a><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/b9601a80/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/b9601a80/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 9<br>
>> >> Date: Sun, 3 Jul 2016 15:26:23 -0400<br>
>> >> From: Henry Gessau <<a href="mailto:HenryG@gessau.net">HenryG@gessau.net</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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">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">cboylan@sapwetik.org</a>> wrote:<br>
>> >> > The infra team is working on taking advantage of the new Ubuntu<br>
>> Xenial<br>
>> >> > release including running unittests on python35. The current plan is<br>
>> to<br>
>> >> > get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday<br>
>> (July<br>
>> >> > 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> >> > master/Newton on all projects that had python34 testing.<br>
>> >> ><br>
>> >> > The expectation is that in many cases python35 tests will just work<br>
>> if<br>
>> >> > python34 testing was also working. If this is the case for your<br>
>> project<br>
>> >> > you can propose a change to openstack-infra/project-config to make<br>
>> these<br>
>> >> > jobs voting against your project. You should only need to edit<br>
>> >> > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> >> > portion of the python35 jobs to do this.<br>
>> >> ><br>
>> >> > We do however expect that there will be a large group of failed tests<br>
>> >> > too. If your project has a specific tox.ini py34 target to restrict<br>
>> >> > python3 testing to a specific list of tests you will need to add a<br>
>> tox<br>
>> >> > target for py35 that does the same thing as the py34 target. We have<br>
>> >> > also seen bug reports against some projects whose tests rely on<br>
>> stable<br>
>> >> > error messages from Python itself which isn't always the case across<br>
>> >> > version changes so these tests will need to be updated as well.<br>
>> >> ><br>
>> >> > Note this change will not add python35 jobs for cases where projects<br>
>> >> > have special tox targets. This is restricted just to the default py35<br>
>> >> > unittesting.<br>
>> >> ><br>
>> >> > As always let us know if you questions,<br>
>> >> > Clark<br>
>> >><br>
>> >> How soon can projects replace py34 with py35?<br>
>> >><br>
>> >> 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">email@daviey.com</a>><br>
>> >> To: OpenStack Development Mailing List<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: [openstack-dev] [kolla][horizon] Out of branch horizon<br>
>> >> plugins?<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CACyjiAhWiOTvZjAKyibSC4wpHyK6c9%2BcNK0dzy_dFxSgX%2BckAA@mail.gmail.com">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<br>
>> Horizon<br>
>> >> is configured in Kolla.<br>
>> >><br>
>> >> Horizon is increasingly embracing a plugin architecture with UI's and<br>
>> >> Dashboards being maintained outside of Horizon's tree.<br>
>> >><br>
>> >> These can be found with the type:horizon-plugin tag in<br>
>> >> openstack/governance<br>
>> >> [0], with 16 projects at current.<br>
>> >><br>
>> >> This isn't really addressed in Kolla, and is a little awkward to<br>
>> 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<br>
>> topic<br>
>> >> of this thread)<br>
>> >><br>
>> >> It would seem logical to pack all of these into the horizon docker<br>
>> image,<br>
>> >> and add a symlink into dashboard/local/enabled via ansible, policy.json<br>
>> >> and<br>
>> >> default settings with some conditionals if enabled_$service... but this<br>
>> >> will make the horizon docker image larger and more complicated.<br>
>> >><br>
>> >> What are your thoughts?<br>
>> >><br>
>> >> [0]<br>
>> >><br>
>> >><br>
>> <a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml</a><br>
>> >><br>
>> >> --<br>
>> >> Kind Regards,<br>
>> >> Dave Walker<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/dd00980b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/dd00980b/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 11<br>
>> >> Date: Sun, 03 Jul 2016 17:20:42 -0700<br>
>> >> From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
>> >> To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">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">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">cboylan@sapwetik.org</a>> wrote:<br>
>> >> > > The infra team is working on taking advantage of the new Ubuntu<br>
>> Xenial<br>
>> >> > > release including running unittests on python35. The current plan<br>
>> is<br>
>> >> to<br>
>> >> > > get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday<br>
>> >> (July<br>
>> >> > > 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> >> > > master/Newton on all projects that had python34 testing.<br>
>> >> > ><br>
>> >> > > The expectation is that in many cases python35 tests will just<br>
>> work if<br>
>> >> > > python34 testing was also working. If this is the case for your<br>
>> >> project<br>
>> >> > > you can propose a change to openstack-infra/project-config to make<br>
>> >> these<br>
>> >> > > jobs voting against your project. You should only need to edit<br>
>> >> > > jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the<br>
>> '-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<br>
>> tests<br>
>> >> > > too. If your project has a specific tox.ini py34 target to restrict<br>
>> >> > > python3 testing to a specific list of tests you will need to add a<br>
>> tox<br>
>> >> > > target for py35 that does the same thing as the py34 target. We<br>
>> have<br>
>> >> > > also seen bug reports against some projects whose tests rely on<br>
>> stable<br>
>> >> > > error messages from Python itself which isn't always the case<br>
>> 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<br>
>> projects<br>
>> >> > > have special tox targets. This is restricted just to the default<br>
>> 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">me@gbraad.nl</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: [openstack-dev] [Kolla] [docker] Storage-driver and loopback<br>
>> >> usage?<br>
>> >> Message-ID:<br>
>> >> <CAGrH30WswSoHyeSOSNse3kJcPwkZOdLxu=<br>
>> >> <a href="mailto:Fd9ki7UGGu3Xw_ww@mail.gmail.com">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">gus@inodes.org</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [grenade] upgrades vs rootwrap<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CAPA_H3fkw%2BMB_AjHVAmS29%2BviS07PJXdM3RukK0fhx-gv2fyRw@mail.gmail.com">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">mriedem@linux.vnet.ibm.com</a><br>
>> ><br>
>> >> wrote:<br>
>> >><br>
>> >> > On 6/28/2016 4:56 PM, Sean Dague wrote:<br>
>> >> > > On 06/28/2016 01:46 AM, Angus Lees wrote:<br>
>> >> > >> Ok, thanks for the in-depth explanation.<br>
>> >> > >><br>
>> >> > >> My take away is that we need to file any rootwrap updates as<br>
>> >> exceptions<br>
>> >> > >> for now (so releasenotes and grenade scripts).<br>
>> >> > ><br>
>> >> > > That is definitely the fall back if there is no better idea.<br>
>> However,<br>
>> >> we<br>
>> >> > > should try really hard to figure out if there is a non manual way<br>
>> >> > > through this. Even if that means some compat code that we keep for<br>
>> 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<br>
>> available.<br>
>> >> > That could be a workaround for upgrading with os-brick for Newton,<br>
>> 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<br>
>> wait<br>
>> >> 6 months before submitting the code that needs it". If we don't wish<br>
>> to<br>
>> >> use the exception mechanism (or adjust the policy to upgrade conf<br>
>> before<br>
>> >> code as I described earlier), then we can certainly do this. Rather<br>
>> 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<br>
>> in<br>
>> >> nova/cinder (the comments suggest (nova) libvirt/imagebackend.py,<br>
>> (cinder)<br>
>> >> remotefs.py, and (both) vzstorage.py). The various privsep-only<br>
>> >> suggestions about fallback strategies don't help in these other<br>
>> >> examples. Any<br>
>> >> corresponding code changes that rely on these new filters will also<br>
>> need<br>
>> >> to<br>
>> >> be reverted and resubmitted during next cycle - or do what usually<br>
>> happens<br>
>> >> and slip under the radar as they are not exercised by grenade.<br>
>> >><br>
>> >> - Gus<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b8832f07/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b8832f07/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 14<br>
>> >> Date: Sun, 3 Jul 2016 23:41:22 -0400<br>
>> >> From: Steve Martinelli <<a href="mailto:s.martinelli@gmail.com">s.martinelli@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: [openstack-dev] [keystone] spec freeze on july 8th, 2016<br>
>> >> Message-ID:<br>
>> >> <CAHc_MXHV+bj-c36=bDxUZ1SU=<br>
>> >> <a href="mailto:FFy-jy2ssSnaVEHFxd3fLGFag@mail.gmail.com">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<br>
>> Newton<br>
>> >> based on how far along the spec is, its complexity, core reviewer<br>
>> >> attention<br>
>> >> and priority. (Thanks Matt R for the wording)<br>
>> >><br>
>> >> I'd like spend the bulk of the next keystone meeting on Tuesday<br>
>> discussing<br>
>> >> the open specs. If you are authoring one, please try to attend.<br>
>> >><br>
>> >> [1]<br>
>> >><br>
>> >><br>
>> <a href="https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/project:openstack/keystone-specs+status:open</a><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/046649b3/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160703/046649b3/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 15<br>
>> >> Date: Mon, 4 Jul 2016 11:58:40 +0800<br>
>> >> From: Jeffrey Zhang <<a href="mailto:zhang.lei.fly@gmail.com">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">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [Kolla] [docker] Storage-driver and<br>
>> >> loopback usage?<br>
>> >> Message-ID:<br>
>> >> <CAATxhGftHC_oJMkX-vabJugNCK+DBom6m3qGZj_051tZS=<br>
>> >> <a href="mailto:7fHg@mail.gmail.com">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<br>
>> 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]<br>
>> <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">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<br>
>> 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>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Regards,<br>
>> >> Jeffrey Zhang<br>
>> >> Blog: <a href="http://xcodest.me" rel="noreferrer" target="_blank">http://xcodest.me</a><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/cf4c7da8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/cf4c7da8/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 16<br>
>> >> Date: Mon, 4 Jul 2016 14:33:08 +1000<br>
>> >> From: Joshua Hesketh <<a href="mailto:joshua.hesketh@gmail.com">joshua.hesketh@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the<br>
>> >> world"<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CA%2BDTi5w-azo949HhOnp7gufu0Lsov77C1dUnHaBG_8SVneGD%2Bg@mail.gmail.com">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">Jesse.Pretorius@rackspace.co.uk</a>> wrote:<br>
>> >><br>
>> >> > Hi all,<br>
>> >> ><br>
>> >> > Now that OpenStack-Ansible has the final Swift kilo-eol tag<br>
>> implemented<br>
>> >> > we?ve requested a final tag [1]. Once that merges we are ready to<br>
>> have<br>
>> >> our<br>
>> >> > kilo-eol tag implemented and the ?kilo? branch removed.<br>
>> >> ><br>
>> >><br>
>> >> I assume you want to wait for the tag to merge before removing the<br>
>> 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<br>
>> too. I<br>
>> >> > think we have the appropriate skips in place for the juno branch so<br>
>> >> there<br>
>> >> > should be no funky post-tag jobs kicking off for them, but the<br>
>> icehouse<br>
>> >> > branch may end up with some unknown jobs kicking off. If you can help<br>
>> >> > identify the changes we need to get implemented into project-config<br>
>> >> then we<br>
>> >> > can be rid of the old cruft.<br>
>> >> ><br>
>> >><br>
>> >> The only tag job I can see for openstack-ansible* projects is the<br>
>> >> releasenotes one. This should be harmless as it just generates the<br>
>> notes<br>
>> >> for mitaka and liberty branches. I'm going to hold off until the final<br>
>> 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<br>
>> Millington<br>
>> >> > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy<br>
>> >> policy<br>
>> >> > can be viewed at <a href="http://www.rackspace.co.uk/legal/privacy-policy" rel="noreferrer" target="_blank">www.rackspace.co.uk/legal/privacy-policy</a> - This<br>
>> e-mail<br>
>> >> > message may contain confidential or privileged information intended<br>
>> for<br>
>> >> the<br>
>> >> > recipient. Any dissemination, distribution or copying of the enclosed<br>
>> >> > material is prohibited. If you receive this transmission in error,<br>
>> >> please<br>
>> >> > notify us immediately by e-mail at <a href="mailto:abuse@rackspace.com">abuse@rackspace.com</a> and delete<br>
>> the<br>
>> >> > original message. Your cooperation is appreciated.<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/dfba39e6/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/dfba39e6/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 17<br>
>> >> Date: Mon, 4 Jul 2016 07:18:41 +0200<br>
>> >> From: Andreas Jaeger <<a href="mailto:aj@suse.com">aj@suse.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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">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">cboylan@sapwetik.org</a>> wrote:<br>
>> >> >> The infra team is working on taking advantage of the new Ubuntu<br>
>> Xenial<br>
>> >> >> release including running unittests on python35. The current plan<br>
>> 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<br>
>> (July<br>
>> >> >> 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> >> >> master/Newton on all projects that had python34 testing.<br>
>> >> >><br>
>> >> >> The expectation is that in many cases python35 tests will just work<br>
>> if<br>
>> >> >> python34 testing was also working. If this is the case for your<br>
>> project<br>
>> >> >> you can propose a change to openstack-infra/project-config to make<br>
>> >> these<br>
>> >> >> jobs voting against your project. You should only need to edit<br>
>> >> >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'<br>
>> >> >> portion of the python35 jobs to do this.<br>
>> >> >><br>
>> >> >> We do however expect that there will be a large group of failed<br>
>> tests<br>
>> >> >> too. If your project has a specific tox.ini py34 target to restrict<br>
>> >> >> python3 testing to a specific list of tests you will need to add a<br>
>> tox<br>
>> >> >> target for py35 that does the same thing as the py34 target. We have<br>
>> >> >> also seen bug reports against some projects whose tests rely on<br>
>> stable<br>
>> >> >> error messages from Python itself which isn't always the case across<br>
>> >> >> version changes so these tests will need to be updated as well.<br>
>> >> >><br>
>> >> >> Note this change will not add python35 jobs for cases where projects<br>
>> >> >> have special tox targets. This is restricted just to the default<br>
>> 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:<br>
>> 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<br>
>> 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">lildee1991@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] New Python35 Jobs coming<br>
>> >> Message-ID:<br>
>> >> <CALzSdtnL==UYr7-WS54G=<br>
>> >> <a href="mailto:HJrFxSHwESdF-W-W6Sz8F7jKe1wfQ@mail.gmail.com">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">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">cboylan@sapwetik.org</a>> wrote:<br>
>> >> > >> The infra team is working on taking advantage of the new Ubuntu<br>
>> >> Xenial<br>
>> >> > >> release including running unittests on python35. The current plan<br>
>> is<br>
>> >> to<br>
>> >> > >> get <a href="https://review.openstack.org/#/c/336272/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/336272/</a> merged next Tuesday<br>
>> >> (July<br>
>> >> > >> 5, 2016). This will add non voting python35 tests restricted to >=<br>
>> >> > >> master/Newton on all projects that had python34 testing.<br>
>> >> > >><br>
>> >> > >> The expectation is that in many cases python35 tests will just<br>
>> work<br>
>> >> if<br>
>> >> > >> python34 testing was also working. If this is the case for your<br>
>> >> project<br>
>> >> > >> you can propose a change to openstack-infra/project-config to make<br>
>> >> these<br>
>> >> > >> jobs voting against your project. You should only need to edit<br>
>> >> > >> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the<br>
>> '-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<br>
>> tests<br>
>> >> > >> too. If your project has a specific tox.ini py34 target to<br>
>> restrict<br>
>> >> > >> python3 testing to a specific list of tests you will need to add a<br>
>> >> tox<br>
>> >> > >> target for py35 that does the same thing as the py34 target. We<br>
>> have<br>
>> >> > >> also seen bug reports against some projects whose tests rely on<br>
>> >> stable<br>
>> >> > >> error messages from Python itself which isn't always the case<br>
>> 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<br>
>> projects<br>
>> >> > >> have special tox targets. This is restricted just to the default<br>
>> 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<br>
>> 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<br>
>> 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:<br>
>> 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<br>
>> A126<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8da19224/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8da19224/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 19<br>
>> >> Date: Mon, 4 Jul 2016 14:12:01 +0800<br>
>> >> From: Zhenyu Zheng <<a href="mailto:zhengzhenyulixi@gmail.com">zhengzhenyulixi@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [Nova] Questions about instance actions'<br>
>> >> update and finish<br>
>> >> Message-ID:<br>
>> >> <CAO0b__-CoU9UDaVQEFrtL9=<br>
>> >> <a href="mailto:L92TbZhJUwkYfs9iA7R-xVM%2Bpwg@mail.gmail.com">L92TbZhJUwkYfs9iA7R-xVM+pwg@mail.gmail.com</a>><br>
>> >> Content-Type: text/plain; charset="utf-8"<br>
>> >><br>
>> >> I'm willing to work on this, should this be a Blueprint for O?<br>
>> >><br>
>> >> On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann <<br>
>> >> <a href="mailto:mriedem@linux.vnet.ibm.com">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">sean@dague.net</a><br>
>> >> >> <mailto:<a href="mailto:sean@dague.net">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,<br>
>> and<br>
>> >> >> leave the<br>
>> >> >> >>>>> finish to the other BP, by this way, I can use updated_at<br>
>> for<br>
>> >> >> the<br>
>> >> >> >>>>> timestamp filter I added and it don't need to change again<br>
>> >> once<br>
>> >> >> the<br>
>> >> >> >>>>> finish BP is complete.<br>
>> >> >> >>>><br>
>> >> >> >>>> Sounds good to me.<br>
>> >> >> >>>><br>
>> >> >> >>><br>
>> >> >> >>> It's been a long day so my memory might be fried, but the<br>
>> >> options<br>
>> >> >> we<br>
>> >> >> >>> talked about in the API meeting were:<br>
>> >> >> >>><br>
>> >> >> >>> 1. Setting updated_at = created_at when the instance action<br>
>> >> >> record is<br>
>> >> >> >>> created. Laski likes this, I'm not crazy about it,<br>
>> especially<br>
>> >> >> since we<br>
>> >> >> >>> don't do that for anything else.<br>
>> >> >> ><br>
>> >> >> > I would actually like for us to do this generally. I have the<br>
>> >> same<br>
>> >> >> > thinking as Ed does elsewhere in this thread, the creation of<br>
>> a<br>
>> >> >> record<br>
>> >> >> > is an update of that record. So take my comments as applying<br>
>> to<br>
>> >> Nova<br>
>> >> >> > overall and not just this issue.<br>
>> >> >><br>
>> >> >> Agree. Also it just simplifies a number of things. We should<br>
>> just<br>
>> >> >> start<br>
>> >> >> doing this going forward, and probably put some online data<br>
>> >> migrations<br>
>> >> >> in place next cycle to update all the old records. Once<br>
>> 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<br>
>> 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<br>
>> (created_at<br>
>> >> > wouldn't change, but updated_at could).<br>
>> >> ><br>
>> >> ><br>
>> >> >> Anyway, we already freeze... probably we can begin to fix the<br>
>> >> updated_at<br>
>> >> >> problem first.<br>
>> >> >><br>
>> >> >><br>
>> >> >> >>> 2. Update the instance action's updated_at when instance<br>
>> 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<br>
>> create/modify<br>
>> >> an<br>
>> >> >> event<br>
>> >> >> >>> we can consider it an update to the parent. Laski thought<br>
>> this<br>
>> >> >> might be<br>
>> >> >> >>> weird UX given we don't expose instance action events in the<br>
>> >> REST<br>
>> >> >> API<br>
>> >> >> >>> unless you're an admin. This is also probably not something<br>
>> >> we'd<br>
>> >> >> do for<br>
>> >> >> >>> other related resources like server groups and server group<br>
>> >> >> members (but<br>
>> >> >> >>> we don't page on those either right now).<br>
>> >> >> ><br>
>> >> >> > Right. My concern is just that the ordering of actions can<br>
>> 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<br>
>> 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<br>
>> fine<br>
>> >> >> > solution for the issue at hand. I just think #1 is a more<br>
>> 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<br>
>> think<br>
>> >> we<br>
>> >> >> all<br>
>> >> >> >>> agreed in the meeting to do this regardless of #1 or #2<br>
>> above.<br>
>> >> >><br>
>> >> >> I kind of hate that as the order, because then the marker is<br>
>> going<br>
>> >> to<br>
>> >> >> have to be really funny double timestamp, right?<br>
>> >> >><br>
>> >> >><br>
>> >> >> The marker only needs to fill with the unique value. There isn't any<br>
>> >> >> problem order with multiple column. Some time we need order with<br>
>> >> >> mulitple column for stable order when the first order column is<br>
>> >> >> without UniqueConstraint.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> I guess that's the one thing I don't see in this patch is a<br>
>> >> functional<br>
>> >> >> test that actually loads up instance actions and iterates<br>
>> through<br>
>> >> >> demonstrating the pagination.<br>
>> >> >><br>
>> >> >> -Sean<br>
>> >> >><br>
>> >> >> --<br>
>> >> >> Sean Dague<br>
>> >> >> <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> Unsubscribe:<br>
>> >> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >> <<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >> ><br>
>> >> >><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> Unsubscribe:<br>
>> >> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> >> > --<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> ><br>
>> >> > Matt Riedemann<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 20<br>
>> >> Date: Mon, 4 Jul 2016 13:17:11 +0700<br>
>> >> From: Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com">renat.akhmerov@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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">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<br>
>> now.<br>
>> >> The changes were really minimal. If it creates some problems for us we<br>
>> can<br>
>> >> always easily revert.<br>
>> >><br>
>> >> Renat Akhmerov<br>
>> >> @Nokia<br>
>> >><br>
>> >> > On 01 Jul 2016, at 04:57, Steve Martinelli <<a href="mailto:s.martinelli@gmail.com">s.martinelli@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> > The crux of this, as Dean stated, is if the library wants OSC to<br>
>> always<br>
>> >> be pulled in (along with its many dependencies). We've seen folks<br>
>> include<br>
>> >> it in requirements, test-requirements, or even not at all (just<br>
>> document<br>
>> >> that OSC needs to be installed).<br>
>> >> ><br>
>> >> > I tossed up the idea with the ironic team of leveraging "extras"<br>
>> field<br>
>> >> to list OSC as optional, the change would look like:<br>
>> >> ><br>
>> >> > --- a/setup.cfg<br>
>> >> > +++ b/setup.cfg<br>
>> >> > @@ -22,6 +22,10 @@ classifier =<br>
>> >> ><br>
>> >> > +[extras]<br>
>> >> > +cli =<br>
>> >> > + python-openstackclient>=3.0.0 # Apache-2.0<br>
>> >> > +<br>
>> >> ><br>
>> >> > So, if a user wanted to install just the python binding of<br>
>> ironicclient<br>
>> >> or mistralclient, they would do $ pip install python-ironicclient; if a<br>
>> >> user wanted the CLI as well.. $ pip install python-ironicclient[cli]<br>
>> >> ><br>
>> >> > Just an idea, it may be overkill and completely horrible.<br>
>> >> ><br>
>> >> > On Thu, Jun 30, 2016 at 5:29 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
>> >> <mailto:<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>>> wrote:<br>
>> >> > On Thu, Jun 30, 2016 at 8:38 AM, Hardik <<br>
>> >> <a href="mailto:hardik.parekh@nectechnologies.in">hardik.parekh@nectechnologies.in</a> <mailto:<br>
>> <a href="mailto:hardik.parekh@nectechnologies.in">hardik.parekh@nectechnologies.in</a>>><br>
>> >> wrote:<br>
>> >> > Regarding osc-lib we have mainly two changes.<br>
>> >> ><br>
>> >> > 1) Used "utils" which is moved from openstackclient.common.utils to<br>
>> >> osc_lib.utils<br>
>> >> > 2) We used "command" which wrapped in osc_lib from cliff.<br>
>> >> ><br>
>> >> > So I think there is no harm in keeping osc_lib.<br>
>> >> ><br>
>> >> > Admittedly the change to include osc-lib is a little early, I would<br>
>> >> have preferred until the other parts of it were a bit more stable.<br>
>> >> ><br>
>> >> > Also, I guess we do not need openstackclient to be installed with<br>
>> >> mistralclient as if mistral is used in standalone mode<br>
>> >> > there is no need of openstackclient.<br>
>> >> ><br>
>> >> > The choice to include OSC as a dependency of a plugin/library rests<br>
>> >> entirely on the plugin team, and that will usually be determined by the<br>
>> >> answer to the question "Do you want all users of your library to have<br>
>> OSc<br>
>> >> installed even if they do not use it?" or alternatively "Do you want<br>
>> to<br>
>> >> make your users remember to install OSC after installing the plugin?"<br>
>> >> ><br>
>> >> > Note that we do intend to have the capability on osc-lib to build an<br>
>> >> OSC-like stand-alone binary for plugins that would theoretically make<br>
>> >> installing OSC optional for stand-alone client users. This is not<br>
>> complete<br>
>> >> yet, and as I said above, one reason I wish osc-lib had not been merged<br>
>> >> into plugin requirements yet. That said, as long as you don't use<br>
>> those<br>
>> >> bits yet you will be fine, the utils, command, etc bits are stable, it<br>
>> is<br>
>> >> the clientmanager and shell parts that are still being developed.<br>
>> >> ><br>
>> >> > dt<br>
>> >> ><br>
>> >> > --<br>
>> >> ><br>
>> >> > Dean Troyer<br>
>> >> > <a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a> <mailto:<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a> <<br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/b0a28ef7/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 21<br>
>> >> Date: Mon, 4 Jul 2016 08:22:11 +0200<br>
>> >> From: Kashyap Chamarthy <<a href="mailto:kchamart@redhat.com">kchamart@redhat.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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<br>
>> exact<br>
>> >> > > question on #openstack-infra, but can't find Infra team's response<br>
>> to<br>
>> >> > > that.<br>
>> >> ><br>
>> >> > The challenge here is that you want to make sure it can't be used to<br>
>> >> > recheck individual jobs until you have them all passing (like<br>
>> >> > picking a pin and tumbler lock). The temptation to recheck-spam<br>
>> >> > nondeterministically failing changes is already present, but this<br>
>> >> > would make it considerably easier still for people to introduce new<br>
>> >> > nondeterministic failures in projects. Maybe if it were tied to a<br>
>> >> > special pipeline type, and then we set it only for the experimental<br>
>> >> > pipeline or something?<br>
>> >><br>
>> >> If it reduces nondeterministic spam for the CI Infra, and makes us<br>
>> >> achieve the task at hand, sure. [/me need to educate himself a<br>
>> >> bit more on the Zuul pipeline infrastructure.]<br>
>> >><br>
>> >> Worth filing this (and your 'idle pipeline' thought below) in the Zuul<br>
>> >> tracker here?<br>
>> >><br>
>> >> <a href="https://storyboard.openstack.org/#!/project/679" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/project/679</a><br>
>> >><br>
>> >> > > > 2. the ability to request this recheck to run multiple<br>
>> >> > > > times in parallel. eg if i just repeat the 'recheck'<br>
>> >> > > > command many times on the same patchset # without<br>
>> >> > > > waiting for results<br>
>> >> > ><br>
>> >> > > Yes, this too, would be _very_ useful for all the reasons you<br>
>> >> described.<br>
>> >> > [...]<br>
>> >> ><br>
>> >> > In the past we've discussed the option of having an "idle pipeline"<br>
>> >> > which repeatedly runs specified jobs only when there are unused<br>
>> >> > resources available, so that it doesn't significantly cut into our<br>
>> >> > resource pool when we're under high demand but still allows to<br>
>> >> > automatically collect a large amount of statistical data.<br>
>> >> ><br>
>> >> > Anyway, hopefully James Blair can weigh in on this, since Zuul is<br>
>> >> > basically in a feature freeze for a while to limit the number of<br>
>> >> > significant changes we'll need to forward-port into the v3 branch.<br>
>> >> > We'd want to discuss these new features in the context of Zuul v3<br>
>> >> > instead.<br>
>> >><br>
>> >> > --<br>
>> >> > Jeremy Stanley<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >> --<br>
>> >> /kashyap<br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 22<br>
>> >> Date: Mon, 4 Jul 2016 15:10:47 +0800<br>
>> >> From: Luck Dog <<a href="mailto:dfhuangg@gmail.com">dfhuangg@gmail.com</a>><br>
>> >> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> >> Subject: [openstack-dev] [tricircle]<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CAL-y67hjWJ7XrOUjLiMZGV2va_5z_921jxMN3YL1a-GCh%2Bi58w@mail.gmail.com">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<br>
>> this<br>
>> >> question not clearly enough?so I make a supplication for it. My steps<br>
>> >> are:<br>
>> >> 1), Git clone DevStack,<br>
>> >> 2), Copy devstack/local.conf.sample to DevStack folder and rename it to<br>
>> >> local.conf.<br>
>> >><br>
>> >> the finished steps before the error turns up are listed as follows:<br>
>> >><br>
>> >> 2016-06-29 09:11:53.081 | stack.sh log<br>
>> >> /opt/stack/logs/stack.sh.log.2016-06-29-171152<br>
>> >> 2016-06-29 09:12:19.797 | Installing package prerequisites<br>
>> >> 2016-06-29 09:15:27.224 | Installing OpenStack project source<br>
>> >> 2016-06-29 09:24:43.323 | Installing Tricircle<br>
>> >> 2016-06-29 09:24:55.979 | Starting RabbitMQ<br>
>> >> 2016-06-29 09:25:00.731 | Configuring and starting MySQL<br>
>> >> 2016-06-29 09:25:20.143 | Starting Keystone<br>
>> >> 2016-06-29 09:43:18.591 | Configuring Glance<br>
>> >> 2016-06-29 09:43:59.667 | Configuring Neutron<br>
>> >> 2016-06-29 09:46:30.646 | Configuring Cinder<br>
>> >> 2016-06-29 09:46:54.719 | Configuring Nova<br>
>> >> 2016-06-29 09:48:23.175 | Configuring Tricircle<br>
>> >> 2016-06-29 09:51:24.143 | Starting Glance<br>
>> >> 2016-06-29 09:52:11.133 | Uploading images<br>
>> >> 2016-06-29 09:52:45.460 | Starting Nova API<br>
>> >> 2016-06-29 09:53:27.511 | Starting Neutron<br>
>> >> 2016-06-29 09:54:21.476 | Creating initial neutron network elements<br>
>> >><br>
>> >> The last errors when it stops running are:<br>
>> >><br>
>> >> Request body: {u'network': {u'router:external': True,<br>
>> >> u'provider:network_type': u'flat', u'name': u'public',<br>
>> >> u'provider:physical_network': u'public', u'admin_state_up':<br>
>> 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]<br>
>> ^[[01;35m^[[00;32mAttempting to<br>
>> >> reserve 1 items for resource network. Total usage: 0; quota limit: 10;<br>
>> >> headroom:10^[[00m ^[[00;33mfrom (pid=29980) make_reservation<br>
>> >> /opt/stack/neutron/neutron/db/quota/driver.py:223^[[00m<br>
>> >> 2016-06-29 17:56:04.425 ^[[01;31mERROR neutron.api.v2.resource<br>
>> >> [^[[01;36mreq-e97f6276-8e19-408b-829a-004a31256453 ^[[00;36madmin<br>
>> >> 13869ba8005b480bbcbe17b2695fd5e2^[[01;31m] ^[[01;35m^[[01;31mcreate<br>
>> >> failed^[[00m<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00mTraceback (most recent call last):<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/resource.py",<br>
>> >> line<br>
>> >> 78, in resource<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m result = method(request=request, **args)<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m File "/opt/stack/neutron/neutron/api/v2/base.py", line<br>
>> >> 424, in create<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m return self._create(request, body, **kwargs)<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m File<br>
>> >> "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in<br>
>> >> wrapper<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m ectxt.value = e.inner_exc<br>
>> >> ^[[01;31m2016-06-29 17:56:04.425 TRACE neutron.api.v2.resource<br>
>> >> ^[[01;35m^[[00m File<br>
>> >> "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line<br>
>> 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<br>
>> 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<br>
>> "/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<br>
>> "/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>
>> - -<br>
>> >> [29/Jun/2016 17:56:04] "POST /v2.0/networks.json HTTP/1.1" 500 368<br>
>> >> 0.147805^[[00m<br>
>> >><br>
>> >> the final printed errors on terminal are:<br>
>> >><br>
>> >> Request Failed: internal server error while processing your request.<br>
>> >> Neutron server returns request_ids:<br>
>> >> ['req-e97f6276-8e19-408b-829a-004a31256453']<br>
>> >> lib/neutron_plugins/services/l3:create_neutron_initial_network:203<br>
>> >> lib/neutron_plugins/services/l3:create_neutron_initial_network:207<br>
>> >> [ERROR] /home/sword/DevStack/functions-common:207 Failure creating<br>
>> >> EXT_NET_ID for public<br>
>> >><br>
>> >> I don't know whether it is my wrong configuration of computer or the<br>
>> >> server error, I wish someone can help me with the problem. thanks!<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a5c3d6b4/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a5c3d6b4/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 23<br>
>> >> Date: Mon, 4 Jul 2016 09:14:00 +0200<br>
>> >> From: Victor Stinner <<a href="mailto:vstinner@redhat.com">vstinner@redhat.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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">dd699b65-c199-2ec5-4e4a-70236971d5d4@redhat.com</a>><br>
>> >> Content-Type: text/plain; charset=windows-1252; format=flowed<br>
>> >><br>
>> >> Le 04/07/2016 ? 07:59, Denis Makogon a ?crit :<br>
>> >> > Then let it run for a day or two in our CI, discuss with neutron<br>
>> >> team,<br>
>> >> > and send a patch for project-config to change the setup,<br>
>> >> ><br>
>> >> > Can confirm that nova, glance, cinder, heat clients are py35<br>
>> 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">eezhova@mirantis.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Cc: "<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>" <<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] Openstack Mitaka Neutron LBaaS Question<br>
>> >> Message-ID:<br>
>> >> <CAFZxAhh=S0QfS+K=<br>
>> >> <a href="mailto:Jtgmx26TMH_goxYFEibKkBmVWLowL7FGUQ@mail.gmail.com">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<br>
>> Octavia<br>
>> >> DevStack plugin<br>
>> >> <<br>
>> >><br>
>> <a href="https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh" rel="noreferrer" target="_blank">https://github.com/openstack/octavia/blob/stable/mitaka/devstack/plugin.sh</a><br>
>> >> >.<br>
>> >> There is also an overview presentation<br>
>> >> <<br>
>> >><br>
>> <a href="https://docs.google.com/presentation/d/1AqmF3BnKLLu1W1n-XT5MSfVYrGue1JIwKSvjbWgGA6s/edit#slide=id.p4" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1AqmF3BnKLLu1W1n-XT5MSfVYrGue1JIwKSvjbWgGA6s/edit#slide=id.p4</a><br>
>> >> ><br>
>> >> which<br>
>> >> has some troubleshooting tips.<br>
>> >><br>
>> >> Thanks,<br>
>> >> Elena<br>
>> >><br>
>> >> On Sat, Jul 2, 2016 at 1:24 AM, zhihao wang <<a href="mailto:wangzhihaocom@hotmail.com">wangzhihaocom@hotmail.com</a><br>
>> ><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<br>
>> 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>
>> >> ><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>
>> >> ><br>
>> router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2<br>
>> >> ><br>
>> >> > [service_providers]<br>
>> >> > service_provider =<br>
>> >> ><br>
>> >><br>
>> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default<br>
>> >> ><br>
>> >> > /etc/openstack-dashboard/local_settings.py<br>
>> >> ><br>
>> >> ><br>
>> >> > OPENSTACK_NEUTRON_NETWORK = {<br>
>> >> > 'enable_lb': True<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> > And then I restart all the neutron service and apache server<br>
>> >> > service neutron-server restart<br>
>> >> > service neutron-dhcp-agent restart<br>
>> >> > service neutron-metadata-agent restart<br>
>> >> > service neutron-l3-agent restart<br>
>> >> ><br>
>> >> > but and then i ran the command neutron agent-list, it return this. I<br>
>> am<br>
>> >> > wondering what is wrong with this? how can I install Neutron LaaS?<br>
>> >> ><br>
>> >> > root@controller:~# neutron agent-list<br>
>> >> > Unable to establish connection to<br>
>> >> <a href="http://controller:9696/v2.0/agents.json" rel="noreferrer" target="_blank">http://controller:9696/v2.0/agents.json</a><br>
>> >> ><br>
>> >> ><br>
>> >> > Please help<br>
>> >> ><br>
>> >> > Thanks so much<br>
>> >> ><br>
>> >> > Thanks<br>
>> >> > Wally<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/26f31912/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/26f31912/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 25<br>
>> >> Date: Mon, 4 Jul 2016 09:38:19 +0200<br>
>> >> From: Antoni Segura Puimedon <<a href="mailto:toni%2Bopenstackml@midokura.com">toni+openstackml@midokura.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [kuryr] kuryr-libnetwork split<br>
>> >> Message-ID:<br>
>> >> <CAP8JW8DxfO+KMPKriHST2w-3k_zRKi_yKu6j=8j2En=<br>
>> >> <a href="mailto:QqR3u4A@mail.gmail.com">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">doug@doughellmann.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >> > Excerpts from Jeremy Stanley's message of 2016-07-01 15:05:30 +0000:<br>
>> >> > > On 2016-07-01 08:26:13 -0500 (-0500), Monty Taylor wrote:<br>
>> >> > > [...]<br>
>> >> > > > Check with Doug Hellman about namespaces. We used to use them in<br>
>> >> some<br>
>> >> > > > oslo things and had to step away from them because of some pretty<br>
>> >> weird<br>
>> >> > > > and horrible breakage issues.<br>
>> >> > > [...]<br>
>> >> > ><br>
>> >> > > Or read the associated Oslo spec from when that was done:<br>
>> >> > ><br>
>> >> > > <URL:<br>
>> >> ><br>
>> >><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<br>
>> 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<br>
>> built<br>
>> >> > into the language.<br>
>> >> ><br>
>> >><br>
>> >> For kuryr-kubernetes we target only Python3, I wonder if we could move<br>
>> >> kuryr-libnetwork<br>
>> >> to be python3 only and, if that were the case, how this alters the<br>
>> >> situation for namespace<br>
>> >> packages.<br>
>> >><br>
>> >><br>
>> >> ><br>
>> >> > Doug<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/15cceea8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/15cceea8/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 26<br>
>> >> Date: Mon, 4 Jul 2016 16:13:28 +0800<br>
>> >> From: Damon Wang <<a href="mailto:damon.devops@gmail.com">damon.devops@gmail.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades<br>
>> >> work status. 6/20/2016<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CABZYMH4S8tc3XxAQbgRsuE2YyDwo6rf5v2u7u0KF%2BwFtceRaWw@mail.gmail.com">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<br>
>> 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">ihrachys@redhat.com</a>>:<br>
>> >><br>
>> >> > Hi all,<br>
>> >> ><br>
>> >> > (It?s not really bi-weekly since I missed it the previous week. This<br>
>> >> > report is for the last 3 weeks. I will try to keep a more regular<br>
>> >> schedule<br>
>> >> > for those updates in the future.)<br>
>> >> ><br>
>> >> > OK. What?s new in neutron upgrades since last update?<br>
>> >> ><br>
>> >> > 1. For the most part, the team works on migrating existing code base<br>
>> 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<br>
>> is<br>
>> >> > something that we push for before we switch resources to using<br>
>> objects<br>
>> >> to<br>
>> >> > avoid potential regressions. Things that landed:<br>
>> >> > - next/prev href links tests: <a href="https://review.openstack.org/318270" rel="noreferrer" target="_blank">https://review.openstack.org/318270</a><br>
>> >> > - subnet tests: <a href="https://review.openstack.org/329340" rel="noreferrer" target="_blank">https://review.openstack.org/329340</a><br>
>> >> > - subnetpools tests: <a href="https://review.openstack.org/327081" rel="noreferrer" target="_blank">https://review.openstack.org/327081</a><br>
>> >> ><br>
>> >> > We have a lot more related patches though, including test coverage as<br>
>> >> well<br>
>> >> > as enabling sorting/pagination for all installations. All those are<br>
>> >> tracked<br>
>> >> > under:<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >><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<br>
>> .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<br>
>> filtering:<br>
>> >> > <a href="https://review.openstack.org/#/c/326361/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/326361/</a><br>
>> >> > - query filter hook added to objects:<br>
>> >> <a href="https://review.openstack.org/328304" rel="noreferrer" target="_blank">https://review.openstack.org/328304</a><br>
>> >> > - qos policy filtering by ?shared? field is fixed by utilizing ^:<br>
>> >> > <a href="https://review.openstack.org/328313" rel="noreferrer" target="_blank">https://review.openstack.org/328313</a><br>
>> >> ><br>
>> >> > 2. As for multinode grenade testing, there was little progress on<br>
>> >> getting<br>
>> >> > voting for the DVR job. This is something that I plan to tackle in<br>
>> the<br>
>> >> near<br>
>> >> > future.<br>
>> >> ><br>
>> >> > ===<br>
>> >> ><br>
>> >> > Team info:<br>
>> >> > Upgrades Subteam has the weekly meetings on Mondays, 2PM UTC, wiki<br>
>> page:<br>
>> >> > <a href="https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</a><br>
>> >> ><br>
>> >> > New patches are generally tracked under the following topic:<br>
>> >> ><br>
>> >><br>
>> <a href="https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db</a><br>
>> >> ><br>
>> >> > Ihar<br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e0472273/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e0472273/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 27<br>
>> >> Date: Mon, 4 Jul 2016 01:17:29 -0700<br>
>> >> From: Stephen Hindle <<a href="mailto:shindle@llnw.com">shindle@llnw.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla +<br>
>> >> BiFrost integration<br>
>> >> Message-ID:<br>
>> >> <CANPbtN_EUx_PV8FYEvQCaTR5XEKp98wik2USYfF=<br>
>> >> <a href="mailto:EugBFXL2jg@mail.gmail.com">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">stdake@cisco.com</a><br>
>> ><br>
>> >> wrote:<br>
>> >> > Stephen,<br>
>> >> ><br>
>> >> > Responses inline.<br>
>> >> ><br>
>> >> > On 7/1/16, 11:35 AM, "Stephen Hindle" <<a href="mailto:shindle@llnw.com">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<br>
>> mind<br>
>> >> > explaining the use case? Typically we in the Kolla community expect<br>
>> a<br>
>> >> > production deployment to only deploy OpenStack, and not other stacks<br>
>> 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<br>
>> top<br>
>> >> of<br>
>> >> > OpenStack that may need these nics. The reason is that OpenStack<br>
>> itself<br>
>> >> > managed alongside another application doesn?t know what it doesn't<br>
>> know<br>
>> >> > and can't handle capacity management or any of a number of other<br>
>> things<br>
>> >> > required to make an OpenStack cloud operate.<br>
>> >> ><br>
>> >> >> IPMI configuration<br>
>> >> ><br>
>> >> > BiFrost includes IPMI integration - assumption being we will just use<br>
>> >> > whatever BiFrost requires here for configuration.<br>
>> >> ><br>
>> >> >> Password integration with Corporate LDAP etc.<br>
>> >> ><br>
>> >> > We have been asked several times for this functionality, and it will<br>
>> >> come<br>
>> >> > naturally during either Newton or Occata.<br>
>> >> ><br>
>> >> >> Integration with existing SANs<br>
>> >> ><br>
>> >> > Cinder integrates with SANs, and in Newton, we have integration with<br>
>> >> > iSCSI. Unfortunately because of some controversy around how glance<br>
>> >> should<br>
>> >> > provide images with regards to cinder, using existing SAN gear with<br>
>> >> iSCSI<br>
>> >> > integration as is done by Cinder may not work as expected in a HA<br>
>> 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<br>
>> 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<br>
>> get<br>
>> >> the<br>
>> >> > system into an operational state. The things listed above are<br>
>> outside<br>
>> >> the<br>
>> >> > "bare minimum" iiuc.<br>
>> >> ><br>
>> >> >><br>
>> >> >>Thats just off the top of my head - I'm sure we'll run into others.<br>
>> I<br>
>> >> >>tend to think the best way<br>
>> >> >>to approach this is to allow some sort of 'bootstrap' role, that<br>
>> could<br>
>> >> >>be populated by the<br>
>> >> >>operators. This should initially be empty (Kolla specific<br>
>> 'bootstrap'<br>
>> >> ><br>
>> >> > Our bootstrap playbook is for launching BiFrost and bringing up the<br>
>> bare<br>
>> >> > metal machines with an SSH credential. It appears from this thread<br>
>> we<br>
>> >> > will have another playbook to do the bare metal initialization<br>
>> (thiings<br>
>> >> > like turning off firewalld, turning on chrony, I.e. Making the bare<br>
>> >> metal<br>
>> >> > environment operational for OpenStack)<br>
>> >> ><br>
>> >> > I think what you want is a third playbook which really belongs in the<br>
>> >> > domain of the operators to handle site-specific configuration as<br>
>> >> required<br>
>> >> > by corporate rules and the like.<br>
>> >> ><br>
>> >> ><br>
>> >> >>actions should be<br>
>> >> >>in another role) to prevent confusion.<br>
>> >> >><br>
>> >> >>We also have to be careful that kolla doesn't stomp on any non-kolla<br>
>> >> >>configuration...<br>
>> >> ><br>
>> >> > Could you expand here. Kolla currently expects the machines under<br>
>> its<br>
>> >> > control to be only OpenStack machines, and not have other<br>
>> 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">sean.k.mooney@intel.com</a>> wrote:<br>
>> >> >>><br>
>> >> >>><br>
>> >> >>>> -----Original Message-----<br>
>> >> >>>> From: Steven Dake (stdake) [mailto:<a href="mailto:stdake@cisco.com">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">openstack-dev@lists.openstack.org</a>><br>
>> >> >>>> Subject: Re: [openstack-dev] [kolla][ironic] My thoughts on Kolla<br>
>> +<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">devananda.vdv@gmail.com</a>><br>
>> >> >>>> wrote:<br>
>> >> >>>><br>
>> >> >>>> >At a quick glance, this sequence diagram matches what I<br>
>> >> >>>> >envisioned/expected.<br>
>> >> >>>> ><br>
>> >> >>>> >I'd like to suggest a few additional steps be called out, however<br>
>> >> I'm<br>
>> >> >>>> >not sure how to edit this so I'll write them here.<br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> >As part of the installation of Ironic, and assuming this is done<br>
>> >> >>>> >through Bifrost, the Actor should configure Bifrost for their<br>
>> >> >>>> >particular network environment. For instance: what eth device is<br>
>> >> >>>> >connected to the IPMI network; what IP ranges can Bifrost assign<br>
>> 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<br>
>> defaults<br>
>> >> >>>> >for this roles' config options are here:<br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> <a href="https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro" rel="noreferrer" target="_blank">https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifro</a><br>
>> >> >>>> s<br>
>> >> >>>> >t-i<br>
>> >> >>>> >ronic-install/defaults/main.yml<br>
>> >> >>>> ><br>
>> >> >>>> >and documentation is here:<br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> <a href="https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro" rel="noreferrer" target="_blank">https://github.com/openstack/bifrost/tree/master/playbooks/roles/bifro</a><br>
>> >> >>>> s<br>
>> >> >>>> >t-i<br>
>> >> >>>> >ronic-install<br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> >Immediately before "Ironic PXE boots..." step, the Actor must<br>
>> >> perform<br>
>> >> >>>> >an action to "enroll" hardware (the "deployment targets") in<br>
>> Ironic.<br>
>> >> >>>> >This could be done in several ways: passing a YAML file to<br>
>> 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<br>
>> (eg,<br>
>> >> >>>> >"ironic node-list").<br>
>> >> >>>> ><br>
>> >> >>>><br>
>> >> >>>> Great,<br>
>> >> >>>><br>
>> >> >>>> Thanks for the feedback. I'll integrate your changes into the<br>
>> >> sequence<br>
>> >> >>>> diagram when I have a free hour or so - whenever that is :)<br>
>> >> >>>><br>
>> >> >>>> Regards<br>
>> >> >>>> -steve<br>
>> >> >>> [Mooney, Sean K] I agree with most of devananda points and had<br>
>> come to<br>
>> >> >>>similar<br>
>> >> >>> Conlcutions.<br>
>> >> >>><br>
>> >> >>> At a highlevel I think the workflow from 0 to cloud would be as<br>
>> >> follow.<br>
>> >> >>> Assuming you have one linux system.<br>
>> >> >>> - clone <a href="http://github.com/openstack/kolla" rel="noreferrer" target="_blank">http://github.com/openstack/kolla</a> && cd kolla<br>
>> >> >>> - tools/kolla-host build-host-deploy<br>
>> >> >>> This will install ansible if not installed then invoke a<br>
>> >> >>>playbook to install<br>
>> >> >>> All build dependencies and generate the kolla-build.conf<br>
>> >> >>>passwords.yml and global.yml.<br>
>> >> >>> Install kolla python package<br>
>> >> >>> - configure kolla-build.conf as required<br>
>> >> >>> - tools/build.py or kolla-build to build image<br>
>> >> >>> - configure global.yml and or biforst specific file<br>
>> >> >>> This would involve specifying a file that can be used with<br>
>> 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<br>
>> when<br>
>> >> >>>connecting to the servers post deploy.<br>
>> >> >>> Configure diskimage builder options or supply path to a file on<br>
>> 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<br>
>> ceph<br>
>> >> >>> Disks .<br>
>> >> >>> This role will reboot the remote server at the end of the role if<br>
>> >> >>>required<br>
>> >> >>> e.g. after installing The wily kernel on Ubuntu 14.04<br>
>> >> >>> - configure global.yml as normal<br>
>> >> >>> - tools/kolla-ansible prechecks (this should now pass)<br>
>> >> >>> - tools/kolla-ansible deploy<br>
>> >> >>> - profit<br>
>> >> >>><br>
>> >> >>> I think this largely agrees with the diagram you proposed but has a<br>
>> >> >>>couple of extra steps/details.<br>
>> >> >>><br>
>> >> >>>><br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> >Cheers,<br>
>> >> >>>> >--Devananda<br>
>> >> >>>> ><br>
>> >> >>>> >On 06/23/2016 06:54 PM, Steven Dake (stdake) wrote:<br>
>> >> >>>> >> Hey folks,<br>
>> >> >>>> >><br>
>> >> >>>> >> I created the following sequence diagram to show my thinking on<br>
>> >> >>>> >>Ironic integration. I recognize some internals of the recently<br>
>> >> >>>> >>merged bifrost changes are not represented in this diagram. I<br>
>> >> would<br>
>> >> >>>> >>like to see a bootstrap action do all of the necessary things<br>
>> to<br>
>> >> >>>> >>bring up BiFrost in a container using Sean's WIP Kolla patch<br>
>> >> >>>> followed<br>
>> >> >>>> >>by bare metal minimal OS load followed by Kolla dependency<br>
>> >> software<br>
>> >> >>>> >>(docker-engine, docker-py, and ntpd) loading and initialization.<br>
>> >> >>>> >><br>
>> >> >>>> >> This diagram expects ssh keys to be installed on the deployment<br>
>> >> >>>> >>targets via BiFrost.<br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> <a href="https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D" rel="noreferrer" target="_blank">https://creately.com/diagram/ipt09l352/ROMDJH4QY1Avy1RYhbMUDraaQ4%3D</a><br>
>> >> >>>> >><br>
>> >> >>>> >> Thoughts welcome, especially from folks in the Ironic<br>
>> community or<br>
>> >> >>>> >>Sean who is leading this work in Kolla.<br>
>> >> >>>> >><br>
>> >> >>>> >> Regards,<br>
>> >> >>>> >> -steve<br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> >>>><br>
>> >> >>_____________________________________________________________________<br>
>> >> >>>> _<br>
>> >> >>>> >>___<br>
>> >> >>>> >>_<br>
>> >> >>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> >> Unsubscribe:<br>
>> >> >>>> >><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> >><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>
>> >> >>>> ><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> _______________________________________________________________________<br>
>> >> >>>> ___<br>
>> >> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> Unsubscribe: OpenStack-dev-<br>
>> >> >>>> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>><br>
>> >> >>><br>
>> >><br>
>> >><br>
>> >>>_________________________________________________________________________<br>
>> >> >>>_<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>
>> >> >>480.807.8189 480.807.8189<br>
>> >> >><a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
>> >> >><br>
>> >> >>Join the conversation<br>
>> >> >><br>
>> >> >>at Limelight Connect<br>
>> >> >><br>
>> >> >>--<br>
>> >> >>The information in this message may be confidential. It is intended<br>
>> >> >>solely<br>
>> >> >>for<br>
>> >> >>the addressee(s). If you are not the intended recipient, any<br>
>> >> disclosure,<br>
>> >> >>copying or distribution of the message, or any action or omission<br>
>> taken<br>
>> >> >>by<br>
>> >> >>you<br>
>> >> >>in reliance on it, is prohibited and may be unlawful. Please<br>
>> >> immediately<br>
>> >> >>contact the sender if you have received this message in error.<br>
>> >> >><br>
>> >> >><br>
>> >><br>
>> >><br>
>> >>__________________________________________________________________________<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>
>> >> Stephen Hindle - Senior Systems Engineer<br>
>> >> 480.807.8189 480.807.8189<br>
>> >> <a href="http://www.limelight.com" rel="noreferrer" target="_blank">www.limelight.com</a> Delivering Faster Better<br>
>> >><br>
>> >> Join the conversation<br>
>> >><br>
>> >> at Limelight Connect<br>
>> >><br>
>> >> --<br>
>> >> The information in this message may be confidential. It is intended<br>
>> >> solely<br>
>> >> for<br>
>> >> the addressee(s). If you are not the intended recipient, any<br>
>> disclosure,<br>
>> >> copying or distribution of the message, or any action or omission<br>
>> taken by<br>
>> >> you<br>
>> >> in reliance on it, is prohibited and may be unlawful. Please<br>
>> immediately<br>
>> >> contact the sender if you have received this message in error.<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 28<br>
>> >> Date: Mon, 4 Jul 2016 16:02:53 +0800<br>
>> >> From: <a href="mailto:hu.zhijiang@zte.com.cn">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">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka<br>
>> >> requirementssupported by CentOS<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:OF685C0E9F.8AD230D6-ON48257FE6.002BD37A-48257FE6.002C2309@zte.com.cn">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<br>
>> 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">hguemar@fedoraproject.org</a>><br>
>> >> ???: "OpenStack Development Mailing List (not for usage<br>
>> >> questions)" <<a href="mailto:openstack-dev@lists.openstack.org">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">huzhijiang@gmail.com</a>>:<br>
>> >> > Pip Package Name Supported By Centos CentOS Name Repo Name<br>
>> >> ><br>
>> >><br>
>> >><br>
>> ======================================================================================================================<br>
>> >> > ansible yes<br>
>> >> > ansible1.9.noarch epel<br>
>> >> > docker-py yes<br>
>> >> > python-docker-py.noarch extras<br>
>> >> > gitdb yes<br>
>> >> > python-gitdb.x86_64 epel<br>
>> >> > GitPython yes<br>
>> >> > GitPython.noarch epel<br>
>> >> > oslo.config yes<br>
>> >> > python2-oslo-config.noarch centos-openstack-mitaka<br>
>> >> > pbr yes<br>
>> >> > python-pbr.noarch epel<br>
>> >> > setuptools yes<br>
>> >> > python-setuptools.noarch base<br>
>> >> > six yes<br>
>> >> > python-six.noarch base<br>
>> >> > pycrypto yes<br>
>> >> > python2-crypto epel<br>
>> >> > graphviz no<br>
>> >> > Jinja2 no (Note: Jinja2 2.7.2 will be installed as<br>
>> >> > dependency by ansible)<br>
>> >> ><br>
>> >><br>
>> >> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> >> It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> >> updates to fit OpenStack requirements.<br>
>> >><br>
>> >> Actually, all the dependency above but ansible, docker and git python<br>
>> >> modules are in CentOS Cloud SIG repositories.<br>
>> >> If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> >> dependencies in our repositories.<br>
>> >><br>
>> >><br>
>> >> ><br>
>> >> > As above table shows, only two (graphviz and Jinja2) are not<br>
>> supported<br>
>> >> > by centos currently. As those not supported packages are definitly<br>
>> 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<br>
>> 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<br>
>> 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>,<br>
>> 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<br>
>> 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,<br>
>> 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>
>> __________________________________________________________________________<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>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> >> --------------------------------------------------------<br>
>> >> ZTE Information Security Notice: The information contained in this mail<br>
>> >> (and any attachment transmitted herewith) is privileged and<br>
>> confidential<br>
>> >> and is intended for the exclusive use of the addressee(s). If you are<br>
>> not<br>
>> >> an intended recipient, any disclosure, reproduction, distribution or<br>
>> other<br>
>> >> dissemination or use of the information contained is strictly<br>
>> prohibited.<br>
>> >> If you have received this mail in error, please delete it and notify us<br>
>> >> immediately.<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/5317a4dc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/5317a4dc/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 29<br>
>> >> Date: Mon, 4 Jul 2016 16:36:30 +0800<br>
>> >> From: Gerard Braad <<a href="mailto:me@gbraad.nl">me@gbraad.nl</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [daisycloud-core] [kolla] Kolla Mitaka<br>
>> >> requirementssupported by CentOS<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:CAGrH30XrpdS2D8UvPdcSMfMdJM1ExsKysaX_f0gLa4miUyf6oQ@mail.gmail.com">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">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">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">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: [openstack-dev] ??: [probably forge email???????]Re:<br>
>> >> [daisycloud-core] Kolla Mitaka requirementssupported by CentOS<br>
>> >> Message-ID:<br>
>> >> <<br>
>> >> <a href="mailto:OFCB261F89.4C7A08C6-ON48257FE6.002EC1D3-48257FE6.002F1386@zte.com.cn">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<br>
>> 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<br>
>> repository<br>
>> >> will be a more better choise than fedora repo.<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> ???: Ha?kel <<a href="mailto:hguemar@fedoraproject.org">hguemar@fedoraproject.org</a>><br>
>> >> ???: "OpenStack Development Mailing List (not for usage<br>
>> >> questions)" <<a href="mailto:openstack-dev@lists.openstack.org">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">huzhijiang@gmail.com</a>>:<br>
>> >> > Pip Package Name Supported By Centos CentOS Name Repo Name<br>
>> >> ><br>
>> >><br>
>> >><br>
>> ======================================================================================================================<br>
>> >> > ansible yes<br>
>> >> > ansible1.9.noarch epel<br>
>> >> > docker-py yes<br>
>> >> > python-docker-py.noarch extras<br>
>> >> > gitdb yes<br>
>> >> > python-gitdb.x86_64 epel<br>
>> >> > GitPython yes<br>
>> >> > GitPython.noarch epel<br>
>> >> > oslo.config yes<br>
>> >> > python2-oslo-config.noarch centos-openstack-mitaka<br>
>> >> > pbr yes<br>
>> >> > python-pbr.noarch epel<br>
>> >> > setuptools yes<br>
>> >> > python-setuptools.noarch base<br>
>> >> > six yes<br>
>> >> > python-six.noarch base<br>
>> >> > pycrypto yes<br>
>> >> > python2-crypto epel<br>
>> >> > graphviz no<br>
>> >> > Jinja2 no (Note: Jinja2 2.7.2 will be installed as<br>
>> >> > dependency by ansible)<br>
>> >> ><br>
>> >><br>
>> >> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.<br>
>> >> It's proven very hard to prevent EPEL pushing broken updates, or push<br>
>> >> updates to fit OpenStack requirements.<br>
>> >><br>
>> >> Actually, all the dependency above but ansible, docker and git python<br>
>> >> modules are in CentOS Cloud SIG repositories.<br>
>> >> If you are interested to work w/ CentOS Cloud SIG, we can add missing<br>
>> >> dependencies in our repositories.<br>
>> >><br>
>> >><br>
>> >> ><br>
>> >> > As above table shows, only two (graphviz and Jinja2) are not<br>
>> supported<br>
>> >> > by centos currently. As those not supported packages are definitly<br>
>> 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<br>
>> 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<br>
>> 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>,<br>
>> 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<br>
>> 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,<br>
>> 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>
>> __________________________________________________________________________<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>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> >> --------------------------------------------------------<br>
>> >> ZTE Information Security Notice: The information contained in this mail<br>
>> >> (and any attachment transmitted herewith) is privileged and<br>
>> confidential<br>
>> >> and is intended for the exclusive use of the addressee(s). If you are<br>
>> not<br>
>> >> an intended recipient, any disclosure, reproduction, distribution or<br>
>> other<br>
>> >> dissemination or use of the information contained is strictly<br>
>> prohibited.<br>
>> >> If you have received this mail in error, please delete it and notify us<br>
>> >> immediately.<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a220fac9/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a220fac9/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 31<br>
>> >> Date: Mon, 4 Jul 2016 09:40:22 +0100<br>
>> >> From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
>> >> To: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">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">openstack-dev@lists.openstack.org</a>>,<br>
>> >> "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>"<br>
>> >> <<a href="mailto:openstack-operators@lists.openstack.org">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">20160704084021.GA3763@redhat.com</a>><br>
>> >> Content-Type: text/plain; charset=utf-8<br>
>> >><br>
>> >> On Sun, Jul 03, 2016 at 10:08:04AM -0500, Matt Riedemann wrote:<br>
>> >> > I want to use the gate-tempest-dsvm-neutron-full-ssh in nova since it<br>
>> >> runs<br>
>> >> > ssh validation + neutron + config drive + metadata service, which<br>
>> will<br>
>> >> test<br>
>> >> > the virtual device tagging 2.32 microversion API (added last week).<br>
>> >> ><br>
>> >> > The job has a file injection test that fails consistently which is<br>
>> >> keeping<br>
>> >> > it from being voting.<br>
>> >> ><br>
>> >> > After debugging, the problem is the files to inject are silently<br>
>> ignored<br>
>> >> > because n-cpu is configured with libvirt.inject_partition=-2 by<br>
>> default.<br>
>> >> > That disables file injection:<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> <a href="https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/faf50a747e03873c3741dac89263a80112da915a/nova/virt/libvirt/driver.py#L3030</a><br>
>> >> ><br>
>> >> > We don't even log a warning if the user requested files to inject<br>
>> and we<br>
>> >> > can't honor it. If I were a user and tried to inject files when<br>
>> >> creating a<br>
>> >> > server but they didn't show up in the guest, I'd open a support<br>
>> ticket<br>
>> >> > against my cloud provider. So I don't think a warning (that only the<br>
>> >> admin<br>
>> >> > sees) is sufficient here. This isn't something that's discoverable<br>
>> from<br>
>> >> the<br>
>> >> > API either, it's really host configuration / capability (something we<br>
>> >> still<br>
>> >> > need to tackle).<br>
>> >><br>
>> >> Won't the user provided files also get made available by the config<br>
>> drive<br>
>> >> /<br>
>> >> metadata service ? I think that's the primary reason for file<br>
>> injection<br>
>> >> not<br>
>> >> being a fatal problem. Oh that and the fact that we've wanted to kill<br>
>> it<br>
>> >> for<br>
>> >> at least 3 years now :-)<br>
>> >><br>
>> >> Regards,<br>
>> >> Daniel<br>
>> >> --<br>
>> >> |: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o-<br>
>> >> <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
>> >> |: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o-<br>
>> >> <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
>> >> |: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o-<br>
>> >> <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
>> >> |: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o-<br>
>> >> <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
>> >><br>
>> >><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 32<br>
>> >> Date: Mon, 04 Jul 2016 11:16:09 +0200<br>
>> >> From: Julien Danjou <<a href="mailto:julien@danjou.info">julien@danjou.info</a>><br>
>> >> To: Denis Makogon <<a href="mailto:lildee1991@gmail.com">lildee1991@gmail.com</a>><br>
>> >> Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">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">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<br>
>> to<br>
>> >> > backend services and it is kinda hard question to answer, but i'd<br>
>> like<br>
>> >> to<br>
>> >> > know if there are any plans to support asynchronous HTTP API client<br>
>> in<br>
>> >> the<br>
>> >> > nearest future using aiohttp [1] (PEP-3156)?<br>
>> >><br>
>> >> I don't think there is unfortunately. Most clients now relies on<br>
>> >> `requests', and unfortunately it's not async not it seems ready to be<br>
>> >> last time I checked.<br>
>> >><br>
>> >> --<br>
>> >> Julien Danjou<br>
>> >> // Free Software hacker<br>
>> >> // <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
>> >> -------------- next part --------------<br>
>> >> A non-text attachment was scrubbed...<br>
>> >> Name: signature.asc<br>
>> >> Type: application/pgp-signature<br>
>> >> Size: 800 bytes<br>
>> >> Desc: not available<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a07dc24c/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/a07dc24c/attachment-0001.pgp</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 33<br>
>> >> Date: Mon, 4 Jul 2016 11:17:40 +0200<br>
>> >> From: Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>><br>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [Fuel] - Nominate Maksim Malchuk to Fuel<br>
>> >> Library Core<br>
>> >> Message-ID:<br>
>> >> <CA+HkNVup=8XN9cRU-Te7B13G5TM8LP=c7FLWskqte=<br>
>> >> <a href="mailto:fyOBQMBg@mail.gmail.com">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">aheczko@mirantis.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >> > Although I'm not Fuel core, +1 from me to Maksim. Maksim is not only<br>
>> >> > excellent engineer but also very friendly and helpful folk.<br>
>> >> ><br>
>> >> > On Tue, Jun 28, 2016 at 12:19 PM, Georgy Kibardin <<br>
>> >> <a href="mailto:gkibardin@mirantis.com">gkibardin@mirantis.com</a>><br>
>> >> > wrote:<br>
>> >> ><br>
>> >> >> +1<br>
>> >> >><br>
>> >> >> On Tue, Jun 28, 2016 at 1:12 PM, Kyrylo Galanov <<br>
>> <a href="mailto:kgalanov@mirantis.com">kgalanov@mirantis.com</a><br>
>> >> ><br>
>> >> >> wrote:<br>
>> >> >><br>
>> >> >>> +1<br>
>> >> >>><br>
>> >> >>> On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn <<br>
>> >> >>> <a href="mailto:mmosesohn@mirantis.com">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 <<br>
>> <a href="mailto:aschultz@mirantis.com">aschultz@mirantis.com</a><br>
>> >> ><br>
>> >> >>>> wrote:<br>
>> >> >>>> > +1<br>
>> >> >>>> ><br>
>> >> >>>> > On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya <<br>
>> >> >>>> <a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>><br>
>> >> >>>> > wrote:<br>
>> >> >>>> >><br>
>> >> >>>> >> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote:<br>
>> >> >>>> >> > I am very sorry for sending without subject. I am adding<br>
>> >> subject to<br>
>> >> >>>> >> > voting and my +1<br>
>> >> >>>> >><br>
>> >> >>>> >> +1 from my side!<br>
>> >> >>>> >><br>
>> >> >>>> >> ><br>
>> >> >>>> >> > --<br>
>> >> >>>> >> > Best regards,<br>
>> >> >>>> >> > Sergii Golovatiuk,<br>
>> >> >>>> >> > Skype #golserge<br>
>> >> >>>> >> > IRC #holser<br>
>> >> >>>> >> ><br>
>> >> >>>> >> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk<br>
>> >> >>>> >> > <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a> <mailto:<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>>><br>
>> >> >>>> wrote:<br>
>> >> >>>> >> ><br>
>> >> >>>> >> > Hi,<br>
>> >> >>>> >> ><br>
>> >> >>>> >> > I would like to nominate Maksim Malchuk to Fuel-Library<br>
>> Core<br>
>> >> >>>> team.<br>
>> >> >>>> >> > He?s been doing a great job so far [0]. He?s #2 reviewer<br>
>> >> and #2<br>
>> >> >>>> >> > contributor with 28 commits for last 90 days [1][2].<br>
>> >> >>>> >> ><br>
>> >> >>>> >> > Fuelers, please vote with +1/-1 for approval/objection.<br>
>> >> Voting<br>
>> >> >>>> will<br>
>> >> >>>> >> > be open until July of 4th. This will go forward after<br>
>> >> voting is<br>
>> >> >>>> >> > closed if there are no objections.<br>
>> >> >>>> >> ><br>
>> >> >>>> >> > Overall contribution:<br>
>> >> >>>> >> > [0] <a href="http://stackalytics.com/?user_id=mmalchuk" rel="noreferrer" target="_blank">http://stackalytics.com/?user_id=mmalchuk</a><br>
>> >> >>>> >> > Fuel library contribution for last 90 days:<br>
>> >> >>>> >> > [1]<br>
>> >> >>>> >> > <<a href="http://stackalytics.com/report/contribution/fuel-library/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/fuel-library/90</a><br>
>> ><br>
>> >> >>>> <a href="http://stackalytics.com/report/contribution/fuel-library/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/fuel-library/90</a><br>
>> >> >>>> >> > <a href="http://stackalytics.com/report/users/mmalchuk" rel="noreferrer" target="_blank">http://stackalytics.com/report/users/mmalchuk</a><br>
>> >> >>>> >> > List of reviews:<br>
>> >> >>>> >> > [2]<br>
>> >> >>>> >> ><br>
>> >> >>>><br>
>> >><br>
>> <a href="https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z</a><br>
>> >> >>>> >> > --<br>
>> >> >>>> >> > Best regards,<br>
>> >> >>>> >> > Sergii Golovatiuk,<br>
>> >> >>>> >> > Skype #golserge<br>
>> >> >>>> >> > IRC #holser<br>
>> >> >>>> >> ><br>
>> >> >>>> >> ><br>
>> >> >>>> >> ><br>
>> >> >>>> >> ><br>
>> >> >>>> >> ><br>
>> >> >>>> >> ><br>
>> >> >>>><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >>>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> >> > Unsubscribe:<br>
>> >> >>>> >> ><br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> >> ><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>>> >> ><br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> >>>> >> --<br>
>> >> >>>> >> Best regards,<br>
>> >> >>>> >> Bogdan Dobrelya,<br>
>> >> >>>> >> Irc #bogdando<br>
>> >> >>>> >><br>
>> >> >>>> >><br>
>> >> >>>><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> >> Unsubscribe:<br>
>> >> >>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> >><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>> ><br>
>> >> >>>><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >>>> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> > Unsubscribe:<br>
>> >> >>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> ><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>>> ><br>
>> >> >>>><br>
>> >> >>>><br>
>> >> >>>><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>>> Unsubscribe:<br>
>> >> >>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>>><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >>> Unsubscribe:<br>
>> >> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >>><br>
>> >> >>><br>
>> >> >><br>
>> >> >><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> >> Unsubscribe:<br>
>> >> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> >><br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Adam Heczko<br>
>> >> > Security Engineer @ Mirantis Inc.<br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> __________________________________________________________________________<br>
>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >> > Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8cbfe82f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/8cbfe82f/attachment-0001.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> Message: 34<br>
>> >> Date: Mon, 4 Jul 2016 12:36:30 +0300<br>
>> >> From: Denis Makogon <<a href="mailto:lildee1991@gmail.com">lildee1991@gmail.com</a>><br>
>> >> To: Denis Makogon <<a href="mailto:lildee1991@gmail.com">lildee1991@gmail.com</a>>, "OpenStack Development<br>
>> >> Mailing List (not for usage questions)"<br>
>> >> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> >> Subject: Re: [openstack-dev] [all][Python 3.4-3.5] Async python<br>
>> >> clients<br>
>> >> Message-ID:<br>
>> >> <CALzSdtnQtzUNCjP+6u4GO=qNesD0q+KZPDZ7=<br>
>> >> <a href="mailto:QmSGcrG7oqr9A@mail.gmail.com">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">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<br>
>> compatibility to<br>
>> >> > > backend services and it is kinda hard question to answer, but i'd<br>
>> >> like to<br>
>> >> > > know if there are any plans to support asynchronous HTTP API<br>
>> 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<br>
>> to<br>
>> >> support async HTTP API during next release. I'll start work on general<br>
>> >> concept that would satisfy both 2.7 and 3.4 or greater Python versions.<br>
>> >><br>
>> >> What would be the best place to submit spec?<br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> > Julien Danjou<br>
>> >> > // Free Software hacker<br>
>> >> > // <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
>> >> ><br>
>> >><br>
>> >> Kind regards,<br>
>> >> Denys Makogon<br>
>> >> -------------- next part --------------<br>
>> >> An HTML attachment was scrubbed...<br>
>> >> URL: <<br>
>> >><br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e88a5547/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/e88a5547/attachment.html</a><br>
>> >> ><br>
>> >><br>
>> >> ------------------------------<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> OpenStack-dev mailing list<br>
>> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >><br>
>> >><br>
>> >> End of OpenStack-dev Digest, Vol 51, Issue 6<br>
>> >> ********************************************<br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<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>
>> Email:<br>
>> <a href="mailto:shinobu@linux.com">shinobu@linux.com</a><br>
>> <a href="mailto:shinobu@redhat.com">shinobu@redhat.com</a><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/51fe3162/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/51fe3162/attachment.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> End of OpenStack-dev Digest, Vol 51, Issue 9<br>
>> ********************************************<br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Email:<br>
<a href="mailto:shinobu@linux.com">shinobu@linux.com</a><br>
<a href="mailto:shinobu@redhat.com">shinobu@redhat.com</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160706/b9b697ae/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160706/b9b697ae/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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 12<br>
*********************************************<br>
</blockquote></div><br></div>