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

[Tony Breeds]

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 deploy step failing.  That's becuase it's only used for a
command that isn't used anymore, and the validation logic has been moved
to a mistral action.

That lead me to look at which of the commands in that file aren't needed
anymore.  If my analysis is correct we have the collowing commands:

openstack baremetal instackenv validate:
tripleoclient.v1.baremetal:ValidateInstackEnv
NOT Deprecated
openstack baremetal import:
tripleoclient.v1.baremetal:ImportBaremetal
DEPRECATED in b272a5c6 2017-01-03
New command: openstack overcloud node import
openstack baremetal introspection bulk start:
tripleoclient.v1.baremetal:StartBaremetalIntrospectionBulk
DEPRECATED in b272a5c6 2017-01-03
New command: openstack overcloud node introspect
openstack baremetal introspection bulk status:
tripleoclient.v1.baremetal:StatusBaremetalIntrospectionBulk
NOT Deprecated
openstack baremetal configure ready state:
tripleoclient.v1.baremetal:ConfigureReadyState
NOT Deprecated
openstack baremetal configure boot:
tripleoclient.v1.baremetal:ConfigureBaremetalBoot
DEPRECATED in b272a5c6 2017-01-03
New command: openstack overcloud node configure

So my questions are basically:
1) Can we remove the deprecated code?
2) Does leaving the not deprecated commands make sesne?
3) Should we deprecate the remaining commands?
3) Do I need to update ValidateInstackEnv or is it okay for it to be
   busted for my use case?

Yours Tony.

__
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] [ceilometer] about add transformer into libvirt

[Jaze Lee]

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 happily
>>
>
> Gnocchi can capture rate information and can also have mathematical
> operations applied to it. there are some examples here:
> https://gnocchi.xyz/rest.html#examples. i imagine we'll change the gate
> workflow to that eventually.
It sounds like great. When the gnocchi can be ready to do transformer's work?
If it takes long time, we have to move to compute temporarily.

>
> you will still need partitioning for HA of central agents... and
> currently, the only way to get batch support is with workload_partitioning.
>
> but yes, moving the transformation to storage will provide the most
> durable solution for transformations.
>
> cheers,
>
> --
> gord
> __
> 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

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

[Matt Riedemann]

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 from source by default?


I've been struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.


Can you give some specific examples here? What are we spending massive 
amounts of time on that aren't addressing real problems? What are the 
real problems that the Nova team is not working on and apparently is a 
priority to everyone else in the OpenStack ecosystem but we are somehow 
oblivious?




The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.


Again, specific examples please. Is Nova somehow breaking compatibility 
every other week which is making upgrade impossible? I'm under the 
impression, maybe wrongly so, that the Nova team bends over backward 
trying to make sure we don't screw people doing upgrades as much as we 
can, at least across N-1 release boundaries. This is why we have 
microversions in the API. This is why we put in blocker schema 
migrations so that you can't move forward until you've performed online 
data migrations. Remember online data migrations? That's the thing where 
you don't have your control plane down for 8 hours running "nova-manage 
db sync". Writing code that migrates date at runtime across multiple 
cells and databases is not fun. If we're doing that for no apparent 
benefit, then we should stop I guess.




Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.


What is unstable about the compute API (assuming Nova is guilty of 
having unstable APIs here)?




Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.


I said this elsewhere in this thread, but how so? You can definitely run 
mixed versions of these services as they communicate over REST APIs. 
Cinder and Nova are using microversions. Neutron isn't, but uses API 
extensions to indicate if a feature is available in the API or not, 
which Nova leverages. The shared library thing I get, but hasn't that 
been a solved problem for years now (run the services in venvs, 
containers, etc)? What specifically keeps people from being able to run 
old Nova and newer Cinder/Neutron and vice-versa?


--

Thanks,

Matt

__
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] Switching to longer development cycles

[Matt Riedemann]

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 unless they are coordinated and tested
much like the current release process. That means that anyone is who
upgrading faster will be forced to wait for yearly releases because they
are the only ones they know to be 'stable'.

I'm actually one of the 20% developers upstream (although I'm trying to
change that), and my experience is actually the opposite. I like the
shorter release times, I'd find that longer releases will make it much
harder and longer waits to get anything in. With the 6 month cadence I
know that if I miss a deadline for one release, the next one is around
the corner. I've never had issue following up in the next release, and
often if a feature or bug fix misses a release, in my experience the
core team does a good job of making it a bit more of a priority. With
yearly releases I'd be waiting for a year to get my code into a stable
coordinated release, and then longer for that code to be deployed as
part of an upgrade to a stable release. And I do often miss release
deadlines, and that yearly wait would drive me mad.

The original goal for our cloud deployment was 1 release behind the
latest, or latest if no noticeably conflicting or potentially breaking
changes, with our own CI helping us ensure that. We sadly, like most
deployers, didn't live up to that goal purely because of what is now a
lot of technical debt we are paying off. Now we are paying off that
technical debt, and our release/upgrade cadence has improved, and
ideally we will get to the point of running latest releases again. As a
developer who does a bit of operations, I don't like the idea of yearly
releases because it means that those are my only safe option to upgrade
to, when in truth getting stability and bug fixes in sooner (or at least
potentially sooner) is where we want to be. Yes we can use master but
using master requires a lot of per project knowledge as to what is being
merged in at that time and what specs are being worked on, because, as
well as we all try to keep master stable, in introducing larger changes
there are always times when a few little things aren't quite right until
all the related reviews for a given feature of bug are merged. Tagged
milestones work, but the safety of a coordinated release is still much
better and requires less potential pain.

We are also one of those weird deployers that at times runs wildly
different versions of the various openstack components, with a large
amount of our own testing to help us ensure our cloud still operates
smoothly. We like smaller releases, because it lets us do incremental
upgrades to services with less features or changes, and helps us ensure
that no major version imbalance will cause any breaks. Larger yearly
releases gives us far less choices in the matter, and could in fact
potentially make this harder.

My other worry is that this proposal still feels related to the LTS
problem because it forces the community to now ensure safe upgrades
between much larger yearly releases. Effectively this forces us to now
support skip releases for 1 release back, while calling it something
else. It puts a larger burden on everyone as well since the releases are
much bigger (more changes to read through and compare), and more likely
to break during upgrade, thus likely making most deployers less likely
to upgrade until others have potentially fixed the pain or written up
how to avoid it thus pushing them even further behind. I may be reading
into this a little, but this proposal in a large part feels like a push
towards something closer to what LTS maintainers want releases to look
like, rather than what might be good for everyone else.

The other thing I really don't like is community goals being set once a
year. Some may be done faster than others, and we may want to introduce
new ones partway through the year. It assumes on a project as big and
complex as openstack we can alway see a full year ahead in perfect
clarity. I don't even think goals should have to always be bound to one
release as it is. Thierry himself said: "having one full year to
complete those will let us tackle more ambitious goals", which makes me
wonder, why can't we now set a goal that covers two releases, with its
intended end target being the following release, and set tasks that need
to completed in the first release of the two? This does not require a
yearly release, and while I get that single release goals will get more
priority, that's mostly a problem of management which will exist in
yearly releases (and goals) anyway.

If another part of the goal here is to lower overheads and management
effort, then PTLs can hold office for two releases, we can drop the
summit to once a year, etc. These 

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

[Zhenyu Zheng]

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 community.
__
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] Switching to longer development cycles

[Zhenyu Zheng]

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, people would continue to organize informal meetups.  But
> admittedly, this shifts the logistics apsect onto contributors -- that's
> probably okay, many other contributor communities self-organize meetups.
>
> [...]
>
> --
> /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
>

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 community.
__
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] [First Contact] [SIG] Presence at the PTG

[Ghanshyam Mann]

+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 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/Tuesday), I am
> proposing that we meet for one of these days. If you are interested, please
> let me know so I can get a headcount.
>
> -Kendall (diablo_rojo)
>
> __
> 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

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

[Tony Breeds]

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 general requirement for anyone who needed an
> FFE for functionality that isn't essential is that it's off by
> default, has minimal impact to the existing functionality and we have
> a rough estimate on feature landing.  Do you have idea when you expect
> to land this functionality? Additionally the patches seem to be
> primarily around the ironic integration so have those been sorted out?

Sadly this is going to be more impactful on x86 and anyone will like,
and I appologise for not raising these issues before now.

There are 3 main aspects:
1. Ironic integration/provisioning setup.
   1.1 Teaching ironic inspector how to deal with ppc64le memory
   detection.  There are a couple of approaches there but they don't
   directly impact tripleo
   1.2 I think there will be some work with puppet-ironic to setup the
   introspection dnsmasq in a way that's compatible with mulri-arch.
   right now this is the introduction of a new tag (based on options
   in the DHCP request and then sending diffent responses in the
   presense/absence of that.  Verymuch akin to the ipxe stuff there
   today.
   1.3 Helping tripleo understadn that there is now more than one
   deply/overcloud image and correctly using that.  These are mostly
   covered with the review Mark published but there is the backwards
   compat/corner cases to deal with.
   1.4 Right now ppc64le has very specific requirements with respect to
   the boot partition layout. Last time I checked these weren't
   handled by default in ironic.  The smiple workaround here is to
   make the overcloud image on ppc64le a whole disk rather than
   single partition and I think given the scope of everythign else
   that's the most likley outcome for queens.

2. Containers.
   Here we run in to several issues not least of which is my general
   lack of understanding of containers but the challenges as I
   understand them are:
   2.1 Having a venue to build/publish/test ppc64le container builds.
   This in many ways is tied to the CI issue below, but all of the
   potential solutions require some conatiner image for ppc64le to
   be available to validate that adding them doesn't impact x86_64.
   2.2 As I understand it the right way to do multi-arch containers is
   with an image manifest or manifest list images[1]  There are so
   many open questions here.
   2.2.1 If the container registry supports manifest lists when we
 pull them onto the the undercloud can we get *all*
 layers/objects - or will we just get the one that matches
 the host CPU?
   2.2.2 If the container registry doesn't support manifest list
 images, can we use somethign like manifest-tool[2] to pull
 "nova" from multiple registreies or orgs on the same
 registry and combine them into a single manifest image on
 the underclud?
   2.2.3 Do we give up entirely on manifest images and just have
 multiple images / tags on the undercloud for example:
nova:latest
nova:x86_64_latest
nova:ppc64le_64_latest
 and have the deployed node pull the $(arch)_latest tag
 first and if $(arch) == x86_64 pull the :latest tag if the
 first pull failed?
   2.3 All the things I can't describe/know about 'cause I haven't
   gotten there yet.
3. CI
   There isn't any ppc64le CI for tripleo and frankly there wont be in
   the forseeable future.  Given the CI that's inplace on x86 we can
   confidently assert that we won't break x86 but the code paths we add
   for power will largely be untested (beyonf unit tests) and any/all
   issues will have to be caught by downstream teams.

So as you can see the aim is to have minimal impact on x86_64 and
default to the existing behaviour in the absence of anything
specifically requesting multi-arch support.  but minimal *may* be > none
:(

As to code ETAs realistically all of the ironic related code will be
public by m3 but probably not merged, and the containers stuff is
somewhat dpenedant on that work / direction from the community on how to
handle the points I enumerated.


Yours Tony.

[1] https://docs.docker.com/registry/spec/manifest-v2-2/
[2] https://github.com/estesp/manifest-tool

__
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] [First Contact] [SIG] Presence at the PTG

[Matthew Oliver]

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 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 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 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/Tuesday), I am
>>> proposing that we meet for one of these days. If you are interested, please
>>> let me know so I can get a headcount.
>>>
>>> -Kendall (diablo_rojo)
>>>
>> 
>>> __
>>> 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

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

[Kendall Nelson]

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 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 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/Tuesday), I am
>> proposing that we meet for one of these days. If you are interested, please
>> let me know so I can get a headcount.
>>
>> -Kendall (diablo_rojo)
>>
> __
>> 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

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

[Jay Bryant]

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 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/Tuesday), I am
> proposing that we meet for one of these days. If you are interested, please
> let me know so I can get a headcount.
>
> -Kendall (diablo_rojo)
> __
> 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

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

[Adrian Turjak]

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 the current release process. That means that anyone is who
upgrading faster will be forced to wait for yearly releases because they
are the only ones they know to be 'stable'.

I'm actually one of the 20% developers upstream (although I'm trying to
change that), and my experience is actually the opposite. I like the
shorter release times, I'd find that longer releases will make it much
harder and longer waits to get anything in. With the 6 month cadence I
know that if I miss a deadline for one release, the next one is around
the corner. I've never had issue following up in the next release, and
often if a feature or bug fix misses a release, in my experience the
core team does a good job of making it a bit more of a priority. With
yearly releases I'd be waiting for a year to get my code into a stable
coordinated release, and then longer for that code to be deployed as
part of an upgrade to a stable release. And I do often miss release
deadlines, and that yearly wait would drive me mad.

The original goal for our cloud deployment was 1 release behind the
latest, or latest if no noticeably conflicting or potentially breaking
changes, with our own CI helping us ensure that. We sadly, like most
deployers, didn't live up to that goal purely because of what is now a
lot of technical debt we are paying off. Now we are paying off that
technical debt, and our release/upgrade cadence has improved, and
ideally we will get to the point of running latest releases again. As a
developer who does a bit of operations, I don't like the idea of yearly
releases because it means that those are my only safe option to upgrade
to, when in truth getting stability and bug fixes in sooner (or at least
potentially sooner) is where we want to be. Yes we can use master but
using master requires a lot of per project knowledge as to what is being
merged in at that time and what specs are being worked on, because, as
well as we all try to keep master stable, in introducing larger changes
there are always times when a few little things aren't quite right until
all the related reviews for a given feature of bug are merged. Tagged
milestones work, but the safety of a coordinated release is still much
better and requires less potential pain.

We are also one of those weird deployers that at times runs wildly
different versions of the various openstack components, with a large
amount of our own testing to help us ensure our cloud still operates
smoothly. We like smaller releases, because it lets us do incremental
upgrades to services with less features or changes, and helps us ensure
that no major version imbalance will cause any breaks. Larger yearly
releases gives us far less choices in the matter, and could in fact
potentially make this harder.

My other worry is that this proposal still feels related to the LTS
problem because it forces the community to now ensure safe upgrades
between much larger yearly releases. Effectively this forces us to now
support skip releases for 1 release back, while calling it something
else. It puts a larger burden on everyone as well since the releases are
much bigger (more changes to read through and compare), and more likely
to break during upgrade, thus likely making most deployers less likely
to upgrade until others have potentially fixed the pain or written up
how to avoid it thus pushing them even further behind. I may be reading
into this a little, but this proposal in a large part feels like a push
towards something closer to what LTS maintainers want releases to look
like, rather than what might be good for everyone else.

The other thing I really don't like is community goals being set once a
year. Some may be done faster than others, and we may want to introduce
new ones partway through the year. It assumes on a project as big and
complex as openstack we can alway see a full year ahead in perfect
clarity. I don't even think goals should have to always be bound to one
release as it is. Thierry himself said: "having one full year to
complete those will let us tackle more ambitious goals", which makes me
wonder, why can't we now set a goal that covers two releases, with its
intended end target being the following release, and set tasks that need
to completed in the first release of the two? This does not require a
yearly release, and while I get that single release goals will get more
priority, that's mostly a problem of management which will exist in
yearly releases (and goals) anyway.

If another part of the goal here is to lower overheads and management
effort, then PTLs can hold office for two releases, we can drop the
summit to once a year, etc. These things do not need to be bound to the
release 

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

[Kendall Nelson]

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/Tuesday), I am
proposing that we meet for one of these days. If you are interested, please
let me know so I can get a headcount.

-Kendall (diablo_rojo)
__
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] [tripleo] Blueprints moved out to Rocky

[Alex Schultz]

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 existing functionality this should have been
>> merged earlier in the cycle so we could work out any user facing
>> issues.
>
> Sorry about that.
> https://review.openstack.org/#/c/528000/
> https://review.openstack.org/#/c/528060/
>

I reviewed it a bit and I think you can put in the backwards
compatibility in the few spots I listed. The problem is really that a
Queens undercloud (tripleoclient/tripleo-common) needs to be able to
manage a Pike undercloud. For now I think we can grant the FFE because
it's not too bad if this is the only bit of changes we need to make.
But we will need to solve for the backwards compatibility prior to
merging.  I'll update the blueprint with this.

Thanks,
-Alex

> I will see how easy it is to also support the old naming convention...
>
> __
> 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

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

[Thomas Goirand]

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 used to package each and every b1, b2 and b3, be ready for rc1, and be
the first to release a working *and tested* release of OpenStack in
Debian. Since I'm no longer paid to do that, I just can't. I already
skipped Ocata, and yes, I will ignore these, and start the packaging
work *after* the official release. That is of course, unless some
companies offer to sponsor my work again... So far, each and every of
such proposal went to nowhere.

Cheers,

Thomas Goirand (zigo)

__
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] [release][PTL] Cycle highlights reminder

[Sean McGinnis]

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 every release cycle by various folks
asking for highlights of what was new and what significant changes were coming
in the new release. It was often the same answer to journalists, product
managers, and others that needed to compile that info.

To try to mitigate that somewhat, we've built in the ability to capture these
highlights as part of the release. It get compiled and published to the web
site so we have one place to point these folks to. It is intended as a place
where they can get the basic info they need, not as a complete marketing
message.

As you prepare for upcoming releases, please start to consider what you might
want to show up in this collection. We ideally want just a few highlights,
probably no more than 3 or 4 in most cases, from each project team.

Usage
-

This is done by adding some information to deliverables/queens/$PROJECT.yaml
in the openstack/releases repo similar to this:

   cycle-highlights:
 - Introduced new service to use unused host to mine bitcoin.


The formatting options for this tag are the same as what you are probably used
to with Reno release notes.

You can check on the formatting of the output by either running locally:

   tox -e docs

And checking the resulting file under doc/build/html/queens/highlights.html, or
you can view the output of the build-openstack-sphinx-docs job under
html/queens/highlights.html.

Ongoing
---

We now have three different places that document activities for three different
audiences:

Commit messages:  Developer documentation
Release notes:End user and deployer documentation
Cycle highlights: Journalists, product manager, and others

This will be the first release cycle with this last data source. It is our hope
that this will ease some of the burden for this information from the PTLs. If
you still get requests, please try to direct them here to spread awareness.

Thanks!

--
Sean McGinnis (smcginnis)


__
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] [tripleo] Blueprints moved out to Rocky

[Mark Hamzy]

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 in the cycle so we could work out any user facing
> issues.

Sorry about that.
https://review.openstack.org/#/c/528000/
https://review.openstack.org/#/c/528060/

I will see how easy it is to also support the old naming convention...

__
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] Switching to longer development cycles

[Michał Jastrzębski]

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 are to deliver
> - the main problem newcomers may have today, is that the release process is
> very disruptive if they have not completed their feature in time for the
> next cut, and not getting it in time will mean a 6 months delay, which is
> very frustrating.

I agree with these points. I would also add that besides that bigger
releases are hard to deliver, stable branches are harder to maintain
as time goes. By that I mean:
1. bug is submitted
2. bug is fixed in master
3. bug is backported to stable

As time goes discrepancy between master and stable grows and backports
are more expensive. Also it will lower the cadence of "this bug is
fixed by new feature" and could potentially mean users/ops will have
to suffer it for longer time.

> As a consequence, I would rather propose:
> - a longer cadence for stable releases
> - a quicker cadence for intermediary releases (release early, release
> often...)

I agree with that approach. With lightweight releases (but still
releases so some cross-community testing is involved, even if only
automated one) we leave decision to operators to either wait for a
year, upgrade in smaller chunks with some testing or chase master with
nearly no testing.

> A longer cadence for stable release would mean that we pick a duration
> between stable branches that would fit our users' need and that is a
> multiplier of the shorter release.  Based on the interview we conducted on
> our user base a year and a half ago, it seemed that 18mo was the right
> cadence, but we could easily poll the wider OpenStack user base to have
> confirmation.  The justification we got for an 18 month cadence was that it
> was itself a divider of most user hardware life-cycle (3 years) and would
> help in their overall life-cycle management (ie they can decide to upgrade
> their hw once in the duration, or not and get to a new version at hw renewal
> every 3 years).
>
> A quicker cadence for intermediary release would mean that instead of
> creating a branch per release, we would only tag the various project
> branches for a release, validating that integration tests and fixes are
> aligned at this point.  Distributions could independently decide to provide
> these release and create their own branch to maintain those, but this would
> not be the burden of the overall project.   As a consequence of the quicker
> cadence, the integration milestone duration should be reduced to something
> like 2 or 3 weeks.  Switching to tagging a release instead of branching,
> should allow for almost uninterrupted merge request, to the exception of the
> integration period when only integration fixes should be (temporarily)
> accepted, but overall simplifying what one has to do to resume his work from
> one version to another.  Also, with a quicker release cycle, the impact of
> missing the window would be less penalizing, which I believe is a big part
> of the newcomers frustration with the project.  If we were going with
> 18month stable, then 3 month or 1.5 months intermediary releases would be my
> recommendation.
>
> What would that mean for summits? I would think that we could only have one
> "worldwide" summit yearly, with the ability to have regional summits in
> between.
> What would that mean for PTG? I would propose to keep a 6 monthly cadence
> for in person PTG, but formalize the creation of a 3 monthly virtual project
> gathering over a period of 48h.  No cross project topics would happen in
> those.
>
> As a consequence of this I think we would have:
> - a stable branch lifecycle which is more aligned with our user base
> - the ability for fast user to run from master "tagged version"
> - the ability for distros to differentiate on the model the adopt with
> respect to the intermediary release
> - less frustration for newcomers
> - a project that moves faster
>
> Thanks for taking the time to read this proposal.
>
> Nick
>
>
>
> On Wed, Dec 13, 2017 at 11: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 time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>>
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them, 

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

[Sean McGinnis]

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 what progress has been made and what looks realistic to
complete in the next few weeks.

General Information
---

Looking ahead to Queens-3, please be aware of the various freeze dates. This
varies for deliverable type, starting with non-client libraries, then client
libraries, then finally services. This is to ensure we have time for
requirements updates and resolving any issues prior to RC.


Upcoming Deadlines & Dates
--

Extra-ATC deadline: January 12
Final non-client library release deadline: January 18
Final client library release deadline: January 25
Queens-3 Milestone: January 25
Rocky PTG in Dublin: Week of February 26, 2018

-- 
Sean McGinnis (smcginnis)

__
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] Switching to longer development cycles

[Matt Riedemann]

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 cycle as it is, especially for people working both 
upstream and downstream at the same time, is complicated enough.


Nothing in this proposal is talking about a longer time between feature 
freeze and release, as far as I know (maybe I missed that somewhere).


In that regard, the one year cycle does not make the release any more 
stable, it just means a bigger pile of stuff dumped on you when you 
finally get it and upgrade.


--

Thanks,

Matt

__
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] [Octavia] Community meeting regarding providers support

[Nir Magnezi]

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/9935153617

Regards,
Nir Magnezi
__
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] [security] Security SIG

[Luke Hinds]

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...), by forming a guild of people with a shared interest. This rings
especially true for security, where changes are often needed cross-project
and not in a silo. A SIG will also (we hope) encourage more user / operator
involvement and lead to discussions of field centric security pains, which
can then be realised as specs and code.

One key point , there will be no change in our overall operations and
working structure. We will still continue to manage and care for the
Security Guide, OSSNs, Bandit, Threat Reviews, Syntribos as well as
encourage and incubate new security projects. We will of course also
continue to work with the VMT, and will keep a Sec-Core group for launchpad
that can work with embargoed issues.

The plan is to make the change at the coming release juncture (Queens ->
Rocky).

Shortly I will follow up with a PTG planning etherpad with a view to
encourage projects and operators / users to seed security related
discussions within the SIGs PTG room. We will also perform an s/Security
Group/Security SIG in the docs and Wiki around the time of the PTG / post
Queens release.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124053.html

Best Regards,

Luke
__
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] Switching to longer development cycles

[Dean Troyer]

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 struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.

The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.

Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.

Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.

Outside of those three projects, what others are experiencing the
sorts of problems being discussed here?  Is this (mostly) only a
problem the three largest and tightly-coupled projects?  In the
current environment I do not see any of our corporate sponsors
stepping up to un-couple those three, but for the rest it seems like
Doug's suggestion goes a long way toward addressing problems being
brought up here.

dt

-- 

Dean Troyer
dtro...@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

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

[michael mccune]

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 around 
the question of involvement from the SIG in the process and also what 
definitions would be used for a baseline certification. Although no 
clear answer was reached on the latter topic, the group agreed that we 
should watch the proposal status and become involved if it grows and 
progresses.


There has been an outstanding request to the SIG for hosting a meeting 
in a more APAC friendly time. Ed Leafe has posted an email [8] and 
created a survey [9] to help narrow down times that might work for 
potential attendees. If you are interested in attending a meeting that 
would fit in the APAC time zones, please add your comments to the email 
thread and respond to the survey with your preferences. The SIG has 
received low responses to both surveys that have been created on this 
issue so if you are passionate about seeing meetings occur in a more 
friendly time zone please add your response and tell your friends to do 
the same!


As the holiday season is nearly upon us, the API-SIG will host its next 
meeting on January 4, 2018. Hope to see you then!


* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, submit 
a patch [6] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [6].


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready 
for review)

  https://review.openstack.org/444892

* WIP: Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that 
you are developing or changing, please address your concerns in an email 
to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, 
and comments to help guide the discussion of the specific challenge you 
are facing.


To learn more about the API SIG mission and the work we do, see our wiki 
page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://bugs.launchpad.net/openstack-api-wg
[6] https://git.openstack.org/cgit/openstack/api-wg
[7] http://lists.openstack.org/pipermail/openstack/2017-December/045844.html
[8] 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125304.html

[9] https://doodle.com/poll/bec9gfff38zvh3ud

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

__
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] Switching to longer development cycles

[Doug Hellmann]

> 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 always running elections, feature freeze is always just around the
>> corner, we lose too much time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>> 
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them, which takes additional time. The
>> end result is that getting anything done in OpenStack takes more time
>> than it used to, but we have kept our cycle rhythm mostly the same.
>> 
>> Our development pace was also designed for fast development in a time
>> where most contributors were full time on OpenStack. But fewer and fewer
>> people have 100% of their time to dedicate to OpenStack upstream
>> development: a lot of us now have composite jobs or have to participate
>> in multiple communities. This is a good thing, and it will only
>> accelerate as more and more OpenStack development becomes fueled
>> directly by OpenStack operators and users.
>> 
>> In another thread, John Dickinson suggested that we move to one-year
>> development cycles, and I've been thinking a lot about it. I now think
>> it is actually the right way to reconcile our self-imposed rhythm with
>> the current pace of development, and I would like us to consider
>> switching to year-long development cycles for coordinated releases as
>> soon as possible.
>> 
>> What it means:
>> 
>> - We'd only do one *coordinated* release of the OpenStack components per
>> year, and maintain one stable branch per year
> 
> 
> So I want to zero in on this part of the proposal.
> 
> It feels like the major driving factor for frustration with the 6 month 
> cadence
> is the weight of the coordinated release versus the value, both for developers
> and users.
> 
> But, I wonder, why do we put so much emphasis on this one process?
> 
> One thing I've always admired about Swift was how immune to the cadence Swift
> appears to be.
> 
> If a set of enthusiastic developers shows up mid-cycle and starts hammering on
> a new feature, there's no angst about whether or not it can be done "this
> release". It's worked on, Swift moves forward, and when it is done, Swift
> releases.
> 
> We have this amazing tool that lets us get away with not doing the hard work
> Swift did to encapsulate itself. Zuul has enabled us to test all the projects
> that want to co-gate together as one. This allows co-dependencies to creep in
> under the covers. We have something that, on first look, appears to be
> micro-service-architecture, but then in reality, behaves like a massive
> monolithic piece of software.
> 
> But maybe we're papering over the real problem. Maybe we need to stop working
> so hard to coordinate these releases.
> 
> As projects mature, I'd expect some to slow down and some to speed up. Glance,
> for instance, is in perpetual maintenance mode. Nova is currently in a pretty
> heavy debt pay down state and still landing features. Neutron too. So I'd
> expect Glance to make frequent small releases of newly fixed items. Nova might
> need to do a slower release while a refactor happens, and then a few 
> follow-ups
> to get fixes and small enhancements out.
> 
> I understand you mentioned the intermediate release tag and practice. I'm
> suggesting that we should focus on getting _everyone_ on that train. I don't
> think this works without such an effort.
> 
> We can keep the release name cadence. But then we get the best of both worlds.
> We can take stock of the intermediate releases over the last year, and make
> sure they all work together once a year. Chris Jones mentioned that we should
> give users time between milestones and release. I suggest we release an
> intermediary and _support it_. Let distros pick those up when they need to 
> ship
> new features. Let users jump ahead for a few projects when they need the bug
> fixes. And then once a year, have a flag day where we all stop, and make an
> assertion that we've done some things, achieved some goals, and suggest that
> you upgrade all the components to at least that version, and that we'll make
> sure you can do that from the last big version.
> 
> I understand the belief that nobody will run the intermediaries. If we don't
> make them work independently of other projects, nobody will. But if we do, and
> if we make sure our interfaces are solid enough to advance components at a
> disjoint pace, then users will in fact start to do just that, and we'll retain
> the faster feedback cycle, 

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

[Jeremy Stanley]

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, Pike, or Ocata.
[...]

Sounds fairly similar to the conclusion the fast-forward upgrades
discussions arrived at. I don't think there are any major objections
to this plan, people just need to work on an implementation.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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][Vitrage] Vitrage Entity Graph supports various actions according to mouse events for entities.

[MinWookKim]

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 this in a separate panel like your comment, or we can
check it at any time when test results arrive during different actions,
apart from other Test actions.

 

In short, the user should not be constrained by any action on the Test
action. (e.g. we can not take another action because we have to wait for the
result of Test.)

 

Adding a configuration menu is a good idea. :)

 

Thanks.

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Friday, December 15, 2017 1:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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, on the resource
properties panel?

 

Regarding excluding the performance tests: I suggest to make the list of
actions configurable, so every user can choose the wanted actions. It can
also be configured per resource type, I guess. 

 

Regarding ‘set monitoring configure’ – I’m not sure that it should be an
action. We could, alternatively, add a ‘configuration’ menu for all kinds of
configurations, regardless of the entity graph. 

 

Best Regards,

Ifat.

 

From: MinWookKim  >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
 >
Date: Thursday, 14 December 2017 at 17:46
To: "'OpenStack Development Mailing List (not for usage questions)'"
 >
Subject: 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 Test from the action list if they are not
needed.

 

'set monitoring configure' is an example of an action that can be added. We
can discuss the addition of required actions in the vitrage-dashboard at the
development level.

 

In addition, my experience is to manually register entities in the
/etc/vitrage/zabbix_conf.yaml file to use the monitoring configuration using
zabbix and vitrage. Then restart the Entity-Graph service.

 

I think we can let this process automatically modify the zabbix_conf.yaml
file by right-clicking on the desired entity in the Vitrage-Dashboard. (I
think we can modify zabbix_conf.yaml automatically via SSH if we perform
that action. we can enter the required parameters for this. )

 

As such, we can discuss the list to be included in the right mouse button
action.

 

what do you think?

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Thursday, December 14, 2017 11:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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 configure”?

 

Best Regards,

Ifat.

 

 

From: 김민욱  >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
 >
Date: Thursday, 14 December 2017 at 8:29
To: "openstack-dev@lists.openstack.org
 "
 >
Subject: [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 

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

[Afek, Ifat (Nokia - IL/Kfar Sava)]

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, on the resource 
properties panel?

Regarding excluding the performance tests: I suggest to make the list of 
actions configurable, so every user can choose the wanted actions. It can also 
be configured per resource type, I guess.

Regarding ‘set monitoring configure’ – I’m not sure that it should be an 
action. We could, alternatively, add a ‘configuration’ menu for all kinds of 
configurations, regardless of the entity graph.

Best Regards,
Ifat.

From: MinWookKim 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 14 December 2017 at 17:46
To: "'OpenStack Development Mailing List (not for usage questions)'" 

Subject: 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 Test from the action list if they are not 
needed.

'set monitoring configure' is an example of an action that can be added. We can 
discuss the addition of required actions in the vitrage-dashboard at the 
development level.

In addition, my experience is to manually register entities in the 
/etc/vitrage/zabbix_conf.yaml file to use the monitoring configuration using 
zabbix and vitrage. Then restart the Entity-Graph service.

I think we can let this process automatically modify the zabbix_conf.yaml file 
by right-clicking on the desired entity in the Vitrage-Dashboard. (I think we 
can modify zabbix_conf.yaml automatically via SSH if we perform that action. we 
can enter the required parameters for this. )

As such, we can discuss the list to be included in the right mouse button 
action.

what do you think?

Best Regards,
Minwook.

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Thursday, December 14, 2017 11:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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 configure”?

Best Regards,
Ifat.


From: 김민욱 >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, 14 December 2017 at 8:29
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [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 through the UI.

These actions include many things, and they do not go through the Vitrage 
interior.

Ask other projects directly.

This is similar to what appears when you right-click on an icon in Windows.

You can set various parameters for a specific action and pass it directly to 
the project.

The actions I thought so far are:
1. Execution of Mistral workflow
2. Performance & Load Test using external project for Entity
3. Set monitorig configure?

# Workflow

Entity click & select action
  |
Vitrage-Dashboard -> Mistral API -> Execute Workflow
   |
   --> Test Project API > Execute Test

I want to check the results of these actions on the UI.

For example, if the Performance & Load Test action is triggered on an Entity, 
the UI will display the following result.

Availability: 99.75%
Elapsed time: 59.66 secs
Data transferred: 10340918 bytes
Response time: 2.36 secs

The focus of this proposal is to provide a click action for the Entity to 
provide convenience to the user.

What do you think?

Best Regards,

Minwook.

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

[Sun, Yicheng (Jerry)]

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 List (not for usage questions) 

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

Hi, Jerry

Please check the rabbitmq section config in your murano.conf


[rabbitmq]
password = rabbit_password
login = rabbit_user
host = rabbit_host


Thanks,
Rong Zhu


On Wed, Dec 13, 2017 at 5:26 AM, Sun, Yicheng (Jerry)  
wrote:
> Hi All,
>
>
>
> I am struggling with deploying the apache package with murano agent. I 
> am using the pike version of murano. I was able to see the following 
> trace many times in the murano agent logs:
>
>
>
> 2017-12-12 20:41:18.836 2382 ERROR muranoagent.app
>
> 2017-12-12 20:42:17.397 2382 WARNING muranoagent.app [-] Communication
> error: timeout: timed out
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app Traceback (most 
> recent call last):
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/app.py", line 133, 
> in _wait_plan
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app with
> self._create_rmq_client() as mq:
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/m
> qclient.py",
> line 72, in __enter__
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/muranoagent/common/messaging/m
> qclient.py",
> line 83, in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> self._connection.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 
> 261, in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return
> self.connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 
> 802, in connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self._connection =
> self._establish_connection()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/connection.py", line 
> 757, in _establish_connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn =
> self.transport.establish_connection()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/kombu/transport/pyamqp.py", 
> line 130, in establish_connection
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app conn.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/connection.py", line 282, 
> in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> self.transport.connect()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 109, 
> in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app 
> self._connect(self.host, self.port, self.connect_timeout)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/amqp/transport.py", line 150, 
> in _connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app self.sock.connect(sa)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
> line 252, in connect
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app 
> timeout_exc=socket.timeout("timed out"))
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
> line 203, in _trampoline
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
> mark_as_closed=self._mark_as_closed)
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/__init__.py", 
> line 162, in trampoline
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return hub.switch()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app   File
> "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 
> 294, in switch
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app return
> self.greenlet.switch()
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app timeout: timed out
>
> 2017-12-12 20:42:17.397 2382 ERROR muranoagent.app
>
>
>
> I have tried with both a self-built ubuntu image with pike murano 
> agent as well as a newton debian image with murano agent from the 
> community application catalog that no longer exist. The VM was created 
> successfully. 

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

[Afek, Ifat (Nokia - IL/Kfar Sava)]

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

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

[MinWookKim]

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 from the action list if they are not
needed.

 

'set monitoring configure' is an example of an action that can be added. We
can discuss the addition of required actions in the vitrage-dashboard at the
development level.

 

In addition, my experience is to manually register entities in the
/etc/vitrage/zabbix_conf.yaml file to use the monitoring configuration using
zabbix and vitrage. Then restart the Entity-Graph service.

 

I think we can let this process automatically modify the zabbix_conf.yaml
file by right-clicking on the desired entity in the Vitrage-Dashboard. (I
think we can modify zabbix_conf.yaml automatically via SSH if we perform
that action. we can enter the required parameters for this. )

 

As such, we can discuss the list to be included in the right mouse button
action.

 

what do you think?

 

Best Regards,

Minwook.

 

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] 
Sent: Thursday, December 14, 2017 11:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: 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 configure”?

 

Best Regards,

Ifat.

 

 

From: 김민욱  >
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
 >
Date: Thursday, 14 December 2017 at 8:29
To: "openstack-dev@lists.openstack.org
 "
 >
Subject: [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 through the
UI.

 

These actions include many things, and they do not go through the Vitrage
interior.

 

Ask other projects directly.

 

This is similar to what appears when you right-click on an icon in Windows.

 

You can set various parameters for a specific action and pass it directly
to the project.

 

The actions I thought so far are:

1. Execution of Mistral workflow

2. Performance & Load Test using external project for Entity

3. Set monitorig configure?

 

# Workflow

 

Entity click & select action

  |

Vitrage-Dashboard -> Mistral API -> Execute Workflow

   |

   --> Test Project API > Execute Test

 

I want to check the results of these actions on the UI. 

 

For example, if the Performance & Load Test action is triggered on an
Entity, the UI will display the following result.

 

Availability: 99.75%

Elapsed time: 59.66 secs

Data transferred: 10340918 bytes

Response time: 2.36 secs

 

The focus of this proposal is to provide a click action for the Entity to
provide convenience to the user.

 

What do you think?

 

Best Regards,

 

Minwook.

 

 

 

<>__
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] Switching to longer development cycles

[Luigi Toscano]

- 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 Feature Freeze point in a cycle to get things
> in, or they will be delayed for 6 months. With the year-long cycle, now
> anything missing Feature Freeze will be delayed by a year. The long cycle
> also means that a lot more time will be spent backporting things to the
> current release, since people won’t be able to wait a whole year for some
> improvements.
> 
> Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).

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 cycle as it is, especially for people working both 
upstream and downstream at the same time, is complicated enough.

If you trust master, as others suggested in this thread, just use master. Let 
people that wants stable releases use them.

-- 
Luigi


__
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] Switching to longer development cycles

[Matt Riedemann]

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 reelection. Reducing the frequency of
those extra activities would increase time dedicated to development.


What does a PTL need to achieve in a term beyond managing a release? How 
many PTLs come into the position with a docket of major changes they 
want to implement in each project? Seems like that would be really 
disruptive to the flow of a team.


Or is the achievement equal to the number of blueprints merged? If so, 
that has to be scoped to the complexity and priority of the blueprint, 
who is doing the work and how many people in the core team are helping 
to get them through, which is not really something fully in the PTLs 
control.


--

Thanks,

Matt

__
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] [tripleo] Blueprints moved out to Rocky

[Alex Schultz]

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,
>> >
>> > (undercloud) [stack@oscloud5 ~]$ openstack image list
>> > +--
>> +---++
>> > | ID   | Name  |
>> > Status |
>> > +--
>> +---++
>> > | fa0ed7cb-21d7-427b-b8cb-7c62f0ff7760 | ppc64le-bm-deploy-kernel  |
>> > active |
>> > | 94dc2adf-49ce-4db5-b914-970b57a8127f | ppc64le-bm-deploy-ramdisk |
>> > active |
>> > | 6c50587d-dd29-41ba-8971-e0abf3429020 | ppc64le-overcloud-full|
>> > active |
>> > | 59e512a7-990e-4689-85d2-f1f4e1e6e7a8 | x86_64-bm-deploy-kernel   |
>> > active |
>> > | bcad2821-01be-4556-b686-31c70bb64716 | x86_64-bm-deploy-ramdisk  |
>> > active |
>> > | 3ab489fa-32c7-4758-a630-287c510fc473 | x86_64-overcloud-full |
>> > active |
>> > | 661f18f7-4d99-43e8-b7b8-f5c8a9d5b116 | x86_64-overcloud-full-initrd  |
>> > active |
>> > | 4a09c422-3de0-46ca-98c3-7c6f1f7717ff | x86_64-overcloud-full-vmlinuz |
>> > active |
>> > +--
>> +---++
>> >
>> > This will change existing functionality.
>> >
>>
>> Any chance of backwards compatibility if no arch is specified in the
>> image list so it's not that impacting?
>
> The patch as currently coded does not do that.  It is more consistent and
> cleaner as it is currently written.  How opposed is the community to a
> new convention?  I know we are pushing up against holidays and deadlines and
> don't know how much longer it will take to also support the old naming
> convention.
>

It's not that the community is averse to new conventions, the issue is
the lack of backwards compatibility especially late in the cycle. If
we need to extend out until the middle of January/the end of M3 for
this that is an option to get the backwards compatibility. I'm
wondering if this lack of backwards compatibility would be a problem
for upgrades or the more advanced use cases.  We do support the
ability for custom role images for the end users so I'm wondering what
the impact would be for that.  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 in the cycle so we could work out any user facing
issues.

> RedHat is asking for another identifier along with ppc64le given that there
> are
> different optimizations and CPU instructions between a Power 8 system and a
> Power 9 system.  The kernel is certainly different and the base operating
> system might be as well.
>
> __
> 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

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

[Dan Smith]

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
> surveys, it is only the major 6-month named releases that are
> deployed, and even then, some time after their release.
>
> Integrated releases make sense for deployers. What does it mean if
> Nova has some new stuff, but it requires a new release from Cinder in
> order to use it, and Cinder hasn't yet released the necessary updates?
> Talking about releasing projects on a monthly-tagged basis just dumps
> the problem of determining what works with the rest of the codebase
> onto the deployers.

Similarly, right now we have easy and uniform points at which we have to
make upgrade and compatibility guarantees. Presumably in such a new
world order, a project would not be allowed to drop compatibility in an
intermediate release, which means we're all being forced into a longer
support envelope for versioned APIs, config files, etc.

If we did do more of what I assume Doug is suggesting, which is just tag
monthly and let the projects decide what to do with upgrades, then we
end up with a massively more complex problem (for our own CI, as well as
for operators) of mapping out where compatibility begins and ends
per-project, instead of at least all aiming for the same point in the
timeline.

--Dan

__
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] Switching to longer development cycles

[Clint Byrum]

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 an upgrade well and the only supported
path out is through several upgrades.

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, Pike, or Ocata.

And then we keep doing that in perpetuity. This gives users 18 months
from one release to get it up and stabilized, and then start the upgrade
cycle again. It also gives them 2 targets to hit while they do that,
since they can try "the stable that just released" and "the prior one"
and not feel like they'll fall behind if the new release has issues and
they have to stay conservative.

Basically instead of doing the release less frequently, shift the value
of the release toward what our users need.

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 the
> corner, we lose too much time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.
> 
> As our various components mature, we have less quick-paced feature
> development going on. As more and more people adopt OpenStack, we are
> more careful about not breaking them, which takes additional time. The
> end result is that getting anything done in OpenStack takes more time
> than it used to, but we have kept our cycle rhythm mostly the same.
> 
> Our development pace was also designed for fast development in a time
> where most contributors were full time on OpenStack. But fewer and fewer
> people have 100% of their time to dedicate to OpenStack upstream
> development: a lot of us now have composite jobs or have to participate
> in multiple communities. This is a good thing, and it will only
> accelerate as more and more OpenStack development becomes fueled
> directly by OpenStack operators and users.
> 
> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for coordinated releases as
> soon as possible.
> 
> What it means:
> 
> - 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 per year
> - We'd have only one PTG with all teams each year
> 
> What it does _not_ mean:
> 
> - It doesn't mean we'd release components less early or less often. Any
> project that is in feature development or wants to ship changes more
> often is encouraged to use the cycle-with-intermediary release model and
> release very early and very often. It just means that the minimum we'd
> impose for mature components is one release per year instead of one
> release every 6 months.
> 
> - It doesn't mean that we encourage slowing down and procrastination.
> Each project would be able to set its own pace. We'd actually encourage
> teams to set objectives for the various (now longer) milestones in the
> cycle, and organize virtual sprints to get specific objectives done as a
> group. Slowing down the time will likely let us do a better job at
> organizing the work that is happening within a cycle.
> 
> - 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 often.
> 
> - It doesn't mean less emphasis on common goals. While we'd set goals
> only once per year, I hope that having one full year to complete those
> will let us tackle more ambitious goals, or more of them in parallel.
> 
> - It doesn't simplify upgrades. The main issue with the pace of
> upgrading is not the rhythm, it's the imposed timing. Being forced to
> upgrade every year is only incrementally better than being forced to
> upgrade every 6 months. The real solution there is better support for
> skipping releases that don't matter to you, not longer development cycles.
> 
> - It doesn't give us LTS. The cost of maintaining branches is not 

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

[Matt Riedemann]

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 
merged:


https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton

3 of those are related to a CVE errata, and the other is an API 
regression introduced in Newton (trivial low-risk fix).


Those can't merge until the corresponding Ocata backports are merged 
first. I'll start pinging people for reviews on the Ocata backports.


2. Fix and backport https://bugs.launchpad.net/nova/+bug/1738094

This came up just yesterday but it's an upgrade impact introduced in 
Newton so while we have the branch available I think we should get a fix 
there before EOL. There are going to be at least two fixes for this bug:


a) Don't store all of the instance group (members and policies) in the 
request_specs table. I think this is a correct fix but I also think 
because of how instance groups and request spec code tends to surprise 
you with funny bugs in funny ways, it's high risk to backport this to 
newton. Dan has a patch started though: 
https://review.openstack.org/#/c/527799/3


b) Alter the request_specs.spec column from TEXT to MEDIUMTEXT, just 
like the build_requests.instance column was increased for similar 
reasons (instance.user_data alone is a MEDIUMTEXT column). This is a 
straight forward schema migration and I think is low risk to backport 
all the way to Newton.


--

Thanks,

Matt

__
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] Switching to longer development cycles

[Sven Anderson]

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 OpenStack is nothing but a wet
dream. That's why I don't think, the 1-year release proposal is about
cutting travel costs. Compared to the costs of the release production
upstream and downstream, travel costs are just a joke. I fully support the
1-year cycle, not because I think it's good to have fewer releases in
general (the opposite is true, I like "release early and often"), but
because I think it's a necessary adaption to reality of OpenStack
development. Release production upstream and downstream creates a _huge_
overhead at the moment, if we like that fact or not, and cutting this
overhead in half is great! In the end the release production is done in
large parts by the same developers that develop upstream as well, and it
would free a lot of resources to do actual upstream development.

Of course, in the perfect world, upstream OpenStack would be a continuous
release-free stream of fresh and bug free software, that people can pull
downstream releases from whenever they like. But that's not the reality, at
least not as long the scope of the product is broader than "Nova on
Devstack". And I honestly don't see a project like OpenStack be "CD'able"
in a foreseeable future. So, to reach CD (which, again, would be awesome)
you have a dependency chain like "better test coverage" -> "shorter
stabilization phase" -> "more frequent releases" -> "CD". So, the time we
reach a stabilization phase of 0 days, that is, no stable branches are
required in general, we reached true CD. But I don't see stabilization
becoming shorter or easier, rather the opposite, because OpenStack becomes
more and more complex and featureful. So, as long as we can't achieve that,
we have to bite the bullet and adapt release cadence to the stabilization
and production efforts, if we like it or not.

BTW. I don't see the 1-year release connected to the frequency of
face-to-face meetings (PTG, Summit, ...), which I think should _not_ be
reduced.


Cheers,

Sven
__
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] Switching to longer development cycles

[Thierry Carrez]

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 think the idea deserves plenty of consideration, but my initial
> reaction has been that it is symptomatic care to ease the impact of
> problems, rather than a cure for whatever the disease might be.

We can take it from multiple angles.

It takes a lot of time to get anything merged, because getting code
reviewed takes a long time, because we are lacking core reviewers,
because becoming a core reviewer is difficult, because it's a role
invented in simpler times. We have tried to fix the disease for a while
without much success. It may be time to ease the pain ?

We have more and more part-time contributors, which is a good thing.
Users of OpenStack are getting more involved in upstream development,
but hey generally can't spend more than 20% of their time upstream.
Compared to people that can spend 4 times as much, getting anything done
(not just getting code reviewed) roughly takes 4 times as long. It's no
wonder 20% people have a difficult experience trying to contribute in a
cycle designed around the needs of 80% people.

In cross-project work and smaller projects, we end up discussing
one-year worth of changes every 6 months. There is not time to implement
and work on everything we discuss. That tends to point to events
occurring too often, or "cycles" being too short.

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 reelection. Reducing the frequency of
those extra activities would increase time dedicated to development.

So yes it's a series of symptoms caused by different diseases, but the
fact that we use a development cycle that was designed for different
times and needs seems to be in all cases an aggravating factor...

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

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

[Nick Barcet]

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 that the release process is
very disruptive if they have not completed their feature in time for the
next cut, and not getting it in time will mean a 6 months delay, which is
very frustrating.

As a consequence, I would rather propose:
- a longer cadence for stable releases
- a quicker cadence for intermediary releases (release early, release
often...)

A longer cadence for stable release would mean that we pick a duration
between stable branches that would fit our users' need and that is a
multiplier of the shorter release.  Based on the interview we conducted on
our user base a year and a half ago, it seemed that 18mo was the right
cadence, but we could easily poll the wider OpenStack user base to have
confirmation.  The justification we got for an 18 month cadence was that it
was itself a divider of most user hardware life-cycle (3 years) and would
help in their overall life-cycle management (ie they can decide to upgrade
their hw once in the duration, or not and get to a new version at hw
renewal every 3 years).

A quicker cadence for intermediary release would mean that instead of
creating a branch per release, we would only tag the various project
branches for a release, validating that integration tests and fixes are
aligned at this point.  Distributions could independently decide to provide
these release and create their own branch to maintain those, but this would
not be the burden of the overall project.   As a consequence of the quicker
cadence, the integration milestone duration should be reduced to something
like 2 or 3 weeks.  Switching to tagging a release instead of branching,
should allow for almost uninterrupted merge request, to the exception of
the integration period when only integration fixes should be (temporarily)
accepted, but overall simplifying what one has to do to resume his work
from one version to another.  Also, with a quicker release cycle, the
impact of missing the window would be less penalizing, which I believe is a
big part of the newcomers frustration with the project.  If we were going
with 18month stable, then 3 month or 1.5 months intermediary releases would
be my recommendation.

What would that mean for summits? I would think that we could only have one
"worldwide" summit yearly, with the ability to have regional summits in
between.
What would that mean for PTG? I would propose to keep a 6 monthly cadence
for in person PTG, but formalize the creation of a 3 monthly virtual
project gathering over a period of 48h.  No cross project topics would
happen in those.

As a consequence of this I think we would have:
- a stable branch lifecycle which is more aligned with our user base
- the ability for fast user to run from master "tagged version"
- the ability for distros to differentiate on the model the adopt with
respect to the intermediary release
- less frustration for newcomers
- a project that moves faster

Thanks for taking the time to read this proposal.

Nick



On Wed, Dec 13, 2017 at 11: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 time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.
>
> As our various components mature, we have less quick-paced feature
> development going on. As more and more people adopt OpenStack, we are
> more careful about not breaking them, which takes additional time. The
> end result is that getting anything done in OpenStack takes more time
> than it used to, but we have kept our cycle rhythm mostly the same.
>
> Our development pace was also designed for fast development in a time
> where most contributors were full time on OpenStack. But fewer and fewer
> people have 100% of their time to dedicate to OpenStack upstream
> development: a lot of us now have composite jobs or have to participate
> in multiple communities. This is a good thing, and it will only
> accelerate as more and more OpenStack development becomes fueled
> directly by OpenStack operators and users.
>
> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for 

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

[Dan Smith]

> 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 out how to solve the rebase conflicts instead of just
> focusing on her code.

Agreed. The first reaction I had to this proposal was pretty much what
you state here: that now the 20% person has a 365-day window in which
they have to keep their head in the game, instead of a 180-day one.

Assuming doubling the length of the cycle has no impact on the
_importance_ of the thing the 20% person is working on, relative to
project priorities, then the longer cycle just means they have to
continuously rebase for a longer period of time.

--Dan

__
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] Switching to longer development cycles

[Matt Riedemann]

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_  stick to what's tested together,
and we should keep testing things together, I also think we should be
more comfortable telling users to go ahead and install a new release of
Nova and feel confident they're going to be supported in doing so.

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.


Nova can certainly run with older versions of all the other projects. We 
communicate over (mostly) versioned REST APIs (glance v2.0 is fine for 
nova, keystone v3 is fine, cinder has microversions, and neutron exposes 
new API features using extensions).


I agree that it's a risk to run that way because it's not how we do CI 
testing, but it's totally possible and I agree that we should be telling 
people you can do this.


--

Thanks,

Matt

__
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] Switching to longer development cycles

[Matt Riedemann]

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 significant done within the timeframe of a
cycle, which leads to frustration as you have to get your stuff
re-discussed and re-prioritized at the start of the next cycle.


If the change that the 20% person is trying to get done is not an actual 
priority for the project, and is significant, then yes it's going to 
take a long time because a stretched core team isn't going to prioritize 
helping to design, implement, review and support something that most 
people don't care about.


If the thing that the 20% contributor is pushing is not all that 
complicated and is shared as a need by many people (I'm thinking 
operators community here), then it's easier for the project maintainers 
as a whole to agree that it should be bumped up in priority. There are a 
few cases like this in nova in the last couple of releases (changing key 
on rebuild in queens, extend attached volume in pike).


--

Thanks,

Matt

__
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] Switching to longer development cycles

[Chris Dent]

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 consideration, but my initial
reaction has been that it is symptomatic care to ease the impact of
problems, rather than a cure for whatever the disease might be.

Frequently, the outcome that happens when band-aiding symptoms is
that there are a lot of unintended (and unexpected) consequences
that introduce more problems which require more band-aids, and so
on.

For example: if we go to a longer cycle, if some projects choose to
use intermediate or milestone-based releases, while others do not,
how do we manage upgrade (grenade) testing? What complexities will
that introduce?

Is there an opportunity here to decouple consumption of releases
from their creation? This is already the case. Most distributions
and deployments are months if not years behind master. The frequency
at which master is blessed as a release™ doesn't necessarily have to
be coupled with that.

If the core problem we're trying to solve for here is to not
discourage part time contribution, let's get to the root causes of
that. The cycle being too short seems unlikely as a _root_ cause.
Six months is a long time.

If there are multiple problems that we're trying to solve for, let's
be clear about what they are. This thread suggests that "too many
events" is a problem, but that's only associated with cycle length
because we choose for it to be, not because it has to be.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Switching to longer development cycles

[Clint Byrum]

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 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 
> > some plans for their projects. Personally, I feel the PTG is not working if 
> > we also have summits – and having two summits and one PTG will make things 
> > worse. Therefore I propose to scrap the PTG and add “design summits” back 
> > to the OpenStack summit. As a side effect this will be a better on-ramp for 
> > casual developers who can’t justify going to the PTG and ensure enough 
> > developers are on-hand to hear the operator’s feedback.
> 
> The original purpose of the summits were for the developers to get together 
> to plan what they would work on for the next few months. Over time, the big 
> money came pouring in, and they became huge marketing events, with developers 
> pushed off to the fringes. The recent PTGs have been refreshing because they 
> are more like the original events, where there is no distraction by the 
> corporate marketing machines, and we can focus on getting shit done.
> 
> My question is: if we only have a release once a year, why do we need two 
> Summits a year?
> 

Regional rotation seems the best reason to keep two per year.

__
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] [ceilometer] about add transformer into libvirt

[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 happily
> 

Gnocchi can capture rate information and can also have mathematical 
operations applied to it. there are some examples here: 
https://gnocchi.xyz/rest.html#examples. i imagine we'll change the gate 
workflow to that eventually.

you will still need partitioning for HA of central agents... and 
currently, the only way to get batch support is with workload_partitioning.

but yes, moving the transformation to storage will provide the most 
durable solution for transformations.

cheers,

-- 
gord
__
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] Switching to longer development cycles

[Ed Leafe]

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 something significant done within the timeframe of a
> cycle, which leads to frustration as you have to get your stuff
> re-discussed and re-prioritized at the start of the next cycle.

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. The 20% developer would be spending a greater 
proportion of her time figuring out how to solve the rebase conflicts instead 
of just focusing on her code.

I’m not saying that the advantages you mention aren’t real. I’m just pointing 
out that there are downsides to stretching things out.

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

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

[Afek, Ifat (Nokia - IL/Kfar Sava)]

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 configure”?

Best Regards,
Ifat.


From: 김민욱 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, 14 December 2017 at 8:29
To: "openstack-dev@lists.openstack.org" 
Subject: [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 through the UI.

These actions include many things, and they do not go through the Vitrage 
interior.

Ask other projects directly.

This is similar to what appears when you right-click on an icon in Windows.

You can set various parameters for a specific action and pass it directly to 
the project.

The actions I thought so far are:
1. Execution of Mistral workflow
2. Performance & Load Test using external project for Entity
3. Set monitorig configure?

# Workflow

Entity click & select action
  |
Vitrage-Dashboard -> Mistral API -> Execute Workflow
   |
   --> Test Project API > Execute Test

I want to check the results of these actions on the UI.

For example, if the Performance & Load Test action is triggered on an Entity, 
the UI will display the following result.

Availability: 99.75%
Elapsed time: 59.66 secs
Data transferred: 10340918 bytes
Response time: 2.36 secs

The focus of this proposal is to provide a click action for the Entity to 
provide convenience to the user.

What do you think?

Best Regards,

Minwook.



__
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] Switching to longer development cycles

[Ed Leafe]

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






__
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] Switching to longer development cycles

[Jeremy Stanley]

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 participating
in software development.

If by "operators" you mean people who are unable or unwilling to
participate in developing software then I suspect attempting to
extend the PTG to that demographic will serve only as a distraction
from people trying to do high-bandwidth codevelopment on a team.

I personally prefer the first definition. Operators are often also
developers and vice versa. It's not one side against the other, but
to me the PTG is mostly about doing software development so
attendees should come prepared to roll up their sleeves and do that.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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] Switching to longer development cycles

[Julien Danjou]

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 significant done within the timeframe of a
> cycle, which leads to frustration as you have to get your stuff
> re-discussed and re-prioritized at the start of the next cycle.
>
> I'm open to other ways to solve what is perceived by many as an
> untenable cadence -- but so far the only suggestion I got on this thread
> was that 20% people should really ask their manager to become 80%
> people. And I don't see that happening.

Yeah that does not seem realistic.

I like the way you state the problem actually: "it's just impossible to
get something significant done within the timeframe of a cycle, which
leads to frustration as you have to get your stuff re-discussed and
re-prioritized at the start of the next cycle".

So the first thing that comes to mind is that having a longer release
cycle will fix it.

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"?

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
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] Switching to longer development cycles

[Ed Leafe]

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're all still working together well.
> 
> My entire point is that we should draw clearer lines around our API's and
> admit that we have a ton of tight coupling that requires us to release
> things in an integrated fashion.
> 
> While I agree, where we're at is a tightly coupled mess, what I don't agree
> with is that the answer is to keep shipping the mess.

I agree 100% with that sentiment. However, *until* we achieve something close 
to that, we have to continue to ship “this mess”. Taking a mess and shipping it 
separately doesn’t clean up the mess.


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

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

[Thierry Carrez]

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 are struggling to recruit new core reviewers, so I think
>> reducing expectations and slowing down the pace could help there.
> 
> 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
> solves it.

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 significant done within the timeframe of a
cycle, which leads to frustration as you have to get your stuff
re-discussed and re-prioritized at the start of the next cycle.

I'm open to other ways to solve what is perceived by many as an
untenable cadence -- but so far the only suggestion I got on this thread
was that 20% people should really ask their manager to become 80%
people. And I don't see that happening. We 80% people can bury our heads
in the sand and pretend that we don't need the 20% people or somehow fix
them so they become 80% people. Fact is we have less and less of those
80% people and we fail to recruit enough of the many available 20%
people to be sustainable long-term.

I'm aware this solution is not perfect. I don't like the idea of
releasing less often, and I can see how intermediary releases might not
get used, leading to "minor releases" that would look like our current
milestones. Maybe the drawbacks outweigh the benefits. Open to other
suggestions :)

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
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] Switching to longer development cycles

[Fred Li]

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 lot to the vendors.
2. prefer longer development cycle to have more features and to
stabilize the release.
I don't think the reason 2 is valid, so I will ignore this. The reason
1 does exist.

But I don't think the the proposal to change release cycle to one year
is good enough to accept.
What image OpenStack community gives to customers if we change the
release cycle to 1 year? I guess there could be 2. The first one is
that OpenStack is mature enough. The second could be that OpenStack is
stepping down as fewer developers are working on it, thus the output
is not big enough. Considering the second reason, I don't think this
idea is good.

The problem some vendors cost is high to follow every single release
still exists. My proposal is OpenStack Foundation can adjust the
release strategy, like the first 6 months release is features
focused, and the next 6 months' is mainly bugs focused. I would say
that it is more a marketing strategy than a technical development
strategy to manage customers' expectation, and can probably help
vendors not to productize each release.

I also share my opinion about ptg/summit/mid-cycle here.
Despite how long the release cycle is, the engineers do need meet in
person periodically. My feeling (sorry, I don't have pretty convincing
figure) is around every 3 months. So design summit (or PTG) every 6
months is mandatory, as the developers need talk about cross-project
topics together, and it is easier to find sponsors supporting formal
events than others (e.g. mid-cycle). Mid-cycle can be decided by each
project team. And to save travel cost, to have the summit and ptg in
the same week and same city is an option.

My 1 cent.


On Thu, Dec 14, 2017 at 6:21 PM, Renat Akhmerov
 wrote:
> 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
> solves it.
>
>
> Yes, exactly.
>
>
> Renat Akhmerov
> @Nokia
>
>
> __
> 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
>



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

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

[Sylvain Bauza]

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 be helpful to them and generally reduce stress in OpenStack
> >> development. I know people who can spend 100% of their time upstream can
> >> cope with our current rhythm. I just observe that we have less and less
> >> of those full-time people and need to attract more of the part-time one.
> >>
> >> If this proposal is not helping developers and making OpenStack
> >> development less painful, I don't think we should do it:)
> >
> > Given I have the luxury of working mostly full time upstream, I've
> > obviously got a skewed perspective on this whole discussion.
> >
> > I am interested in which part time developers are having issues keeping
> > up and how, i.e. are these core team members that don't feel they can be
> > good core reviewers if they aren't around enough to keep up with the
> > changes that are happening? I could definitely see a case like that with
> > some of the complicated stuff going on in nova like the placement and
> > cells v2 work.
>
> There was two kind of feedback.
>
> - 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 core reviewers, so I think
> reducing expectations and slowing down the pace could help there.
>
>

Like others said, I don't see how slowing down the number of releases will
help those people to catch up with the project updates since features
should in theory be delivered at the same pace (if we don't loose developer
interests in developing features, which is one of my concerns).
Struggling with managing your day-to-day work really means you're in
trouble, and you need to find ways to prioritize your tasks, IMHO. Be
verbose, talk to your manager, try to find how you can increase time for
OpenStack. And yes, it's hard and I'm personnally facing problems too.


- People in projects that are more mature (or packaging projects) where
> the process overhead (coordinated releases, elections, PTG
> preparation...) ends up representing a significant chunk of the work.
> For those it felt like longer cycles would reduce that overhead and give
> them more time to do real work.
>
>
If we do intermediary releases, it doesn't really solve the problem either,
right?
There are actually two separate concerns from what I can read :
 - release coordination (tagging a milestone or branching a release)
 - governance and community coordination (electing a PTL or organizing a
PTG)


The former concern does seem to me less impactful now because thanks to a
couple of major improvements with Zuul and release management, we're less
depending on humans. And, again, doing intermediary releases would still
burn people's time, right ?
The latter is really a specific problem tied to a specific group of people
(namely the PTLs and the election team). Couldn't we rather review what
those people need to do and how we can help them to reduce the burden ?


> If we're talking about part time contributors that are contributing bug
> > fixes here and there, docs patches, random reviews, I'm not sure how
> > this is substantially better for them.
>
> No, I'm more talking about someone who can dedicate one day per week to
> OpenStack development, and who currently struggle to be part of a team
> where everyone has to be >80% to keep up with the rhythm.
>
> > We've said in this thread that project teams are encouraged to still do
> > intermediate releases, often. And we're still going to be working on
> > features, so how does that help slow things down for the part time
> > contributor?
>
> My hope is that by reducing the "coordinated release" pressure, we'd
> encourage project teams to adopt a rhythm that is more natural for them.
> Some teams would still be pretty active with lots of intermediary
> releases, while some others would have an easier time.
>
>

Well, I do feel that if we decide to go with a 1-year timeframe for a
"coordinated" release, it would highly raise the price of that release.
Imagine what it means for someone who really desperately want to integrate
a feature that require some kernel update and fancy network driver thingy.
If you loose the target, you're a dead man for 1 year. Of course, you can
target an intermediary release but since we only "coordinate" yearly, how
can you be sure that packagers will ship your feature from that
intermediary release ?

> If *everyone* must slow down then that's going to be a problem I think,
> > unless we do something like alternating intermediate releases where
> > there are new features and then only bug fixes, something like 

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

[Clint Byrum]

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 patches out-of-tree to
scale. Luckily, I'm told neither does Nova anymore, so maybe this will
get more natural.. well.. naturally.

Excerpts from Blair Bethwaite's message of 2017-12-14 18:39:33 +1100:
> 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
> https://trello.com/b/9fkuT1eU/nectar-openstack-versions for the current
> version snapshot.
> 
> On 14 Dec. 2017 18:00, "Clint Byrum"  wrote:
> 
> > 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 much about doing the whole integrated release dance so often.
> > >
> > > Is there any data about how operators approach this currently? Nectar
> > > (and I presume other large and/or loosely coordinated OpenStack
> > > clouds) has been running different projects across multiple versions
> > > for quite a while, sometimes 3 or 4 different versions. Coordinating
> > > upgrades in a federated cloud with distributed operations requires
> > > that we do this, e.g., our current Nova Newton upgrade has probably
> > > been in-train for a couple of months now.
> > >
> >
> > That's interesting. Can you share what you mean by running 3 or 4
> > different versions?
> >
> > Do you mean you mix versions in a single region, like, Pike keystone,
> > Ocata Nova, and Newton Neutron? Or do you mean you might have a region
> > running Pike, and another running Ocata, and another running Newton?
> >
> > __
> > 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

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

[Dmitry Tantsur]

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 summit (and in fact I skipped 
Sydney). On the other hand some devs got together and hashed out some plans for 
their projects. Personally, I feel the PTG is not working if we also have 
summits – and having two summits and one PTG will make things worse. Therefore 
I propose to scrap the PTG and add “design summits” back to the OpenStack 
summit. As a side effect this will be a better on-ramp for casual developers 
who can’t justify going to the PTG and ensure enough developers are on-hand to 
hear the operator’s feedback.


The original purpose of the summits were for the developers to get together to 
plan what they would work on for the next few months. Over time, the big money 
came pouring in, and they became huge marketing events, with developers pushed 
off to the fringes. The recent PTGs have been refreshing because they are more 
like the original events, where there is no distraction by the corporate 
marketing machines, and we can focus on getting shit done.

My question is: if we only have a release once a year, why do we need two 
Summits a year?


That's a very good question. I'd see the opposite: PTG twice a year with a Forum 
after each release. And loop operators into PTGs more.




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




__
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] Switching to longer development cycles

[Dmitry Tantsur]

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 always a rush at the Feature Freeze point in a cycle to get things in, 
or they will be delayed for 6 months. With the year-long cycle, now anything 
missing Feature Freeze will be delayed by a year. The long cycle also means 
that a lot more time will be spent backporting things to the current release, 
since people won’t be able to wait a whole year for some improvements.

Maybe it’s just the dev in me, but I prefer shorter cycles (CD, anyone?).


Yes, I'll admit I'm struggling with that part of the proposal too. We
could use intermediary releases but there would always be a "more
important" release.

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 that the pressure is reduced now that
we are past the hype peak...



There was quite a pressure all past releases for us. I don't quite expect it to 
end, until people proposing features start being more realistic about timelines.


__
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] Switching to longer development cycles

[Kashyap Chamarthy]

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 around the
> corner, we lose too much time to events, and generally the impression
> that there is less time to get things done. Milestones in the
> development cycles are mostly useless now as they fly past us too fast.
> A lot of other people reported that same feeling.

Thanks for articulating it out loud.  FWIW, I share that same feeling to
an extent, especially as one of those people involved in mulitple
communities (the lower-layer components that OpenStack depends on) and
simply don't have the necessary bandwidth to keep up.

[...]

> In another thread, John Dickinson suggested that we move to one-year
> development cycles, and I've been thinking a lot about it. I now think
> it is actually the right way to reconcile our self-imposed rhythm with
> the current pace of development, and I would like us to consider
> switching to year-long development cycles for coordinated releases as
> soon as possible.
> 
> What it means:
> 
> - 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 per year
> - We'd have only one PTG with all teams each year

The above sounds reasonable to me.  

And it should (and will) reduce a lot of breathlessness and 'keeping the
pedal glued to the metal' feeling that comes from being unable to keep
up with things.  Not to mention, the OpenStack Foundation welcomes a bit
of breathing room from having to organize and coordinate so many events.

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, people would continue to organize informal meetups.  But
admittedly, this shifts the logistics apsect onto contributors -- that's
probably okay, many other contributor communities self-organize meetups.

[...]

> When ?

[...]

> So the year-long cycles would ideally start at the beginning of the
> year, when we would organize the yearly PTG. That said, I'm not sure we
> can really afford to keep the current rhythm for one more year before
> switching. That is why I'd like us to consider taking the plunge and
> just doing it for *Rocky*, and have a single PTG in 2018 (in Dublin).

Jumping right in sounds good.  Getting started immediately will also get
us to real world 'data' sooner, rather than dilly-dallying around.

[...]

> So... What do you think ?

I welcome this proposal.

-- 
/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

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

[Ana Krivokapic]

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 tripleo-validations project. The project would highly benefit from
> his
> > addition to the core reviewer team.
> >
> > Assuming that there are no objections, we will add Gaël to the core team
> > next week.
> >
> > Thanks!
> >
> > --
> > Regards,
> > Ana Krivokapic
> > Senior Software Engineer
> > OpenStack team
> > Red Hat Inc.
> >
> > 
> __
> > 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
>



-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat Inc.
__
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] Switching to longer development cycles

[Renat Akhmerov]

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
> solves it.

Yes, exactly.


Renat Akhmerov
@Nokia

__
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] Switching to longer development cycles

[Fred Li]

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
> Sydney). On the other hand some devs got together and hashed out some plans
> for their projects. Personally, I feel the PTG is not working if we also
> have summits – and having two summits and one PTG will make things worse.
> Therefore I propose to scrap the PTG and add “design summits” back to the
> OpenStack summit. As a side effect this will be a better on-ramp for casual
+1. If one of the purpose is to save developers' travel cost, this
idea works. Besides this, it is important for the developers to hear
voice from users/operators who attend the current summits.
> developers who can’t justify going to the PTG and ensure enough developers
> are on-hand to hear the operator’s feedback.
>
>
>
> German
>
>
>
> From: Tim Bell 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, December 13, 2017 at 10:15 AM
>
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: 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 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.
>
>
>
> If there is consensus, I’d suggest to get feedback from openstack-operators
> on the idea. My initial suspicion is that it would be welcomed, especially
> by those running from distros, but there are many different perspectives.
>
>
>
> Tim
>
>
>
> From: Amy Marrich 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, 13 December 2017 at 18:58
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: 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 and if it's planned for in the individual projects they can have an
> earlier 'end' to allow for members not being around.
>
>
>
> The one year release would help to get 'new' users to adopt a more recent
> release, even if it's the one from the year previously as there is the
> 'confidence' that it's been around for a bit and been used by others in
> production. And if projects want to do incrementals they can, if I've read
> the thread correctly. Also those that want the latest will just use master
> anyways as some do currently.
>
>
>
> With the move to a yearly cycle I agree with the 1 year cycle for PTLs,
> though if needed perhaps a way to have a co-PTL or a LT could be implemented
> to help with the longer duties?
>
>
>
> My 2 cents from the peanut gallery:)
>
>
>
> Amy (spotz)
>
>
>
> On Wed, Dec 13, 2017 at 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 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 often.
>> >>
>> > The PTG seems to allow greater coordination between groups. I worry that
>> > going back to an optional mid-cycle would reduce this
>> > cross-collaboration,
>> > while also reducing project face-to-face time.
>>
>>
>> I can't speak for the Foundation, but I would think it would be good to
>> have an official PTG in the middle of the cycle (perhaps neatly aligned
>> with some kind of milestone/event) that lets people discuss plans for
>> finishing off the release, and early work they want to get started on for
>> the subsequent release). The problem with team-organised midcycles (as I'm
>> sure everyone remembers), is that there's little/no opportunity for
>> cross-project work.
>>
>> --
>> Cheers,
>>
>> Chris
>
> This was one of my 

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

[Julien Danjou]

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 core reviewers, so I think
> reducing expectations and slowing down the pace could help there.

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
solves it.

-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


signature.asc
Description: PGP signature
__
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] [ceilometer] about add transformer into libvirt

[Jaze Lee]

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,
>> transform it. Then we can scale notification agent and do not have
>> flapping sample problems
>
> 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


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

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

[Thierry Carrez]

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
>> development. I know people who can spend 100% of their time upstream can
>> cope with our current rhythm. I just observe that we have less and less
>> of those full-time people and need to attract more of the part-time one.
>>
>> If this proposal is not helping developers and making OpenStack
>> development less painful, I don't think we should do it:)
> 
> Given I have the luxury of working mostly full time upstream, I've
> obviously got a skewed perspective on this whole discussion.
> 
> I am interested in which part time developers are having issues keeping
> up and how, i.e. are these core team members that don't feel they can be
> good core reviewers if they aren't around enough to keep up with the
> changes that are happening? I could definitely see a case like that with
> some of the complicated stuff going on in nova like the placement and
> cells v2 work.

There was two kind of feedback.

- 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 core reviewers, so I think
reducing expectations and slowing down the pace could help there.

- People in projects that are more mature (or packaging projects) where
the process overhead (coordinated releases, elections, PTG
preparation...) ends up representing a significant chunk of the work.
For those it felt like longer cycles would reduce that overhead and give
them more time to do real work.

> If we're talking about part time contributors that are contributing bug
> fixes here and there, docs patches, random reviews, I'm not sure how
> this is substantially better for them.

No, I'm more talking about someone who can dedicate one day per week to
OpenStack development, and who currently struggle to be part of a team
where everyone has to be >80% to keep up with the rhythm.

> We've said in this thread that project teams are encouraged to still do
> intermediate releases, often. And we're still going to be working on
> features, so how does that help slow things down for the part time
> contributor?

My hope is that by reducing the "coordinated release" pressure, we'd
encourage project teams to adopt a rhythm that is more natural for them.
Some teams would still be pretty active with lots of intermediary
releases, while some others would have an easier time.

> If *everyone* must slow down then that's going to be a problem I think,
> unless we do something like alternating intermediate releases where
> there are new features and then only bug fixes, something like that - up
> to the discretion of each project team as they see fit.
> 
> I haven't seen anyone mention this yet either, but if "slowing down"
> begins to look like we're entering maintenance mode, I don't think
> that's going to attract new developers and it's likely to mean long-time
> key maintainers are going to lose interest and start looking elsewhere
> to scratch their itches. It's hard to say what would happen. I can
> certainly keep myself busy with docs patches and bug fixes until the
> cows come home.

All good points.

It feels like we have to dive deeper into the consequences in terms of
release cadence (intermediary/coordinated) and in terms of stable branch
maintenance before we can make a call.

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

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

[Thomas Goirand]

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 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] [networking-ovn] [tripleo] enable open ptcp communication to NB and SB databases

[pranab boruah]

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 open tcp based communication.

I have couple of follow-up questions:

1. Is the open TCP(no SSL) based mechanism enabled by default in
TripleO ? Or we have to set a config parameter for using open TCP ?
2. In actual production deployments, is open TCP used instead of SSL?

Thanks,
Pranab

__
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] [ceilometer] about add transformer into libvirt

[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,
> transform it. Then we can scale notification agent and do not have
> flapping sample problems

The plan is to actually make the TSDB (Gnocchi) do that job for us.

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: PGP signature
__
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] Switching to longer development cycles

[Thierry Carrez]

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 one.
> 
> 2) ​Keep the support cycle to a year
>     This would basically mean that as soon as there is a new release, the
>     previous one would become EOL ? This is what seems suggested here
>     and I'm really not confident this would be a great idea. It would force
>     people to upgrade within weeks after a new release to stay on a
> supported version.

There is also the intermediary solution, where branches would be
supported for 15 or 18 months, giving a 3-month or 6-month overlap.

> As some others have mentioned in the thread, there are pros and cons to
> moving to a
> year-long cycle and I think it's great that we are having this
> discussion as it will help
> us make an informed decision.

Yes! The proposal is really based on partial feedback I received, which
is why I think we should have this discussion publicly to explore the
consequences and decide how much of a good idea it would be (or not).

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

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

[Jaze Lee]

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 companies is
just maintained, not develop forward.
No attractive feature is include in.
One reason is the IaaS does not need too much feature. If the vm is
ok, and can be
connected, It is ok. Let other people to develop it.
One reason is as public cloud goes popular, users have multiple
choices. Openstack is just one, and the less attractive one.
Only the company do not want, or not  allowed, to use public  cloud
may be want to use Openstack.
One reason is the time changed, right now every body talks about AI. I
attend one storage reference, all people talks about AI,
 they said, we will make storage more intelligent, if we do not do
this, we will be eliminated.

May be we should give new mission to Openstack to refresh it ?
Thanks a lot again.

2017-12-14 15:39 GMT+08:00 Blair Bethwaite :
> 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
> https://trello.com/b/9fkuT1eU/nectar-openstack-versions for the current
> version snapshot.
>
> On 14 Dec. 2017 18:00, "Clint Byrum"  wrote:
>>
>> 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 much about doing the whole integrated release dance so often.
>> >
>> > Is there any data about how operators approach this currently? Nectar
>> > (and I presume other large and/or loosely coordinated OpenStack
>> > clouds) has been running different projects across multiple versions
>> > for quite a while, sometimes 3 or 4 different versions. Coordinating
>> > upgrades in a federated cloud with distributed operations requires
>> > that we do this, e.g., our current Nova Newton upgrade has probably
>> > been in-train for a couple of months now.
>> >
>>
>> That's interesting. Can you share what you mean by running 3 or 4
>> different versions?
>>
>> Do you mean you mix versions in a single region, like, Pike keystone,
>> Ocata Nova, and Newton Neutron? Or do you mean you might have a region
>> running Pike, and another running Ocata, and another running Newton?
>>
>> __
>> 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