[openstack-dev] [Zun] Zun UI questions

[Hongbin Lu]

Hi Amy,

First, I want to confirm which version of devstack you were using? (go to
the devstack folder and type "git log -1").

If possible, I would suggest to do the following steps:

* Run ./unstack
* Run ./clean
* Pull down the latest version of devstack (if it is too old)
* Pull down the latest version of all the projects under /opt/stack/
* Run ./stack

If above steps couldn't resolve the problem, please let me know.

Best regards,
Hongbin

On Fri, Jul 13, 2018 at 10:33 AM Amy Marrich  wrote:

> Hongbin,
>
> Let me know if you still want me to mail the dev list, but here are the
> gists for the installations and the broken CLI I mentioned
>
> local.conf - which is basically the developer quickstart instructions for
> Zun
>
> https://gist.github.com/spotz/69c5cfa958b233b4c3d232bbfcc451ea
>
>
> This is the failure with a fresh devstack installation
>
> https://gist.github.com/spotz/14e19b8a3e0b68b7db2f96bff7fdf4a8
>
>
> Requirements repo change a few weeks ago
>
>
> http://git.openstack.org/cgit/openstack/requirements/commit/?id=cb6c00c01f82537a38bd0c5a560183735cefe2f9
>
>
> Changed local Flask version for curry-libnetwork and set local.conf to
> reclone=no and then installed and tried to use the CLI.
>
> https://gist.github.com/spotz/b53d729fc72d24b4454ee55519e72c07
>
>
> It makes sense that Flask would cause an issue on the UI installation even
> though it's enabled even for a non-enabled build according to the
> quickstart doc. I don't mind doing a patch to fix kuryr-libnetwork to bring
> it up to the current requirements. I don't however know where to start
> troubleshooting the 401 issue. On a different machine I have decstack with
> Zun but no zun-ui and the CLI responds correctly.
>
>
> Thanks,
>
> Amy (spotz)
>
>
> On Thu, Jul 12, 2018 at 11:21 PM, Hongbin Lu  wrote:
>
>> Hi Amy,
>>
>> I am also in doubts about the Flask version issue. Perhaps you can
>> provide more details about this issue? Do you see any error message?
>>
>> Best regards,
>> Hongbin
>>
>> On Thu, Jul 12, 2018 at 10:49 PM Shu M.  wrote:
>>
>>>
>>> Hi Amy,
>>>
>>> Thank you for sharing the issues. Zun UI does not require
>>> kuryr-libnetwork directly, and keystone seems to have same requirements for
>>> Flask. So I wonder why install failure occurred by Zun UI.
>>>
>>> Could you share your correction for requrements.
>>>
>>> Unfortunately, I'm in trouble on my development environment since
>>> yesterday. So I can not investigate the issues quickly.
>>> I added Hongbin to this topic, he would help us.
>>>
>>> Best regards,
>>> Shu Muto
>>>
>>> 2018年7月13日(金) 9:29 Amy Marrich :
>>>
 Hi,

 I was given your email on the #openstack-zun channel as a source for
 questions for the UI. I've found a few issues installing the Master branch
 on devstack and not sure if they should be bugged.

 kuryr-libnetwork has incorrect versions for Flask in both
 lower-constraints.txt and requirements.txt, this only affects installation
 when enabling zun-ui, I'll be more then happy to bug and patch it, if
 confirmed as an issue.

 Once correcting the requirements locally to complete the devstack
 installation, I'm receiving 401s when using both the OpenStack CLI and Zun
 client. I'm also unable to create a container within Horizon. The same
 credentials work fine for other OpenStack commands.

 On another server without the ui enabled I can use both the CLI and
 client no issues. I'm not sure if there's something missing on
 https://docs.openstack.org/zun/latest/contributor/quickstart.html or
 some other underlying issue.

 Any help or thoughts appreciated!

 Thanks,

 Amy (spotz)


>
__
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] Feature Status and Exceptions

[Johannes Grassler]

Hello,

On Fri, Jul 13, 2018 at 03:50:33PM -0500, Lance Bragstad wrote:
> On 07/13/2018 03:37 PM, Johannes Grassler wrote:
> > On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
> >> *Capability Lists**
> >> *
> >> The capability lists involves a lot of work, not just within keystone,
> >> but also keystonemiddleware, which will freeze next week. I think it's
> >> reasonable to say that this will be something that has to be pushed to
> >> Stein [3].
> > I was was planning to email you about that, too...I didn't have much
> > time for it lately (rushing to get a few changes in Monasca in plus a
> > whole bunch of packaging stuff) and with the deadline this close I
> > didn't see much of a chance to get anything meaningful in.
> >
> > So +1 for Stein from my side. This time I can plan for and accomodate it
> > by having less Monasca stuff on my plate...
> 
> +1
> 
> Thanks for confirming. There still seems to be quite a bit of discussion
> around the data model and layout. We can use the PTG to focus on that as
> a group if needed (and if you'll be there).

For now I'll try to remain cautiously optimistic that this discussion
can mostly be resolved by starting from the controller end and making my
way to the data model from that side, as people suggested :-)

As for the PTG: until now I was planning on skipping it. Lots of travel
already this year and I need some quiet time without jetlag to work on
the code, too...

Cheers,

Johannes



-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany 

__
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] Feature Status and Exceptions

[Lance Bragstad]

On 07/13/2018 02:37 PM, Harry Rybacki wrote:
> On Fri, Jul 13, 2018 at 3:20 PM Lance Bragstad  wrote:
>> Hey all,
>>
>> As noted in the weekly report [0], today is feature freeze for 
>> keystone-related specifications. I wanted to elaborate on each specification 
>> so that our plan is clear moving forward.
>>
>> Unified Limits
>>
>> I propose that we issue a feature freeze exception for this work. Mainly 
>> because the changes are relatively isolated and low-risk. The majority of 
>> the feedback on the approach is being held up by an interface decision, 
>> which doesn't impact users, it's certainly more of a developer preference 
>> [1].
>>
>> That said, I don't think it would be too ambitious to focus reviews on this 
>> next week and iron out the last few bits well before rocky-3.
>>
>> Default Roles
>>
>> The implementation to ensure each of the new defaults is available after 
>> installing keystone is complete. We realized that incorporating those new 
>> roles into keystone's default policies would be a lot easier after the flask 
>> work lands [2]. Instead of doing a bunch of work to incorporate those 
>> default and then re-doing it to accommodate flask, I think we have a safe 
>> checkpoint where we are right now. We can use free cycles during the RC 
>> period to queue up those implementation, mark them with a -2, and hit the 
>> ground running in Stein. This approach feels like the safest compromise 
>> between risk and reward.
>>
> +1 to this approach.

I've proposed a couple updates to the specification, trying to clarify
exactly what was implemented in the release [0].

[0] https://review.openstack.org/#/c/582673/

>
>> Capability Lists
>>
>> The capability lists involves a lot of work, not just within keystone, but 
>> also keystonemiddleware, which will freeze next week. I think it's 
>> reasonable to say that this will be something that has to be pushed to Stein 
>> [3].
>>
>> MFA Receipts
>>
>> Much of the code used in the existing approach uses a lot of the same 
>> patterns from the token provider API within keystone [4]. Since the UUID and 
>> SQL parts of the token provider API have been removed, we're also in the 
>> middle of cleaning up a ton of technical debt in that area [5]. Adrian seems 
>> OK giving us the opportunity to finish cleaning things up before reworking 
>> his proposal for authentication receipts. IMO, this seems totally reasonable 
>> since it will help us ensure the new code for authentication receipts 
>> doesn't have the bad patterns that have plagued us with the token provider 
>> API.
>>
>>
>> Does anyone have objections to any of these proposals? If not, I can start 
>> bumping various specs to reflect the status described here.
>>
>>
>> [0] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
>> [1] 
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model
>> [2] 
>> https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
>> [3] 
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds
>> [4] 
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt
>> [5] 
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945
>>
>> __
>> 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




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] [keystone] Feature Status and Exceptions

[Lance Bragstad]

On 07/13/2018 03:37 PM, Johannes Grassler wrote:
> Hello,
>
> On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
>> *Capability Lists**
>> *
>> The capability lists involves a lot of work, not just within keystone,
>> but also keystonemiddleware, which will freeze next week. I think it's
>> reasonable to say that this will be something that has to be pushed to
>> Stein [3].
> I was was planning to email you about that, too...I didn't have much
> time for it lately (rushing to get a few changes in Monasca in plus a
> whole bunch of packaging stuff) and with the deadline this close I
> didn't see much of a chance to get anything meaningful in.
>
> So +1 for Stein from my side. This time I can plan for and accomodate it
> by having less Monasca stuff on my plate...

+1

Thanks for confirming. There still seems to be quite a bit of discussion
around the data model and layout. We can use the PTG to focus on that as
a group if needed (and if you'll be there).

>
> Cheers,
>
> Johannes
>




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

Re: [openstack-dev] [all][ptl][release] deadline for non-client library releases 19 July

[Matthew Thode]

On 18-07-13 14:57:58, Doug Hellmann wrote:
> The deadline for releasing non-client libraries for Rocky is coming up
> next week on 19 July (https://releases.openstack.org/rocky/schedule.html).
> 
> We have a few libraries that have no releases at all this cycle,
> which makes creating the stable branch problematic. Therefore, if
> the PTL or release liaison do not propose a release by next week,
> the release team may tag HEAD of master with an appropriate version
> number (raising at least the minor value) to provide a place to
> create the stable/rocky branch. (See Thread at
> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html
> for the discussion of this policy. We will need to decide whether
> to tag based on whether there are any changes on master for the
> repository.)
> 
> - automaton
> - ceilometermiddleware
> - debtcollector
> - pycadf
> - requestsexceptions
> - stevedore
> 
> Below is the set of unreleased changes for known deliverables
> classified as non-client libraries and that look like they may
> warrant a release (i.e., they are not only CI configuration changes).
> Any items in the report below that are not also in the list above
> will not be tagged by the release team because we already have a
> tag we can use to create the stable branch. The unrelease changes
> for those deliverables will not be available to Rocky users unless
> they are backported to the stable branch.
> 
> If you manage one of these deliverables, please review the list and
> consider proposing a release before the deadline.
> 
> Doug
> 
> 
> [ Unreleased changes in openstack/automaton (master) ]
> 
> Changes between 1.14.0 and ce03d76
> 
> * ce03d76 2018-07-11 09:48:53 +0700 Switch to stestr
> * 5d8233a 2018-06-06 14:53:48 -0400 fix tox python3 overrides
> * 885b3d4 2018-04-21 02:40:23 +0800 Trivial: Update pypi url to new url
> * 67b3093 2018-04-13 15:48:27 -0400 fix list of default virtualenvs
> * aa12fe5 2018-04-13 15:48:23 -0400 set default python to python3
> * f8623e5 2018-03-24 21:02:01 -0400 add lower-constraints job
> * 84a646c 2018-03-15 06:45:10 + Updated from global requirements
> * 85b7139 2018-01-24 17:58:52 + Update reno for stable/queens
> * 08228a1 2018-01-24 00:48:55 + Updated from global requirements
> * 22b2b86 2018-01-17 20:27:45 + Updated from global requirements
> * 6191cf6 2018-01-16 04:02:08 + Updated from global requirements
> 
> 
> 
> [ Unreleased changes in openstack/ceilometermiddleware (master) ]
> 
> Changes between 1.2.0 and 8332b9e
> 
> * 8332b9e 2018-06-06 15:27:00 -0400 fix tox python3 overrides
> * 2f0efc7 2018-02-01 16:33:52 + Update reno for stable/queens
> 
> 
> 
> 
> [ Unreleased changes in openstack/debtcollector (master) ]
> 
> Changes between 1.19.0 and 858f15d
> 
> * 858f15d 2018-06-06 14:53:48 -0400 fix tox python3 overrides
> * 2ee856f 2018-04-21 05:21:26 +0800 Trivial: Update pypi url to new url
> * 821478a 2018-04-16 11:16:59 -0400 remove obsolete tox environments
> * 03292af 2018-04-16 11:16:59 -0400 set default python to python3
> * 9e2a2d1 2018-03-15 06:50:50 + Updated from global requirements
> | * d8e616d 2018-03-24 21:02:07 -0400 add lower-constraints job
> | * 17ffa68 2018-03-21 18:26:09 +0530 pypy is not checked at gate
> |/  
> * 19616fc 2018-03-10 13:09:54 + Updated from global requirements
> * b9a6777 2018-02-28 01:53:43 +0800 Update links in README
> * 0ff121e 2018-01-24 17:59:41 + Update reno for stable/queens
> | * 4e6aabb 2018-01-24 00:51:19 + Updated from global requirements
> |/  
> * dceacf1 2018-01-17 20:30:24 + Updated from global requirements
> * 81d2312 2017-11-17 10:09:38 +0100 Remove setting of version/release from 
> releasenotes
> 
> 
> 
> [ Unreleased changes in openstack/glance_store (master) ]
> 
> Changes between 0.24.0 and d50ab63
> 
> * d50ab63 2018-07-09 15:42:10 + specify region on creating cinderclient
> * 573fde0 2018-06-06 15:27:00 -0400 fix tox python3 overrides
> * 5a20d47 2018-06-20 19:40:17 -0400 Deprecate 
> store_capabilities_update_min_interval
> * 54b7ccb 2016-12-20 16:07:45 +1100 Disable verification for Keystone session 
> in Swift
> 
> 
> 
> 
> [ Unreleased changes in openstack/ironic-lib (master) ]
> 
> Changes between 2.13.0 and 9ba805d
> 
> * 9ba805d 2018-07-11 18:16:12 +0700 Remove testrepository
> * a809787 2018-07-02 11:39:03 +0200 Expose GPT partitioning fixing method
> * 89fbae4 2018-06-27 14:50:06 -0400 Switch to using stestr
> * 68f017f 2018-06-27 12:36:05 +0200 Do not run API (functional) tests in the 
> CI
> * 4e31bc5 2018-06-07 17:34:53 + Remove unneccessary lambda from 
> _test_make_partitions
> * e4dda71 2018-06-06 15:27:00 -0400 fix tox python3 overrides
> 
> 
> 
> [ Unreleased changes in openstack/kuryr (master) ]
> 
> Changes between 0.8.0 and cb6eef2
> 
> * 6dc4279 2018-05-11 09:33:19 +0700 Replace deprecated "auth_uri" by 
> "www_authenticate_uri"
> 
> 
> 
> [ Unreleased changes in openstack/mistral-lib (master) ]
> 
> Changes bet

Re: [openstack-dev] [all][ptg] Wiki page for Etherpads

[Matt Riedemann]

On 7/13/2018 3:16 PM, Frank Kloeker wrote:

Hello,

just wondering there was not Wiki page for the upcoming PTG in Denver, 
so I've just created [1] and put in the links what I found here. Please 
check and update if required.


thx

Frank

[1] https://wiki.openstack.org/wiki/PTG/Stein/Etherpads


Thanks for doing that.

--

Thanks,

Matt

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

Re: [openstack-dev] [keystone] Feature Status and Exceptions

[Johannes Grassler]

Hello,

On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
> *Capability Lists**
> *
> The capability lists involves a lot of work, not just within keystone,
> but also keystonemiddleware, which will freeze next week. I think it's
> reasonable to say that this will be something that has to be pushed to
> Stein [3].

I was was planning to email you about that, too...I didn't have much
time for it lately (rushing to get a few changes in Monasca in plus a
whole bunch of packaging stuff) and with the deadline this close I
didn't see much of a chance to get anything meaningful in.

So +1 for Stein from my side. This time I can plan for and accomodate it
by having less Monasca stuff on my plate...

Cheers,

Johannes

-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany 

__
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] [docs][i18n][ptg] PTG infos on Etherpad

[Frank Kloeker]

Hello,

the Docs and I18n team will also present during the PTG in Denver. The 
rough plan told us on Monday/Tuesday. As usually we're in the same room 
and will use also the same Etherpad on [1],
which I have shameless copied from the last PTG in Denver, so we have 
all this usefull links for Station 26 already there :)


Please write down your topics and your possible participation. The 
Etherpad from the previous PTG is also linked as a reminder.


many thanks

Frank

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

__
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] Reminder on nova-network API removal work

[Matt Riedemann]

There are currently no open changes for the nova-network API removal 
tracked here [1] but there are at least two low-hanging fruit APIs to 
remove:


* os-floating-ips-bulk
* os-floating-ips-dns

It would be nice to at least get those removed yet before the feature 
freeze. See one of the existing linked removal patches in the etherpad 
for an example of how to do this, and/or read the doc [2].


[1] https://etherpad.openstack.org/p/nova-network-removal-rocky
[2] 
https://docs.openstack.org/nova/latest/contributor/api.html#removing-deprecated-apis


--

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] [all][ptg] Wiki page for Etherpads

[Frank Kloeker]

Hello,

just wondering there was not Wiki page for the upcoming PTG in Denver, 
so I've just created [1] and put in the links what I found here. Please 
check and update if required.


thx

Frank

[1] https://wiki.openstack.org/wiki/PTG/Stein/Etherpads

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

Re: [openstack-dev] [nova]API update week 5-11

[Matt Riedemann]

On 7/11/2018 9:03 PM, Zhenyu Zheng wrote:

2. Abort live migration in queued state:

-https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status

-https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged)


- Weekly Progress: Review is going and it is in nova runway this
week. In API office hour, we discussed about doing the compute
service version checks oncompute.api.py side
than on rpc side. Dan has point of doing it on rpc side where
migration status can changed to running. We decided to further
discussed it on patch.


This is my own defence, Dan's point seems to be that the actual rpc 
version pin could be set to be lower than the can_send_version even when 
the service version is new enough, so he thinks doing it in rpc is better.


That series is all rebased now and I'm +2 up the stack until the API 
change, where I'm just +1 since I wrote the compute service version 
checking part, but I think this series is ready for wider review.


--

Thanks,

Matt

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

Re: [openstack-dev] [nova]API update week 5-11

[Matt Riedemann]

On 7/11/2018 8:14 PM, Ghanshyam Mann wrote:

4. Volume multiattach enhancements:
-https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements  
-https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged)  
- Weekly Progress: mriedem mentioned in last week status mail that he will continue work on this.


I failed to work on this again this week since I spent the majority of 
my week doing reviews.


--

Thanks,

Matt

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

Re: [openstack-dev] [keystone] Feature Status and Exceptions

[Harry Rybacki]

On Fri, Jul 13, 2018 at 3:20 PM Lance Bragstad  wrote:
>
> Hey all,
>
> As noted in the weekly report [0], today is feature freeze for 
> keystone-related specifications. I wanted to elaborate on each specification 
> so that our plan is clear moving forward.
>
> Unified Limits
>
> I propose that we issue a feature freeze exception for this work. Mainly 
> because the changes are relatively isolated and low-risk. The majority of the 
> feedback on the approach is being held up by an interface decision, which 
> doesn't impact users, it's certainly more of a developer preference [1].
>
> That said, I don't think it would be too ambitious to focus reviews on this 
> next week and iron out the last few bits well before rocky-3.
>
> Default Roles
>
> The implementation to ensure each of the new defaults is available after 
> installing keystone is complete. We realized that incorporating those new 
> roles into keystone's default policies would be a lot easier after the flask 
> work lands [2]. Instead of doing a bunch of work to incorporate those default 
> and then re-doing it to accommodate flask, I think we have a safe checkpoint 
> where we are right now. We can use free cycles during the RC period to queue 
> up those implementation, mark them with a -2, and hit the ground running in 
> Stein. This approach feels like the safest compromise between risk and reward.
>
+1 to this approach.

> Capability Lists
>
> The capability lists involves a lot of work, not just within keystone, but 
> also keystonemiddleware, which will freeze next week. I think it's reasonable 
> to say that this will be something that has to be pushed to Stein [3].
>
> MFA Receipts
>
> Much of the code used in the existing approach uses a lot of the same 
> patterns from the token provider API within keystone [4]. Since the UUID and 
> SQL parts of the token provider API have been removed, we're also in the 
> middle of cleaning up a ton of technical debt in that area [5]. Adrian seems 
> OK giving us the opportunity to finish cleaning things up before reworking 
> his proposal for authentication receipts. IMO, this seems totally reasonable 
> since it will help us ensure the new code for authentication receipts doesn't 
> have the bad patterns that have plagued us with the token provider API.
>
>
> Does anyone have objections to any of these proposals? If not, I can start 
> bumping various specs to reflect the status described here.
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
> [1] 
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model
> [2] 
> https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
> [3] 
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds
> [4] 
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt
> [5] 
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945
>
> __
> 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] [keystone] Feature Status and Exceptions

[Lance Bragstad]

Hey all,

As noted in the weekly report [0], today is feature freeze for
keystone-related specifications. I wanted to elaborate on each
specification so that our plan is clear moving forward.

*Unified Limits**
**
*I propose that we issue a feature freeze exception for this work.
Mainly because the changes are relatively isolated and low-risk. The
majority of the feedback on the approach is being held up by an
interface decision, which doesn't impact users, it's certainly more of a
developer preference [1].

That said, I don't think it would be too ambitious to focus reviews on
this next week and iron out the last few bits well before rocky-3.

*Default Roles**
*
The implementation to ensure each of the new defaults is available after
installing keystone is complete. We realized that incorporating those
new roles into keystone's default policies would be a lot easier after
the flask work lands [2]. Instead of doing a bunch of work to
incorporate those default and then re-doing it to accommodate flask, I
think we have a safe checkpoint where we are right now. We can use free
cycles during the RC period to queue up those implementation, mark them
with a -2, and hit the ground running in Stein. This approach feels like
the safest compromise between risk and reward.

*Capability Lists**
*
The capability lists involves a lot of work, not just within keystone,
but also keystonemiddleware, which will freeze next week. I think it's
reasonable to say that this will be something that has to be pushed to
Stein [3].

*MFA Receipts**
*
Much of the code used in the existing approach uses a lot of the same
patterns from the token provider API within keystone [4]. Since the UUID
and SQL parts of the token provider API have been removed, we're also in
the middle of cleaning up a ton of technical debt in that area [5].
Adrian seems OK giving us the opportunity to finish cleaning things up
before reworking his proposal for authentication receipts. IMO, this
seems totally reasonable since it will help us ensure the new code for
authentication receipts doesn't have the bad patterns that have plagued
us with the token provider API.


Does anyone have objections to any of these proposals? If not, I can
start bumping various specs to reflect the status described here.


[0] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
[1]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model
[2]
https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
[3]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds
[4]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt
[5]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945



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] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)

[Juan Antonio Osorio]

 Sounds good to me. Even if pacemaker is heavier, less options and
consistency is better.

Greetings from Mexico :D

On Fri, 13 Jul 2018, 13:33 Emilien Macchi,  wrote:

> Greetings,
>
> We have been supporting both Keepalived and Pacemaker to handle VIP
> management.
> Keepalived is actually the tool used by the undercloud when SSL is enabled
> (for SSL termination).
> While Pacemaker is used on the overcloud to handle VIPs but also services
> HA.
>
> I see some benefits at removing support for keepalived and deploying
> Pacemaker by default:
> - pacemaker can be deployed on one node (we actually do it in CI), so can
> be deployed on the undercloud to handle VIPs and manage HA as well.
> - it'll allow to extend undercloud & standalone use cases to support
> multinode one day, with HA and SSL, like we already have on the overcloud.
> - it removes the complexity of managing two tools so we'll potentially
> removing code in TripleO.
> - of course since pacemaker features from overcloud would be usable in
> standalone environment, but also on the undercloud.
>
> There is probably some downside, the first one is I think Keepalived is
> much more lightweight than Pacemaker, we probably need to run some
> benchmark here and make sure we don't make the undercloud heavier than it
> is now.
>
> I went ahead and created this blueprint for Stein:
> https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default
> I also plan to prototype some basic code soon and provide an upgrade path
> if we accept this blueprint.
>
> This is something I would like to discuss here and at the PTG, feel free
> to bring questions/concerns,
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][ptl][release] deadline for non-client library releases 19 July

[Doug Hellmann]

The deadline for releasing non-client libraries for Rocky is coming up
next week on 19 July (https://releases.openstack.org/rocky/schedule.html).

We have a few libraries that have no releases at all this cycle,
which makes creating the stable branch problematic. Therefore, if
the PTL or release liaison do not propose a release by next week,
the release team may tag HEAD of master with an appropriate version
number (raising at least the minor value) to provide a place to
create the stable/rocky branch. (See Thread at
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html
for the discussion of this policy. We will need to decide whether
to tag based on whether there are any changes on master for the
repository.)

- automaton
- ceilometermiddleware
- debtcollector
- pycadf
- requestsexceptions
- stevedore

Below is the set of unreleased changes for known deliverables
classified as non-client libraries and that look like they may
warrant a release (i.e., they are not only CI configuration changes).
Any items in the report below that are not also in the list above
will not be tagged by the release team because we already have a
tag we can use to create the stable branch. The unrelease changes
for those deliverables will not be available to Rocky users unless
they are backported to the stable branch.

If you manage one of these deliverables, please review the list and
consider proposing a release before the deadline.

Doug


[ Unreleased changes in openstack/automaton (master) ]

Changes between 1.14.0 and ce03d76

* ce03d76 2018-07-11 09:48:53 +0700 Switch to stestr
* 5d8233a 2018-06-06 14:53:48 -0400 fix tox python3 overrides
* 885b3d4 2018-04-21 02:40:23 +0800 Trivial: Update pypi url to new url
* 67b3093 2018-04-13 15:48:27 -0400 fix list of default virtualenvs
* aa12fe5 2018-04-13 15:48:23 -0400 set default python to python3
* f8623e5 2018-03-24 21:02:01 -0400 add lower-constraints job
* 84a646c 2018-03-15 06:45:10 + Updated from global requirements
* 85b7139 2018-01-24 17:58:52 + Update reno for stable/queens
* 08228a1 2018-01-24 00:48:55 + Updated from global requirements
* 22b2b86 2018-01-17 20:27:45 + Updated from global requirements
* 6191cf6 2018-01-16 04:02:08 + Updated from global requirements



[ Unreleased changes in openstack/ceilometermiddleware (master) ]

Changes between 1.2.0 and 8332b9e

* 8332b9e 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* 2f0efc7 2018-02-01 16:33:52 + Update reno for stable/queens




[ Unreleased changes in openstack/debtcollector (master) ]

Changes between 1.19.0 and 858f15d

* 858f15d 2018-06-06 14:53:48 -0400 fix tox python3 overrides
* 2ee856f 2018-04-21 05:21:26 +0800 Trivial: Update pypi url to new url
* 821478a 2018-04-16 11:16:59 -0400 remove obsolete tox environments
* 03292af 2018-04-16 11:16:59 -0400 set default python to python3
* 9e2a2d1 2018-03-15 06:50:50 + Updated from global requirements
| * d8e616d 2018-03-24 21:02:07 -0400 add lower-constraints job
| * 17ffa68 2018-03-21 18:26:09 +0530 pypy is not checked at gate
|/  
* 19616fc 2018-03-10 13:09:54 + Updated from global requirements
* b9a6777 2018-02-28 01:53:43 +0800 Update links in README
* 0ff121e 2018-01-24 17:59:41 + Update reno for stable/queens
| * 4e6aabb 2018-01-24 00:51:19 + Updated from global requirements
|/  
* dceacf1 2018-01-17 20:30:24 + Updated from global requirements
* 81d2312 2017-11-17 10:09:38 +0100 Remove setting of version/release from 
releasenotes



[ Unreleased changes in openstack/glance_store (master) ]

Changes between 0.24.0 and d50ab63

* d50ab63 2018-07-09 15:42:10 + specify region on creating cinderclient
* 573fde0 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* 5a20d47 2018-06-20 19:40:17 -0400 Deprecate 
store_capabilities_update_min_interval
* 54b7ccb 2016-12-20 16:07:45 +1100 Disable verification for Keystone session 
in Swift




[ Unreleased changes in openstack/ironic-lib (master) ]

Changes between 2.13.0 and 9ba805d

* 9ba805d 2018-07-11 18:16:12 +0700 Remove testrepository
* a809787 2018-07-02 11:39:03 +0200 Expose GPT partitioning fixing method
* 89fbae4 2018-06-27 14:50:06 -0400 Switch to using stestr
* 68f017f 2018-06-27 12:36:05 +0200 Do not run API (functional) tests in the CI
* 4e31bc5 2018-06-07 17:34:53 + Remove unneccessary lambda from 
_test_make_partitions
* e4dda71 2018-06-06 15:27:00 -0400 fix tox python3 overrides



[ Unreleased changes in openstack/kuryr (master) ]

Changes between 0.8.0 and cb6eef2

* 6dc4279 2018-05-11 09:33:19 +0700 Replace deprecated "auth_uri" by 
"www_authenticate_uri"



[ Unreleased changes in openstack/mistral-lib (master) ]

Changes between 0.5.0 and d1ccfd0

* d1ccfd0 2018-06-27 15:11:04 + Fixed the documentation of 'run' params
* df04a2b 2018-06-12 16:07:01 +0100 Add the restructuredtext check to the 
flake8 job
* 37fea13 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* de6805b 2018-05-22 13:18:29 -0700 Switch to using 

[openstack-dev] [keystone] Keystone Team Update - Week of 9 July 2018

[Colleen Murphy]

# Keystone Team Update - Week of 9 July 2018

## News

### New Core Reviewer

We added a new core reviewer[1]: thanks to XiYuan for stepping up to take this 
responsibility and for all your hard work on keystone!

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132123.html

### Release Status

This week is our scheduled feature freeze week, but we did not have quite the 
tumult of activity we had at feature freeze last cycle. We're pushing the auth 
receipts work until after the token model refactor is finished[2], to avoid the 
receipts model having to carry extra technical debt. The fine-grained access 
control feature for application credentials is also going to need to be pushed 
to next cycle when more of us can dedicate time to helping with it it[3]. The 
base work for default roles was completed[4] but the auditing of the keystone 
API hasn't been completed yet and is partly dependent on the flask work, so it 
is going to continue on into next cycle[5]. The hierarchical limits work is 
pretty solid but we're (likely) going to let it slide into next week so that 
some of the interface details can be worked out[6].
  
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-10.log.html#t2018-07-10T01:39:27
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-13.log.html#t2018-07-13T14:19:08
[4] https://review.openstack.org/572243
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-13.log.html#t2018-07-13T14:02:03
[6] https://review.openstack.org/557696

### PTG Planning

We're starting to prepare topics for the next PTG in Denver[7] so please add 
topics to the planning etherpad[8].

[7] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132144.html
[8] https://etherpad.openstack.org/p/keystone-stein-ptg

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 20 changes this week, including several of the flask conversion 
patches.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 62 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. The major efforts to focus on are 
the token model refactor[9], the flaskification work[10], and the hierarchical 
project limits work[11].

[9] https://review.openstack.org/#/q/is:open+topic:bug/1778945
[10] https://review.openstack.org/#/q/is:open+topic:bug/1776504
[11] https://review.openstack.org/#/q/is:open+topic:bp/strict-two-level-model

## Bugs

This week we opened 3 new bugs and closed 4.

Bugs opened (3) 
Bug #1780532 (keystone:Undecided) opened by zheng yan 
https://bugs.launchpad.net/keystone/+bug/1780532 
Bug #1780896 (keystone:Undecided) opened by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1780896 
Bug #1781536 (keystone:Undecided) opened by Pawan Gupta 
https://bugs.launchpad.net/keystone/+bug/1781536 

Bugs closed (0) 

Bugs fixed (4) 
Bug #1765193 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1765193 
Bug #1780159 (keystone:Medium) fixed by Sami Makki 
https://bugs.launchpad.net/keystone/+bug/1780159 
Bug #1780896 (keystone:Undecided) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1780896 
Bug #1779172 (oslo.policy:Undecided) fixed by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1779172

## Milestone Outlook

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

This week is our scheduled feature freeze. We are likely going to make an 
extension for the hierarchical project limits work, pending discussion on the 
mailing list.

Next week is the non-client final release date[12], so work happening in 
keystoneauth, keystonemiddleware, and our oslo libraries needs to be finished 
and reviewed prior to next Thursday so a release can be requested in time.

[12] https://review.openstack.org/572243

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)

[Emilien Macchi]

Greetings,

We have been supporting both Keepalived and Pacemaker to handle VIP
management.
Keepalived is actually the tool used by the undercloud when SSL is enabled
(for SSL termination).
While Pacemaker is used on the overcloud to handle VIPs but also services
HA.

I see some benefits at removing support for keepalived and deploying
Pacemaker by default:
- pacemaker can be deployed on one node (we actually do it in CI), so can
be deployed on the undercloud to handle VIPs and manage HA as well.
- it'll allow to extend undercloud & standalone use cases to support
multinode one day, with HA and SSL, like we already have on the overcloud.
- it removes the complexity of managing two tools so we'll potentially
removing code in TripleO.
- of course since pacemaker features from overcloud would be usable in
standalone environment, but also on the undercloud.

There is probably some downside, the first one is I think Keepalived is
much more lightweight than Pacemaker, we probably need to run some
benchmark here and make sure we don't make the undercloud heavier than it
is now.

I went ahead and created this blueprint for Stein:
https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default
I also plan to prototype some basic code soon and provide an upgrade path
if we accept this blueprint.

This is something I would like to discuss here and at the PTG, feel free to
bring questions/concerns,
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] Fwd: [TIP] tox release 3.1.1

[Eric Fried]

Ben-

On 07/13/2018 10:12 AM, Ben Nemec wrote:
>
>
> On 07/12/2018 04:29 PM, Eric Fried wrote:
>> Here it is for nova.
>>
>> https://review.openstack.org/#/c/582392/
>>
 also don't love that immediately bumping the lower bound for tox is
 going to be kind of disruptive to a lot of people.
>>
>> By "kind of disruptive," do you mean:
>>
>>   $ tox -e blah
>>   ERROR: MinVersionError: tox version is 1.6, required is at least 3.1.1
>>   $ sudo pip install --upgrade tox
>>   
>>   $ tox -e blah
>>   
>
> Repeat for every developer on every project that gets updated.  And if
> you installed tox from a distro package then it might not be that
> simple since pip installing over distro packages can get weird.

Not every project; I only install tox once on my system and it works for
all projects, nah? Am I missing something?

Stephen commented similarly that we should wait for distros to pick up
the package. WFM, nothing urgent about this.

>
> No, it's not a huge deal, but then neither is the repetition in
> tox.ini so I'd just as soon leave it be for now.  But I'm not going to
> -1 any patches either.
>
>>
>> ?
>>
>> Thanks,
>> efried
>>
>> On 07/09/2018 03:58 PM, Doug Hellmann wrote:
>>> Excerpts from Ben Nemec's message of 2018-07-09 15:42:02 -0500:

 On 07/09/2018 11:16 AM, Eric Fried wrote:
> Doug-
>
>  How long til we can start relying on the new behavior in the
> gate?  I
> gots me some basepython to purge...

 I want to point out that most projects require a rather old version of
 tox, so chances are most people are not staying up to date with the
 very
 latest version.  I don't love the repetition in tox.ini right now,
 but I
 also don't love that immediately bumping the lower bound for tox is
 going to be kind of disruptive to a lot of people.

 1:
 http://codesearch.openstack.org/?q=minversion&i=nope&files=tox.ini&repos=
>>>
>>> Good point. Any patches to clean up the repetition should probably
>>> go ahead and update that minimum version setting, too.
>>>
>>> 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 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] Need help on this neutron-server start error with vmware_nsx plugin enable

[Tong Liu]

Hi Enoch,

There are two issues here.
1. Plugin 'vmware_nsx.plugin.NsxDvsPlugin' cannot be found.
This could be resolved by changing core_plugin to 'vmware_nsxv' as the
entry point for vmware_nsxv is defined as vmware_nsxv.
2. No module named neutron_fwaas.db.firewall
It looks like you are missing firewall module. Can you try to install
neutron_fwaas module either from rpm or from repo?

Thanks,
Tong

On Fri, Jul 13, 2018 at 4:10 AM Enoch Huangfu  wrote:

> env:
> openstack queen version on centos7
> latest vmware_nsx plugin rpm installed: python-networking-vmware-nsx-12.0.1
>
> when i modify 'core_plugin' value in [default] section of
> /etc/neutron/neutron.conf from ml2 to vmware_nsx.plugin.NsxDvsPlugin, then
> try to start neutron-server with command 'systemctl start neutron-server'
> on control node, the log shows:
>
> 2018-07-13 17:57:50.802 25653 INFO neutron.manager [-] Loading core
> plugin: vmware_nsx.plugin.NsxDvsPlugin
> 2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_create
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_update
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_delete
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.366 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe: 
> router_gateway before_create subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.393 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_create
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.394 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_update
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.394 25653 DEBUG neutron_lib.callbacks.manager [-]
> Subscribe:  > rbac-policy before_delete
> subscribe
> /usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime [-] Error
> loading class by alias: NoMatches: No 'neutron.core_plugins' driver found,
> looking for 'vmware_nsx.plugin.NsxDvsPlugin'
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime Traceback
> (most recent call last):
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/neutron_lib/utils/runtime.py", line 46,
> in load_class_by_alias_or_classname
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
>  namespace, name, warn_on_missing_entrypoint=False)
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/stevedore/driver.py", line 61, in __init__
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
>  warn_on_missing_entrypoint=warn_on_missing_entrypoint
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/stevedore/named.py", line 89, in __init__
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
>  self._init_plugins(extensions)
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/stevedore/driver.py", line 113, in
> _init_plugins
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
>  (self.namespace, name))
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime NoMatches:
> No 'neutron.core_plugins' driver found, looking for
> 'vmware_nsx.plugin.NsxDvsPlugin'
> 2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime [-] Error
> loading class by class name: ImportError: No module named
> neutron_fwaas.db.firewall
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime Traceback
> (most recent call last):
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/neutron_lib/utils/runtime.py", line 52,
> in load_class_by_alias_or_classname
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime
>  class_to_load = importutils.import_class(name)
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 30, in
> import_class
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime
>  __import__(mod_str)
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
> "/usr/lib/python2.7/site-packages/vmware_nsx/plugin.py", line 24, in
> 
> 2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime from
> vmware_nsx.plugins.nsx import plugin as nsx
> 2

[openstack-dev] [octavia][ptg] Stein PTG Planning etherpad for Octavia

[Michael Johnson]

Hi Octavia folks!

I have created an etherpad [1] for topics at the Stein PTG in Denver.
Please indicate if you will be attending or not and any topics you
think we should cover.

Michael

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

__
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] Fwd: [TIP] tox release 3.1.1

[Ben Nemec]

On 07/12/2018 04:29 PM, Eric Fried wrote:

Here it is for nova.

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


also don't love that immediately bumping the lower bound for tox is
going to be kind of disruptive to a lot of people.


By "kind of disruptive," do you mean:

  $ tox -e blah
  ERROR: MinVersionError: tox version is 1.6, required is at least 3.1.1
  $ sudo pip install --upgrade tox
  
  $ tox -e blah
  


Repeat for every developer on every project that gets updated.  And if 
you installed tox from a distro package then it might not be that simple 
since pip installing over distro packages can get weird.


No, it's not a huge deal, but then neither is the repetition in tox.ini 
so I'd just as soon leave it be for now.  But I'm not going to -1 any 
patches either.




?

Thanks,
efried

On 07/09/2018 03:58 PM, Doug Hellmann wrote:

Excerpts from Ben Nemec's message of 2018-07-09 15:42:02 -0500:


On 07/09/2018 11:16 AM, Eric Fried wrote:

Doug-

 How long til we can start relying on the new behavior in the gate?  I
gots me some basepython to purge...


I want to point out that most projects require a rather old version of
tox, so chances are most people are not staying up to date with the very
latest version.  I don't love the repetition in tox.ini right now, but I
also don't love that immediately bumping the lower bound for tox is
going to be kind of disruptive to a lot of people.

1: http://codesearch.openstack.org/?q=minversion&i=nope&files=tox.ini&repos=


Good point. Any patches to clean up the repetition should probably
go ahead and update that minimum version setting, too.

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 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] Rocky blueprints

[Emilien Macchi]

On Thu, Jul 12, 2018 at 11:07 AM Bogdan Dobrelya 
wrote:
[...]

> > -
> https://blueprints.launchpad.net/tripleo/+spec/containerized-undercloud
>
> This needs FFE please.  [...]


No i don't think we need FFE for containerized undercloud. Most of the code
has merged and we're switching the default in tripleoclient as of today if
the patches merge (in gate today probably).
So we're good on this one.
-- 
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][pre] removing default ssh rule from tripleo::firewall::pre

[Lars Kellogg-Stedman]

On Fri, Jul 13, 2018 at 07:47:17AM -0600, Alex Schultz wrote:
> I think we should update the default rule to allow access over the
> control plane but there must be at least 1 rule that we're enforcing
> exist so the deployment and update processes will continue to
> function.

That's makes sense. I'll update the review with that change.

-- 
Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
http://blog.oddbit.com/|

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

Re: [openstack-dev] [kolla][nova][tripleo] Safe guest shutdowns with kolla?

[Alex Schultz]

On Fri, Jul 13, 2018 at 1:54 AM, Bogdan Dobrelya  wrote:
> [Added tripleo]
>
> It would be nice to have this situation verified/improved for containerized
> libvirt for compute nodes deployed with TripleO as well.
>
> On 7/12/18 11:02 PM, Clint Byrum wrote:
>>
>> Greetings! We've been deploying with Kolla on CentOS 7 now for a while,
>> and
>> we've recently noticed a rather troubling behavior when we shutdown
>> hypervisors.
>>
>> Somewhere between systemd and libvirt's systemd-machined integration,
>> we see that guests get killed aggressively by SIGTERM'ing all of the
>> qemu-kvm processes. This seems to happen because they are scoped into
>> machine.slice, but systemd-machined is killed which drops those scopes
>> and thus results in killing off the machines.
>
>
> So far we had observed the similar [0] happening, but to systemd vs
> containers managed by docker-daemon (dockerd).
>
> [0] https://bugs.launchpad.net/tripleo/+bug/1778913
>
>
>>
>> In the past, we've used the libvirt-guests service when our libvirt was
>> running outside of containers. This worked splendidly, as we could
>> have it wait 5 minutes for VMs to attempt a graceful shutdown, avoiding
>> interrupting any running processes. But this service isn't available on
>> the host OS, as it won't be able to talk to libvirt inside the container.
>>
>> The solution I've come up with for now is this:
>>
>> [Unit]
>> Description=Manage libvirt guests in kolla safely
>> After=docker.service systemd-machined.service
>> Requires=docker.service
>>
>> [Install]
>> WantedBy=sysinit.target
>>
>> [Service]
>> Type=oneshot
>> RemainAfterExit=yes
>> TimeoutStopSec=400
>> ExecStart=/usr/bin/docker exec nova_libvirt /usr/libexec/libvirt-guests.sh
>> start
>> ExecStart=/usr/bin/docker start nova_compute
>> ExecStop=/usr/bin/docker stop nova_compute
>> ExecStop=/usr/bin/docker exec nova_libvirt /usr/libexec/libvirt-guests.sh
>> shutdown
>>
>> This doesn't seem to work, though I'm still trying to work out
>> the ordering and such. It should ensure that before we stop the
>> systemd-machined and destroy all of its scopes (thus, killing all the
>> vms), we run the libvirt-guests.sh script to try and shut them down. The
>> TimeoutStopSec=400 is because the script itself waits 300 seconds for any
>> VM that refuses to shutdown cleanly, so this gives it a chance to wait
>> for at least one of those. This is an imperfect solution but it allows us
>> to move forward after having made a reasonable attempt at clean shutdowns.
>>
>> Anyway, just wondering if anybody else using kolla-ansible or kolla
>> containers in general have run into this problem, and whether or not
>> there are better/known solutions.
>
>
> As I noted above, I think the issue may be valid for TripleO as well.
>

I think https://review.openstack.org/#/c/580351/ is trying to address this.

Thanks,
-Alex

>>
>> 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
>>
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
>
> __
> 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][pre] removing default ssh rule from tripleo::firewall::pre

[Alex Schultz]

On Thu, Jul 12, 2018 at 8:17 PM, Lars Kellogg-Stedman  wrote:
> I've had a few operators complain about the permissive rule tripleo
> creates for ssh.  The current alternatives seems to be to either disable
> tripleo firewall management completely, or move from the default-deny
> model to a set of rules that include higher-priority blacklist rules
> for ssh traffic.
>
> I've just submitted a pair of reviews [1] that (a) remove the default
> "allow ssh from everywhere" rule in tripleo::firewall:pre and (b) add
> a DefaultFirewallRules parameter to the tripleo-firewall service.
>
> The default value for this new parameter is the same rule that was
> previously in tripleo::firewall::pre, but now it can be replaced by an
> operator as part of the deployment configuration.
>
> For example, a deployment can include:
>
> parameter_defaults:
>   DefaultFirewallRules:
> tripleo.tripleo_firewall.firewall_rules:
>   '003 allow ssh from internal networks':
> source: '172.16.0.0/22'
> proto: 'tcp'
> dport: 22
>   '003 allow ssh from bastion host':
> source: '192.168.1.10'
> proto: 'tcp'
> dport: 22
>

I've commented on the reviews, but for the wider audience I don't
think we should completely remove these default rules. As we've
switched to ansible (and ssh) being the deployment orchestration
mechanism, it is important that we don't allow a user to lock
themselves out of their cloud via a bad ssh rule. I think we should
update the default rule to allow access over the control plane but
there must be at least 1 rule that we're enforcing exist so the
deployment and update processes will continue to function.

Thanks,
-Alex

> [1] 
> https://review.openstack.org/#/q/topic:feature/firewall%20(status:open%20OR%20status:merged)
>
> --
> Lars Kellogg-Stedman  | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] Need help on this neutron-server start error with vmware_nsx plugin enable

[Enoch Huangfu]

 env:
openstack queen version on centos7
latest vmware_nsx plugin rpm installed: python-networking-vmware-nsx-12.0.1

when i modify 'core_plugin' value in [default] section of
/etc/neutron/neutron.conf from ml2 to vmware_nsx.plugin.NsxDvsPlugin, then
try to start neutron-server with command 'systemctl start neutron-server'
on control node, the log shows:

2018-07-13 17:57:50.802 25653 INFO neutron.manager [-] Loading core plugin:
vmware_nsx.plugin.NsxDvsPlugin
2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_create
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_update
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.017 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_delete
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.366 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: 
router_gateway before_create subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.393 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_create
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.394 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_update
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.394 25653 DEBUG neutron_lib.callbacks.manager [-]
Subscribe: > rbac-policy before_delete
subscribe
/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py:41
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime [-] Error
loading class by alias: NoMatches: No 'neutron.core_plugins' driver found,
looking for 'vmware_nsx.plugin.NsxDvsPlugin'
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime Traceback
(most recent call last):
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/neutron_lib/utils/runtime.py", line 46,
in load_class_by_alias_or_classname
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
 namespace, name, warn_on_missing_entrypoint=False)
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/stevedore/driver.py", line 61, in __init__
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
 warn_on_missing_entrypoint=warn_on_missing_entrypoint
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/stevedore/named.py", line 89, in __init__
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
 self._init_plugins(extensions)
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/stevedore/driver.py", line 113, in
_init_plugins
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
 (self.namespace, name))
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime NoMatches: No
'neutron.core_plugins' driver found, looking for
'vmware_nsx.plugin.NsxDvsPlugin'
2018-07-13 17:57:51.442 25653 ERROR neutron_lib.utils.runtime
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime [-] Error
loading class by class name: ImportError: No module named
neutron_fwaas.db.firewall
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime Traceback
(most recent call last):
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/neutron_lib/utils/runtime.py", line 52,
in load_class_by_alias_or_classname
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime
 class_to_load = importutils.import_class(name)
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 30, in
import_class
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime
 __import__(mod_str)
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/vmware_nsx/plugin.py", line 24, in

2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime from
vmware_nsx.plugins.nsx import plugin as nsx
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/vmware_nsx/plugins/nsx/plugin.py", line
64, in 
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime from
vmware_nsx.plugins.nsx_v import plugin as v
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/site-packages/vmware_nsx/plugins/nsx_v/plugin.py", line
145, in 
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime from
vmware_nsx.services.fwaas.nsx_v import fwaas_callbacks
2018-07-13 17:57:51.443 25653 ERROR neutron_lib.utils.runtime   File
"/usr/lib/python2.7/sit

Re: [openstack-dev] [tripleo] Updates/upgrades equivalent for external_deploy_tasks

[Jiří Stránský]

Thanks for the feedback, John and Emilien.

On 13.7.2018 01:35, Emilien Macchi wrote:

+1 for Option A as well, I feel like it's the one which would give us the
more of flexibility and also I'm not a big fan of the usage of Anchors for
this use case.
Some folks are currently working on extracting these tasks out of THT and I
can already see something like:

 external_deploy_tasks
   - include_role:
   name: my-service
   tasks_from: deploy

 external_update_tasks
   - include_role:
   name: my-service
   tasks_from: update

Or we could re-use the same playbooks, but use tags maybe.
Anyway, I like your proposal and I vote for option A.


I like the tasks_from approach in the snippet. Regarding tags, i'm 
currently thinking of using them to optionally update/upgrade individual 
services which make use of external_*_tasks. E.g. in an environment with 
both OpenShift and Ceph, i'm hoping we could run:


openstack overcloud external-update run --tags ceph
openstack overcloud external-update run --tags openshift

to update them separately if needed. That's the way i'm trying to 
prototype it right now anyway, open to feedback.


Jirka

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

Re: [openstack-dev] [kolla][nova][tripleo] Safe guest shutdowns with kolla?

[Bogdan Dobrelya]

[Added tripleo]

It would be nice to have this situation verified/improved for 
containerized libvirt for compute nodes deployed with TripleO as well.


On 7/12/18 11:02 PM, Clint Byrum wrote:

Greetings! We've been deploying with Kolla on CentOS 7 now for a while, and
we've recently noticed a rather troubling behavior when we shutdown
hypervisors.

Somewhere between systemd and libvirt's systemd-machined integration,
we see that guests get killed aggressively by SIGTERM'ing all of the
qemu-kvm processes. This seems to happen because they are scoped into
machine.slice, but systemd-machined is killed which drops those scopes
and thus results in killing off the machines.


So far we had observed the similar [0] happening, but to systemd vs 
containers managed by docker-daemon (dockerd).


[0] https://bugs.launchpad.net/tripleo/+bug/1778913



In the past, we've used the libvirt-guests service when our libvirt was
running outside of containers. This worked splendidly, as we could
have it wait 5 minutes for VMs to attempt a graceful shutdown, avoiding
interrupting any running processes. But this service isn't available on
the host OS, as it won't be able to talk to libvirt inside the container.

The solution I've come up with for now is this:

[Unit]
Description=Manage libvirt guests in kolla safely
After=docker.service systemd-machined.service
Requires=docker.service

[Install]
WantedBy=sysinit.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStopSec=400
ExecStart=/usr/bin/docker exec nova_libvirt /usr/libexec/libvirt-guests.sh start
ExecStart=/usr/bin/docker start nova_compute
ExecStop=/usr/bin/docker stop nova_compute
ExecStop=/usr/bin/docker exec nova_libvirt /usr/libexec/libvirt-guests.sh 
shutdown

This doesn't seem to work, though I'm still trying to work out
the ordering and such. It should ensure that before we stop the
systemd-machined and destroy all of its scopes (thus, killing all the
vms), we run the libvirt-guests.sh script to try and shut them down. The
TimeoutStopSec=400 is because the script itself waits 300 seconds for any
VM that refuses to shutdown cleanly, so this gives it a chance to wait
for at least one of those. This is an imperfect solution but it allows us
to move forward after having made a reasonable attempt at clean shutdowns.

Anyway, just wondering if anybody else using kolla-ansible or kolla
containers in general have run into this problem, and whether or not
there are better/known solutions.


As I noted above, I think the issue may be valid for TripleO as well.



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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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