[openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

[Matthew Thode]

several projects have had problems with the new release, some have ways
of working around it, and some do not.  I'm sending this just to raise
the issue and allow a place to discuss solutions.

Currently there is a review proposed to blacklist 9.0.0, but if this is
going to still be an issue somehow in further releases we may need
another solution.

https://review.openstack.org/#/c/608835/

-- 
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] [tc] assigning new liaisons to projects

[Ghanshyam Mann]

  On Mon, 08 Oct 2018 23:27:06 +0900 Doug Hellmann  
wrote  
 > TC members,
 > 
 > Since we are starting a new term, and have several new members, we need
 > to decide how we want to rotate the liaisons attached to each our
 > project teams, SIGs, and working groups [1].
 > 
 > Last term we went through a period of volunteer sign-up and then I
 > randomly assigned folks to slots to fill out the roster evenly. During
 > the retrospective we talked a bit about how to ensure we had an
 > objective perspective for each team by not having PTLs sign up for their
 > own teams, but I don't think we settled on that as a hard rule.
 > 
 > I think the easiest and fairest (to new members) way to manage the list
 > will be to wipe it and follow the same process we did last time. If you
 > agree, I will update the page this week and we can start collecting
 > volunteers over the next week or so.

+1, sounds good to me.

-gmann

 > 
 > Doug
 > 
 > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
 > 
 > __
 > 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] [tc] assigning new liaisons to projects

[Julia Kreger]

On Mon, Oct 8, 2018 at 8:27 AM Doug Hellmann  wrote:

> TC members,
>
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
>
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
>
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
>
> Doug
>
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>
>
>
+1, Sounds good. I would just ask that if a TC is member has any
expectation on another member to post  a status update, that they
explicitly reach out and convey that expectation so we minimize confusion.
__
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] Stepping down from Release Management team

[Doug Hellmann]

Anne Bertucio  writes:

> Hi all,
>
> I have had a fantastic time getting to work on the Release Management
> team and getting to know you all through the release marketing work,
> however, it is time for me to step down from my role on the Release
> Management team as I am moving on from my role at the Foundation and
> will no longer be working on upstream OpenStack. I cannot thank you
> all enough for how you all welcomed me into the OpenStack community
> and for how much I have learned about open source development in my
> time here.
>
> If you have questions about cycle-highlights, swing by #openstack-release. 
> If you have questions about release marketing, contact lau...@openstack.org.
> For other inquiries, contact alli...@openstack.org. 
> While I won't be working upstream anymore, I'll only be a Tweet or IRC 
> message away. 
>
> Thank you again, and remember that cycle-highlights should be
> submitted by RC1.

Thank you for everything, Anne! The cycle-highlights system you helped
us create is a great example of using decentralization and peer review
at the same time. I'm sure it's going to continue to be an important
communication tool for the community.

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

Re: [openstack-dev] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

[Doug Hellmann]

Doug Hellmann  writes:

> Doug Hellmann  writes:
>
>> Doug Hellmann  writes:
>>
>>> Doug Hellmann  writes:
>>
>>> I have filed requests with the maintainers of PyPI to claim the names
>>> "keystone" and "congress". That may take some time. Please let me know
>>> if you're willing to simply use "openstack-keystone" and
>>> "openstack-congress" instead. I will take care of configuring PyPI and
>>> proposing the patch to update your setup.cfg (that way you can approve
>>> the change).
>>>
>>> * https://github.com/pypa/warehouse/issues/4770
>>> * https://github.com/pypa/warehouse/issues/4771
>
> We haven't heard back about either of these requests, so I filed changes
> with congress and keystone to change the dist names.
>
> * https://review.openstack.org/608332 (congress)
> * https://review.openstack.org/608331 (keystone)
>
> Doug

Dan Crosta has very graciously given us the name "keystone" so I
abandoned that patch, made openstackci an owner, and uploaded the
previous release.

The patch to rename congress is approved, but sitting on top of one or
two other patches that also need reviews.

The patch to rename heat is failing the grenade tests, and we could use
some help with fixing the problem. I think we need an upgrade script
that removes the old package before installing the new one. Does someone
want to learn how grenade scripts 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

Re: [openstack-dev] [all] Zuul job backlog

[Doug Hellmann]

Abhishek Kekane  writes:

> Hi Doug,
>
> Should I use something like SimpleHttpServer to upload a file and download
> the same, or there are other efficient ways to handle it,
> Kindly let me know if you are having any suggestions for the same.

Sure, that would work, especially if your tests are running in the unit
test jobs. If you're running a functional test, it seems like it would
also be OK to just copy a file into the directory Apache is serving from
and then download it from there.

Doug

>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
>
> On Fri, Oct 5, 2018 at 4:57 PM Doug Hellmann  wrote:
>
>> Abhishek Kekane  writes:
>>
>> > Hi Matt,
>> >
>> > Thanks for the input, I guess I should use '
>> > http://git.openstack.org/static/openstack.png' which will definitely
>> work.
>> > Clark, Matt, Kindly let me know your opinion about the same.
>>
>> That URL would not be on the local node running the test, and would
>> eventually exhibit the same problems. In fact we have seen issues
>> cloning git repositories as part of the tests in the past.
>>
>> You need to use a localhost URL to ensure that the download doesn't have
>> to go off of the node. That may mean placing something into the directory
>> where Apache is serving files as part of the test setup.
>>
>> 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

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

[Jay Pipes]

On 10/08/2018 06:14 AM, Florian Engelmann wrote:
3. HAProxy is not capable to handle "read/write" split with Galera. I 
would like to introduce ProxySQL to be able to scale Galera.


Why not send all read and all write traffic to a single haproxy endpoint 
and just have haproxy spread all traffic across each Galera node?


Galera, after all, is multi-master synchronous replication... so it 
shouldn't matter which node in the Galera cluster you send traffic to.


-jay

__
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] [goals][upgrade-checkers] Oslo library status

[Slawomir Kaplonski]

Ok. Thx for info Matt. My patch is now marked as WIP and I will wait for 
release of this lib then.

> Wiadomość napisana przez Matt Riedemann  w dniu 
> 08.10.2018, o godz. 18:08:
> 
> On 10/7/2018 4:10 AM, Slawomir Kaplonski wrote:
>> I start working on „neutron-status upgrade check” tool with noop operation 
>> for now. Patch is in [1]
>> I started using this new oslo_upgradecheck library in version 0.0.1.dev15 
>> which is available on pypi.org but I see that in master there are some 
>> changes already (like shorted names of base classes).
>> So my question here is: should I just wait a bit more for kind of „stable” 
>> version of this lib and then push neutron patch to review (do You have any 
>> eta for that?), or maybe we shouldn’t rely on this oslo library in this 
>> release and implement all on our own, like it is done currently in nova?
>> [1]https://review.openstack.org/#/c/608444/
> 
> I would wait. I think there are just a couple of changes we need to get into 
> the library (one of which changes the interface) and then we can do a 
> release. Sean McGinnis is waiting on the release for Cinder as well.
> 
> -- 
> 
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [tc] assigning new liaisons to projects

[Sean McGinnis]

On Mon, Oct 08, 2018 at 10:27:06AM -0400, Doug Hellmann wrote:
> TC members,
> 
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
> 
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
> 
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
> 
> Doug
> 

Seems fair and a good approach to me.

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] [all] Stepping down from Release Management team

[Melvin Hillsman]

Nooo! lol

Sorry to see you go but do stay in touch and I will do the same. Cheers to 
going on and continuing to do great things Anne; excited to see what you are up 
to in the coming days.

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

Date: Monday, October 8, 2018 at 11:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [all] Stepping down from Release Management team

Hi all,

I have had a fantastic time getting to work on the Release Management team and 
getting to know you all through the release marketing work, however, it is time 
for me to step down from my role on the Release Management team as I am moving 
on from my role at the Foundation and will no longer be working on upstream 
OpenStack. I cannot thank you all enough for how you all welcomed me into the 
OpenStack community and for how much I have learned about open source 
development in my time here.

If you have questions about cycle-highlights, swing by #openstack-release.
If you have questions about release marketing, contact 
lau...@openstack.org.
For other inquiries, contact 
alli...@openstack.org.
While I won't be working upstream anymore, I'll only be a Tweet or IRC message 
away.

Thank you again, and remember that cycle-highlights should be submitted by RC1.

Best,
Anne Bertucio
irc: annabelleB
twitter: @whyhiannabelle


Anne Bertucio
OpenStack Foundation
a...@openstack.org | irc: annabelleB





__
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] [stable][octavia] Backport patch adding new configuration options

[Assaf Muller]

On Mon, Oct 8, 2018 at 12:34 PM Matt Riedemann  wrote:
>
> On 10/8/2018 11:05 AM, Carlos Goncalves wrote:
> > The Octavia team merged a patch in master [1] that fixed an issue where
> > load balancers could be deleted whenever queue_event_streamer driver is
> > enabled and RabbitMQ goes down [2].
> >
> > As this is a critical bug, we would like to backport as much back as
> > possible. The question is whether these backports comply with the stable
> > policy because it adds two new configuration options and deprecates one.
> > The patch was prepared so that the deprecated option has precedence if
> > set over the other two.
> >
> > Reading the review guidelines [3], I only see "Incompatible config file
> > changes" as relevant, but the patch doesn't seem to go against that. We
> > had a patch that added a new config option backported to Queens that
> > raised some concern, so we'd like to be on the safe side this time ;-)
> >
> > We'd appreciate guidance to whether such backports are acceptable or not.
> >
>
> Well, a few things:
>
> * I would have introduced the new config options as part of the bug fix
> but *not* deprecated the existing option in the same change but rather
> as a follow up. Then the new options, which do nothing by default (?),
> could be backported and the deprecation would remain on master.
>
> * The release note mentions the new options as a feature, but that's not
> really correct is it? They are for fixing a bug, not new feature
> functionality as much.
>
> In general, as long as the new options don't introduce new behavior by
> default for existing configuration (as you said, the existing option
> takes precedence if set), and don't require configuration then it should
> be OK to backport those new options. But the sticky parts here are (1)
> deprecating an option on stable (we shouldn't do that) and (2) the
> release note mentioning a feature.

I would classify this as a critical bug fix. I think it's important to
fix the bug on stable branches, even for deployments that will get the
fix but not change their configuration options. How that's done with
respect to configuration options & backports is another matter, but I
do think that whatever approach is chosen should end up with the bug
fixed on stable branches without requiring operators to use new
options or otherwise make changes to their existing configuration
files.

>
> What I'd probably do is (1) change the 'feature' release note to a
> 'fixes' release note on master and then (2) backport the change but (a)
> drop the deprecation and (b) fix the release note in the backport to not
> call out a feature (since it's not a feature I don't think?) - and just
> make it clear with a note in the backport commit message why the
> backport is different from the original change.
>
> --
>
> 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 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] Stepping down from Release Management team

[Anne Bertucio]

Hi all,

I have had a fantastic time getting to work on the Release Management team and 
getting to know you all through the release marketing work, however, it is time 
for me to step down from my role on the Release Management team as I am moving 
on from my role at the Foundation and will no longer be working on upstream 
OpenStack. I cannot thank you all enough for how you all welcomed me into the 
OpenStack community and for how much I have learned about open source 
development in my time here. 

If you have questions about cycle-highlights, swing by #openstack-release. 
If you have questions about release marketing, contact lau...@openstack.org.
For other inquiries, contact alli...@openstack.org. 
While I won't be working upstream anymore, I'll only be a Tweet or IRC message 
away. 

Thank you again, and remember that cycle-highlights should be submitted by RC1.

Best,
Anne Bertucio
irc: annabelleB
twitter: @whyhiannabelle


Anne Bertucio
OpenStack Foundation
a...@openstack.org | irc: annabelleB





__
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] [stable][octavia] Backport patch adding new configuration options

[Matt Riedemann]

On 10/8/2018 11:05 AM, Carlos Goncalves wrote:
The Octavia team merged a patch in master [1] that fixed an issue where 
load balancers could be deleted whenever queue_event_streamer driver is 
enabled and RabbitMQ goes down [2].


As this is a critical bug, we would like to backport as much back as 
possible. The question is whether these backports comply with the stable 
policy because it adds two new configuration options and deprecates one. 
The patch was prepared so that the deprecated option has precedence if 
set over the other two.


Reading the review guidelines [3], I only see "Incompatible config file 
changes" as relevant, but the patch doesn't seem to go against that. We 
had a patch that added a new config option backported to Queens that 
raised some concern, so we'd like to be on the safe side this time ;-)


We'd appreciate guidance to whether such backports are acceptable or not.



Well, a few things:

* I would have introduced the new config options as part of the bug fix 
but *not* deprecated the existing option in the same change but rather 
as a follow up. Then the new options, which do nothing by default (?), 
could be backported and the deprecation would remain on master.


* The release note mentions the new options as a feature, but that's not 
really correct is it? They are for fixing a bug, not new feature 
functionality as much.


In general, as long as the new options don't introduce new behavior by 
default for existing configuration (as you said, the existing option 
takes precedence if set), and don't require configuration then it should 
be OK to backport those new options. But the sticky parts here are (1) 
deprecating an option on stable (we shouldn't do that) and (2) the 
release note mentioning a feature.


What I'd probably do is (1) change the 'feature' release note to a 
'fixes' release note on master and then (2) backport the change but (a) 
drop the deprecation and (b) fix the release note in the backport to not 
call out a feature (since it's not a feature I don't think?) - and just 
make it clear with a note in the backport commit message why the 
backport is different from the original change.


--

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] [goals][upgrade-checkers] Oslo library status

[Matt Riedemann]

On 10/7/2018 4:10 AM, Slawomir Kaplonski wrote:

I start working on „neutron-status upgrade check” tool with noop operation for 
now. Patch is in [1]
I started using this new oslo_upgradecheck library in version 0.0.1.dev15 which 
is available on pypi.org but I see that in master there are some changes 
already (like shorted names of base classes).
So my question here is: should I just wait a bit more for kind of „stable” 
version of this lib and then push neutron patch to review (do You have any eta 
for that?), or maybe we shouldn’t rely on this oslo library in this release and 
implement all on our own, like it is done currently in nova?

[1]https://review.openstack.org/#/c/608444/


I would wait. I think there are just a couple of changes we need to get 
into the library (one of which changes the interface) and then we can do 
a release. Sean McGinnis is waiting on the release for Cinder as well.


--

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] [stable][octavia] Backport patch adding new configuration options

[Carlos Goncalves]

Stable team,

The Octavia team merged a patch in master [1] that fixed an issue where
load balancers could be deleted whenever queue_event_streamer driver is
enabled and RabbitMQ goes down [2].

As this is a critical bug, we would like to backport as much back as
possible. The question is whether these backports comply with the stable
policy because it adds two new configuration options and deprecates one.
The patch was prepared so that the deprecated option has precedence if set
over the other two.

Reading the review guidelines [3], I only see "Incompatible config file
changes" as relevant, but the patch doesn't seem to go against that. We had
a patch that added a new config option backported to Queens that raised
some concern, so we'd like to be on the safe side this time ;-)

We'd appreciate guidance to whether such backports are acceptable or not.

Thanks,
Carlos

[1] https://review.openstack.org/#/c/581585/
[2] https://storyboard.openstack.org/#!/story/2002937
[3]
https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
[4] https://review.openstack.org/#/c/593954/
__
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] [tc] assigning new liaisons to projects

[Lance Bragstad]

On Mon, Oct 8, 2018 at 9:27 AM Doug Hellmann  wrote:

> TC members,
>
> Since we are starting a new term, and have several new members, we need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
>
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly. During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for their
> own teams, but I don't think we settled on that as a hard rule.
>
> I think the easiest and fairest (to new members) way to manage the list
> will be to wipe it and follow the same process we did last time. If you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
>

+1

>From the perspective of someone new, it'll be nice to go through all the
motions.


>
> Doug
>
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
>
> __
> 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] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

[Markus Hentsch]

Dear OpenStack developers,

as you suggested, we have written individual specs for Nova [1] and
Cinder [2] so far and will write another spec for Glance soon. We'd
appreciate any feedback and reviews on the specs :)

Thank you in advance,
Markus Hentsch

[1] https://review.openstack.org/#/c/608696/
[2] https://review.openstack.org/#/c/608663/


__
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] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches

[Doug Hellmann]

We have about 17 remaining patches to import zuul job settings into a
few repositories. Those are mostly in stable branches and the jobs are
failing in ways that may take us a long time to fix.

Rather than waiting for those, Andreas and I are proposing that we have
someone from the infra team approve them, bypassing the test jobs. That
will allow us to complete the cleanup work in the project-config
repository, and will not leave the affected repositories in a state that
is any more (or less) broken than they are today.

If you have any objections to the plan, please speak up quickly. I
would like to try to proceed before the end of the week.

Doug

+--+-+---++--+-+---+---+
| Subject  | Repo   
 | Team  | Tests  | Workflow | URL | Branch 
   | Owner |
+--+-+---++--+-+---+---+
| import zuul job settings from project-config | openstack/aodh 
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598648 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/barbican 
 | barbican  | FAILED | REVIEWED | https://review.openstack.org/599659 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/barbican 
 | barbican  | FAILED | REVIEWED | https://review.openstack.org/599661 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | openstack/castellan-ui 
 | barbican  | FAILED | NEW  | https://review.openstack.org/599649 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598634 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598655 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | PASS   | NEW  | https://review.openstack.org/598661 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/ceilometermiddleware 
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598667 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | openstack/monasca-analytics
 | monasca   | FAILED | REVIEWED | https://review.openstack.org/595658 | master 
   | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-midonet   
 | neutron   | PASS   | REVIEWED | https://review.openstack.org/597937 | 
stable/queens | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-sfc   
 | neutron   | FAILED | NEW  | https://review.openstack.org/597913 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/networking-sfc   
 | neutron   | FAILED | NEW  | https://review.openstack.org/597925 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598652 | 
stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | NEW  | https://review.openstack.org/598657 | 
stable/pike   | Doug Hellmann |
| import zuul job settings from project-config | openstack/python-aodhclient
 | Telemetry | FAILED | APPROVED | https://review.openstack.org/598669 | 
stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config | 
openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
https://review.openstack.org/599656 | stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config | 
openstack/python-barbicanclient | barbican  | FAILED | NEW  | 
https://review.openstack.org/599658 | stable/pike   | Doug Hellmann |
+--+-+---++--+-+---+---+

__
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] [tc] Technical Committee status update for 8 October 2018

[Doug Hellmann]

This is the weekly summary of work being done by the Technical Committee
members. The full list of active items is managed in the wiki:
https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Since the last update email, we have held another TC election in which 3
returning and 3 new members have been elected. Welcome again to our new
and returning members, and thank you to the former members for their
service!

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/135187.html

If you missed it, I sent the summary of TC discussions at the PTG a
while back.

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/134744.html

Between being busy with the PTG and then the TC elections, I did not
send a status update during September, so there are quite a few project
updates to report.

Project updates:

* Add os-ken to neutron: https://review.openstack.org/#/c/588358/
* Add cookbook-openstack-bare-metal to Chef:
* https://review.openstack.org/#/c/596746/
* Add mistral-extra to Mistral: https://review.openstack.org/#/c/597551/
* Add placement deliverable to Nova:
* https://review.openstack.org/#/c/598380/
* Add metalsmith to Ironic: https://review.openstack.org/#/c/602075/
* Add oslo.upgradecheck to Oslo:
* https://review.openstack.org/#/c/602483/
* Add puppet-placement to Puppet:
* https://review.openstack.org/#/c/602870/
* Add ansible-role-chrony to TripleO:
* https://review.openstack.org/#/c/603516/
* Add octavia-lib to Octavia: https://review.openstack.org/#/c/604890/
* Add neutron-interconnection to neutron:
* https://review.openstack.org/#/c/599428/

Retired repositories:

* Retire the development-proposals repository:
  https://review.openstack.org/#/c/600649/
* Retire fuxi: https://review.openstack.org/#/c/604527/
* Retire charm-ceph: https://review.openstack.org/#/c/604530/

Community Updates:

* Add Jay Faulkner as ATC for Ironic:
  https://review.openstack.org/#/c/597212/
* Begin the T deveiopment cycle naming process:
  https://review.openstack.org/#/c/600354/
* The Operations Guide team adopted the HA Guide:
  https://review.openstack.org/#/c/601321/
* The Interop Working Group adopted the refstack tools:
  https://review.openstack.org/#/c/590179/

== TC Meetings ==

In order to fulfill our obligations under the OpenStack Foundation
bylaws, the TC needs to hold meetings at least once each quarter. We
have decided to schedule monthly meetings on IRC, and retain the
existing office hours times for less formal discussions. See the thread
for details.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html

== Ongoing Discussions ==

Tony Breeds is coordinating the poll for names for the T development
cycle and release series.

* http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html

== TC member actions/focus/discussions for the coming week(s) ==

We need to decide how we are going to handle updating the list of
liaisons to projects this cycle. Please follow up on that thread.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135523.html

Add the monthly meeting to your calendar.

* http://lists.openstack.org/pipermail/openstack-dev/2018-October/135521.html

The next Foundation board meeting will be held via webex on 25
October. See the wiki for details.

* https://wiki.openstack.org/wiki/Governance/Foundation/25Oct2018BoardMeeting

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.

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

Re: [openstack-dev] [ironic] Tenks

[Jim Rollenhagen]

On Tue, Oct 2, 2018 at 8:59 AM Mark Goddard  wrote:

> Hi,
>
> In the most recent Ironic meeting we discussed [1] tenks, and the
> possibility of adding the project under Ironic governance. We agreed to
> move the discussion to the mailing list. I'll introduce the project here
> and give everyone a chance to ask questions. If things appear to move in
> the right direction, I'll propose a vote for inclusion under Ironic's
> governance.
>
> Tenks is a project for managing 'virtual bare metal clusters'. It aims to
> be a drop-in replacement for the various scripts and templates that exist
> in the Ironic devstack plugin for creating VMs to act as bare metal nodes
> in development and test environments. Similar code exists in Bifrost and
> TripleO, and probably other places too. By focusing on one project, we can
> ensure that it works well, and provides all the features necessary as
> support for bare metal in the cloud evolves.
>
> That's tenks the concept. Tenks in reality today is a working version 1.0,
> written in Ansible, built by Will Miller (w-miller) during his summer
> placement. Will has returned to his studies, and Will Szumski (jovial) has
> picked it up. You don't have to be called Will to work on Tenks, but it
> helps.
>
> There are various resources available for anyone wishing to find out more:
>
> * Ironic spec review: https://review.openstack.org/#/c/579583
> * Documentation: https://tenks.readthedocs.io/en/latest/
> * Source code: https://github.com/stackhpc/tenks
> * Blog: https://stackhpc.com/tenks.html
> * IRC: mgoddard or jovial in #openstack-ironic
>
> What does everyone think? Is this something that the ironic community
> could or should take ownership of?
>

Makes sense to me, but we should also have an explicit goal of using tenks
to kill our devstack code (and the other things mentioned).

Consider me +2 on the spec but leaving time for additional discussion. :)

Thanks Mark!

// jim


>
> [1]
> http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-10-01-15.00.log.html#l-170
>
> Thanks,
> Mark
> __
> 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] [tc] bringing back formal TC meetings

[Lance Bragstad]

On Mon, Oct 8, 2018 at 9:08 AM Doug Hellmann  wrote:

> Based on the conversation in the other branch of this thread, I have
> filed [1] to start monthly meetings on November 1 at 1400 UTC. It may
> take a while before that actually shows up on the calendar, because it
> required adding a feature to yaml2ical [2].
>
> We talked about using email to add items to the agenda, but I realized
> that's going to complicate the coordination between chair and vice
> chair, so I would like for us to use the wiki [2] to suggest agenda
> items. We will still rely on email to the openstack-dev or
> openstack-discuss list to set the formal agenda before the actual
> meeting. Let me know if you foresee any issues with that plan.
>
>
++ I think the wiki is a good alternative to using email. Those times also
work for me.


> Doug
>
> [1] https://review.openstack.org/608682
> [2] https://review.openstack.org/608680
> [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
>
> __
> 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-dev] [tc] assigning new liaisons to projects

[Doug Hellmann]

TC members,

Since we are starting a new term, and have several new members, we need
to decide how we want to rotate the liaisons attached to each our
project teams, SIGs, and working groups [1].

Last term we went through a period of volunteer sign-up and then I
randomly assigned folks to slots to fill out the roster evenly. During
the retrospective we talked a bit about how to ensure we had an
objective perspective for each team by not having PTLs sign up for their
own teams, but I don't think we settled on that as a hard rule.

I think the easiest and fairest (to new members) way to manage the list
will be to wipe it and follow the same process we did last time. If you
agree, I will update the page this week and we can start collecting
volunteers over the next week or so.

Doug

[1] https://wiki.openstack.org/wiki/OpenStack_health_tracker

__
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] [tc] planned absence

[Doug Hellmann]

TC members,

I have some PTO planned, so I will be away from 13 Oct - 28 Oct. I
approved the patch appointing Mohammed as vice chair this morning, so he
will be serving as chair during that time.

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

Re: [openstack-dev] [tc] bringing back formal TC meetings

[Doug Hellmann]

Based on the conversation in the other branch of this thread, I have
filed [1] to start monthly meetings on November 1 at 1400 UTC. It may
take a while before that actually shows up on the calendar, because it
required adding a feature to yaml2ical [2].

We talked about using email to add items to the agenda, but I realized
that's going to complicate the coordination between chair and vice
chair, so I would like for us to use the wiki [2] to suggest agenda
items. We will still rely on email to the openstack-dev or
openstack-discuss list to set the formal agenda before the actual
meeting. Let me know if you foresee any issues with that plan.

Doug

[1] https://review.openstack.org/608682
[2] https://review.openstack.org/608680
[3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

__
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] [tc] bringing back formal TC meetings

[Sean McGinnis]

> >
> > I think we can definitely manage the agenda to minimize the number of
> > complex discussions. If that proves to be too hard, I wouldn't mind
> > meeting more often, but there does seem to be a lot of support for
> > preferring other venues for those conversations.
> >
> >
> +1 I think there is a point where we need to recognize there is a time and
> place for everything, and some of those long running complex conversations
> might not be well suited for what would essentially be "review business
> status" meetings.  If we have any clue that something is going to be a very
> long and drawn out discussion, then I feel like we should make an effort to
> schedule individually.

We could also be very aggressive about ending the meeting early if all process
topics are covered to actively discourage this meeting from becoming a forum
for other non-process discussions.

__
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] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

[Sean McGinnis]

On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote:
> In Denver, we agree to add a new "re-image" API in cinder to support upport
> volume-backed server rebuild with a new image.
> 
> An initial blueprint has been drafted in [3], welcome to review it, thanks.
> : )
> 
> [snip]
> 
> The "force" parameter idea comes from [4], means that
> 1. we can re-image an "available" volume directly.
> 2. we can't re-image "in-use"/"reserved" volume directly.
> 3. we can only re-image an "in-use"/"reserved" volume with "force"
> parameter.
> 
> And it means nova need to always call re-image API with an extra "force"
> parameter,
> because the volume status is "in-use" or "reserve" when we rebuild the
> server.
> 
> *So, what's you idea? Do we really want to add this "force" parameter?*
> 

I would prefer we have the "force" parameter, even if it is something that will
always be defaulted to True from Nova.

Having this exposed as a REST API means anyone could call it, not just Nova
code. So as protection from someone doing something that they are not really
clear on the full implications of, having a flag in there to guard volumes that
are already attached or reserved for shelved instances is worth the very minor
extra overhead.

> [1] https://etherpad.openstack.org/p/nova-ptg-stein L483
> [2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12
> [3] https://review.openstack.org/#/c/605317
> [4]
> https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75
> 
> Regards,
> Yikun
> 
> Jiang Yikun（Kero）
> Mail: yikunk...@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 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-operators] [all] Consistent policy names

[Lance Bragstad]

On Mon, Oct 1, 2018 at 8:13 AM Ghanshyam Mann 
wrote:

>   On Sat, 29 Sep 2018 03:54:01 +0900 Lance Bragstad <
> lbrags...@gmail.com> wrote 
>  >
>  > On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki 
> wrote:
>  > On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>  >   wrote:
>  >  >
>  >  > Ideally I would like to see it in the form of least specific to most
> specific. But more importantly in a way that there is no additional
> delimiters between the service type and the resource. Finally, I do not
> like the change of plurality depending on action type.
>  >  >
>  >  > I propose we consider
>  >  >
>  >  > ::[:]
>  >  >
>  >  > Example for keystone (note, action names below are strictly examples
> I am fine with whatever form those actions take):
>  >  > identity:projects:create
>  >  > identity:projects:delete
>  >  > identity:projects:list
>  >  > identity:projects:get
>  >  >
>  >  > It keeps things simple and consistent when you're looking through
> overrides / defaults.
>  >  > --Morgan
>  >  +1 -- I think the ordering if `resource` comes before
>  >  `action|subaction` will be more clean.
>  >
>  > ++
>  > These are excellent points. I especially like being able to omit the
> convention about plurality. Furthermore, I'd like to add that I think we
> should make the resource singular (e.g., project instead or projects). For
> example:
>  > compute:server:list
>  >
> compute:server:updatecompute:server:createcompute:server:deletecompute:server:action:rebootcompute:server:action:confirm_resize
> (or confirm-resize)
>
> Do we need "action" word there? I think action name itself should convey
> the operation. IMO below notation without "äction" word looks clear enough.
> what you say?
>
> compute:server:reboot
> compute:server:confirm_resize
>

I agree. I simplified this in the current version up for review.


>
> -gmann
>
>  >
>  > Otherwise, someone might mistake compute:servers:get, as "list". This
> is ultra-nick-picky, but something I thought of when seeing the usage of
> "get_all" in policy names in favor of "list."
>  > In summary, the new convention based on the most recent feedback should
> be:
>  > ::[:]
>  > Rules:service-type is always defined in the service types authority
>  > resources are always singular
>  > Thanks to all for sticking through this tedious discussion. I
> appreciate it.
>  >  /R
>  >
>  >  Harry
>  >  >
>  >  > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad 
> wrote:
>  >  >>
>  >  >> Bumping this thread again and proposing two conventions based on
> the discussion here. I propose we decide on one of the two following
> conventions:
>  >  >>
>  >  >> ::
>  >  >>
>  >  >> or
>  >  >>
>  >  >> :_
>  >  >>
>  >  >> Where  is the corresponding service type of the
> project [0], and  is either create, get, list, update, or delete. I
> think decoupling the method from the policy name should aid in consistency,
> regardless of the underlying implementation. The HTTP method specifics can
> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>  >  >>
>  >  >> I think the plurality of the resource should default to what makes
> sense for the operation being carried out (e.g., list:foobars,
> create:foobar).
>  >  >>
>  >  >> I don't mind the first one because it's clear about what the
> delimiter is and it doesn't look weird when projects have something like:
>  >  >>
>  >  >> :::
>  >  >>
>  >  >> If folks are ok with this, I can start working on some
> documentation that explains the motivation for this. Afterward, we can
> figure out how we want to track this work.
>  >  >>
>  >  >> What color do you want the shed to be?
>  >  >>
>  >  >> [0] https://service-types.openstack.org/service-types.json
>  >  >> [1]
> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
>  >  >>
>  >  >> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad 
> wrote:
>  >  >>>
>  >  >>>
>  >  >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann <
> gm...@ghanshyammann.com> wrote:
>  >  
>  >     On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> j...@johngarbutt.com> wrote 
>  >    > tl;dr+1 consistent names
>  >    > I would make the names mirror the API... because the Operator
> setting them knows the API, not the codeIgnore the crazy names in Nova, I
> certainly hate them
>  >  
>  >   Big +1 on consistent naming  which will help operator as well as
> developer to maintain those.
>  >  
>  >    >
>  >    > Lance Bragstad  wrote:
>  >    > > I'm curious if anyone has context on the "os-" part of the
> format?
>  >    >
>  >    > My memory of the Nova policy mess...* Nova's policy rules
> traditionally followed the patterns of the code
>  >    > ** Yes, horrible, but it happened.* The code used to have the
> OpenStack API and the EC2 API, hence the "os"* API used to expand with
> extensions, so the policy name is often based on extensions** note most of
> the extension code has 

Re: [openstack-dev] [nova] Rocky RC time regression analysis

[Eric Fried]

Mel-

I don't have much of anything useful to add here, but wanted to say
thanks for this thorough analysis. It must have taken a lot of time and
work.

Musings inline.

On 10/05/2018 06:59 PM, melanie witt wrote:
> Hey everyone,
> 
> During our Rocky retrospective discussion at the PTG [1], we talked
> about the spec freeze deadline (milestone 2, historically it had been
> milestone 1) and whether or not it was related to the hectic
> late-breaking regression RC time we had last cycle. I had an action item
> to go through the list of RC time bugs [2] and dig into each one,
> examining: when the patch that introduced the bug landed vs when the bug
> was reported, why it wasn't caught sooner, and report back so we can
> take a look together and determine whether they were related to the spec
> freeze deadline.
> 
> I used this etherpad to make notes [3], which I will [mostly] copy-paste
> here. These are all after RC1 and I'll paste them in chronological order
> of when the bug was reported.
> 
> Milestone 1 r-1 was 2018-04-19.
> Spec freeze was milestone 2 r-2 was 2018-06-07.
> Feature freeze (FF) was on 2018-07-26.
> RC1 was on 2018-08-09.
> 
> 1) Broken live migration bandwidth minimum => maximum based on neutron
> event https://bugs.launchpad.net/nova/+bug/1786346
> 
> - Bug was reported on 2018-08-09, the day of RC1
> - The patch that caused the regression landed on 2018-03-30
> https://review.openstack.org/497457
> - Unrelated to a blueprint, the regression was part of a bug fix
> - Was found because prometheanfire was doing live migrations and noticed
> they seemed to be stuck at 1MiB/s for linuxbridge VMs
> - The bug was due to a race, so the gate didn't hit it
> - Comment on the regression bug from dansmith: "The few hacked up gate
> jobs we used to test this feature at merge time likely didn't notice the
> race because the migrations finished before the potential timeout and/or
> are on systems so loaded that the neutron event came late enough for us
> to win the race repeatedly."
> 
> 2) Docs for the zvm driver missing
> 
> - All zvm driver code changes were merged by 2018-07-17 but the
> documentation was overlooked but was noticed near RC time
> - Blueprint was approved on 2018-02-12
> 
> 3) Volume status remains "detaching" after a failure to detach a volume
> due to DeviceDetachFailed https://bugs.launchpad.net/nova/+bug/1786318
> 
> - Bug was reported on 2018-08-09, the day of RC1
> - The change that introduced the regression landed on 2018-02-21
> https://review.openstack.org/546423
> - Unrelated to a blueprint, the regression was part of a bug fix
> - Question: why wasn't this caught earlier?
> - Answer: Unit tests were not asserting the call to the roll_detaching
> volume API. Coverage has since been added along with the bug fix
> https://review.openstack.org/590439
> 
> 4) OVB overcloud deploy fails on nova placement errors
> https://bugs.launchpad.net/nova/+bug/1787910
> 
> - Bug was reported on 2018-08-20
> - Change that caused the regression landed on 2018-07-26, FF day
> https://review.openstack.org/517921
> - Blueprint was approved on 2018-05-16
> - Was found because of a failure in the
> legacy-periodic-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master
> CI job. The ironic-inspector CI upstream also failed because of this, as
> noted by dtantsur.
> - Question: why did it take nearly a month for the failure to be
> noticed? Is there any way we can cover this in our
> ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa job?
> 
> 5) when live migration fails due to a internal error rollback is not
> handled correctly https://bugs.launchpad.net/nova/+bug/1788014
> 
> - Bug was reported on 2018-08-20
> - The change that caused the regression landed on 2018-07-26, FF day
> https://review.openstack.org/434870
> - Unrelated to a blueprint, the regression was part of a bug fix
> - Was found because sean-k-mooney was doing live migrations and found
> that when a LM failed because of a QEMU internal error, the VM remained
> ACTIVE but the VM no longer had network connectivity.
> - Question: why wasn't this caught earlier?
> - Answer: We would need a live migration job scenario that intentionally
> initiates and fails a live migration, then verify network connectivity
> after the rollback occurs.
> - Question: can we add something like that?
> 
> 6) nova-manage db online_data_migrations hangs on instances with no host
> set https://bugs.launchpad.net/nova/+bug/1788115
> 
> - Bug was reported on 2018-08-21
> - The patch that introduced the bug landed on 2018-05-30
> https://review.openstack.org/567878
> - Unrelated to a blueprint, the regression was part of a bug fix
> - Question: why wasn't this caught earlier?
> - Answer: To hit the bug, you had to have had instances with no host set
> (that failed to schedule) in your database during an upgrade. This does
> not happen during the grenade job
> - Question: could we add anything to the grenade job that would leave
> some 

Re: [openstack-dev] [Monasca] [monasca-Agent] Monasca agent problem

[Bedyk, Witold]

Hi Amal,

I guess, the mailing list doesn’t accept attachments.

Could you please check if you’re using the right project? Monasca is 
multi-tenant and stores all the measurements and alarm definitions per project. 
If alarm definition is created, let’s say for project ‘admin’ and the agent is 
configured to send the measurements for project ‘customer1’, the alarm won’t 
get triggered in either of them.

Best regards
Witek


From: amal kammoun 
Sent: Montag, 8. Oktober 2018 12:03
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Monasca] [monasca-Agent] Monasca agent problem

Hello,

I have an issue with the monasca Agent.
In fact, I installed monasca with Openstack using devstack.
I want to minitor now the instances deployed using Openstack. For that I 
installed on each instance the monasca agent with the following link: 
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md
The problem is that I cannot define alarms for the concerned instance.
Example on my agent:
[image.png]

On my monitoring system I found the alam defintion but it is not activated. 
also the instance on where the agent is running is not declared as a server on 
the monasca servers list.

Regards,
Amal Kammoun.
__
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] [manila] Stein mid-cycle and bug smash dates

[Tom Barron]

In a recent weekly manila community meeting [1] we tentatively agreed 
to have a virtual mid-cycle Wednesday and Thursday 16-17 January 2019.
This would be the week after the Stein-2 miletone and a month before 
Manila Feature proposal Freeze.


Also, given the success of the China-based bug-smashes in the last few 
years, we are planning an Americas-timezone-friendly bug-smash as 
well, aiming for 13-14 March 2019, the week after the Stein-3 
milestone and Feature Freeze.


Please respond to the list if you have objections or counter-proposals 
to these proposed dates.


Thanks!

-- Tom Barron (tbarron)

[1] 
http://eavesdrop.openstack.org/meetings/manila/2018/manila.2018-09-27-15.00.log.txt



__
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] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

[Florian Engelmann]

Hi,

I would like to start a discussion about some changes and additions I 
would like to see in in kolla and kolla-ansible.


1. Keepalived is a problem in layer3 spine leaf networks as any floating 
IP can only exist in one leaf (and VRRP is a problem in layer3). I would 
like to use consul and registrar to get rid of the "internal" floating 
IP and use consuls DNS service discovery to connect all services with 
each other.


2. Using "ports" for external API (endpoint) access is a major headache 
if a firewall is involved. I would like to configure the HAProxy (or 
fabio) for the external access to use "Host:" like, eg. "Host: 
keystone.somedomain.tld", "Host: nova.somedomain.tld", ... with HTTPS. 
Any customer would just need HTTPS access and not have to open all those 
ports in his firewall. For some enterprise customers it is not possible 
to request FW changes like that.


3. HAProxy is not capable to handle "read/write" split with Galera. I 
would like to introduce ProxySQL to be able to scale Galera.


4. HAProxy is fine but fabio integrates well with consul, statsd and 
could be connected to a vault cluster to manage secure certificate access.


5. I would like to add vault as Barbican backend.

6. I would like to add an option to enable tokenless authentication for 
all services with each other to get rid of all the openstack service 
passwords (security issue).


What do you think about it?

All the best,
Florian


smime.p7s
Description: S/MIME cryptographic 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] [Monasca] [monasca-Agent] Monasca agent problem

[amal kammoun]

Hello,

I have an issue with the monasca Agent.
In fact, I installed monasca with Openstack using devstack.
I want to minitor now the instances deployed using Openstack. For that I
installed on each instance the monasca agent with the following link:
https://github.com/openstack/monasca-agent/blob/master/docs/Agent.md
The problem is that I cannot define alarms for the concerned instance.
Example on my agent:
[image: image.png]

On my monitoring system I found the alam defintion but it is not activated.
also the instance on where the agent is running is not declared as a server
on the monasca servers list.

Regards,
Amal Kammoun.
__
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] Zuul job backlog

[Abhishek Kekane]

Hi Doug,

Should I use something like SimpleHttpServer to upload a file and download
the same, or there are other efficient ways to handle it,
Kindly let me know if you are having any suggestions for the same.

Thanks & Best Regards,

Abhishek Kekane


On Fri, Oct 5, 2018 at 4:57 PM Doug Hellmann  wrote:

> Abhishek Kekane  writes:
>
> > Hi Matt,
> >
> > Thanks for the input, I guess I should use '
> > http://git.openstack.org/static/openstack.png' which will definitely
> work.
> > Clark, Matt, Kindly let me know your opinion about the same.
>
> That URL would not be on the local node running the test, and would
> eventually exhibit the same problems. In fact we have seen issues
> cloning git repositories as part of the tests in the past.
>
> You need to use a localhost URL to ensure that the download doesn't have
> to go off of the node. That may mean placing something into the directory
> where Apache is serving files as part of the test setup.
>
> 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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 05/10/18 21:54, Jim Rollenhagen wrote:
GraphQL has introspection features that allow clients to pull the 
schema (types, queries, mutations, etc): 
https://graphql.org/learn/introspection/


That said, it seems like using this in a client like OpenStackSDK 
would get messy quickly. Instead of asking for which versions are 
supported, you'd have to fetch the schema, map it to actual features 
somehow, and adjust queries based on this info.




A main difference in software architecture when using GraphQL is that a 
client makes use of a GraphQL client library instead of relaying on a SDK.



I guess there might be a middleground where we could fetch the REST 
API version, and know from that what GraphQL queries can be made.


// jim



__
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] [vitrage] vitrage virtual PTG

[Ifat Afek]

Hi,

We will hold the vitrage virtual PTG on Wednesday-Thursday this week,
October 10-11th.
The agenda is listed in the etherpad[1], and you can still add new topics
for discussion.

We will skip the regular IRC meeting this week.

[1] https://etherpad.openstack.org/p/vitrage-stein-ptg

Thanks,
Ifat
__
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] [cinder] [nova] Do we need a "force" parameter in cinder "re-image" API?

[Yikun Jiang]

In Denver, we agree to add a new "re-image" API in cinder to support upport
volume-backed server rebuild with a new image.

An initial blueprint has been drafted in [3], welcome to review it, thanks.
: )

The API is very simple, something like:

URL:

  POST /v3/{project_id}/volumes/{volume_id}/action

Request body:

  {
  'os-reimage': {
  'image_id': "71543ced-a8af-45b6-a5c4-a46282108a90"
  }
  }

The question is do we need a "force" parameter in request body? like:
  {
  'os-reimage': {
  'image_id': "71543ced-a8af-45b6-a5c4-a46282108a90",
*  'force': True*
  }
  }

The "force" parameter idea comes from [4], means that
1. we can re-image an "available" volume directly.
2. we can't re-image "in-use"/"reserved" volume directly.
3. we can only re-image an "in-use"/"reserved" volume with "force"
parameter.

And it means nova need to always call re-image API with an extra "force"
parameter,
because the volume status is "in-use" or "reserve" when we rebuild the
server.

*So, what's you idea? Do we really want to add this "force" parameter?*

[1] https://etherpad.openstack.org/p/nova-ptg-stein L483
[2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12
[3] https://review.openstack.org/#/c/605317
[4]
https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75

Regards,
Yikun

Jiang Yikun（Kero）
Mail: yikunk...@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