[openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49
Andrew Woodward
xarses at gmail.com
Mon Oct 5 21:14:12 UTC 2015
Santosh Parihar,
I've replied in a new thread "Re: [openstack-dev][fuel] Problems with
mcollective offline nodes" I'm sorry to break threading, but it will ensure
that the right people can find the thread with their filters and help get
you the responses you are looking for.
-
Andrew
Fuel Community
On Mon, Oct 5, 2015 at 1:55 AM santosh parihar <santosh.parihar8 at gmail.com>
wrote:
> Topic - Fuel
>
> Hi,
>
> My deployment is failing beacuse of following reason :
>
> Verification failed.
> Method verify_networks. Network verification not avaliable because nodes
> ["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for
> the details
>
> anybody can help here ?
>
>
>
> On Thu, Sep 17, 2015 at 3:42 PM, <
> openstack-dev-request at lists.openstack.org> wrote:
>
>> Send OpenStack-dev mailing list submissions to
>> openstack-dev at lists.openstack.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> or, via email, send a message with subject or body 'help' to
>> openstack-dev-request at lists.openstack.org
>>
>> You can reach the person managing the list at
>> openstack-dev-owner at lists.openstack.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of OpenStack-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: [Congress] CLI equivalent (Alex Yip)
>> 2. Re: [relmgt] PTL non-candidacy (Thomas Goirand)
>> 3. [Trove] PTL Candidacy (Craig Vyvial)
>> 4. Re: [Congress] PTL candidacy (Ramki_Krishnan at Dell.com)
>> 5. [storlets] Review requests suggestion (Eran Rom)
>> 6. Re: [cinder] LVM snapshot performance issue -- why isn't thin
>> provisioning the default? (Duncan Thomas)
>> 7. Re: [puppet] service default value functions (Cody Herriges)
>> 8. Re: [cinder] LVM snapshot performance issue -- why isn't thin
>> provisioning the default? (Eric Harney)
>> 9. Re: [puppet][keystone] Choose domain names with 'composite
>> namevar' or 'meaningless name'? (Cody Herriges)
>> 10. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core
>> (Sheena Gregson)
>> 11. Re: [Fuel] Nominate Olga Gusarenko for fuel-docs core
>> (Dmitry Borodaenko)
>> 12. [ironic] PTL candidacy (Devananda van der Veen)
>> 13. [oslo][doc] Oslo doc sprint 9/24-9/25 (James Carey)
>> 14. [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas
>> core team (Doug Wiegley)
>> 15. Re: [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team (Al Miller)
>> 16. Re: [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team (Eichberger, German)
>> 17. Re: [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team (Phillip Toohill)
>> 18. [QA] Meeting Thursday September 17th at 9:00 UTC (GHANSHYAM MANN)
>> 19. Re: [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team (Kyle Mestery)
>> 20. [gate] requirement conflict on Babel breaks grenade jobs
>> (Armando M.)
>> 21. [Cue] PTL Candidacy (Vipul Sabhaya)
>> 22. Re: [Barbican] Providing service user read access to all
>> tenant's certificates (Vijay Venkatachalam)
>> 23. Re: [Barbican] Providing service user read access to all
>> tenant's certificates (Vijay Venkatachalam)
>> 24. Re: ceilometer code debugging (gord chung)
>> 25. Re: [Congress] PTL candidacy (Rui Chen)
>> 26. Re: how to get current memory utilization of an instance
>> (Abhishek Talwar)
>> 27. [all][gate] grende jobs failing. (Tony Breeds)
>> 28. [i18n] PTL candidacy (Ying Chun Guo)
>> 29. [defcore] Scoring for DefCore 2016.01 Guideline (Chris Hoge)
>> 30. Re: [all][gate] grende jobs failing. (Tony Breeds)
>> 31. [Glance] PTL candidacy (Nikhil Komawar)
>> 32. Re: [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team (Samuel Bercovici)
>> 33. Re: [Magnum] API response on k8s failure (Ton Ngo)
>> 34. [dragonflow] Low OVS version for Ubuntu (Li Ma)
>> 35. Re: [neutron] RFE process question (Li Ma)
>> 36. [oslo][oslo.config] Reloading configuration of service (mhorban)
>> 37. [neutron] Please help review this RFE (Li Ma)
>> 38. Re: [dragonflow] Low OVS version for Ubuntu (Sudipto Biswas)
>> 39. [oslo][oslo.config] Reloading configuration of service (mhorban)
>> 40. Re: [puppet] service default value functions (Yanis Guenane)
>> 41. Re: [Fuel] Bugs which we should accept in 7.0 after Hard Code
>> Freeze (Adam Heczko)
>> 42. Re: [all][gate] grende jobs failing. (Tony Breeds)
>> 43. questions about nova compute monitors extensions (Hou Gang HG Liu)
>> 44. Re: [dragonflow] Low OVS version for Ubuntu (Gal Sagie)
>> 45. Re: [cinder] LVM snapshot performance issue -- why isn't thin
>> provisioning the default? (Duncan Thomas)
>> 46. [magnum][ptl] Magnum PTL Candidacy (Hongbin Lu)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 16 Sep 2015 19:47:57 +0000
>> From: Alex Yip <ayip at vmware.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Congress] CLI equivalent
>> Message-ID: <1442433064831.38322 at vmware.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Try this:
>>
>> openstack congress policy row list classification error?
>>
>>
>>
>> ________________________________
>> From: Shiv Haris <sharis at Brocade.com>
>> Sent: Wednesday, September 16, 2015 12:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Congress] CLI equivalent
>>
>> Do we have a CLI way for doing the equivalent of:
>>
>> $ curl -X GET localhost:1789/v1/policies/classification/tables/error/rows
>> As described in the tutorial:
>>
>>
>> https://github.com/openstack/congress/blob/master/doc/source/tutorial-tenant-sharing.rst#listing-policy-violations
>> <
>> 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=
>> >
>>
>> -Shiv
>>
>> From: Tim Hinrichs [mailto:tim at styra.com]
>> Sent: Thursday, September 10, 2015 8:41 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Congress] Ending feature freeze
>>
>> Hi all,
>>
>> 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:
>>
>> 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.
>>
>> https://review.openstack.org/#/c/220707/
>>
>> 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.
>>
>> 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.
>>
>> // pull down the latest changes for master
>> $ git checkout master
>> $ git pull
>>
>> // create a local branch for stable/liberty and switch to it
>> $ git checkout origin/stable/liberty -b stable/liberty
>>
>> // cherry-pick your change from master onto the local stable/liberty
>> // The -x records the original <sha1 from master> in the commit msg
>> $ git cherry-pick -x <sha1 from master>
>>
>> // Push to review and specify the stable/liberty branch.
>> // Notice in gerrit that the branch is stable/liberty, not master
>> $ git review stable/liberty
>>
>> // Once your change to stable/liberty gets merged, fetch all the new
>> // changes.
>>
>> // switch to local version of stable/liberty
>> $ git checkout stable/liberty
>>
>> // fetch all the new changes to all the branches
>> $ git fetch origin
>>
>> // update your local branch
>> $ git rebase origin/stable/liberty
>>
>> Tim
>>
>>
>>
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/52432cf9/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 16 Sep 2015 22:01:33 +0200
>> From: Thomas Goirand <zigo at debian.org>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [relmgt] PTL non-candidacy
>> Message-ID: <55F9CA9D.2060408 at debian.org>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 09/16/2015 11:33 AM, Thierry Carrez wrote:
>> > Hi everyone,
>> >
>> > I have been handling release management for OpenStack since the
>> > beginning of this story, well before Release Management was a program or
>> > a project team needing a proper elected PTL. Until recently it was
>> > largely a one-man job. But starting with this cycle, to accommodate the
>> > Big Tent changes, we grew the team significantly, to the point where I
>> > think it is healthy to set up a PTL rotation in the team.
>> >
>> > I generally think it's a good thing to change the PTL for a team from
>> > time to time. That allows different perspectives, skills and focus to be
>> > brought to a project team. That lets you take a step back. That allows
>> > to recognize the efforts and leadership of other members, which is
>> > difficult if you hold on the throne. So I decided to put my foot where
>> > my mouth is and apply those principles to my own team.
>> >
>> > That doesn't mean I won't be handling release management for Mitaka, or
>> > that I won't ever be Release Management PTL again -- it's just that
>> > someone else will take the PTL hat for the next cycle, drive the effort
>> > and be the most visible ambassador of the team.
>> >
>> > Cheers,
>>
>> If we are switching from you to Doug, we'll be switching from an awesome
>> person to another also awesome one. Thanks for all the work.
>>
>> Cheers,
>>
>> Thomas
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 16 Sep 2015 20:03:35 +0000
>> From: Craig Vyvial <cp16net at gmail.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [Trove] PTL Candidacy
>> Message-ID:
>> <
>> CAOK58XR8X7MMRXgj4EKJ7ZtQfPNDxgWuqJHs6XMLpQmZhakH1A at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> My name is Craig Vyvial and I'd like run for Mitaka Trove PTL. I've been
>> working on Trove for about 4 years and a core member for about 2 years.
>> Over the this time, Trove has continued to evolve and the community has
>> grown. My passion is to help make sure that Trove continues this trend and
>> guide Trove to be a world class database as a service for OpenStack.
>>
>> Trove started just provisioing a single MySQL instance and has grown to a
>> total of 12 datastores to date with a few datastores supporting
>> clustering.
>> I think there are a few areas that make sense with this kind of growth
>> that
>> we should focus on during Mitaka.
>>
>> * Add CI tests for other datastores with third patry CI systems. With so
>> many new datastores available within Trove, we need to make sure that we
>> stabilize tests on multiple datastores.
>>
>> * Advance the features of Trove for all datastores.
>>
>> * Simplify the installation of Trove that includes install, upgrades,
>> building guest images, and management operations.
>>
>> * Continue the trend of growing the trove community.
>>
>> As PTL of Trove, I will help the project move forward by looking to the
>> community for input and making sure we take steps toward making OpenStack
>> a
>> better platform as well as Trove the ideal solution for users looking for
>> a
>> database as a service solution.
>>
>>
>> Thanks,
>>
>> - Craig Vyvial
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a772ad0a/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 16 Sep 2015 15:09:32 -0500
>> From: <Ramki_Krishnan at Dell.com>
>> To: <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Congress] PTL candidacy
>> Message-ID:
>> <
>> DF91EBC32A031943A8B78D81D40122BC0404D4FB5E at AUSX7MCPC103.AMER.DELL.COM>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1 and looking forward to see you in Tokyo.
>>
>> Thanks,
>> Ramki
>>
>> From: Tim Hinrichs [mailto:tim at styra.com]
>> Sent: Tuesday, September 15, 2015 1:23 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Congress] PTL candidacy
>>
>> Hi all,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> See you all in Tokyo!
>> Tim
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/6ed1879f/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 16 Sep 2015 23:19:18 +0300
>> From: Eran Rom <ERANR at il.ibm.com>
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] [storlets] Review requests suggestion
>> Message-ID:
>> <
>> OFAF5DC7D8.6A8D3CF1-ONC2257EC2.006F4467-C2257EC2.006FA199 at il.ibm.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi All,
>> I suggest that until we have functional tests in place, each commit
>> message should specify that:
>> (1) For a code change - the system tests were executed successfully with
>> the change -
>> (2) For installation related change that the installation was tested with
>> this.
>>
>> I further suggest that if the commit message does not have this the
>> reviewer can assume that the committer forgot to do these and -1
>> Opinions?
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/451c3b22/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 16 Sep 2015 23:25:18 +0300
>> From: Duncan Thomas <duncan.thomas at gmail.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue
>> -- why isn't thin provisioning the default?
>> Message-ID:
>> <CAOyZ2aGZn6a-eRUv_TmB2r4s2FD719NONvBihzS4hNEKhNC=
>> Nw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On 16 Sep 2015 20:42, "yang, xing" <xing.yang at emc.com> wrote:
>>
>> > On 9/16/15, 1:20 PM, "Eric Harney" <eharney at redhat.com> wrote:
>>
>> > >This sounds like a good idea, I'm just not sure how to structure it yet
>> > >without creating a very confusing set of config options.
>> >
>> > I?m thinking we could have a prefix with vendor name for this and it
>> also
>> > requires documentation by driver maintainers if they are using a
>> different
>> > config option. I proposed a topic to discuss about this at the summit.
>>
>> We already have per-backend config values in cinder.conf. I'm not sure how
>> the config code will need to be structured to achieve it, but ideally I'd
>> like a single config option that can be:
>>
>> (i) set in the default section if desired
>> (in) overridden in the per driver section, and (iii) have a default set in
>> each driver.
>>
>> I don't think oslo.config lets us do (I'll) yet though.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/a06a65d2/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 16 Sep 2015 13:35:47 -0700
>> From: Cody Herriges <cody at puppetlabs.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>, Hunter Haugen
>> <hunter at puppetlabs.com>
>> Subject: Re: [openstack-dev] [puppet] service default value functions
>> Message-ID: <55F9D2A3.8010006 at puppetlabs.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Emilien Macchi wrote:
>> >
>> > On 09/16/2015 12:53 PM, Alex Schultz wrote:
>> >> Hey puppet folks,
>> >>
>> >> Based on the meeting yesterday[0], I had proposed creating a parser
>> >> function called is_service_default[1] to validate if a variable matched
>> >> our agreed upon value of '<SERVICE DEFAULT>'. This got me thinking
>> >> about how can we maybe not use the arbitrary string throughout the
>> >> puppet that can not easily be validated. So I tested creating another
>> >> puppet function named service_default[2] to replace the use of
>> '<SERVICE
>> >> DEFAULT>' throughout all the puppet modules. My tests seemed to
>> >> indicate that you can use a parser function as parameter default for
>> >> classes.
>> >>
>> >> I wanted to send a note to gather comments around the second function.
>> >> When we originally discussed what to use to designate for a service's
>> >> default configuration, I really didn't like using an arbitrary string
>> >> since it's hard to parse and validate. I think leveraging a function
>> >> might be better since it is something that can be validated via tests
>> >> and a syntax checker. Thoughts?
>> >
>> > Let me add your attempt to make it work in puppet-cinder:
>> > https://review.openstack.org/#/c/224277
>> >
>> > I like the proposal, +1.
>> >
>>
>> Hunter,
>>
>> Do you off hand know what kind of overhead is generated by this?
>>
>>
>> --
>> Cody
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 931 bytes
>> Desc: OpenPGP digital signature
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/e4c794ef/attachment-0001.pgp
>> >
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Wed, 16 Sep 2015 16:43:30 -0400
>> From: Eric Harney <eharney at redhat.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [cinder] LVM snapshot performance issue
>> -- why isn't thin provisioning the default?
>> Message-ID: <55F9D472.5000505 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 09/16/2015 04:25 PM, Duncan Thomas wrote:
>> > On 16 Sep 2015 20:42, "yang, xing" <xing.yang at emc.com> wrote:
>> >
>> >> On 9/16/15, 1:20 PM, "Eric Harney" <eharney at redhat.com> wrote:
>> >
>> >>> This sounds like a good idea, I'm just not sure how to structure it
>> yet
>> >>> without creating a very confusing set of config options.
>> >>
>> >> I?m thinking we could have a prefix with vendor name for this and it
>> also
>> >> requires documentation by driver maintainers if they are using a
>> different
>> >> config option. I proposed a topic to discuss about this at the summit.
>> >
>> > We already have per-backend config values in cinder.conf. I'm not sure
>> how
>> > the config code will need to be structured to achieve it, but ideally
>> I'd
>> > like a single config option that can be:
>> >
>> > (i) set in the default section if desired
>> > (in) overridden in the per driver section, and (iii) have a default set
>> in
>> > each driver.
>> >
>> > I don't think oslo.config lets us do (I'll) yet though.
>> >
>>
>> I think there may be other issues to sort through to do that.
>> Currently, at least some options set in [DEFAULT] don't apply to
>> per-driver sections, and require you to set them in the driver section
>> as well.
>>
>> If we keep that behavior (which I think is broken, personally), then
>> trying to do option (iii) may be pretty confusing, because the deployer
>> won't know which of the global vs. driver defaults are actually going to
>> be applied.
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Wed, 16 Sep 2015 13:58:30 -0700
>> From: Cody Herriges <cody at puppetlabs.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [puppet][keystone] Choose domain names
>> with 'composite namevar' or 'meaningless name'?
>> Message-ID: <55F9D7F6.2000604 at puppetlabs.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> I wrote my first composite namevar type a few years and ago and all the
>> magic is basically a single block of code inside the type...
>>
>>
>> https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L145-L169
>>
>> It basically boils down to these three things:
>>
>> * Pick your namevars
>> (
>> https://github.com/puppetlabs/puppetlabs-java_ks/blob/master/lib/puppet/type/java_ks.rb#L49-L64
>> )
>> * Pick a delimiter
>> - Personally I'd use @ here since we are talking about domains
>> * Build your self.title_patterns method, accounting for delimited names
>> and arbitrary names.
>>
>> While it looks like the README never got updated, the java_ks example
>> supports both meaningful titles and arbitrary ones.
>>
>> java_ks { 'activemq_puppetca_keystore':
>> ensure => latest,
>> name => 'puppetca',
>> certificate => '/etc/puppet/ssl/certs/ca.pem',
>> target => '/etc/activemq/broker.ks',
>> password => 'puppet',
>> trustcacerts => true,
>> }
>>
>> java_ks { 'broker.example.com:/etc/activemq/broker.ks':
>> ensure => latest,
>> certificate =>
>> '/etc/puppet/ssl/certs/broker.example.com.pe-internal-broker.pem',
>> private_key =>
>> '/etc/puppet/ssl/private_keys/broker.example.com.pe-internal-broker.pem',
>> password => 'puppet',
>> }
>>
>> You'll notice the first being an arbitrary title and the second
>> utilizing a ":" as a delimiter and omitting the name and target
>> parameters.
>>
>> Another code example can be found in the package type.
>>
>>
>> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L268-L291
>> .
>>
>> --
>> Cody
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 931 bytes
>> Desc: OpenPGP digital signature
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/73c3b7f1/attachment-0001.pgp
>> >
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Wed, 16 Sep 2015 16:22:02 -0500
>> From: Sheena Gregson <sgregson at mirantis.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Cc: Olga Gusarenko <ogusarenko at mirantis.com>
>> Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for
>> fuel-docs core
>> Message-ID: <7e65f8d3e04579ba78d3c14bdea4dcb2 at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1 Thanks for being a great docs contributor and community member.
>>
>>
>>
>> *From:* Alexander Adamov [mailto:aadamov at mirantis.com]
>> *Sent:* Monday, September 14, 2015 5:44 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> *Cc:* Olga Gusarenko <ogusarenko at mirantis.com>
>> *Subject:* Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for
>> fuel-docs
>> core
>>
>>
>>
>> +1
>>
>> Nice!)
>>
>>
>>
>> Alexander
>>
>>
>>
>> On Fri, Sep 11, 2015 at 8:19 PM, Dmitry Borodaenko <
>> dborodaenko at mirantis.com>
>> wrote:
>>
>> +1
>>
>> Great work Olga!
>>
>>
>>
>> On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya <
>> ipovolotskaya at mirantis.com>
>> wrote:
>>
>> Fuelers,
>>
>>
>>
>> I'd like to nominate Olga Gusarenko for the fuel-docs-core.
>>
>>
>>
>> She has been doing great work and made a great contribution
>>
>> into Fuel documentation:
>>
>>
>> http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs
>>
>> It's high time to grant her core reviewer's rights in fuel-docs.
>>
>> Core reviewer approval process definition:
>> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>>
>>
>>
>> --
>>
>> Best regards,
>>
>>
>> Irina
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9d63d703/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 11
>> Date: Wed, 16 Sep 2015 14:28:59 -0700
>> From: Dmitry Borodaenko <dborodaenko at mirantis.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Cc: Olga Gusarenko <ogusarenko at mirantis.com>
>> Subject: Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for
>> fuel-docs core
>> Message-ID:
>> <
>> CAM0pNLMoTfdds-N6mXpeeE360YopScqbgbW3e-hUhPT3oysKvA at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 5 days and no objections: welcome to Fuel Docs core reviewers! Keep up
>> the great work!
>>
>> On Fri, Sep 11, 2015 at 11:07 AM, Irina Povolotskaya
>> <ipovolotskaya at mirantis.com> wrote:
>> > Fuelers,
>> >
>> > I'd like to nominate Olga Gusarenko for the fuel-docs-core.
>> >
>> > She has been doing great work and made a great contribution
>> > into Fuel documentation:
>> >
>> >
>> http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs
>> >
>> > It's high time to grant her core reviewer's rights in fuel-docs.
>> >
>> > Core reviewer approval process definition:
>> > https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>> >
>> > --
>> > Best regards,
>> >
>> > Irina
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Dmitry Borodaenko
>>
>>
>>
>> ------------------------------
>>
>> Message: 12
>> Date: Wed, 16 Sep 2015 21:35:51 +0000
>> From: Devananda van der Veen <devananda.vdv at gmail.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [ironic] PTL candidacy
>> Message-ID:
>> <
>> CAExZKEoTHvniLyO09cesYsB9VEOg3frfo_YM_qHpQfXVJgdZkg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi all,
>>
>> ( repost from https <https://review.openstack.org/223753>://
>> <https://review.openstack.org/223753>review.openstack.org
>> <https://review.openstack.org/223753>/223753
>> <https://review.openstack.org/223753> )
>>
>> It's that time again, where encumbent PTLs are supposed to write about
>> what
>> features or changes they accomplished and what goals they have for the
>> next
>> cycle.
>>
>> I'm not going to do that this time.
>>
>> Even you though you may have read similar things from others (either in
>> this or in previous cycles) I'm going to reiterate something. Contrary to
>> being the technical lead, OpenStack requires the PTL to do a whole slew of
>> less glamorous things (or delegate them to other people).
>>
>> - launchpad monkey
>> - midcycle coordinator
>> - release coordinator
>> - public speaker
>> - cross project liaison
>> - vendor buffer
>> - cat wrangler
>>
>> Historically, PTL meant "project technical lead", but as OpenStack grew,
>> we
>> / the TC realized that it is more^D^D^D^Ddifferent than that, and so now
>> the acronym is defined as "project team lead" [0]. And that is much more
>> representative of the responsibilities a PTL has today. In short, being
>> PTL
>> and the lead architect for a successful/sizable project at the same time
>> ==
>> two full time jobs.
>>
>> Even before I was doing anything internal at HP, it seemed like my
>> upstream
>> work was never done since I was trying to be both the team and tech leads
>> for Ironic. That said, it was also extremely rewarding to found this
>> project and exercise my social and organizational skills in building a
>> community around it. I could not be more satisfied with the results -- all
>> of you make Ironic much more awesome than I could have done alone. That's
>> the point, after all :)
>>
>> Last election cycle, I stepped down from the TC so that I could have more
>> time for my roles as tech and team lead, and to focus on some internal
>> work
>> (yup, still three jobs). That other work, for better or for worse, took a
>> greater tax on me than I had anticipated, and my activity upstream has
>> suffered (sorry!). This has created room for many of the other core
>> developers, who've been around the project almost as long as I have, to
>> come forward and fill in the gaps I left in the project management. And
>> that's really awesome. Thank you all.
>>
>> I am thrilled that more of the project responsibilities are being handled
>> by Jim, Ruby, Chris, Lucas, and everyone else now. They are all leading
>> different areas in their own ways. As PTLs, each would bring a different
>> viewpoint to the project's day-to-day operations, and if they were to run,
>> I would support all of them (even though we disagree some times). Today,
>> there are multiple people who could run the project in my stead, and that
>> makes me very happy.
>>
>> If elected, I promise to continue enabling the core team to do more
>> without
>> my direct involvement, to continue leading in the technical vision for the
>> project, and liaising with vendors and operators to ensure the project
>> matures in such a way that it meets their needs.
>>
>> If you believe I've done a great job as PTL and want me to continue doing
>> what I've been doing, then please re-elect me. (*)
>>
>> If you'd like to see a change of pace, please don't hesitate to elect
>> another PTL :)
>>
>> Thank you,
>> Devananda
>>
>> (*) If you think I haven't done a great job as PTL, I invite you to tell
>> me
>> how you think I could do better. For the sake of the election archives,
>> please don't reply to this email.
>>
>> [0]
>>
>> https://github.com/openstack/governance/commit/319fae1ea13775d16f865f886db0388e42cd0d1b
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/da01d068/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 13
>> Date: Wed, 16 Sep 2015 16:40:27 -0500
>> From: James Carey <bellerophon at flyinghorsie.com>
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] [oslo][doc] Oslo doc sprint 9/24-9/25
>> Message-ID:
>> <CAHjMoV0vx=
>> mEcnsJHyq29hwoAA6oq9fwdXYqVFGttVCwLEeicg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> In order to improve the Oslo libraries documentation, the Oslo team is
>> having a documentation sprint from 9/24 to 9/25.
>>
>> We'll kick things off at 14:00 UTC on 9/24 in the
>> #openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].
>>
>> All help is appreciated. If you can help or have suggestions for
>> areas of focus, please update the etherpad.
>>
>> [0] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/dd80ed8e/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 14
>> Date: Wed, 16 Sep 2015 16:33:59 -0600
>> From: Doug Wiegley <dougwig at parksidesoftware.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson
>> for neutron-lbaas core team
>> Message-ID:
>> <FB4D40AE-3C76-4069-81D7-6593C5AFEB89 at parksidesoftware.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hi all,
>>
>> As the Lieutenant of the advanced services, I nominate Michael Johnson to
>> be a member of the neutron-lbaas core reviewer team.
>>
>> Review stats are in line with other cores[2], and Michael has been
>> instrumental in both neutron-lbaas and octavia.
>>
>> Existing cores, please vote +1/-1 for his addition to the team (that?s
>> Brandon, Phil, Al, and Kyle.)
>>
>> Thanks,
>> doug
>>
>> 1.
>> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>> 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 15
>> Date: Wed, 16 Sep 2015 22:40:51 +0000
>> From: Al Miller <ajmiller at ajmiller.net>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
>> Johnson for neutron-lbaas core team
>> Message-ID:
>>
>> <EFBE70D7D09F0A4397281F770E1802DBA87A2451 at uc2-exmbx15-n1.UC2.Chicago.Hostway
>> >
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1
>>
>> Al
>>
>>
>> > -----Original Message-----
>> > From: Doug Wiegley [mailto:dougwig at parksidesoftware.com]
>> > Sent: Wednesday, September 16, 2015 3:34 PM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
>> > neutron-lbaas core team
>> >
>> > Hi all,
>> >
>> > As the Lieutenant of the advanced services, I nominate Michael Johnson
>> to
>> > be a member of the neutron-lbaas core reviewer team.
>> >
>> > Review stats are in line with other cores[2], and Michael has been
>> > instrumental in both neutron-lbaas and octavia.
>> >
>> > Existing cores, please vote +1/-1 for his addition to the team (that?s
>> Brandon,
>> > Phil, Al, and Kyle.)
>> >
>> > Thanks,
>> > doug
>> >
>> > 1. http://docs.openstack.org/developer/neutron/policies/core-
>> > reviewers.html#core-review-hierarchy
>> > 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>> >
>> >
>> > __________________________________________________________
>> > ________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-
>> > request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ------------------------------
>>
>> Message: 16
>> Date: Wed, 16 Sep 2015 22:44:27 +0000
>> From: "Eichberger, German" <german.eichberger at hpe.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
>> Johnson for neutron-lbaas core team
>> Message-ID: <D21F3EA2.17995%german.eichberger at hpe.com>
>> Content-Type: text/plain; charset="Windows-1252"
>>
>> Great news! From the Octavia end I totally support that choice?
>>
>> German
>>
>> On 9/16/15, 3:40 PM, "Al Miller" <ajmiller at ajmiller.net> wrote:
>>
>> >+1
>> >
>> >Al
>> >
>> >
>> >> -----Original Message-----
>> >> From: Doug Wiegley [mailto:dougwig at parksidesoftware.com]
>> >> Sent: Wednesday, September 16, 2015 3:34 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
>> >> neutron-lbaas core team
>> >>
>> >> Hi all,
>> >>
>> >> As the Lieutenant of the advanced services, I nominate Michael Johnson
>> >>to
>> >> be a member of the neutron-lbaas core reviewer team.
>> >>
>> >> Review stats are in line with other cores[2], and Michael has been
>> >> instrumental in both neutron-lbaas and octavia.
>> >>
>> >> Existing cores, please vote +1/-1 for his addition to the team (that?s
>> >>Brandon,
>> >> Phil, Al, and Kyle.)
>> >>
>> >> Thanks,
>> >> doug
>> >>
>> >> 1. http://docs.openstack.org/developer/neutron/policies/core-
>> >> reviewers.html#core-review-hierarchy
>> >> 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>> >>
>> >>
>> >> __________________________________________________________
>> >> ________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: OpenStack-dev-
>> >> request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> >__________________________________________________________________________
>> >OpenStack Development Mailing List (not for usage questions)
>> >Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 17
>> Date: Wed, 16 Sep 2015 23:03:22 +0000
>> From: Phillip Toohill <phillip.toohill at RACKSPACE.COM>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
>> Johnson for neutron-lbaas core team
>> Message-ID:
>> <
>> 45ef3cc22894430a97c42f7693fe843b at 543881-IEXCH01.ror-uc.rackspace.com>
>> Content-Type: text/plain; charset="Windows-1252"
>>
>> +1
>>
>> Phillip V. Toohill III
>> Software Developer
>>
>> phone: 210-312-4366
>> mobile: 210-440-8374
>>
>>
>> ________________________________________
>> From: Eichberger, German [german.eichberger at hpe.com]
>> Sent: Wednesday, September 16, 2015 5:44 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson
>> for neutron-lbaas core team
>>
>> Great news! From the Octavia end I totally support that choice?
>>
>> German
>>
>> On 9/16/15, 3:40 PM, "Al Miller" <ajmiller at ajmiller.net> wrote:
>>
>> >+1
>> >
>> >Al
>> >
>> >
>> >> -----Original Message-----
>> >> From: Doug Wiegley [mailto:dougwig at parksidesoftware.com]
>> >> Sent: Wednesday, September 16, 2015 3:34 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
>> >> neutron-lbaas core team
>> >>
>> >> Hi all,
>> >>
>> >> As the Lieutenant of the advanced services, I nominate Michael Johnson
>> >>to
>> >> be a member of the neutron-lbaas core reviewer team.
>> >>
>> >> Review stats are in line with other cores[2], and Michael has been
>> >> instrumental in both neutron-lbaas and octavia.
>> >>
>> >> Existing cores, please vote +1/-1 for his addition to the team (that?s
>> >>Brandon,
>> >> Phil, Al, and Kyle.)
>> >>
>> >> Thanks,
>> >> doug
>> >>
>> >> 1. http://docs.openstack.org/developer/neutron/policies/core-
>> >> reviewers.html#core-review-hierarchy
>> >> 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>> >>
>> >>
>> >> __________________________________________________________
>> >> ________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: OpenStack-dev-
>> >> request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> >__________________________________________________________________________
>> >OpenStack Development Mailing List (not for usage questions)
>> >Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ------------------------------
>>
>> Message: 18
>> Date: Thu, 17 Sep 2015 08:56:53 +0900
>> From: GHANSHYAM MANN <ghanshyammann at gmail.com>
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] [QA] Meeting Thursday September 17th at 9:00
>> UTC
>> Message-ID:
>> <CACE3TKW=Ldh4=Xg0Ggo4apepB0_4Nu=
>> 6ZdKNsmf0kWsBbw2EeA at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi everyone,
>>
>> Please reminder that the weekly OpenStack QA team IRC meeting will be
>> Thursday, September 17th at 9:00 UTC in the #openstack-meeting channel.
>>
>> The agenda for the meeting can be found here:
>> https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
>> Anyone is welcome to add an item to the agenda.
>>
>> To help people figure out what time 9:00 UTC is in other timezones,
>> meeting will be at:
>>
>> 04:00 EDT
>> 18:00 JST
>> 18:30 ACST
>> 11:00 CEST
>> 04:00 CDT
>> 02:00 PDT
>>
>>
>> --
>> Thanks & Regards
>> Ghanshyam Mann
>>
>>
>>
>> ------------------------------
>>
>> Message: 19
>> Date: Wed, 16 Sep 2015 20:07:17 -0500
>> From: Kyle Mestery <mestery at mestery.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael
>> Johnson for neutron-lbaas core team
>> Message-ID:
>> <
>> CAL3VkVz13METd05kGu25-ao7nvhqTod09a3PwAG9jnsRV3yYOw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1
>>
>> On Wed, Sep 16, 2015 at 5:33 PM, Doug Wiegley <
>> dougwig at parksidesoftware.com>
>> wrote:
>>
>> > Hi all,
>> >
>> > As the Lieutenant of the advanced services, I nominate Michael Johnson
>> to
>> > be a member of the neutron-lbaas core reviewer team.
>> >
>> > Review stats are in line with other cores[2], and Michael has been
>> > instrumental in both neutron-lbaas and octavia.
>> >
>> > Existing cores, please vote +1/-1 for his addition to the team (that?s
>> > Brandon, Phil, Al, and Kyle.)
>> >
>> > Thanks,
>> > doug
>> >
>> > 1.
>> >
>> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>> > 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>> >
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/ff556612/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 20
>> Date: Wed, 16 Sep 2015 18:07:57 -0700
>> From: "Armando M." <armamig at gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [gate] requirement conflict on Babel breaks
>> grenade jobs
>> Message-ID:
>> <CAK+RQebrUhwYS=
>> Uvey_PRHH+ASUQ5o67XouSOigH33BLxU4u_A at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> https://bugs.launchpad.net/grenade/+bug/1496650
>>
>> HTH
>> Armando
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/9de4060e/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 21
>> Date: Wed, 16 Sep 2015 18:16:17 -0700
>> From: Vipul Sabhaya <vipuls at gmail.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [Cue] PTL Candidacy
>> Message-ID:
>> <
>> CAHC46jtoP5A5Pe7w26LFb+A06W6icr1jeEYJgPsFQDbjw21CXQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> This will be the first official PTL election for Cue, and I would be
>> honored to serve another term leading the project for the M Cycle.
>>
>> Cue is a relatively new project in Openstack, and was approved into the
>> Big
>> Tent during Liberty. I have been involved with Cue from the beginning,
>> from initial POC to having a product that is production worthy. In my
>> past
>> life, i?ve been a member of the Trove Core team.
>>
>> During the Liberty Cycle, Cue has become a solid product with a control
>> plane that can manage per-tenant RabbitMQ Clusters. We spent a lot of
>> time
>> beefing up our tests, and boast >90% unit test coverage. We also added
>> Tempest tests, and Rally tests, including gating jobs for both. Our
>> documentation has also been revamped considerably, and allows new
>> contributors to ramp up quickly with the project.
>>
>> During the M cycle, I would like to focus on building a community and
>> getting additional contributors to Cue. I would also like to focus the
>> team on multi-broker support, including adding Kafka as a broker that is
>> managed by Cue.
>>
>> I believe Cue has come a long ways in a short time, and going forward have
>> the opportunity accelerate the growth in terms of features, quality, and
>> adoption.
>>
>> Thanks for your consideration!
>> -Vipul
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/470c335c/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 22
>> Date: Thu, 17 Sep 2015 01:57:44 +0000
>> From: Vijay Venkatachalam <Vijay.Venkatachalam at citrix.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Barbican] Providing service user read
>> access to all tenant's certificates
>> Message-ID:
>> <
>> 26B082831A2B1A4783604AB89B9B2C080E89F58B at SINPEX01CL02.citrite.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> How does lbaas do step 2?
>> It does not have the privilege for that secret/container using the
>> service user.
>> 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?
>>
>> Thanks,
>> Vijay V.
>>
>> From: Fox, Kevin M [mailto:Kevin.Fox at pnnl.gov]
>> Sent: 16 September 2015 19:24
>> To: OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Barbican] Providing service user read
>> access to all tenant's certificates
>>
>> 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?
>>
>> Thanks,
>> Kevin
>>
>> ________________________________
>> From: Vijay Venkatachalam
>> Sent: Tuesday, September 15, 2015 7:06:39 PM
>> To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>)
>> Subject: [openstack-dev] [Barbican] Providing service user read access to
>> all tenant's certificates
>> Hi,
>> Is there a way to provide read access to a certain user to
>> all secrets/containers of all project/tenant's certificates?
>> 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.
>>
>> Today's LBaaS users are following the below mentioned
>> process
>>
>> 1. tenant's creator/admin user uploads a certificate info as secrets
>> and container
>>
>> 2. User then have to create ACLs for the LBaaS service user to
>> access the containers and secrets
>>
>> 3. User creates LB config with the container reference
>>
>> 4. LBaaS plugin using the service user will then access container
>> reference provided in LB config and proceeds to implement.
>>
>> 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.
>>
>> Thanks,
>> Vijay V.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/1e0b37b1/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 23
>> Date: Thu, 17 Sep 2015 02:02:44 +0000
>> From: Vijay Venkatachalam <Vijay.Venkatachalam at citrix.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Barbican] Providing service user read
>> access to all tenant's certificates
>> Message-ID:
>> <
>> 26B082831A2B1A4783604AB89B9B2C080E89F5CB at SINPEX01CL02.citrite.net>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> 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.
>> For ex. "admin" user with "admin" role in "admin" project is the service
>> user in devstack for LBaaS.
>>
>> --Vijay
>>
>>
>>
>> From: Dave McCowan (dmccowan) [mailto:dmccowan at cisco.com]
>> Sent: 16 September 2015 18:36
>> To: OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Barbican] Providing service user read
>> access to all tenant's certificates
>>
>> 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.
>>
>> --Dave McCowan
>>
>> From: Vijay Venkatachalam <Vijay.Venkatachalam at citrix.com<mailto:
>> Vijay.Venkatachalam at citrix.com>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org<mailto:
>> openstack-dev at lists.openstack.org>>
>> Date: Tuesday, September 15, 2015 at 10:06 PM
>> To: "OpenStack Development Mailing List (
>> openstack-dev at lists.openstack.org<mailto:
>> openstack-dev at lists.openstack.org>)" <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>
>> Subject: [openstack-dev] [Barbican] Providing service user read access to
>> all tenant's certificates
>>
>> Hi,
>> Is there a way to provide read access to a certain user to
>> all secrets/containers of all project/tenant's certificates?
>> 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.
>>
>> Today's LBaaS users are following the below mentioned
>> process
>>
>> 1. tenant's creator/admin user uploads a certificate info as secrets
>> and container
>>
>> 2. User then have to create ACLs for the LBaaS service user to
>> access the containers and secrets
>>
>> 3. User creates LB config with the container reference
>>
>> 4. LBaaS plugin using the service user will then access container
>> reference provided in LB config and proceeds to implement.
>>
>> 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.
>>
>> Thanks,
>> Vijay V.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/9a2da227/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 24
>> Date: Wed, 16 Sep 2015 22:10:23 -0400
>> From: gord chung <gord at live.ca>
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] ceilometer code debugging
>> Message-ID: <BLU437-SMTP72E84AA275C3A5BD36B6DDE5A0 at phx.gbl>
>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>
>> hi,
>>
>> i'm not familiar with eclipse+pydev but you should be able to run that
>> command as is in terminal
>>
>> './tools/ceilometer-test-event.py'
>>
>> the main question i have is what are you trying to debug? that script,
>> to be honest, does not do much. it seems to just test the event
>> conversion functionality. you might find some useful information in the
>> dev docs[1] if you have questions about Ceilometer. if it's a pydev
>> specific question you might want to generalise your subject line to have
>> more eyes.
>>
>> [1] http://docs.openstack.org/developer/ceilometer
>>
>>
>> On 16/09/15 08:42 AM, Nanda Devi Sahu wrote:
>> > Hello,
>> >
>> > I am trying to debug Ceilometer code taken from git. I have configured
>> > Eclipse with Pydev for the same. The configuration seems to be fine
>> > but when I do a debug of the code it shows to be running but I do not
>> > see the flow of the code. LIke the main thread and the following
>> threads.
>> >
>> > Attached is the debug prespective view where the run is working
>> > without any code stack.
>> >
>> > Could you please suggest what Am I missing to get the flow. I have
>> > also attached the debug configuration image for reference.
>> >
>> >
>> > Regards,
>> > Nanda.
>> >
>> > *L&T Technology Services Ltd*
>> >
>> > www.LntTechservices.com <http://www.lnttechservices.com/>
>> >
>> > This Email may contain confidential or privileged information for the
>> > intended recipient (s). If you are not the intended recipient, please
>> > do not use or disseminate the information, notify the sender and
>> > delete it from your system.
>> >
>> >
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> gord
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/34169458/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 25
>> Date: Thu, 17 Sep 2015 10:27:40 +0800
>> From: Rui Chen <chenrui.momo at gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Congress] PTL candidacy
>> Message-ID:
>> <CABHH=
>> 5D0-XNG1ebhYEbBSvHf8BMfs0x8tMxw36d9j_AMS5qrEQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1
>>
>> Tim is an excellent and passionate leader, go ahead, Congress :-)
>>
>>
>> 2015-09-17 4:09 GMT+08:00 <Ramki_Krishnan at dell.com>:
>>
>> > +1 and looking forward to see you in Tokyo.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Ramki
>> >
>> >
>> >
>> > *From:* Tim Hinrichs [mailto:tim at styra.com]
>> > *Sent:* Tuesday, September 15, 2015 1:23 PM
>> > *To:* OpenStack Development Mailing List (not for usage questions)
>> > *Subject:* [openstack-dev] [Congress] PTL candidacy
>> >
>> >
>> >
>> > Hi all,
>> >
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> > See you all in Tokyo!
>> >
>> > Tim
>> >
>> >
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6eb8e3f/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 26
>> Date: Thu, 17 Sep 2015 10:00:38 +0530
>> From: Abhishek Talwar <abhishek.talwar at tcs.com>
>> To: "OpenStack Development Mailing List \(not for usage questions\)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] how to get current memory utilization of
>> an instance
>> Message-ID:
>> <
>> OFE5715C3D.F5F7173F-ON65257EC3.0018C71C-65257EC3.0018C722 at tcs.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/17a718cc/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 27
>> Date: Thu, 17 Sep 2015 15:01:53 +1000
>> From: Tony Breeds <tony at bakeyournoodle.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [all][gate] grende jobs failing.
>> Message-ID: <20150917050153.GE68449 at thor.bakeyournoodle.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi all,
>> The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
>> kilo. The
>> juno global-requirements for Babel are not compatible with kilo so
>> nothing can
>> get through grenade :(
>>
>> We're working it
>> https://bugs.launchpad.net/oslo.utils/+bug/1496678
>>
>> Yours Tony.
>>
>> [1] https://review.openstack.org/#/c/223909/ sorry :(
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: not available
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/67c713cc/attachment-0001.pgp
>> >
>>
>> ------------------------------
>>
>> Message: 28
>> Date: Thu, 17 Sep 2015 13:22:23 +0800
>> From: Ying Chun Guo <guoyingc at cn.ibm.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [i18n] PTL candidacy
>> Message-ID:
>> <
>> OF4A738412.8EF74BD1-ON48257EC3.001CE928-48257EC3.001D8417 at cn.ibm.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> I, also known as "Daisy", would like to continue as the I18n PTL,
>> if you will have me.
>>
>> I had a great time as the I18n PTL in Liberty,
>> working with the whole team to make important changes happen.
>> I would like to have another term to stabilize them.
>>
>> In June, I18n project became an official project.
>> Translation contributors are treated the same as code contributors.
>> 30+ active translators are regarded as ATC's in Liberty.
>> It is a great milestone for I18n team and translators.
>> We are getting more official and more visible.
>>
>> In July, we started the trial of the new tool -Zanata,
>> which is a open source based and OpenStack hosted translation website.
>> After a long time evaluation and improvement, in September,
>> we officially migrated translations to Zanata.
>> 49 language teams are created and 130+ translators have been registered.
>> Now we are running Liberty translation there.
>>
>> In September, we kicked off Liberty translation, which is under
>> processing now. It's the first time that we translate on top of Zanata,
>> the first time that we include Nova in the translation plan,
>> and the first time we formally use two phases of string freeze.
>> I'm trying my best to make sure everything is running well.
>> When Liberty translation is done, we could review how we did and how
>> to make them better.
>>
>> In Mitaka, I'm going to focus on blew items:
>>
>> 1. Get official recoginization to translators
>> I'm going to add translation metric in stackalytics,
>> and automate the process to award active translators "ATC"
>>
>> 2. Improve translation quality
>> I'm going to improve the list of translation terminologies, promote
>> its broad adoption in all language teams.
>> I'm going to boost the enablement of translation check website.
>>
>> 3. Better cooperation with development team and documentation team
>>
>> I welcome any good ideas which could help the team to achieve
>> these goals. Hope to get your support for my PTL role in Mitaka.
>> I am honored to work with everyone to build up a better I18n project.
>>
>> Thank you.
>> Daisy
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/f4f33730/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> Message: 29
>> Date: Wed, 16 Sep 2015 22:26:17 -0700
>> From: Chris Hoge <chris at openstack.org>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [defcore] Scoring for DefCore 2016.01
>> Guideline
>> Message-ID: <0AC92343-7973-4015-A9C2-E8ADD1B5355B at openstack.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> The DefCore Committee is working on scoring capabilities for the upcoming
>> 2016.01 Guideline, a solid draft of which will be available at the Mitaka
>> summit for community review and will go to the Board of Directors for
>> approaval in Janaury [1]. The current 2015.07 Guideline [2] covers Nova,
>> Swift, and Keystone. Scoring for the upcoming Guideline may includes new
>> capabilities for Neutron, Glance, Cinder, and Heat, as well as
>> updated capabilities for Keystone and Nova.
>>
>> As part of our process, we want to encourage the development and user
>> communities to give feedback on the proposed capability categorizations
>> and how they are currently graded against the Defcore criteria [3].
>>
>> Capabilities we're currently considering for possible inclusion are:
>> Neutron: https://review.openstack.org/#/c/210080/
>> Glance: https://review.openstack.org/#/c/213353/
>> Cinder: https://review.openstack.org/#/c/221631/
>> Heat: https://review.openstack.org/#/c/216983/
>> Keystone: https://review.openstack.org/#/c/213330/
>> Nova: https://review.openstack.org/#/c/223915/
>>
>> We would especially like to thank the PTL's and technical community
>> members
>> who helped draft the proposed capabilities lists and provided
>> feedback--your input has been very helpful.
>>
>> [1]
>> http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/2015A.rst#n13
>> [2] http://git.openstack.org/cgit/openstack/defcore/tree/2015.07.json
>> [3]
>> http://git.openstack.org/cgit/openstack/defcore/tree/doc/source/process/CoreCriteria.rst
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 30
>> Date: Thu, 17 Sep 2015 15:34:30 +1000
>> From: Tony Breeds <tony at bakeyournoodle.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [all][gate] grende jobs failing.
>> Message-ID: <20150917053429.GF68449 at thor.bakeyournoodle.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Thu, Sep 17, 2015 at 03:01:53PM +1000, Tony Breeds wrote:
>> > Hi all,
>> > The recent relapse of oslo.utils 1.4.1[1] (for juno) is valid in
>> kilo. The
>> > juno global-requirements for Babel are not compatible with kilo so
>> nothing can
>> > get through grenade :(
>> >
>> > We're working it
>> > https://bugs.launchpad.net/oslo.utils/+bug/1496678
>>
>> Here's my best effort for right now.
>> https://review.openstack.org/#/c/224429/
>>
>> Yours Tony.
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: not available
>> URL: <
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/4fc3d53f/attachment-0001.pgp
>> >
>>
>> ------------------------------
>>
>> Message: 31
>> Date: Thu, 17 Sep 2015 01:58:59 -0400
>> From: Nikhil Komawar <nik.komawar at gmail.com>
>> To: OpenStack Development Mailing List
>> <openstack-dev at lists.openstack.org>
>> Subject: [openstack-dev] [Glance] PTL candidacy
>> Message-ID: <55FA56A3.4000001 at gmail.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hello everyone,
>>
>> I would like to herewith propose my candidacy for the role of Glance PTL
>> for the Mitaka release cycle.
>>
>> I. Personal Commitment
>>
>> I am a full time upstream OpenStacker at IBM and have recently
>> transitioned into this role with the condition that I will be given 100%
>> time to focus on community issues, development and help solve upstream
>> challenges. I am also committed to giving my full attention to Glance.
>> Not too long ago, I have had a few conversations with the PTLs of other
>> projects for either help them better use Glance or for dissolving the
>> issues they were facing in their projectsw. However, in this cycle I
>> would like to work with some of you in the capacity of inter-project
>> liaisons to help better understand the usage and stability of Glance in
>> respective areas and yet be involved with you in addressing those
>> issues. I know this is added work that must not go unrewarded so, I
>> would like to work out a plan with you that will enable distribution of
>> power (if with more power comes more responsibility, visa versa must
>> true, making it true claim). It has been enabled in Glance to some
>> extent & I have learnt other bigger projects implementing this. I would
>> like to make it a complete reality in Glance. I am also committed to
>> documenting and improving the current specs process and criterion that
>> will enable quicker turnaround time.
>>
>> At IBM, I have the pleasure of being part of team that has some of the
>> most outstanding OpenStackers and I hope to collaborate more with them
>> in Mitaka for solving (hard) problems.
>>
>> II. Liberty
>>
>> a) Stability
>>
>> Over 100 bugs were fixed in Liberty (including python-glanceclient,
>> glance_store and Glance servers) with a relatively small review team.
>> Glance is gradually improving momentum to help the different code
>> proposals get time-justice for code reviews. Some features in Kilo
>> introduced a number security bugs beyond expectations so, the further
>> development of those features has been slowed down and focus has been
>> shifted to fix the functionality, making it more stable and secure.
>> Experimental features showed a smooth progress and close to no issues of
>> such sort. A close eye on the reviews was kept to ensure so. Any spec
>> proposals that showed potential security risks, shake stability or
>> performance or refactor major parts of the code base were given a wait
>> signal.
>>
>> b) Performance
>>
>> I consider them as systematic optimizations and sometimes systematic
>> improvisations. Major disagreements on the path forward for optimizing
>> streaming workflows for images data have been sorted out. Many new
>> proposals were made however, due to lack of early time commitment from
>> developers they were unable to be seen through. Continued feedback
>> should be expected for similar proposals for glance_store in early Mitaka.
>>
>> c) Cross project communications & Process Evolution
>>
>> I have made an attempt to continually evolve our process to make it more
>> engaging and community friendly. Now there are three meetings weekly
>> that are a good place for collaboration on different aspects of Glance.
>> Either me or a member of the Glance community is at the weekly CPL
>> meeting to gather feedback from horizontal teams, cross project
>> decision/efforts etc. as well as input has been provided using Glance?s
>> perspective. I have had regular chats with Nova PTL on the outstanding
>> issues of the Images APIs and adoption of v2 Images API by Nova.
>> Feedback was provided at the DefCore mid-cycle as well as a welcoming
>> hand was presented for attending Glance mid-cycle (even virtually) for
>> those who could not make it. In Mitaka, I hope to continue
>> collaborating with the interested members there as well as in the other
>> projects. I would like to pay close personal attention to the pressing
>> matters that need short team resolution like the adoption of v2 API by
>> Nova and Images API suitable for DefCore. Unfortunately, any of the
>> existing (half) attempts at fixing this issue have been wasted as they
>> were breaking some of the fundamental aspects of project. This matter
>> would need wider input for a fine resolution and a change that would not
>> break the world; of-course compromise is very likely for some but
>> doesn?t need to be fundamentally disjoint with the newly established
>> DefCore standard. It was realized early that a half baked attempt of
>> making such a critical change would break core of Glance so, I have been
>> contemplating on the future of the project. More clarity of thought has
>> been accomplished during the conversations with the TC members, PTLs,
>> Product WG liaisons etc. and I will continue to gather more feedback in
>> Mitaka. It has been a pleasure to be part of (collaborating with) teams
>> that help build very large cloud deployments and I find that experience
>> valuable for solving this complicated matter. Not only upstream but at
>> IBM too, I plan to closely interact with the technical and product
>> leaders of the Public and Private cloud deployment to help solve such
>> issues. My team at IBM enables me to have such interactions with
>> veterans of OpenStack.
>>
>> III. Direction
>>
>> a) Short Term Goals
>> There are four short team goals that seem important right away: DefCore
>> requirements; Nova and Cinder v2 adoption/stability; cadence between
>> developer and reviewer bandwidth; better collaboration via
>> documentation, CPL & inter project liaisons power distribution.
>>
>> b) Mid Term Goals
>> I think it?s vital that we pin down subtle aspects of v2 API in
>> mid-term, primarily focus on Images however, at the same time ensure
>> that all of our APIs are efficient and performant.
>>
>> The concept of tasks needs to have a clear picture in all the developers
>> as well as operators viewpoints. There are equally compelling arguments
>> to make them user centric only, admin only and open to both. Most
>> important use cases will be taken into account and a plan for tasks will
>> be setup.
>>
>> Some of the operators and active developers wish to focus on performance
>> improvement and reliaiblity of image data delivery ? so this will be
>> another very important mid-term goal.
>>
>> Definition of core fundamentals like immutability of images & Glance
>> architecture seems critical. Also, it is necessary to be aware about the
>> side-effects of feature proposals that can potentially lead to breaking
>> changes. It has come to my notice that many a times such proposals are
>> made and the proposers find it difficult to grasp how the change could
>> affect Glance. We will try to solve this issue via collaboration and
>> documentation.
>>
>> c) Long Term Goals
>>
>> The long term goals follow the mid-term goals. Solidification of the
>> Images v2 API and planning long term support for the same. There?s
>> already some work happening to set a direction for this.
>>
>> Artifacts and a generic repository ? as per Glance?s mission statement,
>> this is an important goal. A generic data asset service would be an
>> excellent one stop shop for users. Possibly evolving in to a Marketplace
>> like stage for many of OpenStack assets (Artifacts).
>>
>> Addressing storage and retrieval of Images issues for smaller size data
>> (Image record in DB) and for larger blobs of data (stored in the backend
>> store) ? this may be termed as performance problem but as a long term
>> objective it will be a clear separation of concerns and give ability to
>> operators to work on image or artifact data in a efficient manner.
>>
>> VII. Community
>>
>> Glance community has been tradit
>
> --
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151005/a7c59388/attachment-0001.html>
More information about the OpenStack-dev
mailing list