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 d
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 process happil
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 installing everything f
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 un
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 communit
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 need
> more face time
+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 all the activities around
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. My
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, I can draft an agenda a
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, Dec 14, 2017, 2:55 PM Kendall N
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 boarding and various other ini
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 like
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 (Mon/
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 these changes. Since this does
>> have an impact on the ex
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?
>
> -- Ed Leafe
I use
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 ev
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 functionality this should have been
> merged earlier
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 releases, the harder they ar
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
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 cy
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] https://bluejeans.com/993515
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
users...),
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 default?
I've been strugg
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 arou
> 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 like we
>> are alw
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,
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 th
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,
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 Lis
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/
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 Test
- 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 always a rush at the
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 reelec
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
>> > specific
>> > images. For example,
>> >
>> > (underc
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, based on user
> surv
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
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
m
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 of CD, but CD and OpenS
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 th
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
> 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
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_ stic
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 significan
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 co
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 Forums, though important,
> > hardly m
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 and
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
> impossible to get some
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 c
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
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 participat
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 signi
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 sure
>> that we'r
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
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 a
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 down our
> >> pace could b
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 patc
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 it worthwhile for me to attend the
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 longer.
There is a
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 ar
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 quality reviews and patches
> to
> > the tri
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
> solv
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 summit (and in fact I skipped
> Sydn
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 new
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 notifications.sample
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
>> develo
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 Developme
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 ope
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 a
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 on
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 com
70 matches
Mail list logo