Re: [openstack-dev] [neutron] heads up to long time ovs users...

[Akihiro Motoki]

The important point of this notice is that packet drops will happen when
switching of_interface option from ovs-ofctl (which was the default value
in the old releases) to native (which is the current default ).

Once neutron drops the option, if deployers use the legacy value
"ovs-ofctl", they will hit some packet losses when upgrading neutron to
Stein.

We have no actual data on large deployments so far and don't know how this
change impacts real deployments.

Your feedback would be really appreciated.

Best regards,
Akihiro Motoki (irc: amotoki)

2018年9月21日(金) 10:37 IWAMOTO Toshihiro :

> The neutron team is finally removing the ovs-ofctl option.
>
> https://review.openstack.org/#/c/599496/
>
> The ovs-ofctl of_interface option wasn't default since Newton and was
> deprecated in Pike.
>
> So, if you are a long time ovs-agent user and upgrading to a new
> coming release, you must switch from the ovs-ofctl implementation to
> the native implementation and are affected by the following issue.
>
> https://bugs.launchpad.net/neutron/+bug/1793354
>
> The loss of communication mentioned in this bug report would be a few
> seconds to a few minutes depending on the number of network
> interfaces.  It happens when an ovs-agent is restarted with the new
> of_interface (so only once during the upgrade) and persists until the
> network interfaces are set up.
>
> Please speak up if you cannot tolerate this during upgrades.
>
> IIUC, this bug is unfixable and I'd like to move forward as
> maintaining two of_interface implementation is a burden for the
> neutron team.
>
> --
> IWAMOTO Toshihiro
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [goals][python3][karbor] Please process thepython3-first patches

[Nguyễn Trí Hải]

Hi,

Thanks for reviewing them. Only two patches need to review:
https://review.openstack.org/#/c/594827/
https://review.openstack.org/#/c/594815/ (Depends-On:
https://review.openstack.org/#/c/596289/)


On Fri, Sep 21, 2018 at 10:33 PM jiaopengju 
wrote:

> Thanks for pushing these patches, we will review and merge them ASAP.
>
>
>  原始邮件
> *发件人:* Nguyễn Trí Hải
> *收件人:* OpenStack Development Mailing List (not for usage questions)<
> openstack-dev@lists.openstack.org>
> *抄送:* jiaopengju
> *发送时间:* 2018年9月21日(周五) 20:36
> *主题:* [openstack-dev][goals][python3][karbor] Please process
> thepython3-first patches
>
> Hi Karbor team and Karbor PTL,
>
> As part of the "Run under Python 3 by default" community goal [1] for
> OpenStack in the Stein cycle, I proposed the patches related to
> python3-first goal very long time ago. However, there is no activity for
> those patches.
>
> Please receive those patches and review them. Those patches belong to:
> - openstack/karbor
> - openstack/karbor-dashboard
> - openstack/python-karborclient
>
> Here they are:
> https://review.openstack.org/#/q/project:%255E.*karbor.*+topic:python3-first+status:open
>
> [1] https://governance.openstack.org/tc/goals/stein/python3-first.html
>
> --
>
> Nguyen Tri Hai / Ph.D. Student
>
> ANDA Lab., Soongsil Univ., Seoul, South Korea
>
> 
> 
> *[image:
> http://link.springer.com/chapter/10.1007/978-3-319-26135-5_4]
> * 
>


-- 

Nguyen Tri Hai / Ph.D. Student

ANDA Lab., Soongsil Univ., Seoul, South Korea



*[image:
http://link.springer.com/chapter/10.1007/978-3-319-26135-5_4]
* 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Project Navigator

[Michael Johnson]

Jimmy,

Yes, the tags are correct in
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
but are not correct in Project Navigator.

I am asking where is the git repository with the Project Navigator
code that creates the "Project Details" section?
I am looking for the Project Navigator source code.

Michael
On Fri, Sep 21, 2018 at 4:22 PM Jimmy McArthur  wrote:
>
> The TC tags are indeed in a different repo: 
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> Let me know if this makes sense.
>
> Jimmy
>
> Michael Johnson September 21, 2018 at 4:32 PM
> Matt,
>
> I'm a bit confused by your response. I'm not looking for a definition
> of the tags, that is very clear.
>
> I'm looking for the source code backing the page that is rendering
> which tags a project has.
> This code appears to be broken and not rendering the tags correctly
> and I wanted to see if I could fix it.
>
> Michael
>
> __
> 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
> Matt Riedemann September 21, 2018 at 3:04 PM
>
>
> Those are down in the project details section of the page, look to the right 
> and there is a 'tag details' column. The tags are descriptive and link to the 
> details on each tag.
>
> Michael Johnson September 21, 2018 at 1:11 PM
> Thank you Jimmy for making this available for updates.
>
> I was unable to find the code backing the project tags section of the
> Project Navigator pages.
> Our page is missing some upgrade tags and is showing duplicate "Stable
> branch policy" tags.
>
> https://www.openstack.org/software/releases/rocky/components/octavia
>
> Is there a different repository for the tags code?
>
> Thanks,
> Michael
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Jimmy Mcarthur September 21, 2018 at 8:59 AM
> Following up on my (very brief) talk from the PTG, you can now propose 
> changes to the Project Navigator by going to 
> https://git.openstack.org/cgit/openstack/openstack-map repository
>
> Once your patch is merged, the page should reflect the changes straight away.
>
> Cheers,
> Jimmy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] Automating role generation

[Janki Chhatbar]

Hi All

As per the discussion at PTG, I have filed a BP [1]. I will push a spec
sometime around mid-October.

[1].
https://blueprints.launchpad.net/tripleo/+spec/automatic-role-generation

On Tue, Sep 4, 2018 at 2:56 PM Steven Hardy  wrote:

> On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský  wrote:
> > On 4.9.2018 08:13, Janki Chhatbar wrote:
> >>
> >> Hi
> >>
> >> I am looking to automate role file generation in TripleO. The idea is
> >> basically for an operator to create a simple yaml file (operator.yaml,
> >> say)
> >> listing services that are needed and then TripleO to generate
> >> Controller.yaml enabling only those services that are mentioned.
> >>
> >> For example:
> >> operator.yaml
> >> services:
> >>  Glance
> >>  OpenDaylight
> >>  Neutron ovs agent
> >
> >
> > I'm not sure it's worth introducing a new file format as such, if the
> > purpose is essentially to expand e.g. "Glance" into
> > "OS::TripleO::Services::GlanceApi" and
> > "OS::TripleO::Services::GlanceRegistry"? It would be another layer of
> > indirection (additional mental work for the operator who wants to
> understand
> > how things work), while the layer doesn't make too much difference in
> > preparation of the role. At least that's my subjective view.
> >
> >>
> >> Then TripleO should
> >> 1. Fail because ODL and OVS agent are either-or services
> >
> >
> > +1 i think having something like this would be useful.
> >
> >> 2. After operator.yaml is modified to remove Neutron ovs agent, it
> should
> >> generate Controller.yaml with below content
> >>
> >> ServicesDefault:
> >> - OS::TripleO::Services::GlanceApi
> >> - OS::TripleO::Services::GlanceRegistry
> >> - OS::TripleO::Services::OpenDaylightApi
> >> - OS::TripleO::Services::OpenDaylightOvs
> >>
> >> Currently, operator has to manually edit the role file (specially when
> >> deployed with ODL) and I have seen many instances of failing deployment
> >> due
> >> to variations of OVS, OVN and ODL services enabled when they are
> actually
> >> exclusive.
> >
> >
> > Having validations on the service list would be helpful IMO, e.g. "these
> > services must not be in one deployment together", "these services must
> not
> > be in one role together", "these services must be together", "we
> recommend
> > this service to be in every role" (i'm thinking TripleOPackages, Ntp,
> ...)
> > etc. But as mentioned above, i think it would be better if we worked
> > directly with the "OS::TripleO::Services..." values rather than a new
> layer
> > of proxy-values.
> >
> > Additional random related thoughts:
> >
> > * Operator should still be able to disobey what the validation suggests,
> if
> > they decide so.
> >
> > * Would be nice to have the info about particular services (e.g what
> can't
> > be together) specified declaratively somewhere (TripleO's favorite thing
> in
> > the world -- YAML?).
> >
> > * We could start with just one type of validation, e.g. the mutual
> > exclusivity rule for ODL vs. OVS, but would be nice to have the solution
> > easily expandable for new rule types.
>
> This is similar to how the UI uses the capabilities-map.yaml, so
> perhaps we can use that as the place to describe service dependencies
> and conflicts?
>
>
> https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml
>
> Currently this isn't used at all for the CLI, but I can imagine some
> kind of wizard interface being useful, e.g you could say enable
> "Glance" group and it'd automatically pull in all glance dependencies?
>
> Another thing to mention is this doesn't necessarily have to generate
> a new role (although it could), the *Services parameter for existing
> roles can be overridden, so it might be simpler to generate an
> environment file instead.
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Thanking you

Janki Chhatbar
OpenStack | Docker | SDN
simplyexplainedblog.wordpress.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] OpenStack Project Navigator

[Jimmy McArthur]

The TC tags are indeed in a different repo: 
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml


Let me know if this makes sense.

Jimmy


Michael Johnson 
September 21, 2018 at 4:32 PM
Matt,

I'm a bit confused by your response. I'm not looking for a definition
of the tags, that is very clear.

I'm looking for the source code backing the page that is rendering
which tags a project has.
This code appears to be broken and not rendering the tags correctly
and I wanted to see if I could fix it.

Michael

__
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
Matt Riedemann 
September 21, 2018 at 3:04 PM


Those are down in the project details section of the page, look to the 
right and there is a 'tag details' column. The tags are descriptive 
and link to the details on each tag.


Michael Johnson 
September 21, 2018 at 1:11 PM
Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?

Thanks,
Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur 
September 21, 2018 at 8:59 AM
Following up on my (very brief) talk from the PTG, you can now propose 
changes to the Project Navigator by going to 
https://git.openstack.org/cgit/openstack/openstack-map repository


Once your patch is merged, the page should reflect the changes 
straight away.


Cheers,
Jimmy

__ 


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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack-sigs] Capturing Feedback/Input

[Doug Hellmann]

Melvin Hillsman  writes:

> On Fri, Sep 21, 2018 at 11:16 AM Doug Hellmann 
> wrote:
>
>> Maybe we're overthinking the organization on this. What is special about
>> the items that would be on this list compared to items opened directly
>> against projects?
>>
>
> Yeah unfortunately we do have a tendency to overthink/complicate things.
> Not saying Storyboard is the right tool but suggested rather than having
> something extra to maintain was what I understood. There are at least 3
> things that were to be addressed:
>
> - single pane so folks know where to provide/see updates
> - it is not a catchall/dumpsite
>   - something still needs to be flushed out/prioritized (Public Cloud WG's
> missing features spreadsheet for example)
> - not specific to a single project (i thought this was a given since there
> is already a process/workflow for single project)
>
> I could very well be wrong so I am open to be corrected. From my
> perspective the idea in the room was to not circumvent anything internal
> but rather make it easy for external viewers, passerbys, etc. When feedback
> is gathered from Ops Meetup, OpenStack Days, Local meetups/events, we
> discussed putting that here as well.

Those are all good points. Sorry for making you rehash stuff that was
already discussed.

So I guess the idea is to have a place where several groups can track
their own backlogs, but then a prioritized list can be created from
those separate backlogs?

In the Storyboard data model, that sounds like separate projects for
each SIG or WG, and then 1 worklist that they all manually update with
their priority items. I say "manually" because if we just combine all of
the backlogs we don't have any good way to order the items and select
the top N.

Doug

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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-29 Update

[Matt Riedemann]

On 9/21/2018 3:53 PM, Matt Riedemann wrote:
* The reference docs I wrote for writing upgrade checks is published now 
[4]. As I've been answering some questions in storyboard and IRC, it's 
obvious that I need to add some FAQs into those docs because I've taken 
some of this for granted on how it works in nova, so I'll push a docs 
change for some of that as well and link it back into the story.


https://review.openstack.org/#/c/604486/ for anyone that thinks I missed 
something.


--

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] OpenStack Project Navigator

[Michael Johnson]

Matt,

I'm a bit confused by your response. I'm not looking for a definition
of the tags, that is very clear.

I'm looking for the source code backing the page that is rendering
which tags a project has.
This code appears to be broken and not rendering the tags correctly
and I wanted to see if I could fix it.

Michael

On Fri, Sep 21, 2018 at 1:05 PM Matt Riedemann  wrote:
>
> On 9/21/2018 1:11 PM, Michael Johnson wrote:
> > Thank you Jimmy for making this available for updates.
> >
> > I was unable to find the code backing the project tags section of the
> > Project Navigator pages.
> > Our page is missing some upgrade tags and is showing duplicate "Stable
> > branch policy" tags.
> >
> > https://www.openstack.org/software/releases/rocky/components/octavia
> >
> > Is there a different repository for the tags code?
>
> Those are down in the project details section of the page, look to the
> right and there is a 'tag details' column. The tags are descriptive and
> link to the details on each tag.
>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-29 Update

[Ben Nemec]

On 09/21/2018 03:53 PM, Matt Riedemann wrote:

Updates for this week:

* As bnemec noted in the last update [1], he's making some progress with 
the oslo.upgradecheck library. He's retrofitting the nova-status upgrade 
check code to use the library and has a patch up for designate to use it.


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


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




* The reference docs I wrote for writing upgrade checks is published now 
[4]. As I've been answering some questions in storyboard and IRC, it's 
obvious that I need to add some FAQs into those docs because I've taken 
some of this for granted on how it works in nova, so I'll push a docs 
change for some of that as well and link it back into the story.


As always, feel free to reach out to me with any questions or issues you 
might have with completing this goal (or just getting started).


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134972.html 


[2] https://review.openstack.org/#/c/603465/
[3] https://review.openstack.org/#/c/604430/
[4] https://docs.openstack.org/nova/latest/reference/upgrade-checks.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

[openstack-dev] [goals][upgrade-checkers] Week R-29 Update

[Matt Riedemann]

Updates for this week:

* As bnemec noted in the last update [1], he's making some progress with 
the oslo.upgradecheck library. He's retrofitting the nova-status upgrade 
check code to use the library and has a patch up for designate to use it.


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


* The reference docs I wrote for writing upgrade checks is published now 
[4]. As I've been answering some questions in storyboard and IRC, it's 
obvious that I need to add some FAQs into those docs because I've taken 
some of this for granted on how it works in nova, so I'll push a docs 
change for some of that as well and link it back into the story.


As always, feel free to reach out to me with any questions or issues you 
might have with completing this goal (or just getting started).


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134972.html

[2] https://review.openstack.org/#/c/603465/
[3] https://review.openstack.org/#/c/604430/
[4] https://docs.openstack.org/nova/latest/reference/upgrade-checks.html

--

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] OpenStack Project Navigator

[Matt Riedemann]

On 9/21/2018 1:11 PM, Michael Johnson wrote:

Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?


Those are down in the project details section of the page, look to the 
right and there is a 'tag details' column. The tags are descriptive and 
link to the details on each tag.


--

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] [Openstack-sigs] Capturing Feedback/Input

[Jeremy Stanley]

On 2018-09-21 12:55:09 -0500 (-0500), Melvin Hillsman wrote:
[...]
> Yeah unfortunately we do have a tendency to overthink/complicate
> things. Not saying Storyboard is the right tool but suggested
> rather than having something extra to maintain was what I
> understood. There are at least 3 things that were to be addressed:
> 
> - single pane so folks know where to provide/see updates

Not all OpenStack projects use the same task trackers currently and
there's no guarantee that they ever will, so this is a best effort
only. Odds are you may wind up duplicating some information also
present in the Nova project on Launchpad, the Tripleo project on
Trello and the Foobly project on Bugzilla (I made this last one up,
in case it's not obvious).

> - it is not a catchall/dumpsite

If it looks generic enough, it will become that unless there are
people actively devoted to triaging and pruning submissions to
curate them... a tedious and thankless long-term commitment, to be
sure.

> - something still needs to be flushed out/prioritized (Public
> Cloud WG's missing features spreadsheet for example)

This is definitely a good source of input, but still needs someone
to determine which various projects/services the tasks for them get
slotted into and then help prioritizing and managing spec
submissions on a per-team basis.

> - not specific to a single project (i thought this was a given
> since there is already a process/workflow for single project)

The way to do that on storyboard.openstack.org is to give it a
project of its own. Basically just couple it to a new, empty Git
repository and then the people doing these tasks still have the
option of also putting that repository to some use later (for
example, to house their workflow documentation).

> I could very well be wrong so I am open to be corrected. From my
> perspective the idea in the room was to not circumvent anything
> internal but rather make it easy for external viewers, passerbys,
> etc. When feedback is gathered from Ops Meetup, OpenStack Days,
> Local meetups/events, we discussed putting that here as well.

It seems a fine plan, just keep in mind that documenting and
publishing feedback doesn't magically translate into developers
acting on any of it (and this is far from the first time it's been
attempted).
-- 
Jeremy Stanley


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

[openstack-dev] [oslo] Storyboard test import done

[Ben Nemec]

Hi,

The test import of the Oslo projects is done (thanks Kendall!), so 
everyone from the Oslo team please take a look around and provide 
feedback on it. If we do the migration this cycle we want to do it 
earlier rather than later so we aren't dealing with migration fallout 
while trying to stabilize things at the end.


https://storyboard-dev.openstack.org/#!/project_group/oslo

Thanks.

-Ben

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

Re: [openstack-dev] OpenStack Project Navigator

[Michael Johnson]

Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?

Thanks,
Michael
On Fri, Sep 21, 2018 at 6:59 AM Jimmy Mcarthur  wrote:
>
> Following up on my (very brief) talk from the PTG, you can now propose
> changes to the Project Navigator by going to
> https://git.openstack.org/cgit/openstack/openstack-map repository
>
> Once your patch is merged, the page should reflect the changes straight
> away.
>
> Cheers,
> Jimmy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [placement] update 18-38

[Chris Dent]

HTML: https://anticdent.org/placement-update-18-38.html

Here's a placement update. Last week there wasn't one, because of
the PTG. There will be some references to various PTG stuff within
but since we haven't fully resolved what the priorities will be, the
discussion here will be somewhat unfocused.

# Most Important

Two main important things to do:

As is typical (at least in my experience), last week we discussed
and planned more work than anyone could be reasonably be expected to
accomplish in a few years, let alone a single cycle, so there will
be an inevitable winnowing and prioritizing of ideas and specs over
the next few days. There's some discussion of priorities on an
[etherpad](https://etherpad.openstack.org/p/nova-ptg-stein-priorities),
but the details of which to do and how to implement are not fully
resolved. Reviewing the specs (below) ought to help that.

We're still working towards a complete set of integration and
upgrade tests for the new placement repo. The unit and functional
tests are happy and nicely fast, but they aren't covering important
things like upgrading from placement-in-nova to just-placement, nor
do they do any live testing with a full devstack. Work is in
progress on all of this, see the "extraction" section below.

# What's Changed

We had a meeting to come up with a plan for migrating placement to
an independent project. Mel wrote up a [summary
email](http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html)
with the steps.

# Questions and Links

(I've added "links" to this section because since there's a good one
this week, why not?)

* There was a demo at the PTG for the minimum bandwith work. That's
  been written up in a [blog
  post](https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html).

* Yesterday, belmoreira showed up in 
[#openstack-placement](http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-09-20.log.html#t2018-09-20T14:11:59)
  with some issues with expected resource providers not showing up
  in allocation candidates. This was traced back to `max_unit` for
  `VCPU` being locked at == `total` and hardware which had had SMT
  turned off now reporting fewer CPUs, thus being unable to accept
  existing large flavors. Discussion ensued about ways to
  potentially make `max_unit` more manageable by operators. The
  existing constraint is there for a reason (discussed in IRC) but
  that reason is not universally agreed.

There are two issues with this: The "reason" is not universally
agreed and we didn't resolve that. Also, management of
`max_unit` of any inventory gets more complicated in a world of
complex NUMA topologies.

# Bugs

* Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 17.
  No change (in number) from last time.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 10. Same as
  last time.

# Specs

New (or newly discovered) ones are at the end. Specs which have
merged have been removed.  As stated above: We still haven't
solidified priorities, so some specs may merge as "low priority".

* 
  Account for host agg allocation ratio in placement
  (Still in rocky/)

* 
  Add subtree filter for GET /resource_providers

* 
  Resource provider - request group mapping in allocation candidate

* 
  VMware: place instances on resource pool
  (still in rocky/)

* 
  Standardize CPU resource tracking

* 
  Allow overcommit of dedicated CPU
  (Has an alternative which changes allocations to a float)

* 
  List resource providers having inventory

* 
  Bi-directional enforcement of traits

* 
  allow transferring ownership of instance

* 
  Modelling passthrough devices for report to placement

* 
  Propose counting quota usage from placement and API database
  (A bit out of date but may be worth resurrecting)

* 
  Spec: allocation candidates in tree

* 
  [WIP] generic device discovery policy

* 
  Nova Cyborg interaction specification.

* 
  supporting virtual NVDIMM devices

* 
  Spec: Support filtering by forbidden aggregate

* 
  Proposes NUMA topology with RPs

* 
  Support initial allocation ratios
  (There are at least two pending allocation ratio handling cleanup
  specs. It's not clear from 

Re: [openstack-dev] [Openstack-sigs] Capturing Feedback/Input

[Melvin Hillsman]

On Fri, Sep 21, 2018 at 11:16 AM Doug Hellmann 
wrote:

> Excerpts from Melvin Hillsman's message of 2018-09-21 10:18:26 -0500:
> > On Fri, Sep 21, 2018 at 9:41 AM Doug Hellmann 
> wrote:
> >
> > > Excerpts from Melvin Hillsman's message of 2018-09-20 17:30:32 -0500:
> > > > Hey everyone,
> > > >
> > > > During the TC meeting at the PTG we discussed the ideal way to
> capture
> > > > user-centric feedback; particular from our various groups like SIGs,
> WGs,
> > > > etc.
> > > >
> > > > Options that were mentioned ranged from a wiki page to a standalone
> > > > solution like discourse.
> > > >
> > > > While there is no perfect solution it was determined that Storyboard
> > > could
> > > > facilitate this. It would play out where there is a project group
> > > > openstack-uc? and each of the SIGs, WGs, etc would have a project
> under
> > > > this group; if I am wrong someone else in the room correct me.
> > > >
> > > > The entire point is a first step (maybe final) in centralizing
> > > user-centric
> > > > feedback that does not require any extra overhead be it cost, time,
> or
> > > > otherwise. Just kicking off a discussion so others have a chance to
> chime
> > > > in before anyone pulls the plug or pushes the button on anything and
> we
> > > > settle as a community on what makes sense.
> > > >
> > >
> > > I like the idea of tracking the information in storyboard. That
> > > said, one of the main purposes of creating SIGs was to separate
> > > those groups from the appearance that they were "managed" by the
> > > TC or UC. So, rather than creating a UC-focused project group, if
> > > we need a single project group at all, I would rather we call it
> > > "SIGs" or something similar.
> > >
> >
> > What you bring up re appearances makes sense definitely. Maybe we call it
> > openstack-feedback since the purpose is focused on that and I actually
> > looked at -uc as user-centric rather than user-committee; but
> appearances :)
>
> Feedback implies that SIGs aren't engaged in creating OpenStack, though,
> and I think that's the perception we're trying to change.
>
> > I think limiting it to SIGs will well, limit it to SIGs, and again could
> > appear to be specific to those groups rather than for example the Public
> > Cloud WG or Financial Team.
>
> OK, I thought those groups were SIGs.
>
> Maybe we're overthinking the organization on this. What is special about
> the items that would be on this list compared to items opened directly
> against projects?
>

Yeah unfortunately we do have a tendency to overthink/complicate things.
Not saying Storyboard is the right tool but suggested rather than having
something extra to maintain was what I understood. There are at least 3
things that were to be addressed:

- single pane so folks know where to provide/see updates
- it is not a catchall/dumpsite
  - something still needs to be flushed out/prioritized (Public Cloud WG's
missing features spreadsheet for example)
- not specific to a single project (i thought this was a given since there
is already a process/workflow for single project)

I could very well be wrong so I am open to be corrected. From my
perspective the idea in the room was to not circumvent anything internal
but rather make it easy for external viewers, passerbys, etc. When feedback
is gathered from Ops Meetup, OpenStack Days, Local meetups/events, we
discussed putting that here as well.


>
> Doug
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] Mid-Cycle Planning ...

[Jay S Bryant]

Team,

As we discussed at the PTG I have started an etherpad to do some 
planning for a possible Cinder Mid-cycle meeting.  Please check out the 
etherpad [1] and leave your input.


Thanks!

Jay

[1] https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning


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

[openstack-dev] [manila] User Survey Results

[Tom Barron]

More PTG follow up :)

The foundation shared results of the User Survey for Manila, where 
users were asked "Which OpenStack Shared File Systems (Manila) 
driver(s) are you using?"


I've uploaded these in a Google Sheets document here [1].  The first 
tab has the raw results as passed to me by the Foundation, the second 
tabulates these, and the third summarizes with a bar chart.


Do let me know if you see any errors :)

-- Tom Barron (tbarron)

[1] 
https://docs.google.com/spreadsheets/d/1J83vnnuuADVwACeJq1g8snxMRM5VAfTbBD6svVeH4yg/edit?usp=sharing



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

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

[Jay S Bryant]

On 9/21/2018 12:06 PM, John Griffith wrote:




On Fri, Sep 21, 2018 at 11:00 AM Sean McGinnis > wrote:


On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote:
> All,
>
> In the last year we have had some changes to Core team
participation.  This
> was a topic of discussion at the PTG in Denver last week.  Based
on that
> discussion I have reached out to John Griffith and Winston D
(Huang Zhiteng)
> and asked if they felt they could continue to be a part of the
Core Team.
> Both agreed that it was time to relinquish their titles.
>
> So, I am proposing to remove John Griffith and Winston D from
Cinder Core.
> If I hear no concerns with this plan in the next week I will
remove them.
>
> It is hard to remove people who have been so instrumental to the
early days
> of Cinder.  Your past contributions are greatly appreciated and
the team
> would be happy to have you back if circumstances every change.
>
> Sincerely,
> Jay Bryant
>

Really sad to see Winston go as he's been a long time member, but
I think over
the last several releases it's been obvious he's had other
priorities to
compete with. It would be great if that were to change some day.
He's made a
lot of great contributions to Cinder over the years.

I'm a little reluctant to make any changes with John though. We've
spoken
briefly. He definitely is off to other things now, but with how
deeply he has
been involved up until recently with things like the multiattach
implementation, replication, and other significant things, I would
much rather
have him around but less active than completely gone. Having a few
good reviews
is worth a lot.



I would propose we hold off on changing John's status for at least
a cycle. He
has indicated to me he would be willing to devote a little time to
still doing
reviews as his time allows, and I would hate to lose out on his
expertise on
changes to some things. Maybe we can give it a little more time
and see if his
other demands keep him too busy to participate and reevaluate later?

Sean

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hey Everyone,

Now that I'm settling in on my other things I think I can still 
contribute a bit to Cinder on my own time.  I'm still pretty fond of 
OpenStack and Cinder so would love the opportunity to give it a cycle 
to see if I can balance things and still be helpful.


Thanks,
John

Sean,

Thank you for your input on this and for following up with John.

John,

Glad that you are settling into your new position and think some time 
will free up for Cinder again.  I would be happy to have your continued 
input.


I am removing you from consideration for removal.

Jay
(jungleboyj)

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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-30 update

[Ben Nemec]

On 09/15/2018 10:30 AM, Matt Riedemann wrote:

Just a couple of updates this week.

* I have assigned PTLs (for projects that have PTLs [1]) to their 
respective tasks in StoryBoard [2]. If someone else on your team is 
planning on working on the pre-upgrade check goal then please just 
reassign ownership of the task.


* I have started going through some project release notes looking for 
upgrade impacts and leaving notes in the task assigned per project. 
There were some questions at the PTG about what some projects could add 
for pre-upgrade checks so check your task to see if I've left any 
thoughts. I have not gone through all projects yet.


* Ben Nemec has extracted the common upgrade check CLI framework into a 
library [3] (thanks Ben!) and is working on getting that imported into 
Gerrit. It would be great if projects that start working on the goal can 
try using that library and provide feedback.


The library has been imported into Gerrit, so people can start consuming 
it from there. Note that there are quite a few pending patches to it 
already that we can't merge until the governance change goes in and I 
can populate the reviewer list.


I also pushed a patch to demonstrate how it would be integrated with the 
existing Nova code[1] and a patch to Designate to demonstrate how a 
completely new set of checks might be implemented[2]. The Designate 
check required some changes in the library config handling, but I think 
the patches proposed should work well now. I need to write some unit 
tests for it, but in my manual testing it has behaved as expected.


As Matt said, any feedback is welcome. I suggest working off the end of 
the series that includes [3] as there are some significant api changes 
there.


-Ben

1: https://review.openstack.org/#/c/603499
2: https://review.openstack.org/#/c/604430
3: https://review.openstack.org/#/c/604422/

__
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] Are we ready to put stable/ocata into extended maintenance mode?

[Sean McGinnis]

On Fri, Sep 21, 2018 at 08:26:41AM -0600, Doug Hellmann wrote:
> Excerpts from Elõd Illés's message of 2018-09-21 16:08:28 +0200:
> > Hi,
> > 
> > Here is an etherpad with the teams that have stable:follow-policy tag on 
> > their repos:
> > 
> > https://etherpad.openstack.org/p/ocata-final-release-before-em
> > 
> > On the links you can find reports about the open and unreleased changes, 
> > that could be a useful input for the before-EM/final release.
> > Please have a look at the report (and review the open patches if there 
> > are) so that a release can be made if necessary.
> > 
> > Thanks,
> > 
> > Előd
> 
> Thanks for pulling all of this information together!
> 
> Doug
> 

Really useful information Előd - thanks for getting that put together!

Sean

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

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

[John Griffith]

On Fri, Sep 21, 2018 at 11:00 AM Sean McGinnis 
wrote:

> On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote:
> > All,
> >
> > In the last year we have had some changes to Core team participation.
> This
> > was a topic of discussion at the PTG in Denver last week.  Based on that
> > discussion I have reached out to John Griffith and Winston D (Huang
> Zhiteng)
> > and asked if they felt they could continue to be a part of the Core
> Team.
> > Both agreed that it was time to relinquish their titles.
> >
> > So, I am proposing to remove John Griffith and Winston D from Cinder
> Core.
> > If I hear no concerns with this plan in the next week I will remove them.
> >
> > It is hard to remove people who have been so instrumental to the early
> days
> > of Cinder.  Your past contributions are greatly appreciated and the team
> > would be happy to have you back if circumstances every change.
> >
> > Sincerely,
> > Jay Bryant
> >
>
> Really sad to see Winston go as he's been a long time member, but I think
> over
> the last several releases it's been obvious he's had other priorities to
> compete with. It would be great if that were to change some day. He's made
> a
> lot of great contributions to Cinder over the years.
>
> I'm a little reluctant to make any changes with John though. We've spoken
> briefly. He definitely is off to other things now, but with how deeply he
> has
> been involved up until recently with things like the multiattach
> implementation, replication, and other significant things, I would much
> rather
> have him around but less active than completely gone. Having a few good
> reviews
> is worth a lot.
>


> I would propose we hold off on changing John's status for at least a
> cycle. He
> has indicated to me he would be willing to devote a little time to still
> doing
> reviews as his time allows, and I would hate to lose out on his expertise
> on
> changes to some things. Maybe we can give it a little more time and see if
> his
> other demands keep him too busy to participate and reevaluate later?
>
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hey Everyone,

Now that I'm settling in on my other things I think I can still contribute
a bit to Cinder on my own time.  I'm still pretty fond of OpenStack and
Cinder so would love the opportunity to give it a cycle to see if I can
balance things and still be helpful.

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

[openstack-dev] [manila] Team Photos

[Tom Barron]

Manila team photos from the recent Stein PTG in Denver [1].

-- Tom Barron (tbarron)

[1] 
https://www.dropbox.com/sh/2pmvfkstudih2wf/AADI7Yo-wuJ2nmAIuYFEun5Ea/Manila?dl=0_nav_tracking=1


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

Re: [openstack-dev] [cinder] Proposed Changes to the Core Team ...

[Sean McGinnis]

On Wed, Sep 19, 2018 at 08:43:24PM -0500, Jay S Bryant wrote:
> All,
> 
> In the last year we have had some changes to Core team participation.  This
> was a topic of discussion at the PTG in Denver last week.  Based on that
> discussion I have reached out to John Griffith and Winston D (Huang Zhiteng)
> and asked if they felt they could continue to be a part of the Core Team. 
> Both agreed that it was time to relinquish their titles.
> 
> So, I am proposing to remove John Griffith and Winston D from Cinder Core. 
> If I hear no concerns with this plan in the next week I will remove them.
> 
> It is hard to remove people who have been so instrumental to the early days
> of Cinder.  Your past contributions are greatly appreciated and the team
> would be happy to have you back if circumstances every change.
> 
> Sincerely,
> Jay Bryant
> 

Really sad to see Winston go as he's been a long time member, but I think over
the last several releases it's been obvious he's had other priorities to
compete with. It would be great if that were to change some day. He's made a
lot of great contributions to Cinder over the years.

I'm a little reluctant to make any changes with John though. We've spoken
briefly. He definitely is off to other things now, but with how deeply he has
been involved up until recently with things like the multiattach
implementation, replication, and other significant things, I would much rather
have him around but less active than completely gone. Having a few good reviews
is worth a lot.

I would propose we hold off on changing John's status for at least a cycle. He
has indicated to me he would be willing to devote a little time to still doing
reviews as his time allows, and I would hate to lose out on his expertise on
changes to some things. Maybe we can give it a little more time and see if his
other demands keep him too busy to participate and reevaluate later?

Sean

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

Re: [openstack-dev] [docs][cinder] about cinder volume qos

[John Griffith]

On Mon, Sep 10, 2018 at 2:22 PM Jay S Bryant  wrote:

>
>
> On 9/10/2018 7:17 AM, Rambo wrote:
>
> Hi,all
>
>   At first,I find it is supported that we can define hard performance
> limits for each volume in doc.openstack.org[1].But only can define hard
> performance limits for each volume type in fact. Another, the note"As of
> the Nova 18.0.0 Rocky release, front end QoS settings are only supported
> when using the libvirt driver.",in fact, we have supported the front end
> QoS settings when using the libvirt driver previous. Is the document
> wrong?Can you tell me more about this ?Thank you very much.
>
> [1]
> https://docs.openstack.org/cinder/latest/admin/blockstorage-basic-volume-qos.html
>
>
>
> Rambo,
>
> The performance limits are limited to a volume type as you need to have a
> volume type to be able to associate a QoS type with it.  So, that makes
> sense.
>
> As for the documentation, it is a little confusing the way that is worded
> but it isn't wrong.  So, QoS support thus far, including Nova 18.0.0, front
> end QoS setting only works with the libvirt driver.  I don't interpret that
> as meaning that there wasn't QoS support before that.
>
Right, the point is that now it's listed as supported ONLY on libvirt, as
opposed to in the past it may have been supported on other hypervisors like
hyper-v, xen etc.  I don't know any of the details around how well those
other implementations worked or what decisions were made but I just read
the update as noting that currently only libvirt is supported, but not that
anything has changed there.

>
> Jay
>
>
>
>
>
>
> Best Regards
> Rambo
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [keystone] Keystone Team Update - Week of 17 September 2018

[Colleen Murphy]

# Keystone Team Update - Week of 17 September 2018

## News

### PTG recaps

The PTG was last week! Lance[1] and I[2] posted recaps of the keystone sessions.

[1] https://www.lbragstad.com/blog/openstack-stein-ptg-keystone-summary
[2] http://www.gazlene.net/denver-ptg-2.html

### No-op roles and default policy rules

adriant started a discussion[3][4] about the difficulty with creating limited 
or no-op roles due to the fact that most OpenStack services have default policy 
rules of just "" which translates to "any role on any project". This means if 
you wanted to give a user access only to, for example, Swift, which uses its 
own ACL model, you have to craft all of your policy files for every other 
OpenStack service to not use "" since those rules would allow the Swift-only 
users access to those other services. The default role work that has been 
ongoing since last cycle and that will eventually turn into a cross-project 
community effort will help to alleviate this hardship for operators by making 
default policies use explicit roles like "reader" and "member", but this will 
require a long transition period.

[3] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134886.html
[4] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-19.log.html#t2018-09-19T21:45:30

### Consistent policy names

lbragstad started a thread to come to consensus on standard policy name 
conventions so that we can come up with guidance when it comes time to start 
migrating policies to use default roles. Vote for your favorite bikeshed color 
on the thread[5].

[5] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134597.html

## Open Specs

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

knikolla started working on a refreshable app creds proposal which will be 
useful for federation and Edge use cases[6]. wxy is working on the next 
iteration of hierarchical limit models by adding domains to the mix[7]. 
lbragstad reproposed the JWT spec with additional details that we discussed at 
the PTG[8].

[6] https://review.openstack.org/604201
[7] https://review.openstack.org/599491
[8] https://review.openstack.org/541903

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT (link updated to include oslo.limit)

We merged 15 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2PUk84S (link updated to include oslo.limit)

There are 50 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 6 new bugs and closed 3.

Bugs opened (5) 
Bug #1793027 (keystone:Critical) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1793027 
Bug #1793374 (keystone:Low) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1793374 
Bug #1793421 (keystone:Low) opened by fupingxie 
https://bugs.launchpad.net/keystone/+bug/1793421 
Bug #1792868 (keystone:Undecided) opened by Tao Li 
https://bugs.launchpad.net/keystone/+bug/1792868 
Bug #1793347 (keystone:Undecided) opened by Tobias Urdin 
https://bugs.launchpad.net/keystone/+bug/1793347 

Bugs fixed (3) 
Bug #1793027 (keystone:Critical) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1793027 
Bug #1754677 (keystone:High) fixed by Raildo Mascena de Sousa Filho 
https://bugs.launchpad.net/keystone/+bug/1754677 
Bug #1431987 (keystone:Wishlist) fixed by no one 
https://bugs.launchpad.net/keystone/+bug/1431987

## Milestone Outlook

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

Welcome to the Stein cycle! This cycle is a longer one so we have a bit of 
extra time between the spec freeze and feature freeze. lbragstad just updated 
the schedule so if you have issues with it we can probably still make 
adjustments.

## Shout-outs

Vishakha Agarwal has been doing a lot of work tackling our bug backlog, thanks 
a lot for your hard work!

## 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] [manila] Stein PTG summary

[Tom Barron]

We've summarized the manila PTG sessions in this etherpad [1] and I've 
included its contents below.


Please feel free to supplement/correct as appropriate, or to follow up 
on this mailing list.


-- Tom Barron (tbarron)

We'll use this etherpad to distill AIs, focus areas, etc. from the Stein PTG

Source: https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018

Retrospective:
*  https://etherpad.openstack.org/p/manila-rocky-retrospective
* Is Dustin willing to be our official bug czar [dustins] Yes! ++
* Should plan regional bug smash days and participate in and publish 
regional OpenStack/open source events
* Need someone to lead? (See AI for tbarron)
* Need more/earlier review attention for approved specs - PTL needs to 
keep attention on review priorities
* Use our wiki rather than misc. etherpads to track work, review focus, 
liaisons, etc.
* Add "Bug Czar", bug deputies info on the wiki

Survey Results: 
https://docs.google.com/spreadsheets/d/1J83vnnuuADVwACeJq1g8snxMRM5VAfTbBD6svVeH4yg/edit#gid=843813633


Work planned for Stein:
* governance goals
* convert gate jobs to python3
* Assignee: vkmc
* need to track progress, including 3rd party jobs, on 
the wiki
* upgrade health checker (governance goal)
* Assignee: ?
* Rocky backlog
* continue priority for access rules
* Assignee: zhongjun
* need to track driver side work on the wiki
* open to continuing json schema request validation
* Assignee: no one appears to be working it currently 
though
* gouthamr will reach out to original authors and 
report status during the next week's weekly meeting
* Manila CSI
* Assignee: gouthamr, vkmc, tbarron
* hodgepodge is setting up biweekly meeting to drive 
convergence of disparate efforts
* https://etherpad.openstack.org/p/sig-k8s-2018-denver-ptg
* Active-active share service
* Assignee: gouthamr
* we were going to wait for cinder action because of downstream 
tooz back end dependencies
* but later Cinder decided to move ahead aggressively on this 
since it's needed for Edge distributed control plane topology so we may start 
work in manila on this in this cycle too
* openstack client integration
* Assignee: gouthamr will drive, distribute work
* We might be able to get an Outreachy intern to help with this 
+++
* openstack sdk integration
* Assignee: amito will drive, distribute work
* We might be able to get an Outreachy intern to help with this 
+++
* telemetry extension
* Assignee: vkmc
* share usage meter, doc, testing
* manage/unmanage for DHSS=True
* Assignee: ganso
* create share from snapshot in another pool/backend
* Asignee: ganso
* replication for DHSS=True
* Assignee: ganso
* OVS -> OVN
* Asignee: tbarron/gouthamr
* 3rd party backends may only work with OVS?
* Manila UI Plugin
* Assignee: vkmc
* Features mapping: how outdated are we?
* Selenium test enablement [dustins: I can help/do this] ++
* uWSGI enablement
* Assignee: vkmc
* By default in devstack?

Agreements:
* Hold off on storyboard migration till attachments issue is resolved
* Don't need placement service but (like cinder) can use Jay Pipes DB 
generation synchronization technique to avoid scheduler races
* Can publish info to placement if / when that is useful for 
nova
* Use "low-hanging-fruit" as a bug tag on trivial bugs
* Pro-active backport policy for non-vendor fixes (Also see AIs for 
gouthamr/ganso)
* Vendor fixes need a +1 or +2 from a vendor reviewer if they 
are active

Action Items:
* tbarron: follow up on user survey question, how to refresh it, talk 
with manila community
* tbarron: refurbish the manila wiki as central landing spot for review 
focus, roles (liaisons, bug czar, etc. rather than us maintaining miscellaneous 
etherpads that get lost.
* tbarron: get agreement on mid-cycle meetup (maybe virtual) and 
America's bug smash +1
* ganso: post proposed stable branch policy for review & talk with 
gouthamr about it
* gouthamr: post proposed revised review policy for review
* gouthamr: drive question of graduation of Experimental features via 
weekly manila meeting/dev mail list
* dustins: Send email to the Manila list to have people sign up for 

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

[Doug Hellmann]

Excerpts from Elõd Illés's message of 2018-09-21 16:08:28 +0200:
> Hi,
> 
> Here is an etherpad with the teams that have stable:follow-policy tag on 
> their repos:
> 
> https://etherpad.openstack.org/p/ocata-final-release-before-em
> 
> On the links you can find reports about the open and unreleased changes, 
> that could be a useful input for the before-EM/final release.
> Please have a look at the report (and review the open patches if there 
> are) so that a release can be made if necessary.
> 
> Thanks,
> 
> Előd

Thanks for pulling all of this information together!

Doug

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

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

[Lance Bragstad]

On Fri, Sep 21, 2018 at 2:10 AM Ghanshyam Mann 
wrote:

>   On Thu, 20 Sep 2018 18:43:00 +0900 John Garbutt <
> j...@johngarbutt.com> wrote 
>  > tl;dr+1 consistent names
>  > I would make the names mirror the API... because the Operator setting
> them knows the API, not the codeIgnore the crazy names in Nova, I certainly
> hate them
>
> Big +1 on consistent naming  which will help operator as well as developer
> to maintain those.
>
>  >
>  > Lance Bragstad  wrote:
>  > > I'm curious if anyone has context on the "os-" part of the format?
>  >
>  > My memory of the Nova policy mess...* Nova's policy rules traditionally
> followed the patterns of the code
>  > ** Yes, horrible, but it happened.* The code used to have the OpenStack
> API and the EC2 API, hence the "os"* API used to expand with extensions, so
> the policy name is often based on extensions** note most of the extension
> code has 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

  @controller.protected
  def list_users(self):
  ...

Having the policy name the same as the method name made it easier for the
decorator implementation to resolve the policy needed to protect the API
because it just looked at the name of the wrapped method. The advantage was
that it was easy to implement new APIs because you only needed to add a
policy, implement the method, and make sure you decorate the implementation.

While this worked, we are moving away from it entirely. The decorator
implementation was ridiculously complicated. Only a handful of keystone
developers understood it. With the addition of system-scope, it would have
only become more convoluted. It also enables a much more copy-paste pattern
(e.g., so long as I wrap my method with this decorator implementation,
things should work right?). Instead, we're calling enforcement within the
controller implementation to ensure things are easier to understand. It
requires developers to be cognizant of how different token types affect the
resources within an API. That said, coupling the policy name to the method
name is no longer a requirement for keystone.

Hopefully, that helps explain why we needed them to match.


>
> Also we have action API (i know from nova not sure from other services)
> like POST /servers/{server_id}/action {addSecurityGroup} and their current
> policy name is all inconsistent.  few have policy name including their
> resource name like "os_compute_api:os-flavor-access:add_tenant_access", few
> has 'action' in policy name like
> "os_compute_api:os-admin-actions:reset_state" and few has direct action
> name like "os_compute_api:os-console-output"
>

Since the actions API relies on the request body and uses a single HTTP
method, does it make sense to have the HTTP method in the policy name? It
feels redundant, and we might be able to establish a convention that's more
meaningful for things like action APIs. It looks like cinder has a similar
pattern [0].

[0]
https://developer.openstack.org/api-ref/block-storage/v3/index.html#volume-actions-volumes-action


>
> May be we can make them consistent with
> :: or any better opinion.
>
>  > From: Lance Bragstad > The topic of having
> consistent policy names has popped up a few times this week.
>  >
>  > I would love to have this nailed down before we go through all the
> policy rules again. In my head I hope in Nova we can go 

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?

[Elõd Illés]

Hi,

Here is an etherpad with the teams that have stable:follow-policy tag on 
their repos:


https://etherpad.openstack.org/p/ocata-final-release-before-em

On the links you can find reports about the open and unreleased changes, 
that could be a useful input for the before-EM/final release.
Please have a look at the report (and review the open patches if there 
are) so that a release can be made if necessary.


Thanks,

Előd


On 2018-09-21 00:53, Matt Riedemann wrote:

On 9/20/2018 12:08 PM, Elõd Illés wrote:

Hi Matt,

About 1.: I think it is a good idea to cut a final release 
(especially as some vendor/operator would be glad even if there would 
be some release in Extended Maintenance, too, what most probably 
won't happen...) -- saying that without knowing how much of a burden 
would it be for projects to do this final release...
After that it sounds reasonably to tag the branches EM (as it is 
written in the mentioned resolution).


Do you have any plan about how to coordinate the 'final releases' and 
do the EM-tagging?


Thanks for raising these questions!

Cheers,

Előd


For anyone following along and that cares about this (hopefully PTLs), 
Előd, Doug, Sean and I formulated a plan in IRC today [1].


[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-stable/%23openstack-stable.2018-09-20.log.html#t2018-09-20T17:10:56






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

[openstack-dev] OpenStack Project Navigator

[Jimmy Mcarthur]

Following up on my (very brief) talk from the PTG, you can now propose 
changes to the Project Navigator by going to 
https://git.openstack.org/cgit/openstack/openstack-map repository


Once your patch is merged, the page should reflect the changes straight 
away.


Cheers,
Jimmy

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

[openstack-dev] [all][tc] please vote

[Doug Hellmann]

A few hours ago Emmet reported that we have around 20% participation
in the Technical Committee election, so far. I think we can do
better.

Our community is founded on the idea that the contributors should
decide how the project is run. PTL and TC elections are the most
explicit example of this principle in action. The people elected
to the TC this term will be representing your interests to the Board
as the Foundation continues to evolve and expand its scope with new
focus areas and projects. They also will continue to work on building and
sustaining the community, choosing and organizing series goals, and
making decisions that have long term effects on the project.

Please take a few minutes to look at Kendall's instructions[1],
find your ballot email, and think about which candidates you want
to have on the committee. Then cast your vote, today.

Doug

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134820.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

[openstack-dev] 回复：[goals][python3][karbor] Please process thepython3-first patches

[jiaopengju]

Thanks for pushing these patches, we will review and merge them ASAP.




原始邮件
发件人:Nguyễn Trí Hảinguyentriha...@gmail.com
收件人:OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.org
抄送:jiaopengjujiaopen...@cmss.chinamobile.com
发送时间:2018年9月21日(周五) 20:36
主题:[openstack-dev][goals][python3][karbor] Please process thepython3-first 
patches


HiKarbor team and Karbor PTL,


As part of the "Run under Python 3 by default" community goal [1] for OpenStack 
in the Stein cycle, I proposed the patches related to python3-first goal very 
long time ago. However, there is no activity for those patches.

Please receive those patches and review them. Those patches belong to:
- openstack/karbor
- openstack/karbor-dashboard
- openstack/python-karborclient

Here they 
are:https://review.openstack.org/#/q/project:%255E.*karbor.*+topic:python3-first+status:open


[1]https://governance.openstack.org/tc/goals/stein/python3-first.html



-- 

Nguyen Tri Hai/ Ph.D. Student
ANDA Lab., Soongsil Univ., Seoul, South Korea__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [goals][python3][karbor] Please process the python3-first patches

[Nguyễn Trí Hải]

Hi Karbor team and Karbor PTL,

As part of the "Run under Python 3 by default" community goal [1] for
OpenStack in the Stein cycle, I proposed the patches related to
python3-first goal very long time ago. However, there is no activity for
those patches.

Please receive those patches and review them. Those patches belong to:
- openstack/karbor
- openstack/karbor-dashboard
- openstack/python-karborclient

Here they are:
https://review.openstack.org/#/q/project:%255E.*karbor.*+topic:python3-first+status:open

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html

-- 

Nguyen Tri Hai / Ph.D. Student

ANDA Lab., Soongsil Univ., Seoul, South Korea



*[image:
http://link.springer.com/chapter/10.1007/978-3-319-26135-5_4]
* 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][nova] Small bandwidth demo on the PTG

[Bence Romsics]

Hi,

At the demo it turned out that people were interested in a written
version of the demo, so here you can find a blog post about the
current state of the guaranteed minimum bandwidth feature:

https://rubasov.github.io/2018/09/21/openstack-qos-min-bw-demo.html

Cheers,
Bence
On Thu, Sep 13, 2018 at 4:48 AM Balázs Gibizer
 wrote:
>
> Hi,
>
> It seems that the Nova room (Ballroom A) does not have any projection
> possibilities. In the other hand the Neutron room (
> Vail Meeting Room, Atrium Level) does have a projector. So I suggest to
> move the demo to the Neutron room.
>
> Cheers,
> gibi
>
> On Fri, Aug 31, 2018 at 2:29 AM, Balázs Gibizer
>  wrote:
> >
> >
> > On Thu, Aug 30, 2018 at 8:13 PM, melanie witt 
> > wrote:
> >> On Thu, 30 Aug 2018 12:43:06 -0500, Miguel Lavalle wrote:
> >>> Gibi, Bence,
> >>>
> >>> In fact, I added the demo explicitly to the Neutron PTG agenda from
> >>>   1:30  to 2, to give it visiblilty
> >>
> >> I'm interested in seeing the demo too. Will the demo be shown at the
> >>  Neutron room or the Nova room? Historically, lunch has ended at
> >> 1:30,  so this will be during the same time as the Neutron/Nova
> >> cross  project time. Should we just co-locate together for the demo
> >> and the  session? I expect anyone watching the demo will want to
> >> participate  in the Neutron/Nova session as well. Either room is
> >> fine by me.
> >>
> >
> > I assume that the nova - neturon cross project session will be in the
> > nova room, so I propose to have the demo there as well to avoid
> > unnecessarily moving people around. For us it is totally OK to start
> > the demo at 1:30.
> >
> > Cheers,
> > gibi
> >
> >
> >> -melanie
> >>
> >>> On Thu, Aug 30, 2018 at 3:55 AM, Balázs Gibizer
> >>> >>> >   wrote:
> >>>
> >>> Hi,
> >>>
> >>> Based on the Nova PTG planning etherpad [1] there is a need to
> >>>   talk
> >>> about the current state of the bandwidth work [2][3]. Bence
> >>> (rubasov) has already planned to show a small demo to Neutron
> >>>   folks
> >>> about the current state of the implementation. So Bence and I
> >>> are
> >>> wondering about bringing that demo close to the nova - neutron
> >>>   cross
> >>> project session. That session is currently planned to happen
> >>> Thursday after lunch. So we are think about showing the demo
> >>>   right
> >>> before that session starts. It would start 30 minutes before the
> >>> nova - neutron cross project session.
> >>>
> >>> Are Nova folks also interested in seeing such a demo?
> >>>
> >>> If you are interested in seeing the demo please drop us a line
> >>> or
> >>> ping us in IRC so we know who should we wait for.
> >>>
> >>> Cheers,
> >>> gibi
> >>>
> >>> [1] https://etherpad.openstack.org/p/nova-ptg-stein
> >>> 
> >>> [2]
> >>>
> >>>   
> >>> https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html
> >>>
> >>>   
> >>> 
> >>> [3]
> >>>
> >>>   
> >>> https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.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
> >>>
> >>>   
> >>>
> >>>
> >>>
> >>>
> >>> __
> >>> 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] [release][collectd-openstack-plugins] Schedule new release?

[Jeremy Stanley]

On 2018-09-21 05:53:08 -0500 (-0500), Sean McGinnis wrote:
[...]
> collectd-openstack-plugins does not appear to be an official repo under
> governance [1]. For these types of projects to do a release, the team would
> need to push a tag to the repo. That will trigger some post jobs to run that
> will create and publish tarballs. Some basic information (though slightly
> different context) can be found here [2].
> 
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
> [2] 
> https://docs.openstack.org/infra/manual/creators.html#prepare-an-initial-release

Perhaps slightly more aligned with the context of the question is
this document:
https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
-- 
Jeremy Stanley


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

Re: [openstack-dev] [ptg][cinder] Stein PTG Summary Page Ready ...

[Erlon Cruz]

Thanks Jay!

Em qua, 19 de set de 2018 às 06:53, Gorka Eguileor 
escreveu:

> On 18/09, Jay S Bryant wrote:
> > Team,
> >
> > I have put together the following page with a summary of all our
> discussions
> > at the PTG: https://wiki.openstack.org/wiki/CinderSteinPTGSummary
> >
> > Please review the contents and let me know if anything needs to be
> changed.
> >
> > Jay
> >
> >
>
> Hi Jay,
>
> Thank you for the great summary, it looks great.
>
> After reading it, I can't think of anything that's missing.
>
> Cheers,
> Gorka.
>
> __
> 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] [release][collectd-openstack-plugins] Schedule new release?

[Sean McGinnis]

On Fri, Sep 21, 2018 at 09:43:52AM +0200, Matthias Runge wrote:
> Hello,
> 
> it has been some time, since collectd-ceilometer-plugin[1]
> has been renamed to collectd-openstack-plugins[2] and since there has been a
> release.
> 
> What is required to trigger a new release here?
> 
> Thank you,
> Matthias
> 
> 
> [1] https://github.com/openstack/collectd-ceilometer-plugin
> [2] https://github.com/openstack/collectd-openstack-plugins
> -- 
> Matthias Runge 
> 

Hi Matthias,

collectd-openstack-plugins does not appear to be an official repo under
governance [1]. For these types of projects to do a release, the team would
need to push a tag to the repo. That will trigger some post jobs to run that
will create and publish tarballs. Some basic information (though slightly
different context) can be found here [2].

[1] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[2] 
https://docs.openstack.org/infra/manual/creators.html#prepare-an-initial-release

--
Sean McGinnis (smcginnis)

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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists!

[Julia Kreger]

In my mind, there is value to having a mailing list for things like
important meetings, but it seems more reasonable to just address such
items as needed. At the same time, I agree with ttx, the separate list
is no longer useful. +1
On Fri, Sep 21, 2018 at 5:24 AM Thierry Carrez  wrote:
>
> Doug Hellmann wrote:
> > I'm inclined to include it and either use a direct mailing or the
> > [tc] tag on the new discuss list to reach TC members, but I would
> > like to hear feedback from TC members and other interested parties
> > before calling that decision made. Please let me know what you think.
>
> +1 -- the separate list has outlived its usefulness.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] [ironic] status of the zuulv3 job migration

[Derek Higgins]

Just quick summary of the status and looking for some input about the
experimental jobs

15 jobs are now done, with another 2 ready for reviewing. This leaves 6
jobs
1 x multinode job
   I've yet to finished porting this one
2 x grenade jobs
   Last time I looked grenade jobs couldn't yet be ported to zuulv3 native
but I'll investigate further

3 x experimental jobs
(ironic-dsvm-functional, ironic-tempest-dsvm-parallel,
ironic-tempest-dsvm-pxe_ipa-full)
These don't currently pass and it doesn't look like anybody is using
them, So I'd like to know if there is anybody out there interested in them,
if not I'll go ahead and remove them.

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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists!

[Thierry Carrez]

Doug Hellmann wrote:

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


+1 -- the separate list has outlived its usefulness.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [release-schedule] about release Series

[Thierry Carrez]

Jaze Lee wrote:

Hello,
 Is the content in https://releases.openstack.org/ is the latest?
There are some question here, why Queens cycles is longer then Rocy cycles.
 The Rocy cycles is too shot of live, even less than six month? May
be the "estimated 2019-02-23" is a slip of pen? Should it be
"2020-02-23" ?
Can someone tell some reason about this? Thanks a lot.


It probably is a slip of pen. Thanks for noticing !

I proposed the fix: https://review.openstack.org/604309

--
Thierry Carrez (ttx)

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

[openstack-dev] [release][collectd-openstack-plugins] Schedule new release?

[Matthias Runge]

Hello,

it has been some time, since collectd-ceilometer-plugin[1]
has been renamed to collectd-openstack-plugins[2] and since there has 
been a release.


What is required to trigger a new release here?

Thank you,
Matthias


[1] https://github.com/openstack/collectd-ceilometer-plugin
[2] https://github.com/openstack/collectd-openstack-plugins
--
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

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

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

[Ghanshyam Mann]

  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.

Also we have action API (i know from nova not sure from other services) like 
POST /servers/{server_id}/action {addSecurityGroup} and their current policy 
name is all inconsistent.  few have policy name including their resource name 
like "os_compute_api:os-flavor-access:add_tenant_access", few has 'action' in 
policy name like "os_compute_api:os-admin-actions:reset_state" and few has 
direct action name like "os_compute_api:os-console-output"

May be we can make them consistent with 
:: or any better opinion. 

 > From: Lance Bragstad > The topic of having consistent 
 > policy names has popped up a few times this week.
 > 
 > I would love to have this nailed down before we go through all the policy 
 > rules again. In my head I hope in Nova we can go through each policy rule 
 > and do the following:
 > * move to new consistent policy name, deprecate existing name* hardcode 
 > scope check to project, system or user** (user, yes... keypairs, yuck, but 
 > its how they work)** deprecate in rule scope checks, which are largely bogus 
 > in Nova anyway* make read/write/admin distinction** therefore adding the 
 > "noop" role, amount other things

+ policy granularity. 

It is good idea to make the policy improvement all together and for all rules 
as you mentioned. But my worries is how much load it will be on operator side 
to migrate all policy rules at same time? What will be the deprecation period 
etc which i think we can discuss on proposed spec - 
https://review.openstack.org/#/c/547850

-gmann

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



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

Re: [openstack-dev] [Openstack-sigs] [First Contact] SIG PTG Summary

[Rico Lin]

On Thu, Sep 20, 2018 at 1:23 PM Kendall Nelson 
wrote:

Organization Guide
>
> ===
>
> Back in Sydney, we started discussing creating a guide for organizations
> to educate them on what their contributors need to be effective and
> successful members of the community. There is a patch out for review right
> now[7] that we want to get merged as soon as possible so that we can
> publicize it in Berlin and start introducing it when new companies join the
> foundation. It was concluded that we needed to add more rationalizations to
> the requirements and we delegated those out to ricolin, jungleboyj, and
> spotz to help mattoliverau with content. As soon as this patch gets merged,
> I volunteered to work to get it onto the soonest board meeting possible.
>
 Dear all,
As an action, I just post some suggest changes for `Technical` section
(with comments) in [7], please take a look.

>
> [7] https://review.openstack.org/#/c/578676
>
-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] Nominating Luis Tomás Bolívar for kuryr-kubernetes core

[Michał Dulko]

On Thu, 2018-09-20 at 18:33 +0200, Daniel Mellado wrote:
> Hi All,
> 
> Id like to nominate Luis Tomás for Kuryr-Kubernetes core.
> 
> He has been contributing to the project development with both features
> and quality reviews at core reviewer level, as well as being the stable
> branch liaison keeping on eye on every needed backport and bug and
> fighting and debugging lbaas issues.
> 
> Please follow up with a +1/-1 to express your support, even if he makes
> the worst jokes ever!

Looks like Luis is doing most of the review work recently [1], so it's
definitely a confident +1 from me.

[1] http://stackalytics.com/report/contribution/kuryr-group/90

> Thanks!
> 
> Daniel


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

[openstack-dev] [release-schedule] about release Series

[Jaze Lee]

Hello,
Is the content in https://releases.openstack.org/ is the latest?
   There are some question here, why Queens cycles is longer then Rocy cycles.
The Rocy cycles is too shot of live, even less than six month? May
be the "estimated 2019-02-23" is a slip of pen? Should it be
"2020-02-23" ?
   Can someone tell some reason about this? Thanks a lot.





-- 
谦谦君子

__
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