<div dir="ltr"><div>Topic - Fuel</div><div><br></div>Hi,<div><br></div><div>My deployment is failing beacuse of following reason :</div><div><br></div><div><span style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px">Verification failed.</span><br style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px"><span style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px">Method verify_networks. Network verification not avaliable because nodes ["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for the details</span><br></div><div><span style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px"><br></span></div><div><span style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px">anybody can help here ?</span></div><div><span style="color:rgb(185,74,72);font-family:'Segoe UI',Arial,Verdana,Tahoma,'Helvetica Neue',Helvetica,Oswald;font-size:14px;line-height:20px"><br></span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 3:42 PM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [Congress] CLI equivalent (Alex Yip)<br>
2. Re: [relmgt] PTL non-candidacy (Thomas Goirand)<br>
3. [Trove] PTL Candidacy (Craig Vyvial)<br>
4. Re: [Congress] PTL candidacy (Ramki_Krishnan@Dell.com)<br>
5. [storlets] Review requests suggestion (Eran Rom)<br>
6. Re: [cinder] LVM snapshot performance issue -- why isn't thin<br>
provisioning the default? (Duncan Thomas)<br>
7. Re: [puppet] service default value functions (Cody Herriges)<br>
8. Re: [cinder] LVM snapshot performance issue -- why isn't thin<br>
provisioning the default? (Eric Harney)<br>
9. Re: [puppet][keystone] Choose domain names with 'composite<br>
namevar' or 'meaningless name'? (Cody Herriges)<br>
10. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core<br>
(Sheena Gregson)<br>
11. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core<br>
(Dmitry Borodaenko)<br>
12. [ironic] PTL candidacy (Devananda van der Veen)<br>
13. [oslo][doc] Oslo doc sprint 9/24-9/25 (James Carey)<br>
14. [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas<br>
core team (Doug Wiegley)<br>
15. Re: [neutron][lbaas] Proposing Michael Johnson for<br>
neutron-lbaas core team (Al Miller)<br>
16. Re: [neutron][lbaas] Proposing Michael Johnson for<br>
neutron-lbaas core team (Eichberger, German)<br>
17. Re: [neutron][lbaas] Proposing Michael Johnson for<br>
neutron-lbaas core team (Phillip Toohill)<br>
18. [QA] Meeting Thursday September 17th at 9:00 UTC (GHANSHYAM MANN)<br>
19. Re: [neutron][lbaas] Proposing Michael Johnson for<br>
neutron-lbaas core team (Kyle Mestery)<br>
20. [gate] requirement conflict on Babel breaks grenade jobs<br>
(Armando M.)<br>
21. [Cue] PTL Candidacy (Vipul Sabhaya)<br>
22. Re: [Barbican] Providing service user read access to all<br>
tenant's certificates (Vijay Venkatachalam)<br>
23. Re: [Barbican] Providing service user read access to all<br>
tenant's certificates (Vijay Venkatachalam)<br>
24. Re: ceilometer code debugging (gord chung)<br>
25. Re: [Congress] PTL candidacy (Rui Chen)<br>
26. Re: how to get current memory utilization of an instance<br>
(Abhishek Talwar)<br>
27. [all][gate] grende jobs failing. (Tony Breeds)<br>
28. [i18n] PTL candidacy (Ying Chun Guo)<br>
29. [defcore] Scoring for DefCore 2016.01 Guideline (Chris Hoge)<br>
30. Re: [all][gate] grende jobs failing. (Tony Breeds)<br>
31. [Glance] PTL candidacy (Nikhil Komawar)<br>
32. Re: [neutron][lbaas] Proposing Michael Johnson for<br>
neutron-lbaas core team (Samuel Bercovici)<br>
33. Re: [Magnum] API response on k8s failure (Ton Ngo)<br>
34. [dragonflow] Low OVS version for Ubuntu (Li Ma)<br>
35. Re: [neutron] RFE process question (Li Ma)<br>
36. [oslo][oslo.config] Reloading configuration of service (mhorban)<br>
37. [neutron] Please help review this RFE (Li Ma)<br>
38. Re: [dragonflow] Low OVS version for Ubuntu (Sudipto Biswas)<br>
39. [oslo][oslo.config] Reloading configuration of service (mhorban)<br>
40. Re: [puppet] service default value functions (Yanis Guenane)<br>
41. Re: [Fuel] Bugs which we should accept in 7.0 after Hard Code<br>
Freeze (Adam Heczko)<br>
42. Re: [all][gate] grende jobs failing. (Tony Breeds)<br>
43. questions about nova compute monitors extensions (Hou Gang HG Liu)<br>
44. Re: [dragonflow] Low OVS version for Ubuntu (Gal Sagie)<br>
45. Re: [cinder] LVM snapshot performance issue -- why isn't thin<br>
provisioning the default? (Duncan Thomas)<br>
46. [magnum][ptl] Magnum PTL Candidacy (Hongbin Lu)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 16 Sep 2015 19:47:57 +0000<br>
From: Alex Yip <<a href="mailto:ayip@vmware.com">ayip@vmware.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Congress] CLI equivalent<br>
Message-ID: <<a href="mailto:1442433064831.38322@vmware.com">1442433064831.38322@vmware.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Try this:<br>
<br>
openstack congress policy row list classification error?<br>
<br>
<br>
<br>
________________________________<br>
From: Shiv Haris <sharis@Brocade.com><br>
Sent: Wednesday, September 16, 2015 12:04 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [Congress] CLI equivalent<br>
<br>
Do we have a CLI way for doing the equivalent of:<br>
<br>
$ curl -X GET localhost:1789/v1/policies/classification/tables/error/rows<br>
As described in the tutorial:<br>
<br>
<a href="https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations" rel="noreferrer" target="_blank">https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations</a><<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_congress_blob_master_doc_source_tutorial-2Dtenant-2Dsharing.rst-23listing-2Dpolicy-2Dviolations&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=djA1lFdIf0--GIJ_8gr44Q&m=m3vnP788yf3Iil8q67Kfx9ViGERr356Hb7b2KBSss9M&s=PUH7xM0t0Uy3ovTTmks2NWmKbdfY_90-EJsXIoNvSEQ&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_congress_blob_master_doc_source_tutorial-2Dtenant-2Dsharing.rst-23listing-2Dpolicy-2Dviolations&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=djA1lFdIf0--GIJ_8gr44Q&m=m3vnP788yf3Iil8q67Kfx9ViGERr356Hb7b2KBSss9M&s=PUH7xM0t0Uy3ovTTmks2NWmKbdfY_90-EJsXIoNvSEQ&e=</a>><br>
<br>
-Shiv<br>
<br>
From: Tim Hinrichs [mailto:<a href="mailto:tim@styra.com">tim@styra.com</a>]<br>
Sent: Thursday, September 10, 2015 8:41 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [Congress] Ending feature freeze<br>
<br>
Hi all,<br>
<br>
We're now finished with feature freeze. We have our first release candidate and the stable/liberty branch. So master is once again open for new features. Couple of things to note:<br>
<br>
1. Documentation. We should also look through the docs and update them. Documentation is really important. There's one doc patch not yet merged, so be sure to pull that down before editing. That patch officially deprecates a number of API calls that don't make sense for the new distributed architecture. If you find places where we don't mention the deprecation, please fix that.<br>
<br>
<a href="https://review.openstack.org/#/c/220707/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/220707/</a><br>
<br>
2. Bugs. We should still all be manually testing, looking for bugs, and fixing them. This will be true especially as other projects change their clients, which as we've seen can break our datasource drivers.<br>
<br>
All bug fixes first go into master, and then we cherry-pick to stable/liberty. Once you've patched a bug on master and it's been merged, you'll create another change for your bug-fix and push it to review. Then one of the cores will +2/+1 it (usually without needing another formal round of reviews). Here's the procedure.<br>
<br>
// pull down the latest changes for master<br>
$ git checkout master<br>
$ git pull<br>
<br>
// create a local branch for stable/liberty and switch to it<br>
$ git checkout origin/stable/liberty -b stable/liberty<br>
<br>
// cherry-pick your change from master onto the local stable/liberty<br>
// The -x records the original <sha1 from master> in the commit msg<br>
$ git cherry-pick -x <sha1 from master><br>
<br>
// Push to review and specify the stable/liberty branch.<br>
// Notice in gerrit that the branch is stable/liberty, not master<br>
$ git review stable/liberty<br>
<br>
// Once your change to stable/liberty gets merged, fetch all the new<br>
// changes.<br>
<br>
// switch to local version of stable/liberty<br>
$ git checkout stable/liberty<br>
<br>
// fetch all the new changes to all the branches<br>
$ git fetch origin<br>
<br>
// update your local branch<br>
$ git rebase origin/stable/liberty<br>
<br>
Tim<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/52432cf9/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/52432cf9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 16 Sep 2015 22:01:33 +0200<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [relmgt] PTL non-candidacy<br>
Message-ID: <<a href="mailto:55F9CA9D.2060408@debian.org">55F9CA9D.2060408@debian.org</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
On 09/16/2015 11:33 AM, Thierry Carrez wrote:<br>
> Hi everyone,<br>
><br>
> I have been handling release management for OpenStack since the<br>
> beginning of this story, well before Release Management was a program or<br>
> a project team needing a proper elected PTL. Until recently it was<br>
> largely a one-man job. But starting with this cycle, to accommodate the<br>
> Big Tent changes, we grew the team significantly, to the point where I<br>
> think it is healthy to set up a PTL rotation in the team.<br>
><br>
> I generally think it's a good thing to change the PTL for a team from<br>
> time to time. That allows different perspectives, skills and focus to be<br>
> brought to a project team. That lets you take a step back. That allows<br>
> to recognize the efforts and leadership of other members, which is<br>
> difficult if you hold on the throne. So I decided to put my foot where<br>
> my mouth is and apply those principles to my own team.<br>
><br>
> That doesn't mean I won't be handling release management for Mitaka, or<br>
> that I won't ever be Release Management PTL again -- it's just that<br>
> someone else will take the PTL hat for the next cycle, drive the effort<br>
> and be the most visible ambassador of the team.<br>
><br>
> Cheers,<br>
<br>
If we are switching from you to Doug, we'll be switching from an awesome<br>
person to another also awesome one. Thanks for all the work.<br>
<br>
Cheers,<br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 16 Sep 2015 20:03:35 +0000<br>
From: Craig Vyvial <<a href="mailto:cp16net@gmail.com">cp16net@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Trove] PTL Candidacy<br>
Message-ID:<br>
<<a href="mailto:CAOK58XR8X7MMRXgj4EKJ7ZtQfPNDxgWuqJHs6XMLpQmZhakH1A@mail.gmail.com">CAOK58XR8X7MMRXgj4EKJ7ZtQfPNDxgWuqJHs6XMLpQmZhakH1A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello,<br>
<br>
My name is Craig Vyvial and I'd like run for Mitaka Trove PTL. I've been<br>
working on Trove for about 4 years and a core member for about 2 years.<br>
Over the this time, Trove has continued to evolve and the community has<br>
grown. My passion is to help make sure that Trove continues this trend and<br>
guide Trove to be a world class database as a service for OpenStack.<br>
<br>
Trove started just provisioing a single MySQL instance and has grown to a<br>
total of 12 datastores to date with a few datastores supporting clustering.<br>
I think there are a few areas that make sense with this kind of growth that<br>
we should focus on during Mitaka.<br>
<br>
* Add CI tests for other datastores with third patry CI systems. With so<br>
many new datastores available within Trove, we need to make sure that we<br>
stabilize tests on multiple datastores.<br>
<br>
* Advance the features of Trove for all datastores.<br>
<br>
* Simplify the installation of Trove that includes install, upgrades,<br>
building guest images, and management operations.<br>
<br>
* Continue the trend of growing the trove community.<br>
<br>
As PTL of Trove, I will help the project move forward by looking to the<br>
community for input and making sure we take steps toward making OpenStack a<br>
better platform as well as Trove the ideal solution for users looking for a<br>
database as a service solution.<br>
<br>
<br>
Thanks,<br>
<br>
- Craig Vyvial<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a772ad0a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a772ad0a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 16 Sep 2015 15:09:32 -0500<br>
From: <Ramki_Krishnan@Dell.com><br>
To: <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Congress] PTL candidacy<br>
Message-ID:<br>
<<a href="mailto:DF91EBC32A031943A8B78D81D40122BC0404D4FB5E@AUSX7MCPC103.AMER.DELL.COM">DF91EBC32A031943A8B78D81D40122BC0404D4FB5E@AUSX7MCPC103.AMER.DELL.COM</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1 and looking forward to see you in Tokyo.<br>
<br>
Thanks,<br>
Ramki<br>
<br>
From: Tim Hinrichs [mailto:<a href="mailto:tim@styra.com">tim@styra.com</a>]<br>
Sent: Tuesday, September 15, 2015 1:23 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [Congress] PTL candidacy<br>
<br>
Hi all,<br>
<br>
I?m writing to announce my candidacy for Congress PTL for the Mitaka cycle. I?m excited at the prospect of continuing the development of our community, our code base, and our integrations with other projects.<br>
<br>
This past cycle has been exciting in that we saw several new, consistent contributors, who actively pushed code, submitted reviews, wrote specs, and participated in the mid-cycle meet-up. Additionally, our integration with the rest of the OpenStack ecosystem improved with our move to running tempest tests in the gate instead of manually or with our own CI. The code base matured as well, as we rounded out some of the features we added near the end of the Kilo cycle. We also began making the most significant architectural change in the project?s history, in an effort meet our high-availability and API throughput targets.<br>
<br>
I?m looking forward to the Mitaka cycle. My highest priority for the code base is completing the architectural changes that we began in Liberty. These changes are undoubtedly the right way forward for production use cases, but it is equally important that we make Congress easy to use and understand for both new developers and new end users. I also plan to further our integration with the OpenStack ecosystem by better utilizing the plugin architectures that are available (e.g. devstack and tempest). I will also work to begin (or continue) dialogues with other projects that might benefit from consuming Congress. Finally I?m excited to continue working with our newest project members, helping them toward becoming core contributors.<br>
<br>
See you all in Tokyo!<br>
Tim<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/6ed1879f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/6ed1879f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 16 Sep 2015 23:19:18 +0300<br>
From: Eran Rom <<a href="mailto:ERANR@il.ibm.com">ERANR@il.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [storlets] Review requests suggestion<br>
Message-ID:<br>
<<a href="mailto:OFAF5DC7D8.6A8D3CF1-ONC2257EC2.006F4467-C2257EC2.006FA199@il.ibm.com">OFAF5DC7D8.6A8D3CF1-ONC2257EC2.006F4467-C2257EC2.006FA199@il.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi All,<br>
I suggest that until we have functional tests in place, each commit<br>
message should specify that:<br>
(1) For a code change - the system tests were executed successfully with<br>
the change -<br>
(2) For installation related change that the installation was tested with<br>
this.<br>
<br>
I further suggest that if the commit message does not have this the<br>
reviewer can assume that the committer forgot to do these and -1<br>
Opinions?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/451c3b22/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/451c3b22/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 16 Sep 2015 23:25:18 +0300<br>
From: Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue<br>
-- why isn't thin provisioning the default?<br>
Message-ID:<br>
<CAOyZ2aGZn6a-eRUv_TmB2r4s2FD719NONvBihzS4hNEKhNC=<a href="mailto:Nw@mail.gmail.com">Nw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 16 Sep 2015 20:42, "yang, xing" <<a href="mailto:xing.yang@emc.com">xing.yang@emc.com</a>> wrote:<br>
<br>
> On 9/16/15, 1:20 PM, "Eric Harney" <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>> wrote:<br>
<br>
> >This sounds like a good idea, I'm just not sure how to structure it yet<br>
> >without creating a very confusing set of config options.<br>
><br>
> I?m thinking we could have a prefix with vendor name for this and it also<br>
> requires documentation by driver maintainers if they are using a different<br>
> config option. I proposed a topic to discuss about this at the summit.<br>
<br>
We already have per-backend config values in cinder.conf. I'm not sure how<br>
the config code will need to be structured to achieve it, but ideally I'd<br>
like a single config option that can be:<br>
<br>
(i) set in the default section if desired<br>
(in) overridden in the per driver section, and (iii) have a default set in<br>
each driver.<br>
<br>
I don't think oslo.config lets us do (I'll) yet though.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a06a65d2/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a06a65d2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 16 Sep 2015 13:35:47 -0700<br>
From: Cody Herriges <<a href="mailto:cody@puppetlabs.com">cody@puppetlabs.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Hunter Haugen<br>
<<a href="mailto:hunter@puppetlabs.com">hunter@puppetlabs.com</a>><br>
Subject: Re: [openstack-dev] [puppet] service default value functions<br>
Message-ID: <<a href="mailto:55F9D2A3.8010006@puppetlabs.com">55F9D2A3.8010006@puppetlabs.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Emilien Macchi wrote:<br>
><br>
> On 09/16/2015 12:53 PM, Alex Schultz wrote:<br>
>> Hey puppet folks,<br>
>><br>
>> Based on the meeting yesterday[0], I had proposed creating a parser<br>
>> function called is_service_default[1] to validate if a variable matched<br>
>> our agreed upon value of '<SERVICE DEFAULT>'. This got me thinking<br>
>> about how can we maybe not use the arbitrary string throughout the<br>
>> puppet that can not easily be validated. So I tested creating another<br>
>> puppet function named service_default[2] to replace the use of '<SERVICE<br>
>> DEFAULT>' throughout all the puppet modules. My tests seemed to<br>
>> indicate that you can use a parser function as parameter default for<br>
>> classes.<br>
>><br>
>> I wanted to send a note to gather comments around the second function.<br>
>> When we originally discussed what to use to designate for a service's<br>
>> default configuration, I really didn't like using an arbitrary string<br>
>> since it's hard to parse and validate. I think leveraging a function<br>
>> might be better since it is something that can be validated via tests<br>
>> and a syntax checker. Thoughts?<br>
><br>
> Let me add your attempt to make it work in puppet-cinder:<br>
> <a href="https://review.openstack.org/#/c/224277" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224277</a><br>
><br>
> I like the proposal, +1.<br>
><br>
<br>
Hunter,<br>
<br>
Do you off hand know what kind of overhead is generated by this?<br>
<br>
<br>
--<br>
Cody<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 931 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/e4c794ef/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/e4c794ef/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 16 Sep 2015 16:43:30 -0400<br>
From: Eric Harney <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue<br>
-- why isn't thin provisioning the default?<br>
Message-ID: <<a href="mailto:55F9D472.5000505@redhat.com">55F9D472.5000505@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
On 09/16/2015 04:25 PM, Duncan Thomas wrote:<br>
> On 16 Sep 2015 20:42, "yang, xing" <<a href="mailto:xing.yang@emc.com">xing.yang@emc.com</a>> wrote:<br>
><br>
>> On 9/16/15, 1:20 PM, "Eric Harney" <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>> wrote:<br>
><br>
>>> This sounds like a good idea, I'm just not sure how to structure it yet<br>
>>> without creating a very confusing set of config options.<br>
>><br>
>> I?m thinking we could have a prefix with vendor name for this and it also<br>
>> requires documentation by driver maintainers if they are using a different<br>
>> config option. I proposed a topic to discuss about this at the summit.<br>
><br>
> We already have per-backend config values in cinder.conf. I'm not sure how<br>
> the config code will need to be structured to achieve it, but ideally I'd<br>
> like a single config option that can be:<br>
><br>
> (i) set in the default section if desired<br>
> (in) overridden in the per driver section, and (iii) have a default set in<br>
> each driver.<br>
><br>
> I don't think oslo.config lets us do (I'll) yet though.<br>
><br>
<br>
I think there may be other issues to sort through to do that.<br>
Currently, at least some options set in [DEFAULT] don't apply to<br>
per-driver sections, and require you to set them in the driver section<br>
as well.<br>
<br>
If we keep that behavior (which I think is broken, personally), then<br>
trying to do option (iii) may be pretty confusing, because the deployer<br>
won't know which of the global vs. driver defaults are actually going to<br>
be applied.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 16 Sep 2015 13:58:30 -0700<br>
From: Cody Herriges <<a href="mailto:cody@puppetlabs.com">cody@puppetlabs.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [puppet][keystone] Choose domain names<br>
with 'composite namevar' or 'meaningless name'?<br>
Message-ID: <<a href="mailto:55F9D7F6.2000604@puppetlabs.com">55F9D7F6.2000604@puppetlabs.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
I wrote my first composite namevar type a few years and ago and all the<br>
magic is basically a single block of code inside the type...<br>
<br>
<a href="https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L145-L169" rel="noreferrer" target="_blank">https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L145-L169</a><br>
<br>
It basically boils down to these three things:<br>
<br>
* Pick your namevars<br>
(<a href="https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L49-L64" rel="noreferrer" target="_blank">https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L49-L64</a>)<br>
* Pick a delimiter<br>
- Personally I'd use @ here since we are talking about domains<br>
* Build your self.title_patterns method, accounting for delimited names<br>
and arbitrary names.<br>
<br>
While it looks like the README never got updated, the java_ks example<br>
supports both meaningful titles and arbitrary ones.<br>
<br>
java_ks { 'activemq_puppetca_keystore':<br>
ensure => latest,<br>
name => 'puppetca',<br>
certificate => '/etc/puppet/ssl/certs/ca.pem',<br>
target => '/etc/activemq/broker.ks',<br>
password => 'puppet',<br>
trustcacerts => true,<br>
}<br>
<br>
java_ks { 'broker.example.com:/etc/activemq/broker.ks':<br>
ensure => latest,<br>
certificate =><br>
'/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem',<br>
private_key =><br>
'/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem',<br>
password => 'puppet',<br>
}<br>
<br>
You'll notice the first being an arbitrary title and the second<br>
utilizing a ":" as a delimiter and omitting the name and target parameters.<br>
<br>
Another code example can be found in the package type.<br>
<br>
<a href="https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291" rel="noreferrer" target="_blank">https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291</a>.<br>
<br>
--<br>
Cody<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 931 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/73c3b7f1/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/73c3b7f1/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 16 Sep 2015 16:22:<a href="tel:02%20-0500" value="+35820500">02 -0500</a><br>
From: Sheena Gregson <<a href="mailto:sgregson@mirantis.com">sgregson@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Olga Gusarenko <<a href="mailto:ogusarenko@mirantis.com">ogusarenko@mirantis.com</a>><br>
Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for<br>
fuel-docs core<br>
Message-ID: <<a href="mailto:7e65f8d3e04579ba78d3c14bdea4dcb2@mail.gmail.com">7e65f8d3e04579ba78d3c14bdea4dcb2@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1 Thanks for being a great docs contributor and community member.<br>
<br>
<br>
<br>
*From:* Alexander Adamov [mailto:<a href="mailto:aadamov@mirantis.com">aadamov@mirantis.com</a>]<br>
*Sent:* Monday, September 14, 2015 5:44 AM<br>
*To:* OpenStack Development Mailing List (not for usage questions) <<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
*Cc:* Olga Gusarenko <<a href="mailto:ogusarenko@mirantis.com">ogusarenko@mirantis.com</a>><br>
*Subject:* Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for fuel-docs<br>
core<br>
<br>
<br>
<br>
+1<br>
<br>
Nice!)<br>
<br>
<br>
<br>
Alexander<br>
<br>
<br>
<br>
On Fri, Sep 11, 2015 at 8:19 PM, Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>><br>
wrote:<br>
<br>
+1<br>
<br>
Great work Olga!<br>
<br>
<br>
<br>
On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya <<a href="mailto:ipovolotskaya@mirantis.com">ipovolotskaya@mirantis.com</a>><br>
wrote:<br>
<br>
Fuelers,<br>
<br>
<br>
<br>
I'd like to nominate Olga Gusarenko for the fuel-docs-core.<br>
<br>
<br>
<br>
She has been doing great work and made a great contribution<br>
<br>
into Fuel documentation:<br>
<br>
<a href="http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs" rel="noreferrer" target="_blank">http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs</a><br>
<br>
It's high time to grant her core reviewer's rights in fuel-docs.<br>
<br>
Core reviewer approval process definition:<br>
<a href="https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess</a><br>
<br>
<br>
<br>
--<br>
<br>
Best regards,<br>
<br>
<br>
Irina<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9d63d703/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9d63d703/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 16 Sep 2015 14:28:59 -0700<br>
From: Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Olga Gusarenko <<a href="mailto:ogusarenko@mirantis.com">ogusarenko@mirantis.com</a>><br>
Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for<br>
fuel-docs core<br>
Message-ID:<br>
<<a href="mailto:CAM0pNLMoTfdds-N6mXpeeE360YopScqbgbW3e-hUhPT3oysKvA@mail.gmail.com">CAM0pNLMoTfdds-N6mXpeeE360YopScqbgbW3e-hUhPT3oysKvA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
5 days and no objections: welcome to Fuel Docs core reviewers! Keep up<br>
the great work!<br>
<br>
On Fri, Sep 11, 2015 at 11:07 AM, Irina Povolotskaya<br>
<<a href="mailto:ipovolotskaya@mirantis.com">ipovolotskaya@mirantis.com</a>> wrote:<br>
> Fuelers,<br>
><br>
> I'd like to nominate Olga Gusarenko for the fuel-docs-core.<br>
><br>
> She has been doing great work and made a great contribution<br>
> into Fuel documentation:<br>
><br>
> <a href="http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs" rel="noreferrer" target="_blank">http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs</a><br>
><br>
> It's high time to grant her core reviewer's rights in fuel-docs.<br>
><br>
> Core reviewer approval process definition:<br>
> <a href="https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess</a><br>
><br>
> --<br>
> Best regards,<br>
><br>
> Irina<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Dmitry Borodaenko<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 16 Sep 2015 21:35:51 +0000<br>
From: Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [ironic] PTL candidacy<br>
Message-ID:<br>
<<a href="mailto:CAExZKEoTHvniLyO09cesYsB9VEOg3frfo_YM_qHpQfXVJgdZkg@mail.gmail.com">CAExZKEoTHvniLyO09cesYsB9VEOg3frfo_YM_qHpQfXVJgdZkg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
<br>
( repost from https <<a href="https://review.openstack.org/223753" rel="noreferrer" target="_blank">https://review.openstack.org/223753</a>>://<br>
<<a href="https://review.openstack.org/223753" rel="noreferrer" target="_blank">https://review.openstack.org/223753</a>><a href="http://review.openstack.org" rel="noreferrer" target="_blank">review.openstack.org</a><br>
<<a href="https://review.openstack.org/223753" rel="noreferrer" target="_blank">https://review.openstack.org/223753</a>>/223753<br>
<<a href="https://review.openstack.org/223753" rel="noreferrer" target="_blank">https://review.openstack.org/223753</a>> )<br>
<br>
It's that time again, where encumbent PTLs are supposed to write about what<br>
features or changes they accomplished and what goals they have for the next<br>
cycle.<br>
<br>
I'm not going to do that this time.<br>
<br>
Even you though you may have read similar things from others (either in<br>
this or in previous cycles) I'm going to reiterate something. Contrary to<br>
being the technical lead, OpenStack requires the PTL to do a whole slew of<br>
less glamorous things (or delegate them to other people).<br>
<br>
- launchpad monkey<br>
- midcycle coordinator<br>
- release coordinator<br>
- public speaker<br>
- cross project liaison<br>
- vendor buffer<br>
- cat wrangler<br>
<br>
Historically, PTL meant "project technical lead", but as OpenStack grew, we<br>
/ the TC realized that it is more^D^D^D^Ddifferent than that, and so now<br>
the acronym is defined as "project team lead" [0]. And that is much more<br>
representative of the responsibilities a PTL has today. In short, being PTL<br>
and the lead architect for a successful/sizable project at the same time ==<br>
two full time jobs.<br>
<br>
Even before I was doing anything internal at HP, it seemed like my upstream<br>
work was never done since I was trying to be both the team and tech leads<br>
for Ironic. That said, it was also extremely rewarding to found this<br>
project and exercise my social and organizational skills in building a<br>
community around it. I could not be more satisfied with the results -- all<br>
of you make Ironic much more awesome than I could have done alone. That's<br>
the point, after all :)<br>
<br>
Last election cycle, I stepped down from the TC so that I could have more<br>
time for my roles as tech and team lead, and to focus on some internal work<br>
(yup, still three jobs). That other work, for better or for worse, took a<br>
greater tax on me than I had anticipated, and my activity upstream has<br>
suffered (sorry!). This has created room for many of the other core<br>
developers, who've been around the project almost as long as I have, to<br>
come forward and fill in the gaps I left in the project management. And<br>
that's really awesome. Thank you all.<br>
<br>
I am thrilled that more of the project responsibilities are being handled<br>
by Jim, Ruby, Chris, Lucas, and everyone else now. They are all leading<br>
different areas in their own ways. As PTLs, each would bring a different<br>
viewpoint to the project's day-to-day operations, and if they were to run,<br>
I would support all of them (even though we disagree some times). Today,<br>
there are multiple people who could run the project in my stead, and that<br>
makes me very happy.<br>
<br>
If elected, I promise to continue enabling the core team to do more without<br>
my direct involvement, to continue leading in the technical vision for the<br>
project, and liaising with vendors and operators to ensure the project<br>
matures in such a way that it meets their needs.<br>
<br>
If you believe I've done a great job as PTL and want me to continue doing<br>
what I've been doing, then please re-elect me. (*)<br>
<br>
If you'd like to see a change of pace, please don't hesitate to elect<br>
another PTL :)<br>
<br>
Thank you,<br>
Devananda<br>
<br>
(*) If you think I haven't done a great job as PTL, I invite you to tell me<br>
how you think I could do better. For the sake of the election archives,<br>
please don't reply to this email.<br>
<br>
[0]<br>
<a href="https://github.com/openstack/governance/commit/319fae1ea13775d16f865f886db0388e42cd0d1b" rel="noreferrer" target="_blank">https://github.com/openstack/governance/commit/319fae1ea13775d16f865f886db0388e42cd0d1b</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/da01d068/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/da01d068/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 16 Sep 2015 16:40:27 -0500<br>
From: James Carey <<a href="mailto:bellerophon@flyinghorsie.com">bellerophon@flyinghorsie.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [oslo][doc] Oslo doc sprint 9/24-9/25<br>
Message-ID:<br>
<CAHjMoV0vx=<a href="mailto:mEcnsJHyq29hwoAA6oq9fwdXYqVFGttVCwLEeicg@mail.gmail.com">mEcnsJHyq29hwoAA6oq9fwdXYqVFGttVCwLEeicg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
In order to improve the Oslo libraries documentation, the Oslo team is<br>
having a documentation sprint from 9/24 to 9/25.<br>
<br>
We'll kick things off at 14:00 UTC on 9/24 in the<br>
#openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].<br>
<br>
All help is appreciated. If you can help or have suggestions for<br>
areas of focus, please update the etherpad.<br>
<br>
[0] <a href="https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/dd80ed8e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/dd80ed8e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 16 Sep 2015 16:33:59 -0600<br>
From: Doug Wiegley <<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson<br>
for neutron-lbaas core team<br>
Message-ID:<br>
<<a href="mailto:FB4D40AE-3C76-4069-81D7-6593C5AFEB89@parksidesoftware.com">FB4D40AE-3C76-4069-81D7-6593C5AFEB89@parksidesoftware.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi all,<br>
<br>
As the Lieutenant of the advanced services, I nominate Michael Johnson to be a member of the neutron-lbaas core reviewer team.<br>
<br>
Review stats are in line with other cores[2], and Michael has been instrumental in both neutron-lbaas and octavia.<br>
<br>
Existing cores, please vote +1/-1 for his addition to the team (that?s Brandon, Phil, Al, and Kyle.)<br>
<br>
Thanks,<br>
doug<br>
<br>
1. <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy</a><br>
2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 16 Sep 2015 22:40:51 +0000<br>
From: Al Miller <<a href="mailto:ajmiller@ajmiller.net">ajmiller@ajmiller.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael<br>
Johnson for neutron-lbaas core team<br>
Message-ID:<br>
<EFBE70D7D09F0A4397281F770E1802DBA87A2451@uc2-exmbx15-n1.UC2.Chicago.Hostway><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1<br>
<br>
Al<br>
<br>
<br>
> -----Original Message-----<br>
> From: Doug Wiegley [mailto:<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>]<br>
> Sent: Wednesday, September 16, 2015 3:34 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for<br>
> neutron-lbaas core team<br>
><br>
> Hi all,<br>
><br>
> As the Lieutenant of the advanced services, I nominate Michael Johnson to<br>
> be a member of the neutron-lbaas core reviewer team.<br>
><br>
> Review stats are in line with other cores[2], and Michael has been<br>
> instrumental in both neutron-lbaas and octavia.<br>
><br>
> Existing cores, please vote +1/-1 for his addition to the team (that?s Brandon,<br>
> Phil, Al, and Kyle.)<br>
><br>
> Thanks,<br>
> doug<br>
><br>
> 1. <a href="http://docs.openstack.org/developer/neutron/policies/core-" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-</a><br>
> reviewers.html#core-review-hierarchy<br>
> 2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
><br>
><br>
> __________________________________________________________<br>
> ________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 16 Sep 2015 22:44:27 +0000<br>
From: "Eichberger, German" <<a href="mailto:german.eichberger@hpe.com">german.eichberger@hpe.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael<br>
Johnson for neutron-lbaas core team<br>
Message-ID: <<a href="mailto:D21F3EA2.17995%25german.eichberger@hpe.com">D21F3EA2.17995%german.eichberger@hpe.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Great news! From the Octavia end I totally support that choice?<br>
<br>
German<br>
<br>
On 9/16/15, 3:40 PM, "Al Miller" <<a href="mailto:ajmiller@ajmiller.net">ajmiller@ajmiller.net</a>> wrote:<br>
<br>
>+1<br>
><br>
>Al<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Doug Wiegley [mailto:<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>]<br>
>> Sent: Wednesday, September 16, 2015 3:34 PM<br>
>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for<br>
>> neutron-lbaas core team<br>
>><br>
>> Hi all,<br>
>><br>
>> As the Lieutenant of the advanced services, I nominate Michael Johnson<br>
>>to<br>
>> be a member of the neutron-lbaas core reviewer team.<br>
>><br>
>> Review stats are in line with other cores[2], and Michael has been<br>
>> instrumental in both neutron-lbaas and octavia.<br>
>><br>
>> Existing cores, please vote +1/-1 for his addition to the team (that?s<br>
>>Brandon,<br>
>> Phil, Al, and Kyle.)<br>
>><br>
>> Thanks,<br>
>> doug<br>
>><br>
>> 1. <a href="http://docs.openstack.org/developer/neutron/policies/core-" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-</a><br>
>> reviewers.html#core-review-hierarchy<br>
>> 2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
>><br>
>><br>
>> __________________________________________________________<br>
>> ________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-<br>
>> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 16 Sep 2015 23:03:22 +0000<br>
From: Phillip Toohill <<a href="mailto:phillip.toohill@RACKSPACE.COM">phillip.toohill@RACKSPACE.COM</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael<br>
Johnson for neutron-lbaas core team<br>
Message-ID:<br>
<<a href="mailto:45ef3cc22894430a97c42f7693fe843b@543881-IEXCH01.ror-uc.rackspace.com">45ef3cc22894430a97c42f7693fe843b@543881-IEXCH01.ror-uc.rackspace.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
+1<br>
<br>
Phillip V. Toohill III<br>
Software Developer<br>
<br>
phone: 210-312-4366<br>
mobile: 210-440-8374<br>
<br>
<br>
________________________________________<br>
From: Eichberger, German [<a href="mailto:german.eichberger@hpe.com">german.eichberger@hpe.com</a>]<br>
Sent: Wednesday, September 16, 2015 5:44 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team<br>
<br>
Great news! From the Octavia end I totally support that choice?<br>
<br>
German<br>
<br>
On 9/16/15, 3:40 PM, "Al Miller" <<a href="mailto:ajmiller@ajmiller.net">ajmiller@ajmiller.net</a>> wrote:<br>
<br>
>+1<br>
><br>
>Al<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Doug Wiegley [mailto:<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>]<br>
>> Sent: Wednesday, September 16, 2015 3:34 PM<br>
>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for<br>
>> neutron-lbaas core team<br>
>><br>
>> Hi all,<br>
>><br>
>> As the Lieutenant of the advanced services, I nominate Michael Johnson<br>
>>to<br>
>> be a member of the neutron-lbaas core reviewer team.<br>
>><br>
>> Review stats are in line with other cores[2], and Michael has been<br>
>> instrumental in both neutron-lbaas and octavia.<br>
>><br>
>> Existing cores, please vote +1/-1 for his addition to the team (that?s<br>
>>Brandon,<br>
>> Phil, Al, and Kyle.)<br>
>><br>
>> Thanks,<br>
>> doug<br>
>><br>
>> 1. <a href="http://docs.openstack.org/developer/neutron/policies/core-" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-</a><br>
>> reviewers.html#core-review-hierarchy<br>
>> 2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
>><br>
>><br>
>> __________________________________________________________<br>
>> ________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: OpenStack-dev-<br>
>> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Thu, 17 Sep 2015 08:56:53 +0900<br>
From: GHANSHYAM MANN <<a href="mailto:ghanshyammann@gmail.com">ghanshyammann@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [QA] Meeting Thursday September 17th at 9:00<br>
UTC<br>
Message-ID:<br>
<CACE3TKW=Ldh4=Xg0Ggo4apepB0_4Nu=<a href="mailto:6ZdKNsmf0kWsBbw2EeA@mail.gmail.com">6ZdKNsmf0kWsBbw2EeA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi everyone,<br>
<br>
Please reminder that the weekly OpenStack QA team IRC meeting will be<br>
Thursday, September 17th at 9:00 UTC in the #openstack-meeting channel.<br>
<br>
The agenda for the meeting can be found here:<br>
<a href="https://wiki.openstack.org/wiki/Meetings/QATeamMeeting" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/QATeamMeeting</a><br>
Anyone is welcome to add an item to the agenda.<br>
<br>
To help people figure out what time 9:00 UTC is in other timezones,<br>
meeting will be at:<br>
<br>
04:00 EDT<br>
18:00 JST<br>
18:30 ACST<br>
11:00 CEST<br>
04:00 CDT<br>
02:00 PDT<br>
<br>
<br>
--<br>
Thanks & Regards<br>
Ghanshyam Mann<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Wed, 16 Sep 2015 20:07:17 -0500<br>
From: Kyle Mestery <<a href="mailto:mestery@mestery.com">mestery@mestery.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael<br>
Johnson for neutron-lbaas core team<br>
Message-ID:<br>
<<a href="mailto:CAL3VkVz13METd05kGu25-ao7nvhqTod09a3PwAG9jnsRV3yYOw@mail.gmail.com">CAL3VkVz13METd05kGu25-ao7nvhqTod09a3PwAG9jnsRV3yYOw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1<br>
<br>
On Wed, Sep 16, 2015 at 5:33 PM, Doug Wiegley <<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>><br>
wrote:<br>
<br>
> Hi all,<br>
><br>
> As the Lieutenant of the advanced services, I nominate Michael Johnson to<br>
> be a member of the neutron-lbaas core reviewer team.<br>
><br>
> Review stats are in line with other cores[2], and Michael has been<br>
> instrumental in both neutron-lbaas and octavia.<br>
><br>
> Existing cores, please vote +1/-1 for his addition to the team (that?s<br>
> Brandon, Phil, Al, and Kyle.)<br>
><br>
> Thanks,<br>
> doug<br>
><br>
> 1.<br>
> <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy</a><br>
> 2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/ff556612/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/ff556612/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Wed, 16 Sep 2015 18:07:57 -0700<br>
From: "Armando M." <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [gate] requirement conflict on Babel breaks<br>
grenade jobs<br>
Message-ID:<br>
<CAK+RQebrUhwYS=<a href="mailto:Uvey_PRHH%2BASUQ5o67XouSOigH33BLxU4u_A@mail.gmail.com">Uvey_PRHH+ASUQ5o67XouSOigH33BLxU4u_A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<a href="https://bugs.launchpad.net/grenade/+bug/1496650" rel="noreferrer" target="_blank">https://bugs.launchpad.net/grenade/+bug/1496650</a><br>
<br>
HTH<br>
Armando<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9de4060e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9de4060e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Wed, 16 Sep 2015 18:16:17 -0700<br>
From: Vipul Sabhaya <<a href="mailto:vipuls@gmail.com">vipuls@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Cue] PTL Candidacy<br>
Message-ID:<br>
<<a href="mailto:CAHC46jtoP5A5Pe7w26LFb%2BA06W6icr1jeEYJgPsFQDbjw21CXQ@mail.gmail.com">CAHC46jtoP5A5Pe7w26LFb+A06W6icr1jeEYJgPsFQDbjw21CXQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello,<br>
<br>
This will be the first official PTL election for Cue, and I would be<br>
honored to serve another term leading the project for the M Cycle.<br>
<br>
Cue is a relatively new project in Openstack, and was approved into the Big<br>
Tent during Liberty. I have been involved with Cue from the beginning,<br>
from initial POC to having a product that is production worthy. In my past<br>
life, i?ve been a member of the Trove Core team.<br>
<br>
During the Liberty Cycle, Cue has become a solid product with a control<br>
plane that can manage per-tenant RabbitMQ Clusters. We spent a lot of time<br>
beefing up our tests, and boast >90% unit test coverage. We also added<br>
Tempest tests, and Rally tests, including gating jobs for both. Our<br>
documentation has also been revamped considerably, and allows new<br>
contributors to ramp up quickly with the project.<br>
<br>
During the M cycle, I would like to focus on building a community and<br>
getting additional contributors to Cue. I would also like to focus the<br>
team on multi-broker support, including adding Kafka as a broker that is<br>
managed by Cue.<br>
<br>
I believe Cue has come a long ways in a short time, and going forward have<br>
the opportunity accelerate the growth in terms of features, quality, and<br>
adoption.<br>
<br>
Thanks for your consideration!<br>
-Vipul<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/470c335c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/470c335c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Thu, 17 Sep 2015 01:57:44 +0000<br>
From: Vijay Venkatachalam <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Barbican] Providing service user read<br>
access to all tenant's certificates<br>
Message-ID:<br>
<<a href="mailto:26B082831A2B1A4783604AB89B9B2C080E89F58B@SINPEX01CL02.citrite.net">26B082831A2B1A4783604AB89B9B2C080E89F58B@SINPEX01CL02.citrite.net</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
How does lbaas do step 2?<br>
It does not have the privilege for that secret/container using the service user.<br>
Should it use the keystone token through which user created LB config and assign read access for the secret/container to the LBaaS service user?<br>
<br>
Thanks,<br>
Vijay V.<br>
<br>
From: Fox, Kevin M [mailto:<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>]<br>
Sent: 16 September 2015 19:24<br>
To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates<br>
<br>
Why not have lbaas do step 2? Even better would be to help with the instance user spec and combined with lbaas doing step 2, you could restrict secret access to just the amphora that need the secret?<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________<br>
From: Vijay Venkatachalam<br>
Sent: Tuesday, September 15, 2015 7:06:39 PM<br>
To: OpenStack Development Mailing List (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>)<br>
Subject: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates<br>
Hi,<br>
Is there a way to provide read access to a certain user to all secrets/containers of all project/tenant's certificates?<br>
This user with universal "read" privilege's will be used as a service user by LBaaS plugin to read tenant's certificates during LB configuration implementation.<br>
<br>
Today's LBaaS users are following the below mentioned process<br>
<br>
1. tenant's creator/admin user uploads a certificate info as secrets and container<br>
<br>
2. User then have to create ACLs for the LBaaS service user to access the containers and secrets<br>
<br>
3. User creates LB config with the container reference<br>
<br>
4. LBaaS plugin using the service user will then access container reference provided in LB config and proceeds to implement.<br>
<br>
Ideally we would want to avoid step 2 in the process. Instead add a step 5 where the lbaas plugin's service user checks if the user configuring the LB has read access to the container reference provided.<br>
<br>
Thanks,<br>
Vijay V.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1e0b37b1/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1e0b37b1/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Thu, 17 Sep 2015 02:02:44 +0000<br>
From: Vijay Venkatachalam <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Barbican] Providing service user read<br>
access to all tenant's certificates<br>
Message-ID:<br>
<<a href="mailto:26B082831A2B1A4783604AB89B9B2C080E89F5CB@SINPEX01CL02.citrite.net">26B082831A2B1A4783604AB89B9B2C080E89F5CB@SINPEX01CL02.citrite.net</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
The user here is the LBaaS service user which needs read access. This service user does play any role in the config creator's project. The service user might be playing a different role is in a common project.<br>
For ex. "admin" user with "admin" role in "admin" project is the service user in devstack for LBaaS.<br>
<br>
--Vijay<br>
<br>
<br>
<br>
From: Dave McCowan (dmccowan) [mailto:<a href="mailto:dmccowan@cisco.com">dmccowan@cisco.com</a>]<br>
Sent: 16 September 2015 18:36<br>
To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates<br>
<br>
A user with the role "observer" in a project will have read access to all secrets and containers for that project, using the default settings in the policy.json file.<br>
<br>
--Dave McCowan<br>
<br>
From: Vijay Venkatachalam <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a><mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>>><br>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
Date: Tuesday, September 15, 2015 at 10:06 PM<br>
To: "OpenStack Development Mailing List (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
Subject: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates<br>
<br>
Hi,<br>
Is there a way to provide read access to a certain user to all secrets/containers of all project/tenant's certificates?<br>
This user with universal "read" privilege's will be used as a service user by LBaaS plugin to read tenant's certificates during LB configuration implementation.<br>
<br>
Today's LBaaS users are following the below mentioned process<br>
<br>
1. tenant's creator/admin user uploads a certificate info as secrets and container<br>
<br>
2. User then have to create ACLs for the LBaaS service user to access the containers and secrets<br>
<br>
3. User creates LB config with the container reference<br>
<br>
4. LBaaS plugin using the service user will then access container reference provided in LB config and proceeds to implement.<br>
<br>
Ideally we would want to avoid step 2 in the process. Instead add a step 5 where the lbaas plugin's service user checks if the user configuring the LB has read access to the container reference provided.<br>
<br>
Thanks,<br>
Vijay V.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/9a2da227/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/9a2da227/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Wed, 16 Sep 2015 22:10:23 -0400<br>
From: gord chung <<a href="mailto:gord@live.ca">gord@live.ca</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] ceilometer code debugging<br>
Message-ID: <BLU437-SMTP72E84AA275C3A5BD36B6DDE5A0@phx.gbl><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
hi,<br>
<br>
i'm not familiar with eclipse+pydev but you should be able to run that<br>
command as is in terminal<br>
<br>
'./tools/ceilometer-test-event.py'<br>
<br>
the main question i have is what are you trying to debug? that script,<br>
to be honest, does not do much. it seems to just test the event<br>
conversion functionality. you might find some useful information in the<br>
dev docs[1] if you have questions about Ceilometer. if it's a pydev<br>
specific question you might want to generalise your subject line to have<br>
more eyes.<br>
<br>
[1] <a href="http://docs.openstack.org/developer/ceilometer" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/ceilometer</a><br>
<br>
<br>
On 16/09/15 08:42 AM, Nanda Devi Sahu wrote:<br>
> Hello,<br>
><br>
> I am trying to debug Ceilometer code taken from git. I have configured<br>
> Eclipse with Pydev for the same. The configuration seems to be fine<br>
> but when I do a debug of the code it shows to be running but I do not<br>
> see the flow of the code. LIke the main thread and the following threads.<br>
><br>
> Attached is the debug prespective view where the run is working<br>
> without any code stack.<br>
><br>
> Could you please suggest what Am I missing to get the flow. I have<br>
> also attached the debug configuration image for reference.<br>
><br>
><br>
> Regards,<br>
> Nanda.<br>
><br>
> *L&T Technology Services Ltd*<br>
><br>
> <a href="http://www.LntTechservices.com" rel="noreferrer" target="_blank">www.LntTechservices.com</a> <<a href="http://www.lnttechservices.com/" rel="noreferrer" target="_blank">http://www.lnttechservices.com/</a>><br>
><br>
> This Email may contain confidential or privileged information for the<br>
> intended recipient (s). If you are not the intended recipient, please<br>
> do not use or disseminate the information, notify the sender and<br>
> delete it from your system.<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
--<br>
gord<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/34169458/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/34169458/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Thu, 17 Sep 2015 10:27:40 +0800<br>
From: Rui Chen <<a href="mailto:chenrui.momo@gmail.com">chenrui.momo@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Congress] PTL candidacy<br>
Message-ID:<br>
<CABHH=<a href="mailto:5D0-XNG1ebhYEbBSvHf8BMfs0x8tMxw36d9j_AMS5qrEQ@mail.gmail.com">5D0-XNG1ebhYEbBSvHf8BMfs0x8tMxw36d9j_AMS5qrEQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1<br>
<br>
Tim is an excellent and passionate leader, go ahead, Congress :-)<br>
<br>
<br>
2015-09-17 4:09 GMT+08:00 <<a href="mailto:Ramki_Krishnan@dell.com">Ramki_Krishnan@dell.com</a>>:<br>
<br>
> +1 and looking forward to see you in Tokyo.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Ramki<br>
><br>
><br>
><br>
> *From:* Tim Hinrichs [mailto:<a href="mailto:tim@styra.com">tim@styra.com</a>]<br>
> *Sent:* Tuesday, September 15, 2015 1:23 PM<br>
> *To:* OpenStack Development Mailing List (not for usage questions)<br>
> *Subject:* [openstack-dev] [Congress] PTL candidacy<br>
><br>
><br>
><br>
> Hi all,<br>
><br>
><br>
><br>
> I?m writing to announce my candidacy for Congress PTL for the Mitaka<br>
> cycle. I?m excited at the prospect of continuing the development of our<br>
> community, our code base, and our integrations with other projects.<br>
><br>
><br>
><br>
> This past cycle has been exciting in that we saw several new, consistent<br>
> contributors, who actively pushed code, submitted reviews, wrote specs, and<br>
> participated in the mid-cycle meet-up. Additionally, our integration with<br>
> the rest of the OpenStack ecosystem improved with our move to running<br>
> tempest tests in the gate instead of manually or with our own CI. The code<br>
> base matured as well, as we rounded out some of the features we added near<br>
> the end of the Kilo cycle. We also began making the most significant<br>
> architectural change in the project?s history, in an effort meet our<br>
> high-availability and API throughput targets.<br>
><br>
><br>
><br>
> I?m looking forward to the Mitaka cycle. My highest priority for the code<br>
> base is completing the architectural changes that we began in Liberty.<br>
> These changes are undoubtedly the right way forward for production use<br>
> cases, but it is equally important that we make Congress easy to use and<br>
> understand for both new developers and new end users. I also plan to<br>
> further our integration with the OpenStack ecosystem by better utilizing<br>
> the plugin architectures that are available (e.g. devstack and tempest). I<br>
> will also work to begin (or continue) dialogues with other projects that<br>
> might benefit from consuming Congress. Finally I?m excited to continue<br>
> working with our newest project members, helping them toward becoming core<br>
> contributors.<br>
><br>
><br>
><br>
> See you all in Tokyo!<br>
><br>
> Tim<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6eb8e3f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6eb8e3f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Thu, 17 Sep 2015 10:00:38 +0530<br>
From: Abhishek Talwar <<a href="mailto:abhishek.talwar@tcs.com">abhishek.talwar@tcs.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] how to get current memory utilization of<br>
an instance<br>
Message-ID:<br>
<<a href="mailto:OFE5715C3D.F5F7173F-ON65257EC3.0018C71C-65257EC3.0018C722@tcs.com">OFE5715C3D.F5F7173F-ON65257EC3.0018C71C-65257EC3.0018C722@tcs.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/17a718cc/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/17a718cc/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Thu, 17 Sep 2015 15:01:53 +1000<br>
From: Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [all][gate] grende jobs failing.<br>
Message-ID: <<a href="mailto:20150917050153.GE68449@thor.bakeyournoodle.com">20150917050153.GE68449@thor.bakeyournoodle.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in kilo. The<br>
juno global-requirements for Babel are not compatible with kilo so nothing can<br>
get through grenade :(<br>
<br>
We're working it<br>
<a href="https://bugs.launchpad.net/oslo.utils/+bug/1496678" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.utils/+bug/1496678</a><br>
<br>
Yours Tony.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/223909/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/223909/</a> sorry :(<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/67c713cc/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/67c713cc/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Thu, 17 Sep 2015 13:22:23 +0800<br>
From: Ying Chun Guo <<a href="mailto:guoyingc@cn.ibm.com">guoyingc@cn.ibm.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [i18n] PTL candidacy<br>
Message-ID:<br>
<<a href="mailto:OF4A738412.8EF74BD1-ON48257EC3.001CE928-48257EC3.001D8417@cn.ibm.com">OF4A738412.8EF74BD1-ON48257EC3.001CE928-48257EC3.001D8417@cn.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
I, also known as "Daisy", would like to continue as the I18n PTL,<br>
if you will have me.<br>
<br>
I had a great time as the I18n PTL in Liberty,<br>
working with the whole team to make important changes happen.<br>
I would like to have another term to stabilize them.<br>
<br>
In June, I18n project became an official project.<br>
Translation contributors are treated the same as code contributors.<br>
30+ active translators are regarded as ATC's in Liberty.<br>
It is a great milestone for I18n team and translators.<br>
We are getting more official and more visible.<br>
<br>
In July, we started the trial of the new tool -Zanata,<br>
which is a open source based and OpenStack hosted translation website.<br>
After a long time evaluation and improvement, in September,<br>
we officially migrated translations to Zanata.<br>
49 language teams are created and 130+ translators have been registered.<br>
Now we are running Liberty translation there.<br>
<br>
In September, we kicked off Liberty translation, which is under<br>
processing now. It's the first time that we translate on top of Zanata,<br>
the first time that we include Nova in the translation plan,<br>
and the first time we formally use two phases of string freeze.<br>
I'm trying my best to make sure everything is running well.<br>
When Liberty translation is done, we could review how we did and how<br>
to make them better.<br>
<br>
In Mitaka, I'm going to focus on blew items:<br>
<br>
1. Get official recoginization to translators<br>
I'm going to add translation metric in stackalytics,<br>
and automate the process to award active translators "ATC"<br>
<br>
2. Improve translation quality<br>
I'm going to improve the list of translation terminologies, promote<br>
its broad adoption in all language teams.<br>
I'm going to boost the enablement of translation check website.<br>
<br>
3. Better cooperation with development team and documentation team<br>
<br>
I welcome any good ideas which could help the team to achieve<br>
these goals. Hope to get your support for my PTL role in Mitaka.<br>
I am honored to work with everyone to build up a better I18n project.<br>
<br>
Thank you.<br>
Daisy<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/f4f33730/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/f4f33730/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Wed, 16 Sep 2015 22:26:17 -0700<br>
From: Chris Hoge <<a href="mailto:chris@openstack.org">chris@openstack.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [defcore] Scoring for DefCore 2016.01<br>
Guideline<br>
Message-ID: <<a href="mailto:0AC92343-7973-4015-A9C2-E8ADD1B5355B@openstack.org">0AC92343-7973-4015-A9C2-E8ADD1B5355B@openstack.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
The DefCore Committee is working on scoring capabilities for the upcoming<br>
2016.01 Guideline, a solid draft of which will be available at the Mitaka<br>
summit for community review and will go to the Board of Directors for<br>
approaval in Janaury [1]. The current 2015.07 Guideline [2] covers Nova,<br>
Swift, and Keystone. Scoring for the upcoming Guideline may includes new<br>
capabilities for Neutron, Glance, Cinder, and Heat, as well as<br>
updated capabilities for Keystone and Nova.<br>
<br>
As part of our process, we want to encourage the development and user<br>
communities to give feedback on the proposed capability categorizations<br>
and how they are currently graded against the Defcore criteria [3].<br>
<br>
Capabilities we're currently considering for possible inclusion are:<br>
Neutron: <a href="https://review.openstack.org/#/c/210080/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/210080/</a><br>
Glance: <a href="https://review.openstack.org/#/c/213353/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/213353/</a><br>
Cinder: <a href="https://review.openstack.org/#/c/221631/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/221631/</a><br>
Heat: <a href="https://review.openstack.org/#/c/216983/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/216983/</a><br>
Keystone: <a href="https://review.openstack.org/#/c/213330/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/213330/</a><br>
Nova: <a href="https://review.openstack.org/#/c/223915/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/223915/</a><br>
<br>
We would especially like to thank the PTL's and technical community members<br>
who helped draft the proposed capabilities lists and provided<br>
feedback--your input has been very helpful.<br>
<br>
[1] <a href="http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n13" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n13</a><br>
[2] <a href="http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json</a><br>
[3] <a href="http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Thu, 17 Sep 2015 15:34:30 +1000<br>
From: Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all][gate] grende jobs failing.<br>
Message-ID: <<a href="mailto:20150917053429.GF68449@thor.bakeyournoodle.com">20150917053429.GF68449@thor.bakeyournoodle.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:<br>
> Hi all,<br>
> The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in kilo. The<br>
> juno global-requirements for Babel are not compatible with kilo so nothing can<br>
> get through grenade :(<br>
><br>
> We're working it<br>
> <a href="https://bugs.launchpad.net/oslo.utils/+bug/1496678" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.utils/+bug/1496678</a><br>
<br>
Here's my best effort for right now.<br>
<a href="https://review.openstack.org/#/c/224429/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224429/</a><br>
<br>
Yours Tony.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/4fc3d53f/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/4fc3d53f/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Thu, 17 Sep 2015 01:58:59 -0400<br>
From: Nikhil Komawar <<a href="mailto:nik.komawar@gmail.com">nik.komawar@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Glance] PTL candidacy<br>
Message-ID: <<a href="mailto:55FA56A3.4000001@gmail.com">55FA56A3.4000001@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hello everyone,<br>
<br>
I would like to herewith propose my candidacy for the role of Glance PTL<br>
for the Mitaka release cycle.<br>
<br>
I. Personal Commitment<br>
<br>
I am a full time upstream OpenStacker at IBM and have recently<br>
transitioned into this role with the condition that I will be given 100%<br>
time to focus on community issues, development and help solve upstream<br>
challenges. I am also committed to giving my full attention to Glance.<br>
Not too long ago, I have had a few conversations with the PTLs of other<br>
projects for either help them better use Glance or for dissolving the<br>
issues they were facing in their projectsw. However, in this cycle I<br>
would like to work with some of you in the capacity of inter-project<br>
liaisons to help better understand the usage and stability of Glance in<br>
respective areas and yet be involved with you in addressing those<br>
issues. I know this is added work that must not go unrewarded so, I<br>
would like to work out a plan with you that will enable distribution of<br>
power (if with more power comes more responsibility, visa versa must<br>
true, making it true claim). It has been enabled in Glance to some<br>
extent & I have learnt other bigger projects implementing this. I would<br>
like to make it a complete reality in Glance. I am also committed to<br>
documenting and improving the current specs process and criterion that<br>
will enable quicker turnaround time.<br>
<br>
At IBM, I have the pleasure of being part of team that has some of the<br>
most outstanding OpenStackers and I hope to collaborate more with them<br>
in Mitaka for solving (hard) problems.<br>
<br>
II. Liberty<br>
<br>
a) Stability<br>
<br>
Over 100 bugs were fixed in Liberty (including python-glanceclient,<br>
glance_store and Glance servers) with a relatively small review team.<br>
Glance is gradually improving momentum to help the different code<br>
proposals get time-justice for code reviews. Some features in Kilo<br>
introduced a number security bugs beyond expectations so, the further<br>
development of those features has been slowed down and focus has been<br>
shifted to fix the functionality, making it more stable and secure.<br>
Experimental features showed a smooth progress and close to no issues of<br>
such sort. A close eye on the reviews was kept to ensure so. Any spec<br>
proposals that showed potential security risks, shake stability or<br>
performance or refactor major parts of the code base were given a wait<br>
signal.<br>
<br>
b) Performance<br>
<br>
I consider them as systematic optimizations and sometimes systematic<br>
improvisations. Major disagreements on the path forward for optimizing<br>
streaming workflows for images data have been sorted out. Many new<br>
proposals were made however, due to lack of early time commitment from<br>
developers they were unable to be seen through. Continued feedback<br>
should be expected for similar proposals for glance_store in early Mitaka.<br>
<br>
c) Cross project communications & Process Evolution<br>
<br>
I have made an attempt to continually evolve our process to make it more<br>
engaging and community friendly. Now there are three meetings weekly<br>
that are a good place for collaboration on different aspects of Glance.<br>
Either me or a member of the Glance community is at the weekly CPL<br>
meeting to gather feedback from horizontal teams, cross project<br>
decision/efforts etc. as well as input has been provided using Glance?s<br>
perspective. I have had regular chats with Nova PTL on the outstanding<br>
issues of the Images APIs and adoption of v2 Images API by Nova.<br>
Feedback was provided at the DefCore mid-cycle as well as a welcoming<br>
hand was presented for attending Glance mid-cycle (even virtually) for<br>
those who could not make it. In Mitaka, I hope to continue<br>
collaborating with the interested members there as well as in the other<br>
projects. I would like to pay close personal attention to the pressing<br>
matters that need short team resolution like the adoption of v2 API by<br>
Nova and Images API suitable for DefCore. Unfortunately, any of the<br>
existing (half) attempts at fixing this issue have been wasted as they<br>
were breaking some of the fundamental aspects of project. This matter<br>
would need wider input for a fine resolution and a change that would not<br>
break the world; of-course compromise is very likely for some but<br>
doesn?t need to be fundamentally disjoint with the newly established<br>
DefCore standard. It was realized early that a half baked attempt of<br>
making such a critical change would break core of Glance so, I have been<br>
contemplating on the future of the project. More clarity of thought has<br>
been accomplished during the conversations with the TC members, PTLs,<br>
Product WG liaisons etc. and I will continue to gather more feedback in<br>
Mitaka. It has been a pleasure to be part of (collaborating with) teams<br>
that help build very large cloud deployments and I find that experience<br>
valuable for solving this complicated matter. Not only upstream but at<br>
IBM too, I plan to closely interact with the technical and product<br>
leaders of the Public and Private cloud deployment to help solve such<br>
issues. My team at IBM enables me to have such interactions with<br>
veterans of OpenStack.<br>
<br>
III. Direction<br>
<br>
a) Short Term Goals<br>
There are four short team goals that seem important right away: DefCore<br>
requirements; Nova and Cinder v2 adoption/stability; cadence between<br>
developer and reviewer bandwidth; better collaboration via<br>
documentation, CPL & inter project liaisons power distribution.<br>
<br>
b) Mid Term Goals<br>
I think it?s vital that we pin down subtle aspects of v2 API in<br>
mid-term, primarily focus on Images however, at the same time ensure<br>
that all of our APIs are efficient and performant.<br>
<br>
The concept of tasks needs to have a clear picture in all the developers<br>
as well as operators viewpoints. There are equally compelling arguments<br>
to make them user centric only, admin only and open to both. Most<br>
important use cases will be taken into account and a plan for tasks will<br>
be setup.<br>
<br>
Some of the operators and active developers wish to focus on performance<br>
improvement and reliaiblity of image data delivery ? so this will be<br>
another very important mid-term goal.<br>
<br>
Definition of core fundamentals like immutability of images & Glance<br>
architecture seems critical. Also, it is necessary to be aware about the<br>
side-effects of feature proposals that can potentially lead to breaking<br>
changes. It has come to my notice that many a times such proposals are<br>
made and the proposers find it difficult to grasp how the change could<br>
affect Glance. We will try to solve this issue via collaboration and<br>
documentation.<br>
<br>
c) Long Term Goals<br>
<br>
The long term goals follow the mid-term goals. Solidification of the<br>
Images v2 API and planning long term support for the same. There?s<br>
already some work happening to set a direction for this.<br>
<br>
Artifacts and a generic repository ? as per Glance?s mission statement,<br>
this is an important goal. A generic data asset service would be an<br>
excellent one stop shop for users. Possibly evolving in to a Marketplace<br>
like stage for many of OpenStack assets (Artifacts).<br>
<br>
Addressing storage and retrieval of Images issues for smaller size data<br>
(Image record in DB) and for larger blobs of data (stored in the backend<br>
store) ? this may be termed as performance problem but as a long term<br>
objective it will be a clear separation of concerns and give ability to<br>
operators to work on image or artifact data in a efficient manner.<br>
<br>
VII. Community<br>
<br>
Glance community has been traditionally known to be friendly to help new<br>
developers join and it avoids the influx vs. outflux issues. Keeping the<br>
long term objectives in mind this remains important. I will try to keep<br>
it a conducive environment for all concerned individuals. Without losing<br>
hind sight help focus on the short term goals, I will enable specific<br>
individuals to make important calls if it helps move forward with<br>
pressing issues.<br>
<br>
VIII. Solving Hard Problems<br>
<br>
a) Collaboration<br>
<br>
The tradition of pre-summit, within cycle video and face-to-face syncs<br>
will be continued. Inputs of the CPLs, inter-project liaisons will be<br>
encouraged and welcomed. Glance representatives will engage in certain<br>
important projects regarding images related subject matter. Artifacts<br>
representatives will engage in other working groups to make the API more<br>
usable and adoptable. I plan to keep working with the DefCore committee<br>
and PTLs to help bridge the gap of overlapping issues. OpenStack is a<br>
diverse community and so is the Glance team. So, we will focus on<br>
keeping weekly syncs addressing important issues interactively. Overall,<br>
collaboration will be one of the most vital component of this cycle.<br>
<br>
b) Themed Focus<br>
<br>
The most important themes that come to mind at this point of time are:<br>
getting a standard API for DefCore, interaction with Nova team to enable<br>
v2 adoption, documentation of the features and processes (this will also<br>
help with collaboration), Artifacts and it?s API, performance and<br>
reliablilty & stability. A sub-team leader would be chosen for each of<br>
these themes and periodic sync would be made effective for a good team<br>
effort.<br>
<br>
c) Core reviewer bandwidth, their influx and outflux<br>
<br>
Glance has had the mis-fortune for losing important and talented<br>
developers time and again due to commitment changes (and not a result of<br>
drive away from the team). We will continue to keep the doors open for<br>
them and if any of the super active OpenStackers wish to become core in<br>
short window, there will be a easier process of doing so. This will help<br>
fix any outstanding bugs, keep the gate steady and help a good momentum<br>
for the release of libraries. Good collaborators have always been good<br>
drivers & it would be wise to continue in that direction. Good<br>
developers have been engaged in Liberty to become part of Glance and I<br>
will continue to do so for Mitaka.<br>
<br>
d) One OpenStack<br>
<br>
No matter how easy it is to define solo project priorities, we all live<br>
in the single OpenStack realm. Operators have to deploy Glance alongside<br>
other OpenStack services and there is a level of understanding that will<br>
be put in into action while defining Glance priorities so that other<br>
projects are not severely affected. I believe in ?One OpenStack & a<br>
unified vision? and hope you are with me.<br>
<br>
<br>
<br>
Thank you for your consideration in allowing me to continue serving as<br>
PTL for Mitaka cycle.<br>
<br>
Nikhil Komawar<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Thu, 17 Sep 2015 06:06:57 +0000<br>
From: Samuel Bercovici <SamuelB@Radware.com><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael<br>
Johnson for neutron-lbaas core team<br>
Message-ID:<br>
<<a href="mailto:F36E8145F2571242A675F56CF6096456A069A64E@ILMB1.corp.radware.com">F36E8145F2571242A675F56CF6096456A069A64E@ILMB1.corp.radware.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
And then they were 6 =D><br>
<br>
<br>
-Sam.<br>
<br>
-----Original Message-----<br>
From: Doug Wiegley [mailto:<a href="mailto:dougwig@parksidesoftware.com">dougwig@parksidesoftware.com</a>]<br>
Sent: Thursday, September 17, 2015 1:34 AM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team<br>
<br>
Hi all,<br>
<br>
As the Lieutenant of the advanced services, I nominate Michael Johnson to be a member of the neutron-lbaas core reviewer team.<br>
<br>
Review stats are in line with other cores[2], and Michael has been instrumental in both neutron-lbaas and octavia.<br>
<br>
Existing cores, please vote +1/-1 for his addition to the team (that?s Brandon, Phil, Al, and Kyle.)<br>
<br>
Thanks,<br>
doug<br>
<br>
1. <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy</a><br>
2. <a href="http://stackalytics.com/report/contribution/neutron-lbaas/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-lbaas/90</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Wed, 16 Sep 2015 23:07:26 -0700<br>
From: "Ton Ngo" <<a href="mailto:ton@us.ibm.com">ton@us.ibm.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Magnum] API response on k8s failure<br>
Message-ID: <<a href="mailto:201509170607.t8H67XWo014648@d01av04.pok.ibm.com">201509170607.t8H67XWo014648@d01av04.pok.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
Hi Ryan,<br>
There is a bug opened with a similar failure symptom, although I am<br>
not sure if the cause is the same:<br>
<a href="https://bugs.launchpad.net/magnum/+bug/1481889" rel="noreferrer" target="_blank">https://bugs.launchpad.net/magnum/+bug/1481889</a><br>
<br>
Trying to use kubectl to deploy the V1 manifest, I get this error message:<br>
Error: unable to recognize "redis-master.yaml": no object named "Pod" is<br>
registered<br>
<br>
Clearly the error handling from the k8s handler needs to be improved. If<br>
the bug above is different from what you found, I think opening a new bug<br>
would be best.<br>
<br>
Ton Ngo,<br>
<br>
<br>
<br>
<br>
From: Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Date: 09/14/2015 05:34 PM<br>
Subject: Re: [openstack-dev] [Magnum] API response on k8s failure<br>
<br>
<br>
<br>
Ryan,<br>
<br>
Thanks for sharing this. Sorry you got out to a bumpy start. I suggest you<br>
do file a bug for this against magnum and we can decide how best to handle<br>
it. I can not tell from your email what the kubectl would do with the same<br>
input. We might have an opportunity to make both better.<br>
<br>
If you need guidance for how to file a bug, feel free to email me directly<br>
and I can point you in the right direction.<br>
<br>
Thanks,<br>
<br>
Adrian<br>
<br>
> On Sep 14, 2015, at 3:05 PM, Ryan Rossiter <<a href="mailto:rlrossit@linux.vnet.ibm.com">rlrossit@linux.vnet.ibm.com</a>><br>
wrote:<br>
><br>
> I was giving a devstacked version of Magnum a try last week, and from a<br>
new user standpoint, I hit a big roadblock that caused me a lot of<br>
confusion. Here's my story:<br>
><br>
> I was attempting to create a pod in a k8s bay, and I provided it with an<br>
sample manifest from the Kubernetes repo. The Magnum API then returned the<br>
following error to me:<br>
><br>
> ERROR: 'NoneType' object has no attribute 'host' (HTTP 500)<br>
><br>
> I hunted down the error to be occurring here [1]. The k8s_api call was<br>
going bad, but conductor was continuing on anyways thinking the k8s API<br>
call went fine. I dug through the API calls to find the true cause of the<br>
error:<br>
><br>
> {u'status': u'Failure', u'kind': u'Status', u'code': 400, u'apiVersion':<br>
u'v1beta3', u'reason': u'BadRequest', u'message': u'Pod in version v1<br>
cannot be handled as a Pod: no kind "Pod" is registered for version "v1"',<br>
u'metadata': {}}<br>
><br>
> It turned out the error was because the manifest I was using had<br>
apiVersion v1, not v1beta3. That was very unclear by Magnum originally<br>
sending the 500.<br>
><br>
> This all does occur within a try, but the k8s API isn't throwing any sort<br>
of exception that can be caught by [2]. Was this caused by a regression in<br>
the k8s client? It looks like the original intention of this was to catch<br>
something going wrong in k8s, and then forward on the message & error code<br>
on to let the magnum API return that.<br>
><br>
> My question here is: does this classify as a bug? This happens in more<br>
places than just the pod create. It's changing around API returns (quite a<br>
few of them), and I don't know how that is handled in the Magnum project.<br>
If we want to have this done as a blueprint, I can open that up and target<br>
it for Mitaka, and get to work. If it should be opened up as a bug, I can<br>
also do that and start work on it ASAP.<br>
><br>
> [1]<br>
<a href="https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L88-L108" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L88-L108</a><br>
<br>
> [2]<br>
<a href="https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L94" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L94</a><br>
<br>
><br>
> --<br>
> Thanks,<br>
><br>
> Ryan Rossiter (rlrossit)<br>
><br>
><br>
><br>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: graycol.gif<br>
Type: image/gif<br>
Size: 105 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.gif" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.gif</a>><br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Thu, 17 Sep 2015 14:52:36 +0800<br>
From: Li Ma <<a href="mailto:skywalker.nick@gmail.com">skywalker.nick@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [dragonflow] Low OVS version for Ubuntu<br>
Message-ID:<br>
<CALFEDVcXE18WAWS=<a href="mailto:64sOQkyLn6ob2R0Nx%2BG2jSP3xOo37Zcubg@mail.gmail.com">64sOQkyLn6ob2R0Nx+G2jSP3xOo37Zcubg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi all,<br>
<br>
I tried to run devstack to deploy dragonflow, but I failed with lower<br>
OVS version.<br>
<br>
I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3<br>
which is much lower than the required version 2.3.1+?<br>
<br>
So, can anyone provide a Ubuntu repository that contains the correct<br>
OVS packages?<br>
<br>
Thanks,<br>
--<br>
<br>
Li Ma (Nick)<br>
Email: <a href="mailto:skywalker.nick@gmail.com">skywalker.nick@gmail.com</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Thu, 17 Sep 2015 15:13:17 +0800<br>
From: Li Ma <<a href="mailto:skywalker.nick@gmail.com">skywalker.nick@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [neutron] RFE process question<br>
Message-ID:<br>
<CALFEDVdLfL9FD01=JbXUJxqfxSF_9T=<a href="mailto:KGr8UkkD2FRzSPESUoA@mail.gmail.com">KGr8UkkD2FRzSPESUoA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
A reasonable user story. Other than tag, a common description field<br>
for Neutron resources is also usable.<br>
<br>
I submitted a RFE bug for review:<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1496705" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1496705</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Thu, 17 Sep 2015 10:14:30 +0300<br>
From: mhorban <<a href="mailto:mhorban@mirantis.com">mhorban@mirantis.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration<br>
of service<br>
Message-ID: <<a href="mailto:55FA6856.1@mirantis.com">55FA6856.1@mirantis.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi Josh,<br>
<br>
> Sounds like a useful idea if projects can plug-in themselves into the<br>
> reloading process. I definitely think there needs to be a way for<br>
> services to plug-in to this, although I'm not quite sure it will be<br>
> sufficient at the current time though.<br>
><br>
> An example of why:<br>
><br>
> -<br>
><br>
<a href="https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24</a><br>
<br>
> (unless this module is purged from python and reloaded it will likely<br>
> not reload correctly).<br>
><br>
> Likely these can all be easily fixed (I just don't know how many of<br>
> those exist in the various projects); but I guess we have to start<br>
> somewhere so getting the underlying code able to be reloaded is a first<br>
> step of likely many.<br>
<br>
Each of openstack component should contain code responsible for<br>
reloading such objects.<br>
What objects will be reloaded? It depends of inspire and desire of<br>
developers/users.<br>
Writing such code is a second step.<br>
<br>
Marian<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Thu, 17 Sep 2015 15:16:50 +0800<br>
From: Li Ma <<a href="mailto:skywalker.nick@gmail.com">skywalker.nick@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [neutron] Please help review this RFE<br>
Message-ID:<br>
<CALFEDVeR=s81c9ux7bWDv=+<a href="mailto:x8YqwemUCSMfBmMhHYRky_ja7xA@mail.gmail.com">x8YqwemUCSMfBmMhHYRky_ja7xA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Neutron folks,<br>
<br>
I'd like to introduce a pure python-driven network configuration<br>
library to Neutron. A discussion just started in the RFE ticket [1].<br>
I'd like to get feedback on this proposal.<br>
<br>
[1]: <a href="https://bugs.launchpad.net/neutron/+bug/1492714" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1492714</a><br>
<br>
Take a look and let me know your thoughts.<br>
--<br>
<br>
Li Ma (Nick)<br>
Email: <a href="mailto:skywalker.nick@gmail.com">skywalker.nick@gmail.com</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Thu, 17 Sep 2015 12:54:36 +0530<br>
From: Sudipto Biswas <<a href="mailto:sbiswas7@linux.vnet.ibm.com">sbiswas7@linux.vnet.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu<br>
Message-ID: <<a href="mailto:55FA6AB4.5030605@linux.vnet.ibm.com">55FA6AB4.5030605@linux.vnet.ibm.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
<br>
<br>
On Thursday 17 September 2015 12:22 PM, Li Ma wrote:<br>
> Hi all,<br>
><br>
> I tried to run devstack to deploy dragonflow, but I failed with lower<br>
> OVS version.<br>
><br>
> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3<br>
> which is much lower than the required version 2.3.1+?<br>
><br>
> So, can anyone provide a Ubuntu repository that contains the correct<br>
> OVS packages?<br>
<br>
Why don't you just build the OVS you want from here: <a href="http://openvswitch.org/download/" rel="noreferrer" target="_blank">http://openvswitch.org/download/</a><br>
<br>
> Thanks,<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Thu, 17 Sep 2015 10:26:28 +0300<br>
From: mhorban <<a href="mailto:mhorban@mirantis.com">mhorban@mirantis.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration<br>
of service<br>
Message-ID: <<a href="mailto:55FA6B24.5000602@mirantis.com">55FA6B24.5000602@mirantis.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi Doug,<br>
<br>
> Rather than building hooks into oslo.config, why don't we build them<br>
> into the thing that is catching the signal. That way the app can do lots<br>
> of things in response to a signal, and one of them might be reloading<br>
> the configuration.<br>
<br>
Hm... Yes... It is really stupid idea to put reloading hook into<br>
oslo.config.<br>
I'll move that hook mechanism into oslo.service. oslo.service is<br>
responsible for catching/handling signals.<br>
<br>
Is it enough to have one callback function? Or should I must add ability<br>
to register many different callback functions?<br>
<br>
What is your point of view?<br>
<br>
Marian<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Thu, 17 Sep 2015 09:28:11 +0200<br>
From: Yanis Guenane <<a href="mailto:yguenane@redhat.com">yguenane@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [puppet] service default value functions<br>
Message-ID: <<a href="mailto:55FA6B8B.1090203@redhat.com">55FA6B8B.1090203@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<br>
<br>
On 09/16/2015 09:39 PM, Emilien Macchi wrote:<br>
><br>
> On 09/16/2015 12:53 PM, Alex Schultz wrote:<br>
>> Hey puppet folks,<br>
>><br>
>> Based on the meeting yesterday[0], I had proposed creating a parser<br>
>> function called is_service_default[1] to validate if a variable matched<br>
>> our agreed upon value of '<SERVICE DEFAULT>'. This got me thinking<br>
>> about how can we maybe not use the arbitrary string throughout the<br>
>> puppet that can not easily be validated. So I tested creating another<br>
>> puppet function named service_default[2] to replace the use of '<SERVICE<br>
>> DEFAULT>' throughout all the puppet modules. My tests seemed to<br>
>> indicate that you can use a parser function as parameter default for<br>
>> classes.<br>
>><br>
>> I wanted to send a note to gather comments around the second function.<br>
>> When we originally discussed what to use to designate for a service's<br>
>> default configuration, I really didn't like using an arbitrary string<br>
>> since it's hard to parse and validate. I think leveraging a function<br>
>> might be better since it is something that can be validated via tests<br>
>> and a syntax checker. Thoughts?<br>
> Let me add your attempt to make it work in puppet-cinder:<br>
> <a href="https://review.openstack.org/#/c/224277" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224277</a><br>
><br>
> I like the proposal, +1.<br>
Alex, thank you for this proposal.<br>
<br>
I like your approach :<br>
<br>
* as it will make writing manifest more idiomatic.<br>
<br>
$foo = service_default() with if is_service_default($foo) { } reads<br>
better than<br>
$foo = '<SERVICE DEFAULT>' with if $foo == '<SERVICE DEFAULT>'.<br>
<br>
* if for any reason, hopefully this shouldn't happen but we need to<br>
change the value,<br>
it will happen only on few places. (less commit to review)<br>
<br>
* the end result is the exact same one as the one we have today.<br>
<br>
For me it's a go, let's see what the other have to say about it<br>
<br>
Thank you,<br>
<br>
><br>
>> Thanks,<br>
>> -Alex<br>
>><br>
>> [0] <a href="http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html</a><br>
>> [1] <a href="https://review.openstack.org/#/c/223672" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/223672</a><br>
>> [2] <a href="https://review.openstack.org/#/c/224187" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224187</a><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 41<br>
Date: Thu, 17 Sep 2015 09:48:59 +0200<br>
From: Adam Heczko <<a href="mailto:aheczko@mirantis.com">aheczko@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Bugs which we should accept in 7.0<br>
after Hard Code Freeze<br>
Message-ID:<br>
<CAJciqMyBC_=<a href="mailto:5AmWjwHK53Wa9pZPL77vctm-f-MEGyADh5hHvFA@mail.gmail.com">5AmWjwHK53Wa9pZPL77vctm-f-MEGyADh5hHvFA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi, I'd like to ask for fixing these security related bugs in stable/7.0<br>
branch:<br>
<br>
<a href="https://bugs.launchpad.net/fuel/+bug/1496407" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1496407</a><br>
<a href="https://bugs.launchpad.net/fuel/+bug/1488732" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1488732</a><br>
<br>
Both are fuel-library related tasks, it is Apache2 and NTPD configuration<br>
lifting.<br>
<br>
Thanks,<br>
<br>
Adam<br>
<br>
On Tue, Sep 15, 2015 at 12:19 AM, Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com">mscherbakov@mirantis.com</a>><br>
wrote:<br>
<br>
> Thanks Andrew.<br>
> Team, if there are any disagreements - let's discuss it. Otherwise, I<br>
> think we should be just strict and follow defined process. We can deliver<br>
> high priority bugfixes in updates channel later if needed.<br>
><br>
> I hope that reasoning is clear for everything. Every bugfix has a<br>
> potential to break something. It's basically a risk.<br>
><br>
> On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov <<a href="mailto:amaksimov@mirantis.com">amaksimov@mirantis.com</a>><br>
> wrote:<br>
><br>
>> Hi Everyone!<br>
>><br>
>> I would like to reiterate the bugfix process after Hard Code Freeze.<br>
>> According to our HCF definition [1] we should only merge fixes for<br>
>> *Critical* bugs to *stable/7.0* branch, High and lower priority bugs<br>
>> should NOT be accepted to *stable/7.0* branch anymore.<br>
>> Also we should accept patches for critical bugs to *stable/7.0* branch<br>
>> only after the corresponding patchset with same ChangeID was accepted into<br>
>> master.<br>
>><br>
>> [1] - <a href="https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze</a><br>
>><br>
>> Regards,<br>
>> Andrey Maximov<br>
>> Fuel Project Manager<br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Adam Heczko<br>
Security Engineer @ Mirantis Inc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/eb282b28/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/eb282b28/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Thu, 17 Sep 2015 18:03:53 +1000<br>
From: Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all][gate] grende jobs failing.<br>
Message-ID: <<a href="mailto:20150917080353.GA72725@thor.bakeyournoodle.com">20150917080353.GA72725@thor.bakeyournoodle.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, Sep 17, 2015 at 03:34:30PM +1000, Tony Breeds wrote:<br>
> On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:<br>
> > Hi all,<br>
> > The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in kilo. The<br>
> > juno global-requirements for Babel are not compatible with kilo so nothing can<br>
> > get through grenade :(<br>
> ><br>
> > We're working it<br>
> > <a href="https://bugs.launchpad.net/oslo.utils/+bug/1496678" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.utils/+bug/1496678</a><br>
><br>
> Here's my best effort for right now.<br>
> <a href="https://review.openstack.org/#/c/224429/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224429/</a><br>
<br>
For those playing along at home the new plan is to:<br>
1. Release a version of oslo.utils with the kilo requirements<br>
This needs to be done as a revert because 1.4.2 must follow 1.4.1<br>
- <a href="https://review.openstack.org/#/c/224472/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224472/</a><br>
2 Tag that as 1.4.2<br>
<br>
Then the gate should be okay again, while the stable team (and me) work out how<br>
to fix juno without breaking kilo.<br>
<br>
Yours Tony.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1a6cbef7/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1a6cbef7/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 43<br>
Date: Thu, 17 Sep 2015 16:13:24 +0800<br>
From: Hou Gang HG Liu <<a href="mailto:liuhoug@cn.ibm.com">liuhoug@cn.ibm.com</a>><br>
To: <a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] questions about nova compute monitors<br>
extensions<br>
Message-ID:<br>
<<a href="mailto:OFDB00AB2C.88557596-ON48257EC3.002CD29A-48257EC3.002D4C16@cn.ibm.com">OFDB00AB2C.88557596-ON48257EC3.002CD29A-48257EC3.002D4C16@cn.ibm.com</a>><br>
Content-Type: text/plain; charset="gb2312"<br>
<br>
Hi Jay,<br>
<br>
I notice nova compute monitor now only tries to load monitors with<br>
namespace "nova.compute.monitors.cpu", and only one monitor in one<br>
namespace can be enabled(<br>
<a href="https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py</a><br>
).<br>
<br>
Is there a plan to make MonitorHandler.NAMESPACES configurable or just<br>
hard code constraint as it is now? And how to make compute monitor support<br>
user defined as it was?<br>
<br>
Thanks!<br>
B.R<br>
<br>
Hougang Liu ?????<br>
Developer - IBM Platform Resource Scheduler<br>
Systems and Technology Group<br>
<br>
Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023 ??<br>
????????42?????3?<br>
E-mail: <a href="mailto:liuhoug@cn.ibm.com">liuhoug@cn.ibm.com</a> Xian, Shaanxi<br>
Province 710075, China<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/gif<br>
Size: 360 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.gif" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.gif</a>><br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Thu, 17 Sep 2015 11:17:09 +0300<br>
From: Gal Sagie <<a href="mailto:gal.sagie@gmail.com">gal.sagie@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Eran Gampel<br>
<<a href="mailto:Eran.Gampel@huawei.com">Eran.Gampel@huawei.com</a>><br>
Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu<br>
Message-ID:<br>
<<a href="mailto:CAG9LJa554aMjAF06G_8U5AiGTOuZ1ODtci%2B6ykfNO-Vaet_B4Q@mail.gmail.com">CAG9LJa554aMjAF06G_8U5AiGTOuZ1ODtci+6ykfNO-Vaet_B4Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello Li Ma,<br>
<br>
Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need<br>
OVS 2.3.1.<br>
As suggested you can build it from source.<br>
For Fedora 21 OVS2.3.1 is part of the default yum repository.<br>
<br>
You can ping me on IRC (gsagie at freenode) if you need any additional help<br>
how<br>
to compile OVS.<br>
<br>
Thanks<br>
Gal.<br>
<br>
On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <<br>
<a href="mailto:sbiswas7@linux.vnet.ibm.com">sbiswas7@linux.vnet.ibm.com</a>> wrote:<br>
<br>
><br>
><br>
> On Thursday 17 September 2015 12:22 PM, Li Ma wrote:<br>
><br>
>> Hi all,<br>
>><br>
>> I tried to run devstack to deploy dragonflow, but I failed with lower<br>
>> OVS version.<br>
>><br>
>> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3<br>
>> which is much lower than the required version 2.3.1+?<br>
>><br>
>> So, can anyone provide a Ubuntu repository that contains the correct<br>
>> OVS packages?<br>
>><br>
><br>
> Why don't you just build the OVS you want from here:<br>
> <a href="http://openvswitch.org/download/" rel="noreferrer" target="_blank">http://openvswitch.org/download/</a><br>
><br>
> Thanks,<br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Best Regards ,<br>
<br>
The G.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/7ba72dce/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/7ba72dce/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 45<br>
Date: Thu, 17 Sep 2015 12:00:22 +0300<br>
From: Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue<br>
-- why isn't thin provisioning the default?<br>
Message-ID:<br>
<CAOyZ2aFFnsrY6AaMe7bYrff5iGfQHcM7ZZtP=_<a href="mailto:yXYxY-75aqSw@mail.gmail.com">yXYxY-75aqSw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 16 September 2015 at 23:43, Eric Harney <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>> wrote:<br>
<br>
> Currently, at least some options set in [DEFAULT] don't apply to<br>
> per-driver sections, and require you to set them in the driver section<br>
> as well.<br>
><br>
<br>
This is extremely confusing behaviour. Do you have any examples? I'm not<br>
sure if we can fix it without breaking people's existing configs but I<br>
think it is worth trying. I'll add it to the list of things to talk about<br>
briefly in Tokyo.<br>
<br>
--<br>
Duncan Thomas<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6e722e1/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6e722e1/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 46<br>
Date: Thu, 17 Sep 2015 07:18:32 +0000<br>
From: Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [magnum][ptl] Magnum PTL Candidacy<br>
Message-ID:<br>
<<a href="mailto:0957CD8F4B55C0418161614FEC580D6BCE4960@SZXEMI503-MBS.china.huawei.com">0957CD8F4B55C0418161614FEC580D6BCE4960@SZXEMI503-MBS.china.huawei.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi all,<br>
<br>
I would like to announce my candidacy for the PTL position of Magnum.<br>
<br>
I involved in Magnum project starting from December 2014. At that time, Magnum's code base is much smaller than right now. Since then, I worked with a diverse set of team members to land features, discuss the roadmap, fix the gate, do pre-release test, fix the documentation, etc.. Thanks to our team efforts, in the past a few months, I saw important features were landed one after another, which I really proud of.<br>
<br>
To address the question why I am a good candidate for Magnum, here are the key reasons:<br>
* I contributed a lot to Magnum's code base and feature set.<br>
* I am familiar with every aspects of the project, and understand both the big picture and technical details.<br>
* I will have time and resources to take the PTL responsibility, mostly because I am a full time allocated to this project.<br>
* I love container.<br>
* I care the project.<br>
Here is more details of my involvement in the project:<br>
<a href="http://stackalytics.com/?module=magnum-group" rel="noreferrer" target="_blank">http://stackalytics.com/?module=magnum-group</a><br>
<a href="https://github.com/openstack/magnum/graphs/contributors" rel="noreferrer" target="_blank">https://github.com/openstack/magnum/graphs/contributors</a><br>
<br>
In my opinion, Magnum needs to focus on the following in the next cycle:<br>
* Production ready: Work on everything that are possible to make it happen.<br>
* Baremetal: Complete and optimize our Ironic integration to enable running containers on baremetal.<br>
* Container network: deliver a network solution that is high performance and customizable.<br>
* UI: Integrate with Horizon to give users a friendly interface to use Magnum.<br>
* Pluggable COE: A pluggable design is a key feature for users to customize Magnum, which is always the case.<br>
* Grow community: Attract more contributors to contribute to Magnum.<br>
<br>
If elected, I will strictly follow the principal of being a OpenStack project, especially the four opens. The direction of the project will be community-driven as always.<br>
<br>
I hope you will give me an opportunity to serve as Magnum's PTL in the next cycle.<br>
<br>
Best regards,<br>
Hongbin<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/6a41cb83/attachment.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/6a41cb83/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 41, Issue 49<br>
*********************************************<br>
</blockquote></div><br></div>