Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

[Harry Rybacki]

On Fri, Sep 28, 2018 at 2:54 PM Lance Bragstad  wrote:
>
>
> On Fri, Sep 28, 2018 at 1:03 PM Harry Rybacki  wrote:
>>
>> On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
>>  wrote:
>> >
>> > Ideally I would like to see it in the form of least specific to most 
>> > specific. But more importantly in a way that there is no additional 
>> > delimiters between the service type and the resource. Finally, I do not 
>> > like the change of plurality depending on action type.
>> >
>> > I propose we consider
>> >
>> > ::[:]
>> >
>> > Example for keystone (note, action names below are strictly examples I am 
>> > fine with whatever form those actions take):
>> > identity:projects:create
>> > identity:projects:delete
>> > identity:projects:list
>> > identity:projects:get
>> >
>> > It keeps things simple and consistent when you're looking through 
>> > overrides / defaults.
>> > --Morgan
>> +1 -- I think the ordering if `resource` comes before
>> `action|subaction` will be more clean.
>
>
> ++
>
> These are excellent points. I especially like being able to omit the 
> convention about plurality. Furthermore, I'd like to add that I think we 
> should make the resource singular (e.g., project instead or projects). For 
> example:
>
> compute:server:list
> compute:server:update
> compute:server:create
> compute:server:delete
> compute:server:action:reboot
> compute:server:action:confirm_resize (or confirm-resize)
>
> Otherwise, someone might mistake compute:servers:get, as "list". This is 
> ultra-nick-picky, but something I thought of when seeing the usage of 
> "get_all" in policy names in favor of "list."
>
> In summary, the new convention based on the most recent feedback should be:
>
> ::[:]
>
> Rules:
>
> service-type is always defined in the service types authority
> resources are always singular
>
++ plurality can be determined by related action. +++ for removing
possible ambiguity.

> Thanks to all for sticking through this tedious discussion. I appreciate it.
>
Thanks for pushing the conversation, Lance!
>>
>>
>> /R
>>
>> Harry
>> >
>> > On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad  wrote:
>> >>
>> >> Bumping this thread again and proposing two conventions based on the 
>> >> discussion here. I propose we decide on one of the two following 
>> >> conventions:
>> >>
>> >> ::
>> >>
>> >> or
>> >>
>> >> :_
>> >>
>> >> Where  is the corresponding service type of the project 
>> >> [0], and  is either create, get, list, update, or delete. I think 
>> >> decoupling the method from the policy name should aid in consistency, 
>> >> regardless of the underlying implementation. The HTTP method specifics 
>> >> can still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>> >>
>> >> I think the plurality of the resource should default to what makes sense 
>> >> for the operation being carried out (e.g., list:foobars, create:foobar).
>> >>
>> >> I don't mind the first one because it's clear about what the delimiter is 
>> >> and it doesn't look weird when projects have something like:
>> >>
>> >> :::
>> >>
>> >> If folks are ok with this, I can start working on some documentation that 
>> >> explains the motivation for this. Afterward, we can figure out how we 
>> >> want to track this work.
>> >>
>> >> What color do you want the shed to be?
>> >>
>> >> [0] https://service-types.openstack.org/service-types.json
>> >> [1] 
>> >> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
>> >>
>> >> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad  
>> >> wrote:
>> >>>
>> >>>
>> >>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann  
>> >>> wrote:
>> >>>>
>> >>>>   On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt 
>> >>>>  wrote 
>> >>>>  > tl;dr+1 consistent names
>> >>>>  > I would make the names mirror the API... because the Operator 
>> >>>> setting them knows the API, not the codeIgnore the crazy names in Nova, 
>> >>>> I certainly hate them
>> >

Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names

[Harry Rybacki]

On Fri, Sep 28, 2018 at 1:57 PM Morgan Fainberg
 wrote:
>
> Ideally I would like to see it in the form of least specific to most 
> specific. But more importantly in a way that there is no additional 
> delimiters between the service type and the resource. Finally, I do not like 
> the change of plurality depending on action type.
>
> I propose we consider
>
> ::[:]
>
> Example for keystone (note, action names below are strictly examples I am 
> fine with whatever form those actions take):
> identity:projects:create
> identity:projects:delete
> identity:projects:list
> identity:projects:get
>
> It keeps things simple and consistent when you're looking through overrides / 
> defaults.
> --Morgan
+1 -- I think the ordering if `resource` comes before
`action|subaction` will be more clean.

/R

Harry
>
> On Fri, Sep 28, 2018 at 6:49 AM Lance Bragstad  wrote:
>>
>> Bumping this thread again and proposing two conventions based on the 
>> discussion here. I propose we decide on one of the two following conventions:
>>
>> ::
>>
>> or
>>
>> :_
>>
>> Where  is the corresponding service type of the project [0], 
>> and  is either create, get, list, update, or delete. I think 
>> decoupling the method from the policy name should aid in consistency, 
>> regardless of the underlying implementation. The HTTP method specifics can 
>> still be relayed using oslo.policy's DocumentedRuleDefault object [1].
>>
>> I think the plurality of the resource should default to what makes sense for 
>> the operation being carried out (e.g., list:foobars, create:foobar).
>>
>> I don't mind the first one because it's clear about what the delimiter is 
>> and it doesn't look weird when projects have something like:
>>
>> :::
>>
>> If folks are ok with this, I can start working on some documentation that 
>> explains the motivation for this. Afterward, we can figure out how we want 
>> to track this work.
>>
>> What color do you want the shed to be?
>>
>> [0] https://service-types.openstack.org/service-types.json
>> [1] 
>> https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#default-rule
>>
>> On Fri, Sep 21, 2018 at 9:13 AM Lance Bragstad  wrote:
>>>
>>>
>>> On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann  
>>> wrote:

   On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt 
  wrote 
  > tl;dr+1 consistent names
  > I would make the names mirror the API... because the Operator setting 
 them knows the API, not the codeIgnore the crazy names in Nova, I 
 certainly hate them

 Big +1 on consistent naming  which will help operator as well as developer 
 to maintain those.

  >
  > Lance Bragstad  wrote:
  > > I'm curious if anyone has context on the "os-" part of the format?
  >
  > My memory of the Nova policy mess...* Nova's policy rules traditionally 
 followed the patterns of the code
  > ** Yes, horrible, but it happened.* The code used to have the OpenStack 
 API and the EC2 API, hence the "os"* API used to expand with extensions, 
 so the policy name is often based on extensions** note most of the 
 extension code has now gone, including lots of related policies* Policy in 
 code was focused on getting us to a place where we could rename policy** 
 Whoop whoop by the way, it feels like we are really close to something 
 sensible now!
  > Lance Bragstad  wrote:
  > Thoughts on using create, list, update, and delete as opposed to post, 
 get, put, patch, and delete in the naming convention?
  > I could go either way as I think about "list servers" in the API.But my 
 preference is for the URL stub and POST, GET, etc.
  >  On Sun, Sep 16, 2018 at 9:47 PM Lance Bragstad  
 wrote:If we consider dropping "os", should we entertain dropping "api", 
 too? Do we have a good reason to keep "api"?I wouldn't be opposed to 
 simple service types (e.g "compute" or "loadbalancer").
  > +1The API is known as "compute" in api-ref, so the policy should be for 
 "compute", etc.

 Agree on mapping the policy name with api-ref as much as possible. Other 
 than policy name having 'os-', we have 'os-' in resource name also in nova 
 API url like /os-agents, /os-aggregates etc (almost every resource except 
 servers , flavors).  As we cannot get rid of those from API url, we need 
 to keep the same in policy naming too? or we can have policy name like 
 compute:agents:create/post but that mismatch from api-ref where agents 
 resource url is os-agents.
>>>
>>>
>>> Good question. I think this depends on how the service does policy 
>>> enforcement.
>>>
>>> I know we did something like this in keystone, which required policy names 
>>> and method names to be the same:
>>>
>>>   "identity:list_users": "..."
>>>
>>> Because the initial implementation of policy enforcement used a decorator 
>>> like this:
>>>
>>>   from keystone import controller
>>>
>>>   

Re: [openstack-dev] [Openstack-sigs] [tc][uc]Community Wide Long Term Goals

[Harry Rybacki]

On Tue, Sep 18, 2018 at 12:57 PM Lance Bragstad  wrote:
>
>
>
> On Tue, Sep 18, 2018 at 10:17 AM Doug Hellmann  wrote:
>>
>> Excerpts from Zhipeng Huang's message of 2018-09-14 18:51:40 -0600:
>> > Hi,
>> >
>> > Based upon the discussion we had at the TC session in the afternoon, I'm
>> > starting to draft a patch to add long term goal mechanism into governance.
>> > It is by no means a complete solution at the moment (still have not thought
>> > through the execution method yet to make sure the outcome), but feel free
>> > to provide your feedback at https://review.openstack.org/#/c/602799/ .
>> >
>> > --
>> > Zhipeng (Howard) Huang
>>
>> [I commented on the patch, but I'll also reply here for anyone not
>> following the review.]
>>
>> I'm glad to see the increased interest in goals. Before we change
>> the existing process, though, I would prefer to see engagement with
>> the current process. We can start by having SIGs and WGs update the
>> etherpad where we track goal proposals
>> (https://etherpad.openstack.org/p/community-goals) and then we can
>> see if we actually need to manage goals across multiple release
>> cycles as a single unit.
>
>
> Depending on the official outcome of this resolution, I was going to try and 
> use the granular RBAC work to test out this process.
>
My thoughts exactly.

> I can still do that, or I can hold off if appropriate.

Breaking down the remaining work per Doug's suggestion would be good.
We've done this a time-or-three before as the target
has moved around. It's probably do for another one.

/R
>
>>
>>
>> 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] [oslo] proposing Moisés Guimarães for oslo.config core

[Harry Rybacki]

On Wed, Aug 1, 2018 at 9:28 AM Doug Hellmann  wrote:
>
> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
>
> Please indicate your approval or concerns with +1/-1.
>
+1!

> 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

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

Re: [openstack-dev] [keystone] Adding Wangxiyuan to keystone core

[Harry Rybacki]

On Tue, Jul 10, 2018 at 6:06 PM Lance Bragstad  wrote:
>
> Hi all,
>
> Today we added Wangxiyuan to the keystone core team [0]. He's been doing
> a bunch of great work over the last couple releases and has become a
> valuable reviewer [1][2]. He's also been instrumental in pushing forward
> the unified limits work not only in keystone, but across projects.
>
> Thanks Wangxiyuan for all your help and welcome to the team!
>
+1 well deserved!

> Lance
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-10-16.00.log.html#l-100
> [1] http://stackalytics.com/?module=keystone-group
> [2] http://stackalytics.com/?module=keystone-group=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

Harry

__
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] Signing off

[Harry Rybacki]

On Wed, May 30, 2018 at 5:05 AM, Colleen Murphy  wrote:
> On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
>> Hi
>>
>> It is with a somewhat heavy heart that I have decided that it is time to
>> hang up my keystone core status. Having been involved since the closing
>> stages of Folsom, I've had a good run! When I look at how far keystone
>> has come since the v2 days, it is remarkable - and we should all feel a
>> sense of pride in that.
>> Thanks to all the hard work, commitment, humour and support from all the
>> keystone folks over the years - I am sure we will continue to interact
>> and meet among the many other open source projects that many of us are
>> becoming involved with. Ad astra!
>> Best regards,
>>
>> Henry
>> Twitter: @henrynash
>> linkedIn: www.linkedin.com/in/henrypnash
>>
>
> Thank you for all the incredible work you've done for this project! You were 
> an invaluable asset at the PTGs, it was great to see you there even though 
> keystone hasn't been your main focus lately. Wishing you the best of luck.
>
Hear, hear. Keystone has largely been shaped by those continual
efforts, Henry. Your face may be missed but your voice will hang
around to guide us future. Hope to run into you somewhere, sometime!

/R

> 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

Harry

__
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] [docs] Automating documentation the tripleo way?

[Harry Rybacki]

On Wed, May 16, 2018 at 2:51 PM, Wesley Hayutin  wrote:
>
>
> On Wed, May 16, 2018 at 2:41 PM Doug Hellmann  wrote:
>>
>> Excerpts from Petr Kovar's message of 2018-05-16 17:39:14 +0200:
>> > Hi all,
>> >
>> > In the past few years, we've seen several efforts aimed at automating
>> > procedural documentation, mostly centered around the OpenStack
>> > installation guide. This idea to automatically produce and verify
>> > installation steps or similar procedures was mentioned again at the last
>> > Summit (https://etherpad.openstack.org/p/SYD-install-guide-testing).
>> >
>> > It was brought to my attention that the tripleo team has been working on
>> > automating some of the tripleo deployment procedures, using a Bash
>> > script
>> > with included comment lines to supply some RST-formatted narrative, for
>> > example:
>> >
>> >
>> > https://github.com/openstack/tripleo-quickstart-extras/blob/master/roles/overcloud-prep-images/templates/overcloud-prep-images.sh.j2
>> >
>> > The Bash script can then be converted to RST, e.g.:
>> >
>> >
>> > https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-queens-rdo_trunk-baremetal-dell_fc430_envB-single_nic_vlans-27/docs/build/
>> >
>> > Source Code:
>> >
>> >
>> > https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/collect-logs
>> >
>> > I really liked this approach and while I don't want to sound like
>> > selling
>> > other people's work, I'm wondering if there is still an interest among
>> > the
>> > broader OpenStack community in automating documentation like this?
>> >
>> > Thanks,
>> > pk
>> >
>>
>> Weren't the folks doing the training-labs or training-guides taking a
>> similar approach? IIRC, they ended up implementing what amounted to
>> their own installer for OpenStack, and then ended up with all of the
>> associated upgrade and testing burden.
>>
>> I like the idea of trying to use some automation from this, but I wonder
>> if we'd be better off extracting data from other tools, rather than
>> building a new one.
>>
>> Doug
>
>
> So there really isn't anything new to create, the work is done and executed
> on every tripleo change that runs in rdo-cloud.
>
> Instead of dismissing the idea upfront I'm more inclined to set an
> achievable small step to see how well it works.  My thought would be to
> focus on the upcoming all-in-one installer and the automated doc generated
> with that workflow.  I'd like to target publishing the all-in-one tripleo
> installer doc to [1] for Stein and of course a section of tripleo.org.
>
> What do you think?
>
Interesting idea -- discussing this a bit at Summit (for those who
will be in attendance) seems like a good place to start.

> [1] https://docs.openstack.org/queens/deploy/
>
>
>>
>>
>> __
>> 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

[openstack-dev] [tc] [nova] [octavia] [ironic] [keystone] [policy] Spec. Freeze Exception - Default Roles

[Harry Rybacki]

Greetings All,

After a discussion in #openstack-tc[1] earlier today, the Keystone
team is adjusting its approach in proposing default roles[2].
Subsequently, I have ported the current default roles specification
from openstack-specs[3] to keystone-specs[2].

The original review has been in a pretty stable state for a few weeks.
As such, I propose we allow the new spec an exception to the original
Rocky-m1 proposal freeze date.

I invite more discussion around default roles, and our proposed
approach. The Keystone team has a forum session[4] dedicated to this
topic at 1135 on day one of the Vancouver Summit. Everyone should feel
welcome and encouraged to attend -- we hope that this work will lead
to an OpenStack Community Goal in a not-so-distant release.

[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-04.log.html#t2018-05-04T14:40:36
[2] - https://review.openstack.org/#/c/566377/
[3] - https://review.openstack.org/#/c/523973/
[4] - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21761/default-roles


/R

Harry Rybacki

__
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] [policy] no policy meeting today

[Harry Rybacki]

Perhaps this meeting would be a good opportunity to get some broader
discussion on our default roles spec we have proposed[1].

[1] - https://review.openstack.org/#/c/523973/8/specs/define-default-roles.rst


/R

Harry

On Wed, May 2, 2018 at 10:17 AM, Lance Bragstad  wrote:
> Hi all,
>
> I'm going to cancel the policy meeting today since attendance has been
> waning the last month or two and there are no items on the agenda.
>
> We should discuss whether or not we want to continue using this meeting.
> At this point, most of the policy work is in helping projects consume
> outcomes from those meetings.The meeting was originally proposed to help
> design a better policy system across OpenStack and figure out how to
> move towards it. If we feel we've come up with a direction that achieves
> that, I'm happy to summarize things and drop the bi-weekly meeting.
> Otherwise, if there are use cases we need to tackle next, we can
> continue holding the meeting.
>
> Thoughts?
>
> Lance
>
>
> __
> 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] FFE for application credentials

[Harry Rybacki]

On Thu, Jan 25, 2018 at 4:24 PM, Colleen Murphy  wrote:
> +1
>
+1

> On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
>> Hey all,
>>
>> The work for system assignments and system scope [0] has been up for a
>> while, reviewers are happy with it, and it is slowly making it's way
>> through the gate. I propose we consider a feature freeze exception given
>> the state of the gate and the frequency of rechecks/failures.
>>
>> Thoughts, comments, or concerns?
>>
>> [0]
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
>>
>>
>>
>> __
>> 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] [keystone] FFE for unified limits

[Harry Rybacki]

On Thu, Jan 25, 2018 at 4:17 PM, Colleen Murphy  wrote:
> +1
>
+1
> On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad  wrote:
>> Hey all,
>>
>> The work for unified limits [0] has been up for a while, reviewers are
>> happy with it being experimental, and it is slowly making it's way
>> through the gate. I propose we consider a feature freeze exception given
>> the state of the gate and the frequency of rechecks/failures.
>>
>> Thoughts, comments, or concerns?
>>
>> [0]
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limits
>>
>>
>>
>> __
>> 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] [keystone] adding Gage Hugo to keystone core

[Harry Rybacki]

+100 -- congratulations, Gage!

On Tue, Jan 16, 2018 at 2:24 PM, Raildo Mascena de Sousa Filho <
rmasc...@redhat.com> wrote:

> +1
>
> Congrats Gage, very well deserved!
>
> Cheers,
>
> On Tue, Jan 16, 2018 at 4:02 PM Lance Bragstad 
> wrote:
>
>> Hey folks,
>>
>> In today's keystone meeting we made the announcement to add Gage Hugo
>> (gagehugo) as a keystone core reviewer [0]! Gage has been actively
>> involved in keystone over the last several cycles. Not only does he
>> provide thorough reviews, but he's really stepped up to help move the
>> project forward by keeping a handle on bugs, fielding questions in the
>> channel, and being diligent about documentation (especially during
>> in-person meet ups).
>>
>> Thanks for all the hard work, Gage!
>>
>> [0]
>> http://eavesdrop.openstack.org/meetings/keystone/2018/
>> keystone.2018-01-16-18.00.log.html
>>
>>
>> 
>> __
>> 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
>>
>
>
> --
>
> Raildo mascena
>
> Software Engineer, Identity Managment
>
> Red Hat
>
> 
> 
> TRIED. TESTED. TRUSTED. 
>
> __
> 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] Proposing Wesley Hayutin core on TripleO CI

[Harry Rybacki]

On Wed, Dec 6, 2017 at 11:19 AM, mathieu bultel  wrote:
> On 12/06/2017 04:45 PM, Emilien Macchi wrote:
>> Team,
>>
>> Wes has been consistently and heavily involved in TripleO CI work.
>> He has a very well understanding on how tripleo-quickstart and
>> tripleo-quickstart-extras work, his number and quality of reviews are
>> excellent so far. His experience with testing TripleO is more than
>> valuable.
>> Also, he's always here to help on TripleO CI issues or just
>> improvements (he's the guy filling bugs on a Saturday evening).
>> I think he would be a good addition to the TripleO CI core team
>> (tripleo-ci, t-q and t-q-e repos for now).
>> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
>> to move on and get you +2 ;-)
>>
>> As usual, it's open for voting, feel free to bring any feedback.
>> Thanks everyone,
>
> +1 of course
>
+1!
>
> __
> 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] Keystone weekly update - Week of 27 November 2017

[Harry Rybacki]

On Fri, Dec 1, 2017 at 11:09 AM, Colleen Murphy  wrote:
> In the "Making OpenStack More Palatable to Part-Time Contributors"
> Forum session in Sydney, one barrier to contribution that came up was
> keeping up with everything happening in OpenStack. The dev mailing
> list is a firehose and IRC can be just as daunting, especially for
> contributors in non-Americas timezones. The current time of the weekly
> team meeting basically excludes a third of the world from
> participating. I don't propose we stop having them, but it would be
> good to try to be a little more inclusive. Following the lead of some
> of the other folks in our community, I propose we consolidate the
> mailing list discussions, IRC meetings, and general discussions in a
> weekly update, just to share what we've been up to and what's
> important to know.
>
+2

> I don't guarantee I'll get to this every week but I'll make an effort.
> Please feel free to provide feedback on what you think would be useful
> to see in a newsletter like this. If you want to help out, I created
> an etherpad - feel free to help fill in the sections or edit the
> template itself.
>
With a nice template (based on this email?) I'm sure other Keystone folk
can help out when you find yourself too busy for a given week.

> https://etherpad.openstack.org/p/keystone-team-newsletter
>
> Without further ado, here's what's been going on this week from my 
> perspective:
>
> # Keystone Team Update - Week of 27 November 2017
>
> ## News
>
> Next week we'll use the meeting time to have a video conference to do
> a milestone retrospective for Queens-2:
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124997.html
>
> We abandoned some very old patches in gerrit. If we abandoned one that
> we shouldn't have, come talk to us:
>
> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124910.html
>
> We used the last weekly keystone meeting to talk about open specs. In
> particular we talked about the Unified Limits spec and what the
> implications are for requiring a region ID in order to create a
> registered limit:
>
> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-11-28-18.00.log.txt
>
> In the weekly policy meeting we talked about using the next round of
> community goals to get projects using the new system scope, but
> decided that we'd like to have a couple of early adopters before
> proposing it community-wide and so we'll likely hold off on proposing
> it until the following cycle. We did decide that we could start a
> community-wide discussion on defining a set of default-roles by
> proposing a cross-project spec.
>
> http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-11-29-16.00.log.txt
>
> ## Open Specs
>
> Search query: https://goo.gl/pc8cCf
>
> We only have one spec proposed for Queens still under review:
>
> Limits API: https://review.openstack.org/455709
>
> ## Recently Merged Changes
>
> Search query: https://goo.gl/hdD9Kw
>
> We merged 24 changes this week. Notably, we merged a few Queens specs
> and some policy roadmaps:
>
> Repropose application credentials to queens: 
> https://review.openstack.org/512505
> Specification for system roles: https://review.openstack.org/460344
> Outline policy goals: https://review.openstack.org/460344
> Add policy roadmap for security: https://review.openstack.org/#/c/462733/
>
> ## Changes that need Attention
>
> Search query:https://goo.gl/YiLt6o
>
> There are 51 changes that are passing CI and have no negative reviews,
> so these authors are waiting for feedback from reviewers. Please give
> them a look.
>
> That doesn't mean you should ignore changes that are failing CI or
> have negative reviews, it's just that the changes highlighted here are
> more likely to be in the reviewers' court rather than a requiring a
> new revision from the author. Sometimes negative votes are misplaced
> or CI needs to be fixed project-wide so this doesn't necessarily mean
> that this list is the only one to mind.
>
> ## Milestone Outlook
>
> https://releases.openstack.org/queens/schedule.html
>
> Queens-2 is next week. That means the specification freeze is on
> December 8 and all Queens specifications must be merged by then or
> will be pushed to the next release. The only open spec affected by
> this is the Limits API spec.
>
> ## Shout-outs
>
> wangxiyuan has been doing a ton of awesome work squashing our bugs and
> taking on the Unified Limits feature. Thanks wangxiyuan!
>
> ## Help with this newsletter
>
> Help contribute to this newsletter by editing the etherpad:
> https://etherpad.openstack.org/p/keystone-team-newsletter
>
This is a wonderful summary, Colleen, thank you for taking the time to
write this up!
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Harry Rybacki]

On Wed, Nov 29, 2017 at 2:34 PM, John Trowbridge  wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
>
+100
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update

[Harry Rybacki]

On Tue, Nov 28, 2017 at 12:14 PM, Lance Bragstad  wrote:
> Hi all,
>
> As Queens 2 comes to a close next week, I figured it was a good time to
> recap the policy goal [0]. The following is the breakdown of where projects
> stand with how I've been tracking things.
>
> Not Started
>
> openstack/ceilometer
> openstack/congress
> openstack/networking-bgpvpn
> openstack/networking-midonet
> openstack/networking-odl
> openstack/neutron-dynamic-routing
> openstack/neutron-fwaas
> openstack/neutron-lib
> openstack/solum
> openstack/swift
>
Okay, I think I can jump into these and help out a bit. Any of the
above you would recommend as a starter?

> In Progress
>
> openstack/barbican
> openstack/cinder
> openstack/cloudkitty
> openstack/glance
> openstack/heat
> openstack/manila
> openstack/mistral
> openstack/neutron
> openstack/panko
> openstack/python-heatclient
> openstack/tacker
> openstack/tricircle
> openstack/trove
> openstack/vitrage
> openstack/watcher
> openstack/zaqar
>
> Completed
>
> openstack/designate
> openstack/freezer
> openstack/ironic
> openstack/keystone
> openstack/magnum
> openstack/murano
> openstack/nova
> openstack/octavia
> openstack/sahara
> openstack/searchlight
> openstack/senlin
> openstack/zun
>
> Note that a lot of the projects "In Progress" are only pending reviews to
> publish sample policy documentation. If a project you're working on has
> already done this, please let me know and I'll get a patch posted to
> governance to mark the status as completed. If you have patches in flight
> the works towards this goal, please be sure to use the
> `policy-and-docs-in-code` topic in Gerrit. It will be picked up and tracked
> automatically [1]. With such a large change, visualizing and leaning on
> automation in any way we can really helps in managing the goal.
>
> Finally, I'd like to give a huge "Thank You" to Dai Dang Van, Nam Nguyen
> Hoai, and Hieu LE. They've all dug into to help other projects complete the
> goal and review patches. We certainly wouldn't be seeing as many projects in
> the Completed or In Progress list if not for their help.
>
> As always, feel free to come find me on IRC if you have questions. If I'm
> missing status for your project(s), just ping me and I'll make sure things
> get tracked and recorded.
>
> Thanks for the time!
>
> Lance
>
>
> [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> [1] https://www.lbragstad.com/policy-burndown/
>
> __
> 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][CI] FreeIPA Deployment

[Harry Rybacki]

On Thu, Aug 31, 2017 at 12:52 PM, Juan Antonio Osorio
 wrote:
> Something that just came to my mind: Another option would be to allocate an
> extra IP Address for the undercloud, that would be dedicated to FreeIPA, and
> that way we MAY be able to deploy the FreeIPA server in the undercloud. If
> folks are OK with this I could experiment on this front. Maybe I could try
> to run FreeIPA on a container [1] (which wasn't available when I started
> working on this).
>
Interesting idea, Ozz! I'm not sure what/if the security implications
of running them
on the same host would be.

I'm cc'ing Toure to discuss possible workflow approach to this as well.

/R

> [1] https://hub.docker.com/r/freeipa/freeipa-server/
>
> On Sat, Aug 26, 2017 at 2:52 AM, Emilien Macchi  wrote:
>>
>> On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
>>  wrote:
>> > The second option seems like the most viable. Not sure how the TripleO
>> > integration would go though. Care to elaborate on what you had in mind?
>>
>> Trying to reproduce what we did with ceph-ansible and use Mistral to
>> deploy FreeIPA with an external deployment tool.
>> Though I find the solution quite complex, maybe we can come-up with an
>> easier approach this time?
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [TripleO] CI design session at the PTG

[Harry Rybacki]

On Mon, Aug 28, 2017 at 9:42 AM, David Moreau Simard  wrote:
> Hi,
>
> (cc whom I would at least like to attend)
>
> The PTG would be a great opportunity to talk about CI design/layout
> and how we see things moving forward in TripleO with Zuul v3, upstream
> and in review.rdoproject.org.
>
> Can we have a formal session on this scheduled somewhere ?
>
+1

> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
> __
> 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][CI] FreeIPA Deployment

[Harry Rybacki]

Greetings Stackers,

Recently, I brought up a discussion around deploying FreeIPA via
TripleO-Quickstart vs TripleO. This is part of a larger discussion
around expanding security related CI coverage for OpenStack.

A few months back, I added the ability to deploy FreeIPA via
TripleO-Quickstart through three reviews:

1) Adding a role to deploy FreeIPA via OOOQ_E[1]
2) Providing OOOQ with the ability to deploy a supplemental node
(alongside the undercloud)[2]
3) Update the quickstart-extras playbook to deploy FreeIPA[3]


The reasoning behind this is as follows (copied from a conversation
with jaosorior):

> So the deal is that both the undercloud and the overcloud need to be 
> registered as a FreeIPA client.
> This is because they need to authenticate to it in order to execute actions.
>
> * The undercloud needs to have FreeIPA credentials because it's running 
> novajoin, which in turn
> executes requests to FreeIPA in order to create service principals
>  - The service principals are ultimately the service name and the node name 
> entries for which we'll
> requests the certificates.
> * The overcloud nodes need to be registered and authenticated to FreeIPA 
> (which right now happens > through a cloud-init script provisioned by 
> nova/nova-metadata) because that's how it requests
> certificates.
>
> So the flow is as follows:
>
> * FreeIPA node is provisioned.
>  - We'll appropriate credentials at this point.
>  - We register the undercloud as a FreeIPA client and get an OTP (one time 
> password) for it
> - We add the OTP to the undercloud.conf and enable novajoin.
> * We trigger the undercloud install.
>  - after the install, we have novajoin running, which is the service that 
> registers automatically the
> overcloud nodes to FreeIPA.
> * We trigger the overcloud deploy
>  - We need to set up a flag that tells the deploy to pass appropriate nova 
> metadata (which tells
> novajoin that the nodes should be registered).
>  - profit!! we can now get certificates from the CA (and do other stuff that 
> FreeIPA allows you to do,
> such as use kerberos auth, control sudo rights of the nodes' users, etc.)
>
> Since the nodes need to be registered to FreeIPA, we can't rely on FreeIPA 
> being installed by
> TripleO, even if that's possible by doing it through a composable service.
> If we would use a composable service to install FreeIPA, the flow would be 
> like this:
>
> * Install undercloud
> * Install overcloud with one node (running FreeIPA)
> * register undercloud node to FreeIPA and modify undercloud.conf
> * Update undercloud
> * scale overcloud and register the rest of the nodes to FreeIPA through 
> novajoin.
>
> So, while we could install FreeIPA with TripleO. This really complicates the 
> deployment to an
> unnecessary point.
>
> So I suggest keeping the current behavior, which treats FreeIPA as a separate 
> node to be
> provisioned before the undercloud). And if folks would like to have a 
> separate FreeIPA node for their > overcloud deployment (which could provision 
> certs for the tenants) then we could do that as a
> composable service, if people request it.

I am now re-raising this to the group at large for discussion about
the merits of this approach vs deploying via TripleO itself.


[1] - https://review.openstack.org/#/c/436198/
[2] - https://review.openstack.org/#/c/451523/
[3] - https://review.openstack.org/#/c/453223/

/R

Harry Rybacki

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

Re: [openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Harry Rybacki]

On Fri, Jun 23, 2017 at 6:14 AM, Sean Dague  wrote:
> On 06/23/2017 05:44 AM, Thierry Carrez wrote:
>> Lance Bragstad wrote:
>>> Is the role of a goal "champion" limited to a single person? Can it be
>>> distributed across multiple people pending actions are well communicated?
>>
>> I'm a bit torn on that. On one hand work can definitely (and probably
>> should) be covered by multiple people. But I like the idea that it's
>> someone's responsibility to ensure that progress is made (even if that
>> person ends up delegating all the work). The trick is, it's easy for
>> everyone to assume that the work is covered since someone has signed up
>> for it.
>>
>> It's like the PTL situation -- work is done by the group and it's great
>> to have a clear go-to person to keep track of things, until the PTL has
>> to do everything because they end up as the default assignee for everything.
>
> I agree, there should be a single name here. They can delegate and
> collect up a group, but at the end of the day one person should be
> responsible for it.
>
Aye, this sounds much like a committee chair. Ideally, even if in name
only, it provides a single point of communication for folks regardless
of whether they are directly working on the goal or not.

Two points: It may require some additional monitoring from the
respective PTL and, we should have have a plan in place for shifting
responsibilities if a given champion can no longer take on the role
(illness, injury, work changes, etc...).

- Harry

> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] New Office Hours Proposal

[Harry Rybacki]

Greetings All,

We would like to foster a more interactive community within Keystone
focused on fixing bugs on a regular basis! On a regular datetime (to
be voted upon) we will have "office hours"[1] where Keystone cores
will be available specifically to advise, help and review your efforts
in squashing bugs. We want to aggressively attack our growing list of
bugs and make sure Keystone is as responsive as possible to fixing
them. The best way to do this is get people working on them and have
the resources to get the fixes reviewed and merged.

Please take a few moments to fill out our Doodle poll[2] to select the
time block(s) that work best for you. We will tally the results and
announce the official Keystone Office hours on Friday, 23-June-2017,
by 2100 (UTC).

[1] - https://etherpad.openstack.org/p/keystone-office-hours
[2] - https://beta.doodle.com/poll/epvs95npfvrd3h5e


/R

Harry Rybacki
Software Engineer, Red Hat

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

Re: [openstack-dev] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

[Harry Rybacki]

On Thu, Jun 15, 2017 at 1:57 PM, Brant Knudson  wrote:
>
>
> On Thu, Jun 15, 2017 at 5:14 AM, Mikhail Fedosin  wrote:
>>
>> Recently I decided to remove deprecated parameters from keystone_authtoken
>> mistral config and replace them with recommended function of devstack [1].
>> In doing so, I discovered a strange behavior of configuration mechanism, and
>> specifically parameters auth_uri and auth_url.
>>
>> 1. The parameter auth_url is not included in the list of the middleware
>> parameters, there is auth_uri only [2]. Nevertheless, it must be present,
>> because it's required by identity plugin [3]. Attempts to remove or replace
>> it with the recommended auth_uri result with these stacktraces [4]
>>
>> 2. Even if auth_url is set, it can't be used later, because it is not
>> registered in oslo_config [5]
>>
>> So I would like to get an advise from keystone team and understand what I
>> should do in such cases. Official documentation doesn't add clarity on the
>> matter because it recommends to use auth_uri in some cases and auth_url in
>> others.
>
>
> While to a human auth_uri and auth_url might look very similar they're
> treated completely differently by auth_token / keystoneauth. One doesn't
> replace the other in any way. So it shouldn't be surprising that
> documentation would say to use auth_uri for one thing and auth_url for
> something else.
>
In this case it's probably worth filing a docs bug against Keystone.
If one person is confused by this, others likely are or will be.

- Harry

>  - Brant
>
>
>>
>> My suggestion is to add auth_url in the list of keystone authtoken
>> middleware config options, so that the parameter can be used by the others.
>>
>> Best,
>> Mike
>>
>> [1] https://review.openstack.org/#/c/473796/
>> [2]
>> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L31
>> [3]
>> https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/identity.py#L37
>> [4] http://paste.openstack.org/show/612662/
>> [5] http://paste.openstack.org/show/612664/
>>
>> __
>> 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] Containers Deep Dive - 15th June

[Harry Rybacki]

Thanks for putting this together, Jirka. The recording is very much
worth anyone's time!

On Thu, Jun 15, 2017 at 12:36 PM, Jiří Stránský  wrote:
> On 15.6.2017 18:25, Jiří Stránský wrote:
>>
>> On 9.6.2017 16:49, Jiří Stránský wrote:
>>>
>>> Hello,
>>>
>>> as discussed previously on the list and at the weekly meeting, we'll do
>>> a deep dive about containers. The time:
>>>
>>> Thursday 15th June, 14:00 UTC (the usual time)
>>>
>>> Link for attending will be at the deep dives etherpad [1], preliminary
>>> agenda is in another etherpad [2], and i hope i'll be able to record it
>>> too.
>>
>>
>> The recording is available here:
>>
>> https://www.youtube.com/watch?v=xhTwHfi65p8
>
>
> And the slides:
>
> https://jistr.github.io/tripleo-deep-dive-containers-june-2017/
>
>
>>
>> Thanks Carlos for managing our youtube channel!
>>
>> Jirka
>>
>>>
>>> This time it may be more of a "broad dive" :) as that's what containers
>>> in TripleO mostly are -- they add new bits into many TripleO
>>> areas/topics (composable services/upgrades, Quickstart/CI, etc.). So
>>> i'll be trying to bring light to the container-specific parts of the
>>> mix, and assume some familiarity with the generic TripleO
>>> concepts/features (e.g. via docs and previous deep dives). Given this
>>> pattern, i'll have slides with links into code. I'll post them online,
>>> so that you can reiterate or examine some code more closely later, in
>>> case you want to.
>>>
>>>
>>> Have a good day!
>>>
>>> Jirka
>>>
>>> [1] https://etherpad.openstack.org/p/tripleo-deep-dive-topics
>>> [2] https://etherpad.openstack.org/p/tripleo-deep-dive-containers
>>>
>>>
>>> __
>>> 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

__
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] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

[Harry Rybacki]

On Thu, Jan 26, 2017 at 12:25 PM, Martin André  wrote:
> On Tue, Jan 24, 2017 at 6:03 PM, Juan Antonio Osorio
>  wrote:
>> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
>> on the current CI solution and in getting tripleo-quickstart jobs for
>> it); So I would like to propose him as part of the TripleO CI core team.
>>
>> I think he'll make a great addition to the team and will help move CI
>> issues forward quicker.
>
> +1
>
+1

>> Best Regards,
>>
>>
>>
>> --
>> Juan Antonio Osorio R.
>> jaosorior
>>
>>
>> __
>> 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

[openstack-dev] [tripleo] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

[Harry Rybacki]

Greetings All,

Folks have been diligently working on the blueprint[1] to prepare
TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for
their transition into TripleO-CI. Presently, our aim is to begin the
actual transition to OOOQ on 4-Feb-2017. We are tracking our work on
the RDO-Infra Trello board[4] and holding public discussion of key
blockers on the team’s scrum etherpad[5].

We are hosting weekly transition update meetings (1600-1700 UTC) and
would like to invite folks to participate. Specifically, we are
looking for at least one stakeholder in the existing TripleO-CI to
join us as we prepare to migrate OOOQ. Attend and map out job/feature
coverage to identify any holes so we can begin plugging them. Please
reply off-list or reach out to me (hrybacki) on IRC to be added to the
transition meeting calendar invite.

[1] - 
https://blueprints.launchpad.net/tripleo/+spec/use-tripleo-quickstart-and-tripleo-quickstart-extras-for-the-tripleo-ci-toolset
[2] - https://github.com/openstack/tripleo-quickstart/
[3] - https://github.com/openstack/tripleo-quickstart-extras/
[4] - https://trello.com/b/HhXlqdiu/rdo
[5] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum


/R

Harry Rybacki

__
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] proposing Michele Baldessari part of core team

[Harry Rybacki]

+1!

On Fri, Nov 4, 2016 at 2:34 PM, Juan Antonio Osorio  wrote:
> +1 :D
>
>
> On 4 Nov 2016 20:16, "Jiří Stránský"  wrote:
>>
>> +1, Michele does great reviews, and his contributions around HA and
>> upgrades have been crucial.
>>
>> On 4.11.2016 18:40, Emilien Macchi wrote:
>>>
>>> MIchele Baldessari (bandini on IRC) has consistently demonstrated high
>>> levels of contributions in TripleO projects, specifically in High
>>> Availability area where's he's for us a guru (I still don't understand
>>> how pacemaker works, but hopefully he does).
>>>
>>> He has done incredible work on composable services and also on
>>> improving our HA configuration by following reference architectures.
>>> Always here during meetings, and on #tripleo to give support to our
>>> team, he's a great team player and we are lucky to have him onboard.
>>> I believe he would be a great core reviewer on HA-related work and we
>>> expect his review stats to continue improving as his scope broadens
>>> over time.
>>>
>>> As usual, feedback is welcome and please vote for this proposal!
>>>
>>> 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 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] TripleO-Quickstart Driven Doc Generation Updates

[Harry Rybacki]

Greetings All,

Detailed post TripleO-Quickstart build doc generation is coming along
smoothly. After much discussion between myself, adarazs, weshay, and
larsks -- I believe to have found a solution that impacts
TripleO-Quickstart and external roles minimally. Combining work from
trown[1] and an old awk script from way-back-when, all we need is to:

  1. Ensure as much work is done within templated bash scripts as
possible (this was/is already a goal of oooq)
  2. Track which templates are used for build paths e.g. for a
"minimal" deployment the following shell scripts are created and
called:
  - undercloud-install.sh
  - undercloud-post-instal.sh
  - overcloud-deploy.sh
  - overcloud-deploy-post.sh
  - overcloud-validate.sh
  3. Update existing/audit new templates to follow some style
guidelines[3] (vanilla example as well as an actual script output
linked in this paste).

After a build has finished, either by way of CI or locally, the
tripleo-collect-logs[4] role can be used to collect logs from the
undercloud, convert the shell scripts into rST files, use Sphinx[5] to
build a documentation, and (optionally) publish the results to an
artifacts server.

There is a PoC job[6] up that is successfully building and publishing
docs created to combine and monitor work done in relevant
tripleo-quickstart[7] and ansible-role-tripleo-collect-logs[8]
patches. To get a better idea of what the end product from Sphinx
looks like, please look here[9]. Note that the job is using a playbook
which is calling external roles for most of the deployment (which
doesn't contain all the possible templated bash script conversions).
For a more complete version, download the output from a local run I
completed yesterday[10] -- just untar it and open the index.html file
located at its root level.

Up to this point, my goal has been to get as much coverage of what our
CI does in a minimal job[10] building documentation. With this shaping
up quickly, I would like to open discussion around what I believe will
be the most complicated part of expanding documentation coverage -
work being done via ansible instead of within templated bash scripts.
For example, the undercloud role in TripleO-Quickstart adjusts an
Ironic config and restarts the service[11] outside of the templated
bash scripts. I can see a few solutions:

  1. Convert work done in ansible to templated bash scripts
  - Requires a fair amount of initial leg work
  - Sections of the workflow very well /should/ be ansible for
various reasons
  2. Write static documentation for things not templated and insert it
inti the correct section of docs
  - Propensity to very easily become out-of-date
  3. Write templated bash that mimics what ansible is doing and let
the automation consume these unused 'scripts'
  - Same issue as option 2 -- both allow for easy divergence
between what is done in automation and what we are presenting folks
with inside of the docs

Would folks chime in on the above? Is there a simple solution that I overlooked?

[1] - https://review.gerrithub.io/#/c/261218/
[2] - 
https://github.com/openstack/tripleo-incubator/blob/master/scripts/extract-docs.awk
[3] - https://paste.fedoraproject.org/408991/
[4] - https://github.com/redhat-openstack/ansible-role-tripleo-collect-logs
[5] - http://www.sphinx-doc.org/en/stable/
[6] - 
https://ci.centos.org/job/poc-hrybacki-tripleo-quickstart-roles-gate-mitaka-doc-generator/
full-minimal/
[7] - https://review.openstack.org/#/c/347592/
[8] - https://review.gerrithub.io/#/c/286349/
[9] - 
https://ci.centos.org/artifacts/rdo/jenkins-poc-hrybacki-tripleo-quickstart-roles-gate-mitaka-doc-generator-44/docs/build/
[10] - 
https://drive.google.com/a/redhat.com/file/d/0B9Alqh5AS1vpS1djWm9zYmZhNHM/view?usp=sharing
[11] - 
https://ci.centos.org/view/rdo/view/tripleo-gate/job/tripleo-quickstart-gate-mitaka-delorean-
[12] - 
https://github.com/openstack/tripleo-quickstart/blob/master/roles/tripleo/undercloud/tasks/main.yml#L9-L21


/R

Harry Rybacki

__
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] [E] [TripleO] CI Driven Documentation: Design Discussion

[Harry Rybacki]

On Tue, Jul 19, 2016 at 1:44 PM, Gordon, Kent
<kent.gor...@verizonwireless.com> wrote:
> How do I access  item [1]?
>
> [1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
> rdo-ci-cd.etherpad.corp.redhat.com  does not have a valid DNS entry.
>
Good catch. In short you can't. Our team is in the transition to
upstream focus -- will need to move our minutes to a new etherpad.
Relevant snippet below:

Demo: Harry Rybacki, creating tripleo-doc from CI
  Trown's PoC Review (redhat-openstack/tripleo-quickstart):
https://review.gerrithub.io/#/c/261218/
  Tracking card:
https://trello.com/c/whHpxvkO/269-investigate-ci-automated-documentation
  Prototyping role: https://github.com/HarryRybacki/tripleo-documentor

>
> Kent S. Gordon
> Verizon Wireless
>
> -Original Message-
> From: Harry Rybacki [mailto:hryba...@redhat.com]
> Sent: Tuesday, July 19, 2016 10:34 AM
> To: openstack-dev@lists.openstack.org
> Subject: [E] [openstack-dev] [TripleO] CI Driven Documentation: Design 
> Discussion
>
> All,
>
> During today's rdo-ci scrum[1], I briefed the team on PoC work that will 
> bring trown's old PoC[2] review inline with the current state of affairs of 
> TripleO-Quickstart (OOOQS) and related ansible roles used heavily in upstream 
> CI[3].
>
> To summarize, our goal is to leverage the power Sphinx[4] and templated bash 
> scripts[5] generated during jobs to decrease the overhead of maintaining 
> TripleO docs. Additionally, we aim to provide more build specific e.g., this 
> is how you would do a minimal deployment on [centos|rhelx|...], documentation 
> with as much automation as possible.
>
> In trown's initial PoC[2] conditionals are used to inside of the templates to 
> allow for selective addition of RST blocks and removal of non-useful chunks 
> of code (CI specific) for documentation[6]. The resulting docs are quite 
> aesthetically pleasing[7]. The multitude of roles which are now consumed for 
> any given build and used by OOOQS complicates things a bit.
>
> Regardless of how we move forward, roles, such as tripleo-undercloud-post[8], 
> will have to update their relevant bash templates[9].
>
> Two ideas were discussed:
>
> 1. Minimally modify the templates to have inline comments which would equate 
> to "steps" which can then be followed to reproduce a build.
>   - This would require the least work bringing roles up to speed but would in 
> turn lose the ability to use much of RST's power.
>   - This would make automated documentation incredibly easy -- just pull 
> relevant bash scripts off of the LastSuccessfullBuild from the artifacts 
> server for a given job every XX hours and
>
> 2. Modify the templates to conditionally add snippets as noted in the 
> original PoC[6].
>   - This would provide the ability to have highly customizable documentation 
> and all of the givens from using RST
>   - This would require executing roles twice (once for the build and once for 
> producing the documentation version of the scripts used during the build).
> - Other problem areas could result from this. For example, vars set 
> dynamically during a roles execution during the initial build might not be 
> available (or different) during the second execution.
>
> While I think that we should strive to have the flexibility RST provides us, 
> the MVP (option 1) already gives us (and our users) a huge leg up already 
> with continually up-to-date documentation that has been tested (and built by) 
> our CI.
>
> Any thoughts on the above would be greatly appreciated  -- perhaps there is a 
> clean way to generate two sets of templated bash in tandem and we can just 
> pull the documentation version off of the artifacts server?
>
> [1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
> [2] - https://review.gerrithub.io/#/c/261218/
> [3] - https://github.com/HarryRybacki/tripleo-documentor
> [4] - http://www.sphinx-doc.org/en/stable/
> [5] - 
> https://github.com/openstack/tripleo-quickstart/tree/master/roles/tripleo/undercloud/templates
> [6] - 
> https://review.gerrithub.io/#/c/261218/1/playbooks/roles/images/undercloud/templates/undercloud-run
> [7] - https://trown.fedorapeople.org/rdodocgen/
> [8] - https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post
> [9] - 
> https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post/blob/master/templates/undercloud-install-post.sh.j2
>
> Thanks, all!
>
>
> /R
>
> Harry Rybacki
> Software Engineer, Red Hat
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

[openstack-dev] [TripleO] CI Driven Documentation: Design Discussion

[Harry Rybacki]

All,

During today's rdo-ci scrum[1], I briefed the team on PoC work that
will bring trown's old PoC[2] review inline with the current state of
affairs of TripleO-Quickstart (OOOQS) and related ansible roles used
heavily in upstream CI[3].

To summarize, our goal is to leverage the power Sphinx[4] and
templated bash scripts[5] generated during jobs to decrease the
overhead of maintaining TripleO docs. Additionally, we aim to provide
more build specific e.g., this is how you would do a minimal
deployment on [centos|rhelx|...], documentation with as much
automation as possible.

In trown's initial PoC[2] conditionals are used to inside of the
templates to allow for selective addition of RST blocks and removal of
non-useful chunks of code (CI specific) for documentation[6]. The
resulting docs are quite aesthetically pleasing[7]. The multitude of
roles which are
now consumed for any given build and used by OOOQS complicates things a
bit.

Regardless of how we move forward, roles, such as
tripleo-undercloud-post[8], will have to update their relevant bash
templates[9].

Two ideas were discussed:

1. Minimally modify the templates to have inline comments which would
equate to "steps" which can then be followed to reproduce a build.
  - This would require the least work bringing roles up to speed but
would in turn lose the ability to use much of RST's power.
  - This would make automated documentation incredibly easy -- just
pull relevant bash scripts off of the LastSuccessfullBuild from the
artifacts server for a given job every XX hours and

2. Modify the templates to conditionally add snippets as noted in the
original PoC[6].
  - This would provide the ability to have highly customizable
documentation and all of the givens from using RST
  - This would require executing roles twice (once for the build and
once for producing the documentation version of the scripts used
during the build).
- Other problem areas could result from this. For example, vars
set dynamically during a roles execution during the initial build
might not be available (or different) during the second execution.

While I think that we should strive to have the flexibility RST
provides us, the MVP (option 1) already gives us (and our users) a
huge leg up already with continually up-to-date documentation that has
been tested (and built by) our CI.

Any thoughts on the above would be greatly appreciated  -- perhaps
there is a clean way to generate two sets of templated bash in tandem
and we can just pull the documentation version off of the artifacts
server?

[1] - http://rdo-ci-cd.etherpad.corp.redhat.com/weekly-scrum
[2] - https://review.gerrithub.io/#/c/261218/
[3] - https://github.com/HarryRybacki/tripleo-documentor
[4] - http://www.sphinx-doc.org/en/stable/
[5] - 
https://github.com/openstack/tripleo-quickstart/tree/master/roles/tripleo/undercloud/templates
[6] - 
https://review.gerrithub.io/#/c/261218/1/playbooks/roles/images/undercloud/templates/undercloud-run
[7] - https://trown.fedorapeople.org/rdodocgen/
[8] - https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post
[9] - 
https://github.com/redhat-openstack/ansible-role-tripleo-undercloud-post/blob/master/templates/undercloud-install-post.sh.j2

Thanks, all!


/R

Harry Rybacki
Software Engineer, Red Hat

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