[openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49
santosh parihar
santosh.parihar8 at gmail.com
Mon Oct 5 08:54:45 UTC 2015
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 traditionally known to be friendly to help new
> developers join and it avoids the influx vs. outflux issues. Keeping the
> long term objectives in mind this remains important. I will try to keep
> it a conducive environment for all concerned individuals. Without losing
> hind sight help focus on the short term goals, I will enable specific
> individuals to make important calls if it helps move forward with
> pressing issues.
>
> VIII. Solving Hard Problems
>
> a) Collaboration
>
> The tradition of pre-summit, within cycle video and face-to-face syncs
> will be continued. Inputs of the CPLs, inter-project liaisons will be
> encouraged and welcomed. Glance representatives will engage in certain
> important projects regarding images related subject matter. Artifacts
> representatives will engage in other working groups to make the API more
> usable and adoptable. I plan to keep working with the DefCore committee
> and PTLs to help bridge the gap of overlapping issues. OpenStack is a
> diverse community and so is the Glance team. So, we will focus on
> keeping weekly syncs addressing important issues interactively. Overall,
> collaboration will be one of the most vital component of this cycle.
>
> b) Themed Focus
>
> The most important themes that come to mind at this point of time are:
> getting a standard API for DefCore, interaction with Nova team to enable
> v2 adoption, documentation of the features and processes (this will also
> help with collaboration), Artifacts and it?s API, performance and
> reliablilty & stability. A sub-team leader would be chosen for each of
> these themes and periodic sync would be made effective for a good team
> effort.
>
> c) Core reviewer bandwidth, their influx and outflux
>
> Glance has had the mis-fortune for losing important and talented
> developers time and again due to commitment changes (and not a result of
> drive away from the team). We will continue to keep the doors open for
> them and if any of the super active OpenStackers wish to become core in
> short window, there will be a easier process of doing so. This will help
> fix any outstanding bugs, keep the gate steady and help a good momentum
> for the release of libraries. Good collaborators have always been good
> drivers & it would be wise to continue in that direction. Good
> developers have been engaged in Liberty to become part of Glance and I
> will continue to do so for Mitaka.
>
> d) One OpenStack
>
> No matter how easy it is to define solo project priorities, we all live
> in the single OpenStack realm. Operators have to deploy Glance alongside
> other OpenStack services and there is a level of understanding that will
> be put in into action while defining Glance priorities so that other
> projects are not severely affected. I believe in ?One OpenStack & a
> unified vision? and hope you are with me.
>
>
>
> Thank you for your consideration in allowing me to continue serving as
> PTL for Mitaka cycle.
>
> Nikhil Komawar
>
>
>
> ------------------------------
>
> Message: 32
> Date: Thu, 17 Sep 2015 06:06:57 +0000
> From: Samuel Bercovici <SamuelB at Radware.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:
> <F36E8145F2571242A675F56CF6096456A069A64E at ILMB1.corp.radware.com>
> Content-Type: text/plain; charset="utf-8"
>
> And then they were 6 =D>
>
>
> -Sam.
>
> -----Original Message-----
> From: Doug Wiegley [mailto:dougwig at parksidesoftware.com]
> Sent: Thursday, September 17, 2015 1:34 AM
> 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: 33
> Date: Wed, 16 Sep 2015 23:07:26 -0700
> From: "Ton Ngo" <ton at us.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] API response on k8s failure
> Message-ID: <201509170607.t8H67XWo014648 at d01av04.pok.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hi Ryan,
> There is a bug opened with a similar failure symptom, although I am
> not sure if the cause is the same:
> https://bugs.launchpad.net/magnum/+bug/1481889
>
> Trying to use kubectl to deploy the V1 manifest, I get this error message:
> Error: unable to recognize "redis-master.yaml": no object named "Pod" is
> registered
>
> Clearly the error handling from the k8s handler needs to be improved. If
> the bug above is different from what you found, I think opening a new bug
> would be best.
>
> Ton Ngo,
>
>
>
>
> From: Adrian Otto <adrian.otto at rackspace.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 09/14/2015 05:34 PM
> Subject: Re: [openstack-dev] [Magnum] API response on k8s failure
>
>
>
> Ryan,
>
> Thanks for sharing this. Sorry you got out to a bumpy start. I suggest you
> do file a bug for this against magnum and we can decide how best to handle
> it. I can not tell from your email what the kubectl would do with the same
> input. We might have an opportunity to make both better.
>
> If you need guidance for how to file a bug, feel free to email me directly
> and I can point you in the right direction.
>
> Thanks,
>
> Adrian
>
> > On Sep 14, 2015, at 3:05 PM, Ryan Rossiter <rlrossit at linux.vnet.ibm.com>
> wrote:
> >
> > I was giving a devstacked version of Magnum a try last week, and from a
> new user standpoint, I hit a big roadblock that caused me a lot of
> confusion. Here's my story:
> >
> > I was attempting to create a pod in a k8s bay, and I provided it with an
> sample manifest from the Kubernetes repo. The Magnum API then returned the
> following error to me:
> >
> > ERROR: 'NoneType' object has no attribute 'host' (HTTP 500)
> >
> > I hunted down the error to be occurring here [1]. The k8s_api call was
> going bad, but conductor was continuing on anyways thinking the k8s API
> call went fine. I dug through the API calls to find the true cause of the
> error:
> >
> > {u'status': u'Failure', u'kind': u'Status', u'code': 400, u'apiVersion':
> u'v1beta3', u'reason': u'BadRequest', u'message': u'Pod in version v1
> cannot be handled as a Pod: no kind "Pod" is registered for version "v1"',
> u'metadata': {}}
> >
> > It turned out the error was because the manifest I was using had
> apiVersion v1, not v1beta3. That was very unclear by Magnum originally
> sending the 500.
> >
> > This all does occur within a try, but the k8s API isn't throwing any sort
> of exception that can be caught by [2]. Was this caused by a regression in
> the k8s client? It looks like the original intention of this was to catch
> something going wrong in k8s, and then forward on the message & error code
> on to let the magnum API return that.
> >
> > My question here is: does this classify as a bug? This happens in more
> places than just the pod create. It's changing around API returns (quite a
> few of them), and I don't know how that is handled in the Magnum project.
> If we want to have this done as a blueprint, I can open that up and target
> it for Mitaka, and get to work. If it should be opened up as a bug, I can
> also do that and start work on it ASAP.
> >
> > [1]
>
> https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L88-L108
>
> > [2]
>
> https://github.com/openstack/magnum/blob/master/magnum/conductor/handlers/k8s_conductor.py#L94
>
> >
> > --
> > Thanks,
> >
> > Ryan Rossiter (rlrossit)
> >
> >
> >
> __________________________________________________________________________
> > 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/3a0c21e5/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: graycol.gif
> Type: image/gif
> Size: 105 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/3a0c21e5/attachment-0001.gif
> >
>
> ------------------------------
>
> Message: 34
> Date: Thu, 17 Sep 2015 14:52:36 +0800
> From: Li Ma <skywalker.nick at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
> Message-ID:
> <CALFEDVcXE18WAWS=
> 64sOQkyLn6ob2R0Nx+G2jSP3xOo37Zcubg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi all,
>
> I tried to run devstack to deploy dragonflow, but I failed with lower
> OVS version.
>
> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
> which is much lower than the required version 2.3.1+?
>
> So, can anyone provide a Ubuntu repository that contains the correct
> OVS packages?
>
> Thanks,
> --
>
> Li Ma (Nick)
> Email: skywalker.nick at gmail.com
>
>
>
> ------------------------------
>
> Message: 35
> Date: Thu, 17 Sep 2015 15:13:17 +0800
> From: Li Ma <skywalker.nick at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] RFE process question
> Message-ID:
> <CALFEDVdLfL9FD01=JbXUJxqfxSF_9T=
> KGr8UkkD2FRzSPESUoA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> A reasonable user story. Other than tag, a common description field
> for Neutron resources is also usable.
>
> I submitted a RFE bug for review:
> https://bugs.launchpad.net/neutron/+bug/1496705
>
>
>
> ------------------------------
>
> Message: 36
> Date: Thu, 17 Sep 2015 10:14:30 +0300
> From: mhorban <mhorban at mirantis.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration
> of service
> Message-ID: <55FA6856.1 at mirantis.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Josh,
>
> > Sounds like a useful idea if projects can plug-in themselves into the
> > reloading process. I definitely think there needs to be a way for
> > services to plug-in to this, although I'm not quite sure it will be
> > sufficient at the current time though.
> >
> > An example of why:
> >
> > -
> >
>
> https://github.com/openstack/cinder/blob/stable/kilo/cinder/volume/__init__.py#L24
>
> > (unless this module is purged from python and reloaded it will likely
> > not reload correctly).
> >
> > Likely these can all be easily fixed (I just don't know how many of
> > those exist in the various projects); but I guess we have to start
> > somewhere so getting the underlying code able to be reloaded is a first
> > step of likely many.
>
> Each of openstack component should contain code responsible for
> reloading such objects.
> What objects will be reloaded? It depends of inspire and desire of
> developers/users.
> Writing such code is a second step.
>
> Marian
>
>
>
> ------------------------------
>
> Message: 37
> Date: Thu, 17 Sep 2015 15:16:50 +0800
> From: Li Ma <skywalker.nick at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [neutron] Please help review this RFE
> Message-ID:
> <CALFEDVeR=s81c9ux7bWDv=+
> x8YqwemUCSMfBmMhHYRky_ja7xA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Neutron folks,
>
> I'd like to introduce a pure python-driven network configuration
> library to Neutron. A discussion just started in the RFE ticket [1].
> I'd like to get feedback on this proposal.
>
> [1]: https://bugs.launchpad.net/neutron/+bug/1492714
>
> Take a look and let me know your thoughts.
> --
>
> Li Ma (Nick)
> Email: skywalker.nick at gmail.com
>
>
>
> ------------------------------
>
> Message: 38
> Date: Thu, 17 Sep 2015 12:54:36 +0530
> From: Sudipto Biswas <sbiswas7 at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
> Message-ID: <55FA6AB4.5030605 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> On Thursday 17 September 2015 12:22 PM, Li Ma wrote:
> > Hi all,
> >
> > I tried to run devstack to deploy dragonflow, but I failed with lower
> > OVS version.
> >
> > I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
> > which is much lower than the required version 2.3.1+?
> >
> > So, can anyone provide a Ubuntu repository that contains the correct
> > OVS packages?
>
> Why don't you just build the OVS you want from here:
> http://openvswitch.org/download/
>
> > Thanks,
>
>
>
>
> ------------------------------
>
> Message: 39
> Date: Thu, 17 Sep 2015 10:26:28 +0300
> From: mhorban <mhorban at mirantis.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [oslo][oslo.config] Reloading configuration
> of service
> Message-ID: <55FA6B24.5000602 at mirantis.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Doug,
>
> > Rather than building hooks into oslo.config, why don't we build them
> > into the thing that is catching the signal. That way the app can do lots
> > of things in response to a signal, and one of them might be reloading
> > the configuration.
>
> Hm... Yes... It is really stupid idea to put reloading hook into
> oslo.config.
> I'll move that hook mechanism into oslo.service. oslo.service is
> responsible for catching/handling signals.
>
> Is it enough to have one callback function? Or should I must add ability
> to register many different callback functions?
>
> What is your point of view?
>
> Marian
>
>
>
> ------------------------------
>
> Message: 40
> Date: Thu, 17 Sep 2015 09:28:11 +0200
> From: Yanis Guenane <yguenane at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [puppet] service default value functions
> Message-ID: <55FA6B8B.1090203 at redhat.com>
> Content-Type: text/plain; charset=windows-1252
>
>
>
> On 09/16/2015 09:39 PM, 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.
> Alex, thank you for this proposal.
>
> I like your approach :
>
> * as it will make writing manifest more idiomatic.
>
> $foo = service_default() with if is_service_default($foo) { } reads
> better than
> $foo = '<SERVICE DEFAULT>' with if $foo == '<SERVICE DEFAULT>'.
>
> * if for any reason, hopefully this shouldn't happen but we need to
> change the value,
> it will happen only on few places. (less commit to review)
>
> * the end result is the exact same one as the one we have today.
>
> For me it's a go, let's see what the other have to say about it
>
> Thank you,
>
> >
> >> Thanks,
> >> -Alex
> >>
> >> [0]
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
> >> [1] https://review.openstack.org/#/c/223672
> >> [2] https://review.openstack.org/#/c/224187
> >>
> >>
> >>
> __________________________________________________________________________
> >> 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: 41
> Date: Thu, 17 Sep 2015 09:48:59 +0200
> From: Adam Heczko <aheczko at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Bugs which we should accept in 7.0
> after Hard Code Freeze
> Message-ID:
> <CAJciqMyBC_=
> 5AmWjwHK53Wa9pZPL77vctm-f-MEGyADh5hHvFA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi, I'd like to ask for fixing these security related bugs in stable/7.0
> branch:
>
> https://bugs.launchpad.net/fuel/+bug/1496407
> https://bugs.launchpad.net/fuel/+bug/1488732
>
> Both are fuel-library related tasks, it is Apache2 and NTPD configuration
> lifting.
>
> Thanks,
>
> Adam
>
> On Tue, Sep 15, 2015 at 12:19 AM, Mike Scherbakov <
> mscherbakov at mirantis.com>
> wrote:
>
> > Thanks Andrew.
> > Team, if there are any disagreements - let's discuss it. Otherwise, I
> > think we should be just strict and follow defined process. We can deliver
> > high priority bugfixes in updates channel later if needed.
> >
> > I hope that reasoning is clear for everything. Every bugfix has a
> > potential to break something. It's basically a risk.
> >
> > On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov <amaksimov at mirantis.com>
> > wrote:
> >
> >> Hi Everyone!
> >>
> >> I would like to reiterate the bugfix process after Hard Code Freeze.
> >> According to our HCF definition [1] we should only merge fixes for
> >> *Critical* bugs to *stable/7.0* branch, High and lower priority bugs
> >> should NOT be accepted to *stable/7.0* branch anymore.
> >> Also we should accept patches for critical bugs to *stable/7.0* branch
> >> only after the corresponding patchset with same ChangeID was accepted
> into
> >> master.
> >>
> >> [1] - https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze
> >>
> >> Regards,
> >> Andrey Maximov
> >> Fuel Project Manager
> >>
> __________________________________________________________________________
> >> 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
> >>
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> __________________________________________________________________________
> > 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
> >
> >
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/eb282b28/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 42
> Date: Thu, 17 Sep 2015 18:03:53 +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: <20150917080353.GA72725 at thor.bakeyournoodle.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Sep 17, 2015 at 03:34:30PM +1000, Tony Breeds wrote:
> > 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/
>
> For those playing along at home the new plan is to:
> 1. Release a version of oslo.utils with the kilo requirements
> This needs to be done as a revert because 1.4.2 must follow 1.4.1
> - https://review.openstack.org/#/c/224472/
> 2 Tag that as 1.4.2
>
> Then the gate should be okay again, while the stable team (and me) work
> out how
> to fix juno without breaking kilo.
>
> 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/1a6cbef7/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 43
> Date: Thu, 17 Sep 2015 16:13:24 +0800
> From: Hou Gang HG Liu <liuhoug at cn.ibm.com>
> To: jaypipes at gmail.com
> Cc: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] questions about nova compute monitors
> extensions
> Message-ID:
> <
> OFDB00AB2C.88557596-ON48257EC3.002CD29A-48257EC3.002D4C16 at cn.ibm.com>
> Content-Type: text/plain; charset="gb2312"
>
> Hi Jay,
>
> I notice nova compute monitor now only tries to load monitors with
> namespace "nova.compute.monitors.cpu", and only one monitor in one
> namespace can be enabled(
> https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py
> ).
>
> Is there a plan to make MonitorHandler.NAMESPACES configurable or just
> hard code constraint as it is now? And how to make compute monitor support
> user defined as it was?
>
> Thanks!
> B.R
>
> Hougang Liu ?????
> Developer - IBM Platform Resource Scheduler
> Systems and Technology Group
>
> Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023 ??
> ????????42?????3?
> E-mail: liuhoug at cn.ibm.com Xian, Shaanxi
> Province 710075, China
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 360 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/cd7ad50b/attachment-0001.gif
> >
>
> ------------------------------
>
> Message: 44
> Date: Thu, 17 Sep 2015 11:17:09 +0300
> From: Gal Sagie <gal.sagie at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Eran Gampel
> <Eran.Gampel at huawei.com>
> Subject: Re: [openstack-dev] [dragonflow] Low OVS version for Ubuntu
> Message-ID:
> <
> CAG9LJa554aMjAF06G_8U5AiGTOuZ1ODtci+6ykfNO-Vaet_B4Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Li Ma,
>
> Dragonflow uses OpenFlow1.3 to communicate with OVS and thats why we need
> OVS 2.3.1.
> As suggested you can build it from source.
> For Fedora 21 OVS2.3.1 is part of the default yum repository.
>
> You can ping me on IRC (gsagie at freenode) if you need any additional help
> how
> to compile OVS.
>
> Thanks
> Gal.
>
> On Thu, Sep 17, 2015 at 10:24 AM, Sudipto Biswas <
> sbiswas7 at linux.vnet.ibm.com> wrote:
>
> >
> >
> > On Thursday 17 September 2015 12:22 PM, Li Ma wrote:
> >
> >> Hi all,
> >>
> >> I tried to run devstack to deploy dragonflow, but I failed with lower
> >> OVS version.
> >>
> >> I used Ubuntu 14.10 server, but the official package of OVS is 2.1.3
> >> which is much lower than the required version 2.3.1+?
> >>
> >> So, can anyone provide a Ubuntu repository that contains the correct
> >> OVS packages?
> >>
> >
> > Why don't you just build the OVS you want from here:
> > http://openvswitch.org/download/
> >
> > Thanks,
> >>
> >
> >
> >
> __________________________________________________________________________
> > 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
> >
>
>
>
> --
> Best Regards ,
>
> The G.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/7ba72dce/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 45
> Date: Thu, 17 Sep 2015 12:00:22 +0300
> From: Duncan Thomas <duncan.thomas at gmail.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:
> <CAOyZ2aFFnsrY6AaMe7bYrff5iGfQHcM7ZZtP=_
> yXYxY-75aqSw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 16 September 2015 at 23:43, Eric Harney <eharney at redhat.com> wrote:
>
> > 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.
> >
>
> This is extremely confusing behaviour. Do you have any examples? I'm not
> sure if we can fix it without breaking people's existing configs but I
> think it is worth trying. I'll add it to the list of things to talk about
> briefly in Tokyo.
>
> --
> Duncan Thomas
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/e6e722e1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 46
> Date: Thu, 17 Sep 2015 07:18:32 +0000
> From: Hongbin Lu <hongbin.lu at huawei.com>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [magnum][ptl] Magnum PTL Candidacy
> Message-ID:
> <
> 0957CD8F4B55C0418161614FEC580D6BCE4960 at SZXEMI503-MBS.china.huawei.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
>
> I would like to announce my candidacy for the PTL position of Magnum.
>
> 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.
>
> To address the question why I am a good candidate for Magnum, here are the
> key reasons:
> * I contributed a lot to Magnum's code base and feature set.
> * I am familiar with every aspects of the project, and understand both the
> big picture and technical details.
> * I will have time and resources to take the PTL responsibility, mostly
> because I am a full time allocated to this project.
> * I love container.
> * I care the project.
> Here is more details of my involvement in the project:
> http://stackalytics.com/?module=magnum-group
> https://github.com/openstack/magnum/graphs/contributors
>
> In my opinion, Magnum needs to focus on the following in the next cycle:
> * Production ready: Work on everything that are possible to make it happen.
> * Baremetal: Complete and optimize our Ironic integration to enable
> running containers on baremetal.
> * Container network: deliver a network solution that is high performance
> and customizable.
> * UI: Integrate with Horizon to give users a friendly interface to use
> Magnum.
> * Pluggable COE: A pluggable design is a key feature for users to
> customize Magnum, which is always the case.
> * Grow community: Attract more contributors to contribute to Magnum.
>
> 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.
>
> I hope you will give me an opportunity to serve as Magnum's PTL in the
> next cycle.
>
> Best regards,
> Hongbin
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/6a41cb83/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 41, Issue 49
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151005/871ad199/attachment-0001.html>
More information about the OpenStack-dev
mailing list
