Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for'T' release

[Chen CH Ji]

>>>(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
>>> "IBM announced that KVM for IBM z will be withdrawn, effective March
>>> 31, 2018 [...] development will not only continue unaffected, but
>>> the options for users grow, especially with the recent addition of
>>> SuSE to the existing support in Ubuntu."

>>> The message seems to be: "use a regular distribution".  So this is
>>> covered, if we a version based on other distributions.

Yes, IBM don't have a product on s390x anymore per [3] indicated,
we are cooperating with distro in enablement

and for openstack, KVM on z has its own 3rd CI maintaining by us per [5]

[5] http://ci-watch.tintri.com/project?project=nova(IBM zKVM CI )

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Kashyap Chamarthy 
To: openstack-operat...@lists.openstack.org,
openstack-dev@lists.openstack.org
Date:   09/24/2018 09:28 PM
Subject:[Openstack-operators] RFC: Next minimum libvirt / QEMU versions
for 'T' release



Hey folks,

Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
versions for the 'T' (which is still in the naming phase) release, which
will come out in the autumn (Sep-Nov) of 2019.

Proposal


Looking at the DistroSupportMatrix[2], it seems like we can pick the
libvirt and QEMU versions supported by the next LTS release of Ubuntu --
18.04; "Bionic", which are:

libvirt: 4.0.0
QEMU:2.11

Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
above versions.  And it seems reasonable to assume that the enterprise
distribtions will also ship the said versions pretty soon; but let's
double-confirm below.

Considerations and open questions
-

(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
"IBM announced that KVM for IBM z will be withdrawn, effective March
31, 2018 [...] development will not only continue unaffected, but
the options for users grow, especially with the recent addition of
SuSE to the existing support in Ubuntu."

The message seems to be: "use a regular distribution".  So this is
covered, if we a version based on other distributions.

(b) Oracle Linux: Can you please confirm if you'll be able to
release libvirt and QEMU to 4.0.0 and 2.11, respectively?

(c) SLES: Same question as above.

Assuming Oracle Linux and SLES confirm, please let us know if there are
any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
release to be libvirt: 4.0.0 and QEMU: 2.11.

* * *

A refresher on libvirt and QEMU release schedules
-

  - There will be at least 12 libvirt releases (_excluding_ maintenance
releases) by Autumn 2019.  A new libvirt release comes out every
month[4].

  - And there will be about 4 releases of QEMU.  A new QEMU release
comes out once every four months.

[1]
http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b

-- Pick next minimum libvirt / QEMU versions for "Stein"
[2]
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix

[3]
http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html

[4]
https://libvirt.org/downloads.html#schedule


--
/kashyap

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




__
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] tripleo-puppet-elements 9.0.0.0rc2 (rocky)

[no-reply]

Hello everyone,

A new release candidate for tripleo-puppet-elements for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-puppet-elements/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


https://git.openstack.org/cgit/openstack/tripleo-puppet-elements/log/?h=stable/rocky

Release notes for tripleo-puppet-elements can be found at:

https://docs.openstack.org/releasenotes/tripleo-puppet-elements/




__
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] tripleo-heat-templates 9.0.0.0rc2 (rocky)

[no-reply]

Hello everyone,

A new release candidate for tripleo-heat-templates for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/tripleo-heat-templates/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


https://git.openstack.org/cgit/openstack/tripleo-heat-templates/log/?h=stable/rocky

Release notes for tripleo-heat-templates can be found at:

https://docs.openstack.org/releasenotes/tripleo-heat-templates/

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/tripleo

and tag it *rocky-rc-potential* to bring it to the tripleo-heat-templates
release crew's attention.


__
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] [penstack-dev]Discussion about the future of OpenStack in China

[Duc Truong]

Senlin also supports the HA use case via its health policy.
On Mon, Sep 24, 2018 at 4:26 PM Zhipeng Huang  wrote:
>
> watcher is known by some, but I don't think Masakari is
>
> On Tue, Sep 25, 2018 at 5:47 AM Matt Riedemann  wrote:
>>
>> On 9/24/2018 12:12 PM, Jay Pipes wrote:
>> > There were a couple points that I did manage to decipher, though. One
>> > thing that both articles seemed to say was that OpenStack doesn't meet
>> > public (AWS-ish) cloud use cases and OpenStack doesn't compare favorably
>> > to VMWare either.
>>
>> Yeah I picked up on that also - trying to be all things to all people
>> means we do less well at any single thing. No surprises there.
>>
>> >
>> > Is there a large contingent of Chinese OpenStack users that expect
>> > OpenStack to be a free (as in beer) version of VMware technology?
>> >
>> > What are the 3 most important features that Chinese OpenStack users
>> > would like to see included in OpenStack projects?
>>
>> Yeah I picked up on a few things as well. The article was talking about
>> gaps in upstream services:
>>
>> a) they did a bunch of work on trove for their dbaas solution, but did
>> they contribute any of that work?
>>
>> b) they mentioned a lack of DRS and HA support, but didn't mention the
>> Watcher or Masakari projects - maybe they didn't know they exist?
>>
>> --
>>
>> 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
>
>
>
> --
> 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 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] [storyboard] Prioritization?

[Jeremy Stanley]

On 2018-09-24 19:31:17 -0400 (-0400), Doug Hellmann wrote:
> That came up as a suggestion, too. The challenge there is that we
> cannot (as far as I know) sort on tags. So even if we have tags,
> we can't create a list of stories that is ordered automatically
> based on the priority. Maybe there's a solution to that?

A board with automatic lanes for each priority tag? That way you can
also have a lane for "stories with incomplete tasks for projects in
my project-group but which haven't been prioritized yet" and be able
to act on/triage them accordingly.
-- 
Jeremy Stanley


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] [storyboard] Prioritization?

[Doug Hellmann]

Jeremy Stanley  writes:

> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> At the PTG there was feedback from at least one team that
>> consumers of the data in storyboard want a priority setting on
>> each story. Historically the response to that has been that
>> different users will have different priorities, so each of them
>> using worklists is the best way to support those differences of
>> opinion.
>> 
>> I think we need to reconsider that position if it's going to block
>> adoption. I think Ben's case is an excellent second example of
>> where having a field to hold some sort of priority value would be
>> useful.
>
> The alternative suggestion, for teams who want to be able to flag
> some sort of bucketed priorities, is to use story tags. We could
> even improve the import tool to accept some sort of
> priority-to-tag-name mapping so that, say, when we import bugs for
> Oslo their oslo-critical tag is applied to any with a critical
> bugtask, oslo-medium to any with medium priority tasks, and so on.
> Not all teams using StoryBoard will want to have a bucketed priority
> scheme, and those who do won't necessarily want to use the same
> number or kinds of priorities.

That came up as a suggestion, too. The challenge there is that we cannot
(as far as I know) sort on tags. So even if we have tags, we can't
create a list of stories that is ordered automatically based on the
priority. Maybe there's a solution to that?

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] [penstack-dev]Discussion about the future of OpenStack in China

[Zhipeng Huang]

watcher is known by some, but I don't think Masakari is

On Tue, Sep 25, 2018 at 5:47 AM Matt Riedemann  wrote:

> On 9/24/2018 12:12 PM, Jay Pipes wrote:
> > There were a couple points that I did manage to decipher, though. One
> > thing that both articles seemed to say was that OpenStack doesn't meet
> > public (AWS-ish) cloud use cases and OpenStack doesn't compare favorably
> > to VMWare either.
>
> Yeah I picked up on that also - trying to be all things to all people
> means we do less well at any single thing. No surprises there.
>
> >
> > Is there a large contingent of Chinese OpenStack users that expect
> > OpenStack to be a free (as in beer) version of VMware technology?
> >
> > What are the 3 most important features that Chinese OpenStack users
> > would like to see included in OpenStack projects?
>
> Yeah I picked up on a few things as well. The article was talking about
> gaps in upstream services:
>
> a) they did a bunch of work on trove for their dbaas solution, but did
> they contribute any of that work?
>
> b) they mentioned a lack of DRS and HA support, but didn't mention the
> Watcher or Masakari projects - maybe they didn't know they exist?
>
> --
>
> 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
>


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

Re: [openstack-dev] [storyboard] Prioritization?

[Jeremy Stanley]

On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
[...]
> At the PTG there was feedback from at least one team that
> consumers of the data in storyboard want a priority setting on
> each story. Historically the response to that has been that
> different users will have different priorities, so each of them
> using worklists is the best way to support those differences of
> opinion.
> 
> I think we need to reconsider that position if it's going to block
> adoption. I think Ben's case is an excellent second example of
> where having a field to hold some sort of priority value would be
> useful.

The alternative suggestion, for teams who want to be able to flag
some sort of bucketed priorities, is to use story tags. We could
even improve the import tool to accept some sort of
priority-to-tag-name mapping so that, say, when we import bugs for
Oslo their oslo-critical tag is applied to any with a critical
bugtask, oslo-medium to any with medium priority tasks, and so on.
Not all teams using StoryBoard will want to have a bucketed priority
scheme, and those who do won't necessarily want to use the same
number or kinds of priorities.
-- 
Jeremy Stanley


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] [storyboard] Prioritization?

[Doug Hellmann]

Ben Nemec  writes:

> Hi,
>
> This came up in the Oslo meeting as a result of my initial look at the 
> test Storyboard import. It appears all of the priority data from 
> launchpad gets lost in the migration, which is going to make organizing 
> hundreds of bugs somewhat difficult. I'm particularly not fond of it 
> after spending last cycle whittling down our untriaged bug list. :-)
>
> Work lists and tags were mentioned as possible priority management tools 
> in Storyboard, so is there some way to migrate launchpad priorities into 
> one of those automatically? If not, are there any plans to add that?
>
> It sounded like a similar conversation is happening with a few other 
> teams so we wanted to bring the discussion to the mailing list for 
> visibility.
>
> Thanks.
>
> -Ben

At the PTG there was feedback from at least one team that consumers of
the data in storyboard want a priority setting on each
story. Historically the response to that has been that different users
will have different priorities, so each of them using worklists is the
best way to support those differences of opinion.

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.

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] [penstack-dev]Discussion about the future of OpenStack in China

[Matt Riedemann]

On 9/24/2018 12:12 PM, Jay Pipes wrote:
There were a couple points that I did manage to decipher, though. One 
thing that both articles seemed to say was that OpenStack doesn't meet 
public (AWS-ish) cloud use cases and OpenStack doesn't compare favorably 
to VMWare either.


Yeah I picked up on that also - trying to be all things to all people 
means we do less well at any single thing. No surprises there.




Is there a large contingent of Chinese OpenStack users that expect 
OpenStack to be a free (as in beer) version of VMware technology?


What are the 3 most important features that Chinese OpenStack users 
would like to see included in OpenStack projects?


Yeah I picked up on a few things as well. The article was talking about 
gaps in upstream services:


a) they did a bunch of work on trove for their dbaas solution, but did 
they contribute any of that work?


b) they mentioned a lack of DRS and HA support, but didn't mention the 
Watcher or Masakari projects - maybe they didn't know they exist?


--

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] [storyboard][oslo] Fewer stories than bugs?

[Ben Nemec]

This is a more oslo-specific (maybe) question that came out of the test 
migration. I noticed that launchpad is reporting 326 open bugs across 
the Oslo projects, but in Storyboard there are only 266 stories created. 
While I'm totally onboard with reducing our bug backlog, I'm curious why 
that is the case. I'm speculating that maybe Launchpad counts bugs that 
affect multiple Oslo projects as multiple bugs whereas Storyboard is 
counting them as a single story?


I think we were also going to skip 
https://bugs.launchpad.net/openstack-infra which for some reason 
appeared in the oslo group, but that's only two bugs so it doesn't 
account for anywhere near the full difference.


Mostly I just want to make sure we didn't miss something. I'm hoping 
this is a known behavior and we don't have to start comparing bug lists 
to find the difference. :-)


Thanks.

-Ben

__
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] [storyboard] Prioritization?

[Ben Nemec]

Hi,

This came up in the Oslo meeting as a result of my initial look at the 
test Storyboard import. It appears all of the priority data from 
launchpad gets lost in the migration, which is going to make organizing 
hundreds of bugs somewhat difficult. I'm particularly not fond of it 
after spending last cycle whittling down our untriaged bug list. :-)


Work lists and tags were mentioned as possible priority management tools 
in Storyboard, so is there some way to migrate launchpad priorities into 
one of those automatically? If not, are there any plans to add that?


It sounded like a similar conversation is happening with a few other 
teams so we wanted to bring the discussion to the mailing list for 
visibility.


Thanks.

-Ben

__
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][ironic][tripleo][oslo][neutron] recovering from today's release failures

[Doug Hellmann]

Doug Hellmann  writes:

> Earlier today a bad version of twine (1.12.0) caused issues with many of
> the release jobs that were trying to publish artifacts to
> pypi.python.org. I didn't notice those failures until after all of the
> releases had been processed, unfortunately, which left us with quite a
> few broken releases to try to recover from.
>
> After working out the cause of the problem, and finding that in fact
> some, but not all, of the release artifacts were published, we started
> making a list of the manual recovery steps we would have to take. And
> that list was really really long.
>
> So, instead of doing all of that, we're going to re-tag the releases,
> using new version numbers, to produce good artifacts. I have prepared
> https://review.openstack.org/#/c/604875/ to do this.
>
> I will also run some tests to ensure the publishing works before
> approving those re-releases.
>
> Sorry for the inconvenience,
> Doug

We've had a few release requests come in since this email, so I want to
make sure everyone understands that we're going to wait to sort out the
issues we already have before releasing anything else. The test release
is waiting in the check queue still, so it's likely to be a while before
we know for sure that things are working.

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] [nova] summit forum topic submission deadline Wed Sep 26

[melanie witt]

Hey everyone,

This is a reminder that the deadline for submitting summit forum topics 
is coming up soon in two days, Wed Sep 26. Please see our forum topic 
etherpad for links to forum information and instructions on how to 
submit a topic:


https://etherpad.openstack.org/p/nova-forum-stein

Cheers,
-melanie

__
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] [glance][upgrade-checkers] Question about glance rocky upgrade release note

[Matt Riedemann]

On 9/24/2018 2:06 PM, Matt Riedemann wrote:
Are there more specific docs about how to configure the 'image import' 
feature so that I can be sure I'm careful? In other words, are there 
specific things a "glance-status upgrade check" check could look at and 
say, "your image import configuration is broken, here are details on how 
you should do this"?


I guess this answers the question about docs:

https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html

Would a basic upgrade check be such that if glance-api.conf contains 
enable_image_import=False, you're going to have issues since that option 
is removed in Rocky?


--

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] [Tacker] Cancelling weekly meeting this week.

[Dharmendra Kushwaha]

Dear Tacker members,

We have discussed most of the thing during PTG on Friday, So cancelling weekly 
meeting for this week.
Please focus on discussed specs & code.

Thanks & Regards
Dharmendra Kushwaha

__
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] [glance][upgrade-checkers] Question about glance rocky upgrade release note

[Matt Riedemann]

Looking at the upgrade-checkers goal [1] for glance and the Rocky 
upgrade release notes [2], one upgrade note says:


"As Image Import will be always enabled, care needs to be taken that it 
is configured properly from this release forward. The 
‘enable_image_import’ option is silently ignored."


Are there more specific docs about how to configure the 'image import' 
feature so that I can be sure I'm careful? In other words, are there 
specific things a "glance-status upgrade check" check could look at and 
say, "your image import configuration is broken, here are details on how 
you should do this"?


I'm willing to help write the upgrade check for glance, but need more 
details on that release note.


[1] https://storyboard.openstack.org/#!/story/2003657
[2] https://docs.openstack.org/releasenotes/glance/rocky.html#upgrade-notes

--

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] [release][ironic][tripleo][oslo][neutron] recovering from today's release failures

[Doug Hellmann]

Earlier today a bad version of twine (1.12.0) caused issues with many of
the release jobs that were trying to publish artifacts to
pypi.python.org. I didn't notice those failures until after all of the
releases had been processed, unfortunately, which left us with quite a
few broken releases to try to recover from.

After working out the cause of the problem, and finding that in fact
some, but not all, of the release artifacts were published, we started
making a list of the manual recovery steps we would have to take. And
that list was really really long.

So, instead of doing all of that, we're going to re-tag the releases,
using new version numbers, to produce good artifacts. I have prepared
https://review.openstack.org/#/c/604875/ to do this.

I will also run some tests to ensure the publishing works before
approving those re-releases.

Sorry for the inconvenience,
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] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[John Dennis]

On 9/24/18 8:00 AM, Colleen Murphy wrote:

This is in regard to https://launchpad.net/bugs/1641625 and the proposed patch 
https://review.openstack.org/588211 for it. Thanks Vishakha for getting the 
ball rolling.

tl;dr: Keystone as an IdP should support sending non-strings/lists-of-strings 
as user attribute values, specifically lists of keystone groups, here's how 
that might happen.

Problem statement:

When keystone is set up as a service provider with an external non-keystone 
identity provider, it is common to configure the mapping rules to accept a list 
of group names from the IdP and map them to some property of a local keystone 
user, usually also a keystone group name. When keystone acts as the IdP, it's 
not currently possible to send a group name as a user property in the 
assertion. There are a few problems:
 
 1. We haven't added any openstack_groups key in the creation of the SAML assertion (http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164).

 2. If we did, this would not be enough. Unlike other IdPs, in keystone 
there can be multiple groups with the same name, namespaced by domain. So it's 
not enough for the SAML AttributeStatement to contain a semi-colon-separated 
list of group names, since a user could theoretically be a member of two or 
more groups with the same name.
* Why can't we just send group IDs, which are unique? Because two different 
keystones are not going to have independent groups with the same UUID, so we 
cannot possibly map an ID of a group from keystone A to the ID of a different 
group in keystone B. We could map the ID of the group in in A to the name of a 
group in B but then operators need to create groups with UUIDs as names which 
is a little awkward for both the operator and the user who now is a member of 
groups with nondescriptive names.
 3. If we then were able to encode a complex type like a group dict in a 
SAML assertion, we'd have to deal with it on the service provider side by being 
able to parse such an environment variable from the Apache headers.
 4. The current mapping rules engine uses basic python string formatting to 
translate remote key-value pairs to local rules. We would need to change the 
mapping API to work with values more complex than strings and lists of strings.
 
Possible solution:


Vishakha's patch (https://review.openstack.org/588211) starts to solve (1) but 
it doesn't go far enough to solve (2-4). What we talked about at the PTG was:
 
 2. Encode the group+domain as a string, for example by using the dict string repr or a string representation of some custom XML and maybe base64 encoding it.

 * It's not totally clear whether the AttributeValue class of the 
pysaml2 library supports any data types outside of the xmlns:xs namespace or 
whether nested XML is an option, so encoding the whole thing as an xs:string 
seems like the simplest solution.
 3. The SP will have to be aware that openstack_groups is a special key 
that needs the encoding reversed.
 * I wrote down "MultiDict" in my notes but I don't recall exactly what 
format the environment variable would take that would make a MultiDict make sense here, 
in any case I think encoding the whole thing as a string eliminates the need for this.
 4. We didn't talk about the mapping API, but here's what I think. If we 
were just talking about group names, the mapping API today would work like this 
(slight oversimplification for brevity):
 
Given a list of openstack_groups like ["A", "B", "C"], it would work like this:
 
[

   {
 "local":
 [
   {
 "group":
 {
   "name": "{0}",
   "domain":
   {
 "name": "federated_domain"
   }
 }
   }
 ], "remote":
 [
   {
 "type": "openstack_groups"
   }
 ]
   }
]
(paste in case the spacing makes this unreadable: 
http://paste.openstack.org/show/730623/ )

But now, we no longer have a list of strings but something more like [{"name": "A", "domain_name": "Default"} {"name": "B", 
"domain_name": "Default", "name": "A", "domain_name": "domainB"}]. Since {0} isn't a string, this example doesn't really work. Instead, 
let's assume that in step (3) we converted the decoded AttributeValue text to an object. Then the mapping could look more like this:
 
[

   {
 "local":
 [
   {
 "group":
 {
   "name": "{0.name}",
   "domain":
   {
 "name": "{0.domain_name}"
   }
 }
   }
 ], "remote":
 [
   {
 "type": "openstack_groups"
   }
 ]
   }
]
(paste: http://paste.openstack.org/show/730622/ )

Alternatively, we could forget about the namespacing problem and simply say we 
only pass group names in the assertion, and if you have ambiguous group names 
you're on your own. We could also try to support both, 

Re: [openstack-dev] [penstack-dev]Discussion about the future of OpenStack in China

[Jay Pipes]

Fred,

I had a hard time understanding the articles. I'm not sure if you used 
Google Translate to do the translation from Chinese to English, but I 
personally found both of them difficult to follow.


There were a couple points that I did manage to decipher, though. One 
thing that both articles seemed to say was that OpenStack doesn't meet 
public (AWS-ish) cloud use cases and OpenStack doesn't compare favorably 
to VMWare either.


Is there a large contingent of Chinese OpenStack users that expect 
OpenStack to be a free (as in beer) version of VMware technology?


What are the 3 most important features that Chinese OpenStack users 
would like to see included in OpenStack projects?


Thanks,
-jay

On 09/24/2018 11:10 AM, Fred Li wrote:

Hi folks,

Recently there are several blogs which discussed about the future of 
OpenStack. If I was not wrong, the first one is 
"OpenStack-8-year-itch"[1], and you can find its English version 
attached. Thanks to google translation. The second one is 
"5-years-my-opinion-on-OpenStack" [2] with English version attached as 
well. Please translate the 3 to 6 and read them if you are interested.


I don't want to judge anything here. I just want to share as they are 
quite hot discussion and I think it is valuable for the whole community, 
not part of community to know.


[1] https://mp.weixin.qq.com/s/GM5cMOl0q3hb_6_eEiixzA
[2] https://mp.weixin.qq.com/s/qZkE4o_BHBPlbIjekjDRKw
[3] https://mp.weixin.qq.com/s/svX4z3JM5ArQ57A1jFoyLw
[4] https://mp.weixin.qq.com/s/Nyb0OxI2Z7LxDpofTTyWOg
[5] https://mp.weixin.qq.com/s/5GV4i8kyedHSbCxCO1VBRw
[6] https://mp.weixin.qq.com/s/yeBcMogumXKGQ0KyKrgbqA
--
Regards
Fred Li (李永乐)


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



__
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] Week R-29 Update

[Ben Nemec]

On 09/22/2018 11:15 AM, Matt Riedemann wrote:

On 9/21/2018 4:19 PM, Ben Nemec wrote:
* The only two projects that I'm aware of with patches up at this 
point are monasca [2] and designate [3]. The monasca one is tricky 
because as I've found going through release notes for some projects, 
they don't really have any major upgrade impacts so writing checks is 
not obvious. I don't have a great solution here. What monasca has 
done is add the framework with a noop check. If others are in the 
same situation, I'd like to hear your thoughts on what you think 
makes sense here. The alternative is these projects opt out of the 
goal for Stein and just add the check code later when it makes sense 
(but people might forget or not care to do that later if it's not a 
goal).


My inclination is for the command to exist with a noop check, the main 
reason being that if we create it for everyone this cycle then the 
deployment tools can implement calls to the status commands all at 
once. If we wait until checks are needed then someone has to not only 
implement it in the service but also remember to go update all of the 
deployment tools. Implementing a noop check should be pretty trivial 
with the library so it isn't a huge imposition.


Yeah, I agree, and I've left comments on the patch to give some ideas on 
how to write the noop check with a description that explains it's an 
initial check but doesn't really do anything. The alternative would be 
to dump the table header for the results but then not have any rows, 
which could be more confusing.




+1 to "this page intentionally left blank", hopefully without the 
logical contradiction those pages always create. ;-)


__
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] upgradecheck core list populated

[Ben Nemec]

Hey,

The oslo.upgradecheck core list is now populated. oslo-core and Matt 
Riedemann should have +2 rights on it, so review away! :-)


-Ben

__
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] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Mon, Sep 24, 2018, at 4:35 PM, Lance Bragstad wrote:
> On Mon, Sep 24, 2018 at 9:31 AM Colleen Murphy  wrote:
> 
> > On Mon, Sep 24, 2018, at 4:16 PM, Lance Bragstad wrote:
> > > On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy 
> > wrote:
> > >
> > > > This is in regard to https://launchpad.net/bugs/1641625 and the
> > proposed
> > > > patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> > > > getting the ball rolling.
> > > >
> > > > tl;dr: Keystone as an IdP should support sending
> > > > non-strings/lists-of-strings as user attribute values, specifically
> > lists
> > > > of keystone groups, here's how that might happen.
> > > >
> > > > Problem statement:
> > > >
> > > > When keystone is set up as a service provider with an external
> > > > non-keystone identity provider, it is common to configure the mapping
> > rules
> > > > to accept a list of group names from the IdP and map them to some
> > property
> > > > of a local keystone user, usually also a keystone group name. When
> > keystone
> > > > acts as the IdP, it's not currently possible to send a group name as a
> > user
> > > > property in the assertion. There are a few problems:
> > > >
> > > > 1. We haven't added any openstack_groups key in the creation of the
> > > > SAML assertion (
> > > >
> > http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> > > > ).
> > > > 2. If we did, this would not be enough. Unlike other IdPs, in
> > keystone
> > > > there can be multiple groups with the same name, namespaced by domain.
> > So
> > > > it's not enough for the SAML AttributeStatement to contain a
> > > > semi-colon-separated list of group names, since a user could
> > theoretically
> > > > be a member of two or more groups with the same name.
> > > >* Why can't we just send group IDs, which are unique? Because two
> > > > different keystones are not going to have independent groups with the
> > same
> > > > UUID, so we cannot possibly map an ID of a group from keystone A to
> > the ID
> > > > of a different group in keystone B. We could map the ID of the group
> > in in
> > > > A to the name of a group in B but then operators need to create groups
> > with
> > > > UUIDs as names which is a little awkward for both the operator and the
> > user
> > > > who now is a member of groups with nondescriptive names.
> > > > 3. If we then were able to encode a complex type like a group dict
> > in
> > > > a SAML assertion, we'd have to deal with it on the service provider
> > side by
> > > > being able to parse such an environment variable from the Apache
> > headers.
> > > > 4. The current mapping rules engine uses basic python string
> > > > formatting to translate remote key-value pairs to local rules. We would
> > > > need to change the mapping API to work with values more complex than
> > > > strings and lists of strings.
> > > >
> > > > Possible solution:
> > > >
> > > > Vishakha's patch (https://review.openstack.org/588211) starts to solve
> > > > (1) but it doesn't go far enough to solve (2-4). What we talked about
> > at
> > > > the PTG was:
> > > >
> > > > 2. Encode the group+domain as a string, for example by using the
> > dict
> > > > string repr or a string representation of some custom XML and maybe
> > base64
> > > > encoding it.
> > > > * It's not totally clear whether the AttributeValue class of
> > the
> > > > pysaml2 library supports any data types outside of the xmlns:xs
> > namespace
> > > > or whether nested XML is an option, so encoding the whole thing as an
> > > > xs:string seems like the simplest solution.
> > > >
> > >
> > > Encoding this makes sense. We can formally support different SAML data
> > > types in the future if a better solution comes along. We would have to
> > make
> > > the service provider deal with both types of encoding, but we could
> > > eventually consolidate, and users shouldn't know the difference. Right?
> >
> > The only way this would make a difference to the user is if they need to
> > debug a request by actually looking at the response to this request[1]. If
> > we were to base64-encode the string that immediately obfuscates what the
> > actual value is. I'm not really sure if we need to base64-encode it or just
> > serialize it some other way.
> >
> 
> Oh - yeah that makes sense. In your opinion, does that prevent us from
> adopting another way of solving the problem if we find a better data type?

Not 100% sure. The format of the SAML assertion is part of our API so we do 
have to be really careful about changing it, that's why I nacked the current 
patch. But how much leeway we have might depend on what the alternate solution 
is: maybe if the end result changes the NameFormat or the xsi:type of the 
Attribute, and we still support the xsi:type="xs:string" solution (the one 
we're discussing now), that might be okay?

> 
> 
> >
> > [1]
> > 

[openstack-dev] [cinder][forum] Need Topics for Berlin Forum ...

[Jay S Bryant]

Team,

Just a reminder that we have an etherpad to plan topics for the Forum in 
Berlin [1].  We are short on topics right now so please take some time 
to think about what we should talk about.  I am also planning time for 
this discussion during our Wednesday meeting this week.


Thanks for taking time to consider topics!

Jay

(jungleboyj)

[1] https://etherpad.openstack.org/p/cinder-berlin-forum-proposals


__
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-sigs] [all][tc] We're combining the lists!

[Zane Bitter]

On 20/09/18 5:46 PM, Doug Hellmann wrote:

Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:

tl;dr: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list.


Since last week there was some discussion of including the openstack-tc
mailing list among these lists to eliminate confusion caused by the fact
that the list is not configured to accept messages from all subscribers
(it's meant to be used for us to make sure TC members see meeting
announcements).

I'm inclined to include it and either use a direct mailing or the
[tc] tag on the new discuss list to reach TC members, but I would
like to hear feedback from TC members and other interested parties
before calling that decision made. Please let me know what you think.


+1. I already sort mail to the -tc list and mail to the -dev list with 
the [tc] tag into the same mailbox, so the value to me of having a list 
that only TC members can post to without moderation is zero.


- ZB

__
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] [Forum] Forum Topic Submission Period - Time Running out!

[Jimmy McArthur]

Just a reminder that there is a little more than 60 hours left to submit 
your forum topics.  Please make haste to the Forum submission tool:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Cheers,
Jimmy


Jimmy McArthur 
September 17, 2018 at 11:13 AM
Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th.  Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step on 
up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy

___
Openstack-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs


__
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] Forum Topic Submission Period

[Jay S Bryant]

Thank you sir!

Jay


On 9/24/2018 10:10 AM, Jimmy McArthur wrote:

Yes - we are taking submissions through Wednesday :)


Jay S Bryant 
September 24, 2018 at 10:03 AM

Jimmy,

Having a little trouble getting topics for Cinder.  Hoping to wrangle 
up more in our meeting on Wednesday.  Wanted to make sure that we 
could submit topics on Wednesday.  That is how I interpreted your 
note but wanted to be better safe than sorry.


Thanks!
Jay



On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

__
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
Jimmy McArthur 
September 17, 2018 at 11:13 AM
Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th. Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step 
on up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum. URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy

___
Openstack-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs




__
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] Forum Topic Submission Period

[Jimmy McArthur]

Yes - we are taking submissions through Wednesday :)


Jay S Bryant 
September 24, 2018 at 10:03 AM

Jimmy,

Having a little trouble getting topics for Cinder.  Hoping to wrangle 
up more in our meeting on Wednesday.  Wanted to make sure that we 
could submit topics on Wednesday.  That is how I interpreted your note 
but wanted to be better safe than sorry.


Thanks!
Jay



On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

__
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
Jimmy McArthur 
September 17, 2018 at 11:13 AM
Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th.  Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step on 
up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy

___
Openstack-track-chairs mailing list
openstack-track-cha...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-track-chairs


__
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] Forum Topic Submission Period

[Jay S Bryant]

Jimmy,

Having a little trouble getting topics for Cinder.  Hoping to wrangle up 
more in our meeting on Wednesday.  Wanted to make sure that we could 
submit topics on Wednesday.  That is how I interpreted your note but 
wanted to be better safe than sorry.


Thanks!
Jay



On 9/17/2018 11:13 AM, Jimmy McArthur wrote:

Hello Everyone!

The Forum Topic Submission session started September 12 and will run 
through September 26th. Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum 
topics through. Don't rely only on a PTL to make the agenda... step on 
up and place the items you consider important front and center.


As you may have noticed on the Forum Wiki 
(https://wiki.openstack.org/wiki/Forum), we're reusing the normal CFP 
tool this year. We did our best to remove Summit specific language, 
but if you notice something, just know that you are submitting to the 
Forum.  URL is here:


https://www.openstack.org/summit/berlin-2018/call-for-presentations

Looking forward to seeing everyone's submissions!

If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
Jimmy



__
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] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Lance Bragstad]

On Mon, Sep 24, 2018 at 9:31 AM Colleen Murphy  wrote:

> On Mon, Sep 24, 2018, at 4:16 PM, Lance Bragstad wrote:
> > On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy 
> wrote:
> >
> > > This is in regard to https://launchpad.net/bugs/1641625 and the
> proposed
> > > patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> > > getting the ball rolling.
> > >
> > > tl;dr: Keystone as an IdP should support sending
> > > non-strings/lists-of-strings as user attribute values, specifically
> lists
> > > of keystone groups, here's how that might happen.
> > >
> > > Problem statement:
> > >
> > > When keystone is set up as a service provider with an external
> > > non-keystone identity provider, it is common to configure the mapping
> rules
> > > to accept a list of group names from the IdP and map them to some
> property
> > > of a local keystone user, usually also a keystone group name. When
> keystone
> > > acts as the IdP, it's not currently possible to send a group name as a
> user
> > > property in the assertion. There are a few problems:
> > >
> > > 1. We haven't added any openstack_groups key in the creation of the
> > > SAML assertion (
> > >
> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> > > ).
> > > 2. If we did, this would not be enough. Unlike other IdPs, in
> keystone
> > > there can be multiple groups with the same name, namespaced by domain.
> So
> > > it's not enough for the SAML AttributeStatement to contain a
> > > semi-colon-separated list of group names, since a user could
> theoretically
> > > be a member of two or more groups with the same name.
> > >* Why can't we just send group IDs, which are unique? Because two
> > > different keystones are not going to have independent groups with the
> same
> > > UUID, so we cannot possibly map an ID of a group from keystone A to
> the ID
> > > of a different group in keystone B. We could map the ID of the group
> in in
> > > A to the name of a group in B but then operators need to create groups
> with
> > > UUIDs as names which is a little awkward for both the operator and the
> user
> > > who now is a member of groups with nondescriptive names.
> > > 3. If we then were able to encode a complex type like a group dict
> in
> > > a SAML assertion, we'd have to deal with it on the service provider
> side by
> > > being able to parse such an environment variable from the Apache
> headers.
> > > 4. The current mapping rules engine uses basic python string
> > > formatting to translate remote key-value pairs to local rules. We would
> > > need to change the mapping API to work with values more complex than
> > > strings and lists of strings.
> > >
> > > Possible solution:
> > >
> > > Vishakha's patch (https://review.openstack.org/588211) starts to solve
> > > (1) but it doesn't go far enough to solve (2-4). What we talked about
> at
> > > the PTG was:
> > >
> > > 2. Encode the group+domain as a string, for example by using the
> dict
> > > string repr or a string representation of some custom XML and maybe
> base64
> > > encoding it.
> > > * It's not totally clear whether the AttributeValue class of
> the
> > > pysaml2 library supports any data types outside of the xmlns:xs
> namespace
> > > or whether nested XML is an option, so encoding the whole thing as an
> > > xs:string seems like the simplest solution.
> > >
> >
> > Encoding this makes sense. We can formally support different SAML data
> > types in the future if a better solution comes along. We would have to
> make
> > the service provider deal with both types of encoding, but we could
> > eventually consolidate, and users shouldn't know the difference. Right?
>
> The only way this would make a difference to the user is if they need to
> debug a request by actually looking at the response to this request[1]. If
> we were to base64-encode the string that immediately obfuscates what the
> actual value is. I'm not really sure if we need to base64-encode it or just
> serialize it some other way.
>

Oh - yeah that makes sense. In your opinion, does that prevent us from
adopting another way of solving the problem if we find a better data type?


>
> [1]
> https://developer.openstack.org/api-ref/identity/v3-ext/index.html#id404
> >
> >
> > > 3. The SP will have to be aware that openstack_groups is a special
> key
> > > that needs the encoding reversed.
> > > * I wrote down "MultiDict" in my notes but I don't recall
> exactly
> > > what format the environment variable would take that would make a
> MultiDict
> > > make sense here, in any case I think encoding the whole thing as a
> string
> > > eliminates the need for this.
> > > 4. We didn't talk about the mapping API, but here's what I think.
> If
> > > we were just talking about group names, the mapping API today would
> work
> > > like this (slight oversimplification for brevity):
> > >
> > > Given a list of openstack_groups like ["A", "B", 

Re: [openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Mon, Sep 24, 2018, at 4:16 PM, Lance Bragstad wrote:
> On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy  wrote:
> 
> > This is in regard to https://launchpad.net/bugs/1641625 and the proposed
> > patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> > getting the ball rolling.
> >
> > tl;dr: Keystone as an IdP should support sending
> > non-strings/lists-of-strings as user attribute values, specifically lists
> > of keystone groups, here's how that might happen.
> >
> > Problem statement:
> >
> > When keystone is set up as a service provider with an external
> > non-keystone identity provider, it is common to configure the mapping rules
> > to accept a list of group names from the IdP and map them to some property
> > of a local keystone user, usually also a keystone group name. When keystone
> > acts as the IdP, it's not currently possible to send a group name as a user
> > property in the assertion. There are a few problems:
> >
> > 1. We haven't added any openstack_groups key in the creation of the
> > SAML assertion (
> > http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> > ).
> > 2. If we did, this would not be enough. Unlike other IdPs, in keystone
> > there can be multiple groups with the same name, namespaced by domain. So
> > it's not enough for the SAML AttributeStatement to contain a
> > semi-colon-separated list of group names, since a user could theoretically
> > be a member of two or more groups with the same name.
> >* Why can't we just send group IDs, which are unique? Because two
> > different keystones are not going to have independent groups with the same
> > UUID, so we cannot possibly map an ID of a group from keystone A to the ID
> > of a different group in keystone B. We could map the ID of the group in in
> > A to the name of a group in B but then operators need to create groups with
> > UUIDs as names which is a little awkward for both the operator and the user
> > who now is a member of groups with nondescriptive names.
> > 3. If we then were able to encode a complex type like a group dict in
> > a SAML assertion, we'd have to deal with it on the service provider side by
> > being able to parse such an environment variable from the Apache headers.
> > 4. The current mapping rules engine uses basic python string
> > formatting to translate remote key-value pairs to local rules. We would
> > need to change the mapping API to work with values more complex than
> > strings and lists of strings.
> >
> > Possible solution:
> >
> > Vishakha's patch (https://review.openstack.org/588211) starts to solve
> > (1) but it doesn't go far enough to solve (2-4). What we talked about at
> > the PTG was:
> >
> > 2. Encode the group+domain as a string, for example by using the dict
> > string repr or a string representation of some custom XML and maybe base64
> > encoding it.
> > * It's not totally clear whether the AttributeValue class of the
> > pysaml2 library supports any data types outside of the xmlns:xs namespace
> > or whether nested XML is an option, so encoding the whole thing as an
> > xs:string seems like the simplest solution.
> >
> 
> Encoding this makes sense. We can formally support different SAML data
> types in the future if a better solution comes along. We would have to make
> the service provider deal with both types of encoding, but we could
> eventually consolidate, and users shouldn't know the difference. Right?

The only way this would make a difference to the user is if they need to debug 
a request by actually looking at the response to this request[1]. If we were to 
base64-encode the string that immediately obfuscates what the actual value is. 
I'm not really sure if we need to base64-encode it or just serialize it some 
other way.

[1] https://developer.openstack.org/api-ref/identity/v3-ext/index.html#id404
> 
> 
> > 3. The SP will have to be aware that openstack_groups is a special key
> > that needs the encoding reversed.
> > * I wrote down "MultiDict" in my notes but I don't recall exactly
> > what format the environment variable would take that would make a MultiDict
> > make sense here, in any case I think encoding the whole thing as a string
> > eliminates the need for this.
> > 4. We didn't talk about the mapping API, but here's what I think. If
> > we were just talking about group names, the mapping API today would work
> > like this (slight oversimplification for brevity):
> >
> > Given a list of openstack_groups like ["A", "B", "C"], it would work like
> > this:
> >
> > [
> >   {
> > "local":
> > [
> >   {
> > "group":
> > {
> >   "name": "{0}",
> >   "domain":
> >   {
> > "name": "federated_domain"
> >   }
> > }
> >   }
> > ], "remote":
> > [
> >   {
> > "type": "openstack_groups"
> >   }
> > ]
> >   }
> > ]
> > (paste in case the 

Re: [openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Lance Bragstad]

On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy  wrote:

> This is in regard to https://launchpad.net/bugs/1641625 and the proposed
> patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> getting the ball rolling.
>
> tl;dr: Keystone as an IdP should support sending
> non-strings/lists-of-strings as user attribute values, specifically lists
> of keystone groups, here's how that might happen.
>
> Problem statement:
>
> When keystone is set up as a service provider with an external
> non-keystone identity provider, it is common to configure the mapping rules
> to accept a list of group names from the IdP and map them to some property
> of a local keystone user, usually also a keystone group name. When keystone
> acts as the IdP, it's not currently possible to send a group name as a user
> property in the assertion. There are a few problems:
>
> 1. We haven't added any openstack_groups key in the creation of the
> SAML assertion (
> http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> ).
> 2. If we did, this would not be enough. Unlike other IdPs, in keystone
> there can be multiple groups with the same name, namespaced by domain. So
> it's not enough for the SAML AttributeStatement to contain a
> semi-colon-separated list of group names, since a user could theoretically
> be a member of two or more groups with the same name.
>* Why can't we just send group IDs, which are unique? Because two
> different keystones are not going to have independent groups with the same
> UUID, so we cannot possibly map an ID of a group from keystone A to the ID
> of a different group in keystone B. We could map the ID of the group in in
> A to the name of a group in B but then operators need to create groups with
> UUIDs as names which is a little awkward for both the operator and the user
> who now is a member of groups with nondescriptive names.
> 3. If we then were able to encode a complex type like a group dict in
> a SAML assertion, we'd have to deal with it on the service provider side by
> being able to parse such an environment variable from the Apache headers.
> 4. The current mapping rules engine uses basic python string
> formatting to translate remote key-value pairs to local rules. We would
> need to change the mapping API to work with values more complex than
> strings and lists of strings.
>
> Possible solution:
>
> Vishakha's patch (https://review.openstack.org/588211) starts to solve
> (1) but it doesn't go far enough to solve (2-4). What we talked about at
> the PTG was:
>
> 2. Encode the group+domain as a string, for example by using the dict
> string repr or a string representation of some custom XML and maybe base64
> encoding it.
> * It's not totally clear whether the AttributeValue class of the
> pysaml2 library supports any data types outside of the xmlns:xs namespace
> or whether nested XML is an option, so encoding the whole thing as an
> xs:string seems like the simplest solution.
>

Encoding this makes sense. We can formally support different SAML data
types in the future if a better solution comes along. We would have to make
the service provider deal with both types of encoding, but we could
eventually consolidate, and users shouldn't know the difference. Right?


> 3. The SP will have to be aware that openstack_groups is a special key
> that needs the encoding reversed.
> * I wrote down "MultiDict" in my notes but I don't recall exactly
> what format the environment variable would take that would make a MultiDict
> make sense here, in any case I think encoding the whole thing as a string
> eliminates the need for this.
> 4. We didn't talk about the mapping API, but here's what I think. If
> we were just talking about group names, the mapping API today would work
> like this (slight oversimplification for brevity):
>
> Given a list of openstack_groups like ["A", "B", "C"], it would work like
> this:
>
> [
>   {
> "local":
> [
>   {
> "group":
> {
>   "name": "{0}",
>   "domain":
>   {
> "name": "federated_domain"
>   }
> }
>   }
> ], "remote":
> [
>   {
> "type": "openstack_groups"
>   }
> ]
>   }
> ]
> (paste in case the spacing makes this unreadable:
> http://paste.openstack.org/show/730623/ )
>
> But now, we no longer have a list of strings but something more like
> [{"name": "A", "domain_name": "Default"} {"name": "B", "domain_name":
> "Default", "name": "A", "domain_name": "domainB"}]. Since {0} isn't a
> string, this example doesn't really work. Instead, let's assume that in
> step (3) we converted the decoded AttributeValue text to an object. Then
> the mapping could look more like this:
>
> [
>   {
> "local":
> [
>   {
> "group":
> {
>   "name": "{0.name}",
>   "domain":
>   {
> "name": "{0.domain_name}"
> 

[openstack-dev] [neutron] Bug deputy report week of Sept 17

[Boden Russell]

Below is a summary of last weeks bug activity.
I've tried to organize the summary to highlight those bugs that still
need attention.
Thanks


Needs additional technical triage:
- [dvr][ha][dataplane down] router_gateway port binding host goes wrong
after the 'master' host down/up
https://bugs.launchpad.net/neutron/+bug/1793529
- q-dhcp crashes with guru meditation on ironic's grenade
https://bugs.launchpad.net/neutron/+bug/1792925
- [RFE] Enable other projects to extend l2pop fdb information
https://bugs.launchpad.net/neutron/+bug/1793653

Under discussion:
- Egress UDP traffic is dropped
https://bugs.launchpad.net/neutron/+bug/1793244
- ha_vrrp_health_check_interval causes constantly VRRP transitions
https://bugs.launchpad.net/neutron/+bug/1793102
- subnet pool can not delete prefixes
https://bugs.launchpad.net/neutron/+bug/1792901
- external_gateway_info enable_snat attribute should be owner-modifiable
https://bugs.launchpad.net/neutron/+bug/1793207

Triaged, but no assignee:
- DB deadlock when delete subnet
https://bugs.launchpad.net/neutron/+bug/1793516
- public-subnet not explained
https://bugs.launchpad.net/neutron/+bug/1793103
- adding 0.0.0.0/0 address pair to a port bypasses all other vm security
groups https://bugs.launchpad.net/neutron/+bug/1793029
- The user can delete a security group which is used as remote-group-id
https://bugs.launchpad.net/neutron/+bug/1792890

In progress:
- [dvr_no_external][ha][dataplane down]centralized floating IP nat rules
not install in every HA node https://bugs.launchpad.net/neutron/+bug/1793527
- Subnet update with the subnet's current segment_id fail with:
NoUpdateSubnetWhenMultipleSegmentsOnNetwork
https://bugs.launchpad.net/neutron/+bug/1793391
- Changing of_interface between native and ovs-ofctl causes packet drops
https://bugs.launchpad.net/neutron/+bug/1793354
- Router: add port doesn't take IP from allocation pool
https://bugs.launchpad.net/neutron/+bug/1793094

__
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] RFC: Next minimum libvirt / QEMU versions for 'T' release

[Kashyap Chamarthy]

Hey folks,

Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
versions for the 'T' (which is still in the naming phase) release, which
will come out in the autumn (Sep-Nov) of 2019.

Proposal


Looking at the DistroSupportMatrix[2], it seems like we can pick the
libvirt and QEMU versions supported by the next LTS release of Ubuntu --
18.04; "Bionic", which are:

libvirt: 4.0.0
QEMU:2.11

Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
above versions.  And it seems reasonable to assume that the enterprise
distribtions will also ship the said versions pretty soon; but let's
double-confirm below.

Considerations and open questions
-

(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
"IBM announced that KVM for IBM z will be withdrawn, effective March
31, 2018 [...] development will not only continue unaffected, but
the options for users grow, especially with the recent addition of
SuSE to the existing support in Ubuntu."

The message seems to be: "use a regular distribution".  So this is
covered, if we a version based on other distributions.

(b) Oracle Linux: Can you please confirm if you'll be able to
release libvirt and QEMU to 4.0.0 and 2.11, respectively?

(c) SLES: Same question as above.

Assuming Oracle Linux and SLES confirm, please let us know if there are
any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
release to be libvirt: 4.0.0 and QEMU: 2.11.

* * *

A refresher on libvirt and QEMU release schedules
-

  - There will be at least 12 libvirt releases (_excluding_ maintenance
releases) by Autumn 2019.  A new libvirt release comes out every
month[4].

  - And there will be about 4 releases of QEMU.  A new QEMU release
comes out once every four months.

[1] http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b
-- Pick next minimum libvirt / QEMU versions for "Stein"
[2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
[3] http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html
[4] https://libvirt.org/downloads.html#schedule

-- 
/kashyap

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

[openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

This is in regard to https://launchpad.net/bugs/1641625 and the proposed patch 
https://review.openstack.org/588211 for it. Thanks Vishakha for getting the 
ball rolling.

tl;dr: Keystone as an IdP should support sending non-strings/lists-of-strings 
as user attribute values, specifically lists of keystone groups, here's how 
that might happen.

Problem statement:

When keystone is set up as a service provider with an external non-keystone 
identity provider, it is common to configure the mapping rules to accept a list 
of group names from the IdP and map them to some property of a local keystone 
user, usually also a keystone group name. When keystone acts as the IdP, it's 
not currently possible to send a group name as a user property in the 
assertion. There are a few problems:

1. We haven't added any openstack_groups key in the creation of the SAML 
assertion 
(http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164).
2. If we did, this would not be enough. Unlike other IdPs, in keystone 
there can be multiple groups with the same name, namespaced by domain. So it's 
not enough for the SAML AttributeStatement to contain a semi-colon-separated 
list of group names, since a user could theoretically be a member of two or 
more groups with the same name.
   * Why can't we just send group IDs, which are unique? Because two different 
keystones are not going to have independent groups with the same UUID, so we 
cannot possibly map an ID of a group from keystone A to the ID of a different 
group in keystone B. We could map the ID of the group in in A to the name of a 
group in B but then operators need to create groups with UUIDs as names which 
is a little awkward for both the operator and the user who now is a member of 
groups with nondescriptive names.
3. If we then were able to encode a complex type like a group dict in a 
SAML assertion, we'd have to deal with it on the service provider side by being 
able to parse such an environment variable from the Apache headers.
4. The current mapping rules engine uses basic python string formatting to 
translate remote key-value pairs to local rules. We would need to change the 
mapping API to work with values more complex than strings and lists of strings.

Possible solution:

Vishakha's patch (https://review.openstack.org/588211) starts to solve (1) but 
it doesn't go far enough to solve (2-4). What we talked about at the PTG was:

2. Encode the group+domain as a string, for example by using the dict 
string repr or a string representation of some custom XML and maybe base64 
encoding it.
* It's not totally clear whether the AttributeValue class of the 
pysaml2 library supports any data types outside of the xmlns:xs namespace or 
whether nested XML is an option, so encoding the whole thing as an xs:string 
seems like the simplest solution.
3. The SP will have to be aware that openstack_groups is a special key that 
needs the encoding reversed.
* I wrote down "MultiDict" in my notes but I don't recall exactly what 
format the environment variable would take that would make a MultiDict make 
sense here, in any case I think encoding the whole thing as a string eliminates 
the need for this.
4. We didn't talk about the mapping API, but here's what I think. If we 
were just talking about group names, the mapping API today would work like this 
(slight oversimplification for brevity):

Given a list of openstack_groups like ["A", "B", "C"], it would work like this:

[
  {
"local": 
[
  {
"group": 
{
  "name": "{0}", 
  "domain":
  {
"name": "federated_domain"
  }
}
  }
], "remote": 
[
  {
"type": "openstack_groups"
  }
]
  }
]
(paste in case the spacing makes this unreadable: 
http://paste.openstack.org/show/730623/ )

But now, we no longer have a list of strings but something more like [{"name": 
"A", "domain_name": "Default"} {"name": "B", "domain_name": "Default", "name": 
"A", "domain_name": "domainB"}]. Since {0} isn't a string, this example doesn't 
really work. Instead, let's assume that in step (3) we converted the decoded 
AttributeValue text to an object. Then the mapping could look more like this:

[
  {
"local": 
[
  {
"group": 
{
  "name": "{0.name}", 
  "domain":
  {
"name": "{0.domain_name}"
  }
}
  }
], "remote": 
[
  {
"type": "openstack_groups"
  }
]
  }
]
(paste: http://paste.openstack.org/show/730622/ )

Alternatively, we could forget about the namespacing problem and simply say we 
only pass group names in the assertion, and if you have ambiguous group names 
you're on your own. We could also try to support both, e.g. have an 
openstack_groups mean a list of group names for simpler use cases, and 

Re: [openstack-dev] [ironic] status of the zuulv3 job migration

[Derek Higgins]

On Fri, 21 Sep 2018 at 11:16, Derek Higgins  wrote:

> Just quick summary of the status and looking for some input about the
> experimental jobs
>
> 15 jobs are now done, with another 2 ready for reviewing. This leaves 6
> jobs
> 1 x multinode job
>I've yet to finished porting this one
> 2 x grenade jobs
>Last time I looked grenade jobs couldn't yet be ported to zuulv3 native
> but I'll investigate further
>
> 3 x experimental jobs
> (ironic-dsvm-functional, ironic-tempest-dsvm-parallel, 
> ironic-tempest-dsvm-pxe_ipa-full)
> These don't currently pass and it doesn't look like anybody is using
> them, So I'd like to know if there is anybody out there interested in them,
> if not I'll go ahead and remove them.
>
Job removal proposed here https://review.openstack.org/#/c/591675/

>
> thanks,
> Derek.
>
__
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] [ptg] Post-lunch presentations schedule

[Stephen Finucane]

On Tue, 2018-09-18 at 12:42 +, Bedyk, Witold wrote:
> Stephen,
> 
> could you please share your presentation slides?
> 
> Thanks
> Witek

Yup. They're available here:

https://docs.google.com/presentation/d/1gaRFmUEJEmy-8lCFsxauQLZNB2ch4hPQ0L4yO11vgL0/edit

Stephen

> 
> > -Original Message-
> > From: Thierry Carrez 
> > Sent: Freitag, 24. August 2018 11:21
> > To: OpenStack Development Mailing List  > d...@lists.openstack.org>
> > Subject: [openstack-dev] [ptg] Post-lunch presentations schedule
> 
> 
> 
> > Friday: Lightning talks
> > Fast-paced 5-min segments to talk about anything... Summaries of
> > team
> > plans for Stein encouraged. A presentation of Sphinx in OpenStack
> > by
> > stephenfin will open the show.
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [goals][python3][nova] starting zuul migration for nova repos

[Balázs Gibizer]

On Mon, Sep 24, 2018 at 11:10 AM, Andreas Jaeger  wrote:
> On 11/09/2018 19.13, Stephen Finucane wrote:
>> On Mon, 2018-09-10 at 13:48 -0600, Doug Hellmann wrote:
>>> Melanie gave me the go-ahead to propose the patches, so here's the 
>>> list
>>> of patches for the zuul migration, doc job update, and python 3.6 
>>> unit
>>> tests for the nova repositories.
>> 
>> I've reviewed/+2d all of these on master and think Sylvain will be
>> following up with the +Ws. I need someone else to handle the
>> 'stable/XXX' patches though.
>> 
>> Here's a query for anyone that wants to jump in here.
>> 
>> https://review.openstack.org/#/q/topic:python3-first+status:open+(openstack/nova+OR+project:openstack/nova-specs+OR+openstack/os-traits+OR+openstack/os-vif+OR+openstack/osc-placement+OR+openstack/python-novaclient)
> 
> Most of these are merged - with exception of stable changes and 
> changes to osc-placement. Any nova stable reviewers around to finish 
> this, please?

I've +A-d the osc-placement patches but I cannot do the same for the 
stale patches.
Cheers,
gibi

> 
> Thanks,
> Andreas
> 
> 
>> 
>> Stephen
>> 
>> PS: Thanks, Andreas, for the follow-up cleanup patches. Much
>> appreciated :)
>> 
>>> +--++---+
 Subject  | Repo
| Branch|
>>> 
>>> +--++---+
 remove job settings for nova repositories| 
 openstack-infra/project-config | master|
 import zuul job settings from project-config | openstack/nova  
| master|
 switch documentation job to new PTI  | openstack/nova  
| master|
 add python 3.6 unit test job | openstack/nova  
| master|
 import zuul job settings from project-config | openstack/nova  
| stable/ocata  |
 import zuul job settings from project-config | openstack/nova  
| stable/pike   |
 import zuul job settings from project-config | openstack/nova  
| stable/queens |
 import zuul job settings from project-config | openstack/nova  
| stable/rocky  |
 import zuul job settings from project-config | 
 openstack/nova-specs   | master|
 import zuul job settings from project-config | openstack/os-traits 
| master|
 switch documentation job to new PTI  | openstack/os-traits 
| master|
 add python 3.6 unit test job | openstack/os-traits 
| master|
 import zuul job settings from project-config | openstack/os-traits 
| stable/pike   |
 import zuul job settings from project-config | openstack/os-traits 
| stable/queens |
 import zuul job settings from project-config | openstack/os-traits 
| stable/rocky  |
 import zuul job settings from project-config | openstack/os-vif
| master|
 switch documentation job to new PTI  | openstack/os-vif
| master|
 add python 3.6 unit test job | openstack/os-vif
| master|
 import zuul job settings from project-config | openstack/os-vif
| stable/ocata  |
 import zuul job settings from project-config | openstack/os-vif
| stable/pike   |
 import zuul job settings from project-config | openstack/os-vif
| stable/queens |
 import zuul job settings from project-config | openstack/os-vif
| stable/rocky  |
 import zuul job settings from project-config | 
 openstack/osc-placement| master|
 switch documentation job to new PTI  | 
 openstack/osc-placement| master|
 add python 3.6 unit test job | 
 openstack/osc-placement| master|
 import zuul job settings from project-config | 
 openstack/osc-placement| stable/queens |
 import zuul job settings from project-config | 
 openstack/osc-placement| stable/rocky  |
 import zuul job settings from project-config | 
 openstack/python-novaclient| master|
 switch documentation job to new PTI  | 
 openstack/python-novaclient| master|
 add python 3.6 unit test job | 
 openstack/python-novaclient| master|
 add lib-forward-testing-python3 test job | 
 openstack/python-novaclient| master|
 import zuul job settings from project-config | 
 openstack/python-novaclient| stable/ocata  |
 import zuul job settings from project-config 

Re: [openstack-dev] [goals][python3][nova] starting zuul migration for nova repos

[Andreas Jaeger]

On 11/09/2018 19.13, Stephen Finucane wrote:

On Mon, 2018-09-10 at 13:48 -0600, Doug Hellmann wrote:

Melanie gave me the go-ahead to propose the patches, so here's the list
of patches for the zuul migration, doc job update, and python 3.6 unit
tests for the nova repositories.


I've reviewed/+2d all of these on master and think Sylvain will be
following up with the +Ws. I need someone else to handle the
'stable/XXX' patches though.

Here's a query for anyone that wants to jump in here.

https://review.openstack.org/#/q/topic:python3-first+status:open+(openstack/nova+OR+project:openstack/nova-specs+OR+openstack/os-traits+OR+openstack/os-vif+OR+openstack/osc-placement+OR+openstack/python-novaclient)


Most of these are merged - with exception of stable changes and changes 
to osc-placement. Any nova stable reviewers around to finish this, please?


Thanks,
Andreas




Stephen

PS: Thanks, Andreas, for the follow-up cleanup patches. Much
appreciated :)


+--++---+

Subject  | Repo   | 
Branch|


+--++---+

remove job settings for nova repositories| openstack-infra/project-config | 
master|
import zuul job settings from project-config | openstack/nova | 
master|
switch documentation job to new PTI  | openstack/nova | 
master|
add python 3.6 unit test job | openstack/nova | 
master|
import zuul job settings from project-config | openstack/nova | 
stable/ocata  |
import zuul job settings from project-config | openstack/nova | 
stable/pike   |
import zuul job settings from project-config | openstack/nova | 
stable/queens |
import zuul job settings from project-config | openstack/nova | 
stable/rocky  |
import zuul job settings from project-config | openstack/nova-specs   | 
master|
import zuul job settings from project-config | openstack/os-traits| 
master|
switch documentation job to new PTI  | openstack/os-traits| 
master|
add python 3.6 unit test job | openstack/os-traits| 
master|
import zuul job settings from project-config | openstack/os-traits| 
stable/pike   |
import zuul job settings from project-config | openstack/os-traits| 
stable/queens |
import zuul job settings from project-config | openstack/os-traits| 
stable/rocky  |
import zuul job settings from project-config | openstack/os-vif   | 
master|
switch documentation job to new PTI  | openstack/os-vif   | 
master|
add python 3.6 unit test job | openstack/os-vif   | 
master|
import zuul job settings from project-config | openstack/os-vif   | 
stable/ocata  |
import zuul job settings from project-config | openstack/os-vif   | 
stable/pike   |
import zuul job settings from project-config | openstack/os-vif   | 
stable/queens |
import zuul job settings from project-config | openstack/os-vif   | 
stable/rocky  |
import zuul job settings from project-config | openstack/osc-placement| 
master|
switch documentation job to new PTI  | openstack/osc-placement| 
master|
add python 3.6 unit test job | openstack/osc-placement| 
master|
import zuul job settings from project-config | openstack/osc-placement| 
stable/queens |
import zuul job settings from project-config | openstack/osc-placement| 
stable/rocky  |
import zuul job settings from project-config | openstack/python-novaclient| 
master|
switch documentation job to new PTI  | openstack/python-novaclient| 
master|
add python 3.6 unit test job | openstack/python-novaclient| 
master|
add lib-forward-testing-python3 test job | openstack/python-novaclient| 
master|
import zuul job settings from project-config | openstack/python-novaclient| 
stable/ocata  |
import zuul job settings from project-config | openstack/python-novaclient| 
stable/pike   |
import zuul job settings from project-config | openstack/python-novaclient| 
stable/queens |
import zuul job settings from project-config | openstack/python-novaclient| 
stable/rocky  |


+--++---+

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

[openstack-dev] [horizon] Horizon gates are broken

[Ivan Kolodyazhny]

Hi team,

Unfortunately, horizon gates are broken now. We can't merge any patch due
to the -1 from CI.
I don't want to disable tests now, that's why I proposed a fix [1].

We'd got released some of XStatic-* packages last week. At least new
XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for
requirements repo [4] to prevent such issues in the future.

Please, do not try 'recheck' until [1] will be merged.

[1] https://review.openstack.org/#/c/604611/
[2] https://pypi.org/project/XStatic-jQuery/#history
[3] https://bugs.launchpad.net/horizon/+bug/1794028
[4] https://review.openstack.org/#/c/604613/

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