<div dir="ltr">Hi Peter,<div><br></div><div>You stated "<span style="font-size:12.8px">I wonder is it's possible to migrate between backends in different share network". From context, I assume that you meant neutron networks, since "share networks" is a logic entity in manila that groups share-servers related to a certain neutron network. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It is possible, this design follows the prior "Admin Network" design, which states that drivers should implement a way to provide an additional export location of a share in the adminstrator network where the Data Service node is running, the same network that runs the cloud nodes such as the controller. Therefore, the data service node mounts both shares in the same network with a single access IP. If the involved backend drivers do not support this, it is up to the administrator to set up such a network that would allow connectivity. Example: use a provider network that connects the administrator network (or just put the Data Service node in there) and connect it to the backend data networks (where shares are served) through routers or neutron ports.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If you really meant "share network", then you can use the migration-start API command --new-share-network and specify the share network ID you would like to change in the share model entry so it is compatible with the driver mode/share-type/availability zone of the destination host.</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div>I hope I have provided the info you need, feel free to ask if you need more information about this.</div><div><br></div><div><br></div><div><span style="font-size:12.8px">Regards,</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 21, 2016 at 11:20 AM, Wang, Peter (Xu) <span dir="ltr"><<a href="mailto:Peter.Wang13@dell.com" target="_blank">Peter.Wang13@dell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all<br>
<br>
I was trying the share migration function these days.<br>
<br>
I just succeeded in migrating a share from one backend to another (actually they are in same neutron network)<br>
My "data_node_access_ip" can access both source back-end and the destination back-end.<br>
<br>
I wonder is it's possible to migrate between backends in different share network( say, one is in VLAN1 and other is VLAN2)<br>
My questions are:<br>
1. While data_node_access_ip is a single IP, how manila data node mount the both source share and destination share with one IP?<br>
2. Even if data node have 2 IPs, can access both 2 network, but m-data (configure 1 IP in manila.conf) service cannot allow access (ro/rw) for both 2 shares respectively.<br>
<br>
If share can be migrated in different share network, can anyone point me the right direction?<br>
<br>
Thanks<br>
Peter<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.<wbr>openstack.org</a> [mailto:<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@<wbr>lists.openstack.org</a>]<br>
Sent: Friday, October 21, 2016 8:00 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: OpenStack-dev Digest, Vol 54, Issue 52<br>
<br>
Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>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/<wbr>cgi-bin/mailman/listinfo/<wbr>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.<wbr>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.<wbr>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: Endpoint structure: a free-for-all (joehuang)<br>
2. [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 21 2016<br>
(<a href="mailto:hu.zhijiang@zte.com.cn">hu.zhijiang@zte.com.cn</a>)<br>
3. Participate in a Usability Study at Barcelona: Get a free<br>
bluetooth speaker and OpenStack t-shirt for your time<br>
(Kruithof Jr, Pieter)<br>
4. What do customers want?: Six studies conducted by the<br>
OpenStack UX project on behalf of the community (Kruithof Jr, Pieter)<br>
5. Re: [heat] Rolling Upgrades (Rabi Mishra)<br>
6. [OpenStack-dev][Fuel][Plugin] (<a href="mailto:nidhi.hada@wipro.com">nidhi.hada@wipro.com</a>)<br>
7. Re: [api] [nova] microversion edge case query (Alex Xu)<br>
8. [Congress] IRC during summit (Eric K)<br>
9. Re: [neutron][calico][tempest][<wbr>gate] Help setting up DSVM<br>
gate job for networking-calico (Kevin Benton)<br>
10. Re: [vitrage][aodh] about aodh notifier to create a event<br>
alarm (Afek, Ifat (Nokia - IL))<br>
11. Re: [release][ptl] pausing releases until 1 Nov (Julien Danjou)<br>
12. Re: [glance][VMT][Security] Glance coresec reorg (Flavio Percoco)<br>
13. Re: [neutron][calico][tempest][<wbr>gate] Help setting up DSVM<br>
gate job for networking-calico (Neil Jerram)<br>
14. [Keystone][Design Session] Where to propose extensions to<br>
trusts? (Johannes Grassler)<br>
15. [daisycloud-core] Meeting minutes for IRC meeting 0800UTC<br>
Oct. 21 2016 (<a href="mailto:hu.zhijiang@zte.com.cn">hu.zhijiang@zte.com.cn</a>)<br>
16. Re: [OpenStack-dev][Fuel][Plugin] (Julia Aranovich)<br>
17. [all] Automation and self described APIs (Gilles Dubreuil)<br>
18. Re: Does it make sense to have self links to things that<br>
don't exist? (Chris Dent)<br>
19. [nova][cinder] Addressing mangled LUKS passphrases<br>
(bug#1633518) (Lee Yarwood)<br>
20. Re: Endpoint structure: a free-for-all (Chris Dent)<br>
21. Re: [all] indoor climbing break at summit? (Chris Dent)<br>
22. Re: Endpoint structure: a free-for-all (Doug Hellmann)<br>
23. Re: [api] [nova] microversion edge case query (Chris Dent)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 21 Oct 2016 02:42:14 +0000<br>
From: joehuang <<a href="mailto:joehuang@huawei.com">joehuang@huawei.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all<br>
Message-ID:<br>
<<a href="mailto:5E7A3D1BF5FD014E86E5F971CF446EFF559BC5E6@szxema505-mbx.china.huawei.com">5E7A3D1BF5FD014E86E5F971CF446<wbr>EFF559BC5E6@szxema505-mbx.<wbr>china.huawei.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
I recalled one issue during using endpoint structure in public cloud<br>
based on OpenStack.<br>
<br>
Currently each service listens on its own port, the format of the endpoint<br>
is like: service-specific ports, e.g., <a href="https://cloud.com:1234/v2" rel="noreferrer" target="_blank">https://cloud.com:1234/v2</a><br>
<br>
If the end user want to access Nova/Cinder/Neutron service endpoint<br>
directly, for example using curl or other tools, then these ports 8774, 8776, 9696 have to be<br>
exposed to the end user. Then you have to open these ports<br>
in many devices if you want to provide these services in the public cloud directly to<br>
end user. The more services are added to the public cloud, the more have to be<br>
configured in these devices for security purpose.<br>
<br>
>From public cloud point of view, the port 80 will be opened by default, but if you have<br>
to open so many non-80 ports, it brings additional work and challenge to manage these ports,<br>
especially in firewalls, anti-DDoS, etc.<br>
<br>
So I think that it would be better to use sub-domain or path to expose different<br>
services end-point.<br>
<br>
A. subdomains, e.g., <a href="https://service.cloud.com/v2" rel="noreferrer" target="_blank">https://service.cloud.com/v2</a><br>
B. paths, e.g., <a href="https://cloud.com/service/v2" rel="noreferrer" target="_blank">https://cloud.com/service/v2</a><br>
<br>
Best Regards<br>
Chaoyi Huang (joehuang)<br>
<br>
______________________________<wbr>__________<br>
From: Brian Curtin [<a href="mailto:brian@python.org">brian@python.org</a>]<br>
Sent: 19 October 2016 23:32<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] Endpoint structure: a free-for-all<br>
<br>
I'm currently facing what looks more and more like an impossible<br>
problem in determining the root of each service on a given cloud. It<br>
is apparently a free-for-all in how endpoints can be structured, and I<br>
think we're out of ways to approach it that catch all of the ways that<br>
all people can think of.<br>
<br>
In openstacksdk, we can no longer use the service catalog for<br>
determining each service's endpoints. Among other things, this is due<br>
to a combination of some versions of some services not actually being<br>
listed, and with things heading the direction of version-less services<br>
anyway. Recently we changed to using the service catalog as a pointer<br>
to where services live and then try to find the root of that service<br>
by stripping the path down and making some extra requests on startup<br>
to find what's offered. Despite a few initial snags, this now works<br>
reasonably well in a majority of cases.<br>
<br>
We have seen endpoints structured in the following ways:<br>
A. subdomains, e.g., <a href="https://service.cloud.com/v2" rel="noreferrer" target="_blank">https://service.cloud.com/v2</a><br>
B. paths, e.g., <a href="https://cloud.com/service/v2" rel="noreferrer" target="_blank">https://cloud.com/service/v2</a> (sometimes there are<br>
more paths in between the root and /service/)<br>
C. service-specific ports, e.g., <a href="https://cloud.com:1234/v2" rel="noreferrer" target="_blank">https://cloud.com:1234/v2</a><br>
D. both A and B plus ports<br>
<br>
Within all of these, we can find the root of the given service just<br>
fine. We split the path and build successively longer paths starting<br>
from the root. In the above examples, we need to hit the path just<br>
short of the /v2, so in B it actually takes two requests as we'd make<br>
one to <a href="http://cloud.com" rel="noreferrer" target="_blank">cloud.com</a> which fails, but then a second one to<br>
<a href="http://cloud.com/service" rel="noreferrer" target="_blank">cloud.com/service</a> gives us what we need.<br>
<br>
However, another case came up: the root of all endpoints is itself<br>
another service. That makes it look like this:<br>
<br>
E. <a href="https://cloud.com:9999/service/v2" rel="noreferrer" target="_blank">https://cloud.com:9999/<wbr>service/v2</a><br>
F. <a href="https://cloud.com:9999/otherservice" rel="noreferrer" target="_blank">https://cloud.com:9999/<wbr>otherservice</a><br>
<br>
In this case, <a href="https://cloud.com:9999" rel="noreferrer" target="_blank">https://cloud.com:9999</a> is keystone, so trying to get E's<br>
base by going from the root and outward will give me a versions<br>
response I can parse properly, but it points to keystone. We then end<br>
up building requests for 'service' that go to keystone endpoints and<br>
end up failing. We're doing this using itertools.accumulate on the<br>
path fragments, so you might think 'just throw it through<br>
`reversed()`' and go the other way. If we do that, we'll also get a<br>
versions response that we can parse, but it's the v2 specific info,<br>
not all available versions.<br>
<br>
So now that we can't reliably go from the left, and we definitely<br>
can't go from the right, how about the middle?<br>
<br>
This sounds ridiculous, and if it sounds familiar it's because they<br>
devise a "middle out" algorithm on the show Silicon Valley, but in<br>
most cases it'd actually work. In E above, it'd be fine. However,<br>
depending on the number of path fragments and which direction we chose<br>
to move first, we'd sometimes hit either a version-specific response<br>
or another service's response, so it's not reliable.<br>
<br>
Ultimately, I would like to know how something like this can be solved.<br>
<br>
1. Is there any reliable, functional, and accurate programmatic way to<br>
get the versions and endpoints that all services on a cloud offer?<br>
<br>
2. Are there any guidelines, rules, expectations, or other<br>
documentation on how services can be installed and their endpoints<br>
structured that are helpful to people build apps that use them, not in<br>
those trying to install and operate them? I've looked around a few<br>
times and found nothing useful. A lot of what I've found has<br>
referenced suggestions for operators setting them up behind various<br>
load balancing tools.<br>
<br>
3. If 1 and 2 won't actually help me solve this, do you have any other<br>
suggestions that will? We already go left, right, and middle of each<br>
URI, so I'm out of directions to go, and we can't go back to the<br>
service catalog.<br>
<br>
Thanks,<br>
<br>
Brian<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 21 Oct 2016 11:12:14 +0800<br>
From: <a href="mailto:hu.zhijiang@zte.com.cn">hu.zhijiang@zte.com.cn</a><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [daisycloud-core] Agenda for IRC meeting<br>
0800UTC Oct. 21 2016<br>
Message-ID:<br>
<<a href="mailto:OF5F3A0595.970F811C-ON48258053.001178BE-48258053.00118AD1@zte.com.cn">OF5F3A0595.970F811C-<wbr>ON48258053.001178BE-48258053.<wbr>00118AD1@zte.com.cn</a>><br>
Content-Type: text/plain; charset="US-ASCII"<br>
<br>
1) Roll Call<br>
2) OPNFV: Escalator Support<br>
3) OPNFV: Daisy4nfv CI Framework Progress<br>
4) Core Code Abstraction<br>
5) Newton Release Related<br>
<br>
B.R.,<br>
Zhijiang<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 21 Oct 2016 03:20:01 +0000<br>
From: "Kruithof Jr, Pieter" <<a href="mailto:pieter.kruithof.jr@intel.com">pieter.kruithof.jr@intel.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Cc: "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>>,<br>
"<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] Participate in a Usability Study at<br>
Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your<br>
time<br>
Message-ID: <<a href="mailto:60FF081C-DBD5-49A7-B624-B2F7583E6D1E@intel.com">60FF081C-DBD5-49A7-B624-<wbr>B2F7583E6D1E@intel.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Apologies for any cross-postings.<br>
<br>
<br>
Hi Folks,<br>
<br>
I wanted to send a second notice that there will be two usability studies being conducted in Barcelona with cloud operators. We had nearly a 100% show rate last summit and the results had a direct impact on the OpenStackClient. In fact, the results were shared at the OSC working session the next day.<br>
<br>
Intel is providing a Philips bluetooth speaker to show our appreciation for your time. In addition, the foundation is providing a t-shirt to each person that participates in the study. I may even give anyone suffering from jetlag a Red Bull to get them through the day.<br>
<br>
___<br>
The first study will be on Monday, October 24th and is intended to investigate the current APIs to understand any specific pain points associated with completing tasks that span projects such as quotas. This study will last 45 minutes per operator.<br>
<br>
You can schedule a time here:<br>
<br>
<a href="http://doodle.com/poll/fwfi2sfcuctxv3u8" rel="noreferrer" target="_blank">http://doodle.com/poll/<wbr>fwfi2sfcuctxv3u8</a><br>
<br>
Note that you may need to set the time zone in Doodle to Spain > Ceuta<br>
<br>
___<br>
The second study will be on Tuesday, October 25th and is intended to investigate the OpenStackClient to understand any specific pain points and opportunities associated with completing tasks with the client. This study will last 45 minutes per operator. We ran a similar study at the previous summit and the feedback from users was that it was a good opportunity to ?test drive? the client with an OSC expert in the room with them.<br>
<br>
You can schedule a time here:<br>
<br>
<a href="http://doodle.com/poll/894aqsmheaa2mv5a" rel="noreferrer" target="_blank">http://doodle.com/poll/<wbr>894aqsmheaa2mv5a</a><br>
<br>
Note that you may need to set the time zone in Doodle to Spain > Ceuta<br>
<br>
<br>
For both studies, someone with the OpenStack UX project will send you a calendar invite after you select a time(s) that are convenient for you.<br>
<br>
<br>
Thanks,<br>
<br>
<br>
Piet Kruithof<br>
PTL OpenStack UX<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0de6e75e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/0de6e75e/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 21 Oct 2016 03:20:30 +0000<br>
From: "Kruithof Jr, Pieter" <<a href="mailto:pieter.kruithof.jr@intel.com">pieter.kruithof.jr@intel.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>>,<br>
"<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>"<br>
<<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] What do customers want?: Six studies<br>
conducted by the OpenStack UX project on behalf of the community<br>
Message-ID: <<a href="mailto:E0DA5CA7-83E2-44B9-875D-7A6296614876@intel.com">E0DA5CA7-83E2-44B9-875D-<wbr>7A6296614876@intel.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Folks,<br>
<br>
The OpenStack UX project and Intel have produced three booklets for the Barcelona OpenStack Summit based on the OpenStack UX?s work over the past six months.<br>
<br>
The first is an overview of user research that was conducted on behalf of the OpenStack community including operator information needs, novice user experience for Horizon, OpenStackClient (OSC) validation and managing quotas at scale.<br>
<br>
<a href="https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/0B8h-<wbr>c0zHxYBoXzFMQWJsY09Eclk/view?<wbr>usp=sharing</a><br>
<br>
The second booklets include the OpenStack Personas and GUI Guidelines:<br>
<br>
OpenStack Personas:<br>
<a href="https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/0B8h-<wbr>c0zHxYBoMXB4UVgtdFFsaDQ/view?<wbr>usp=sharing</a><br>
<br>
OpenStack GUI Guidelines:<br>
<a href="https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/<wbr>d/0B8h-<wbr>c0zHxYBoV0tHV1l5bVpZZzg/view?<wbr>usp=sharing</a><br>
<br>
<br>
___<br>
Unfortunately, we were unable to include the results for the searchlight/horizon integration as well as cloud architect information needs. However, the presentations are posted to the OpenStack UX YouTube channel.<br>
<br>
<a href="https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw" rel="noreferrer" target="_blank">https://www.youtube.com/<wbr>channel/<wbr>UCt6h129lzcjUqLDY005aCxw</a><br>
<br>
The channel is updated regularly, so it may be worth checking from time to time.<br>
<br>
<br>
___<br>
For extra credit, my suggestion would be to read the ?State of OpenStack User Experience October 2016? which provides a succinct overview of the research that was conducted, why it matters, results, and recommendations.<br>
<br>
<a href="https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>presentation/d/<wbr>1hZYCOADJ1gXiFHT1ahwv8-<wbr>tDIQCSingu7zqSMbKFZ_Y/edit?<wbr>usp=sharing</a><br>
<br>
<br>
<br>
Thanks,<br>
<br>
Piet Kruithof<br>
PTL OpenStack UX project<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/a395ede6/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/a395ede6/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 21 Oct 2016 10:00:07 +0530<br>
From: Rabi Mishra <<a href="mailto:ramishra@redhat.com">ramishra@redhat.com</a>><br>
To: <a href="mailto:cwolfe@redhat.com">cwolfe@redhat.com</a>, "OpenStack Development Mailing List (not for<br>
usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [heat] Rolling Upgrades<br>
Message-ID:<br>
<CABJHmF7E+hZJs1YHZ-QMk8n5R+<wbr>Jxr8Xjzm=<a href="mailto:v9qTTK6TtzQed6w@mail.gmail.com">v9qTTK6TtzQed6w@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Crag on starting the thread. Few comments inline.<br>
<br>
On Fri, Oct 21, 2016 at 5:32 AM, Crag Wolfe <<a href="mailto:cwolfe@redhat.com">cwolfe@redhat.com</a>> wrote:<br>
<br>
> At Summit, folks will be discussing the rolling upgrade issue across a<br>
> couple of sessions. I personally won't be able to attend, but thought<br>
> I would share my thoughts on the subject.<br>
><br>
> To handle rolling upgrades, there are two general cases to consider:<br>
> database model changes and RPC method signature changes.<br>
><br>
> For DB Model changes (this has already been well discussed on the<br>
> mailing list, see the footnotes), let's assume for the moment we don't<br>
> want to use triggers. If we are moving data from one column/table to<br>
> another, the pattern looks like:<br>
><br>
> legacy release: write to old location<br>
> release+1: write to old and new location, read from old<br>
> release+2: write to old and new location, read from new,<br>
> provide migration utility<br>
> release+3: write to new location, read from new<br>
><br>
Not sure I understand this. Is it always about changing the table name or<br>
column name of a table?<br>
What about adding a new column to an existing table? I assume the db api<br>
implementation have to ignore the additional column values when writing to<br>
old location.<br>
<br>
<br>
> Works great! The main issue is if the duplicated old and new data<br>
> happens to be large. For a heat-specific example (one that is close to<br>
> my heart), consider moving resource/event properties data into a<br>
> separate table.<br>
><br>
> We could speed up the process by adding config variables that specify<br>
> where to read from, but that is putting a burden on the operator,<br>
> creating a risk that data is lost if the config variables are not<br>
> updated in the correct order after each full rolling restart, etc.<br>
><br>
> Which brings us back to triggers. AFAIK, only sqlalchemy+mariadb is<br>
> being used in production, so we really only have one backend we would<br>
> have to write triggers for. If the data duplication is too unpalatable<br>
> for a given migration (using the +1, +2, +3 pattern above), we may<br>
> have to wade into the less simple world of triggers.<br>
><br>
I think we can only enable the trigger during the upgrade process and then<br>
disable it.<br>
<br>
<br>
> For RPC changes, we don't have a great solution right now (looking<br>
> specifically at heat/engine/service.py). If we add a field, an older<br>
> running heat-engine will break if it receives a request from a newer<br>
> running heat-engine. For a relevant example, consider adding the<br>
> "root_id" as an argument (<br>
> <a href="https://review.openstack.org/#/c/354621/13/heat/engine/service.py" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/354621/13/heat/engine/<wbr>service.py</a> ).<br>
><br>
> Looking for the simplest solution -- if we introduce a mandatory<br>
> "future_args" arg (a dict) now to all rpc methods (perhaps provide a<br>
> decorator to do so), then we could follow this pattern post-Ocata:<br>
><br>
> legacy release: accepts the future_args param (but does nothing with it).<br>
> release+1: accept the new parameter with a default of None,<br>
> pass the value of the new parameter in future_args.<br>
> release+2: accept the new parameter, pass the value of the new parameter<br>
> in its proper placeholder, no longer in future_args.<br>
><br>
This is something similar to the one is being used by neutron for the<br>
agents,<br>
i.e consistently capturing those new/unknown arguments with keyword<br>
arguments<br>
and ignoring them on agent side; and by not enforcing newer RPC entry point<br>
versions on server side. However, this makes the rpc api less strict and<br>
not ideal.<br>
<br>
The best way would be do some kind of rpc pinning on the new engines when<br>
they send messages(new engines can receive old messages). I was also<br>
wondering<br>
if it's possible/good idea to restrict engines not to communicate with<br>
other engines<br>
only during the upgrade process.<br>
<br>
But, we don't have a way of deleting args. That's not super<br>
> awful... old args never die, they just eventually get ignored. As for<br>
> adding new api's, the pattern would be to add them in release+1, but<br>
> not call them until release+2. [If we really have a case where we need<br>
> to add and use a new api in release+1, the solution may be to have two<br>
> rpc api messaging targets in release+1, one for the previous<br>
> major.minor release and another for the major+1.0 release that has the<br>
> new api. Then, we of course we could remove outdated args in<br>
> major+1.0.]<br>
><br>
I'm not sure we ever delete args, as we make the rpc servers backward<br>
compatible.<br>
<br>
<br>
> Finally, a note about Oslo versioned objects: they don't really help<br>
> us. They work great for nova where there is just nova-conductor<br>
> reading and writing to the DB, but we have multiple heat-engines doing<br>
> that that need to be restarted in a rolling manner. See the references<br>
> below for greater detail.<br>
><br>
> --Crag<br>
><br>
> References<br>
> ----------<br>
><br>
> [openstack-dev] [Heat] Versioned objects upgrade patterns<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-</a><br>
> May/thread.html#95245<br>
><br>
> [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades:<br>
> database triggers and oslo.versionedobjects<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-</a><br>
> September/102698.html<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-</a><br>
> October/105764.html<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Regards,<br>
Rabi Misra<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/9c5274fc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/9c5274fc/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 21 Oct 2016 05:16:08 +0000<br>
From: <<a href="mailto:nidhi.hada@wipro.com">nidhi.hada@wipro.com</a>><br>
To: <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [OpenStack-dev][Fuel][Plugin]<br>
Message-ID:<br>
<<a href="mailto:SIXPR0301MB13386D15FF13B35C13865D0486D40@SIXPR0301MB1338.apcprd03.prod.outlook.com">SIXPR0301MB13386D15FF13B35C13<wbr>865D0486D40@SIXPR0301MB1338.<wbr>apcprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi All,<br>
<br>
<br>
This is regarding an info required for fuel plugin development.<br>
<br>
We are working on Fuel Cinder Plugin where we require to<br>
<br>
configure multiple 'n' number of backends of storage vendor ,<br>
<br>
in one go, from Fuel UI screen. where 'n' will be known at run time.<br>
<br>
<br>
Its like from UI, I can configure a set of fields, [field1, field2, field3]<br>
<br>
for one backend and if user ask to configure 'n' backends then same<br>
<br>
set of fields to be asked repeatedly.<br>
<br>
<br>
I have found some similar provision was planned in<br>
<br>
<a href="https://blueprints.launchpad.net/fuel/+spec/dynamic-fields" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/fuel/+spec/dynamic-fields</a><br>
<br>
<br>
But when i see implementation <a href="https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/dynamic-fields,n,z</a><br>
<br>
which implements new type as text_list and textarea_list ..<br>
<br>
which is capability to add multiple lines of text in single field..<br>
<br>
<br>
It does not look like same as aim of BP, where acceptance criteria for BP is<br>
<br>
"Enable text and textarea field types to be extended - where a plugin user is able to toggle the visibility of additional fields with +/- signs and the data provided is used by plugin"<br>
<br>
<br>
Kindly correct my understanding if its wrong, do we have capability to add a text field by pressing +/- ?<br>
<br>
What capability do we have with Fuel UI to add fields dynamically today ?<br>
<br>
<br>
I have read <a href="https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel" rel="noreferrer" target="_blank">https://openstack.nimeyo.com/<wbr>44264/openstack-dev-fuel-<wbr>interaction-between-fuel-<wbr>plugin-and-fuel</a><br>
<br>
[openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI - OpenStack Mailing List Archive<<a href="https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel" rel="noreferrer" target="_blank">https://openstack.<wbr>nimeyo.com/44264/openstack-<wbr>dev-fuel-interaction-between-<wbr>fuel-plugin-and-fuel</a>><br>
<a href="http://openstack.nimeyo.com" rel="noreferrer" target="_blank">openstack.nimeyo.com</a><br>
Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp (to add ... /<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">lists.openstack.org/cgi-bin/<wbr>mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
where suggestions are made to use restrictions to hide display components.<br>
<br>
<br>
Another suggestion is to use comma separated values.<br>
<br>
<br>
But its an year back post, do we have a better solution today ?<br>
<br>
<br>
Will be helpful if someone can suggest how do we achieve it in fuel UI.<br>
<br>
<br>
<br>
Thanks<br>
<br>
Nidhi<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. <a href="http://www.wipro.com" rel="noreferrer" target="_blank">www.wipro.com</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/f7954eeb/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/f7954eeb/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 21 Oct 2016 14:20:39 +0800<br>
From: Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@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.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query<br>
Message-ID:<br>
<<a href="mailto:CAH7mGauaFBeGt9njyBfg2Y840exN6i_3FdJS0p%2BK91yLrBAU_Q@mail.gmail.com">CAH7mGauaFBeGt9njyBfg2Y840exN<wbr>6i_3FdJS0p+K91yLrBAU_Q@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2016-10-19 0:58 GMT+08:00 Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>>:<br>
<br>
> On Oct 18, 2016, at 11:01 AM, Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>> wrote:<br>
> ><br>
> > If the requested microversion is greater than the maximum, a 404 still<br>
> > makes some sense (no mapping _now_), but a 406 could as well because it<br>
> > provides a signal that if you used a different microversion the<br>
> > situation could be different and the time represented by the<br>
> > requested microversion has conceptual awareness of its past.<br>
> ><br>
> > What do people think?<br>
> ><br>
> > I think I recall there was some discussion of this sort of thing<br>
> > with regard to some of the proxy APIs at the nova midcycle but I<br>
> > can't remember the details of the outcome.<br>
><br>
> The only way that that could happen (besides a total collapse of the<br>
> review process) is when a method is removed from the API. When that<br>
> happens, the latest version has its max set to the last microversion where<br>
> that method is supported. For microversions after that, 404 is the correct<br>
> response. For all other methods, the latest version should not have a<br>
> maximum specified.<br>
><br>
<br>
<br>
Also think 404 is right at here. If you return 406 and it is a signal that<br>
if you used a different microversion the situation could be different, the<br>
thing will become strange when we raise the acceptable min_version someday.<br>
<br>
<br>
<br>
><br>
> -- Ed Leafe<br>
><br>
><br>
><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>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/20161021/6cff826b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/6cff826b/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 21 Oct 2016 00:03:21 -0700<br>
From: Eric K <<a href="mailto:ekcs.openstack@gmail.com">ekcs.openstack@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.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [Congress] IRC during summit<br>
Message-ID: <<a href="mailto:D42F04D8.3F4BA%25ekcs.openstack@gmail.com">D42F04D8.3F4BA%ekcs.<wbr>openstack@gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi all!<br>
<br>
To help us connect and coordinate during the upcoming summit, those who are<br>
interested can try IRCcloud (<a href="https://www.irccloud.com" rel="noreferrer" target="_blank">https://www.irccloud.com</a> ; suggested by aimeeu)<br>
to communicate over the #congress channel. The service acts as an IRC<br>
bouncer to keep your nick connected and send push notifications to the<br>
mobile app. I just tried it out and it works pretty well.<br>
<br>
To be notified of all messages on the channel, set your mobile app to<br>
?Notify on all messages? (under display options). To be notified only of<br>
messages that mention your nick, just keep the default settings.<br>
<br>
See you all at the summit soon!<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/91e6e835/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/91e6e835/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Fri, 21 Oct 2016 00:05:27 -0700<br>
From: Kevin Benton <kevin@benton.pub><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][calico][tempest][<wbr>gate] Help<br>
setting up DSVM gate job for networking-calico<br>
Message-ID:<br>
<CAO_F6JM9efO-=<a href="mailto:nDb%2BfOzYCg0ogDOL_D1_9XCPmaSr39Ombk4Yg@mail.gmail.com">nDb+<wbr>fOzYCg0ogDOL_D1_<wbr>9XCPmaSr39Ombk4Yg@mail.gmail.<wbr>com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Left a comment on your patch. Looks like you have tempest disabled in your<br>
devstack settings file.<br>
<br>
On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram <<a href="mailto:neil@tigera.io">neil@tigera.io</a>> wrote:<br>
<br>
> I'm trying to set up a dsvm gate job for networking-calico [1] - which I<br>
> think means<br>
> - using DevStack to set up a single combined controller/compute node, with<br>
> networking-calico settings and plugin [2]<br>
> - using Tempest to run some tests on that; ideally including some<br>
> networking-related tests :-)<br>
><br>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because<br>
> of something to do with credentials, and that also seem unrelated to<br>
> networking, and I'm not sure if any networking-related tests are running.<br>
><br>
> I've tried comparing against the similar job for networking-ovn [5][6].<br>
> Before the point where Tempest starts reporting success/failure of<br>
> individual tests, the only notable difference I see is that the<br>
> networking-calico output has:<br>
><br>
> sed: can't read /opt/stack/new/tempest/etc/<wbr>tempest.conf: No such file or<br>
> directory<br>
> Running tempest with a custom regex filter<br>
> all create: /opt/stack/new/tempest/.tox/<wbr>tempest<br>
> all installdeps: setuptools, -r/opt/stack/new/tempest/<wbr>requirements.txt<br>
> all develop-inst: /opt/stack/new/tempest<br>
><br>
> where the networking-ovn output only has:<br>
><br>
> Running tempest with a custom regex filter<br>
> all develop-inst-noop: /opt/stack/new/tempest<br>
><br>
> Is that significant?<br>
><br>
> Then the next, very obvious, difference is that the networking-calico<br>
> output seems to have the results of individual tests all jumbled up - like<br>
> output from multiple threads without a lock:<br>
><br>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}<br>
> ${OS_TEST_PATH:-./tempest/<wbr>test_discover} --load-list /tmp/tmpGuFAar<br>
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file<br>
> /etc/tempest/tempest.conf<br>
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1<br>
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf<br>
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6<br>
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file<br>
> /etc/tempest/tempest.conf<br>
> {0} setUpClass (tempest.api.baremetal.admin.<wbr>test_api_discovery.<wbr>TestApiDiscovery)<br>
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available<br>
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class<br>
> 'tempest.lib.exceptions.<wbr>InvalidCredentials'> raised in<br>
> AgentsAdminTestJSON.<wbr>setUpClass. Invoking tearDownClass.<br>
> {3} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodes.TestNodes) ...<br>
> SKIPPED: TestNodes skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_drivers.TestDrivers) ...<br>
> SKIPPED: TestDrivers skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports_negative.<wbr>TestPortsNegative)<br>
> ... SKIPPED: TestPortsNegative skipped as Ironic is not available<br>
> 20{3} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodestates.<wbr>TestNodeStates)<br>
> ... SKIPPED: TestNodeStates skipped as Ironic is not available<br>
> 16{0} setUpClass (tempest.api.compute.admin.<wbr>test_agents.<wbr>AgentsAdminTestJSON)<br>
> [0.000000s] ... FAILED<br>
> 2{3} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports.TestPorts) ...<br>
> SKIPPED: TestPorts skipped as Ironic is not available<br>
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_chassis.TestChassis) ... SKIPPED:<br>
> TestChassis skipped as Ironic is not available<br>
> 23:3020.41356 7-9 0931300006 INFO tempest.test [-] <class<br>
> 'tempest.lib.exceptions.<wbr>InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22<br>
> t. [i3-8aIN]l6 FOs t'30em90<p>4 IN class resFa't.O teitesmpstt<br>
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.<wbr>ecmetexalceptions.Invs<br>
> 'temNodesAdminTestJSON.<wbr>setUpCalpesidCredentitlaa.<wbr>lliss 'teb.eassxce.<br>
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn Agitgeber.<br>
> aeergaxDcdteoepesntAdtiwmionia<wbr>nnlCsN'el>sga .asrItsan.iiv<br>
><br>
> whereas the networking-ovn output looks neat:<br>
><br>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}<br>
> ${OS_TEST_PATH:-./tempest/<wbr>test_discover} --load-list /tmp/tmpl_uSDt<br>
> {0} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodestates.<wbr>TestNodeStates)<br>
> ... SKIPPED: TestNodeStates skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_api_discovery.<wbr>TestApiDiscovery)<br>
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports.TestPorts) ...<br>
> SKIPPED: TestPorts skipped as Ironic is not available<br>
> {3} setUpClass (tempest.api.baremetal.admin.<wbr>test_chassis.TestChassis) ...<br>
> SKIPPED: TestChassis skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.baremetal.admin.<wbr>test_drivers.TestDrivers) ...<br>
> SKIPPED: TestDrivers skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodes.TestNodes) ...<br>
> SKIPPED: TestNodes skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports_negative.<wbr>TestPortsNegative)<br>
> ... SKIPPED: TestPortsNegative skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.compute.admin.<wbr>test_baremetal_nodes.<wbr>BaremetalNodesAdminTestJSON)<br>
> ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_using_string_ram<br>
> [0.232261s] ... ok<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<br>
> create_flavor_verify_entry_in_<wbr>list_details [0.101537s] ... ok<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_int_id<br>
> [0.081664s] ... ok<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_none_id<br>
> [0.079674s] ... ok<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_uuid_id<br>
> [0.075899s] ... ok<br>
> {1} tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<br>
> create_list_flavor_without_<wbr>extra_data [0.409597s] ... ok<br>
><br>
> I would appreciate any help as regards what I'm doing wrong here.<br>
><br>
> Thanks,<br>
> Neil<br>
><br>
> [1] <a href="http://git.openstack.org/cgit/openstack-infra/project-" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/project-</a><br>
> config/tree/jenkins/jobs/<wbr>networking-calico.yaml<br>
> [2] <a href="http://git.openstack.org/cgit/openstack/networking-calico/" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/networking-calico/</a><br>
> tree/devstack<br>
> [3] <a href="https://review.openstack.org/#/c/339263/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/339263/</a><br>
> [4] <a href="http://logs.openstack.org/63/339263/5/experimental/gate-" rel="noreferrer" target="_blank">http://logs.openstack.org/63/<wbr>339263/5/experimental/gate-</a><br>
> tempest-dsvm-networking-<wbr>calico-nv/8d47b1c/console.html<br>
> [5] <a href="http://git.openstack.org/cgit/openstack-infra/project-" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/project-</a><br>
> config/tree/jenkins/jobs/<wbr>networking-ovn.yaml<br>
> [6] <a href="http://logs.openstack.org/16/386016/1/check/gate-tempest-" rel="noreferrer" target="_blank">http://logs.openstack.org/16/<wbr>386016/1/check/gate-tempest-</a><br>
> dsvm-networking-ovn/4e3924f/<wbr>console.html.gz<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/12558dc1/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/12558dc1/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Fri, 21 Oct 2016 07:21:51 +0000<br>
From: "Afek, Ifat (Nokia - IL)" <<a href="mailto:ifat.afek@nokia.com">ifat.afek@nokia.com</a>><br>
To: "<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a>" <<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a>>, gordon chung<br>
<<a href="mailto:gord@live.ca">gord@live.ca</a>><br>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to<br>
create a event alarm<br>
Message-ID: <<a href="mailto:AA498EFB-1739-43B4-8021-89DCEC588DC3@alcatel-lucent.com">AA498EFB-1739-43B4-8021-<wbr>89DCEC588DC3@alcatel-lucent.<wbr>com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
dwj,<br>
<br>
This would be great! Thanks for your help.<br>
<br>
Ifat.<br>
<br>
From: "<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><<wbr>mailto:<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><wbr>>"<br>
Date: Friday, 21 October 2016 at 04:14<br>
To: "Afek, Ifat (Nokia - IL)", gordon chung<br>
Cc: "OpenStack Development Mailing List (not for usage questions)"<br>
Subject: ??: Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm<br>
<br>
<br>
Hi All,<br>
<br>
I think it's clear now.<br>
We can start to implement the Aodh-message-bus-<wbr>notificationsBP. :)<br>
Thanks~<br>
<br>
BR,<br>
dwj<br>
<br>
<br>
<br>
<br>
<br>
"Afek, Ifat (Nokia - IL)" <<a href="mailto:ifat.afek@nokia.com">ifat.afek@nokia.com</a><mailto:<a href="mailto:ifat.afek@nokia.com">if<wbr>at.afek@nokia.com</a>>><br>
<br>
2016-10-21 01:23<br>
<br>
<br>
???<br>
gordon chung <<a href="mailto:gord@live.ca">gord@live.ca</a><mailto:<a href="mailto:gord@live.ca">gord@<wbr>live.ca</a>>>, "<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><<wbr>mailto:<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><wbr>>" <<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><<wbr>mailto:<a href="mailto:dong.wenjuan@zte.com.cn">dong.wenjuan@zte.com.cn</a><wbr>>><br>
??<br>
"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack<wbr>-dev@lists.openstack.org</a>>><br>
??<br>
Re: ??: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to create a event alarm<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 20/10/2016, 20:14, "gordon chung" <<a href="mailto:gord@live.ca">gord@live.ca</a><mailto:<a href="mailto:gord@live.ca">gord@<wbr>live.ca</a>>> wrote:<br>
<br>
><br>
>On 20/10/16 01:01 PM, Afek, Ifat (Nokia - IL) wrote:<br>
>> Well? long time ago I asked to add another notification topic to Aodh, and you said that you blocked it. If that?s not the case, everything is fine :-)<br>
>> Like I said before, we planned on implementing it in Newton, but unfortunately it didn?t happen. I really hope to improve the Vitrage-Aodh integration in Ocata.<br>
>><br>
>><br>
>><br>
>> Ifat.<br>
><br>
>i see. i wasn't being critical about no work but i'll be honest, i don't<br>
>remember what this is about since i was looking at other stuff so if you<br>
>have a patch/ML to refresh my memory, that'd help.<br>
><br>
>this is the only thread[1] i recall, and even then, i don't remember<br>
>much about it. :(<br>
><br>
>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-June/098074.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>June/098074.html</a><br>
><br>
>cheers,<br>
><br>
>--<br>
>gord<br>
<br>
What I recall was a few months earlier, we had a chat on ceilometer IRC channel? not sure if I can find the exact date.<br>
Anyway, I guess it doesn?t matter now. If you think the change can be done, then great.<br>
<br>
Ifat.<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/2e94d9dc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/2e94d9dc/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Fri, 21 Oct 2016 09:40:51 +0200<br>
From: Julien Danjou <<a href="mailto:julien@danjou.info">julien@danjou.info</a>><br>
To: Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>><br>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [release][ptl] pausing releases until 1<br>
Nov<br>
Message-ID: <<a href="mailto:m0lgxib14s.fsf@danjou.info">m0lgxib14s.fsf@danjou.info</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Thu, Oct 20 2016, Emilien Macchi wrote:<br>
<br>
> I take this opportunity to thank doug/dims/ttx for their hard work on<br>
> release management; they always help PTLs in a productive and<br>
> responsive way to reach the goals.<br>
> As a PTL, I always feel happy to deal with release management assisted<br>
> by such a great team, with nice tools like reno and openstack/releases<br>
> repo.<br>
<br>
Ditto.<br>
<br>
Also I'd like to emphasize how happy I become dealing with the<br>
openstack/releases repository even and especially for independent<br>
projects, where nothing peculiar has been implemented. :-)<br>
<br>
--<br>
Julien Danjou<br>
/* Free Software hacker<br>
<a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a> */<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 800 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/cb62103b/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/cb62103b/<wbr>attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Fri, 21 Oct 2016 10:07:12 +0200<br>
From: Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@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.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [glance][VMT][Security] Glance coresec<br>
reorg<br>
Message-ID: <<a href="mailto:20161021080712.lpr3xhkupwrbbvmx@redhat.com">20161021080712.<wbr>lpr3xhkupwrbbvmx@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On 20/10/16 12:33 -0700, Steve Lewis wrote:<br>
>I'm not voicing as a core here, but in the course of several cycles I have<br>
>seen Erno and Ian each providing the care and insight needed by this role<br>
>and trust them to do the job well.<br>
><br>
<br>
+1k to the above!<br>
<br>
Thank you both for stepping up for this critical task.<br>
Flavio<br>
<br>
><br>
>On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
><br>
>> On 2016-10-18 22:22:28 +0000 (+0000), Brian Rosmaita wrote:<br>
>> > Thus, the main point of this email is to propose Ian Cordasco and Erno<br>
>> > Kuvaja as new members of the Glance coresec team. They've both been<br>
>> > Glance cores for several cycles, have a broad knowledge of the software<br>
>> > and team, contribute high-quality reviews, and are conversant with good<br>
>> > security practices.<br>
>> [...]<br>
>><br>
>> Sounds good to me. From a VMT perspective, I'm just happy to see<br>
>> Glance keeping active participants with available bandwidth looking<br>
>> at prospective vulnerability reports so we can continue to churn<br>
>> through them faster and make them public sooner. Thanks for keeping<br>
>> the wheels turning!<br>
>> --<br>
>> Jeremy Stanley<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
>><br>
>><br>
><br>
><br>
>--<br>
>SteveL<br>
<br>
>_____________________________<wbr>______________________________<wbr>_______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
--<br>
@flaper87<br>
Flavio Percoco<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 847 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/131e9b81/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/131e9b81/<wbr>attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Fri, 21 Oct 2016 08:51:06 +0000<br>
From: Neil Jerram <<a href="mailto:neil@tigera.io">neil@tigera.io</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][calico][tempest][<wbr>gate] Help<br>
setting up DSVM gate job for networking-calico<br>
Message-ID:<br>
<CAMGh4hMMnCdQ1Do8x-<wbr>ohWtzJymekMkvA3UN=<a href="mailto:CMsziP0QXhJgYQ@mail.gmail.com">CMsziP0QXhJg<wbr>YQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks very much, Kevin. After removing that line that disables tempest,<br>
things are looking a lot saner [1]. There are still other detailed things<br>
wrong with the config, and failures to look at, but I think I know how to<br>
attack those now.<br>
<br>
(I also realized, from your help, that networking-calico/devstack/<wbr>settings<br>
is incorrectly confusing two things: (a) What is a minimal complete<br>
devstack configuration, to demonstrate networking-calico function? and (b)<br>
What are the changes to devstack configuration that should be made if<br>
someone decides to do 'enable_plugin networking-calico'? So I'll also see<br>
about de-confusing that.)<br>
<br>
Neil<br>
<br>
[1]<br>
<a href="http://logs.openstack.org/63/339263/6/experimental/gate-tempest-dsvm-networking-calico-nv/3639cd8/console.html" rel="noreferrer" target="_blank">http://logs.openstack.org/63/<wbr>339263/6/experimental/gate-<wbr>tempest-dsvm-networking-<wbr>calico-nv/3639cd8/console.html</a><br>
<br>
<br>
On Fri, Oct 21, 2016 at 8:06 AM Kevin Benton <kevin@benton.pub> wrote:<br>
<br>
> Left a comment on your patch. Looks like you have tempest disabled in your<br>
> devstack settings file.<br>
><br>
> On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram <<a href="mailto:neil@tigera.io">neil@tigera.io</a>> wrote:<br>
><br>
> I'm trying to set up a dsvm gate job for networking-calico [1] - which I<br>
> think means<br>
> - using DevStack to set up a single combined controller/compute node, with<br>
> networking-calico settings and plugin [2]<br>
> - using Tempest to run some tests on that; ideally including some<br>
> networking-related tests :-)<br>
><br>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because<br>
> of something to do with credentials, and that also seem unrelated to<br>
> networking, and I'm not sure if any networking-related tests are running.<br>
><br>
> I've tried comparing against the similar job for networking-ovn [5][6].<br>
> Before the point where Tempest starts reporting success/failure of<br>
> individual tests, the only notable difference I see is that the<br>
> networking-calico output has:<br>
><br>
> sed: can't read /opt/stack/new/tempest/etc/<wbr>tempest.conf: No such file or<br>
> directory<br>
> Running tempest with a custom regex filter<br>
> all create: /opt/stack/new/tempest/.tox/<wbr>tempest<br>
> all installdeps: setuptools, -r/opt/stack/new/tempest/<wbr>requirements.txt<br>
> all develop-inst: /opt/stack/new/tempest<br>
><br>
> where the networking-ovn output only has:<br>
><br>
> Running tempest with a custom regex filter<br>
> all develop-inst-noop: /opt/stack/new/tempest<br>
><br>
> Is that significant?<br>
><br>
> Then the next, very obvious, difference is that the networking-calico<br>
> output seems to have the results of individual tests all jumbled up - like<br>
> output from multiple threads without a lock:<br>
><br>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}<br>
> ${OS_TEST_PATH:-./tempest/<wbr>test_discover} --load-list /tmp/tmpGuFAar<br>
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file<br>
> /etc/tempest/tempest.conf<br>
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1<br>
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf<br>
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6<br>
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file<br>
> /etc/tempest/tempest.conf<br>
> {0} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_api_discovery.<wbr>TestApiDiscovery) ...<br>
> SKIPPED: TestApiDiscovery skipped as Ironic is not available<br>
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-] <class<br>
> 'tempest.lib.exceptions.<wbr>InvalidCredentials'> raised in<br>
> AgentsAdminTestJSON.<wbr>setUpClass. Invoking tearDownClass.<br>
> {3} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodes.TestNodes) ...<br>
> SKIPPED: TestNodes skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_drivers.TestDrivers) ...<br>
> SKIPPED: TestDrivers skipped as Ironic is not available<br>
> {2} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_ports_negative.<wbr>TestPortsNegative) ...<br>
> SKIPPED: TestPortsNegative skipped as Ironic is not available<br>
> 20{3} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_nodestates.<wbr>TestNodeStates) ... SKIPPED:<br>
> TestNodeStates skipped as Ironic is not available<br>
> 16{0} setUpClass<br>
> (tempest.api.compute.admin.<wbr>test_agents.<wbr>AgentsAdminTestJSON) [0.000000s] ...<br>
> FAILED<br>
> 2{3} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports.TestPorts) ...<br>
> SKIPPED: TestPorts skipped as Ironic is not available<br>
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_chassis.TestChassis) ... SKIPPED:<br>
> TestChassis skipped as Ironic is not available<br>
> 23:3020.41356 7-9 0931300006 INFO tempest.test [-] <class<br>
> 'tempest.lib.exceptions.<wbr>InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22<br>
> t. [i3-8aIN]l6 FOs t'30em90<p>4 IN class resFa't.O teitesmpstt<br>
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.<wbr>ecmetexalceptions.Invs<br>
> 'temNodesAdminTestJSON.<wbr>setUpCalpesidCredentitlaa.<wbr>lliss 'teb.eassxce.<br>
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn<br>
> Agitgeber.<wbr>aeergaxDcdteoepesntAdtiwmionia<wbr>nnlCsN'el>sga .asrItsan.iiv<br>
><br>
> whereas the networking-ovn output looks neat:<br>
><br>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}<br>
> ${OS_TEST_PATH:-./tempest/<wbr>test_discover} --load-list /tmp/tmpl_uSDt<br>
> {0} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_nodestates.<wbr>TestNodeStates) ... SKIPPED:<br>
> TestNodeStates skipped as Ironic is not available<br>
> {2} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_api_discovery.<wbr>TestApiDiscovery) ...<br>
> SKIPPED: TestApiDiscovery skipped as Ironic is not available<br>
> {2} setUpClass (tempest.api.baremetal.admin.<wbr>test_ports.TestPorts) ...<br>
> SKIPPED: TestPorts skipped as Ironic is not available<br>
> {3} setUpClass (tempest.api.baremetal.admin.<wbr>test_chassis.TestChassis) ...<br>
> SKIPPED: TestChassis skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.baremetal.admin.<wbr>test_drivers.TestDrivers) ...<br>
> SKIPPED: TestDrivers skipped as Ironic is not available<br>
> {1} setUpClass (tempest.api.baremetal.admin.<wbr>test_nodes.TestNodes) ...<br>
> SKIPPED: TestNodes skipped as Ironic is not available<br>
> {1} setUpClass<br>
> (tempest.api.baremetal.admin.<wbr>test_ports_negative.<wbr>TestPortsNegative) ...<br>
> SKIPPED: TestPortsNegative skipped as Ironic is not available<br>
> {1} setUpClass<br>
> (tempest.api.compute.admin.<wbr>test_baremetal_nodes.<wbr>BaremetalNodesAdminTestJSON)<br>
> ... SKIPPED: BaremetalNodesAdminTestJSON skipped as Ironic is not available<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_using_string_ram<br>
> [0.232261s] ... ok<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_verify_entry_in_<wbr>list_details<br>
> [0.101537s] ... ok<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_int_id<br>
> [0.081664s] ... ok<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_none_id<br>
> [0.079674s] ... ok<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_flavor_with_uuid_id<br>
> [0.075899s] ... ok<br>
> {1}<br>
> tempest.api.compute.admin.<wbr>test_flavors.<wbr>FlavorsAdminTestJSON.test_<wbr>create_list_flavor_without_<wbr>extra_data<br>
> [0.409597s] ... ok<br>
><br>
> I would appreciate any help as regards what I'm doing wrong here.<br>
><br>
> Thanks,<br>
> Neil<br>
><br>
> [1]<br>
> <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-calico.yaml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/project-<wbr>config/tree/jenkins/jobs/<wbr>networking-calico.yaml</a><br>
> [2]<br>
> <a href="http://git.openstack.org/cgit/openstack/networking-calico/tree/devstack" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/networking-calico/<wbr>tree/devstack</a><br>
> [3] <a href="https://review.openstack.org/#/c/339263/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/339263/</a><br>
> [4]<br>
> <a href="http://logs.openstack.org/63/339263/5/experimental/gate-tempest-dsvm-networking-calico-nv/8d47b1c/console.html" rel="noreferrer" target="_blank">http://logs.openstack.org/63/<wbr>339263/5/experimental/gate-<wbr>tempest-dsvm-networking-<wbr>calico-nv/8d47b1c/console.html</a><br>
> [5]<br>
> <a href="http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/networking-ovn.yaml" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack-infra/project-<wbr>config/tree/jenkins/jobs/<wbr>networking-ovn.yaml</a><br>
> [6]<br>
> <a href="http://logs.openstack.org/16/386016/1/check/gate-tempest-dsvm-networking-ovn/4e3924f/console.html.gz" rel="noreferrer" target="_blank">http://logs.openstack.org/16/<wbr>386016/1/check/gate-tempest-<wbr>dsvm-networking-ovn/4e3924f/<wbr>console.html.gz</a><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>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/20161021/0610e6ce/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/0610e6ce/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Fri, 21 Oct 2016 11:01:53 +0200<br>
From: Johannes Grassler <<a href="mailto:jgrassler@suse.de">jgrassler@suse.de</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: [openstack-dev] [Keystone][Design Session] Where to propose<br>
extensions to trusts?<br>
Message-ID: <<a href="mailto:41b5666f-3c09-eb8d-537e-5d56fafaefeb@suse.de">41b5666f-3c09-eb8d-537e-<wbr>5d56fafaefeb@suse.de</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hello,<br>
<br>
I've got a last minute proposal, or rather two of them for the Keystone side of<br>
the design sessions in Barcelona. I guess it's something that would fit the<br>
Authorization work session on Friday (09:00-09:40) but I'm not sure I can<br>
simply add it on the Etherpad. Also, I may not able to attend the session in<br>
person since I'll need to join the Barbican session in the same time slot as<br>
well[0], so I'd appreciate an alternative venue if that's possible.<br>
<br>
Hence I'll put them forth here for now:<br>
<br>
1. Scope extensions for trusts<br>
==============================<br>
<br>
Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to<br>
grant their service users or dedicated trustee users limited rights for various<br>
purposes, such as deferred operations on behalf of the user or providing access to<br>
certificate containers. These trusts can only be limited to a set of roles in a<br>
given project right now. The Admin guide mentions an endpoint limitation on top of<br>
that, but I haven't found any code in Keystone for handling that. I played with it<br>
a bit and found that every keyword argument Keystone doesn't know what to do<br>
with ends up in the trust table's `extra` column, but there's no code for doing<br>
anything with it as far as I can tell. It would be a useful thing, though and<br>
implementing it goes hand in hand with my proposal: I'd like to see an ability<br>
to scope trusts to:<br>
<br>
1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL and nothing else")<br>
2) A fixed path (i.e. "This trust may only access /v1/secrets/238ca94d-6115-<wbr>4fe6-b41f-c445eeb47df8)<br>
3) A fixed URL (i.e. "This trust may only access<br>
<a href="http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8" rel="noreferrer" target="_blank">http://192.168.123.20:9311/v1/<wbr>secrets/238ca94d-6115-4fe6-<wbr>b41f-c445eeb47df8</a>)<br>
<br>
The main thing I'm currently interested in is whether this is feasible. If so,<br>
I'd be happy to work on a blueprint and implementation. I believe this is<br>
really important to allow services and users to limit trusts to exactly the<br>
access level needed and not a bit more.<br>
<br>
<br>
2. Lightweight trusts<br>
=====================<br>
<br>
When Keystone trusts are created the current practice is to either<br>
<br>
1) Delegate the trust to a service user using the trust (example: Heat)<br>
2) Create a dedicated trustee user for delegating the trust to (example:<br>
Magnum)<br>
<br>
(1) is fine as far as I'm concerned, but I think (2) could do with some<br>
improvement. The dedicated trustee user will have a user name and password that<br>
needs to be used to authenticate as that user (along with a trust ID to consume<br>
the trust). I'd rather see a long-lived trust token scoped to the trust that<br>
can be extended upon expiry for that purpose. Just like a regular token, in<br>
other words. For the following reasons:<br>
<br>
1) Everybody who creates such a user will have different idea of a secure<br>
password length. A token is generated by keystone in a centralized manner<br>
and always of a sufficient length to make for a secure secret.<br>
2) It requires third party software that may need to authenticate as the<br>
trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver<br>
(used by Magnum). Most such software should be able to handle an auth<br>
token, on the other hand.<br>
3) There is less cleanup required after the trust has served its purpose:<br>
only the trust needs to be deleted at that point, but no trustee user.<br>
<br>
Comments on these two proposals (and advice on a suitable forum for discussing<br>
them at the summit) would be greatly appreciated. Thank you!<br>
<br>
Cheers,<br>
<br>
Johannes<br>
<br>
<br>
Footnotes:<br>
<br>
[0] In a pinch I could probably ask a colleague to stand in for me, but I'd<br>
prefer a solution where I can be present for both discussions.<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>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Fri, 21 Oct 2016 17:08:57 +0800<br>
From: <a href="mailto:hu.zhijiang@zte.com.cn">hu.zhijiang@zte.com.cn</a><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [daisycloud-core] Meeting minutes for IRC<br>
meeting 0800UTC Oct. 21 2016<br>
Message-ID:<br>
<<a href="mailto:OFDF353D09.BB96A698-ON48258053.00321B98-48258053.00323315@zte.com.cn">OFDF353D09.BB96A698-<wbr>ON48258053.00321B98-48258053.<wbr>00323315@zte.com.cn</a>><br>
Content-Type: text/plain; charset="US-ASCII"<br>
<br>
Minutes:<br>
<a href="http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/meetings/daisycloud/2016/<wbr>daisycloud.2016-10-21-07.59.<wbr>html</a><br>
<br>
Minutes (text):<br>
<a href="http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.txt" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/meetings/daisycloud/2016/<wbr>daisycloud.2016-10-21-07.59.<wbr>txt</a><br>
<br>
Log:<br>
<a href="http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/meetings/daisycloud/2016/<wbr>daisycloud.2016-10-21-07.59.<wbr>log.html</a><br>
<br>
<br>
<br>
B.R.,<br>
Zhijiang<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Fri, 21 Oct 2016 09:19:40 +0000<br>
From: Julia Aranovich <<a href="mailto:jkirnosova@mirantis.com">jkirnosova@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.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [OpenStack-dev][Fuel][Plugin]<br>
Message-ID:<br>
<<a href="mailto:CAMfgBLVa61Gz4Rtzu%2BF4PVOWby1gQdAgqmSFpJmPpGpvRqB61A@mail.gmail.com">CAMfgBLVa61Gz4Rtzu+<wbr>F4PVOWby1gQdAgqmSFpJmPpGpvRqB6<wbr>1A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Nidhi,<br>
<br>
This implemented <a href="https://blueprints.launchpad.net/fuel/+spec/dynamic-fields" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/fuel/+spec/dynamic-fields</a><br>
blueprint provided an ability to use "text_list" and "textarea_list" UI<br>
control types.<br>
They are suitable for settings where the value is a list of strings.<br>
These controls represent on UI a list of single or multiline text inputs<br>
with +/- buttons to add/remove an additional element:<br>
<br>
My Setting value1 +/-<br>
value2 +/-<br>
value3 +/-<br>
(the result value for the setting "My Setting" is ['value1', 'value2',<br>
'value3']).<br>
<br>
<br>
If I understand your case properly, you need something like dynamic groups<br>
of inputs of different type.<br>
This is still not supported by Fuel UI. The implementation does not look<br>
simple, it requires changing of data structure in settings yaml, adding a<br>
new level of nesting. There is a need to think thoroughly about the<br>
details: how to organize such a setting yaml structure, how to declare a<br>
set of inputs in such a group, how inputs should be aligned in the group<br>
(horizontally/vertically), etc.<br>
<br>
For now, I would suggest the following ways of how to organize your plugin<br>
settings:<br>
<br>
1) use text_list/textarea_list controls for each field from a group that<br>
represents storage backend configuration:<br>
<br>
Field1 value_for_backend_1 +/-<br>
value_for_backend_2 +/-<br>
value_for_backend_3 +/-<br>
<br>
Field2 value_for_backend_1 +/-<br>
value_for_backend_2 +/-<br>
value_for_backend_3 +/-<br>
<br>
Field3 value_for_backend_1 +/-<br>
value_for_backend_2 +/-<br>
value_for_backend_3 +/-<br>
<br>
2) use text_list/textarea_list controls to configure a list of storage<br>
backends by declaring their settings as a single comma-separated string:<br>
<br>
Backends Settings comma_separated_settings_for_<wbr>backend_1 +/-<br>
comma_separated_settings_for_<wbr>backend_2 +/-<br>
comma_separated_settings_for_<wbr>backend_3 +/-<br>
<br>
>From my point of view, the first version looks more clear. Will it<br>
suit your case, Nidhi?<br>
<br>
<br>
Best regards,<br>
Julia<br>
<br>
On Fri, Oct 21, 2016 at 8:17 AM <<a href="mailto:nidhi.hada@wipro.com">nidhi.hada@wipro.com</a>> wrote:<br>
<br>
> Hi All,<br>
><br>
><br>
> This is regarding an info required for fuel plugin development.<br>
><br>
> We are working on Fuel Cinder Plugin where we require to<br>
><br>
> configure multiple 'n' number of backends of storage vendor ,<br>
><br>
> in one go, from Fuel UI screen. where 'n' will be known at run time.<br>
><br>
><br>
> Its like from UI, I can configure a set of fields, [field1, field2,<br>
> field3]<br>
><br>
> for one backend and if user ask to configure 'n' backends then same<br>
><br>
> set of fields to be asked repeatedly.<br>
><br>
><br>
> I have found some similar provision was planned in<br>
><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/dynamic-fields" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/fuel/+spec/dynamic-fields</a><br>
><br>
><br>
> But when i see implementation<br>
> <a href="https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/dynamic-fields,n,z</a><br>
><br>
> which implements new type as text_list and textarea_list ..<br>
><br>
> which is capability to add multiple lines of text in single field..<br>
><br>
><br>
> It does not look like same as aim of BP, where acceptance criteria for BP<br>
> is<br>
><br>
> "Enable text and textarea field types to be extended - where a plugin user<br>
> is able to toggle the visibility of additional fields with +/- signs and<br>
> the data provided is used by plugin"<br>
><br>
><br>
> Kindly correct my understanding if its wrong, do we have capability to add<br>
> a text field by pressing +/- ?<br>
><br>
> What capability do we have with Fuel UI to add fields dynamically today ?<br>
><br>
><br>
> I have read<br>
> <a href="https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel" rel="noreferrer" target="_blank">https://openstack.nimeyo.com/<wbr>44264/openstack-dev-fuel-<wbr>interaction-between-fuel-<wbr>plugin-and-fuel</a><br>
><br>
> [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI -<br>
> OpenStack Mailing List Archive<br>
> <<a href="https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel" rel="noreferrer" target="_blank">https://openstack.nimeyo.com/<wbr>44264/openstack-dev-fuel-<wbr>interaction-between-fuel-<wbr>plugin-and-fuel</a>><br>
> <a href="http://openstack.nimeyo.com" rel="noreferrer" target="_blank">openstack.nimeyo.com</a><br>
> Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp<br>
> (to add ... /<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">lists.openstack.org/cgi-bin/<wbr>mailman/listinfo/openstack-dev</a><br>
><br>
> where suggestions are made to use restrictions to hide display components.<br>
><br>
><br>
> Another suggestion is to use comma separated values.<br>
><br>
><br>
> But its an year back post, do we have a better solution today ?<br>
><br>
><br>
> Will be helpful if someone can suggest how do we achieve it in fuel UI.<br>
><br>
><br>
><br>
> Thanks<br>
><br>
> Nidhi<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> The information contained in this electronic message and any attachments<br>
> to this message are intended for the exclusive use of the addressee(s) and<br>
> may contain proprietary, confidential or privileged information. If you are<br>
> not the intended recipient, you should not disseminate, distribute or copy<br>
> this e-mail. Please notify the sender immediately and destroy all copies of<br>
> this message and any attachments. WARNING: Computer viruses can be<br>
> transmitted via email. The recipient should check this email and any<br>
> attachments for the presence of viruses. The company accepts no liability<br>
> for any damage caused by any virus transmitted by this email.<br>
> <a href="http://www.wipro.com" rel="noreferrer" target="_blank">www.wipro.com</a><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>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/20161021/1848bace/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/1848bace/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Fri, 21 Oct 2016 20:23:12 +1100<br>
From: Gilles Dubreuil <<a href="mailto:gdubreui@redhat.com">gdubreui@redhat.com</a>><br>
To: <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [all] Automation and self described APIs<br>
Message-ID: <<a href="mailto:3ce11c50-24da-9e30-9017-92c20c57f213@redhat.com">3ce11c50-24da-9e30-9017-<wbr>92c20c57f213@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Ok, OpenStack ransom of success means the APIs request list is growing.<br>
So what's the plan for self-described APIs?<br>
Do we have a standardized solution exposing the requests' methods,<br>
parameters to other program to exploit?<br>
<br>
Sure, some OpenStack APIs advertise their interface using GET method<br>
such as {"show api version", "/v1/"}.<br>
Although consistent in the format but not available across all projects,<br>
it doesn't seem to be following a standard anyway, right?<br>
Besides and more importantly it isn't suitable to fully expose the<br>
requests interfaces.<br>
<br>
We know REST is not a standard in itself, but RESTful implementations<br>
make use of standards, such as HTTP, URI, JSON and XML [1]<br>
This have brought an excellent candidate tailored for the job, the HTTP<br>
OPTION, please see RFC2616 [2] for more details.<br>
Using such an approach would allow OpenStack APIs requests interfaces<br>
(methods, parameters and items) to be advertised to other programs.<br>
By offering a new level of API automation, almost over are the days of<br>
tedious work for every OpenStack client of creating or adding every<br>
interface corresponding code and its test code.<br>
The next generation of RESTful clients could get up to date automatically.<br>
<br>
In the meantime that happens, the only comprehensive APIs reference<br>
source I've found is <a href="http://developer.openstack.org/api-ref.html" rel="noreferrer" target="_blank">developer.openstack.org/api-<wbr>ref.html</a><br>
<<a href="http://developer.openstack.org/api-ref.html" rel="noreferrer" target="_blank">http://developer.openstack.<wbr>org/api-ref.html</a>> [2].<br>
BTW, great work Oslo Sphinx team, thank you!<br>
The API-ref allows most of APIs interfaces to be partly generated using<br>
web crawlers.<br>
Unfortunately, there a still missing projects from the reference so the<br>
rest still has to be manually produced and for the one automatically<br>
generated there are various flaws which require manual intervention.<br>
<br>
The flaws I've found:<br>
- Missing requests from API ref: Only a few (example? Ironic: heartbeat<br>
POST, "/v1/heartbeat/{node_ident}")<br>
- API Inconsistencies: For instance, the call a method for Node Vendor<br>
[3] or Driver Vendor [4] Passthru is the same, which create a conflict<br>
for REST Clients.<br>
<br>
So again, the API-ref is great and allow to cover the requests list but<br>
that's not good enough for automation where the requests capabilities<br>
need to be advertised properly and comprehensively through a standard,<br>
such as the HTTP Option. Actually the API-ref could benefit from it too<br>
and consume the latter.<br>
<br>
Cheers,<br>
Gilles<br>
<br>
PS: In an ideal world, the API is built first and the rest upon.<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Representational_state_transfer" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Representational_state_<wbr>transfer</a><br>
[2] <a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html" rel="noreferrer" target="_blank">https://www.w3.org/Protocols/<wbr>rfc2616/rfc2616-sec9.html</a><br>
[3]<br>
<a href="http://developer.openstack.org/api-ref/baremetal/?expanded=call-a-method-detail" rel="noreferrer" target="_blank">http://developer.openstack.<wbr>org/api-ref/baremetal/?<wbr>expanded=call-a-method-detail</a><br>
[4] <a href="http://developer.openstack.org/api-ref/baremetal/?expanded=id73-detail" rel="noreferrer" target="_blank">http://developer.openstack.<wbr>org/api-ref/baremetal/?<wbr>expanded=id73-detail</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/2864e0c5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/<wbr>attachments/20161021/2864e0c5/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Fri, 21 Oct 2016 12:06:46 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] Does it make sense to have self links to<br>
things that don't exist?<br>
Message-ID: <alpine.OSX.2.20.<wbr>1610211205410.52839@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Thu, 20 Oct 2016, Matt Riedemann wrote:<br>
<br>
> It's not convenient, IMO, to provide a link to something that doesn't exist.<br>
> That's just frustrating from the API user point of view.<br>
><br>
> So is this fine?<br>
> Should it be implemented?<br>
> Or should the docs say, the link might not exist?<br>
> Or should the link to the non-existent handler just be removed?<br>
<br>
If the discovery doc is for discovering stuff, it shouldn't list stuff<br>
that doesn't exist. That's pretty simple and straightforward, right?<br>
How could it be anything else?<br>
<br>
--<br>
Chris Dent ????( ? _ ??) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Fri, 21 Oct 2016 12:07:08 +0100<br>
From: Lee Yarwood <<a href="mailto:lyarwood@redhat.com">lyarwood@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: [openstack-dev] [nova][cinder] Addressing mangled LUKS<br>
passphrases (bug#1633518)<br>
Message-ID:<br>
<<a href="mailto:20161021110708.sqql3h3sddaezld7@lyarwood.usersys.redhat.com">20161021110708.<wbr>sqql3h3sddaezld7@lyarwood.<wbr>usersys.redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hello,<br>
<br>
I documented bug#1633518 [1] last week in which volumes encrypted prior<br>
to Ib563b0ea [2] used a slightly mangled passphrase instead of the<br>
original passphrase provided by the configured key manager.<br>
<br>
My first attempt at resolving this [3] prompted an alternative<br>
suggestion from mdbooth of adding the correct passphrase to the LUKS<br>
device when we detect the use of a mangled passphrase.<br>
<br>
I'm slightly wary of this option given the changing of passphrases so<br>
I'd really appreciate input from the wider Nova and Cinder groups on<br>
your preference for resolving this :<br>
<br>
1. Keep the mangled passphrase in place and attempt to use it after<br>
getting a permission denied error during luksOpen.<br>
<br>
2. Add the correct passphrase and remove the mangled passphrase from the<br>
LUKS device with luksChangeKey when we detect the use of the mangled<br>
passphrase.<br>
<br>
3. An alternative suggestion.<br>
<br>
FYI, as os-brick has now copied the encryptor classes from Nova into<br>
their own tree any fix will be cherry-picked across shortly after<br>
landing in Nova. I'm also looking into dropping these classes from Nova<br>
for Ocata so we can avoid duplicating effort like this in future.<br>
<br>
Thanks in advance,<br>
<br>
Lee<br>
<br>
[1] <a href="https://launchpad.net/bugs/1633518" rel="noreferrer" target="_blank">https://launchpad.net/bugs/<wbr>1633518</a><br>
[2] <a href="https://review.openstack.org/#/c/309614/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/309614/</a><br>
[3] <a href="https://review.openstack.org/#/c/386670/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/386670/</a><br>
--<br>
Lee Yarwood<br>
Senior Software Engineer<br>
Red Hat<br>
<br>
PGP : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Fri, 21 Oct 2016 12:22:52 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all<br>
Message-ID: <alpine.OSX.2.20.<wbr>1610211213490.52839@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Wed, 19 Oct 2016, Sean Dague wrote:<br>
<br>
> The reason we have volume, volumev2, and volumev3 is that no one actually<br>
> wants the unversioned volume endpoint. You can't do anything with it.<br>
> Everyone wants the actual endpoint that has resources.<br>
<br>
That's right, they do want the endpoint that has the resources, but<br>
do they care about asking for a version? I'm not sure. I think they<br>
just want the thing that's going to work and the version is<br>
superfluous.<br>
<br>
> We can solve this for all consumers by adding additional version field to the<br>
> catalog. This was the direction we were headed last spring before the api-ref<br>
> work took over.<br>
<br>
I'd rather not see versions in the service catalog as a reified entity<br>
because it increases the surface area of an endpoint request. I don't<br>
want to have think which version I want. Or if I do, I want it to be<br>
built into the service type. We want the service type to be the<br>
entrypoint for endpoints...<br>
<br>
In any case, just for reference, both the arch-wg and the api-wg<br>
have expressed a lot of concern about and interest in the service<br>
catalog (and the service authority idea that was bouncing around for<br>
a while too). So I agree with everyone else who is saying "yeah,<br>
it's time to make this better."<br>
<br>
There are a lot of issues:<br>
<br>
* how to deal with versions<br>
* auth handling at the top-level endpoint<br>
* service type value consistency amongst clouds<br>
* public, internal, admin, whatever endpoints (can we make it so<br>
there is one and only one?)<br>
* dynamic v static service catalogs in the face of different<br>
contexts<br>
* whatever else I'm forgetting right now because the coffee is weak<br>
but I'm sure someone else remembers<br>
<br>
--<br>
Chris Dent ????( ? _ ??) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 21 Oct 2016 12:41:16 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [all] indoor climbing break at summit?<br>
Message-ID: <alpine.OSX.2.20.<wbr>1610211239040.52839@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Tue, 18 Oct 2016, Miles Gould wrote:<br>
<br>
> Speaking of which: woo yeah! I'm totally up for this, schedule permitting.<br>
<br>
The etherpad is gathering steam, on Monday I'll use the email<br>
addresses on there and send out a plan, so anyone who wants to be<br>
notified, look there, or just show up at the gym at the chosen time.<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-climb" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/ocata-climb</a><br>
<br>
--<br>
Chris Dent ????( ? _ ??) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 21 Oct 2016 07:41:52 -0400<br>
From: Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] Endpoint structure: a free-for-all<br>
Message-ID: <<a href="mailto:99262145-B20A-4A8A-8AFF-465BF2E8E7B2@doughellmann.com">99262145-B20A-4A8A-8AFF-<wbr>465BF2E8E7B2@doughellmann.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
> On Oct 21, 2016, at 7:22 AM, Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>> wrote:<br>
><br>
>> On Wed, 19 Oct 2016, Sean Dague wrote:<br>
>><br>
>> The reason we have volume, volumev2, and volumev3 is that no one actually wants the unversioned volume endpoint. You can't do anything with it. Everyone wants the actual endpoint that has resources.<br>
><br>
> That's right, they do want the endpoint that has the resources, but<br>
> do they care about asking for a version? I'm not sure. I think they<br>
> just want the thing that's going to work and the version is<br>
> superfluous.<br>
><br>
>> We can solve this for all consumers by adding additional version field to the catalog. This was the direction we were headed last spring before the api-ref work took over.<br>
><br>
> I'd rather not see versions in the service catalog as a reified entity<br>
> because it increases the surface area of an endpoint request. I don't<br>
> want to have think which version I want. Or if I do, I want it to be<br>
> built into the service type. We want the service type to be the<br>
> entrypoint for endpoints...<br>
><br>
> In any case, just for reference, both the arch-wg and the api-wg<br>
> have expressed a lot of concern about and interest in the service<br>
> catalog (and the service authority idea that was bouncing around for<br>
> a while too). So I agree with everyone else who is saying "yeah,<br>
> it's time to make this better."<br>
<br>
This is the sort of issue that would work well as a community-wide goal. If we get a group together to resolve some of the issues you list below, they can act as guides to steer the work and help teams with the transition. If we act quickly maybe we can make enough progress to do it for Pike.<br>
<br>
Doug<br>
<br>
><br>
> There are a lot of issues:<br>
><br>
> * how to deal with versions<br>
> * auth handling at the top-level endpoint<br>
> * service type value consistency amongst clouds<br>
> * public, internal, admin, whatever endpoints (can we make it so<br>
> there is one and only one?)<br>
> * dynamic v static service catalogs in the face of different<br>
> contexts<br>
> * whatever else I'm forgetting right now because the coffee is weak<br>
> but I'm sure someone else remembers<br>
><br>
> --<br>
> Chris Dent ????( ? _ ??) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
> freenode: cdent tw: @anticdent<br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 21 Oct 2016 12:44:21 +0100 (BST)<br>
From: Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [api] [nova] microversion edge case query<br>
Message-ID: <alpine.OSX.2.20.<wbr>1610211242140.52839@shine.<wbr>local><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On Fri, 21 Oct 2016, Alex Xu wrote:<br>
<br>
> Also think 404 is right at here. If you return 406 and it is a signal that<br>
> if you used a different microversion the situation could be different, the<br>
> thing will become strange when we raise the acceptable min_version someday.<br>
<br>
Thanks, yeah, what you and Ed have said has been convincing, I've<br>
updated the code at: <a href="https://review.openstack.org/#/c/388115/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/388115/</a><br>
<br>
Jay's review of that has raised a new issue: which is should we even<br>
bother with the decorator style?<br>
<br>
<br>
--<br>
Chris Dent ????( ? _ ??) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.<wbr>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 54, Issue 52<br>
******************************<wbr>***************<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Rodrigo Barbieri<div>MSc Computer Scientist</div><div>OpenStack Manila Core Contributor</div><div>Federal University of São Carlos</div><div><br></div></div></div></div></div></div></div></div>
</div>