Re: [openstack-dev] [oslo] UUID sentinel needs a home
+1 for oslotest Jay Pipes 于2018年8月23日周四 上午11:24写道： > > On Wed, Aug 22, 2018, 10:13 AM Eric Fried wrote: > >> For some time, nova has been using uuidsentinel [1] which conveniently >> allows you to get a random UUID in a single LOC with a readable name >> that's the same every time you reference it within that process (but not >> across processes). Example usage: [2]. >> >> We would like other projects (notably the soon-to-be-split-out placement >> project) to be able to use uuidsentinel without duplicating the code. So >> we would like to stuff it in an oslo lib. >> >> The question is whether it should live in oslotest [3] or in >> oslo_utils.uuidutils [4]. The proposed patches are (almost) the same. >> The issues we've thought of so far: >> >> - If this thing is used only for test, oslotest makes sense. We haven't >> thought of a non-test use, but somebody surely will. >> - Conversely, if we put it in oslo_utils, we're kinda saying we support >> it for non-test too. (This is why the oslo_utils version does some extra >> work for thread safety and collision avoidance.) >> - In oslotest, awkwardness is necessary to avoid circular importing: >> uuidsentinel uses oslo_utils.uuidutils, which requires oslotest. In >> oslo_utils.uuidutils, everything is right there. >> > > My preference is to put it in oslotest. Why does oslo_utils.uuidutils > import oslotest? That makes zero sense to me... > > -jay > > - It's a... UUID util. If I didn't know anything and I was looking for a >> UUID util like uuidsentinel, I would look in a module called uuidutils >> first. >> >> We hereby solicit your opinions, either by further discussion here or as >> votes on the respective patches. >> >> Thanks, >> efried >> >> [1] >> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/uuidsentinel.py >> [2] >> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/functional/api/openstack/placement/db/test_resource_provider.py#L109-L115 >> [3] https://review.openstack.org/594068 >> [4] https://review.openstack.org/594179 >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Proposing Zane Bitter as oslo.service core
+1 2018-08-04 2:58 GMT+08:00 Davanum Srinivas : > +1 from me! > On Fri, Aug 3, 2018 at 12:58 PM Ben Nemec wrote: > > > > Hi, > > > > Zane has been doing some good work in oslo.service recently and I would > > like to add him to the core team. I know he's got a lot on his plate > > already, but he has taken the time to propose and review patches in > > oslo.service and has demonstrated an understanding of the code. > > > > Please respond with +1 or any concerns you may have. Thanks. > > > > -Ben > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core
+1 2018-08-01 23:38 GMT+08:00 John Dennis : > On 08/01/2018 09:27 AM, Doug Hellmann wrote: > >> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config >> during the Rocky cycle to add driver support. Based on that work, >> and a discussion we have had since then about general cleanup needed >> in oslo.config, I think he would make a good addition to the >> oslo.config review team. >> >> Please indicate your approval or concerns with +1/-1. >> > > +1 > > > -- > John Dennis > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Summit onboarding and project update slides
Thanks Ben 2018-05-31 6:48 GMT+08:00 Ben Nemec : > As promised in the sessions, here are the slides that were presented: > > https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding > > https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update > > The font in the onboarding one got a little funny in the conversion, so if > you want to see the original that is more readable let me know and I can > send it to you. > > -Ben > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] A worked example of adding privsep to an OpenStack project
Thanks Michael, that's very useful. 2018-05-08 10:05 GMT+08:00 Michael Still <mi...@stillhq.com>: > Hi, > > further to last week's example of how to add a new privsep'ed call in > Nova, I thought I'd write up how to add privsep to a new OpenStack project. > I've used Cinder in this worked example, but it really applies to any > project which wants to do things with escalated permissions. > > The write up is here -- http://www.madebymikal.com/ > adding-oslo-privsep-to-a-new-project-a-worked-example/ > > Michael > > -- > Did this email leave you hoping to cause me pain? Good news! > Sponsor me in city2surf 2018 and I promise to suffer greatly. > http://www.madebymikal.com/city2surf-2018/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] proposing Ken Giusti for oslo-core
+1 2018-03-27 0:58 GMT+08:00 Joshua Harlow <harlo...@fastmail.com>: > +1 > > > Ben Nemec wrote: > >> +1! >> >> On 03/26/2018 10:52 AM, Doug Hellmann wrote: >> >>> Ken has been managing oslo.messaging for ages now but his participation >>> in the team has gone far beyond that single library. He regularly >>> attends meetings, including the PTG, and has provided input into several >>> of our team decisions recently. >>> >>> I think it's time we make him a full member of the oslo-core group. >>> >>> Please respond here with a +1 or -1 to indicate your opinion. >>> >>> Thanks, >>> Doug >>> >>> >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ALL][PTLs] [Community goal] Toggle the debug option at runtime
2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <sla...@kaplonski.pl>: > Hi, > > I took care of implementation of [1] in Neutron and I have couple > questions to about this goal. > > 1. Should we only change "restart_method" to mutate as is described in [2] > ? I did already something like that in [3] - is it what is expected? > Yes , let's the only thing. we need test if that if it works . > > 2. How I can check if this change is fine and config option are mutable > exactly? For now when I change any config option for any of neutron agents > and send SIGHUP to it it is in fact "restarted" and config is reloaded even > with this old restart method. > good question, we indeed thought this question when we proposal the goal. But It seems difficult to test that consuming projects like Neutron automatically. > > 3. Should we add any automatic tests for such change also? Any examples of > such tests in other projects maybe? > There is no example for tests now, we only have some unit tests in oslo.service . > > [1] https://governance.openstack.org/tc/goals/rocky/enable- > mutable-configuration.html > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html > [3] https://review.openstack.org/#/c/554259/ > > — > Best regards > Slawek Kaplonski > sla...@kaplonski.pl > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?
There is no special reasons that ListOpt doesn't allow parameter, PortOpt also uses parameter 'choices'. PortOpt and StrOpt only accept one value and use this parameter to double check value is valid which is in the 'choices'. What's your use case for ListOpt, just make sure the value(a list) is part of 'choices' ? Maybe we need another parameter to distinguish 2018-03-26 17:49 GMT+08:00 Kashyap Chamarthy <kcham...@redhat.com>: > Hi there, > > I was looking at oslo_config/cfg.py[*], and the StrOpt() class has > 'choices' parameter, to allow a sequence of valid values / tuples of > valid values for descriptions. > > However, I don't see the same 'choices' parameter for the ListOpt() > class. Out of curiosity, is there a reason to not add it for ListOpt() > too? > > [*] https://git.openstack.org/cgit/openstack/oslo.config/ > tree/oslo_config/cfg.py#n1271 > > -- > /kashyap > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [oslo] new unified limit library
Yeah, we need a unified limit library , from oslo side we need a spec according to new library process. The spec will be useful to track the background and update oslo wiki [1] [0] http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html [1] https://wiki.openstack.org/wiki/Oslo 2018-03-07 22:58 GMT+08:00 Lance Bragstad <lbrags...@gmail.com>: > Hi all, > > Per the identity-integration track at the PTG [0], I proposed a new oslo > library for services to use for hierarchical quota enforcement [1]. Let > me know if you have any questions or concerns about the library. If the > oslo team would like, I can add an agenda item for next weeks oslo > meeting to discuss. > > Thanks, > > Lance > > [0] https://etherpad.openstack.org/p/unified-limits-rocky-ptg > [1] https://review.openstack.org/#/c/550491/ > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime
Hi ALL, TC approved the goal [0] a week ago , so it's time to finish the work. we also have a short discussion in oslo meeting at PTG, find more details in [1] , we use storyboard to check the goal in https://storyboard.openstack.org/#!/story/2001545. It's appreciated PTL set the owner in time . Feel free to reach me( gcb) in IRC if you have any questions. [0] https://review.openstack.org/#/c/534605/ [1] https://etherpad.openstack.org/p/oslo-ptg-rocky From line 175 -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] PTL candidacy
Thanks for stepping up to take the role, Ben looking forward to making oslo better with your lead . 2018-02-03 2:43 GMT+08:00 Ben Nemec <openst...@nemebean.com>: > Hi, > > I am submitting my candidacy for Oslo PTL. > > I have been an Oslo core since 2014 and although my involvement in the > project > has at times been limited by other responsibilities, I have always kept up > on > what is going on in Oslo. > > For the Rocky cycle my primary goals would be: > > * Continue to maintain the stability and quality of the existing Oslo code. > > * Help drive the oslo.config improvements that are underway. > > * Encourage new and existing contributors to ensure the long-term health of > the project. > > I am, of course, always open to suggestions on other areas of focus for > Oslo. > > Thanks. > > -Ben > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance][oslo][requirements] [ironic]oslo.serialization fails with glance
add Ironic team in the loop the revert patch got -1 from ironic folks , more details please see the comments in https://review.openstack.org/534736 The possible solution is to figure out why the change break Glance's unit test. which side should be fixed. 2018-01-17 20:14 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > I dig a little. It shows success when updating constraint to 2.21.2 [1] > but failure when updating constraint to 2.22.0 [2]. according to release > information [3]. > It means 2.21.1 works with glance test but 2.21.2 doesn't work well with > glance. The only issue patch is https://github.com/openstack/ > oslo.serialization/commit/c1a7079c26d27a2e46cca26963d3d9aa040bdbe8. > > > [1] https://review.openstack.org/514833 > [2] https://review.openstack.org/#/c/525136 > [3] https://github.com/openstack/releases/blob/master/ > deliverables/queens/oslo.serialization.yaml > > > Actions: > > Block oslo.serialization version 2.21.2, 2.22.0, 2. 23.0in > https://review.openstack.org/534739 > Revert c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 in > https://review.openstack.org/534736 > > > > > 2018-01-16 23:35 GMT+08:00 Matthew Thode <prometheanf...@gentoo.org>: > >> On 18-01-16 19:12:16, ChangBo Guo wrote: >> > What's the issue for Glance, any bug link ? >> > >> > 2018-01-16 0:12 GMT+08:00 Matthew Thode <prometheanf...@gentoo.org>: >> > >> > > On 18-01-13 00:41:28, Matthew Thode wrote: >> > > > https://review.openstack.org/531788 is the review we are seeing it >> in, >> > > > but 2.22.0 failed as well. >> > > > >> > > > I'm guessing it was introduced in either >> > > > >> > > > https://github.com/openstack/oslo.serialization/commit/ >> > > c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 >> > > > or >> > > > https://github.com/openstack/oslo.serialization/commit/ >> > > cdb2f60d26e3b65b6370f87b2e9864045651c117 >> > > >> > > bamp >> > > >> >> The best bug for this is >> https://bugs.launchpad.net/oslo.serialization/+bug/1728368 and we are >> currently getting test fails in https://review.openstack.org/531788 >> >> -- >> Matthew Thode (prometheanfire) >> > > > > -- > ChangBo Guo(gcb) > Community Director @EasyStack > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Community Goals for Rocky
2018-01-17 0:29 GMT+08:00 Emilien Macchi <emil...@redhat.com>: > Here's an update so we can hopefully, as a community, take a decision > in the next days or so. > > > * Migration to StoryBoard > > Champion: Kendall Nelson > https://review.openstack.org/#/c/513875/ > Some projects already migrated, some projects will migrate soon but > there is still a gap of things that prevents some projects to not > migrate. > See https://storyboard.openstack.org/#!/search?tags=blocking- > storyboard-migration > For that reason, we are postponing this goal to later but work needs > to keep going to make that happen one day. > > > * Remove mox > > Champion: Sean McGinnis (unless someone else steps up) > https://review.openstack.org/#/c/532361/ > This goal is to clean some technical debt in the code. > It remains a good candidate for Queens. > > > * Ensure pagination links > > Champion: Monty Taylor > https://review.openstack.org/#/c/532627/ > This one would improve API users experience. > It remains a good candidate for Queens. > > > * Enable mutable configuration > Champion: ChangBo Guo > Nothing was proposed in governance so far and we have enough proposals > now, I guess it could be a candidate for a future cycle though. This > one would make happy our operators. > >This is the review in governance https://review.openstack.org/534605 This change really benefit users, hope this can be finished in Rocky. > > * Cold upgrades capabilities > Champion: Masayuki Igawa > https://review.openstack.org/#/c/533544/ > This one would be appreciated by our operators who always need > improvements on upgrades experience - I believe it would be a good > candidate. > > > Note: some projects requested about having less goals so they have > more time to work on their backlogs. While I agree with that, I would > like to know who asked exactly, and if they would be affected by the > goals or not. > It will help us to decide which ones we take. > > So now, it's really a good time to speak-up and say if: > - your project could commit to 2 of these goals or not (and why? backlog? > etc) > - which ones you couldn't commit to > - the ones you prefer > > We need to take a decision as a community, not just TC members, so > please bring feedback. > > Thanks, > > > On Fri, Jan 12, 2018 at 2:19 PM, Lance Bragstad <lbrags...@gmail.com> > wrote: > > > > > > On 01/12/2018 11:09 AM, Tim Bell wrote: > >> I was reading a tweet from Jean-Daniel and wondering if there would be > an appropriate community goal regarding support of some of the later API > versions or whether this would be more of a per-project goal. > >> > >> https://twitter.com/pilgrimstack/status/951860289141641217 > >> > >> Interesting numbers about customers tools used to talk to our > @OpenStack APIs and the Keystone v3 compatibility: > >> - 10% are not KeystoneV3 compatible > >> - 16% are compatible > >> - for the rest, the tools documentation has no info > >> > >> I think Keystone V3 and Glance V2 are the ones with APIs which have > moved on significantly from the initial implementations and not all > projects have been keeping up. > > Yeah, I'm super interested in this, too. I'll be honest I'm not quite > > sure where to start. If the tools are open source we can start > > contributing to them directly. > >> > >> Tim > >> > >> -Original Message- > >> From: Emilien Macchi <emil...@redhat.com> > >> Reply-To: "OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > >> Date: Friday, 12 January 2018 at 16:51 > >> To: OpenStack Development Mailing List <openstack-dev@lists. > openstack.org> > >> Subject: Re: [openstack-dev] [all] [tc] Community Goals for Rocky > >> > >> Here's a quick update before the weekend: > >> > >> 2 goals were proposed to governance: > >> > >> Remove mox > >> https://review.openstack.org/#/c/532361/ > >> Champion: Sean McGinnis (unless someone else steps up) > >> > >> Ensure pagination links > >> https://review.openstack.org/#/c/532627/ > >> Champion: Monty Taylor > >> > >> 2 more goals are about to be proposed: > >> > >> Enable mutable configuration > >> Champion: ChangBo Guo > >> > >> Cold upgrades capabilities > >> Champion: Masayuki Igawa > >> > >> > >> Thanks everyone for you
Re: [openstack-dev] [glance][oslo][requirements] oslo.serialization fails with glance
What's the issue for Glance, any bug link ? 2018-01-16 0:12 GMT+08:00 Matthew Thode <prometheanf...@gentoo.org>: > On 18-01-13 00:41:28, Matthew Thode wrote: > > https://review.openstack.org/531788 is the review we are seeing it in, > > but 2.22.0 failed as well. > > > > I'm guessing it was introduced in either > > > > https://github.com/openstack/oslo.serialization/commit/ > c1a7079c26d27a2e46cca26963d3d9aa040bdbe8 > > or > > https://github.com/openstack/oslo.serialization/commit/ > cdb2f60d26e3b65b6370f87b2e9864045651c117 > > bamp > > -- > Matthew Thode (prometheanfire) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] not run for PTL
Hi Oslo folks, I taken the role of PTL in last 2 cycles, and would like to focus on coding this cycle. it's time to let new leader to make oslo better. So I won't be running for PTL reelection for Rocky cycle. Thanks all of your support and trust in last 2 cycles. -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Community Goals for Rocky
Yeah, help means to be the "Champion" for me :-) 2018-01-12 14:22 GMT+08:00 Emilien Macchi <emil...@redhat.com>: > On Thu, Jan 11, 2018 at 9:59 PM, ChangBo Guo <glongw...@gmail.com> wrote: > > I would like to help the goal - enable mutable configuration, would like > to > > post a patch for that later. > > are you interested to be the "Champion" for this goal? > > > > > 2018-01-10 2:37 GMT+08:00 Emilien Macchi <emil...@redhat.com>: > >> > >> As promised, let's continue the discussion and move things forward. > >> > >> This morning Thierry brought the discussion during the TC office hour > >> (that I couldn't attend due to timezone): > >> > >> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ > latest.log.html#t2018-01-09T09:18:33 > >> > >> Some outputs: > >> > >> - One goal has been proposed so far. > >> > >> Right now, we only have one goal proposal: Storyboard Migration. There > >> are some concerns about the ability to achieve this goal in 6 months. > >> At that point, we think it would be great to postpone the goal to S > >> cycle, continue the progress (kudos to Kendall) and fine other goals > >> for Rocky. > >> > >> > >> - We still have a good backlog of goals, we're just missing champions. > >> > >> https://etherpad.openstack.org/p/community-goals > >> > >> Chris brought up "pagination links in collection resources" in api-wg > >> guidelines theme. He said in the past this goal was more a "should" > >> than a "must". > >> Thierry mentioned privsep migration (done in Nova and Zun). (action, > >> ping mikal about it). > >> Thierry also brought up the version discovery (proposed by Monty). > >> Flavio proposed mutable configuration, which might be very useful for > >> operators. > >> He also mentioned that IPv6 support goal shouldn't be that far from > >> done, but we're currently lacking in CI jobs that test IPv6 > >> deployments (question for infra/QA, can we maybe document the gap so > >> we can run some gate jobs on ipv6 ?) > >> (personal note on that one, since TripleO & Puppet OpenStack CI > >> already have IPv6 jobs, we can indeed be confident that it shouldn't > >> be that hard to complete this goal in 6 months, I guess the work needs > >> to happen in the projects layouts). > >> Another interesting goal proposed by Thierry, also useful for > >> operators, is to move more projects to assert:supports-upgrade tag. > >> Thierry said we are probably not that far from this goal, but the > >> major lack is in testing. > >> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most > >> of projects don't use it anymore already). > >> > >> With that said, let's continue the discussion on these goals, see > >> which ones can be actionable and find champions. > >> > >> - Flavio asked how would it be perceived if one cycle wouldn't have at > >> least one community goal. > >> > >> Thierry said we could introduce multi-cycle goals (Storyboard might be > >> a good candidate). > >> Chris and Thierry thought that it would be a bad sign for our > >> community to not have community goals during a cycle, "loss of > >> momentum" eventually. > >> > >> > >> Thanks for reading so far, > >> > >> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi <emil...@redhat.com> > >> wrote: > >> > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi <emil...@redhat.com> > >> > wrote: > >> > [...] > >> >> Suggestions are welcome: > >> >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing > >> >> goal XYZ for Rocky > >> >> - on Gerrit in openstack/governance like Kendall did. > >> > > >> > Just a fresh reminder about Rocky goals. > >> > A few questions that we can ask ourselves: > >> > > >> > 1) What common challenges do we have? > >> > > >> > e.g. Some projects don't have mutable configuration or some projects > >> > aren't tested against IPv6 clouds, etc. > >> > > >> > 2) Who is willing to drive a community goal (a.k.a. Champion)? > >> > > >> > note: a Champion is someone who volunteer to drive the goal,
Re: [openstack-dev] [all] [tc] Community Goals for Rocky
I would like to help the goal - enable mutable configuration, would like to post a patch for that later. 2018-01-10 2:37 GMT+08:00 Emilien Macchi <emil...@redhat.com>: > As promised, let's continue the discussion and move things forward. > > This morning Thierry brought the discussion during the TC office hour > (that I couldn't attend due to timezone): > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ > latest.log.html#t2018-01-09T09:18:33 > > Some outputs: > > - One goal has been proposed so far. > > Right now, we only have one goal proposal: Storyboard Migration. There > are some concerns about the ability to achieve this goal in 6 months. > At that point, we think it would be great to postpone the goal to S > cycle, continue the progress (kudos to Kendall) and fine other goals > for Rocky. > > > - We still have a good backlog of goals, we're just missing champions. > > https://etherpad.openstack.org/p/community-goals > > Chris brought up "pagination links in collection resources" in api-wg > guidelines theme. He said in the past this goal was more a "should" > than a "must". > Thierry mentioned privsep migration (done in Nova and Zun). (action, > ping mikal about it). > Thierry also brought up the version discovery (proposed by Monty). > Flavio proposed mutable configuration, which might be very useful for > operators. > He also mentioned that IPv6 support goal shouldn't be that far from > done, but we're currently lacking in CI jobs that test IPv6 > deployments (question for infra/QA, can we maybe document the gap so > we can run some gate jobs on ipv6 ?) > (personal note on that one, since TripleO & Puppet OpenStack CI > already have IPv6 jobs, we can indeed be confident that it shouldn't > be that hard to complete this goal in 6 months, I guess the work needs > to happen in the projects layouts). > Another interesting goal proposed by Thierry, also useful for > operators, is to move more projects to assert:supports-upgrade tag. > Thierry said we are probably not that far from this goal, but the > major lack is in testing. > Finally, another "simple" goal is to remove mox/mox3 (Flavio said most > of projects don't use it anymore already). > > With that said, let's continue the discussion on these goals, see > which ones can be actionable and find champions. > > - Flavio asked how would it be perceived if one cycle wouldn't have at > least one community goal. > > Thierry said we could introduce multi-cycle goals (Storyboard might be > a good candidate). > Chris and Thierry thought that it would be a bad sign for our > community to not have community goals during a cycle, "loss of > momentum" eventually. > > > Thanks for reading so far, > > On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi <emil...@redhat.com> > wrote: > > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi <emil...@redhat.com> > wrote: > > [...] > >> Suggestions are welcome: > >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing > >> goal XYZ for Rocky > >> - on Gerrit in openstack/governance like Kendall did. > > > > Just a fresh reminder about Rocky goals. > > A few questions that we can ask ourselves: > > > > 1) What common challenges do we have? > > > > e.g. Some projects don't have mutable configuration or some projects > > aren't tested against IPv6 clouds, etc. > > > > 2) Who is willing to drive a community goal (a.k.a. Champion)? > > > > note: a Champion is someone who volunteer to drive the goal, but > > doesn't commit to write the code necessarily. The Champion will > > communicate with projects PTLs about the goal, and make the liaison if > > needed. > > > > The list of ideas for Community Goals is documented here: > > https://etherpad.openstack.org/p/community-goals > > > > Please be involved and propose some ideas, I'm sure our community has > > some common goals, right ? :-) > > Thanks, and happy holidays. I'll follow-up in January of next year. > > -- > > Emilien Macchi > > > > -- > Emilien Macchi > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Rocky PTG planning
Hi , The Dublin PTG is closing, It' time to collect topics before the PTG. Just put your idea or discussion in https://etherpad.openstack.org/p/oslo-ptg-rocky -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] proposing Stephen Finucan for oslo-core
+1 for stephenfin. 2018-01-09 1:34 GMT+08:00 Ben Nemec <openst...@nemebean.com>: > Definite +1 > > > On 01/08/2018 08:55 AM, Doug Hellmann wrote: > >> Stephen (sfinucan) has been working on pbr, oslo.config, and >> oslo.policy and reviewing several of the other Oslo libraries for >> a while now. His reviews are always helpful and I think he would >> make a good addition to the oslo-core team. >> >> As per our usual practice, please reply here with a +1 or -1 and >> any reservations. >> >> Doug >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Oslo team updates
In last two cycles some people's situation changed, can't focus on Oslo code review, so I propose some changes in Oslo team. Remove following people, thanks their past hard wok to make Oslo well, and welcome them back if they want to join the team again. please +1/-1 for the change Generalist Code Reviewers: Brant Knudson Specialist API Maintainers: oslo-cache-core: Brant Kundson David Stanek oslo-db-core: Viktor Serhieiev oslo-messaging-core:Dmitriy Ukhlov Oleksii Zamiatin Viktor Serhieiev oslo-policy-core: Brant Kundson David Stanek guang-yee oslo-service-core: Marian Horban We welcome anyone join the team or contribution in Oslo. The Oslo program brings together generalist code reviewers and specialist API maintainers They share a common interest in tackling copy-and-paste technical debt across the OpenStack project. For more information please refer to wiki [1]. [1] https://wiki.openstack.org/wiki/Oslo -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][all] Final release for Oslo libraries(Jan 15 - Jan 19)
Hi ALL, Happy New Year ! We are in the week of R-5 , according to the queens schedule [1], there is only two weeks before we issue final release for Oslo libraries. We plan to do that in Jan 15. So please wrap up related work in Oslo. Oslo team please focus on the patches which are still active. [1] https://releases.openstack.org/queens/schedule.html -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Cancel next two meetings ( Dec 6 and Jan 1)
Next two mondays are holidays , there is no urgent topic to discuss, so let's skip the meeting. Merry Christmas and Happy New Year! -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][requirements][vitrage] oslo.service 1.28.1 breaks Vitrage gate
Thanks for raising this, Oslo team will revert the change in https://review.openstack.org/#/c/528202/ 2017-12-14 23:58 GMT+08:00 Afek, Ifat (Nokia - IL/Kfar Sava) < ifat.a...@nokia.com>: > Hi, > > > > The latest release of oslo.service 1.28.1 breaks the Vitrage gate. We are > creating several threads and timers [1], but only the first thread is > executed. We noticed that Trove project already reported this problem [2]. > > > > Please help us fix it. > > > > Thanks, > > Ifat. > > > > [1] https://github.com/openstack/vitrage/blob/master/vitrage/ > datasources/services.py > > [2] https://review.openstack.org/#/c/527755/ > > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Oslo weekly meeting time has changed!
Oslo folks, As we discussed in last two weekly meeting, we decide adjust the meeting time to let more people join in easier [1]. That means we schedule weekly meeting in chanel #openstack-oslo at UTC 15:00 from next Monday [1] https://review.openstack.org/522740 -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] No meeting next Monday( Nov 6)
Some of us will attend Sydney Summit, there is no urgent topic to discuss, so let's skip the meeting. -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][bilean][cue][poppy] Remove the parameter enforce_type from set_override and set_default
We plan to remove the parameter enforce_type from set_override and set_default in oslo.config [1]. we have been blocking its usage in bilean, cue, poppy for a long time. patchs were posted in these projects [2][3][4]. What we can do next, Just remove the Depends-On and go ahead in oslo side ? or push reviewers of these projects. [1] https://review.openstack.org/#/c/503181/ [2]https://review.openstack.org/#/c/503199/ [3]https://review.openstack.org/#/c/503236/ [4] https://review.openstack.org/#/c/503249/ -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Bug Smash for Queens
Thanks Fred for raising this. BWT , we have a session about the Bug Smash event in Sydney Summit [1], please join us if you're interested. [1] https://www.openstack.org/summit/sydney-2017/summit-schedule/events/19746/what-china-developers-brought-to-community-after-6-openstack-bug-smash-events 2017-10-21 15:40 GMT+08:00 Fred Li <yongle...@gmail.com>: > Hi all OpenStackers, > > Since April 2015, there have been 6 OpenStack Bug Smash events in > China. OpenStack Bug Smash has been a routine and exciting event by > OpenStacker expects. In the past 5 bug smashes, over 300 top > developers from many companies(Huawei,Intel,CMCC, IBM, Mirantis, > Awcloud, 99cloud, UnitedStack, EasyStack, LeTV, ZTE, and etc.) > contributed 600+ bugs to community. This achievement significantly > demonstrated the technical strength of Chinese engineers. Huawei, > Intel and those companies show the commitment of OpenStack Stability > to enterprise customers. > > Now, the 7th OpenStack bug smash is coming. Intel, Huawei, Fiberhome > and CESI will host this event. Intel, Huawei and Fiberhome are all > OpenStack members[1]. > Come to join other OpenStackers to make Queens a grand success! > Come to learn tips and gain a better understanding by working closely > with other talents. > Each focused project will have a core on standby to review patches and > vote for merges. > > Queens Bug SmashObject: smash the critical and high bugs in key > projects. Focused projects: Nova, Neutron, Cinder, Keystone, Manila, > Heat, Telemetry, Karbor, Tricircle, and the ones you want to add. > > To all the projects team leaders, you can discuss with your team > members in the project meeting and mark the bugs you expect OpenStack > Bug Smash Queens to fix. If you can arrange core reviewers to take > care of the patches during that week, that will be more efficient. > > Date: from Nov 22 to Nov 24, which is 2 weeks prior to Queens-2 > milestone[2]. > > Location: 中国湖北省武汉市洪山区邮科院路88号，烽火创新谷武汉国际创客中心五楼一号会议室 [3] > > > Please start to register in [4]. > And start to list the bugs to be fixed in [5]. > > [1] https://www.openstack.org/foundation/companies/ > [2] https://releases.openstack.org/queens/schedule.html > [3] https://www.google.co.jp/maps/place/88+You+Ke+Yuan+Lu,+ > GuangGu+ShangQuan,+Hongshan+Qu,+Wuhan+Shi,+Hubei+Sheng,+ > China,+430073/@30.5107646,114.392814,17z/data=!3m1!4b1!4m5! > 3m4!1s0x342ea4ce1537ed17:0x52ff45d6b5dba38c!8m2!3d30. > 51076!4d114.395008?hl=en > [4] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan > [5] https://etherpad.openstack.org/p/OpenStack-Bug-Smash- > Queens-Wuhan-Bugs-List > > > Regards > Fred Li (李永乐) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [elections] Technical Committee Election Results
Congratulations to new TC members ! 2017-10-21 7:59 GMT+08:00 Kendall Nelson <kennelso...@gmail.com>: > Hello Everyone :) > > Please join me in congratulating the 6 newly elected members of the > Technical Committee (TC)! > > Colleen Murphy (cmurphy) > Doug Hellmann (dhellmann) > Emilien Macchi (emilienm) > Jeremy Stanley (fungi) > Julia Kreger (TheJulia) > Paul Belanger (pabelanger) > > Full results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ > ce86063991ef8aae > > Election process details and results are also available here: > https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates > helps engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. We need to > ensure your voice is heard. > > Thank you for another great round. > > -Kendall Nelson (diablo_rojo) > > [1] https://review.openstack.org/#/c/513881/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][mistral] Mistral expressions package
nstack.org/cgit/openstack/oslo.tools/tree/ > filter_git_history.sh > as a tool for making the new repository. > > I'm happy to help you work out a more detailed plan. Let me know if that > would be useful. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][blazar][heat] Remove oslotest.mockpatch
Zane, Thanks for the update, we can clean up this module from Oslo side. 2017-10-18 2:10 GMT+08:00 Zane Bitter <zbit...@redhat.com>: > On 16/10/17 09:53, ChangBo Guo wrote: > >> The oslotest.mockpatch has been deprecated in favor of native fixtures in >> [1] , need remove its usage in python-heatclient, python-blazarclient >> [2][3], Heat/Blazar team please help review, then we'll merge [4] >> >> >> [1]https://review.openstack.org/#/c/245199/ >> [2]https://review.openstack.org/#/c/496120/ >> > > I guess this was meant to be a link to https://review.openstack.org/# > /c/503067/ :) > > It turns out there's an identical patch https://review.openstack.org/# > /c/495533/ that already had one +2, so I approved that one. > > - ZB > > [3]https://review.openstack.org/#/c/496120/ >> [4] https://review.openstack.org/495534 >> >> -- >> ChangBo Guo(gcb) >> Community Director @EasyStack >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][blazar][heat] Remove oslotest.mockpatch
The oslotest.mockpatch has been deprecated in favor of native fixtures in [1] , need remove its usage in python-heatclient, python-blazarclient [2][3], Heat/Blazar team please help review, then we'll merge [4] [1]https://review.openstack.org/#/c/245199/ [2]https://review.openstack.org/#/c/496120/ [3]https://review.openstack.org/#/c/496120/ [4] https://review.openstack.org/495534 -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?
FeiLong, Thanks for raising the pain points as a non-English native speaker. I had similar experience with you in last 5 years. Language, timezone, culture are the common barriers for diversity and inclusiveness. We could identify what's the biggest obstacles for contributors to contribute happily. That could be done through discussions occurred in local meetup/online meeting in local language and bring conclusions back to the global community discussion. record the obstacles and find the way to overcome them. BTW, I really like the TC office hours. how you think we could make our community more inclusive. What areas would you improve first? 2017-10-14 3:22 GMT+08:00 feilong <feil...@catalyst.net.nz>: > Thanks for asking, Flavio. That's one of the topic I mentioned in my > candidacy, that's because as a Chinese working on OpenStack in the past 6 > years, I do have some experiences about this though I agree it couldn't be > done in 1 cycle/year. But I think it's still a domain I can contribute for > OpenStack. > > I can still remember I had to join the Glance meeting at 2:00AM, and was > challenged because of saying "Hi guys" in a public channel though "Hi guys" > is used very common in New Zealand. Should we expect a non-English native > speaker to understand the details between “Hi there", "Hi guys" and "Hi > folks"? I think that's the language and culture barrier for many new > contributors. We (Brian, Erno） even tried to propose a panel at summit to > discuss it before. Currently, it's more important than ever to keep those > new contributors due to the changes happening around OpenStack nowadays. > > On 14/10/17 01:45, Flavio Percoco wrote: > > Greetings, > > Some of you, TC candidates, expressed concerns about diversity and > inclusiveness > (or inclusivity, depending on your taste) in your candidacy. I believe > this is a > broad, and some times ill-used, topic so, I'd like to know, from y'all, > how you > think we could make our community more inclusive. What areas would you > improve > first? > > Thank you, > Flavio > > -- > @flaper87 > Flavio Percoco > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > -- > Senior Cloud Software Engineer > Tel: +64-48032246 <+64%204-803%202246> > Email: flw...@catalyst.net.nz > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > -- > > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][election] Question for the candidates
One thing I wish the TC could do more in the past years is that make users and developers in the same page: share requirements, pain points and development progress, glad we have some ways to shorten the feedback loop like building SIG(Special Interest Group) to involve more users. 2017-10-13 2:38 GMT+08:00 Ed Leafe <e...@leafe.com>: > In the past year or so, has there been anything that made you think “I > wish the TC would do something about that!” ? If so, what was it, and what > would you have wanted the TC to do about it? > > -- Ed Leafe > > > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] TC Candidates: what does an OpenStack user look like?
Zane,
Thanks for raising the discussion. We recently discuss a lot about what's
OpenStack, what OpenStack Foundation should be. I would like to list some
discussion I involved before [1]. OpenSack affects following people and
organizations. we should consider when we make decisions.
*Q1: Who benefits from OpenStack? Who are the customers, users, etc?*
1st tier (direct users) : Developers, Sys Admins, DevOps, Application
owners that want IaaS/PaaS resources
2nd tier (providers) catering to 1st directly :
2a (internal) : Enterprises and IT departments
2b (external) : IaaS/PaaS Providers, SaaS Providers, Enterprises,
Operators and CSPs
3rd tier catering to 2nd tier :
3a : Distribution Vendors and OpenStack Integrators
3b : Hardware vendors
[1] https://etherpad.openstack.org/p/ocata-12questions-exercise-board
2017-10-13 0:51 GMT+08:00 Zane Bitter <zbit...@redhat.com>:
> (Reminder: we are in the TC election campaigning period, and we all have
> the opportunity to question the candidates. The campaigning period ends on
> Saturday, so make with the questions.)
>
>
> In my head, I have a mental picture of who I'm building OpenStack for.
> When I'm making design decisions I try to think about how it will affect
> these hypothetical near-future users. By 'users' here I mean end-users, the
> actual consumers of OpenStack APIs. What will it enable them to do? What
> will they have to work around? I think we probably all do this, at least
> subconsciously. (Free tip: try doing it consciously.)
>
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack user
> that is top-of-mind in your head look like? Who are _you_ building
> OpenStack for?
>
> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-Octo
> ber/123312.html
>
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my opinion
> is that we have a bunch of people with *different* answers on the TC,
> because I think that will lead to better discussion and hopefully better
> decisions.
>
> Discuss.
>
> cheers,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][election] Question for the candidates
Several changes seems very well in the past months, for me the "top 5 help wanted list" [1] is really helpful. It's introduced in [2] and with some follow ups. This document lists areas where the OpenStack Technical Committee seeks contributions to significantly help OpenStack as a whole. In last several cycles some key contributors changed their work, not focus on OpenStack, in the other side, some new contributors couldn't find 'the right way' to contribute, posting trivial repeated patches, The document provides a guidance on how to make useful, strategic contributions to OpenStack. It's important for new contributors,even key contributors. [1] https://governance.openstack.org/tc/reference/top-5-help-wanted.html [2] https://review.openstack.org/#/c/466684/ 2017-10-13 3:42 GMT+08:00 Clay Gerrard <clay.gerr...@gmail.com>: > I like a representative democracy. It mostly means I get a say in which > other people I have to trust to think deeply about issues which effect me > and make decisions which I agree (more or less) are of benefit to the > social groups in which I participate. When I vote IRL I like to consider > voting records. Actions speak louder blah blah. > > To candidates: > > Would you please self select a change (or changes) from > https://github.com/openstack/governance/ in the past ~12 mo or so where > they thought the outcome or the discussion/process was particular good and > explain why you think so? > > It'd be super helpful to me, thanks! > > -Clay > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [election] [tc] TC Candidacy
Hi everyone, I'm announcing my candidacy for a position on the OpenStack Technical Committee. I'm ChangBo Guo(AKA gcb)[1], currently working for EasyStack, leading developers' upstream contribution on OpenStack in the company. I have been working on the OpenStack since 2012, firstly focused on Nova and then focus on Oslo, also contributed to several other projects[2]. I've been serving as the PTL of Oslo (OpenStack Common libraries) for Pike and Queens. During the last 5 years, as a developer I have the chance to talk with users/operators, meeting users/operators' requirements and making OpenStack more useful are important, that's the key factor to make OpenStack successful. OpenStack has huge potential customers though some companies adjust their investment on OpenStack. We have some progress on shortening the feedback loop like building SIG(Special Interest Group) to involve more users. Not all the users can raise their requirements easily due to the barrier like language. TC may need work with UC to find more ways to collect users/operators' requirements like we have 'Top 5 help wanted list' in development cycle. OpenStack is the first open source project I contributed, I've learned a lot from community leaders in the past 5 years and guided some new contributors how to work with other world wide contributors. It's not a easy to be productive for a new contributor especially for whom without open source experience. In last several cycles some key contributors changed their work, not focus on OpenStack, in the other side, some new contributors couldn't find 'the right way' to contribute, posting trivial repeated patches, we're facing the challenge! Though we have program 'OpenStack Upstream Institute' to training new contributors, that's not enough for new contributor, because not all new contributors can attend the the OpenStack Summit. TC may host more online events to invite community leaders to communicate with new contributors, and help new contributors to contribute in 'the right way'. As a TC member I want to focus on shortening the feedback loop and guiding new contributors. Thank you for your consideration! ChangBo Guo(gcb) [1] https://www.openstack.org/community/members/profile/14945/changbo-guo [2] http://stackalytics.com/report/users/glongwave __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][oslo] Retiring openstack/pylockfile
pylockfile was deprecated about two years ago in [1] and it is not used in any OpenStack Projects now [2] , we would like to retire it according to steps of retiring a project[3]. [1]c8798cedfbc4d738c99977a07cde2de54687ac6c#diff-88b99bb28683bd5b7e3a204826ead112 [2] http://codesearch.openstack.org/?q=pylockfile=nope== [3]https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] No meeting next Monday( Oct 2)
Hi Oslo folks, Next week is China's National Day holiday, I can't be online the whole week, If we can't find others to hold the meeting, let's skip the weekly meeting. I will prepare weekly release patch tomorrow, the that won't block other's work. -- ChangBo Guo(gcb) Community Director @EasyStack __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo][oslo.messaging][all] Notice: upcoming change to oslo.messaging RPC server
BTW, We plan to release 5.33 with the patch https://review.openstack.org/#
/c/500456/ please let me know if you need hold the release.
[ Unreleased changes in openstack/oslo.messaging (master) ]
Changes between 5.32.0 and a9d10d3
* 3a9c01f 2017-09-24 20:25:38 -0700 Fix default value of RPC dispatcher
access_policy
| * 6efa86a 2017-09-22 17:13:26 -0700 Fix wrong transport warnings in
functional tests
|/
* c2338ee 2017-09-20 16:23:04 + Updated from global requirements
2017-09-28 20:11 GMT+08:00 ChangBo Guo <glongw...@gmail.com>:
> Ken, thanks for raising this , Oslo team will send notice early when we
> have major changes like this .
>
> 2017-09-27 4:17 GMT+08:00 Ken Giusti <kgiu...@gmail.com>:
>
>> Hi Folks,
>>
>> Just a head's up:
>>
>> In Queens the default access policy for RPC Endpoints will change from
>> LegacyRPCAccessPolicy to DefaultRPCAccessPolicy. RPC calls to private
>> ('_' prefix) methods will no longer be possible. If you want to allow
>> RPC Clients to invoke private methods, you must explicitly set the
>> access_policy to LegacyRPCAccessPolicy when you call get_rpc_server()
>> or instantiate an RPCDispatcher. This change [0] has been merged to
>> oslo.messaging master and will appear in the next release of
>> oslo.messaging.
>>
>> "Umm What?"
>>
>> Good question! Here's the TL;DR details:
>>
>> Since forever it's been possible for a client to make an RPC call
>> against _any_ method defined in the RPC Endpoint object. And by "any"
>> we mean "all methods including private ones (method names prefixed by
>> '_' )"
>>
>> Naturally this ability came as a surprise many folk [1], including
>> yours truly and others on the oslo team [2]. It was agreed that
>> having this be the default behavior was indeed A Bad Thing.
>>
>> So starting in Ocata oslo.messaging has provided a means for
>> controlling access to Endpoint methods [3]. Oslo.messaging now
>> defines three different "access control policies" that can be applied
>> to an RPC Server:
>>
>> LegacyRPCAccessPolicy: original behavior - any method can be invoked
>> by an RPC client
>> DefaultRPCAccessPolicy: prevent RPC access to private '_' methods, all
>> others may be invoked
>> ExplicitRPCAccessPolicy: only allow access to those methods that have
>> been decorated with @expose decorator
>>
>> See [4] for more details.
>>
>> In order not to break anything at the time the default access policy
>> was set to 'LegacyRPCAccessPolicy'. This has been the default for
>> Ocata and Pike.
>>
>> Starting in Queens this will no longer be the case.
>> DefaultRPCAccessPolicy will become the default if no access policy is
>> specified when calling get_rpc_server() or directly instantiating an
>> RPCDispatcher. To keep the old behavior you must explicitly set the
>> access policy to LegacyRPCAccessPolicy:
>>
>> from oslo_messaging.rpc import LegacyRPCAccessPolicy
>> ...
>> server = get_rpc_server(transport, target, endpoints,
>> access_policy=LegacyRPCAccessPolicy)
>>
>>
>>
>> Reply here if you have any questions or hit any issues, thanks!
>>
>> -K
>>
>> [0] https://review.openstack.org/#/c/500456/
>> [1] https://bugs.launchpad.net/oslo.messaging/+bug/1194279
>> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1555845
>> [3] https://review.openstack.org/#/c/358359/
>> [4] https://docs.openstack.org/oslo.messaging/latest/reference/
>> server.html
>> --
>> Ken Giusti (kgiu...@gmail.com)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
--
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo][oslo.messaging][all] Notice: upcoming change to oslo.messaging RPC server
Ken, thanks for raising this , Oslo team will send notice early when we
have major changes like this .
2017-09-27 4:17 GMT+08:00 Ken Giusti <kgiu...@gmail.com>:
> Hi Folks,
>
> Just a head's up:
>
> In Queens the default access policy for RPC Endpoints will change from
> LegacyRPCAccessPolicy to DefaultRPCAccessPolicy. RPC calls to private
> ('_' prefix) methods will no longer be possible. If you want to allow
> RPC Clients to invoke private methods, you must explicitly set the
> access_policy to LegacyRPCAccessPolicy when you call get_rpc_server()
> or instantiate an RPCDispatcher. This change [0] has been merged to
> oslo.messaging master and will appear in the next release of
> oslo.messaging.
>
> "Umm What?"
>
> Good question! Here's the TL;DR details:
>
> Since forever it's been possible for a client to make an RPC call
> against _any_ method defined in the RPC Endpoint object. And by "any"
> we mean "all methods including private ones (method names prefixed by
> '_' )"
>
> Naturally this ability came as a surprise many folk [1], including
> yours truly and others on the oslo team [2]. It was agreed that
> having this be the default behavior was indeed A Bad Thing.
>
> So starting in Ocata oslo.messaging has provided a means for
> controlling access to Endpoint methods [3]. Oslo.messaging now
> defines three different "access control policies" that can be applied
> to an RPC Server:
>
> LegacyRPCAccessPolicy: original behavior - any method can be invoked
> by an RPC client
> DefaultRPCAccessPolicy: prevent RPC access to private '_' methods, all
> others may be invoked
> ExplicitRPCAccessPolicy: only allow access to those methods that have
> been decorated with @expose decorator
>
> See [4] for more details.
>
> In order not to break anything at the time the default access policy
> was set to 'LegacyRPCAccessPolicy'. This has been the default for
> Ocata and Pike.
>
> Starting in Queens this will no longer be the case.
> DefaultRPCAccessPolicy will become the default if no access policy is
> specified when calling get_rpc_server() or directly instantiating an
> RPCDispatcher. To keep the old behavior you must explicitly set the
> access policy to LegacyRPCAccessPolicy:
>
> from oslo_messaging.rpc import LegacyRPCAccessPolicy
> ...
> server = get_rpc_server(transport, target, endpoints,
> access_policy=LegacyRPCAccessPolicy)
>
>
>
> Reply here if you have any questions or hit any issues, thanks!
>
> -K
>
> [0] https://review.openstack.org/#/c/500456/
> [1] https://bugs.launchpad.net/oslo.messaging/+bug/1194279
> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1555845
> [3] https://review.openstack.org/#/c/358359/
> [4] https://docs.openstack.org/oslo.messaging/latest/reference/server.html
> --
> Ken Giusti (kgiu...@gmail.com)
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] No meeting today
Hi Oslo folks, Most of us just attended Dever PTG, there is no urgent topics to discuss, so I think we can skip the meeting today. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] No meeting on next Monday( Sep 11th)
Most of us will attend the PTG, so there is no weekly meeting next Monday. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] schedule for Denver PTG is ready !
Lance, I just update the schedule in [1] and add your new proposal topic in the schedule, kindly let me know when you're available, then we can rearrange your topics if you still have conflicts :-) [1] https://etherpad.openstack.org/p/oslo-ptg-queens 2017-09-02 6:16 GMT+08:00 Lance Bragstad <lbrags...@gmail.com>: > Thanks for the schedule! I should be somewhat available Monday afternoon > for the policy deprecation discussion. The only conflict that might come up > for me is with the Baremetal/VM group [0]. Keystone has a few topics to > iron out there, but I'm not exactly sure when that group plans to talk > about those things. Also, I proposed another oslo spec detailing some > additional policy work [1]. Let me know if you have thoughts, or would like > to discuss it in Denver. > > [0] https://etherpad.openstack.org/p/keystone-queens-ptg > [1] https://review.openstack.org/#/c/500207/ > > > On 08/28/2017 09:44 PM, ChangBo Guo wrote: > > sure, will adjust the schedule > > 2017-08-29 2:24 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > >> Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800: >> > Please check for the draft in [1], we can adjust if you have conflicts >> > with other discussions. >> > >> > We have specific cross projects coding event in the Tuesday afternoon, >> for >> > more details please >> > check [2] and [3], please join us if you're free from 1:00 PM to 3: PM >> on >> > Tuesday. >> > >> > [1] https://etherpad.openstack.org/p/oslo-ptg-queens >> > [2] >> > http://lists.openstack.org/pipermail/openstack-dev/2017-Augu >> st/121345.html >> > [3] https://etherpad.openstack.org/p/oslo-queens-tasks >> > >> >> I think we can drop the discussion of retiring oslosphinx from the >> schedule. We had no objections, and the way forward is clear (see the >> other thread [4] for details). >> >> Doug >> >> [4] http://lists.openstack.org/pipermail/openstack-dev/2017-Augu >> st/121564.html >> >> ________ >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > ChangBo Guo(gcb) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.serialization]
Tom, it's good to backport the fix into previous branch. I just cherry-pick the fix in https://review.openstack.org/#/c/500781/ I will release new version of oslo.serialization for branch stable/ocata. 2017-09-04 22:15 GMT+08:00 Tom STAPPAERTS <tom.stappae...@nuagenetworks.net> : > Hi guys, > > We are having an issue when trying to json.dumps() an object that contains > an IPNetwork. oslo.serialization.jsonutils.to_primitive() tries to > include every single ip address in the ip network in the dumped json. This > of course creates issues with an ipv6 network. > > You guys fixed this in https://review.openstack.org/#/c/475052/ , but > only for master / 2.19.0 upwards. > > Is there a way to backport this to newton/ocata releases as well? I am > more than happy to do the heavy lifting on this, but wanted to check with > you guys before I start submitting anything :) > > Kind regards, > Tom Stappaerts > Nokia OpenStack software engineer > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.middleware] when will next release arrive
Hi YunJun, Oslo team hold the releases of oslo libraries for branch Pike(previous master) until we release Pike for service projects like Nova, Cinder. We can issue new release when Queens cycle is open. will confirm with release team today if we can do that in this week or next week. 2017-09-04 9:57 GMT+08:00 Yujun Zhang (ZTE) <zhangyujun+...@gmail.com>: > Hi oslo cores, > > It has been more than one month since last release of oslo.middleware > (3.30.0 on July 18th). I wonder when will next release arrive. > > I'm asking it because some bug fix[1] is depending the patch sets to be > released[2]. > > [1]: https://review.openstack.org/#/c/487388/ > [2]: https://review.openstack.org/#/c/487454/ > > -- > Yujun Zhang > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] schedule for Denver PTG is ready !
sure, will adjust the schedule 2017-08-29 2:24 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800: > > Please check for the draft in [1], we can adjust if you have conflicts > > with other discussions. > > > > We have specific cross projects coding event in the Tuesday afternoon, > for > > more details please > > check [2] and [3], please join us if you're free from 1:00 PM to 3: PM > on > > Tuesday. > > > > [1] https://etherpad.openstack.org/p/oslo-ptg-queens > > [2] > > http://lists.openstack.org/pipermail/openstack-dev/2017- > August/121345.html > > [3] https://etherpad.openstack.org/p/oslo-queens-tasks > > > > I think we can drop the discussion of retiring oslosphinx from the > schedule. We had no objections, and the way forward is clear (see the > other thread [4] for details). > > Doug > > [4] http://lists.openstack.org/pipermail/openstack-dev/2017- > August/121564.html > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] [oslo] schedule for Denver PTG is ready !
Please check for the draft in [1], we can adjust if you have conflicts with other discussions. We have specific cross projects coding event in the Tuesday afternoon, for more details please check [2] and [3], please join us if you're free from 1:00 PM to 3: PM on Tuesday. [1] https://etherpad.openstack.org/p/oslo-ptg-queens [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/121345.html [3] https://etherpad.openstack.org/p/oslo-queens-tasks -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.messaging] Proposing Andy Smith as an oslo.messaging core reviewers
There is no objection during last two weeks, added Andy Smith as oslo.message core reviewer Welcome Andy ! 2017-08-16 23:06 GMT+08:00 Ken Giusti <kgiu...@gmail.com>: > +1 > > On Mon, Aug 14, 2017 at 6:59 AM, ChangBo Guo <glongw...@gmail.com> wrote: > >> I propose that we add Andy Smith to the oslo.messaging team. >> >> Andy Smith has been actively contributing to oslo.messaging for a while >> now, both >> in helping make oslo.messaging better via code contribution(s) and by >> helping with >> the review load when he can. He's been involved on the AMQP 1.0 side for >> awhile. He's really interested in taking ownership of the experimental >> Kafka driver, which would be great to have someone able to drive that. >> >> Please respond with +1/-1 >> >> Voting will last 2 weeks and will end at 28th of August. >> >> Cheers, >> -- >> ChangBo Guo(gcb) >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Ken Giusti (kgiu...@gmail.com) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [os-upstream-institute][all] Get together at the PTG
Would like to join the meeting if I' am free on Monday or Tuesday, though I wasn't involved too much before. 2017-08-28 9:35 GMT+08:00 Ghanshyam Mann <ghanshyamm...@gmail.com>: > I will be there and Monday or Tuesday works better for me too. > > -gmann > > > On Sat, Aug 26, 2017 at 2:41 AM, Kendall Nelson <kennelso...@gmail.com> > wrote: > > I'll be around obviously. > > > > Monday or Tuesday would work best for me as well. > > > > -Kendall (diablo_rojo) > > > > On Fri, Aug 25, 2017 at 8:09 AM Miguel Lavalle <mig...@mlavalle.com> > wrote: > >> > >> Ildiko, > >> > >> For me it would be great if we can meet on Monday or Tuesday. Those two > I > >> have also to find time to get together with the Docs team > >> > >> Regards > >> > >> On Fri, Aug 25, 2017 at 9:36 AM, Ildiko Vancsa <ildiko.van...@gmail.com > > > >> wrote: > >>> > >>> Hi Training Team and All, > >>> > >>> As we have our next PTG coming up shortly I think that would be a great > >>> opportunity for the team and everyone who’s interested to meet and > check > >>> where we are and what our future plans are. :) > >>> > >>> I would like to ask you to raise your hand by replying to this mail if > >>> you will be around during the PTG week in Denver and would be > interested in > >>> joining. Please also indicate your availability for the week. > >>> > >>> Based on the responses we will pick a day and a time that works best > for > >>> most to have our gathering. > >>> > >>> Please let me know if you have any questions. > >>> > >>> Thanks and Best Regards, > >>> Ildikó > >>> (IRC: ildikov) > >>> > >>> > >>> > >>> > >>> > __ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Python 3.6 testing is available on Fedora 26 nodes
Thanks for the follow up, it's really helpful for us to support Python 3.6
smoothly in the future.
2017-08-25 12:29 GMT+08:00 Ian Wienand <iwien...@redhat.com>:
> Hello,
>
> In a recent discussion [1] I mentioned we could, in theory, use Fedora
> 26 for Python 3.6 testing (3.6.2, to be exact). After a few offline
> queries we have put theory into practice, sorted out remaining issues
> and things are working.
>
> For unit testing (tox), you can use the
> 'gate-{name}-python36-{node}-nv' job template with fedora-26 nodes.
> For an example, see [2] (which, I'm happy to report, found a real
> issue [3] :). You may need to modify your bindep.txt files to install
> correct build pacakges for RPM platforms; in terms of general
> portability this is probably not a bad thing anyway.
>
> I have an up/down devstack test working with a minor change [4]. I
> will work on getting this more stable and more complete, but if this
> is of interest, reach out. In general, I track the centos & fedora
> jobs fairly closely at [5] to try and keep up with any systemic
> issues.
>
> Although it is not exactly trivial, there is fairly complete
> instructions within [6] to help build a Fedora image that looks like
> the infra ones for testing purposes. You can also reach out and we
> can do things like place failed nodes on hold if there are hard to
> debug issues.
>
> Thanks,
>
> -i
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120888.html
> [2] https://git.openstack.org/cgit/openstack-infra/project-
> config/commit/?id=5fe3ba95616136709a319ae1cd3beda38a299a13
> [3] https://review.openstack.org/496054
> [4] https://review.openstack.org/496098
> [5] http://people.redhat.com/~iwienand/devstack-status/
> [6] https://git.openstack.org/cgit/openstack-infra/project-
> config/tree/tools/build-image.sh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
ChangBo Guo(gcb)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !
Ken, I just search debtcollector usage to find deprecated stuff, we still have other things to clean up, feel free to add items in the etherpad. 2017-08-23 21:32 GMT+08:00 Ken Giusti <kgiu...@gmail.com>: > > > On Tue, Aug 22, 2017 at 3:24 AM, ChangBo Guo <glongw...@gmail.com> wrote: > >> Hi ALL, >> >> We discussed a little about how to avoid breaking consuming projects' >> gate in oslo weekly meeting last week. The easy improvement is that clean >> up deprecated stuff in oslo at the beginning of Queens. I collected >> deprecated stuff in [1]. This need Oslo team and other team work >> toghether. I think we can start the work when cycle Queens is open. I >> also reserved a room in PTG >> for 2 hours to do hacking.[2] >> >> >> [1] https://etherpad.openstack.org/p/oslo-queens-tasks >> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms >> >> -- >> ChangBo Guo(gcb) >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > I've gone through oslo.messaging and have updated the etherpad [1] with a > few more entries. I've opened launchpad bugs where appropriate, adding the > oslo-debt-cleanup tag to each for good measure. > > The original list included a few items that as best I can tell were not > tagged as deprecated via debtcollector until Pike. IIUC we can't remove > those in Queens, correct? > > -- > Ken Giusti (kgiu...@gmail.com) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !
2017-08-22 20:37 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800: > > Hi ALL, > > > > We discussed a little about how to avoid breaking consuming projects' > gate > > in oslo weekly meeting last week. The easy improvement is that clean up > > deprecated stuff in oslo at the beginning of Queens. I collected > > deprecated stuff in [1]. This need Oslo team and other team work > > toghether. I think we can start the work when cycle Queens is open. I > also > > reserved a room in PTG > > for 2 hours to do hacking.[2] > > > > > > [1] https://etherpad.openstack.org/p/oslo-queens-tasks > > [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms > > > > Cleaning up some of this technical debt is a great idea for Queens! > > What do you think about using a common gerrit topic to make those > reviews easy to find across the repository? > > yeah, that's helpful to track the reviews, what about the topic > 'oslo-debt-cleanup' ? > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack][oslo][all] Clean up oslo deprecated stuff !
Hi ALL, We discussed a little about how to avoid breaking consuming projects' gate in oslo weekly meeting last week. The easy improvement is that clean up deprecated stuff in oslo at the beginning of Queens. I collected deprecated stuff in [1]. This need Oslo team and other team work toghether. I think we can start the work when cycle Queens is open. I also reserved a room in PTG for 2 hours to do hacking.[2] [1] https://etherpad.openstack.org/p/oslo-queens-tasks [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] PTG Planning with online meeting
Hi ALL, Oslo team will try to set up online meeting( maybe zoom) during the PTG, then others who can't travel to Denver can join the discussion. will send out the meeting link before the PTG. So please add topics in https://etherpad.openstack.org/p/oslo-ptg-queens even you can't attend the PTG. 2017-07-28 15:11 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > Just a reminder, please add your name and topic in the etherpad if you > will join the discussion abouth Oslo at the PTG. > > 2017-07-10 21:48 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > >> Hi Oslo folks, >> >> I created a planning etherpad[1] for topics for the next PTG in Denver. >> Please add any topics there, then we can schedule the topics before the >> PTG. >> >> [1]https://etherpad.openstack.org/p/oslo-ptg-queens >> >> -- >> ChangBo Guo(gcb) >> > > > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][oslo.messaging] Proposing Andy Smith as an oslo.messaging core reviewers
I propose that we add Andy Smith to the oslo.messaging team. Andy Smith has been actively contributing to oslo.messaging for a while now, both in helping make oslo.messaging better via code contribution(s) and by helping with the review load when he can. He's been involved on the AMQP 1.0 side for awhile. He's really interested in taking ownership of the experimental Kafka driver, which would be great to have someone able to drive that. Please respond with +1/-1 Voting will last 2 weeks and will end at 28th of August. Cheers, -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to run period tasks by OpenStack way?
I think You are missing initialization for running period tasks. You need prepare a daemon service with period tasks like nova-compute There are some key points to enable period task: 1. add period tasks to thread group https://github.com/openstack/nova/blob/master/nova/service.py#L194 2. make manager class inherit from periodic_task.PeriodicTasks https://github.com/openstack/nova/blob/master/nova/manager.py#L91 3. run service as daemon https://github.com/openstack/nova/blob/master/nova/cmd/compute.py#L56 2017-08-14 17:50 GMT+08:00 zhi <changzhi1...@gmail.com>: > Hi, all. > > There are two ways to run period tasks in OpenStack. One is using > "FixedIntervalLoopingCall" and the other is using the decorator named > "periodic_task.periodic_task". Both of them are defining in Oslo service > module. > > My question is, how to use them in non OpenStack environment? In other > words, how to use them in our own private projects? I have some demo codes > at [1] and [2]. But may be there is something wrong with them. They didn't > run periodically. > > Could someone give me some advice? > > > Thanks. > Zhi > > > [1]: http://paste.openstack.org/show/618295/ > [2]: http://paste.openstack.org/show/618296/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][infra]Plan to support Python 3.6 ?
2017-08-10 0:46 GMT+08:00 Jeremy Stanley <fu...@yuggoth.org>: > On 2017-08-09 09:31:37 -0400 (-0400), Doug Hellmann wrote: > [...] > > One of the reasons we were able to move ahead with 3.5 was that it > > would be available on the platforms for which we test deployments, > > as defined in the CTI [5]. Are Ubuntu LTS and CentOS shipping > > Python 3.6? > [...] > > Yes, we ran early 3.3 testing on Ubuntu 12.04 LTS with the aid of > some backported packages but this was far from ideal. Proper support > for 3.4 testing came with Ubuntu 14.04 LTS which included it > directly in the package archive, and then we switched to testing > against 3.5 when Ubuntu 16.04 became available installing it by > default. The Ubuntu python3.6 packages started appearing after 16.04 > was out the door, and so looks like it will be generally available > to us once Ubuntu 18.04 LTS is released and we can start using it as > a basis for CI jobs (likely in Q2 of next year, so probably during > OpenStack's "Rocky" release cycle). > -- > yeah, We can migrate to Python 3.6 in Q2 of next year when we have basic CI jobs. > Jeremy Stanley > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][infra]Plan to support Python 3.6 ?
We received Python 3.6 related Bug recently [1][2]. That let me think what's the plan to support Python 3.6 for OpenStack in the future. Python 3.6 was released on December 23, 2016, has some different behaviors from Python 3.5[3]. talked with cdent in the IRC, would like to discuss this through mailing list , and suggest a discussion at the PTG[3] 1. what's the time to support Python 3.6 ? 2. what 's the plan or process ? Maybe we can do that we support python 3 1) setup python 3.6 non-voting CI jobs 2) Fix related issues about Python 3.6 3) enable pyhton 3.6 jobs voting [1] https://bugs.launchpad.net/oslo.rootwrap/+bug/1709505 [2]https://bugs.launchpad.net/pbr/+bug/1690103 [3]https://docs.python.org/3/whatsnew/3.6.html [4] https://etherpad.openstack.org/p/infra-ptg-queens -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] New code contributors no longer forced to join the foundation
thanks for all of the effort, great work 2017-08-08 13:30 GMT+08:00 Swapnil Kulkarni <cools...@gmail.com>: > On Tue, Aug 8, 2017 at 4:58 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > > Due to improvements in the OpenStack Foundation member directory and > > our technical election tooling, it is no longer necessary to join > > the foundation as an individual member just to be able to submit > > changes through Gerrit for official repositories. You do, however, > > still eventually need to join if you want to be able to participate > > in technical elections (as a candidate or a voter). > > > > The Account Setup section[1] of the Developer's Guide has been > > updated to reflect the new simpler process, and a separate > > (optional) Eligibility to Vote in Elections section[2] has been > > added. This process change significantly simplifies the onboarding > > process for new code contributors by removing a very error-prone > > and, for many, eyebrow-raising hurdle. > > > > A little background: the Bylaws of the OpenStack Foundation Appendix > > 4 Technical Committee Member Policy[3] (section 3b) limits voter > > rolls for technical elections to Foundation Individual Members. It > > was never strictly required by policy to join the foundation if you > > only wanted to contribute code and had no interest in voting, which > > is not an entirely uncommon case for new contributors. Due to > > previous technical limitations in our systems we still forced new > > contributors to join, because that was the easiest way at the time > > to be relatively certain who was qualified to participate in > > technical elections. Now that we have a mechanism for verifying > > membership on demand when validating nominations and generating > > voter rolls, we have made the step of joining the foundation > > optional (though still very much recommended once you reach the > > point as a contributor where you want to participate in community > > governance processes). > > > > [1] https://docs.openstack.org/infra/manual/developers.html# > account-setup > > [2] https://docs.openstack.org/infra/manual/developers.html# > eligibility-to-vote-in-elections > > [3] https://www.openstack.org/legal/technical-committee-member-policy/ > > -- > > Jeremy Stanley > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > Great, excellent step to reduce barrier to entry. Kudos! > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Developer Mailing List Digest July 22-28
Mike, Thanks for the summary 2017-08-02 10:03 GMT+08:00 Mike Perez <thin...@gmail.com>: > HTML version: https://www.openstack.org/blog/2017/08/openstack- > developer-mailing-list-digest-20170728/ > > Summaries > = > * Nova placement/resource providers update 30 [1] > * TC Report 30 [2] > * POST /api-wg/news [3] > * Release countdown for week R-4, July 28 - Aug 4 [4] > * Technical Committee Status update, July 28 [5] > > Project Team Gathering Planning > === > * Nova [6] > * Keystone [7] > * Sahara [8] > * Cinder [9] > * Oslo [10] > * Neutron [11] > * Documentation [12] > > Oslo DB Network Database Base namespace throughout OpenStack Projects > = > * Mike Bayer has been working with Octave Oregon on adding the network > database > storage engine for mysql to oslo.db module so other projects can take > advantage of it. Mike Bayer notes: > - The code review [13] > - Support in Nova [14] > - Support in Neutron [15] > * New data types that map to types from the NDB namespace. > - oslo_db.sqlalchemy.types.SmallString > - oslo_db.sqlalchemy.types.String > * Full thread: [16] > > 1. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120290.html > 2. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120112.html > 3. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120245.html > 4. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120304.html > 5. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120280.html > 6. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120020.html > 7. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119299.html > 8. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119352.html > 9. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119358.html > 10. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119462.html > 11. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/120270.html > 12. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119990.html > 13. https://review.openstack.org/#/c/427970/ > 14. https://review.openstack.org/#/c/446643 > 15. https://review.openstack.org/#/c/446136/ > 16. http://lists.openstack.org/pipermail/openstack-dev/2017- > July/thread.html#120037 > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][ptl][stable][release] stable/pike branches created for most libraries
Thanks for the reminder, I saw related patches showed up in the Gerrit, will ensure them pass validation jobs. 2017-07-29 5:13 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > As Thierry mentioned in his countdown email today, the release team has > now created the stable branches for most deliverables with type > "library". > > We have 3 exceptions: > > 1. python-neutronclient had a late release, so I will be branching it >shortly. > 2. python-barbicanclient was skipped until they have a chance to resolve >the critical bug they are working on. > 3. tempest doesn't branch (we should probably reclassify that as >something other than a library to avoid issues with the automation) > > All libraries should have had updates for the .gitreview file in the new > branch, the constraints URL in the tox.ini file, and the reno > configuration (in master, if the project uses reno). > > Landing any of the patches in the stable/pike branch will trigger a new > documentation build publishing to docs.o.o/$project/pike. > > Please take over any of the bot-created patches that do not pass your > validation jobs and fix them so that they can land as soon as possible. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] PTG Planning
Just a reminder, please add your name and topic in the etherpad if you will join the discussion abouth Oslo at the PTG. 2017-07-10 21:48 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > Hi Oslo folks, > > I created a planning etherpad[1] for topics for the next PTG in Denver. > Please add any topics there, then we can schedule the topics before the > PTG. > > [1]https://etherpad.openstack.org/p/oslo-ptg-queens > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.db] nominating Jay Pipes for oslo-db-core
+1000 2017-07-27 22:04 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > I have noticed that Jay has been very deeply involved in several > recent design discussions about oslo.db, and he obviously has a > great deal of experience in the area, so even though he hasn't been > actively reviewing patches recently I think he would be a good > addition to the team. I have asked him, and he is interested and will > try to become more active as well. > > Please indicate your opinion with +1/-1. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs] 404s on docs website after the great reorg
++ for the solution. 2017-07-28 2:24 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > Excerpts from Jeremy Stanley's message of 2017-07-27 16:40:08 +: > > On 2017-07-27 12:23:39 -0400 (-0400), Sean Dague wrote: > > > In the #openstack-nova channel this morning we were debugging some > cells > > > v2 things, and ran into the fact that the online docs for this - > > > https://docs.openstack.org/nova/latest/cells.html go to a 404. That's > a > > > previously well known link, people have it in their browser history, > > > bookmarks, wiki pages, other websites. > > > > > > My understanding of big moves like this is that redirects are > important. > > > Things going blackhole like that not only is an inconvenience to users, > > > but impacts our search engine rankings, and takes a while for them to > > > all sift out. I know in sites I run I'm still regularly getting in > > > bounds to paths on the site that haven't been there for 8 years. > > > > > > It would be really good if we had a way (manual or automated) to have > > > 301 redirects, that are fixable by the teams that now own the > > > documentation (the project teams). > > > > We can look at including .htaccess files in the tree I guess? Or > > some metadata the publish job uses to build them maybe? > > That's exactly what I was thinking. > > 1. Enable .htaccess files by turning on allowoverride for >docs.openstack.org. > > 2. Add .htaccess files in each tree, as needed (see >https://review.openstack.org/487932 for an example of how this >is done with sphinx). > > 3. Update the main .htaccess file in openstack-manuals to redirect >from the old location of docs in a way that passes the full path. >Right now we redirect to /project/latest/: > > redirectmatch 301 "^/developer/([^/]+)/.*$" /$1/latest/ > >I think that would change to look something like: > > redirectmatch 301 "^/developer/([^/]+)/(.*)$" /$1/latest/$2 > >We would only want to do that for projects that actually have >.htaccess files, so we can put a flag in the project-data files in >openstack-manuals and generate project-specific redirect rules (we're >already doing that for some other pages). > > Then when someone visits docs.o.o/developer/nova/cells.html it would > redirect to docs.o.o/nova/latest/cells.html. The nova team then > need to have a redirect from docs.o.o/nova/latest/cells.html to > docs.o.o/nova/latest/user/cells.html. > > If folks think that's a good approach, I will start on the patches > needed in infra and openstack-manuals (1 and 3). > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Broken nova-lxd
For the specific case with method "last_bytes", it's also used in other projects [1], an alternative solution is that add this method in oslo.utils.fileutils, then consume it from oslo. [1] http://codesearch.openstack.org/?q=last_bytes=nope== 2017-07-28 6:57 GMT+08:00 Michael Still <mi...@stillhq.com>: > Hi, > > I'm cc'ing openstack-dev because your email is the same as the comment you > made on the relevant review, and I think getting visibility with the wider > Nova team is a good idea. > > Unfortunately this is a risk of having an out of tree Nova driver, which > has never been the recommended path for implementing drivers for Nova. > Being out of tree isn't forbidden, but it does come with the cost of > staying up to date with Nova and handling changes as they occur. > > In this case, if you look at the review chain you'll see that the move is > a pre-cursor to moving this code to use oslo.privsep. Unless lxd is going > to move to privsep in lockstep with nova, your best bet would be to > duplicate this utility method in the nova-lxd codebase. > > Michael > > > > > On Thu, Jul 27, 2017 at 11:25 PM, Kharkov Alexander < > kharkovalexan...@gmail.com> wrote: > >> Hi, Michael >> I recently found that you commit to nova break nova-lxd driver >> functionality because it utilizes last_bytes function from nova/utils.py >> which you recently move to libvirt. Could you please confirm that it was >> not expected and suggest a fix? I'm currently working on nova-lxd now and >> want to have functioning unit tests to pull my changes for review. >> Your commit and review links below: >> https://git.openstack.org/cgit/openstack/nova/commit/?id=234 >> 1a41eaee5152e95379e5ed38012270af82ef5 >> https://review.openstack.org/#/c/472228/9 >> ... >> Failed nova-lxd >> ... >> >> Failed 1 tests - output below: >> >> == >> >> >> test_driver.LXDDriverTest.test_get_console_output >> >> - >> >> >> Captured traceback: >> >> ~~~ >> >> b'Traceback (most recent call last):' >> >> b' File >> "/home/ubuntu/nova-lxd/.tox/py35/lib/python3.5/site-packages/mock/mock.py", >> line 1305, in patched' >> >> b'return func(*args, **keywargs)' >> >> b' File "/home/ubuntu/nova-lxd/nova/tests/unit/virt/lxd/test_driver.py", >> line 604, in test_get_console_output' >> >> b'contents = lxd_driver.get_console_output(context, instance)' >> >> b' File "/home/ubuntu/nova-lxd/nova/virt/lxd/driver.py", line 594, >> in get_console_output' >> >> b'log_data, _ = utils.last_bytes(f, MAX_CONSOLE_BYTES)' >> >> b"AttributeError: module 'nova.utils' has no attribute 'last_bytes'" >> >> b'' >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] trying to understand CORS deprecation
Hi, I tried to fix serveral month ago in https://review.openstack.org/# /c/453723/ , but gived up due to lack of time to fix many tests, will restore it and continue on it :-) 2017-07-25 0:46 GMT+08:00 Jay Pipes <jaypi...@gmail.com>: > On 07/24/2017 12:43 PM, Sean Dague wrote: > >> I'm trying to knock out common deprecation messages which are generating >> noise in the test runs. There is a deprecation message emitted all the >> time during test runs in Nova which is: >> >> DeprecationWarning: Method 'CORS.set_latent()' has moved to >> 'method.set_defaults()': CORS.set_latent has been deprecated in favor of >> oslo_middleware.cors.set_defaults" >> >> But from what I can see it's primary caller is the cors middleware >> itself - >> https://github.com/openstack/oslo.middleware/blob/1cf39ee5c3 >> 739c18fed78946532438550f56356f/oslo_middleware/cors.py#L133-L137 >> >> >> At least I'm having a hard time finding anyone else in this stack >> calling set_latent. Is this just a circular bug on the cors.py module? >> > > > FYI: https://bugs.launchpad.net/oslo.middleware/+bug/1642008 > > It's bothered me for a while but never been able to get to the bottom of > it. > > Best, > -jay > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo.db] [relational database users] heads up for a MariaDB issue that will affect most projects
Thanks for the follow up, maybe we need document the issue and work around in some place, in alembic? 2017-07-24 23:21 GMT+08:00 Michael Bayer <mba...@redhat.com>: > hey good news, the owner of the issue upstream found that the SQL > standard agrees with my proposed behavior. So while this is current > MariaDB 10.2 / 10.3 behavior, hopefully it will be resolved in an > upcoming release within those series. not sure of the timing though > so we may not be able to duck it. > > On Mon, Jul 24, 2017 at 11:16 AM, Michael Bayer <mba...@redhat.com> wrote: > > On Mon, Jul 24, 2017 at 10:37 AM, Doug Hellmann <d...@doughellmann.com> > wrote: > >> Excerpts from Michael Bayer's message of 2017-07-23 16:39:20 -0400: > >>> Hey list - > >>> > >>> It appears that MariaDB as of version 10.2 has made an enhancement > >>> that overall is great and fairly historic in the MySQL community, > >>> they've made CHECK constraints finally work. For all of MySQL's > >>> existence, you could emit a CREATE TABLE statement that included CHECK > >>> constraint, but the CHECK phrase would be silently ignored; there are > >>> no actual CHECK constraints in MySQL. > >>> > >>> Mariadb 10.2 has now made CHECK do something! However! the bad news! > >>> They have decided that the CHECK constraint against a single column > >>> should not be implicitly dropped if you drop the column [1]. In case > >>> you were under the impression your SQLAlchemy / oslo.db project > >>> doesn't use CHECK constraints, if you are using the SQLAlchemy Boolean > >>> type, or the "ENUM" type without using MySQL's native ENUM feature > >>> (less likely), there's a simple CHECK constraint in there. > >>> > >>> So far the Zun project has reported the first bug on Alembic [2] that > >>> they can't emit a DROP COLUMN for a boolean column.In [1] I've > >>> made my complete argument for why this decision on the MariaDB side is > >>> misguided. However, be on the lookout for boolean columns that can't > >>> be DROPPED on some environments using newer MariaDB. Workarounds for > >>> now include: > >>> > >>> 1. when using Boolean(), set create_constraint=False > >>> > >>> 2. when using Boolean(), make sure it has a "name" to give the > >>> constraint, so that later you can DROP CONSTRAINT easily > >>> > >>> 3. if not doing #1 and #2, in order to drop the column you need to use > >>> the inspector (e.g. from sqlalchemy import inspect; inspector = > >>> inspect(engine)) and locate all the CHECK constraints involving the > >>> target column, and then drop them by name. > >> > >> Item 3 sounds like the description of a helper function we could add to > >> oslo.db for use in migration scripts. > > > > OK let me give a little bit more context, that if MariaDB holds steady > > here, I will have to implement #3 within Alembic itself (though yes, > > for SQLAlchemy-migrate, still needed :) ). MS SQL Server has the > > same limitation for CHECK constraints and Alembic provides for a > > SQL-only procedure that can run as a static SQL element on that > > backend; hopefully the same is possible for MySQL. > > > > > > > >> > >> Doug > >> > >>> > >>> [1] https://jira.mariadb.org/browse/MDEV-4 > >>> > >>> [2] https://bitbucket.org/zzzeek/alembic/issues/440/cannot- > drop-boolean-column-in-mysql > >>> > >> > >> > __ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Oslo] Weekly meeting canceled on July 24
I'm not able to chair the meeting tomorrow due to attend OpenStack Days China event and we just issued the final releases of Oslo libraries for Pike last week. It seems there is no urgent stuff to handle, sol let's skip the meeting. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Stepping down from oslo-core
jd Thanks for your contribution for oslo, you are not alone on tooz, I would like to spent some time on it when I have time :-) 2017-07-20 18:24 GMT+08:00 Davanum Srinivas <dava...@gmail.com>: > Thanks for all your help @jd !! yes of course (on tooz) > > -- Dims > > On Thu, Jul 20, 2017 at 3:59 AM, Julien Danjou <jul...@danjou.info> wrote: > > Hi folks, > > > > I've not been reviewing or contributing to oslo.* stuff for a while and > > I don't intend to change that in the near future. It seems only fair to > > step down. > > > > As I'm currently the only maintainer of tooz, I'd still suggest to leave > > me on tooz-core though. :) > > > > Cheers, > > -- > > Julien Danjou > > # Free Software hacker > > # https://julien.danjou.info > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] PTL nominations
Hi oslo folks, The PTL nomination week is fast approaching [0], and as you might have guessed by the subject of this email, I am not planning to run for Queens, I'm still in the team and give some guidance about oslo PTL's daily work as previous PTL did before . It' my honor to be oslo PTL, I learned a lot and grew quickly. It's time to give someone else the opportunity to grow in the amazing role of oslo PTL [0]https://review.openstack.org/#/c/481768/4/configuration.yaml -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] next week is deadline for final release for non-client libraries
We scheduled the final release(s) for oslo libraries on July 19, please focus on bug fixing. thanks 2017-07-14 20:48 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > Just a reminder, I will add final releases of oslo libraries for Pike on > next Monday. > > 2017-07-10 22:37 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > >> OpenStackers, >> >> According to Pike Schedule https://releases.openstack.org >> /pike/schedule.html >> >> Jul 17 - Jul 21 is the deadline for final release for oslo libraries, so >> please pay more attentions to your reviews which are needed for Pike. Feel >> free to ping me if you want to quicken the review process. >> >> -- >> ChangBo Guo(gcb) >> > > > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all] next week is deadline for final release for non-client libraries
Just a reminder, I will add final releases of oslo libraries for Pike on next Monday. 2017-07-10 22:37 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > OpenStackers, > > According to Pike Schedule https://releases.openstack. > org/pike/schedule.html > > Jul 17 - Jul 21 is the deadline for final release for oslo libraries, so > please pay more attentions to your reviews which are needed for Pike. Feel > free to ping me if you want to quicken the review process. > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][all] next week is deadline for final release for non-client libraries
OpenStackers, According to Pike Schedule https://releases.openstack.org/pike/schedule.html Jul 17 - Jul 21 is the deadline for final release for oslo libraries, so please pay more attentions to your reviews which are needed for Pike. Feel free to ping me if you want to quicken the review process. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Oslo] PTG Planning
Hi Oslo folks, I created a planning etherpad[1] for topics for the next PTG in Denver. Please add any topics there, then we can schedule the topics before the PTG. [1]https://etherpad.openstack.org/p/oslo-ptg-queens -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] scheduling oslosphinx for retirement at the start of queens
+1 2017-07-10 21:38 GMT+08:00 Davanum Srinivas <dava...@gmail.com>: > +1 from me > > On Mon, Jul 10, 2017 at 9:10 AM, Doug Hellmann <d...@doughellmann.com> > wrote: > > Oslo team, > > > > With all documentation now moving to use the openstackdocs theme, > > I propose that we retire the oslosphinx repository during Queens. > > We should go ahead and create the stable/pike branch at the end of > > this cycle, so that we have a way to deal with bugs in existing > > pike releases, but I think we can retire the repository at any point > > after that. > > > > Thoughts? > > > > Doug > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable][release] Last release date vs End of Life date
Thanks tony for raising up this, better document this in some place :-) 2017-06-28 16:51 GMT+08:00 Thierry Carrez <thie...@openstack.org>: > Sean McGinnis wrote: > > On Tue, Jun 27, 2017 at 02:47:30PM -0400, Doug Hellmann wrote: > >> Excerpts from Tony Breeds's message of 2017-06-27 16:51:37 +1000: > >>> Hi all, > >>> Up 'til now we haven't set a last release date for a stable branch > >>> approaching end of life. It seems like formalizing that would be a > good > >>> thing. > >>> > >>> This comes up as we need time to verify that said release integrates > >>> well (at least doesn't break) said branch. So should we define a date > >>> for the last release for *libraries* services are less critical as > we're > >>> always testing the HEAD of that branch. > >>> > >>> I'd suggest it be 2 weeks before EOL date. Thoughts? > >> > >> That makes sense. > > > > Agree, that makes sense to me too. Unless something has gone horribly > wrong, > > two weeks should be plenty to make sure things are settled before things > get > > wrapped up. > > +1 > > > -- > Thierry Carrez (ttx) > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology
+1000 Thanks for the proposal, " OpenStack projects" vs "OpenStack-Hosted projects" is more clear for everyone. That also helps people uderstand the scope of OpenStack projects when evaluating the maturity of OpenStack. We would gain more benifit. I like the idea. 2017-06-15 17:15 GMT+08:00 Thierry Carrez <thie...@openstack.org>: > Hi everyone, > > Back in 2014, OpenStack was facing a problem. Our project structure, > inherited from days where Nova, Swift and friends were the only game in > town, was not working anymore. The "integrated release" that we ended up > producing was not really integrated, already too big to be installed by > everyone, and yet too small to accommodate the growing interest in other > forms of "open infrastructure". The incubation process (from stackforge > to incubated, from incubated to integrated) created catch-22s that > prevented projects from gathering enough interest to reach the upper > layers. Something had to give. > > The project structure reform[1] that resulted from those discussions > switched to a simpler model: project teams would be approved based on > how well they fit the OpenStack overall mission and community > principles, rather than based on a degree of maturity. It was nicknamed > "the big tent" based on a blogpost[2] that Monty wrote -- mostly > explaining that things produced by the OpenStack community should be > considered OpenStack projects. > > So the reform removed the concept of incubated vs. integrated, in favor > of a single "official" category. Tags[3] were introduced to better > describe the degree of maturity of the various official things. "Being > part of the big tent" was synonymous to "being an official project" (but > people kept saying the former). > > At around the same time, mostly for technical reasons around the > difficulty of renaming git repositories, the "stackforge/" git > repository prefix was discontinued (all projects hosted on OpenStack > infrastructure would be created under an "openstack/" git repository > prefix). > > All those events combined, though, sent a mixed message, which we are > still struggling with today. "Big tent" has a flea market connotation of > "everyone can come in". Combined with the fact that all git repositories > are under the same prefix, it created a lot of confusion. Some people > even think the big tent is the openstack/ namespace, not the list of > official projects. We tried to stop using the "big tent" meme, but (I > blame Monty), the name is still sticking. I think it's time to more > aggressively get rid of it. We tried using "unofficial" and "official" > terminology, but that did not stick either. > > I'd like to propose that we introduce a new concept: "OpenStack-Hosted > projects". There would be "OpenStack projects" on one side, and > "Projects hosted on OpenStack infrastructure" on the other side (all > still under the openstack/ git repo prefix). We'll stop saying "official > OpenStack project" and "unofficial OpenStack project". The only > "OpenStack projects" will be the official ones. We'll chase down the > last mentions of "big tent" in documentation and remove it from our > vocabulary. > > I think this new wording (replacing what was previously Stackforge, > replacing what was previously called "unofficial OpenStack projects") > will bring some clarity as to what is OpenStack and what is beyond it. > > Thoughts ? > > [1] > https://governance.openstack.org/tc/resolutions/20141202- > project-structure-reform-spec.html > [2] http://inaugust.com/posts/big-tent.html > [3] https://governance.openstack.org/tc/reference/tags/index.html > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.db] Stepping down from core
Roman, Thanks for your contributions for oslo.db, hope we can have cross path again in the futrue. Best wishes! 2017-06-11 23:17 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > Excerpts from Roman Podoliaka's message of 2017-06-11 17:32:49 +0300: > > Hi all, > > > > I recently changed job and hasn't been able to devote as much time to > > oslo.db as it is expected from a core reviewer. I'm no longer working > > on OpenStack, so you won't see me around much. > > > > Anyway, it's been an amazing experience to work with all of you! Best > > of luck! And see ya at various PyCon's around the world! ;) > > > > Thanks, > > Roman > > > > Thanks for your help launching oslo.db and making it so useful, > Roman. We'll miss your contributions! > > Good luck with your new job, > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][nova] Goodbye^W See you later
Jim, Though I wasn't involved Ironic too much, I know you're one of the best Ironicer. Good luck! 2017-06-09 9:33 GMT+08:00 phuon...@vn.fujitsu.com <phuon...@vn.fujitsu.com>: > Hi Jim, good luck to you. Remember the time we discussed right after you > waked up in the morning. :) > > > > Phuong. > > > > *From:* Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > *Sent:* Thursday, June 08, 2017 7:45 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [ironic][nova] Goodbye^W See you later > > > > Hey friends, > > > > I've been mostly missing for the past six weeks while looking for a new > job, so maybe you've forgotten me already, maybe not. I'm happy to tell you > I've found one that I think is a great opportunity for me. But, I'm sad to > tell you that it's totally outside of the OpenStack community. > > > > The last 3.5 years have been amazing. I'm extremely grateful that I've > been able to work in this community - I've learned so much and met so many > awesome people. I'm going to miss the insane(ly awesome) level of > collaboration, the summits, the PTGs, and even some of the bikeshedding. > We've built amazing things together, and I'm sure y'all will continue to do > so without me. > > > > I'll still be lurking in #openstack-dev and #openstack-ironic for a while, > if people need me to drop a -2 or dictate old knowledge or whatever, feel > free to ping me. Or if you just want to chat. :) > > > > <3 jroll > > > > P.S. obviously my core permissions should be dropped now :P > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][all][logging] logging debugging improvement work status
Thanks Doug, I will release it on next Monday. 2017-05-25 22:15 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > One outcome from the forum session about improving logging debugging > was agreement that the proposal to add more details about exceptions > to the logs. The spec [1] was updated and has been approved, and > the patches to implement the work in oslo.log have also been approved > [2]. > > The changes should be included in the Oslo releases next week. I > think it makes sense to hold off until then, given the holiday > weekend for many of the Oslo team members. As soon as the constraints > are updated to allow the new version of oslo.log, the log output > produced by devstack will change so that any log message emitted > in the context of handling an exception will include that exception > detail at the end of the log message (see the spec for details about > configuring that behavior). > > After we start seeing this run in the gate for a bit, we can evaluate > if we need to tweak the format or skip any other of Python's built-in > exception types. > > Thanks to Dims, Flavio, gcb, and Eric Fried for their help with > code reviews, and to the rest of the Oslo team and everyone who > participated in the discussion of the spec online and in Boston. > > Doug > > [1] http://specs.openstack.org/openstack/oslo-specs/specs/ > pike/improving-logging-debugging.html > [2] https://review.openstack.org/#/q/topic:improve-logging-debugging > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] cancel weekly meeting in next week (05/29)
Hi folks, Just a reminder that we will skip oslo weekly meeting in next week, due to the holiday of the USA. Coincidently, It's also a holiday for Chinese. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.messaging] Call to deprecate the 'pika' driver in the oslo.messaging project
+1 , let's focus on key drivers. 2017-05-17 2:02 GMT+08:00 Joshua Harlow <harlo...@fastmail.com>: > Fine with me, > > I'd personally rather get down to say 2 'great' drivers for RPC, > > And say 1 (or 2?) for notifications. > > So ya, wfm. > > -Josh > > > Mehdi Abaakouk wrote: > >> +1 too, I haven't seen its contributors since a while. >> >> On Mon, May 15, 2017 at 09:42:00PM -0400, Flavio Percoco wrote: >> >>> On 15/05/17 15:29 -0500, Ben Nemec wrote: >>> >>>> >>>> >>>> On 05/15/2017 01:55 PM, Doug Hellmann wrote: >>>> >>>>> Excerpts from Davanum Srinivas (dims)'s message of 2017-05-15 >>>>> 14:27:36 -0400: >>>>> >>>>>> On Mon, May 15, 2017 at 2:08 PM, Ken Giusti <kgiu...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> It was decided at the oslo.messaging forum at summit that the pika >>>>>>> driver will be marked as deprecated [1] for removal. >>>>>>> >>>>>> >>>>>> [dims} +1 from me. >>>>>> >>>>> >>>>> +1 >>>>> >>>> >>>> Also +1 >>>> >>> >>> +1 >>> >>> Flavio >>> >>> -- >>> @flaper87 >>> Flavio Percoco >>> >> >> >> >> >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] can we make everyone drop eventlet? (was: Can we stop global requirements update?)
We discussed this for a long time, As I know , some projects use eventlet heavily like Nova [1], If everyon agree with removing eventlet , we can set it as one of comunnity goals[2] [1]https://github.com/openstack/nova/blob/master/doc/source/threading.rst [2]https://etherpad.openstack.org/p/community-goals 2017-05-20 5:09 GMT+08:00 Mike Bayer <mba...@redhat.com>: > FTFY > > > > On 05/19/2017 03:58 PM, Joshua Harlow wrote: > >> Mehdi Abaakouk wrote: >> >>> Not really, I just put some comments on reviews and discus this on IRC. >>> Since nobody except Telemetry have expressed/try to get rid of eventlet. >>> >> >> Octavia is using cotyledon and they have gotten rid of eventlet. Didn't >> seem like it was that hard either to do it (of course the experience in how >> easy it was is likely not transferable to other projects...) >> >> -Josh >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] cancel weekly meeting in next week (05/08)
Hi folks, Just a reminder that we will skip oslo weekly meeting in next week, most people should be in the Boston Summit :-) -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Colleen Murphy for core
Congratulations, Colleen. Thanks for reivewing my enforce_type related patches recently. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Oslo Core team updates
Greetings, Some oslo core reviewers have changed their focus, didn't work on Oslo or OpenStack anymore . They did superexcellent work in the past, It's honor to work them, I would like to sent out to dev ML before we remove acces right on the gerrit. Please reply to me if you want to be part of Oslo team again . The removals include Alexi Lee, Gevorg Davoian, Oleksii Zamiation, Ronald Bradford, Sachi King. -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] priorities for the current week (05/02-05/05)
Oslo folks, Oslo team maintain 35 libraries, each core reviewer focuses on part of them. In last several weeks, We did some work , try to make Oslo review productive and efficiently . Summarize them as follow: 1. Collect core reviwers' focuses The Oslo program brings together generalist code reviewers and specialist API maintainers. Not all of generalist code reviewers know all libraries enough, you cand find the list in section one in [1]. 2. Generate unified review dashboard I post review dashboard links in https://wiki.openstack.org/wiki/Oslo#Review_Links and section three in [1] That would be helpful to the review process. 3. Highlight priorities We discussed this in last weekly meeting [2], will try to post hight priorities each week, You can edit section two in [1] to let others pay more attention. This week we need more input to Dough's logging related patches before the Summit. https://review.openstack.org/#/c/460112/ https://review.openstack.org/459426 https://review.openstack.org/459424 https://review.openstack.org/461506 [1] https://etherpad.openstack.org/p/oslo-pike-tracking [2] http://eavesdrop.openstack.org/meetings/oslo/2017/oslo.2017-05-01-14.01.log.html -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone]oslo.config 4.0 will break projects' unit test
Most projects landed fixes for oslo.config 4.0. Keystone needs more effort to make the unit test pass. In addition to https://review.openstack.org/#/c/455391/ which fixes most of failures. There are other failures [1] , I created a bug [2] for Keytone. These chagnes are related with Keystone domain knowlege , I only tried to fix simple ones. so keystone team, please help dig, thanks [1] http://logs.openstack.org/periodic/periodic-keystone-py27-with-oslo-master/0868d74/testr_results.html.gz [2] https://bugs.launchpad.net/keystone/+bug/1686921 2017-04-16 15:32 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > As I expect, there are some failures in periodic tasks recently [1] if we > set enforce_type with True by default, we'd better fix them before we > release oslo.config 4.0. Some guys had been working on this : > Nova: https://review.openstack.org/455534 should fix failures > tempest: https://review.openstack.org/456445 fixed > Keystone: https://review.openstack.org/455391 wait for oslo.config 4.0 > > We still need help from Glance/Ironic/Octavia > Glance: https://review.openstack.org/#/c/455522/ need review > Ironic: Need fix failure in http://logs.openstack.org/ > periodic/periodic-ironic-py27-with-oslo-master/680abfe/ > testr_results.html.gz > Octavia: Need fix failure in http://logs.openstack.org/ > periodic/periodic-octavia-py35-with-oslo-master/80fee03/ > testr_results.html.gz > > [1] http://status.openstack.org/openstack-health/#/?groupKey= > build_name=hour=-with-oslo > > 2017-04-04 0:01 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > >> Hi ALL, >> >> oslo_config provides method CONF.set_override[1] , developers usually use >> it to change config option's value in tests. That's convenient . By >> default parameter enforce_type=False, it doesn't check any type or >> value of override. If set enforce_type=True , will check parameter >> override's type and value. In production code(running time code), >> oslo_config always checks config option's value. In short, we test and >> run code in different ways. so there's gap: config option with wrong >> type or invalid value can pass tests when >> parameter enforce_type = False in consuming projects. that means some >> invalid or wrong tests are in our code base. >> >> >> We began to warn user about the change since Sep, 2016 in [2]. This >> change will notify consuming project to write correct test cases with >> config options. >> We would make enforce_type = true by default in [3], that may break some >> projects' tests, that's also raise wrong unit tests. The failure is easy to >> fix, which >> is recommended. >> >> >> [1] https://github.com/openstack/oslo.config/blob/efb287a94645b1 >> 5b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613 >> [2] https://review.openstack.org/#/c/365476/ >> [3] https://review.openstack.org/328692 >> >> -- >> ChangBo Guo(gcb) >> > > > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] priorities for the current week (04/23-04/27)
Please give https://review.openstack.org/#/c/457050/ high priority , which blocks oslo.config 4.0 in https://review.openstack.org/#/c/459411/ For more details, please see http://logs.openstack.org/11/459411/1/check/gate-cross-glance-python27-ubuntu-xenial/ae7ac1d/testr_results.html.gz 2017-04-24 6:42 GMT+08:00 Brian Rosmaita <rosmaita.foss...@gmail.com>: > 1 Pike midcycle review > == > Hopefully, you saw my summary of the Glance Pike virtual midcycle > meeting ... if not, here it is: > - http://lists.openstack.org/pipermail/openstack-dev/2017- > April/115777.html > > > 2 Spec finalization > === > I realize that many Glance cores are kind of preoccupied at the moment, > but here are some patches that will be quick to review and can help get > the specs repo cleaned up: > - https://review.openstack.org/#/c/459132/ > - https://review.openstack.org/#/c/451560/ > - https://review.openstack.org/#/c/206120/ > - https://review.openstack.org/#/c/448680/ > > See this etherpad if you're wondering why we're still messing with some > of the above patches: > https://etherpad.openstack.org/p/glance-pike-specs-review > > > 3 Image import refactor > === > Of course! > - https://review.openstack.org/#/c/391442/ > - https://review.openstack.org/#/c/391441/ > - https://review.openstack.org/#/c/443636/ > - https://review.openstack.org/#/c/443632/ > - https://review.openstack.org/#/c/443633/ > > > Have a productive week! > brian > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Update Review dashboard links
There is tinny update the latest links are: libs_part1 https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslo.%2A+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fcastellan+OR+project%3Aopenstack%2Ffuturist+OR%0Aproject%3Aopenstack%2Fautomaton+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Ddev%2Foslo%2Dcookiecutter+OR+project%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+One%29+Specs=project%3Aopenstack%2Foslo%2Dspecs=project%3Aopenstack%2Fautomaton=project%3Aopenstack%2Fcastellan=project%3Aopenstack%2Ddev%2Fcookiecutter=project%3Aopenstack%2Fdebtcollector=project%3Aopenstack%2Ffuturist=project%3Aopenstack%2Fmox3%2Dcookiecutter=project%3Aopenstack%2Ddev%2Foslo%2Dcookiecutter=project%3Aopenstack%2Foslo.cache libs_part2 https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Foslo.%2A%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Two%29=project%3Aopenstack%2Foslo.privsep=project%3Aopenstack%2Foslo.reports=project%3Aopenstack%2Foslo.rootwrap=project%3Aopenstack%2Foslo.serialization=project%3Aopenstack%2Foslo.service=project%3Aopenstack%2Foslo.tools=project%3Aopenstack%2Foslo.utils=project%3Aopenstack%2Foslo.versionedobjects=project%3Aopenstack%2Foslo.vmware libs_part3 https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Foslo.%2A%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Three%29=project%3Aopenstack%2Foslo.concurrency=project%3Aopenstack%2Foslo.config=project%3Aopenstack%2Foslo.context=project%3Aopenstack%2Foslo.db=project%3Aopenstack%2Foslo.i18n=project%3Aopenstack%2Foslo.log=project%3Aopenstack%2Foslo.messaging=project%3Aopenstack%2Foslo.middleware=project%3Aopenstack%2Foslo.policy libs_part4 https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslosphinx+OR+project%3Aopenstack%2Foslotest+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fpbr%29%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Four%29=project%3Aopenstack%2Foslosphinx=project%3Aopenstack%2Foslotest=project%3Aopenstack%2Fosprofiler=project%3Aopenstack%2Ddev%2Fpbr=project%3Aopenstack%2Fpylockfile=project%3Aopenstack%2Fstevedore=project%3Aopenstack%2Ftaskflow=project%3Aopenstack%2Ftooz main https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslo.%2A+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fpylockfile+OR+project%3Aopenstack%2Fcastellan+OR%0Aproject%3Aopenstack%2Ffuturist+OR+project%3Aopenstack%2Fautomaton+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Ddev%2Fpbr+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Ddev%2Foslo%2Dcookiecutter+OR+project%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%0ANOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself=Oslo+Review+Inbox+Specs=project%3Aopenstack%2Foslo%2Dspecs+Fixes=topic%3A%5Ebug%2F.%2A=message%3A%22Blueprint%22+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A5d+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50+Contributors=reviewer%3A10068+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1+limit%3A50+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A2d 2017-04-24 20:04 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > I just posted a update of our Review dashboard config files in > https://review.openstack.org/#/c/459247/. > the main.dash was copied from oslo-incubator with adding missing > libraries. > I must divid 35 libraries into 4 groups becuase each dashboard allows up > to 10 queries. > > > The output can be used directly , hope this will be useful. > > # ./build_dashboards.sh /home/changboguo/code/os/gerrit-dash-creator > /home/changboguo/code/os/oslo.tools/dashboards/ > > > libs_part1 > > https://review.openstack.org/#/dashboard/?foreach=% > 28project%3A%5Eopenstack%2Foslo.%2A+OR+project% > 3Aopenstack%2Fdebtcollector+OR%0Aproje
[openstack-dev] [oslo] Update Review dashboard links
I just posted a update of our Review dashboard config files in https://review.openstack.org/#/c/459247/. the main.dash was copied from oslo-incubator with adding missing libraries. I must divid 35 libraries into 4 groups becuase each dashboard allows up to 10 queries. The output can be used directly , hope this will be useful. # ./build_dashboards.sh /home/changboguo/code/os/gerrit-dash-creator /home/changboguo/code/os/oslo.tools/dashboards/ libs_part1 https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslo.%2A+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fcastellan+OR+project%3Aopenstack%2Ffuturist+OR%0Aproject%3Aopenstack%2Fautomaton+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Ddev%2Foslo%2Dcookiecutter+OR+project%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+One%29+Specs=project%3Aopenstack%2Foslo%2Dspecs=project%3Aopenstack%2Fautomaton=project%3Aopenstack%2Fcastellan=project%3Aopenstack%2Ddev%2Fcookiecutter=project%3Aopenstack%2Fdebtcollector=project%3Aopenstack%2Ffuturist=project%3Aopenstack%2Fmox3%2Dcookiecutter=project%3Aopenstack%2Ddev%2Fcookiecutter=project%3Aopenstack%2Foslo.cache libs_part2 https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Foslo.%2A%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Two%29=project%3Aopenstack%2Foslo.privsep=project%3Aopenstack%2Foslo.reports=project%3Aopenstack%2Foslo.rootwrap=project%3Aopenstack%2Foslo.serialization=project%3Aopenstack%2Foslo.service=project%3Aopenstack%2Foslo.tools=project%3Aopenstack%2Foslo.utils=project%3Aopenstack%2Foslo.versionedobjects=project%3Aopenstack%2Foslo.vmware libs_part3 https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Foslo.%2A%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Three%29=project%3Aopenstack%2Foslo.concurrency=project%3Aopenstack%2Foslo.config=project%3Aopenstack%2Foslo.context=project%3Aopenstack%2Foslo.db=project%3Aopenstack%2Foslo.i18n=project%3Aopenstack%2Foslo.log=project%3Aopenstack%2Foslo.messaging=project%3Aopenstack%2Foslo.middleware=project%3Aopenstack%2Foslo.policy libs_part4 https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslosphinx+OR+project%3Aopenstack%2Foslotest+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fpbr%29%0Astatus%3Aopen+NOT+owner%3Aself=Oslo+Review+Inbox%28Part+Two%29=project%3Aopenstack%2Foslosphinx=project%3Aopenstack%2Foslotest=project%3Aopenstack%2Fosprofiler=project%3Aopenstack%2Ddev%2Fpbr=project%3Aopenstack%2Fpylockfile=project%3Aopenstack%2Fstevedore=project%3Aopenstack%2Ftaskflow=project%3Aopenstack%2Ftooz main https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2Foslo.%2A+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fpylockfile+OR+project%3Aopenstack%2Fcastellan+OR%0Aproject%3Aopenstack%2Ffuturist+OR+project%3Aopenstack%2Fautomaton+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Ddev%2Fpbr+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Ddev%2Foslo%2Dcookiecutter+OR+project%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%0ANOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself=Oslo+Review+Inbox+Specs=project%3Aopenstack%2Foslo%2Dspecs+Fixes=topic%3A%5Ebug%2F.%2A=message%3A%22Blueprint%22+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A5d+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50+Contributors=reviewer%3A10068+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1+limit%3A50+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A2d -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] do we still need non-voting tests for older releases?
>From operator and user view, we just make sure same stable branch of oslo and other service work well . So I think we don't need these jobs anymore, would like to get more input from others 2017-04-21 23:37 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > Excerpts from ChangBo Guo's message of 2017-04-21 16:04:35 +0800: > > What the related thing I can remember is we discuss oslo libraries' > > compatibility in [1], which was abandoned. > > I made stable compat ocata jobs non-voting in [2], hope can revert when > > related bug is fixed before. > > But now, If we decide remove them, we don't revert anymore. > > With our constraint system and with stable branches for libraries, > do we need new releases from master to be compatible with older > services on stable branches? > > Doug > > > > > [1] https://review.openstack.org/226157 > > [2] https://review.openstack.org/#/c/448431 > > > > 2017-04-20 0:42 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > > > > > I noticed again today that we have some test jobs running for some > > > of the Oslo libraries against old versions of services (e.g., > > > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-newton, > > > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-ocata, and > > > gate-oslo.log-src-grenade-dsvm-ubuntu-xenial-nv). > > > > > > I don't remember what those are for, but I imagine they have to do > > > with testing compatibility. They're all non-voting, though, so maybe > > > not? > > > > > > Now that we're constraining libraries in our test systems, I wonder > > > if we still need the jobs at all? > > > > > > Doug > > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Can we stop global requirements update?
2017-04-19 23:10 GMT+08:00 Clark Boylan <cboy...@sapwetik.org>: > On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote: > > Hoy, > > > > So Gnocchi gate is all broken (agan) because it depends on "pbr" and > > some new release of oslo.* depends on pbr!=2.1.0. > > > > Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0 > > that got in banished by requirements Gods. It does not prevent it to be > > used e.g. to install the software or get version information. But it > > does break anything that is not in OpenStack because well, pip installs > > the latest pbr (2.1.0) and then oslo.* is unhappy about it. > > It actually breaks everything, including OpenStack. Shade and others are > affected by this as well. The specific problem here is that PBR is a > setup_requires which means it gets installed by easy_install before > anything else. This means that the requirements restrictions are not > applied to it (neither are the constraints). So you get latest PBR from > easy_install then later when something checks the requirements > (pkg_resources console script entrypoints?) they break because latest > PBR isn't allowed. > > What we disscuss here is the way to avoid break things, not sure we add pbr into periodic-**-with-oslo-master works in https://review.openstack.org/458753 We need to stop pinning PBR and more generally stop pinning any > setup_requires (there are a few more now since setuptools itself is > starting to use that to list its deps rather than bundling them). > > > So I understand the culprit is probably pip installation scheme, and we > > can blame him until we fix it. I'm also trying to push pbr 2.2.0 to > > avoid the entire issue. > > Yes, a new release of PBR undoing the "pin" is the current sane step > forward for fixing this particular issue. Monty also suggested that we > gate global requirements changes on requiring changes not pin any > setup_requires. > > > But for the future, could we stop updating the requirements in oslo libs > > for no good reason? just because some random OpenStack project hit a bug > > somewhere? > > > > For example, I've removed requirements update on tooz¹ for more than a > > year now, which did not break *anything* in the meantime, proving that > > this process is giving more problem than solutions. Oslo libs doing that > > automatic update introduce more pain for all consumers than anything (at > > least not in OpenStack). > > You are likely largely shielded by the constraints list here which is > derivative of the global requirements list. Basically by using > constraints you get distilled global requirements and even without being > part of the requirements updates you'd be shielded from breakages when > installed via something like devstack or other deployment method using > constraints. > > > So if we care about Oslo users outside OpenStack, I beg us to stop this > > crazyness. If we don't, we'll just spend time getting rid of Oslo over > > the long term… > > I think we know from experience that just stopping (eg reverting to the > situation we had before requirements and constraints) would lead to > sadness. Installations would frequently be impossible due to some > unresolvable error in dependency resolution. Do you have some > alternative in mind? Perhaps we loosen the in project requirements and > explicitly state that constraints are known to work due to testing and > users should use constraints? That would give users control to manage > their own constraints list too if they wish. Maybe we do this in > libraries while continuing to be more specific in applications? > > > > > My 2c, > > > > Cheers, > > > > ¹ Unless some API changed in a dep and we needed to raise the dep, > > obviously. > > > > -- > > Julien Danjou > > # Free Software hacker > > # https://julien.danjou.info > > I don't have all the answers, but am fairly certain the situation we > have today is better than the one from several years ago. It is just not > perfect. I think we are better served by refining the current setup or > replacing it with something better but not by reverting. > > Clark > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] do we still need non-voting tests for older releases?
What the related thing I can remember is we discuss oslo libraries' compatibility in [1], which was abandoned. I made stable compat ocata jobs non-voting in [2], hope can revert when related bug is fixed before. But now, If we decide remove them, we don't revert anymore. [1] https://review.openstack.org/226157 [2] https://review.openstack.org/#/c/448431 2017-04-20 0:42 GMT+08:00 Doug Hellmann <d...@doughellmann.com>: > I noticed again today that we have some test jobs running for some > of the Oslo libraries against old versions of services (e.g., > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-newton, > gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-ocata, and > gate-oslo.log-src-grenade-dsvm-ubuntu-xenial-nv). > > I don't remember what those are for, but I imagine they have to do > with testing compatibility. They're all non-voting, though, so maybe > not? > > Now that we're constraining libraries in our test systems, I wonder > if we still need the jobs at all? > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core
There is no objection in past 7 days, so I added Stephen Finucane as pbr-core group, welecom Stephen ! 2017-04-19 0:01 GMT+08:00 Jeremy Stanley <fu...@yuggoth.org>: > On 2017-04-12 08:14:31 -0500 (-0500), Monty Taylor wrote: > [...] > > Recently Stephen Finucane (sfinucan) has stepped up to the plate > > to help sort out issues we've been having. He's shown a lack of > > fear of the codebase and an understanding of what's going on. He's > > also following through on patches to projects themselves when > > needed, which is a huge part of the game. And most importantly he > > knows when to suggest we _not_ do something. > [...] > > As an occasional pbr author and transitive core, I'm in favor. The > more help the better! > -- > Jeremy Stanley > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] blog post about being PTL in OpenStack
yeah, I read https://blog.flaper87.com/something-about-being-a-ptl.html before I take the role , that really helps me a lot . I aslo share the blog in some meetups. Thanks Flavio and Emilien. and I will attend https://www.openstack.org/summ it/boston-2017/summit-schedule/events/18518/ 2017-04-18 4:15 GMT+08:00 Flavio Percoco <fla...@redhat.com>: > On 17/04/17 13:39 -0500, Matt Riedemann wrote: > >> On 4/13/2017 7:22 PM, Emilien Macchi wrote: >> >>> Exceptionally, I'll self-promote a blog post that I wrote about my >>> personal experience of being PTL in OpenStack. >>> >>> http://my1.fr/blog/my-journey-as-an-openstack-ptl/ >>> >>> My hope is to engage some discussion about what our community thinks >>> about this role and how we could bring more leaders in OpenStack. >>> This blog post also explains why I won't run for PTL during the next >>> cycle. >>> >>> Happy week-end, >>> >>> >> Thanks Emilien. Coincidentally, stevemar, armax and I have a talk at the >> upcoming Boston summit with a lot of the same content: >> >> https://www.openstack.org/summit/boston-2017/summit-schedule >> /events/18518/ >> >> > alright, I'll throw mine in the mix as well. I wrote this one a couple of > cycles > ago, right before the PTL elections happened. I'm happy to talk about this > and > have further discussions. > > https://blog.flaper87.com/something-about-being-a-ptl.html > > Flavio > > -- > @flaper87 > Flavio Percoco > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][glance][ironic][octavia][nova]oslo.config 4.0 will break projects' unit test
Thanks Michael Johnson for your fix ! We plan to release oslo.config 4.0 when each project has a fix at least in review , Latest updates: Nova: https://review.openstack.org/457188 need review Keystone: https://review.openstack.org/455391 wait for oslo.config 4.0 Glance: https://review.openstack.org/#/c/455522/ need review Octavia: https://review.openstack.org/457356 need review Ironic: talked with ironic liason curshil in oslo weekly meeting, will dig into it. 2017-04-18 4:51 GMT+08:00 Michael Johnson <johnso...@gmail.com>: > Thank you ChangBo, I have resolved the issues in octavia in this patch: > https://review.openstack.org/457356 up for review. > > > > Michael > > > > *From:* ChangBo Guo [mailto:glongw...@gmail.com] > *Sent:* Sunday, April 16, 2017 12:32 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [glance][ironic][octavia] oslo.config 4.0 > will break projects' unit test > > > > As I expect, there are some failures in periodic tasks recently [1] if we > set enforce_type with True by default, we'd better fix them before we > release oslo.config 4.0. Some guys had been working on this : > Nova: https://review.openstack.org/455534 should fix failures > > tempest: https://review.openstack.org/456445 fixed > > Keystone: https://review.openstack.org/455391 wait for oslo.config 4.0 > > > > We still need help from Glance/Ironic/Octavia > > Glance: https://review.openstack.org/#/c/455522/ need review > > Ironic: Need fix failure in http://logs.openstack.org/ > periodic/periodic-ironic-py27-with-oslo-master/680abfe/ > testr_results.html.gz > Octavia: Need fix failure in http://logs.openstack.org/ > periodic/periodic-octavia-py35-with-oslo-master/80fee03/ > testr_results.html.gz > > > [1] http://status.openstack.org/openstack-health/#/?groupKey= > build_name=hour=-with-oslo > > > > 2017-04-04 0:01 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > > Hi ALL, > > > oslo_config provides method CONF.set_override[1] , developers usually use > it to change config option's value in tests. That's convenient . By > default parameter enforce_type=False, it doesn't check any type or value > of override. If set enforce_type=True , will check parameter override's > type and value. In production code(running time code), oslo_config > always checks config option's value. In short, we test and run code in > different ways. so there's gap: config option with wrong type or > invalid value can pass tests when > > parameter enforce_type = False in consuming projects. that means some > invalid or wrong tests are in our code base. > > > We began to warn user about the change since Sep, 2016 in [2]. This change > will notify consuming project to write correct test cases with config > options. > > We would make enforce_type = true by default in [3], that may break some > projects' tests, that's also raise wrong unit tests. The failure is easy to > fix, which > > is recommended. > > > > [1] https://github.com/openstack/oslo.config/blob/ > efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613 > [2] https://review.openstack.org/#/c/365476/ > [3] https://review.openstack.org/328692 > > > -- > > ChangBo Guo(gcb) > > > > > -- > > ChangBo Guo(gcb) > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance][ironic][octavia] oslo.config 4.0 will break projects' unit test
As I expect, there are some failures in periodic tasks recently [1] if we set enforce_type with True by default, we'd better fix them before we release oslo.config 4.0. Some guys had been working on this : Nova: https://review.openstack.org/455534 should fix failures tempest: https://review.openstack.org/456445 fixed Keystone: https://review.openstack.org/455391 wait for oslo.config 4.0 We still need help from Glance/Ironic/Octavia Glance: https://review.openstack.org/#/c/455522/ need review Ironic: Need fix failure in http://logs.openstack.org/periodic/periodic-ironic-py27-with-oslo-master/680abfe/testr_results.html.gz Octavia: Need fix failure in http://logs.openstack.org/periodic/periodic-octavia-py35-with-oslo-master/80fee03/testr_results.html.gz [1] http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-oslo 2017-04-04 0:01 GMT+08:00 ChangBo Guo <glongw...@gmail.com>: > Hi ALL, > > oslo_config provides method CONF.set_override[1] , developers usually use > it to change config option's value in tests. That's convenient . By > default parameter enforce_type=False, it doesn't check any type or > value of override. If set enforce_type=True , will check parameter > override's type and value. In production code(running time code), > oslo_config always checks config option's value. In short, we test and > run code in different ways. so there's gap: config option with wrong > type or invalid value can pass tests when > parameter enforce_type = False in consuming projects. that means some > invalid or wrong tests are in our code base. > > > We began to warn user about the change since Sep, 2016 in [2]. This change > will notify consuming project to write correct test cases with config > options. > We would make enforce_type = true by default in [3], that may break some > projects' tests, that's also raise wrong unit tests. The failure is easy to > fix, which > is recommended. > > > [1] https://github.com/openstack/oslo.config/blob/ > efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613 > [2] https://review.openstack.org/#/c/365476/ > [3] https://review.openstack.org/328692 > > -- > ChangBo Guo(gcb) > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core
+1, we really need more people who know pbr well :-) 2017-04-12 21:14 GMT+08:00 Monty Taylor <mord...@inaugust.com>: > Hey all, > > As I'm sure you all know, pbr is both our most pervasively used dependency > and our least well understood. Nobody ever wants to look at the code > (sorry, I can write ugly code sometimes - but also wow setuptools) or dig > in to figure out what happened when things break. > > Recently Stephen Finucane (sfinucan) has stepped up to the plate to help > sort out issues we've been having. He's shown a lack of fear of the > codebase and an understanding of what's going on. He's also following > through on patches to projects themselves when needed, which is a huge part > of the game. And most importantly he knows when to suggest we _not_ do > something. > > It's not a HUGE corpus of work we have to go on - but that's a good thing > - pbr shouldn't chance much - but it's in keeping with the other active pbr > maintainers: > > http://stackalytics.com/report/contribution/pbr/90 > > Monty > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][all] Make CONF.set_override with paramter enforce_type=True by default may break unit test
Hi ALL, oslo_config provides method CONF.set_override[1] , developers usually use it to change config option's value in tests. That's convenient . By default parameter enforce_type=False, it doesn't check any type or value of override. If set enforce_type=True , will check parameter override's type and value. In production code(running time code), oslo_config always checks config option's value. In short, we test and run code in different ways. so there's gap: config option with wrong type or invalid value can pass tests when parameter enforce_type = False in consuming projects. that means some invalid or wrong tests are in our code base. We began to warn user about the change since Sep, 2016 in [2]. This change will notify consuming project to write correct test cases with config options. We would make enforce_type = true by default in [3], that may break some projects' tests, that's also raise wrong unit tests. The failure is easy to fix, which is recommended. [1] https://github.com/openstack/oslo.config/blob/efb287a94645b15b634e8c344352696ff85c219f/oslo_config/cfg.py#L2613 [2] https://review.openstack.org/#/c/365476/ [3] https://review.openstack.org/328692 -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
