Re: [openstack-dev] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Masayuki Igawa]

Hi,

Thank you so much for your warm comments/links/etc,etc!
I'll check them and start to write a proposal for the goal for Rocky
early next week.

-- Masayuki


On 01/11, Emilien Macchi wrote:
> Sorry I forgot an important action: propose the goal for Rocky :-)
> 
> An example with https://review.openstack.org/#/c/532361/ (from Sean).
> 
> Thanks,
> 
> On Thu, Jan 11, 2018 at 9:29 PM, Emilien Macchi  wrote:
> > On Thu, Jan 11, 2018 at 7:13 PM, Masayuki Igawa
> >  wrote:
> >> Hi Emilien,
> >>
> >> I'd love to take this role!
> >
> > Wow, this is AWESOME.
> >
> >> I have some tempest experience but not QA work which you mentioned
> >> (devstack, grenade, zuul layout) that much. However, I think it will
> >> be a very good opportunity to step-up.
> >>
> >> So, for me, the next step might be to know grenade / upgrade jobs /
> >> plugin mechanizm deeply. And I suppose we need some documentation
> >> about "how to support upgrade" based on the requirements for the other
> >> projects (and me :).
> >>
> >> Any suggestion and/or comments are welcome!
> >
> > OK so the steps are documented here:
> > https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
> >
> > So first of all, it only affects projects that are "services" (e.g. Tacker).
> > The main requirement is to have grenade scripts in-tree for the
> > projects which miss the tag now.
> > Look at Ironic which already has the tag:
> > https://github.com/openstack/ironic/tree/master/devstack/upgrade
> >
> > At the same time, we need to change the zuul layout for the projects
> > which don't have the tag yet.
> > Still example with Ironic:
> > https://github.com/openstack/ironic/blob/master/zuul.d/project.yaml#L6-L7
> >
> > Once a project has a grenade job (voting) that runs Grenade with the
> > specs described here:
> > https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
> > - the project can apply to the tag and the goal is complete once the
> > tag is approved.
> >
> > I think the first step is to make sure each project which doesn't have
> > the tag has to understand what the tag means, in term of requirements.
> >
> > If they say:
> >
> > "Yeah, our project can already do that" (because they did some manual
> > testing etc): then the work is purely grenade/zuul-layout.
> >
> > "No, we don't support upgrades at all": then the goal might take one
> > or two cycles, depending on the amount of work.
> >
> > This is the list of service projects that don't have the tag yet:
> > aodh
> > blazar
> > cloudkitty
> > congress
> > dragonflow
> > ec2api
> > freezer
> > karbor
> > kuryr
> > masakari
> > mistral
> > monasca
> > murano
> > octavia
> > panko
> > searchlight
> > senlin
> > tacker
> > trove
> > vitrage
> > watcher
> > zaqar
> > zun
> >
> > (I might have miss some, please fix it).
> >
> > That's it for now, I hope it helped, please let us know if more questions.
> > Thanks again for stepping up and you have all our support at any time.
> >
> > [...]
> > --
> > Emilien Macchi
> 
> 
> 
> -- 
> Emilien Macchi
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 


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] [tc] Community Goals for Rocky

[Emilien Macchi]

On Thu, Jan 11, 2018 at 9:59 PM, ChangBo Guo  wrote:
> I would like to help the goal - enable mutable configuration, would like to
> post a patch for that later.

are you interested to be the "Champion" for this goal?

>
> 2018-01-10 2:37 GMT+08:00 Emilien Macchi :
>>
>> As promised, let's continue the discussion and move things forward.
>>
>> This morning Thierry brought the discussion during the TC office hour
>> (that I couldn't attend due to timezone):
>>
>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/latest.log.html#t2018-01-09T09:18:33
>>
>> Some outputs:
>>
>> - One goal has been proposed so far.
>>
>> Right now, we only have one goal proposal: Storyboard Migration. There
>> are some concerns about the ability to achieve this goal in 6 months.
>> At that point, we think it would be great to postpone the goal to S
>> cycle, continue the progress (kudos to Kendall) and fine other goals
>> for Rocky.
>>
>>
>> - We still have a good backlog of goals, we're just missing champions.
>>
>> https://etherpad.openstack.org/p/community-goals
>>
>> Chris brought up "pagination links in collection resources" in api-wg
>> guidelines theme. He said in the past this goal was more a "should"
>> than a "must".
>> Thierry mentioned privsep migration (done in Nova and Zun). (action,
>> ping mikal about it).
>> Thierry also brought up the version discovery (proposed by Monty).
>> Flavio proposed mutable configuration, which might be very useful for
>> operators.
>> He also mentioned that IPv6 support goal shouldn't be that far from
>> done, but we're currently lacking in CI jobs that test IPv6
>> deployments (question for infra/QA, can we maybe document the gap so
>> we can run some gate jobs on ipv6 ?)
>> (personal note on that one, since TripleO & Puppet OpenStack CI
>> already have IPv6 jobs, we can indeed be confident that it shouldn't
>> be that hard to complete this goal in 6 months, I guess the work needs
>> to happen in the projects layouts).
>> Another interesting goal proposed by Thierry, also useful for
>> operators, is to move more projects to assert:supports-upgrade tag.
>> Thierry said we are probably not that far from this goal, but the
>> major lack is in testing.
>> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
>> of projects don't use it anymore already).
>>
>> With that said, let's continue the discussion on these goals, see
>> which ones can be actionable and find champions.
>>
>> - Flavio asked how would it be perceived if one cycle wouldn't have at
>> least one community goal.
>>
>> Thierry said we could introduce multi-cycle goals (Storyboard might be
>> a good candidate).
>> Chris and Thierry thought that it would be a bad sign for our
>> community to not have community goals during a cycle, "loss of
>> momentum" eventually.
>>
>>
>> Thanks for reading so far,
>>
>> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi 
>> wrote:
>> > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi 
>> > wrote:
>> > [...]
>> >> Suggestions are welcome:
>> >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
>> >> goal XYZ for Rocky
>> >> - on Gerrit in openstack/governance like Kendall did.
>> >
>> > Just a fresh reminder about Rocky goals.
>> > A few questions that we can ask ourselves:
>> >
>> > 1) What common challenges do we have?
>> >
>> > e.g. Some projects don't have mutable configuration or some projects
>> > aren't tested against IPv6 clouds, etc.
>> >
>> > 2) Who is willing to drive a community goal (a.k.a. Champion)?
>> >
>> > note: a Champion is someone who volunteer to drive the goal, but
>> > doesn't commit to write the code necessarily. The Champion will
>> > communicate with projects PTLs about the goal, and make the liaison if
>> > needed.
>> >
>> > The list of ideas for Community Goals is documented here:
>> > https://etherpad.openstack.org/p/community-goals
>> >
>> > Please be involved and propose some ideas, I'm sure our community has
>> > some common goals, right ? :-)
>> > Thanks, and happy holidays. I'll follow-up in January of next year.
>> > --
>> > Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List 

Re: [openstack-dev] [all] [tc] Community Goals for Rocky

[ChangBo Guo]

I would like to help the goal - enable mutable configuration, would like to
post a patch for that later.

2018-01-10 2:37 GMT+08:00 Emilien Macchi :

> As promised, let's continue the discussion and move things forward.
>
> This morning Thierry brought the discussion during the TC office hour
> (that I couldn't attend due to timezone):
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/
> latest.log.html#t2018-01-09T09:18:33
>
> Some outputs:
>
> - One goal has been proposed so far.
>
> Right now, we only have one goal proposal: Storyboard Migration. There
> are some concerns about the ability to achieve this goal in 6 months.
> At that point, we think it would be great to postpone the goal to S
> cycle, continue the progress (kudos to Kendall) and fine other goals
> for Rocky.
>
>
> - We still have a good backlog of goals, we're just missing champions.
>
> https://etherpad.openstack.org/p/community-goals
>
> Chris brought up "pagination links in collection resources" in api-wg
> guidelines theme. He said in the past this goal was more a "should"
> than a "must".
> Thierry mentioned privsep migration (done in Nova and Zun). (action,
> ping mikal about it).
> Thierry also brought up the version discovery (proposed by Monty).
> Flavio proposed mutable configuration, which might be very useful for
> operators.
> He also mentioned that IPv6 support goal shouldn't be that far from
> done, but we're currently lacking in CI jobs that test IPv6
> deployments (question for infra/QA, can we maybe document the gap so
> we can run some gate jobs on ipv6 ?)
> (personal note on that one, since TripleO & Puppet OpenStack CI
> already have IPv6 jobs, we can indeed be confident that it shouldn't
> be that hard to complete this goal in 6 months, I guess the work needs
> to happen in the projects layouts).
> Another interesting goal proposed by Thierry, also useful for
> operators, is to move more projects to assert:supports-upgrade tag.
> Thierry said we are probably not that far from this goal, but the
> major lack is in testing.
> Finally, another "simple" goal is to remove mox/mox3 (Flavio said most
> of projects don't use it anymore already).
>
> With that said, let's continue the discussion on these goals, see
> which ones can be actionable and find champions.
>
> - Flavio asked how would it be perceived if one cycle wouldn't have at
> least one community goal.
>
> Thierry said we could introduce multi-cycle goals (Storyboard might be
> a good candidate).
> Chris and Thierry thought that it would be a bad sign for our
> community to not have community goals during a cycle, "loss of
> momentum" eventually.
>
>
> Thanks for reading so far,
>
> On Fri, Dec 15, 2017 at 9:07 AM, Emilien Macchi 
> wrote:
> > On Tue, Nov 28, 2017 at 2:22 PM, Emilien Macchi 
> wrote:
> > [...]
> >> Suggestions are welcome:
> >> - on the mailing-list, in a new thread per goal [all] [tc] Proposing
> >> goal XYZ for Rocky
> >> - on Gerrit in openstack/governance like Kendall did.
> >
> > Just a fresh reminder about Rocky goals.
> > A few questions that we can ask ourselves:
> >
> > 1) What common challenges do we have?
> >
> > e.g. Some projects don't have mutable configuration or some projects
> > aren't tested against IPv6 clouds, etc.
> >
> > 2) Who is willing to drive a community goal (a.k.a. Champion)?
> >
> > note: a Champion is someone who volunteer to drive the goal, but
> > doesn't commit to write the code necessarily. The Champion will
> > communicate with projects PTLs about the goal, and make the liaison if
> > needed.
> >
> > The list of ideas for Community Goals is documented here:
> > https://etherpad.openstack.org/p/community-goals
> >
> > Please be involved and propose some ideas, I'm sure our community has
> > some common goals, right ? :-)
> > Thanks, and happy holidays. I'll follow-up in January of next year.
> > --
> > Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Emilien Macchi]

Sorry I forgot an important action: propose the goal for Rocky :-)

An example with https://review.openstack.org/#/c/532361/ (from Sean).

Thanks,

On Thu, Jan 11, 2018 at 9:29 PM, Emilien Macchi  wrote:
> On Thu, Jan 11, 2018 at 7:13 PM, Masayuki Igawa
>  wrote:
>> Hi Emilien,
>>
>> I'd love to take this role!
>
> Wow, this is AWESOME.
>
>> I have some tempest experience but not QA work which you mentioned
>> (devstack, grenade, zuul layout) that much. However, I think it will
>> be a very good opportunity to step-up.
>>
>> So, for me, the next step might be to know grenade / upgrade jobs /
>> plugin mechanizm deeply. And I suppose we need some documentation
>> about "how to support upgrade" based on the requirements for the other
>> projects (and me :).
>>
>> Any suggestion and/or comments are welcome!
>
> OK so the steps are documented here:
> https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
>
> So first of all, it only affects projects that are "services" (e.g. Tacker).
> The main requirement is to have grenade scripts in-tree for the
> projects which miss the tag now.
> Look at Ironic which already has the tag:
> https://github.com/openstack/ironic/tree/master/devstack/upgrade
>
> At the same time, we need to change the zuul layout for the projects
> which don't have the tag yet.
> Still example with Ironic:
> https://github.com/openstack/ironic/blob/master/zuul.d/project.yaml#L6-L7
>
> Once a project has a grenade job (voting) that runs Grenade with the
> specs described here:
> https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
> - the project can apply to the tag and the goal is complete once the
> tag is approved.
>
> I think the first step is to make sure each project which doesn't have
> the tag has to understand what the tag means, in term of requirements.
>
> If they say:
>
> "Yeah, our project can already do that" (because they did some manual
> testing etc): then the work is purely grenade/zuul-layout.
>
> "No, we don't support upgrades at all": then the goal might take one
> or two cycles, depending on the amount of work.
>
> This is the list of service projects that don't have the tag yet:
> aodh
> blazar
> cloudkitty
> congress
> dragonflow
> ec2api
> freezer
> karbor
> kuryr
> masakari
> mistral
> monasca
> murano
> octavia
> panko
> searchlight
> senlin
> tacker
> trove
> vitrage
> watcher
> zaqar
> zun
>
> (I might have miss some, please fix it).
>
> That's it for now, I hope it helped, please let us know if more questions.
> Thanks again for stepping up and you have all our support at any time.
>
> [...]
> --
> Emilien Macchi



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

[gordon chung]

hey Dan,

On 2018-01-11 06:05 PM, Daniel Dyer wrote:
> My understanding was that the API is not officially deprecated until queens. 
> Is this not the case?

not quite. we removed the API permanently in queens. it was actually 
deprecated back in 2016[1] officially. we've unofficially/transparently 
been telling people to switch to Gnocchi (or whatever target you want to 
put into publisher) for longer than that as the legacy api/storage 
hasn't been touched meaningfully since 2015.

given the realities of the project and OpenStack, our project was just 
more proactive in culling stale and/or unusable code.

as it stands, ceilometer solely generates/normalises data about 
openstack resources and publishes data to consumers. other services are 
required to leverage and add value to the data.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105042.html

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] [ceilometer] Retiring ceilometerclient

[Emilien Macchi]

On Thu, Jan 11, 2018 at 3:05 PM, Daniel Dyer  wrote:
> My understanding was that the API is not officially deprecated until queens. 
> Is this not the case?

https://docs.openstack.org/releasenotes/ceilometer/ocata.html#deprecation-notes
https://docs.openstack.org/releasenotes/ceilometer/unreleased.html#upgrade-notes
(queens)

Ceilometer API was deprecated in Ocata and removed in Queens.
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Emilien Macchi]

On Thu, Jan 11, 2018 at 7:13 PM, Masayuki Igawa
 wrote:
> Hi Emilien,
>
> I'd love to take this role!

Wow, this is AWESOME.

> I have some tempest experience but not QA work which you mentioned
> (devstack, grenade, zuul layout) that much. However, I think it will
> be a very good opportunity to step-up.
>
> So, for me, the next step might be to know grenade / upgrade jobs /
> plugin mechanizm deeply. And I suppose we need some documentation
> about "how to support upgrade" based on the requirements for the other
> projects (and me :).
>
> Any suggestion and/or comments are welcome!

OK so the steps are documented here:
https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements

So first of all, it only affects projects that are "services" (e.g. Tacker).
The main requirement is to have grenade scripts in-tree for the
projects which miss the tag now.
Look at Ironic which already has the tag:
https://github.com/openstack/ironic/tree/master/devstack/upgrade

At the same time, we need to change the zuul layout for the projects
which don't have the tag yet.
Still example with Ironic:
https://github.com/openstack/ironic/blob/master/zuul.d/project.yaml#L6-L7

Once a project has a grenade job (voting) that runs Grenade with the
specs described here:
https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements
- the project can apply to the tag and the goal is complete once the
tag is approved.

I think the first step is to make sure each project which doesn't have
the tag has to understand what the tag means, in term of requirements.

If they say:

"Yeah, our project can already do that" (because they did some manual
testing etc): then the work is purely grenade/zuul-layout.

"No, we don't support upgrades at all": then the goal might take one
or two cycles, depending on the amount of work.

This is the list of service projects that don't have the tag yet:
aodh
blazar
cloudkitty
congress
dragonflow
ec2api
freezer
karbor
kuryr
masakari
mistral
monasca
murano
octavia
panko
searchlight
senlin
tacker
trove
vitrage
watcher
zaqar
zun

(I might have miss some, please fix it).

That's it for now, I hope it helped, please let us know if more questions.
Thanks again for stepping up and you have all our support at any time.

[...]
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa][requirements] CentOS libvirt versus newton/ocata libvirt-python

[Ian Wienand]

On 01/12/2018 02:53 PM, Matthew Thode wrote:

First, about newton, it's dead (2017-10-11).


Yeah, there were a few opt-outs, which is why I think devstack still
runs it.  Not worth a lot of effort.


Next, about ocata, it looks like it can support newer libvirt, but
just because a distro updated a library doesn't mean we have to
update.  IIRC, for ubuntu they use cloud-archives to get the right
version of libvirt, does something like that exist for
centos/redhat?


Well cloud-archives is ports of more recent things backwards, whereas
I think we're in a situation of having too recent libraries in the
base platform.  The CentOS 7.3 v 7.4 situation is a little more subtle
than Trusty v Xenial, say, but fundamentally the same I guess.  The
answer may be "Ocata not supported on 7.4".

p.s. I hope I'm understanding the python-libvirt compat story
correctly.  AIUI any newer python-binding release will build against
older versions of libvirt.  But an old version of python-libvirt may
not build against a newer release of the C libraries?

-i

__
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] [qa][requirements] CentOS libvirt versus newton/ocata libvirt-python

[Matthew Thode]

On 18-01-12 12:42:49, Ian Wienand wrote:
> Hi,
> 
> So I guess since CentOS included libvirt 3.2 (7-1708, or around RHEL
> 7.4), it's been incompatible with libvirt-python requirements of 2.1.0
> in newton [1] and 2.5.0 in ocata [2] (pike, at 3.5.0, works).
> 
> Do we want to do anything about this?  I can think of several options
> 
> * bump the libvirt-python versions on older branches
> 
> * Create an older centos image (can't imagine we have the person
>   bandwidth to maintain this)
> 
> * Hack something in devstack (seems rather pointless to test
>   something so far outside deployments).
> 
> * Turn off CentOS testing for old devstack branches
> 
> None are particularly appealing...
> 
> (I'm sorry if this has been discussed, I have great déjà vu about it,
> maybe we were talking about it at summit or something).
> 

I thought I remembered something about it, but couldn't find it in the
archives.  First, about newton, it's dead (2017-10-11).  Next, about ocata,
it looks like it can support newer libvirt, but just because a distro
updated a library doesn't mean we have to update.  IIRC, for ubuntu they
use cloud-archives to get the right version of libvirt, does something
like that exist for centos/redhat?

-- 
Matthew Thode (prometheanfire)


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] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Masayuki Igawa]

Hi Emilien,

I'd love to take this role!
I have some tempest experience but not QA work which you mentioned
(devstack, grenade, zuul layout) that much. However, I think it will
be a very good opportunity to step-up.

So, for me, the next step might be to know grenade / upgrade jobs /
plugin mechanizm deeply. And I suppose we need some documentation
about "how to support upgrade" based on the requirements for the other
projects (and me :).

Any suggestion and/or comments are welcome!

-- Masayuki


On 01/11, Emilien Macchi wrote:
> Some projects are still not testing cold upgrades and therefore don't
> have the "supports-upgrade" tag.
> 
> https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html
> 
> This goal would mostly benefit the operators community as we would
> continue to ensure OpenStack can be upgraded and it's something that
> we actually test in the gate.
> In term of actions, we would need to run grenade / upgrade jobs for
> the projects which don't have this tag yet, so it's mostly QA work
> (devstack, grenade, zuul layout).
> 
> We're now looking for someone willing to lead this effort. Someone
> with a little bit of experience on QA and upgrades would work.
> However, our community is strong and we always help each others so no
> big deal if someone volunteers without all knowledge.
> A Champion is someone who coordinates the work to make a goal happen,
> and not supposed to do all the work. The Champion gets support from
> the whole community at any time.
> 
> Please step-up if you're willing to take this role!
> 
> Thanks,
> -- 
> Emilien Macchi
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [qa][requirements] CentOS libvirt versus newton/ocata libvirt-python

[Ian Wienand]

Hi,

So I guess since CentOS included libvirt 3.2 (7-1708, or around RHEL
7.4), it's been incompatible with libvirt-python requirements of 2.1.0
in newton [1] and 2.5.0 in ocata [2] (pike, at 3.5.0, works).

Do we want to do anything about this?  I can think of several options

* bump the libvirt-python versions on older branches

* Create an older centos image (can't imagine we have the person
  bandwidth to maintain this)

* Hack something in devstack (seems rather pointless to test
  something so far outside deployments).

* Turn off CentOS testing for old devstack branches

None are particularly appealing...

(I'm sorry if this has been discussed, I have great déjà vu about it,
maybe we were talking about it at summit or something).

-i

[1] 
http://logs.openstack.org/48/531248/2/check/legacy-tempest-dsvm-neutron-full-centos-7/80fa903/logs/devstacklog.txt.gz#_2018-01-09_05_14_40_960
[2] 
http://logs.openstack.org/50/531250/2/check/legacy-tempest-dsvm-neutron-full-centos-7/1c711f5/logs/devstacklog.txt.gz#_2018-01-09_20_43_08_833

__
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] How to use libxml2 with tox

[Clark Boylan]

On Thu, Jan 11, 2018, at 1:52 PM, Kwan, Louie wrote:
> Would like to use libxml2 and having issues for tox.
> 
> What needs to be included in the requirements.txt file etc.
> 
> Any tip is much appreciated.

You likely need to make sure that libxml2 header packages are installed so that 
the python package can link against libxml2. On Debian and Ubuntu I think the 
package is libxml2-dev and is libxml2-devel on suse. This isn't something that 
you would add to your requirements.txt as it would be a system dependency. To 
get it installed on our test nodes you can add it to the project's bindep.txt 
file.

Hope this helps,
Clark

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

[Daniel Dyer]

Gordon,

My understanding was that the API is not officially deprecated until queens. Is 
this not the case?

Dan

> On Jan 11, 2018, at 7:05 AM, gordon chung  wrote:
> 
> 
> 
> On 2018-01-11 01:48 AM, Thomas Bechtold wrote:
>> 
>> It was at lease for openSUSE: 
>> https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer
> 
> ah, maybe just centos then... or i'm not searching the correct place. :)
> 
> 
> -- 
> 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][tc] Clarifying testing recommendation for interop programs

[Matt Riedemann]

On 1/11/2018 10:36 AM, Colleen Murphy wrote:

1) All trademark-related tests should go in the tempest repo, in accordance
with the original resolution. This would mean that even projects that have
never had tests in tempest would now have to add at least some of their
black-box tests to tempest.

The value of this option is that centralizes tests used for the Interop program
in a location where interop-minded folks from the QA team can control them. The
downside is that projects that so far have avoided having a dependency on
tempest will now lose some control over the black-box tests that they use for
functional and integration that would now also be used for trademark
certification.
There's also concern for the review bandwidth of the QA team - we can't expect
the QA team to be continually responsible for an ever-growing list of projects
and their trademark tests.


How many tests are we talking about for designate and heat? Half a 
dozen? A dozen? More?


If it's just a couple of tests per project it doesn't seem terrible to 
have them live in Tempest so you get the "interop eye" on reviews, as 
noted in your email. If it's a considerable amount, then option 2 seems 
the best for the majority of parties.


--

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] Retirement of astara repos?

[Sean McGinnis]

On Thu, Jan 11, 2018 at 04:55:03PM -0500, Mark McClain wrote:
> Sean, Andreas-
> 
> Sorry I missed Andres’ message earlier in December about retiring astara. 
> Everyone is correct that development stopped a good while ago.  We attempted 
> in Barcelona to find others in the community to take over the day-to-day 
> management of the project. Unfortunately, nothing sustained resulted from 
> that session. 
> 
> I’ve intentionally delayed archiving the repos because of background 
> conversations around restarting active development for some pieces bubble up 
> from time-to-time.  I’ll contact those I know were interested and try for a 
> resolution to propose before the PTG.
> 
> mark

Great - yeah, no rush on this. I was just looking at things that could be
cleaned up, but it's just been general housekeeping. We can wait and see how
things go.

Thanks!
Sean


__
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] Retirement of astara repos?

[Mark McClain]

Sean, Andreas-

Sorry I missed Andres’ message earlier in December about retiring astara. 
Everyone is correct that development stopped a good while ago.  We attempted in 
Barcelona to find others in the community to take over the day-to-day 
management of the project. Unfortunately, nothing sustained resulted from that 
session. 

I’ve intentionally delayed archiving the repos because of background 
conversations around restarting active development for some pieces bubble up 
from time-to-time.  I’ll contact those I know were interested and try for a 
resolution to propose before the PTG.

mark

> On Jan 10, 2018, at 5:20 PM, Sean McGinnis  wrote:
> 
> While going through various repos looking at things to be cleaned up, I 
> noticed the last commit for openstack/astara
> was well over a year ago. Based on this and the little bit I have followed 
> with this project, it’s my understanding that
> there is no further work planned with Astara.
> 
> Should these repos be retired at this point? Or is there a reason to keep 
> things around?
> 
> 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

[openstack-dev] [all] How to use libxml2 with tox

[Kwan, Louie]

Would like to use libxml2 and having issues for tox.

What needs to be included in the requirements.txt file etc.

Any tip is much appreciated.

Thanks.
Louie
__
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] [Release-job-failures] release-post job for openstack/releases failed

[Sean McGinnis]

On Thu, Jan 11, 2018 at 09:08:38PM +, z...@openstack.org wrote:
> Build failed.
> 
> - tag-releases 
> http://logs.openstack.org/a5/a52aa0b2ad06a52e50be8879f9256576ceceb91c/release-post/tag-releases/fecf776/
>  : SUCCESS in 3m 53s
> - publish-static 
> http://logs.openstack.org/a5/a52aa0b2ad06a52e50be8879f9256576ceceb91c/release-post/publish-static/cee3a5f/
>  : POST_FAILURE in 5m 06s
> 

Already discussed a little with fungi and team, but to make sure it's captured
here, failed on an rsync error. A test of ssh'ing into the server succeeded, so
may be a transient failure.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Working toward Queens feature freeze and RC1

[William M Edmonds]

> From: William M Edmonds/Raleigh/IBM
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> 
> Date: 01/08/2018 03:11 PM
> Subject: Re: [openstack-dev] [nova] Working toward Queens feature
> freeze and RC1
>
> > From: Matt Riedemann 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 01/03/2018 07:03 PM
> > Subject: [openstack-dev] [nova] Working toward Queens feature freeze
and RC1
> >
> ... snip ...
> > The rest of the blueprints are tracked here:
> >
> > https://etherpad.openstack.org/p/nova-queens-blueprint-status
>
> I updated that etherpad with the latest status for the powervm
> blueprint. Should have 2 of the 3 remaining patches ready for review
> in the next day or two, and the last later in the week.

All of the powervm patches are ready for core reviews, and the etherpad has
been updated accordingly. Thanks in advance!
__
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] Retirement of astara repos?

[sean roberts]

It’s my understanding that the development has been moved back into
DreamHost. I stopped working on it over two years ago. I’ll ping them to
double check that repo retiring is what they want.

Thanks for asking first!

On Wed, Jan 10, 2018 at 21:56 Swapnil Kulkarni  wrote:

> On Thu, Jan 11, 2018 at 3:50 AM, Sean McGinnis 
> wrote:
> > While going through various repos looking at things to be cleaned up, I
> noticed the last commit for openstack/astara
> > was well over a year ago. Based on this and the little bit I have
> followed with this project, it’s my understanding that
> > there is no further work planned with Astara.
> >
> > Should these repos be retired at this point? Or is there a reason to
> keep things around?
> >
> > 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
>
>
> Sean,
>
> There have been a set of e-mails from Andreas in Dec for the inactive
> projects [1] [2] [3] [4] with less or no responce. Just FYI.
>
> [1] Astara:
> http://lists.openstack.org/pipermail/openstack-dev/2017-December/125350.html
> [2] Cerberor:
> http://lists.openstack.org/pipermail/openstack-dev/2017-December/125351.html
> [3] Evoque:
> http://lists.openstack.org/pipermail/openstack-dev/2017-December/125352.html
> [4] puppet-apps-site:
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-December/125360.html
>
> ~coolsvap
>
> __
> 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
>
-- 
~sean
__
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] [qa] [tc] Need champion for "cold upgrades capabilities" goal

[Emilien Macchi]

Some projects are still not testing cold upgrades and therefore don't
have the "supports-upgrade" tag.

https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html

This goal would mostly benefit the operators community as we would
continue to ensure OpenStack can be upgraded and it's something that
we actually test in the gate.
In term of actions, we would need to run grenade / upgrade jobs for
the projects which don't have this tag yet, so it's mostly QA work
(devstack, grenade, zuul layout).

We're now looking for someone willing to lead this effort. Someone
with a little bit of experience on QA and upgrades would work.
However, our community is strong and we always help each others so no
big deal if someone volunteers without all knowledge.
A Champion is someone who coordinates the work to make a goal happen,
and not supposed to do all the work. The Champion gets support from
the whole community at any time.

Please step-up if you're willing to take this role!

Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

[Doug Hellmann]

Excerpts from Saverio Proto's message of 2018-01-11 15:23:46 +0100:
> Hello,
> 
> we recently enabled the JSON logging to feed a Kibana dashboard and look
> at the logs with modern tooling.
> 
> however it looks like in our Openstack Newton deployment that some
> information in the JSON files is missing.
> 
> most important missing bit is the request-id, that we use to track an
> event across multiple log files on multiple hosts.
> 
> Looking at the code it really looks like the request ID is there for the
> context formatter and not for the json formatter.
> 
> https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L208
> 
> https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L460
> 
> I am an operator and a very bad python developer, so can anyone confirm
> that is really missing in the code, and it is not me configuring stuff
> wrongly ?
> 
> If it is really missing the request-id in the json log formatter, should
> I open a bug about this ?
> 
> thank you
> 
> Saverio
> 

The newton version of the JSONFormatter adds all of the values from the
context to the log record:

http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=newton-eol#n142

That should include the request_id.

Which service's logs are missing the request_id?

Chaining request_id values from one service to the next was a separate
piece of work, and I don't remember off the top of my head when that was
added. Perhaps someone else can. I think Sean Dague drove a lot of that
work.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

Greetings OpenStack community,

Wide-ranging conversations in the API-SIG meeting today [7]. We started out 
discussing techniques for driving the adoption of the guidelines published by 
the group. Two ideas received most of the attention:

* Provide guidance on the tools available to make it easier to align new API 
projects with the guidelines, from the outset. The idea of an example or 
cookbook project was mooted, but the number of options, variables, and opinions 
that such an effort would face killed this idea. Better, perhaps, are recommend 
tools for addressing common problems.

* Making use of the OpenStack-wide goals [8] process to encourage working 
towards consistency. Monty has made a proposal [9] based on the rfc5988 link 
guidance newly listed below.

Then we talked about work in progress to establish a common health check system 
across the OpenStack services. There's an oslo-spec [10] in progress. The 
API-SIG's involvement is to help make sure the HTTP side of things is handled 
well.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

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

* Expand note about rfc5988 link header
  https://review.openstack.org/#/c/531914/

# Guidelines Currently Under Review [3]

* Add guideline on exposing microversions in SDKs
  https://review.openstack.org/#/c/532814/

* 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://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-01-11-15.59.html
[8] https://governance.openstack.org/tc/goals/index.html
[9] https://review.openstack.org/#/c/532627/
[10] https://review.openstack.org/#/c/531456/

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

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

[openstack-dev] [release] Release countdown for week R-6, January 13 - 19

[Sean McGinnis]

Development Focus
-

Teams should be focused on implementing planned work. Work should be wrapping
up on non-client libraries to meet the lib deadline Thursday, the 18th.

General Information
---

We are now getting close to the end of the cycle. The non-client library
(typically any lib other than the "python-$PROJECTclient" deliverables)
deadline is 18 January, followed quickly the next Thursday with the final
client library release. Releases for critical fixes will be allowed after this
point, but we will be much more restrictive about what is allowed if there are
more lib release requests after this point. Please keep this in mind.

When requesting these library releases, you should also include the stable
branching request with the review (as an example, see the "branches" section
here:

http://git.openstack.org/cgit/openstack/releases/tree/deliverables/pike/os-brick.yaml#n2)


Upcoming Deadlines & Dates
--

Final non-client library release deadline: January 18
Final client library release deadline: January 25
Queens-3 Milestone: January 25
Start of Rocky PTL nominations: January 29
Start of Rocky PTL election: February 7
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

[openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Colleen Murphy]

Hi everyone,

We have governance review under debate[1] that we need the community's help on.
The debate is over what recommendation the TC should make to the Interop team
on where the tests it uses for the OpenStack trademark program should be
located, specifically those for the new add-on program being introduced. Let me
badly summarize:

A couple of years ago we issued a resolution[2] officially recommending that
the Interop team use solely tempest as its source of tests for capability
verification. The Interop team has always had the view that the developers,
being the people closest to the project they're creating, are the best people
to write tests verifying correct functionality, and so the Interop team doesn't
maintain its own test suite, instead selecting tests from those written in
coordination between the QA team and the other project teams. These tests are
used to validate clouds applying for the OpenStack Powered tag, and since all
of the projects included in the OpenStack Powered program already had tests in
tempest, this was a natural fit. When we consider adding new trademark programs
comprising of other projects, the test source is less obvious. Two examples are
designate, which has never had tests in the tempest repo, and heat, which
recently had its tests removed from the tempest repo.

So far the patch proposes three options:

1) All trademark-related tests should go in the tempest repo, in accordance
   with the original resolution. This would mean that even projects that have
   never had tests in tempest would now have to add at least some of their
   black-box tests to tempest.

The value of this option is that centralizes tests used for the Interop program
in a location where interop-minded folks from the QA team can control them. The
downside is that projects that so far have avoided having a dependency on
tempest will now lose some control over the black-box tests that they use for
functional and integration that would now also be used for trademark
certification.
There's also concern for the review bandwidth of the QA team - we can't expect
the QA team to be continually responsible for an ever-growing list of projects
and their trademark tests.

2) All trademark-related tests for *add-on projects* should be sourced from
   plugins external to tempest.

The value of this option is it allows project teams to retain control over
these tests. The potential problem with it is that individual project teams are
not necessarily reviewing test changes with an eye for interop concerns and so
could inadvertently change the behavior of the trademark-verification tools.

3) All trademark-related tests should go in a single separate tempest plugin.

This has the value of giving the QA and Interop teams control over
interop-related tests while also making clear the distinction between tests
used for trademark verification and tests used for CI. Matt's argument against
this is that there actually is very little distinction between those two cases,
and that a given test could have many different applications.

Other ideas that have been thrown around are:

* Maintaining a branch in the tempest repo that Interop tests are pulled from.

* Tagging Interop-related tests with decorators to make it clear that they need
  to be handled carefully.

At the heart of the issue is the perception that projects that keep their
integration tests within the tempest tree are somehow blessed, maybe by the QA
team or by the TC. It would be nice to try to clarify what technical
and political
reasons we have for why different projects have tests in different places -
review bandwidth of the QA team, ownership/control by the project teams,
technical interdependency between certain projects, or otherwise.

Ultimately, as Jeremy said in the comments on the resolution patch, the
recommendation should be one that works best for the QA and Interop teams. So
far we've heard from Matt and Mark expressing moderate support for option 2.
We'd like to hear more from those teams about how they see this working,
especially with regard to concerns about the quality and stability standards
that out-of-tree tests may be held to. We additionally need input from the
whole community on how maintaining trademark-related tests in tempest will
affect you if you don't already have your tests there. We'd especially like to
address any perceptions of favoritism or exclusionism that stem from these
issues.

And to quickly clear up one detail before it makes it onto this thread, the
Queens Community Goal about splitting tempest plugins out of the main project's
tree[3] is entirely about addressing technical problems related to packaging for
existing tempest plugins, it's not a decree about what should live
within the tempest
repository nor does it have anything to do with the Interop program.

As I'm not deeply steeped in the history of either the Interop or QA teams I am
sure I've misrepresented some details here, I'm sorry about that. But 

[openstack-dev] [security] Security PTG Planning, x-project request for topics.

[Luke Hinds]

Hello All,

I am seeking topics for the PTG from all projects, as this will be where we
try out are new form of being a SIG.

For this PTG, we hope to facilitate more cross project collaboration topics
now that we are a SIG, so if your project has a security need / problem /
proposal than please do use the security SIG room where a larger audience
may be present to help solve problems and gain x-project consensus.

Please see our PTG planning pad [0] where I encourage you to add to the
topics.

[0] https://etherpad.openstack.org/p/security-ptg-rocky

-- 
Luke Hinds
Security Project PTL
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

[Saverio Proto]

Hello,

we recently enabled the JSON logging to feed a Kibana dashboard and look
at the logs with modern tooling.

however it looks like in our Openstack Newton deployment that some
information in the JSON files is missing.

most important missing bit is the request-id, that we use to track an
event across multiple log files on multiple hosts.

Looking at the code it really looks like the request ID is there for the
context formatter and not for the json formatter.

https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L208

https://github.com/openstack/oslo.log/blob/master/oslo_log/formatters.py#L460

I am an operator and a very bad python developer, so can anyone confirm
that is really missing in the code, and it is not me configuring stuff
wrongly ?

If it is really missing the request-id in the json log formatter, should
I open a bug about this ?

thank you

Saverio


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] Community Goals for Rocky -- privsep

[Thierry Carrez]

Emilien Macchi wrote:
> [...]
> Thierry mentioned privsep migration (done in Nova and Zun). (action,
> ping mikal about it).

It's not "done" in Nova: Mikal planned to migrate all of nova-compute
(arguably the largest service using rootwrap) to privsep during Queens,
but AFAICT it's still work in progress.

Other projects like cinder and neutron are using it.

If support in Nova is almost there, it would make a great Queens goal to
get rid of the last rootwrap leftovers and deprecate it.

Mikal: could you give us a quick update of where you are ?
Anyone interested in championing that as a goal?

-- 
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] [ceilometer] Retiring ceilometerclient

[gordon chung]

On 2018-01-11 01:48 AM, Thomas Bechtold wrote:
> 
> It was at lease for openSUSE: 
> https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer

ah, maybe just centos then... or i'm not searching the correct place. :)


-- 
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] [qa] [api] [all] use gabbi and tempest with just YAML

[Chris Dent]

On Thu, 4 Jan 2018, Chris Dent wrote:


The gabbi-tempest plugin is responsible for getting authentication
and service catalog information (using standard tempest calls) from
keystone and creating a suite of environment variables (such as
PLACEMENT_SERVICE and COMPUTE_BASE).

I have a sample file[5] that confirms resource provider and
allocation handling across the process of booting a single server.
It demonstrates some of the potential. Don't be too scared by the
noisy YAML anchors at the top, that's just an experiment to see what
can be done to manage URLs without having to know URLs.


I did a bit more work on this and wrote it up:

   https://anticdent.org/gabbi-tempest-experiment-1.html

--
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] [vitrage] rules in vitrage_aggregated_state()

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

From: "Yujun Zhang (ZTE)" 
Date: Thursday, 11 January 2018 at 10:52

I have almost understood it thanks to your explanation.

[Ifat] I liked the “almost” ;-)

The confusion is mainly caused by the naming. I guess the main reason is that 
the scope evolves but the naming is not updated with it.

For example
1.  `vitrage_aggregated_state` actually applies for both resource state and 
alarm severity as defined in `value_properties`. So `vitrage_aggregated_values` 
could be a better name.
[Ifat] For alarms we use ‘vitrage_aggregated_severity’
2.  For data source in static configuration, we may use `static.yaml` as a 
fallback. The name `default.yaml` will mislead user that it should be applied 
to data source configured in "types" but without a values configuration.
[Ifat] We should decide whether we want the default values to apply also to 
“real” datasources. I think the risk is that people who write a new datasource 
will forget to add the values yaml file, and will believe that everything works 
fine with the default. Then, upon a specific failure (that doesn’t happen 
often) they will get UNDEFINED status. On the other hand, if they always get 
UNDEFINED, they will remember to add the correct yaml file.
3.  The UNDEFINED value is named UNDEFINED_DATASOURCE = "undefined 
datasource", it is not a consistent type of severity and state enumeration.
[Ifat] I didn’t understand this comment.
4.  The behavior for data source defined in static without values 
configuration and data source defined in "types" without values configuration 
are inconsistent. The former will fallback to `default.yaml` but the latter 
will lead to undefined value.
[Ifat] See my answer to #2.
I know it is there for historical reasons and current developers may already 
get used to it, but it gives new contributors too many surprises.

What do you think? Shall we amend them?

On Tue, Jan 9, 2018 at 11:29 PM Afek, Ifat (Nokia - IL/Kfar Sava) 
> wrote:
Hi,

I agree that the code is confusing…

This is part of a change that was made in order to support default states for 
static entities. For example, in the static configuration yaml file you can add 
entities of types ‘switch’ and ‘br-ex’. In the past, in order to support states 
for these new types, you needed to add switch.yaml and br-ex.yaml under 
/etc/vitrage/datasources_values, which you would most likely copy from 
another datasource. Now, we have under /etc/vitrage/datasources_values a 
default.yaml file that is used for all static entities.

Back to the code, I believe this is the logic:


• If the datasource is part of ‘types’ (as defined in vitrage.conf) and 
has states configuration – use it. This is the normal behavior.

• If the datasource is not part of ‘types’, we understand that it was 
defined in a static configuration file. Use the default states configuration. I 
assume that it is somehow handled in the first part of the if statement (I’m 
not so familiar with that code)

• If neither is true – it means that the datasource is “real” and not 
static, and was defined in vitrage.conf types. And it also means that its 
states configuration is missing, so the state is UNDEFINED.

And to your questions:

1.  the data source is not defined -> the default states should be used
2.  data source defined but state config not exist -> UNDEFINED state
3.  data source defined, state config exist but the state is not found. -> 
I believe that somewhere in the first part of the if statement you will get 
UNDEFINED


Hope that’s more clear now. It might be a good idea to add some comments to 
that function…

Best Regards,
Ifat.


From: "Yujun Zhang (ZTE)" 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, 9 January 2018 at 8:34
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

Forgot to paste the link to the related code:

https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61



On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
> wrote:
Hi root causers

I have been inspecting the code about aggregated state recently and have a 
question regarding the rules.

The "not" operator in the if clause confuses me. If it is not a configured data 
source, how do we apply the aggregation rules? It seems this is handled in else 
clause.


if datasource_name in self.datasources_state_confs or \

datasource_name not in self.conf.datasources.types:
...

else:

Re: [openstack-dev] [vitrage] rules in vitrage_aggregated_state()

[Yujun Zhang (ZTE)]

I have almost understood it thanks to your explanation.

The confusion is mainly caused by the naming. I guess the main reason is
that the scope evolves but the naming is not updated with it.

For example

   1. `vitrage_aggregated_state` actually applies for both resource state
   and alarm severity as defined in `value_properties`. So
   `vitrage_aggregated_values` could be a better name.
   2. For data source in static configuration, we may use `static.yaml` as
   a fallback. The name `default.yaml` will mislead user that it should be
   applied to data source configured in "types" but without a values
   configuration.
   3. The UNDEFINED value is named UNDEFINED_DATASOURCE = "undefined
   datasource", it is not a consistent type of severity and state enumeration.
   4. The behavior for data source defined in static without values
   configuration and data source defined in "types" without values
   configuration are inconsistent. The former will fallback to `default.yaml`
   but the latter will lead to undefined value.

I know it is there for historical reasons and current developers may
already get used to it, but it gives new contributors too many surprises.

What do you think? Shall we amend them?

On Tue, Jan 9, 2018 at 11:29 PM Afek, Ifat (Nokia - IL/Kfar Sava) <
ifat.a...@nokia.com> wrote:

> Hi,
>
>
>
> I agree that the code is confusing…
>
>
>
> This is part of a change that was made in order to support default states
> for static entities. For example, in the static configuration yaml file you
> can add entities of types ‘switch’ and ‘br-ex’. In the past, in order to
> support states for these new types, you needed to add switch.yaml and
> br-ex.yaml under /etc/vitrage/datasources_values, which you would most
> likely copy from another datasource. Now, we have under
> /etc/vitrage/datasources_values a default.yaml file that is used for all
> static entities.
>
>
>
> Back to the code, I believe this is the logic:
>
>
>
> · If the datasource is part of ‘types’ (as defined in
> vitrage.conf) and has states configuration – use it. This is the normal
> behavior.
>
> · If the datasource is not part of ‘types’, we understand that it
> was defined in a static configuration file. Use the default states
> configuration. I assume that it is somehow handled in the first part of the
> if statement (I’m not so familiar with that code)
>
> · If neither is true – it means that the datasource is “real” and
> not static, and was defined in vitrage.conf types. And it also means that
> its states configuration is missing, so the state is UNDEFINED.
>
>
>
> And to your questions:
>
>
>
>1. the data source is not defined -> the default states should be used
>2. data source defined but state config not exist -> UNDEFINED state
>3. data source defined, state config exist but the state is not found.
>-> I believe that somewhere in the first part of the if statement you will
>get UNDEFINED
>
>
>
>
>
> Hope that’s more clear now. It might be a good idea to add some comments
> to that function…
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *"Yujun Zhang (ZTE)" 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, 9 January 2018 at 8:34
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [vitrage] rules in
> vitrage_aggregated_state()
>
>
>
> Forgot to paste the link to the related code:
>
>
>
>
> https://git.openstack.org/cgit/openstack/vitrage/tree/vitrage/entity_graph/mappings/datasource_info_mapper.py#n61
>
>
>
>
>
>
>
> On Tue, Jan 9, 2018 at 2:34 PM Yujun Zhang (ZTE) 
> wrote:
>
> Hi root causers
>
>
>
> I have been inspecting the code about aggregated state recently and have a
> question regarding the rules.
>
>
>
> The "not" operator in the if clause confuses me. If it is not a configured
> data source, how do we apply the aggregation rules? It seems this is
> handled in else clause.
>
>
>
> if datasource_name in self.datasources_state_confs or \
>
> datasource_name *not* in self.conf.datasources.types: 
>...
>
> else:
>
> self.category_normalizer[vitrage_category].set_aggregated_value(
>
> new_vertex, self.UNDEFINED_DATASOURCE)
>
> self.category_normalizer[vitrage_category].set_operational_value(
>
> new_vertex, self.UNDEFINED_DATASOURCE)
>
>
> There are some test case describing the expected behavior. But I couldn't 
> understand the design philosophy behind it. What is expected when
>
> 1.   the data source is not defined
>
> 2.   data source defined but state config not exist
>
> 3.   data source defined, state config exist but the state is not found.
>
> Could somebody shed some light on it?
>
>
>
>
>
> --
>
> Yujun Zhang
>
>
>
> --
>
> 

[openstack-dev] [publiccloud-wg]Rocky PTG Planning Etherpad

[Zhipeng Huang]

Hi Team,

I drafted an initial framework of the etherpad we could use for Rocky PTG
in Dublin. You are more than welcomed to provide input:
https://etherpad.openstack.org/p/publiccloud-wg-ptg-rocky

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [mogan] Transitioning PTL role to Li Tao

[Zhenguo Niu]

Hi team,

Due to my job responsibilities changed a while ago, I will transition the
PTL role to Li Tao.

If anyone has any concerns with this, please reach out to me.

-- 
Best Regards,
Zhenguo Niu
__
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