[openstack-dev] [keystone] keystone client service_catalog is None

[Eric K]

Hi all,

I'm working on some code [1] that attempts to retrieve a endpoint from the
service_catalog, but the service_catalog comes up None. Any suggestions on
what I need to do differently to get a working service_catalog? Thanks
very much!

Python 2.7.12 (default, Nov 20 2017, 18:23:56)
[GCC 5.4.0 20160609] on linux2
>>> from keystoneauth1 import session # Version 2.12.1
>>> from keystoneauth1.identity import v2
>>> import keystoneclient.v3.client as ksclient
>>> auth = v2.Password(auth_url='http://127.0.0.1/identity',
>>>username='admin', password='password', tenant_name='admin')
>>> sess = session.Session(auth=auth)
>>> keystone = ksclient.Client(session=sess)
>>> print(keystone.service_catalog)
None



[1] 
https://review.openstack.org/#/c/526813/1/congress/datasources/monasca_driv
er.py@94



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

Re: [openstack-dev] [tripleo] [upgrade] CI status and Current effort.

[Emilien Macchi]

On Fri, Dec 8, 2017 at 11:42 AM, Emilien Macchi  wrote:
> On Fri, Dec 8, 2017 at 5:39 AM, Wesley Hayutin  wrote:
> [...]
>> Sofer, can you estimate when the redhat-openstack gerrit repo will be
>> dropped and the upstream
>> openstac/tripleo-upgrades role used in it's place.  I need to coordinate the
>> CI team to work you and
>> Jose Louis, however not using the upstream repo makes that difficult.
>
> When https://review.openstack.org/#/c/524141/ will be merged - we're
> working on that. Alex cleanup the repo, today I rebased the patch and
> added ansble-lint tests. When we have lint working, we'll probably
> merge the patch.
> From then, I don't see any blocker to use the upstream repo.

OK, https://review.openstack.org/#/c/524141/ is now ready for review.
I had to rebase
https://review.openstack.org/#/c/524141/2..4/templates/create_registry_env.sh.j2
- please carefully review this one.

Otherwise, we fixed lint and update the CI job, all looks good.
Once we land it, we need to make sure we have all commits from the old
repo, and then we need to kill the repo (following this commit:
https://github.com/openstack/puppet-tuskar/commit/d54150a1ad61034cb73c6160fb57956d30f2b2d9).
Then, use the new repo, and enjoy.

Thanks,
-- 
Emilien Macchi

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

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

[Moshe Levi]

Hi Alex, 

I don't see the tripleo ovs hardware offload feature. The spec was merge into 
queens [1], but for some reason the blueprint is not in approve state [2].

I has only 3 patches left: 
1.  https://review.openstack.org/#/c/507401/ has 2 +2
2.  https://review.openstack.org/#/c/507100/ has 1 +2 
3.  https://review.openstack.org/#/c/518715/

I would appreciated if we can land all the patches to  queens release. 

[1] - https://review.openstack.org/#/c/502313/
[2] - https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-hw-offload 

> -Original Message-
> From: Alex Schultz [mailto:aschu...@redhat.com]
> Sent: Saturday, December 9, 2017 1:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> 
> Hey folks,
> 
> So I went through the list of blueprints and moved some that were either not
> updated or appeared to have a bunch of patches not in a mergable state.
> 
> Please take some time to review the list of blueprints currently associated
> with Rocky[0] to see if your efforts have been moved. If you believe you're
> close to implementing the feature in the next week or two, let me know and
> we can move it back into Queens. If you think it will take an extended period
> of time (more than 2 weeks) to land but we need it in Queens, please submit
> an FFE.
> 
> If you have an blueprint that is currently not in implemented in Queens[1],
> please make sure to update the blueprint status if possible.  For the ones I
> left in due to the patches being in a decent state, please make sure those get
> merged in the next few weeks or we will need to push them out to Rocky.
> 
> Thanks,
> -Alex
> 
> 
> [0]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> eprints.launchpad.net%2Ftripleo%2Frocky=02%7C01%7Cmoshele%40
> mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4d
> 9ba6a4d149256f461b%7C0%7C0%7C636483729194465277=xDwvHSmx
> niqu6HN5FaQB2DTc6N8mRS879Ku1y4FDLss%3D=0
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> eprints.launchpad.net%2Ftripleo%2Fqueens=02%7C01%7Cmoshele%4
> 0mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4
> d9ba6a4d149256f461b%7C0%7C0%7C636483729194465277=v6v1yDjt1f
> dc3FAILGsS2voCiMUmaLQGPwwxNtTzcso%3D=0
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C0abe7d8deef74a13d2
> 9508d53e945633%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636
> 483729194465277=N%2B78nm8bMlSWsASO6uIX2mJlO1%2BX9VfTM2
> A3qUu6GUk%3D=0
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Eric K]

Ah sorry about that, Doug. And thank you for the pointer, Sean. I'm on it.

On 12/8/17, 2:10 PM, "Sean McGinnis"  wrote:

>On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
>> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
>> > Build failed.
>> > 
>> > - release-openstack-python-without-pypi
>>http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre
>>-release/release-openstack-python-without-pypi/8c423e5/ : FAILURE in 5m
>>53s
>> > - announce-release announce-release : SKIPPED
>> > 
>> 
>> This error looks like there is a bad file reference in the MANIFEST.in:
>> 
>> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
>> ERROR: InvocationError:
>> 
>>'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
>> setup.py bdist_wheel'
>> venv finish: runtests after 2.76 seconds
>
>I think this is needed to fix it. Some missing cleanup work from the
>policy-in-code activity.
>
>https://review.openstack.org/#/c/526274/
>
>
>__
>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] [tripleo] Blueprints moved out to Rocky

[Alex Schultz]

Hey folks,

So I went through the list of blueprints and moved some that were
either not updated or appeared to have a bunch of patches not in a
mergable state.

Please take some time to review the list of blueprints currently
associated with Rocky[0] to see if your efforts have been moved. If
you believe you're close to implementing the feature in the next week
or two, let me know and we can move it back into Queens. If you think
it will take an extended period of time (more than 2 weeks) to land
but we need it in Queens, please submit an FFE.

If you have an blueprint that is currently not in implemented in
Queens[1], please make sure to update the blueprint status if
possible.  For the ones I left in due to the patches being in a decent
state, please make sure those get merged in the next few weeks or we
will need to push them out to Rocky.

Thanks,
-Alex


[0] https://blueprints.launchpad.net/tripleo/rocky
[1] https://blueprints.launchpad.net/tripleo/queens

__
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, December 8th

[Thierry Carrez]

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker

If you are working on something (or plan to work on something) that is
not on the tracker, feel free to add to it !


== Recently-approved changes ==

* Officialize election organization working group [1]
* stop linking to documentation from governance [2]
* Tags are applied to deliverables, or teams [3]
* Remove redundant links in index.rst [4]
* Update URL for TC tracker on the wiki [5]
* New repos: masakari-dashboard, log-classify, ansible-role-k8s-glance
* Goal updates: vitrage, panko

[1] https://review.openstack.org/521062
[2] https://review.openstack.org/523195
[3] https://review.openstack.org/#/c/523886/
[4] https://review.openstack.org/523121
[5] https://review.openstack.org/523381

Nothing really significant this week, mostly a bunch of cleanup changes
and clarifications.


== Voting in progress ==

Monty's patch updating shade team metainfo is still missing a couple of
votes:

https://review.openstack.org/523519

Doug Hellmann proposes to round up our top-5 "help needed" list with
goal champions. His proposal is still short of a couple of votes:

https://review.openstack.org/510656

The patch to remove the unused docs:follows-policy tag reached majority
and will be approved on Tuesday unless new objections are posted:

https://review.openstack.org/524217


== Under discussion ==

Graham Hayes proposed various options to clarify how the testing of
interoperability programs should be organized, in the age of add-on
trademark programs. It is a difficult trade-off between the benefits of
centralizing reviews and decentralizing reviews for that specific area.
Please chime in on the review:

https://review.openstack.org/521602

Matt Treinish proposed an update to the Python PTI for tests to be
specific and explicit. Wider community input is needed on that topic.
Please review at:

https://review.openstack.org/519751

The "top-5 help wanted list" assumes there will always be 5 items, and
the name is a bit of a mouthful. Naming is hard. Current proposal is to
call is the "help most needed" list. If you prefer your bikesheds
painted in blue, please comment at:

https://review.openstack.org/520619

Emilien Macchi officially launched the goal proposing season for the
Rocky cycle in a thread at:

http://lists.openstack.org/pipermail/openstack-dev/2017-November/124976.html

We already have one proposal on the docket (Storyboard migration),
thanks to Kendall Nelson. Please chime in on whether it's a good idea at:

https://review.openstack.org/513875


== TC member actions for the coming week(s) ==

Nothing specific.


== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on
#openstack-tc:

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

For the coming week, I expect reports around the cross-community
discussions that happened at KubeCon.

Cheers,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Sean McGinnis]

On Fri, Dec 08, 2017 at 04:06:15PM -0600, Doug Hellmann wrote:
> Excerpts from zuul's message of 2017-12-08 21:56:33 +:
> > Build failed.
> > 
> > - release-openstack-python-without-pypi 
> > http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre-release/release-openstack-python-without-pypi/8c423e5/
> >  : FAILURE in 5m 53s
> > - announce-release announce-release : SKIPPED
> > 
> 
> This error looks like there is a bad file reference in the MANIFEST.in:
> 
> error: can't copy 'etc/policy.json': doesn't exist or not a regular file
> ERROR: InvocationError:
> '/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
> setup.py bdist_wheel'
> venv finish: runtests after 2.76 seconds

I think this is needed to fix it. Some missing cleanup work from the
policy-in-code activity.

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


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

Re: [openstack-dev] [Release-job-failures][congress] Pre-release of openstack/congress failed

[Doug Hellmann]

Excerpts from zuul's message of 2017-12-08 21:56:33 +:
> Build failed.
> 
> - release-openstack-python-without-pypi 
> http://logs.openstack.org/08/080df7f0b147dc8290cc9ceb513ba5d8c1f8f295/pre-release/release-openstack-python-without-pypi/8c423e5/
>  : FAILURE in 5m 53s
> - announce-release announce-release : SKIPPED
> 

This error looks like there is a bad file reference in the MANIFEST.in:

error: can't copy 'etc/policy.json': doesn't exist or not a regular file
ERROR: InvocationError:
'/home/zuul/src/git.openstack.org/openstack/congress/.tox/venv/bin/python
setup.py bdist_wheel'
venv finish: runtests after 2.76 seconds

__
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] Gerrit custom menu entries - help needed

[Sławek Kapłoński]

Hello,

I’m trying to personalize my Gerrit menus in settings panel on 
review.openstack.org.
So I prepared query like:

(NOT owner:self) AND status:open AND label:Code-Review-0,self AND 
label:Workflow=0 AND (project:openstack/neutron OR 
project:openstack/neutron-lib) AND branch:master

And I wanted to create menu entry with this query. When I’m pasting query:

#/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master

On gerrit settings page it replaces me chars like , or = to something else and 
query looks like:

#/q/(NOT+owner:self)+AND+status:open+AND+label:Code-Review-0%252Cself+AND+label:Workflow%253D0+AND+(project:openstack/neutron+OR+project:openstack/neutron-lib)+AND+branch:master

And it don’t work properly then.
So I have a question to more experienced Gerrit users. What I’m doing wrong 
here and how I should create menu entry with query which I really want?

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl






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

Re: [openstack-dev] [Tripleo] Some historic digging

[Zane Bitter]

On 08/12/17 03:51, Cédric Jeanneret wrote:

On 12/07/2017 05:23 PM, Steven Hardy wrote:

On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret
  wrote:

After some more digging, it appears the "dot" (".") in YAML is a
reserved char for hashes. In the puppet world, we usually use the double
semi-colon, aka "::" as a separator.


Can you work around the yaml issue by using quotes to force the
"tripleo.foo.firewall" to be a string?

That was the first thing I tried - but nope. YAML seems to want to parse
that and kind of "re-cast" it :(


There is most definitely no such thing in YAML:

>>> yaml.safe_load('- tripleo.foo.firewallrules:\nbar: baz')
[{'tripleo.foo.firewallrules': {'bar': 'baz'}}]

The problem is hiera:

https://puppet.com/docs/puppet/5.1/hiera_subkey.html

Discussion:

https://tickets.puppetlabs.com/browse/HI-496

The quoting thing was added comparatively recently (March 2016), so 
maybe that's why it isn't working for you:


https://tickets.puppetlabs.com/browse/HI-504

- 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

Re: [openstack-dev] [tripleo] [upgrade] CI status and Current effort.

[Emilien Macchi]

On Fri, Dec 8, 2017 at 1:32 AM, Sofer Athlan-Guyot  wrote:
[...]
> So currently we don’t use the role but when it will be there we will do
> the switch.
>
> Thanks,

Thanks a ton Sofer for all these upgrades. It's excellent to see these
kinds of updates more frequently on the mailing-list it really helps.
Also, it's really cool to see the Upgrade Squad catching up more
quickly on the cycles than before. At least but not last, it's awesome
to see all these efforts in upstream CI, we really need it.

Please let us know if we can help more (reviews, testing, etc).

Thanks again,
-- 
Emilien Macchi

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

Re: [openstack-dev] [tripleo] [upgrade] CI status and Current effort.

[Emilien Macchi]

On Fri, Dec 8, 2017 at 5:39 AM, Wesley Hayutin  wrote:
[...]
> Sofer, can you estimate when the redhat-openstack gerrit repo will be
> dropped and the upstream
> openstac/tripleo-upgrades role used in it's place.  I need to coordinate the
> CI team to work you and
> Jose Louis, however not using the upstream repo makes that difficult.

When https://review.openstack.org/#/c/524141/ will be merged - we're
working on that. Alex cleanup the repo, today I rebased the patch and
added ansble-lint tests. When we have lint working, we'll probably
merge the patch.
From then, I don't see any blocker to use the upstream repo.
-- 
Emilien Macchi

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

[openstack-dev] [keystone] specification freeze exception for unified limits

[Lance Bragstad]

Hey all,

We had a really productive conversation [0] regarding the outstanding
concerns with the unified limits proposal. The initial implementation
for unified limits should target a model so that we can do proper limit
validation. The specification has been reworked to include the outcomes
of the conversation.

I'm proposing we issue a specification freeze exception for the unified
limits specification [1]. We've made a ton of good progress on it and
wxy has been diligently updating the spec and implementation.

If you have any concerns with the new direction or the discussion we had
today, please let me know. If everyone is OK with the direction and the
exception, we'll plan to have the specification smoothed out and merged
by the end of next week.

Thanks,

Lance

[0]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28
[1]
https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+branch:master+topic:bp/unified-limits




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

Re: [openstack-dev] [tripleo][ffu] Fast-forward upgrades M2 progress report

[Emilien Macchi]

On Fri, Dec 8, 2017 at 8:51 AM, Lee Yarwood  wrote:
[...]
> My thanks again to Sofer, Lukas, Marios, the rest of the upgrade squad
> and wider TripleO community for your guidance and patience when putting
> up with my constant inane questioning regarding FFU over the past few
> months!

Thanks Lee for your hard work on this topic, your patience with
TripleO community and all your transparency via the mailing-list and
blog posts. It was really helpful!
-- 
Emilien Macchi

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

Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017

[Jeremy Stanley]

On 2017-12-08 19:21:39 +0100 (+0100), Colleen Murphy wrote:
[...]
> Thanks for pointing this out! Good to know this is moving along.

Well, I wouldn't want to give the impression that it's all squared
away... as your original message indicated, the SB team would
_definitely_ love assistance from others in the community on getting
solutions for these sorts of migration blockers implemented; so
please anyone interested in helping pop into #storyboard and there
are usually people around even if it seems relatively quiet. ;)
-- 
Jeremy Stanley


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

Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017

[Colleen Murphy]

On Fri, Dec 8, 2017 at 6:58 PM, Jeremy Stanley  wrote:
> On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote:
> [...]
>> The major hindrance to keystone using Storyboard is its lack of
>> support for private bugs, which is a requirement given that
>> keystone is a VMT-managed project. If anyone is tired of keystone
>> work and wants to help the Storyboard team with that feature I'm
>> sure they would appreciate it!
> [...]
>
> I also followed up on this topic in the SB meeting yesterday[*] and
> realized support is much further along than I previously recalled.
> In summary, SB admins can define "teams" (e.g., OpenStack VMT) and
> anyone creating a private story can choose to share it with any
> teams or individual accounts they like. What we're mostly missing at
> this point is a streamlined reporting mechanism to reduce the steps
> (and chances to make mistakes) when reporting a suspected
> vulnerability. A leading candidate solution would be support for
> custom reporting URLs which can feed arbitrary values into the
> creation form.
>
> [*] 
> http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36
>
> --
> Jeremy Stanley
>
Thanks for pointing this out! Good to know this is moving along.

Colleen

__
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 Team Update - Week of 4 December 2017

[Paul Belanger]

On Fri, Dec 08, 2017 at 05:58:05PM +, Jeremy Stanley wrote:
> On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote:
> [...]
> > The major hindrance to keystone using Storyboard is its lack of
> > support for private bugs, which is a requirement given that
> > keystone is a VMT-managed project. If anyone is tired of keystone
> > work and wants to help the Storyboard team with that feature I'm
> > sure they would appreciate it!
> [...]
> 
> I also followed up on this topic in the SB meeting yesterday[*] and
> realized support is much further along than I previously recalled.
> In summary, SB admins can define "teams" (e.g., OpenStack VMT) and
> anyone creating a private story can choose to share it with any
> teams or individual accounts they like. What we're mostly missing at
> this point is a streamlined reporting mechanism to reduce the steps
> (and chances to make mistakes) when reporting a suspected
> vulnerability. A leading candidate solution would be support for
> custom reporting URLs which can feed arbitrary values into the
> creation form.
> 
> [*] 
> http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36
> 
Thanks to both for pointing this out again. I too didn't know it was possible to
create teams for private stories. Sounds like we are slowly making progress on
this blocker for some of our projects.

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

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

[Alex Schultz]

+1

On Thu, Dec 7, 2017 at 7:34 AM, Ana Krivokapic  wrote:
> Hey TripleO devs,
>
> Gaël has consistently been contributing high quality reviews and patches to
> the tripleo-validations project. The project would highly benefit from his
> addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Gaël to the core team
> next week.
>
> Thanks!
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] Keystone Team Update - Week of 4 December 2017

[Jeremy Stanley]

On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote:
[...]
> The major hindrance to keystone using Storyboard is its lack of
> support for private bugs, which is a requirement given that
> keystone is a VMT-managed project. If anyone is tired of keystone
> work and wants to help the Storyboard team with that feature I'm
> sure they would appreciate it!
[...]

I also followed up on this topic in the SB meeting yesterday[*] and
realized support is much further along than I previously recalled.
In summary, SB admins can define "teams" (e.g., OpenStack VMT) and
anyone creating a private story can choose to share it with any
teams or individual accounts they like. What we're mostly missing at
this point is a streamlined reporting mechanism to reduce the steps
(and chances to make mistakes) when reporting a suspected
vulnerability. A leading candidate solution would be support for
custom reporting URLs which can feed arbitrary values into the
creation form.

[*] 
http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36

-- 
Jeremy Stanley


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

[openstack-dev] Keystone Team Update - Week of 4 December 2017

[Colleen Murphy]

# Keystone Team Update - Week of 4 December 2017

## News

### Keystone Queens-2 Retrospective

We used our meeting time for our milestone-ly team retrospective,
which took place on Google Hangouts. We were unfortunately not able to
record the session but the Trello board reflects the discussion
topics[1].

One of the key topics that came up was the potential of moving our
roadmap management from Trello to Storyboard. Earlier advice from the
Storyboard folks advised that there would be a mass migration for all
interlinked projects, but the current evolution of the plan promotes a
more iterative approach. See the discussion on the Community Goal
governance review[2]. The major hindrance to keystone using Storyboard
is its lack of support for private bugs, which is a requirement given
that keystone is a VMT-managed project. If anyone is tired of keystone
work and wants to help the Storyboard team with that feature I'm sure
they would appreciate it! In any case, we don't want to switch our
roadmap tooling in the middle of a cycle, so we would continue to use
Trello for roadmap tracking until a cycle change.

[1] https://trello.com/b/jrpmDKtf/keystone-retrospective
[2] 
https://review.openstack.org/#/c/513875/4/goals/rocky/storyboard_migration.rst@82

### Policy Meetings

The last policy meeting was pretty quiet[3]. We decided to cancel
policy meetings until after the holidays.

[3] 
http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-12-06-16.00.log.txt

### Longer project names

We rejected Adrian's patch to extend the maximum length of project
names from 64 to 255 characters[4]. While it might initially seem like
a harmless expansion, it is actually an API breakage because it
changes a response from a 400 to a 200. Keystone does not currently
implement microversions, but we think that microversions would still
not be helpful here, for reasons I described on that patch. We'd like
to look for an alternative way to support Adrian's use case[5].

[4] https://review.openstack.org/#/c/440941/
[5] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106288.html

## Open Specs

Search query: https://goo.gl/pc8cCf

We are closing in on the Limits API spec[6]. We had a good discussion
about it today[7] where we walked through some of the API
compatibility implications of whether or not to start defining and
implementing hierarchical quota models at this stage and reached a
satisfactory conclusion. We'll likely make a spec freeze exception for
this spec so that we can flesh this out fully and get feedback from
other teams.

We also have renewed interest in a feature allowing control over the
generation of project IDs[8], a request that has been independently
made by multiple groups over the years but has historically been
resisted by the keystone team.

[6] https://review.openstack.org/#/c/455709/
[7] 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28
[8] https://review.openstack.org/#/c/323499/

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 17 changes this week.

Among those are a couple of patches that push us further down our
policy roadmap:

Enforce policy on oslo-context: https://review.openstack.org/#/c/523650/
Add scope_types to RuleDefault objects:
https://review.openstack.org/#/c/510222/

We also finally moved keystonemiddleware to using oslo.cache instead
of using the python-memcached library directly:

Use oslo_cache in auth_token middleware:
https://review.openstack.org/#/c/268664/

## Changes that need Attention

Search query:https://goo.gl/YiLt6o

There are 49 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots, so their authors are
waiting for feedback from reviewers. Please have a look at them.

In particular, Adam has been working on finishing the is_admin_project
work: https://goo.gl/dDojbk

Lance is closing in on the system-scope implementation: https://goo.gl/2nLbVx

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Queens-2 is today. Lance has been preparing releases for this
milestone: https://goo.gl/GQBeAi

Spec freeze is today but we'll likely make an exception for the Limits API spec.

Our next deadline is for the Feature Proposal Freeze at Rocky-10.

## Shout-outs

Thanks Harry Rybacki for leading our retrospective!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] OpenStack Ops Meetup Topic Brainstorming

[Melvin Hillsman]

https://etherpad.openstack.org/p/TYO-ops-meetup-2018

Hey everyone,

Just a friendly reminder that the Ops Meetup for Spring 2018 is approaching
March 7-8, 2018 in Tokyo and we are looking for topics. Some have been
gathered already but brainstorming could definitely use some love.

What is different about this meetup compared to others is the addition of
focus areas; tracks. Spring 2018 will have NFV+General on day one and
Enterprise+General on day two. Add additional topics to the etherpad or +/-
1 those already proposed.

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
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] [Neutron] Shifting the bug deputy schedule

[Miguel Lavalle]

Dear Neutrinos,

Recently two members of the team have been re-assigned by their companies
to other duties. As a consequence, we need to adjust our bugs deputy
schedule and your duty slot will be one week sooner than originally
expected. Please take some time to check the revised schedule here:
https://wiki.openstack.org/wiki/Network/Meetings

Best regards

Miguel
__
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][ffu] Fast-forward upgrades M2 progress report

[Lee Yarwood]

Hello all,

This is a brief progress report from the Upgrades squad for the fast-forward
upgrades (FFU) feature in TripleO, introducing N to Q upgrades.

tl;dr Good initial progress, missed M2 goal of nv CI jobs, pushing on to M3.

Overview


For anyone unfamiliar with the concept of fast-forward upgrades the following
sentence from the spec gives a brief high level introduction:

> Fast-forward upgrades are upgrades that move an environment from release `N`
> to `N+X` in a single step, where `X` is greater than `1` and for fast-forward
> upgrades is typically `3`.

The spec itself obviously goes into more detail and I'd recommend anyone
wanting to know more about our approach for FFU in TripleO to start there:

https://specs.openstack.org/openstack/tripleo-specs/specs/queens/fast-forward-upgrades.html

Note that the spec is being updated at present by the following change,
introducing more details on the FFU task layout, ordering, dependency on
the on-going major upgrade rework in Q, canary compute validation etc:

WIP ffu: Spec update for M2
https://review.openstack.org/#/c/526353/

M2 Status
-

The original goal for Queens M2 was to have one or more non-voting FFU jobs
deployed *somewhere* able to run through the basic undercloud and overcloud
upgrade workflows, exercising as many compute service dependencies as we could
up to and including Nova. Unfortunately while Sofer has made some great
progress with this we do not have any running FFU jobs at present:

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125316.html

We do however have documented demos that cover FFU for some limited overcloud
environments from Newton to Queens:

OpenStack TripleO FFU Keystone Demo N to Q
https://blog.yarwood.me.uk/2017/11/16/openstack_fastforward_tripleo_keystone/

OpenStack TripleO FFU Nova Demo N to Q
https://blog.yarwood.me.uk/2017/12/01/openstack_fastforward_tripleo_nova/

These demos currently use a stack of changes against THT with the first ~4 or
so changes introducing the FFU framework:

https://review.openstack.org/#/q/status:open+project:openstack/tripleo-heat-templates+branch:master+topic:bp/fast-forward-upgrades

FWIW getting these initial changes merged would help avoid the current change
storm every time this series is rebased to pick up upgrade or deploy related
bug fixes.

Also note that the demos currently use the raw Ansible playbooks stack
outputs to run through the FFU tasks, upgrade tasks and deploy tasks.
This is by no means what the final UX will be, with python-tripleoclient
and workflow work to be completed ahead of M3.

M3 Goals


The squad will be focusing on the following goals for M3:

- Non-voting RDO CI jobs defined and running
- FFU THT changes tested by the above jobs and merged
- python-tripleoclient & required Mistral workflows merged
- Use of ceph-ansible for Ceph upgrades
- Draft developer and user docs under review

FFU squad
- 

Finally, a quick note to highlight that this report marks the end of my own
personal involvement with the FFU feature in TripleO. I'm not going far,
returning to work on Nova and happy to make time to talk about and review FFU
related changes etc. The members of the upgrade squad taking this forward and
your main points of contact for FFU in TripleO will be:

- Sofer (chem)
- Lukas (social)
- Marios (marios)

My thanks again to Sofer, Lukas, Marios, the rest of the upgrade squad
and wider TripleO community for your guidance and patience when putting
up with my constant inane questioning regarding FFU over the past few
months!

Cheers,

Lee
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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

[openstack-dev] [Zun] PTL on vacation for 3 weeks

[Hongbin Lu]

Hi team,

I will be on vacation during Dec 11 - Jan 2. Madhuri Kumari (cc-ed) kindly
agreed to serve the PTL role while I am away. Wish everyone have a happy
holiday.

Best regards,
Hongbin
__
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] [neutron][l2gw] Preventing DB out-of-sync

[Michael Bayer]

On Wed, Dec 6, 2017 at 3:46 AM, Peng Liu  wrote:
> Hi,
>
> During working on this patch[0], I encounter some DB out-of-sync problem. I
> think maybe the design can be improved. Here is my thought, all comments are
> welcome.


see also https://review.openstack.org/#/c/490834/ which I think is
dealing with a similar (if not the same) issue.

>
> In plugin code, I found all the resource operations follow the pattern in
> [1]. It is a very misleading design compare to [2].
>
> "For every action that can be taken on a resource, the mechanism driver
> exposes two methods - ACTION_RESOURCE_precommit, which is called within the
> database transaction context, and ACTION_RESOURCE_postcommit, called after
> the database transaction is complete."
>
> In result, if we focus on the out-of-sync between plugin DB and
> driver/backend DB:
>
> 1) In RPC driver, only methods Action_Resource and are implemented. Which
> means the action is token before it was written in plugin DB. In case of
> action partial succeed (especially for update case) or plugin DB operation
> failure, it will cause DB out-of-sync.
> 2) In ODL driver, only methods Action_Resource_postcommit are implemented,
> which means there is no validation in ODL level before the record is written
> in the plugin DB. In case of, ODL side failure, there is no rollback for
> plugin DB.
>
> So, to fix this issue is costly. Both plugin and driver sides need to be
> altered.
>
> The other side of this issue is a period db monitor mechanism between plugin
> and drivers, and it is another story.
>
>
> [0] https://review.openstack.org/#/c/516256
> [1]
> ...
> def Action_Resource
> self.validate_Resource_for_Action
> self.driver.Action_Resource
> with context.session.begin(subtransactions=True):
> super.Action_Resource
> self.driver.Action_Resource_precommit
> try:
> self.driver.Action_Resource_postcommit
> ...
> [2] https://wiki.openstack.org/wiki/Neutron/ML2
>
> --
> Peng Liu
>
> __
> 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] [nova] [placement] resource providers update 44

[Chris Dent]

I'm feeling pressure from the (excellent and welcomed) Weekly Owl

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125214.html

and Keystone update:

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125112.html

to enhance the rp and placement update brand, to maximize market
penetration, global influence, and reader participation, but instead
I'll stick to habit.

# Most Important

The three main themes (nested providers, alternate hosts, migration)
continue to be the main priorities.

A thing to be aware of, now that some of nested has merged on the
placement side, is that the nova side is underway and the work
surrounding the ProviderTree concept is fairly penetrating. It will
supersede the "get_inventory" method in the virt drivers, and thus far
not all the virt drivers have get_inventory methods. See

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

way down inside the nested-resource-providers topic for a bit of
context.

# What's Changed

Microversion 1.14 has merged (causing a might microversion conflict
pileup behind it) meaning that some aspects of nested providers are in
the placement API. Hierarchies of providers can be created, and trees
of results can be returned:

https://developer.openstack.org/api-ref/placement/#create-resource-provider
https://developer.openstack.org/api-ref/placement/#list-resource-providers

A fix was merged that defaults the accept header, if not set, to
application/json. This means that whereas in the past an error
response could inadvertently be HTML, it will now be JSON, structured
(partially, critically the 'code' field is not there as we've stumbled
trying to create standards) according to the errors guideline:

https://review.openstack.org/#/c/518223/
http://specs.openstack.org/openstack/api-wg/guidelines/errors.html

Eric made the compute node be more alert when it encounters an error
condition when getting or creating resource providers:

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

This led to the discovery that in grenade placement was not being
properly stopped and restarted over the upgrade transition:

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

I mention all this because it's quite likely that latent bugs with
talking to placement (from nova) in grenade will be exposed. Be on
the lookout. If you find something weird, report a bug, and if
possible, fix it.

# Help Wanted

(unchanged from last week, no new data, yet)

A takeaway from summit is that we need, where possible, benchmarking
info from people who are making the transition from old methods of
scheduling to the newer allocation_candidate driven modes.  While
detailed numbers will be most useful, even anecdotal summaries of
"woot it's way better" or "hmmm, no it seems worse" are useful.

# Docs

Quite a few docs improvements have merged. Others need more review:

* https://review.openstack.org/#/c/512215/
   Add create inventories doc for placement

* https://review.openstack.org/#/c/523007/
   Add x-openstack-request-id in API ref

* https://review.openstack.org/#/c/521541/
   Add 'Location' parameters in API ref

* https://review.openstack.org/#/c/511342/
   add API reference for create inventory

# Nested Providers

The nested-resource-providers stack has grown a long tail of changes
for managing nested providers rooted on a compute node:

https://review.openstack.org/#/q/topic:bp/nested-resource-providers

As mentioned above this has impact for virt drivers.

The current spec for nested providers


http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html

doesn't really cover the ProviderTree and inventory management plans
that are currently being implemented in that long tail. That makes it
a bit harder to review than it might otherwise. We may not need a spec
but a sort of explanatory overview may help provide some context on
what needs to happen. A lot of the work that is in progress feels like
it is working to a design where the use cases are not entirely obvious.
There's a danger this can lead to an implementation that is somewhat
divorced for reality. There's no evidence as yet that this is
happening, but there's also none that it's not.

## Alternate Hosts

Having the scheduler request and use alternate hosts:

https://review.openstack.org/#/q/topic:bp/return-alternate-hosts

This has come unstuck and is moving along, but needs continued eyes.

## Migration allocations

Do allocation "doubling" using the migration uuid for the consumer for
one half. This is also very close:

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

The concept of migration allocations is what drove the work to enable
the POST /allocations handling now at microversion 1.13, so we have
the option to start using that power. Dan helpfully left comments in
the code to indicate where it could be done. Do we want to consider
getting that in before the end of queens, to avoid some racing?

## Misc Traits, 

Re: [openstack-dev] [tripleo] [upgrade] CI status and Current effort.

[Wesley Hayutin]

On Fri, Dec 8, 2017 at 4:32 AM, Sofer Athlan-Guyot 
wrote:

> Hi,
>
> We (Upgrade Squad) have eventually save some time for fixing/creating
> the needed upgrade/update jobs.
>
> We have made an inventory of what currently exists there[1] and what is
> missing in the same spreadsheet.
>
> I recap the missing one here:
>
>  - minor updates (master and pike)
>  - UC non containerized to containerized
>  - ffu-undercould-upgrade
>  - ffu-overcloud-upgrade
>
> We are currently working on fixing the existing ocata->pike upgrade.
>
> You don’t see pike->master as we are reworking the workflow (as usual)
> and it’s non working.  But we have a jobs to track the progress in
> experimental[2] with the right depends-on.
>
> The two newcomers are FFU uc upgrade and oc upgrade (Fast Forward
> Upgrade, or upgrade from Newton to Queens).  We have a work in progress
> there[3] and there[4] for oc upgrade.
>
> It’s not yet working but would be nice to have those jobs in
> experimental as soon as we can to track our progress there and detect
> code/repo deletion that prevents the whole FFU to function.
>
> We’re are working on minor upgrade testing there[5] and there[6]
>
> Oki, nearly done...
>
> We have the tripleo-upgrade role that is stuck in transition.  This repo
> is an effort to share downstream QE testing with upstream.  Du to
> various reasons (speed, mainly) we kept using github instead of
> switching to the openstack one.  Now we are stuck there[7].  We would
> like a new import but if it is not possible, we will merge all the
> patches manually.
>
> So currently we don’t use the role but when it will be there we will do
> the switch.
>
> Thanks,
> --
> [1] https://ethercalc.openstack.org/iv2jr35o98
> [2] https://review.openstack.org/#/c/526006/
> [3] https://review.openstack.org/#/q/topic:ffu/ci+(status:open+
> OR+status:merged)
> [4] https://review.rdoproject.org/r/10827
> [5] https://review.openstack.org/#/q/topic:upgrade/ci+(status:
> open+OR+status:merged)
> [6] https://review.rdoproject.org/r/#/c/10878/
> [7] https://review.openstack.org/#/c/524141/
> --
> Sofer
>

Sofer, can you estimate when the redhat-openstack gerrit repo will be
dropped and the upstream
openstac/tripleo-upgrades role used in it's place.  I need to coordinate
the CI team to work you and
Jose Louis, however not using the upstream repo makes that difficult.

We have a meeting today, so we can also talk about it there.
Thanks



>
> __
> 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] [tripleo] [upgrade] CI status and Current effort.

[Sofer Athlan-Guyot]

Hi,

We (Upgrade Squad) have eventually save some time for fixing/creating
the needed upgrade/update jobs.

We have made an inventory of what currently exists there[1] and what is
missing in the same spreadsheet.

I recap the missing one here:

 - minor updates (master and pike)
 - UC non containerized to containerized
 - ffu-undercould-upgrade
 - ffu-overcloud-upgrade

We are currently working on fixing the existing ocata->pike upgrade.

You don’t see pike->master as we are reworking the workflow (as usual)
and it’s non working.  But we have a jobs to track the progress in
experimental[2] with the right depends-on.

The two newcomers are FFU uc upgrade and oc upgrade (Fast Forward
Upgrade, or upgrade from Newton to Queens).  We have a work in progress
there[3] and there[4] for oc upgrade.

It’s not yet working but would be nice to have those jobs in
experimental as soon as we can to track our progress there and detect
code/repo deletion that prevents the whole FFU to function.

We’re are working on minor upgrade testing there[5] and there[6]

Oki, nearly done...

We have the tripleo-upgrade role that is stuck in transition.  This repo
is an effort to share downstream QE testing with upstream.  Du to
various reasons (speed, mainly) we kept using github instead of
switching to the openstack one.  Now we are stuck there[7].  We would
like a new import but if it is not possible, we will merge all the
patches manually.

So currently we don’t use the role but when it will be there we will do
the switch.

Thanks,
--
[1] https://ethercalc.openstack.org/iv2jr35o98
[2] https://review.openstack.org/#/c/526006/
[3] https://review.openstack.org/#/q/topic:ffu/ci+(status:open+OR+status:merged)
[4] https://review.rdoproject.org/r/10827
[5] 
https://review.openstack.org/#/q/topic:upgrade/ci+(status:open+OR+status:merged)
[6] https://review.rdoproject.org/r/#/c/10878/
[7] https://review.openstack.org/#/c/524141/
-- 
Sofer

__
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] multiple federated keystones with single Identity Provider

[Adam Heczko]

Hi Pavlo, I think that there are viable alternatives to your specific use
case having single external idp for federated auth.
Depending on your IT environment architecture and preferences you have the
following possibilities, both of them are providing very smooth user
experience:
- in AD centric environments connect each of Keystone services to AD and
leverage Kerberos for SSO. You can consume REMOTE_USER and other variables
from AD directly via mod_auth_gssapi and mod_lookup_identity. Advantage of
this approach is that you can leverage AD native SSO mechanism based on
SPNEGO. So you are not any longer  forcing users to perform SAML or OIDC
referrals etc.
- in both AD or non AD centric environments you can leverage 'Tokenless
Auth' plugin, which basically can also be used with Keystone to issue
tokens (e.g. Fernet) and perform token scoping based on X.509 certificate
properties. You can also configure specific X.509 certificate attributes
e.g. SAN or subjectDirectoryAttributes to control access for specific
region or Keystone instance.

On Fri, Dec 8, 2017 at 1:25 AM, Boris Bobrov  wrote:

> Hi,
>
> > On 12/07/2017 12:27 PM, Colleen Murphy wrote:
> >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
> >>  wrote:
> >>> Hi all,
> >>>
> >>> We have a following use case - several independent keystones (say KeyA
> and
> >>> KeyB), using fernet tokens and synchronized fernet keys, and single
> external
> >>> IdP for federated auth.
> >>>
> >>> Is it generally possible to configure both KeyA and KeyB such that
> scoped
> >>> token issued by KeyA for a federated user is valid on KeyB?
> >>>
> >>> Currently we have the next problem - although domains/projects where
> >>> keystone's mapping engine assigns federated users are equal by name
> between
> >>> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB  are
> >>> different, which seems to invalidate the scoped token issued by KeyA
> when
> >>> trying to use it for KeyB. And it is not possible to create
> projects/domains
> >>> with specific UUIDs via keystone API (which would probably solve this
> >>> problem for non-autoprovisioned projects).
> >>>
> >>> Is such usage scenario supported? Or one should always use the unscoped
> >>> token first to list projects/domains available on a specific keystone
> >>> instance and then get a scoped token for usage o this instance only?
> >> No, it is not currently possible to use the same token on projects in
> >> different keystones, for the reasons you gave. You might be interested
> >> in following https://review.openstack.org/#/c/323499/ if you're not
> >> already aware of it, which has the goal of solving that problem.
> >>
> >> It's also been brought up before:
> >>
> >> https://review.openstack.org/#/c/403866/
> >> http://lists.openstack.org/pipermail/openstack-dev/2016-
> December/108466.html
> >>
> >> And we talked about it a lot at the last Forum (sorry my brief summary
> >> does not really do the discussion justice):
> >>
> >> http://www.gazlene.net/sydney-summit.html#keystone-operator-
> and-user-feedback
> > I had a snippet about it in my recap under the "Other Feedback" section
> > [0]. The TL;DR in my opinion is that we originally thought we could
> > solve the problem with federation 100%, and if we couldn't we wanted to
> > try and improve the parts of federation that would make that possible.
> >
> > The interesting bit we came up with during the feedback session in
> > Sydney is what happens if a user no longer has a role on a project. For
> > example;
> >
> > - A user has a role on Project A and in the us-east region and the
> > us-west region, each region has it's own keystone deployment, but let's
> > assume the ID for Project A are the same in each region
> > - A user authenticates for a token scoped to Project A and starts
> > creating instances in both regions
> > - The user has their role from Project A removed in us-east, but not in
> > us-west
> > - The user isn't able to do anything within us-east since they no longer
> > have a role assignment on Project A in that region, but they can still
> > take the invalid token from the us-east region and effectively use it in
> > the us-west region
> >
> > Without replicating revocation events, or syncing the assignment table,
> > this will lead to security concerns.
>
> There is also cache invalidation issue. And that would make tokens of
> various scope behave in a different manner. A year ago i was -2 on this,
> and i still don't think this is a good idea.
>
> If there is a demand to control several clouds from single place,
> K2K support should be added where it is needed.
>
>
> __
> 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
>
>


-- 
Adam Heczko

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

[Marios Andreou]

On Thu, Dec 7, 2017 at 4:34 PM, Ana Krivokapic  wrote:

> Hey TripleO devs,
>
> Gaël has consistently been contributing high quality reviews and patches
> to the tripleo-validations project. The project would highly benefit from
> his addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Gaël to the core team
> next week.
>

+1


>
> Thanks!
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tripleo] Some historic digging

[Cédric Jeanneret]

On 12/07/2017 05:23 PM, Steven Hardy wrote:
> On Thu, Dec 7, 2017 at 7:22 AM, Cédric Jeanneret
>  wrote:
>> Hello,
>>
>> While trying to add some unit tests for some resources in the
>> puppet-tripleo repository, I stumbled on a not-so-nice case: the
>> tripleo::firewall::service_rules definition.
>>
>> In there, a resource is dynamically taken from hiera, using the
>> following key structure:
>> tripleo..firewall_rules
>>
>> Although this seems to work properly in the tripleo deploy process, it
>> just doesn't work at all for a unit test.
>>
>> After some more digging, it appears the "dot" (".") in YAML is a
>> reserved char for hashes. In the puppet world, we usually use the double
>> semi-colon, aka "::" as a separator.
>>
>> Sooo… I'm wondering what's the history behind that non-puppet-standard
>> choice of "dot" separator, and what would be required in order to move
>> to a more standard syntax for that kind of resources.
> 
> dprince may be the best person to answer as IIRC he implemented this 
> originally.
> 
> However I suspect the choice of "." was deliberate to differentiate
> from :: which implies the hiera values are consumed by puppet class
> interfaces, vs parsed inside the class.
> 

Hmm, possible, although.. well, a dedicated prefix might be used in
order to avoid weird things

> Can you work around the yaml issue by using quotes to force the
> "tripleo.foo.firewall" to be a string?

That was the first thing I tried - but nope. YAML seems to want to parse
that and kind of "re-cast" it :(

> 
> We don't seem to require that for any templates in
> tripleo-heat-templates though, is that just because the yaml key gets
> cast to a string by hiera?

There might be something in some hiera configuration used in the deploy
process. I'll check the hiera.yaml and try to find something about that
weird string. If we can just report it into the unit tests, it can be
fine. Although... dots... well. ;)

> 
>> I've checked the puppet-tripleo repository, and apparently only two
>> resources are using that kind of syntax:
>> - tripleo::firewall::service_rules (already widely present in the
>> tripleo-heat-templates)
>> - tripleo::haproxy::service_endpoints
>> (at least, those are the only resources using a "$underscore_name" variable)
>>
>> Currently, if anyone wants to change something close to those two
>> resources, it won't be tested against regressions, and it's a really bad
>> situation. Especially since it might break central services (closing all
>> firewall ports isn't good, for example, or dropping an haproxy endpoint
>> by mistake)… Unit tests are needed, especially in such a huge piece of
>> software ;).
> 
> Yeah I think we need to know more about the reasons this syntax won't
> work for unit tests, we could conceivably change it, but as you say
> it's widely used for firewall rules, and could potentially break any
> out of tree service templates that exist, so we'd have to follow a
> deprecation process to change the interface.

Hmmm ok. I didn't check outside of the puppet-tripleo - it indeed might
be some things using this string format. I've already pushed two reviews
that *adds* support for the "::" notation for the said resources. That
way, we have at least a basis for a smooth move. Of course, they are
only "reviews", so they have to be accepted:
https://review.openstack.org/#/c/526589/
https://review.openstack.org/#/c/526292/

I doubt out-of-tree stuff uses those hiera entries, but of course this
would require some grep and, probably, advice from other contributors ;).

Thank you for your feedback!

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




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

Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Masahito MUROI]

Hi Gerg0,

I added some comments for GAP-04. It looks like NFVO works as an tenant 
user and an operator. IMHO, NFVO could calculate the capacity of the cloud.


best regards,
Masahito


On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Hi,

During the Forum session about the ETSI NFV Gaps I received a request to 
clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.


The advice is that it should be possible to get the capacity of an 
OpenStack tenant, an user and a resource provider. This is because the 
NFVO might use different tenants and even different users to manage the 
resources in the OpenStack instances.


Any comments are welcome, also if you need more clarification on the 
gaps listed in [1] do not hesitate to contact me.


Br,

Gerg0

[1]: 
https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained




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






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

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

[Florian Fuchs]

+1 Thanks for the good work!

On Fri, Dec 8, 2017 at 8:38 AM, Martin André  wrote:
> +1! Gaël has been doing a fantastic job in tripleo-validations for a long 
> time.
>
> On Thu, Dec 7, 2017 at 3:34 PM, Ana Krivokapic  wrote:
>> Hey TripleO devs,
>>
>> Gaël has consistently been contributing high quality reviews and patches to
>> the tripleo-validations project. The project would highly benefit from his
>> addition to the core reviewer team.
>>
>> Assuming that there are no objections, we will add Gaël to the core team
>> next week.
>>
>> Thanks!
>>
>> --
>> Regards,
>> Ana Krivokapic
>> Senior Software Engineer
>> OpenStack team
>> Red Hat Inc.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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