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

On Thu, Dec 14, 2017 at 12:38 PM, Mark Hamzy wrote: > Alex Schultz wrote on 12/14/2017 09:24:54 AM: >> On Wed, Dec 13, 2017 at 6:36 PM, Mark Hamzy wrote: >> ... As I said previously, please post the >> patches ASAP so we can get eyes on

[openstack-dev] [First Contact] [SIG] Presence at the PTG

Hello, It came up in a discussion today that it might be good to get together and discuss all the activities around on boarding and various other initial interactions to get us all on the same page and a little more organized/established. Given that SIGs have space the beginning of the week

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

I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases unless they are coordinated and tested much

Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

Sounds like a good plan. Hopefully we can do some OUI work face to face as well? Jay On Thu, Dec 14, 2017, 2:55 PM Kendall Nelson wrote: > Hello, > > It came up in a discussion today that it might be good to get together and > discuss all the activities around on

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

On 2017-12-14 12:15:08 +0100 (+0100), Dmitry Tantsur wrote: [...] > loop operators into PTGs more. If by "operators" you mean people who run OpenStack, then yes while many of our developers are also operators it definitely makes sense to have increasing amounts of overlap with operators

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

On 12/14/2017 12:36 AM, Clint Byrum wrote: This isn't really fair to the users. They're running what we tell them to run. They're also running what we try to test together, which is all the same versions of the same components at integrated release time. While I do think most users_should_

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

Excerpts from Ed Leafe's message of 2017-12-13 22:55:43 -0600: > 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

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

Hello Thierry, Really appreciate the effort you are putting to find creative ways to help new contributors join our project. However, based on my experience, it seems that: - the longer the delay between the releases, the harder they are to deliver - the main problem newcomers may have today, is

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

On Dec 14, 2017, at 12:55 AM, Clint Byrum wrote: >> The rest of OpenStack is what Nova originally was. It was split into many >> different project because of the sheer complexity of the tasks it had to >> perform. But splitting it up required that we occasionally have to make

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

On Thu, Dec 14 2017, Thierry Carrez wrote: > It takes time to get a feature merged (or any significant work done) in > OpenStack. It takes time to get reviews, we need to be careful about not > breaking all our users, etc. If you are a 20% time person, it's just > impossible to get something

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

Hi MinWookKim, I think that the right click is a good idea. Some questions: · Just to make sure I understood correctly – after the “performance and load test”, do you expect to see the result on the selected resource, or somewhere else? · What do you mean by “set monitoring

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

Chris Dent wrote: > On Thu, 14 Dec 2017, Julien Danjou wrote: > >> However, has anyone tried to understand the reasons why it is hard to >> impossible to do anything useful in a cycle, other than "it is too >> short"? > > This gets to the root my concern with this proposal and this thread. > I

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

On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote: > > As a package maintainer who no longer can follow the high pace, I very > much support this change. So you’re saying that you would be ignoring any intermediate releases? -- Ed Leafe

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

On 2017-12-14 04:14 AM, Jaze Lee wrote: >> The plan is to actually make the TSDB (Gnocchi) do that job for us. > What ？ > Is there some detail on this plan ? If it did, then we do not need > workload partition, and scale with agent process happily > Gnocchi can capture rate information

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

On Thu, 14 Dec 2017, Julien Danjou wrote: However, has anyone tried to understand the reasons why it is hard to impossible to do anything useful in a cycle, other than "it is too short"? This gets to the root my concern with this proposal and this thread. I think the idea deserves plenty of

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

On 12/14/2017 7:07 AM, Thierry Carrez wrote: It takes time to get a feature merged (or any significant work done) in OpenStack. It takes time to get reviews, we need to be careful about not breaking all our users, etc. If you are a 20% time person, it's just impossible to get something

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

> In my experience, the longer a patch (or worse, patch series) sits > around, the staler it gets. Others are merging changes, so the > long-lived patch series has to be constantly rebased. This is definitely true. > The 20% developer would be spending a greater proportion of her time > figuring

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

TL;DR: +1 for 1-year release, without reducing face-to-face meetings. On Wed, Dec 13, 2017 at 6:35 PM Matt Riedemann wrote: > > Same question as above about just doing CD then. Why not getting rid of stable branches and releases altogether then? Honestly, I'm a big fan

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

Hi Minwook, Do you mean that you would like to: · Right click an entity · Ask to run performance tests · Wait for the results to show? I assume that the performance test would take some time. Or do you expect to trigger the test execution and see the results later on,

[openstack-dev] [nova][stable] What nova needs to get to newton end of life

I'm not sure how many other projects still have an active stable/newton branch, but I know nova is one of them. At this point, these are I think the things that need to get done to end of life the newton branch for nova: 1. We have a set of existing stable/newton backports that need to get

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

I feel like the thing not stated is that what we really don't like is that our users are falling behind. Sure, pressure in release time is definitely real. Multiple PTG's and forums feels like people are missing out. But what's really awful is that some of our users are stuck down in the bottom of

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

Hello Ifat. Thanks for your comments. The Performance Test action is completely independent of the Vitrage flow and is simply an action that triggers an external Performance Test project. Users can simply see the results on the Vitrage-Dashboard. We can also exclude Performance

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

On 2017-12-14 08:15:51 -0700 (-0700), Clint Byrum wrote: [...] > What if we did a community goal to get upgrade testing solidified, > and have it test upgrading each project from _three_ stable releases > prior. So, if we did this for Rocky, we'd make sure you could upgrade > to Rocky from Queens,

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

Hello Ifat. In conclusion, we do not have to wait for test results. We can take other actions while performing a test action. As with all performance tests, we are mindful that it will take an unspecified amount of time (because we can set the test time we want). So, we can check

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

> On Dec 13, 2017, at 6:44 PM, Clint Byrum wrote: > > 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

[openstack-dev] [oslo][requirements][vitrage] oslo.service 1.28.1 breaks Vitrage gate

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]

Re: [openstack-dev] [murano] Deployment fails with Murano Agent

Hi Rong, I checked the rabbit config and it was correct. The issue turned out to be something completely unrelated to Murano. Thanks for your help. Jerry -Original Message- From: Rong Zhu [mailto:aaronzhu1...@gmail.com] Sent: December-12-17 8:22 PM To: OpenStack Development Mailing

[openstack-dev] [all][api] POST /api-sig/news

Greetings OpenStack community, Today's meeting was relatively short and covered a few topics surrounding OpenStack SDKs and expanding the meeting times. On the topic of OpenStack SDKs, there is a proposal [7] being crafted for an SDK certification program. Our discussions mainly centered

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

On 12/14/2017 9:11 AM, Thierry Carrez wrote: We lose development time to activities directly linked to our cycle: like election, release, PTG preparation, participation to Forum(s). PTLs have reported not being able to achieve much before reaching the end of a cycle and having to stand for

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

- Original Message - > 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

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

Ed Leafe writes: > I think you're missing the reality that intermediate releases have > about zero uptake in the real world. We have had milestone releases of > Nova for years, but I challenge you to find me one non-trivial > deployment that uses one of them. To my knowledge,

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

On Wed, Dec 13, 2017 at 6:36 PM, Mark Hamzy wrote: > 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

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

On Dec 14, 2017, at 7:07 AM, Thierry Carrez wrote: > > It takes time to get a feature merged (or any significant work done) in > OpenStack. It takes time to get reviews, we need to be careful about not > breaking all our users, etc. If you are a 20% time person, it's just

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

On 14 December 2017 at 07:09, Nick Barcet wrote: > Hello Thierry, > > Really appreciate the effort you are putting to find creative ways to help > new contributors join our project. However, based on my experience, it > seems that: > - the longer the delay between the

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

Alex Schultz wrote on 12/14/2017 09:24:54 AM: > On Wed, Dec 13, 2017 at 6:36 PM, Mark Hamzy wrote: > ... As I said previously, please post the > patches ASAP so we can get eyes on these changes. Since this does > have an impact on the existing

[openstack-dev] [release][PTL] Cycle highlights reminder

Hey all, As we get closer to Queens-3 and our final RCs, I wanted to remind everyone about the new 'cycle-highlights' we have added to our deliverable info. Background -- As a reminder on the background, we were finding that a lot of PTLs were getting pings several times at the end of

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

On 12/14/2017 03:16 PM, Ed Leafe wrote: > On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote: >> >> As a package maintainer who no longer can follow the high pace, I very >> much support this change. > > So you’re saying that you would be ignoring any intermediate releases? > >

[openstack-dev] [release] Release countdown for week R-10, December 16-22

Welcome to the weekly countdown email. Please let me know if there are any questions or concerns. Development Focus - Teams should be focused on implementing planned work for the cycle. It is also a good time to review those plans and reprioritize anything if needed based on the

[openstack-dev] [all] [security] Security SIG

Hi All, Following on from the mailing list discussion [0], we now plan to change the Security Project into a Special Interest Group (The Security SIG). SIGs are a good match for an activity that centers around a topic or practice that spans all the community (developers, operators, end

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

On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann wrote: > What would our world look like if we treated inter-service dependencies like > we do service-to-library dependencies and only integration test released > components, rather than installing everything from source by

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

On 12/14/2017 9:38 AM, Luigi Toscano wrote: And the QE in me says that there are enough moving parts around for the integration testing (because CD yes, but the resources are limited) that a longer cycle with a longer time between freeze and release is better to refine the testing part. The

[openstack-dev] [Octavia] Community meeting regarding providers support

Hello, We are going to have an Octavia community meeting to discuss providers[1] support in Queens, on Tuesday 12/19/2017 at 16:00 to 17:00 UTC time. The meeting will take place in Bluejeans[2]. Hope to see you there. [1] https://review.openstack.org/#/c/509957/ [2]

Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

Yeah that should be doable :) As we get a little closer, I can draft an agenda and add OUI to it. -Kendall On Thu, Dec 14, 2017 at 1:37 PM Jay Bryant wrote: > Sounds like a good plan. Hopefully we can do some OUI work face to face > as well? > > Jay > > On Thu,

Re: [openstack-dev] [tripleo] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core

Gaël has been added to the validations core team. Welcome! On Fri, Dec 8, 2017 at 6:56 PM, Alex Schultz wrote: > +1 > > On Thu, Dec 7, 2017 at 7:34 AM, Ana Krivokapic > wrote: > > Hey TripleO devs, > > > > Gaël has consistently been contributing high

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

I noticed some OpenStack distro vendors in China(not all the vendors) like the idea to have one release per year. There are couple of different reason: 1. It takes about 3 to 6 months to productize the release. But customers always expect the vendors to productize every single release, which cost

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

On Wed, Dec 13, 2017 at 03:01:41PM -0700, Alex Schultz wrote: > 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 testing or > increase regressions.

Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

Sounds great.. Still haven't got a green light from my employer whether they'd send me or not yet tho. But if I can get to the PTG I'll be there :) Matt On Fri, Dec 15, 2017 at 8:41 AM, Kendall Nelson wrote: > Yeah that should be doable :) > > As we get a little closer,

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

On 12/14/2017 11:12 AM, Dean Troyer wrote: On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann wrote: What would our world look like if we treated inter-service dependencies like we do service-to-library dependencies and only integration test released components, rather than

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

On 12/14/2017 3:27 PM, Adrian Turjak wrote: I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases

[openstack-dev] [tripleo] Removing old baremetal commands from python-tripleoclient

Hi All, In review I01837a9daf6f119292b5a2ffc361506925423f11 I updated ValidateInstackEnv to handle the case when then instackenv.json file needs to represent a node that deosn't require a pm_user for IMPI to work. It turns out that I foudn that code path with grep rather than the result of a

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

On Thu, Dec 14, 2017 at 7:02 PM, Kashyap Chamarthy wrote: > [..] > > For a relatively mature (~7 years; and ~5 years if we count from the > time governance changed to OpenStack Foudation) project, one official > contributor gathering per year sounds fine. And for those that

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

The contributors in APAC are growing and wish to be more involved in OpenStack, it will be really hard for us to join informal meetups( VISA Invitation letters, company support etc.) So I really hope the current official technical gathering remains, so that we can be more involved with the

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

2017-12-14 22:34 GMT+08:00 gordon chung : > > > On 2017-12-14 04:14 AM, Jaze Lee wrote: >>> The plan is to actually make the TSDB (Gnocchi) do that job for us. >> What ？ >> Is there some detail on this plan ? If it did, then we do not need >> workload partition, and scale with agent

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

Julien Danjou wrote: > On Thu, Dec 14 2017, Thierry Carrez wrote: > >> - People who would like to get more involved (and become core >> developers) but can't keep up with what's happening in their project or >> reach the review activity necessary to become core developers. A number >> of projects

Re: [openstack-dev] [First Contact] [SIG] Presence at the PTG

+1, nice idea. I will make it. btw, what will be the meeting duration you are planning like an hour or 2 ? -gmann On Fri, Dec 15, 2017 at 5:55 AM, Kendall Nelson wrote: > Hello, > > It came up in a discussion today that it might be good to get together and > discuss

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

On 12/13/2017 05:17 PM, Thierry Carrez wrote: > So... What do you think ? As a package maintainer who no longer can follow the high pace, I very much support this change. Cheers, Thomas Goirand (zigo) __ OpenStack

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

Thanks Numan for the reply. >tripleo takes care of that and there should be no need to run those >commands manually. Which release of tripleo you are using ? We are using Pike. My bad, I was looking for the aforementioned commands and didn't check the code properly for the alternate way to use

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

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 to them and generally reduce stress in OpenStack >>

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

Thanks a lot to open this topic. I want to open this topic like this some times, but i thought, may be myself is too sensitive? To me, i found as Openstack mature, the developer is less valuable. The devs can install it then teach user to use it, then ok the deal is done. The Openstack in many

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

2017-12-14 16:58 GMT+08:00 Julien Danjou : > On Thu, Dec 14 2017, Jaze Lee wrote: > >> Oh, sorry. I found libvirt can not get cpu.util, cpu.delta, and >> network/disk rate info directly >> from inspector. So i mean, we can move this into compute pollster. >> Before it sends to

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

David Moreau Simard wrote: > This can go down a few different ways, I guess we can: > 1) Extend the support of a stable release by a full year >     This keeps the two rolling stable releases plus the one in development. >     Not quite LTS, but you know, it's still 2 years of support instead of

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

On Thu, Dec 14 2017, Jaze Lee wrote: > Oh, sorry. I found libvirt can not get cpu.util, cpu.delta, and > network/disk rate info directly > from inspector. So i mean, we can move this into compute pollster. > Before it sends to notifications.sample, > transform it. Then we can scale notification

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

On 14 Dec 2017, 17:04 +0700, wrote: > > Can you detail more how having a longer cycle will make people that > spends 20% of their time on OpenStack "catch up" with the people that > spends 80% of their time on OpenStack? > > I understand the problem but I don't see how the proposed solution >

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

On Thu, Dec 14, 2017 at 6:38 AM, 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 Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: > Hi everyone, Hey Thierry, > 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

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

On 12/13/2017 11:20 PM, Thierry Carrez wrote: 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

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

On Thu, Dec 14, 2017 at 10:09 AM, Thierry Carrez wrote: > 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

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

On Thu, Dec 14 2017, Thierry Carrez wrote: > - People who would like to get more involved (and become core > developers) but can't keep up with what's happening in their project or > reach the review activity necessary to become core developers. A number > of projects are struggling to recruit

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

I think this is in-line with my earlier points. Projects started later, with clear API definitions, are easier to run on whatever version you need. They don't dig in under the hood the way Neutron/Nova/Cinder do because of their shared history. It also helps that they don't require a bunch of

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

On 12/14/2017 05:55 AM, Ed Leafe wrote: 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