Re: [openstack-dev] [all] Switching to longer development cycles

The former - we're running Cells so only have a single region currently (except for Swift where we have multiple proxy endpoints around the country, all backed by a global cluster, but they have to be different regions to put them all in the service catalog). See

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Blair Bethwaite's message of 2017-12-14 17:44:53 +1100: > On 14 December 2017 at 17:36, Clint Byrum wrote: > > The batch size for "upgrade the whole cloud" is too big. Let's help our > > users advance components one at a time, and then we won't have to worry > > so

Re: [openstack-dev] [all] Switching to longer development cycles

Maybe not exactly on the topic but I’d like to express some more thoughts on OpenStack development rhythm being too harsh for newcomers and part time developers. Although I partially agree with the initial Thierry’s point I think the key thing here itself is that they are part time developers.

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 23:02:11 -0600: > On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote: > > > One thing I've always admired about Swift was how immune to the cadence > > Swift > > appears to be. > > As I've pointed out before [0], Swift is a whole

Re: [openstack-dev] [all] Switching to longer development cycles

On 14 December 2017 at 17:36, Clint Byrum wrote: > The batch size for "upgrade the whole cloud" is too big. Let's help our > users advance components one at a time, and then we won't have to worry > so much about doing the whole integrated release dance so often. Is there any

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 22:51:19 -0600: > On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote: > > > You're missing the key point that coupled with the change in the > > overall development cycle schedule we would be encouraging projects > > to release

[openstack-dev] [OpenStack][Vitrage] Vitrage Entity Graph supports various actions according to mouse events for entities.

Hello. I'm MinWookKim. I have been discussing my proposal with the Vitrage PTL a while ago, I want to get feedback from Vitrage contributors. In conclusion, my suggestion is that when I right-click on the Entity Graph provided by Vitrage, I want the user to perform various actions

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 5:44 PM, Clint Byrum wrote: > One thing I've always admired about Swift was how immune to the cadence Swift > appears to be. As I've pointed out before [0], Swift is a whole 'nother thing. It does not have API interdependencies with anything else in

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 4:38 PM, German Eichberger wrote: > It looks like the implicit expectation is that devs also need to attend the > Forums at the summit in addition to the PTG. The Forums, though important, > hardly made it worthwhile for me to attend the

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 4:31 PM, Doug Hellmann wrote: > You're missing the key point that coupled with the change in the > overall development cycle schedule we would be encouraging projects > to release more often. I'd personally rather do away with milestones > altogether

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Thierry Carrez's message of 2017-12-13 17:17:26 +0100: > Hi everyone, > > Over the past year, it has become pretty obvious to me that our > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just around

Re: [openstack-dev] [masakari] problems starting up masakari instance monitoring in devstack @ master

Hi Greg, Looks like you don’t have “devstack-masakari” host registered in Masakari database. Currently operator have to add all the hosts from failover-segment manually to Masakari database. You can use below command: Register failover-segment to Masakari database: openstack segment

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 9:13 PM, Matt Riedemann wrote: > On 12/13/2017 4:15 PM, Thierry Carrez wrote: > >> Based on several discussions I had with developers working part-time on >> OpenStack at various events lately, it sounded like slowing down our >> pace could be helpful

Re: [openstack-dev] [networking-ovn] [tripleo] enable open ptcp communication to NB and SB databases

On Wed, Dec 13, 2017 at 5:22 PM, pranab boruah wrote: > Hi folks, > The following commit[0] added support for SSL connections to NB and SB > databases. Now for enabling open ptcp communication to NB and SB dbs, > we need to do this: > > # ovn-sbctl set-connection

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 4:15 PM, Thierry Carrez wrote: Based on several discussions I had with developers working part-time on OpenStack at various events lately, it sounded like slowing down our pace could be helpful to them and generally reduce stress in OpenStack development. I know people who can

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Arkady.Kanevsky's message of 2017-12-14 02:44:24 +: > How about add to our biannual questionnaire how often customer upgrade their > openstack environment? There is quite a bit of information about deployments in the latest user survey [1], starting on page 24. Page 29 shows

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 11:17 AM, Thierry Carrez wrote: > - It doesn't mean that teams can only meet in-person once a year. > Summits would still provide a venue for team members to have an > in-person meeting. I also expect a revival of the team-organized > midcycles to

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 4:20 PM, Thierry Carrez wrote: Is the "rush" at the end of the cycle still a thing those days ? From a release management perspective it felt like the pressure was reduced in recent cycles, with less and less FFEs. But that may be that PTLs have gotten better at denying them, not

Re: [openstack-dev] [all] Switching to longer development cycles

How about add to our biannual questionnaire how often customer upgrade their openstack environment? -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Wednesday, December 13, 2017 4:20 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all]

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

Thanks edleafe, I am interested to attend but it is little early for me(i am in JST(UTC +9)), any chance we can make it to 23:00 UTC or 0:00 UTC ? -gmann On Wed, Dec 13, 2017 at 12:22 AM, Ed Leafe wrote: > Re-sending this in the hope of getting more responses. If you’re in

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

2017-12-13 21:16 GMT+08:00 gordon chung : > > > On 2017-12-13 01:52 AM, Jaze Lee wrote: >> Hello, >> >> What about move transformer to compute pollster? If we do this, we >> do not need >> transformer any more > > sorry, i don't understand. if you move the transformer,

[openstack-dev] [QA] Meeting Thursday Dec 14th at 8:00 UTC

Hello everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, Dec 14th at 8:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Dec_14th_2017_.280800_UTC.29

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

Alex Schultz wrote on 12/13/2017 04:29:49 PM: > On Wed, Dec 13, 2017 at 3:22 PM, Mark Hamzy wrote: > > What I have done at a high level is to rename the images into architecture > > specific > > images. For example, > > > > (undercloud) [stack@oscloud5

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

Obviously, I'm interested and I voted. Thanks, Gilles On 13/12/17 02:22, Ed Leafe wrote: Re-sending this in the hope of getting more responses. If you’re in the APAC region and interested in contributing to our discussions, please indicate your preferences on the link below. That brought

Re: [openstack-dev] [First Contact] [OUI] Call for Project Liaisons

Kendall, I ran this by Sean and since I am covering the other On-Boarding work for Cinder and am integrated with OUI and SIG it makes the most sense for me to cover this as well. Thanks for updating the list. Jay On 12/13/2017 2:15 PM, Kendall Nelson wrote: I didn't want to assume you

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Chris Jones's message of 2017-12-13 19:25:03 +: > Hey > > On 13 December 2017 at 17:31, Thierry Carrez wrote: > > > See attached for the PDF strawman the release team came up with when > > considering how that change would roll out in practice... > > >

Re: [openstack-dev] [all] Switching to longer development cycles

It looks like the implicit expectation is that devs also need to attend the Forums at the summit in addition to the PTG. The Forums, though important, hardly made it worthwhile for me to attend the summit (and in fact I skipped Sydney). On the other hand some devs got together and hashed out

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Ed Leafe's message of 2017-12-13 16:07:50 -0600: > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > > > There is a risk that deployment to production is delayed, and therefore > > feedback is delayed and the wait for the ‘initial bug fixes before we > > deploy to

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

On Wed, Dec 13, 2017 at 3:22 PM, Mark Hamzy wrote: >> I just need an understanding on the impact and the timeline. Replying >> here is sufficient. >> >> I assume since some of this work was sort of done earlier outside of >> tripleo and does not affect the default installation

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

> I just need an understanding on the impact and the timeline. Replying > here is sufficient. > > I assume since some of this work was sort of done earlier outside of > tripleo and does not affect the default installation path that most > folks will consume, it shouldn't be impacting to general

Re: [openstack-dev] [all] Switching to longer development cycles

Ed Leafe wrote: > On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > >> There is a risk that deployment to production is delayed, and therefore >> feedback is delayed and the wait for the ‘initial bug fixes before we deploy >> to prod’ gets longer. > > There is always a rush at

Re: [openstack-dev] [all] Switching to longer development cycles

Doug Hellmann wrote: > That said, I'm more interested in settling the question of whether > changing the development cycle helps development teams in any way > before we consider other effects. Because if it doesn't do any good > then there's no reason to solve problems we won't have, and if we >

Re: [openstack-dev] [all] Switching to longer development cycles

On Dec 13, 2017, at 12:13 PM, Tim Bell wrote: > There is a risk that deployment to production is delayed, and therefore > feedback is delayed and the wait for the ‘initial bug fixes before we deploy > to prod’ gets longer. There is always a rush at the Feature Freeze point

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

On Wed, Dec 13, 2017 at 11:16 AM, Sven Anderson wrote: > > On Sat, Dec 9, 2017 at 12:35 AM Alex Schultz wrote: >> >> Please take some time to review the list of blueprints currently >> associated with Rocky[0] to see if your efforts have been moved. If >>

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

On Tue, Dec 12, 2017 at 5:50 PM, Tony Breeds wrote: > On Fri, Dec 08, 2017 at 04:34:09PM -0700, Alex Schultz wrote: >> Hey folks, >> >> So I went through the list of blueprints and moved some that were >> either not updated or appeared to have a bunch of patches not in a

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Thierry Carrez's message of 2017-12-13 22:26:49 +0100: > Doug Hellmann wrote: > > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: > >> Do we continue to support the previous two releases as stable branches? > >> Doesn't that mean we double the amount of time we

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 03:16:33PM -0500, Doug Hellmann wrote: > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: > > Do we continue to support the previous two releases as stable branches? > > Doesn't that mean we double the amount of time we need to keep older CI > > setups

Re: [openstack-dev] [all] Switching to longer development cycles

Doug Hellmann wrote: > Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: >> Do we continue to support the previous two releases as stable branches? >> Doesn't that mean we double the amount of time we need to keep older CI >> setups around? Isn't that already a pain point for the

Re: [openstack-dev] [all] Switching to longer development cycles

Excerpts from Michael Still's message of 2017-12-13 10:59:37 -0800: > Do we continue to support the previous two releases as stable branches? > Doesn't that mean we double the amount of time we need to keep older CI > setups around? Isn't that already a pain point for the stable teams? > >

Re: [openstack-dev] [First Contact] [OUI] Call for Project Liaisons

I didn't want to assume you would for Cinder or if you wanted to only be a member of the SIG and maybe someone else would step up as the Cinder project liaison. I can add you as the Cinder Project Liaison now though. Thanks Jay! -Kendall (diablo_rojo) On Wed, Dec 13, 2017 at 12:09 PM Jay S

Re: [openstack-dev] [First Contact] [OUI] Call for Project Liaisons

Kendall, I thought it was implied in my earlier replies but to be clear, I will represent Cinder. Jay (jungleboyj) On 12/13/2017 12:17 PM, Kendall Nelson wrote: We only have three projects covered at this point (QA, Monasca, and Swift), would be nice to see some more volunteers from other

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 12:26 PM, Sean McGinnis wrote: On Wed, Dec 13, 2017 at 06:13:41PM +, Tim Bell wrote: The forums would seem to provide a good opportunity for get togethers during the release cycle. With these happening April/May and October/November, there could be a good chance for

Re: [openstack-dev] [all] Switching to longer development cycles

This is a much needed change. It will ease the effort required by operators to maintain a current openstack environment. +1 from me Chris Krelle On Dec 13, 2017 8:17 AM, "Thierry Carrez" wrote: Hi everyone, Over the past year, it has become pretty obvious to me that

Re: [openstack-dev] [all] Switching to longer development cycles

I have two concerns. 1.) I'm hesitant to lose developer <---> operator communication more than we already have. Outcomes and conversations from the PTGs are super useful, but we don't exactly have rooms full of operators to bounce ideas off of. We can summarize outcomes and socialize reports on

Re: [openstack-dev] [all] Switching to longer development cycles

Hey On 13 December 2017 at 17:31, Thierry Carrez wrote: > See attached for the PDF strawman the release team came up with when > considering how that change would roll out in practice... > [in which the final stage of the release is 8 weeks, therefore shorter than the

Re: [openstack-dev] [Women-of-openstack] Introduction

Ok! On Dec 13, 2017 8:01 PM, "Amy Marrich" wrote: > And if we don't answer right away we will when we can! > > Amy (spotz) > > On Wed, Dec 13, 2017 at 11:37 AM, Kendall Nelson > wrote: > >> Hello Again :) >> >> I know I had responded the other day, but

Re: [openstack-dev] [Women-of-openstack] Introduction

And if we don't answer right away we will when we can! Amy (spotz) On Wed, Dec 13, 2017 at 11:37 AM, Kendall Nelson wrote: > Hello Again :) > > I know I had responded the other day, but I just wanted to check in and > make sure the setup was going well. We would love to

Re: [openstack-dev] [all] Switching to longer development cycles

Do we continue to support the previous two releases as stable branches? Doesn't that mean we double the amount of time we need to keep older CI setups around? Isn't that already a pain point for the stable teams? Michael On Wed, Dec 13, 2017 at 8:17 AM, Thierry Carrez

Re: [openstack-dev] [Women-of-openstack] Introduction

Will do, thanks! On Dec 13, 2017 6:37 PM, "Kendall Nelson" wrote: > Hello Again :) > > I know I had responded the other day, but I just wanted to check in and > make sure the setup was going well. We would love to chat with you on IRC > in #openstack-dev or in

Re: [openstack-dev] [all] Switching to longer development cycles

Dirk Müller wrote: > 2017-12-13 17:17 GMT+01:00 Thierry Carrez : > > > - We'd only do one *coordinated* release of the OpenStack components per > > year, and maintain one stable branch per year > > - We'd elect PTLs for one year instead of every 6 months > > - We'd only

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 06:13:41PM +, Tim Bell wrote: > The forums would seem to provide a good opportunity for get togethers during > the release cycle. With these happening April/May and October/November, there > could be a good chance for productive team discussions and the opportunities

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 10:13 AM, Tim Bell wrote: [...] > There is a risk that deployment to production is delayed, and therefore > feedback is delayed and the wait for the ‘initial bug fixes before we deploy > to prod’ gets longer. This is exactly what worries me with this

Re: [openstack-dev] [First Contact] [OUI] Call for Project Liaisons

We only have three projects covered at this point (QA, Monasca, and Swift), would be nice to see some more volunteers from other projects. Thanks Matt, Cristiano and Ghanshyam! -Kendall (diablo_rojo) On Mon, Dec 11, 2017 at 1:24 PM Kendall Nelson wrote: > Hello, > > As

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

On Sat, Dec 9, 2017 at 12:35 AM Alex Schultz wrote: > Please take some time to review the list of blueprints currently > associated with Rocky[0] to see if your efforts have been moved. If > you believe you're close to implementing the feature in the next week > or two, let

Re: [openstack-dev] [all] Switching to longer development cycles

The forums would seem to provide a good opportunity for get togethers during the release cycle. With these happening April/May and October/November, there could be a good chance for productive team discussions and the opportunities to interact with the user/operator community. There is a risk

Re: [openstack-dev] [all] Switching to longer development cycles

2017-12-13 17:17 GMT+01:00 Thierry Carrez : > - We'd only do one *coordinated* release of the OpenStack components per > year, and maintain one stable branch per year > - We'd elect PTLs for one year instead of every 6 months > - We'd only have one set of community goals

Re: [openstack-dev] [all] Switching to longer development cycles

I think Sean has made some really good points with the PTG setting things off in the start of the year and conversations carrying over to the Forums and their importance. And having a gap at the end of the year as Jay mentioned will give time for those still about to do finishing work if needed

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 8:52 AM, Matt Riedemann wrote: [...] > I personally don't expect anyone to pick up these intermediate releases. I > expect most consumers are going to pick up a coordinated release (several > months or years after it's released), especially if that's

Re: [openstack-dev] [all] Switching to longer development cycles

I share the same concerns that Matt and Dmitry have already spoken. One year release process seems like a good plan, but I do feel that cuting the PTG can directly affect the progress of the cycle. It would take a great effort from PTLs and Core team to keep developement going smoothly througout

Re: [openstack-dev] [Women-of-openstack] Introduction

Hello Again :) I know I had responded the other day, but I just wanted to check in and make sure the setup was going well. We would love to chat with you on IRC in #openstack-dev or in #openstack-women. Feel free to ping me once you get connected and we can chat more about getting you connected

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 11:29 AM, Sean McGinnis wrote: On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote: Hey On 13 December 2017 at 17:12, Jimmy McArthur wrote: Thierry Carrez wrote: - It doesn't mean that teams can only meet in-person once a year. Summits would

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 06:29 PM, Sean McGinnis wrote: On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote: Hey On 13 December 2017 at 17:12, Jimmy McArthur wrote: Thierry Carrez wrote: - It doesn't mean that teams can only meet in-person once a year. Summits would

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 11:16 AM, Jean-Philippe Evrard wrote: On the other hand, without community-wide imposed deadlines and milestones, we lose some motivation for getting things done by a specific time, which could mean the bigger and more complicated things drag on longer because there isn't a

Re: [openstack-dev] [all] Switching to longer development cycles

Thierry, Thank you for this well thought out note.  I had kind-of felt like the idea was crazy but as I read through this note I can see there could be benefits for the community. The Cinder team would need to decide if we still wanted to do a mid-cycle in August/September.  We used to

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 05:13:00PM +, arkady.kanev...@dell.com wrote: > A lot of great points. > If we are switching to 1 year cycle do we also move summits/forum to once a > year... > That impacts much more than developers. > The current plan is the Summit/Forum schedule would not change.

Re: [openstack-dev] [all] Switching to longer development cycles

Jay S Bryant wrote: > If we are reworking the schedule it is a good idea to leave more > stabilization time at the end and try to wrap things up before the end > of the year when people disappear. > > As far as releases go ... other teams have been doing frequent > intermediate releases and have

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote: > Hey > > On 13 December 2017 at 17:12, Jimmy McArthur wrote: > > > Thierry Carrez wrote: > > > >> - It doesn't mean that teams can only meet in-person once a year. > >> Summits would still provide a venue for

Re: [openstack-dev] [all] Switching to longer development cycles

Sean, If we are reworking the schedule it is a good idea to leave more stabilization time at the end and try to wrap things up before the end of the year when people disappear. As far as releases go ... other teams have been doing frequent intermediate releases and have benefited from it. 

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 04:49:24PM +, Jeremy Stanley wrote: > On 2017-12-13 16:45:14 + (+), Chris Jones wrote: > [...] > > For me the first thing that comes to mind with this proposal, is > > how would the milestones/FF/etc be arranged within that year? > [...] > > Excellent point. If

Re: [openstack-dev] [all] Switching to longer development cycles

Hey On 13 December 2017 at 17:12, Jimmy McArthur wrote: > Thierry Carrez wrote: > >> - It doesn't mean that teams can only meet in-person once a year. >> Summits would still provide a venue for team members to have an >> in-person meeting. I also expect a revival of the

Re: [openstack-dev] [all] Switching to longer development cycles

On 13 December 2017 at 16:52, Matt Riedemann wrote: > On 12/13/2017 10:17 AM, Thierry Carrez wrote: >> >> Hi everyone, >> >> Over the past year, it has become pretty obvious to me that our >> self-imposed rhythm no longer matches our natural pace. It feels like we >> are

Re: [openstack-dev] [all] Switching to longer development cycles

I think we should not mix summits/forum discussion with this and would require a lot more open discussion as has been happening with this proposal prior to it being formally introduced here. On Wed, Dec 13, 2017 at 11:13 AM, wrote: > A lot of great points. > If we are

Re: [openstack-dev] [all] Switching to longer development cycles

A lot of great points. If we are switching to 1 year cycle do we also move summits/forum to once a year... That impacts much more than developers. -Original Message- From: Matt Riedemann [mailto:mriede...@gmail.com] Sent: Wednesday, December 13, 2017 10:52 AM To:

Re: [openstack-dev] [all] Switching to longer development cycles

Thierry Carrez wrote: - It doesn't mean that teams can only meet in-person once a year. Summits would still provide a venue for team members to have an in-person meeting. I also expect a revival of the team-organized midcycles to replace the second PTG for teams that need or want to meet more

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 9:59 AM, Thierry Carrez wrote: > Chris Jones wrote: > > [...] > > For me the first thing that comes to mind with this proposal, is how > > would the milestones/FF/etc be arranged within that year? As I've raised > > previously on this list [0], I

Re: [openstack-dev] [all] Switching to longer development cycles

There are definitely pros and cons to this approach but I think considerable amount of time and concern went into this prior to being posted on the ML and agree with JP there will be folks who agree and/or disagree with some or all of this so TC vote is best. I think getting away from the

Re: [openstack-dev] [all] Switching to longer development cycles

Matt Riedemann wrote: > On 12/13/2017 10:17 AM, Thierry Carrez wrote: >> [...] >> Why one year ? >> >> Why not switch to 9 months ? Beyond making the math a lot easier, this >> has mostly to do with events organization. The Summits are already >> locked for 2018/2019 with a pattern of happening in

Re: [openstack-dev] [all] Switching to longer development cycles

On 13 December 2017 at 16:49, Jeremy Stanley wrote: > On 2017-12-13 16:45:14 + (+), Chris Jones wrote: > [...] >> For me the first thing that comes to mind with this proposal, is >> how would the milestones/FF/etc be arranged within that year? > [...] > > Excellent

Re: [openstack-dev] [all] Switching to longer development cycles

Chris Jones wrote: > [...] > For me the first thing that comes to mind with this proposal, is how > would the milestones/FF/etc be arranged within that year? As I've raised > previously on this list [0], I would prefer more time for testing and > stabilisation between Feature Freeze and Release. I

[openstack-dev] [docs] Documentation meeting minutes for 2017-12-13

=== #openstack-doc: docteam === Meeting started by pkovar at 16:01:40 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-12-13-16.01.log.html . Meeting summary --- * roll call (pkovar,

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

On Thu, Dec 7, 2017 at 2:55 AM, Sławomir Kapłoński wrote: > Hi, > > Thanks all of You for support. I'm very happy to be part of the team. Congratulations Slawek, and job well done! > > — > Best regards > Slawek Kaplonski > sla...@kaplonski.pl > > >> Wiadomość napisana przez

Re: [openstack-dev] [all] Switching to longer development cycles

On 12/13/2017 10:17 AM, Thierry Carrez wrote: Hi everyone, Over the past year, it has become pretty obvious to me that our self-imposed rhythm no longer matches our natural pace. It feels like we are always running elections, feature freeze is always just around the corner, we lose too much

Re: [openstack-dev] [all] Switching to longer development cycles

On 2017-12-13 16:45:14 + (+), Chris Jones wrote: [...] > For me the first thing that comes to mind with this proposal, is > how would the milestones/FF/etc be arranged within that year? [...] Excellent point. If it's not too much work for the Release team, it would be very helpful to have

Re: [openstack-dev] [all] Switching to longer development cycles

Hey On 13 December 2017 at 16:17, Thierry Carrez wrote: > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just around the > corner, we lose too much time to events, and generally the

Re: [openstack-dev] [all] Switching to longer development cycles

Thierry, Thanks for starting this discussion. I support move to 1 year cycle. With OpenStack maturity and adoption it is a natural transformation. However, we also need to consider previous releases, support for them and "." release for them. Also for projects that are "in early stages" they

[openstack-dev] [all] Switching to longer development cycles

Hi everyone, Over the past year, it has become pretty obvious to me that our self-imposed rhythm no longer matches our natural pace. It feels like we are always running elections, feature freeze is always just around the corner, we lose too much time to events, and generally the impression that

Re: [openstack-dev] [masakari] problems starting up masakari instance monitoring in devstack @ master

ok ... i changed all the domain related attributes in /etc/masakarimonitors/masakarimonitors.conf to be set to ‘default’ . I seemed to get further, but now get the following error when instancemonitor tries to send a notification: Bad Request (HTTP 400) (Request-ID:

[openstack-dev] [manila] [NEEDACTION] CI changes due to manila tempest tests new repository

Hi all, As part of the effort of splitting tempest plugins to their own repositories [0], we are calling all Manila 3rd party CI maintainers to adjust their gate scripts to use the new tempest test repository If the third party CIs are configured to run with DevStack Gate, they only need to make

Re: [openstack-dev] [ceilometer] about add transformer into libvirt

On 2017-12-13 01:52 AM, Jaze Lee wrote: > Hello, > > What about move transformer to compute pollster? If we do this, we > do not need > transformer any more sorry, i don't understand. if you move the transformer, you still have a transformer. -- gord

[openstack-dev] [docs] Documentation meeting today

Hi all, The docs meeting will continue today at 16:00 UTC in #openstack-doc, as scheduled. For more details, and the agenda, see the meeting page: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting Cheers, pk __

[openstack-dev] [acceleration] Cyborg Team Weekly Meeting 2017.12.13

Hi guys, We will have our weekly team meeting today on #openstack-cyborg starting from UTC1500 . I've been under the weather for the whole week so plz zhuli, Justin and Rushil help lead the meeting. The agenda is to sync up everyone's progress, zhuli will also provide a summary of yesterday's

[openstack-dev] [neutron] Generalized issues in the unit testing of ML2 mechanism drivers

Through my work in networking-odl I've found what I believe is an issue present in a majority of ML2 drivers. An issue I think needs awareness so each project can decide a course of action. The issue stems from the adopted practice of importing `neutron.tests.unit.plugins.ml2.test_plugin` and

Re: [openstack-dev] [ovs-discuss] [Neutron][networking-ovn] OVN + Openstack Issues

Hi, > Hi Martin, > > I met exactly the same issue with yours, could you please show some details > about security groups deleting, resyncing and recreating? cause I cleared > DEFAULT security group and add 'ovn-sync-mode=repair' in config file then > restarted the neutron-server, but didn't work

[openstack-dev] [Heat] [Octavia] Re: [Bug 1737567] Re: Direct support for Octavia LBaaS API

Hi Rabi, see below On 12/13/17 11:03 AM, Rabi Mishra wrote: if Heat will provide a way to choose provider (neutron-lbaas or octavia), then customers will continue to use neutron-lbaas as long as it will be required, with their specific drivers (haproxy, F5, A10, etc), gradually migrating to

[openstack-dev] [networking-ovn] [tripleo] enable open ptcp communication to NB and SB databases

Hi folks, The following commit[0] added support for SSL connections to NB and SB databases. Now for enabling open ptcp communication to NB and SB dbs, we need to do this: # ovn-sbctl set-connection ptcp:6642 # ovn-nbctl set-connection ptcp:6641 For an OpenStack cloud deployment(TripleO), if open

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

On Wed, 2017-12-13 at 12:18 +0200, Eyal Leshem wrote: > 3.0.0 is align with the kubernetes-1.7 api spec. > In 1.8 there is some fields that had been added to the k8s-network- > policy. > so for me 4.0.0 will be much better. Okay, then I don't see a point to block that, we can work around the

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

3.0.0 is align with the kubernetes-1.7 api spec. In 1.8 there is some fields that had been added to the k8s-network-policy. so for me 4.0.0 will be much better. thanks, leyal On 13 December 2017 at 11:49, wrote: > On Wed, 2017-12-13 at 09:51 +0200, Eyal Leshem wrote: > > Hi

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

cool, thanks! Cheers, Lingxian Kong (Larry) On Wed, Dec 13, 2017 at 10:41 PM, Eyal Leshem wrote: > Hi Lingxian, > > It's should - under the assumption of uses only the v1 models ( and not > v1_alpha or v1_beta). > see : https://kubernetes.io/docs/reference/api-overview/

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

On Wed, 2017-12-13 at 09:51 +0200, Eyal Leshem wrote: > Hi all , > > In order to use kubernetes client that support network-policies , > we plan to upgrade the python kubernetes package from 1.0.0 to > 4.0.0. > > any objections ? There's a couple of issues ([1], [2]) introduced in 4.0.0

Re: [openstack-dev] [all] propose to upgrade python kubernetes (the k8s python client) to 4.0.0

Hi Lingxian, It's should - under the assumption of uses only the v1 models ( and not v1_alpha or v1_beta). see : https://kubernetes.io/docs/reference/api-overview/ thanks , leyal On 13 December 2017 at 11:16, Lingxian Kong wrote: > hi, leyal, > > I suppose the upgrade

  1   2   >