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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Samuel Cassiba]

On Thu, Sep 20, 2018 at 2:48 PM Doug Hellmann  wrote:
>
> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
> > tl;dr: The openstack, openstack-dev, openstack-sigs and
> > openstack-operators mailing lists (to which this is being sent) will
> > be replaced by a new openstack-disc...@lists.openstack.org mailing
> > list.
>
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
>
> I'm inclined to include it and either use a direct mailing or the
> [tc] tag on the new discuss list to reach TC members, but I would
> like to hear feedback from TC members and other interested parties
> before calling that decision made. Please let me know what you think.
>
> Doug
>

+1 including the TC list as a tag makes sense to me and my tangent
about intent in online communities.

__
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! (was: Bringing the community together...)

[Ghanshyam Mann]

  On Fri, 21 Sep 2018 06:46:43 +0900 Doug Hellmann  
wrote  
 > Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
 > > tl;dr: The openstack, openstack-dev, openstack-sigs and
 > > openstack-operators mailing lists (to which this is being sent) will
 > > be replaced by a new openstack-disc...@lists.openstack.org mailing
 > > list.
 > 
 > Since last week there was some discussion of including the openstack-tc
 > mailing list among these lists to eliminate confusion caused by the fact
 > that the list is not configured to accept messages from all subscribers
 > (it's meant to be used for us to make sure TC members see meeting
 > announcements).
 > 
 > I'm inclined to include it and either use a direct mailing or the
 > [tc] tag on the new discuss list to reach TC members, but I would
 > like to hear feedback from TC members and other interested parties
 > before calling that decision made. Please let me know what you think.

+1 on including the openstack-tc also. That will help to get more attentions on 
TC discussions from other group also. 

-gmann

 > 
 > 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-dev] [Searchlight] vPTG Summary

[Trinh Nguyen]

Hi team,

We had had a great vPTG yesterday. Here is the summary [1].

Thank Kevin_Zheng and thuydang for joining us.

Bests,

[1] https://www.dangtrinh.com/2018/09/searchlight-vptg-summary.html


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
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] [congress] proposed new meeting time

[Eric K]

Hi all,

Following discussions in IRC meetings, here is a proposed new meeting
time for Congress project:
On even weeks, Friday UTC 4AM (from the current UTC 2:30AM)

The new time would make it easier for India while still good for Asia
Pacific. The time continues to be bad for Europe and Eastern Americas.
We can add another meeting time in the off week if there is interest.

Please respond if you have any additional comments!

Eric Kao

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

Re: [openstack-dev] [StoryBoard] PTG Summary

[Trinh Nguyen]

Hi Kendall,

I couldn't attend the PTG but those are exactly what I love to have in
Storyboard, especially "Project Group Descriptions" and "Story Attachments".

Thanks for the effort!

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Fri, Sep 21, 2018 at 6:15 AM Kendall Nelson 
wrote:

> Hello Lovers of Task Tracking!
>
> So! We talked about a lot of things, and I went to a lot of rooms to talk
> about StoryBoard related things and it was already a week ago so bear with
> me.
>
> We had a lot of good discussions as we were able to include SotK in
> discussions via videocalling. We also had the privilege of our outreachy
> intern to come all the way from Cairo to Denver to join us :)
>
> Onto the summaries!
>
> Story Attachments
>
> ==
>
> This topic has started coming up with increasing regularity. Currently,
> StoryBoard doesn’t support attachments, but it’s a feature that several
> projects claim to be blocking their migration. The current work around is
> either to trim down logs and paste the relevant section, or to host the
> file elsewhere and link to its location. After consulting with the
> infrastructure team, we concluded that currently, there is no donated
> storage. The next step is for me to draft a spec detailing our requirements
> and implementation details and then to include infra on the review to help
> them have something concrete to go to vendors with. For notes on the
> proposed method see the etherpad[1].
>
> One other thing discussed during this topic was how we could maybe migrate
> the current attachments. This isn’t supported by the migration script at
> this point, but it’s something we could write a separate script for. It
> should be separate because it would be a painfully slow process and we
> wouldn’t want to slow down the migration script more than it already is by
> the Launchpad API. The attachments script would be run after the initial
> migration; that being said, everything still persists in Launchpad so
> things can still be referenced there.
>
> Handling Duplicate Stories
>
> 
>
> This is also an ongoing topic for discussion. Duplicate stories if not
> handled properly could dilute the database as we get more projects migrated
> over. The plan we settled on is to add a ‘Mark as Duplicate’ button to the
> webclient and corresponding functions to the API. The user would be
> prompted for a link to the master story. The master story would get a new
> timeline event that would have the link to the duplicate and the duplicate
> story would have all tasks auto marked as invalid (aside from those marked
> as merged) so that the story then shows as inactive. The duplicate story
> could also get a timeline event that explains what happened and links to
> the master story. I’ve yet to create a story for all of this, but it’s on
> my todo list.
>
> Handling Thousands of Comments Per Story
>
> ==
>
> There’s this special flower story[2] that has literally thousands of
> comments on it because of all of the gerrit comments being added to the
> timeline for all the patches for all the tasks. Rendering of the timeline
> portion of the webpage in the webclient is virtually impossible. It will
> load the tasks and then hang forever. The discussion around this boiled
> down to this: other task trackers also can’t handle this and there is a
> better way to divvy up the story into several stories and contain them in a
> worklist for future, similar work. For now, users can select what they want
> to load in their timeline views for stories, so by unmarking all of the
> timeline events in their preferences, the story will load completely sans
> timeline details. Another solution we discussed to help alleviate the
> timeline load on stories with lots of tasks is to have a task field that
> links to the review, rather than a comment from gerrit every time a new
> patch gets pushed. Essentially we want to focus on cleaning up the timeline
> rather than just going straight to a pagination type of solution. It was
> also concluded that we want to add another user preference for page sizes
> of 1000. Tasks have not been created in the story related to this issue
> yet[3], but its on my todo list.
>
> Project Group Descriptions
>
> =
>
> There was a request to have project group descriptions, but currently
> there is nothing in the API handling this. Discussion concluded with
> agreement that this shouldn’t be too difficult. All that needs to happen is
> a few additions to the API and the connection to managing group definitions
> in project-config. I still need to make a story for this.
>
> Translating storyboard-webclient
>
> =
>
> There was an infrastructure mailing list thread a little while back that
> kicked off discussion on this topic. It was received as an interesting idea
> and co

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Zhipeng Huang]

+1 and thanks for the effort to make this happen

On Fri, Sep 21, 2018, 9:22 AM Lance Bragstad  wrote:

>
>
> On Thu, Sep 20, 2018 at 7:19 PM Sean McGinnis 
> wrote:
>
>> On Thu, Sep 20, 2018 at 03:46:43PM -0600, Doug Hellmann wrote:
>> > Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
>> > > tl;dr: The openstack, openstack-dev, openstack-sigs and
>> > > openstack-operators mailing lists (to which this is being sent) will
>> > > be replaced by a new openstack-disc...@lists.openstack.org mailing
>> > > list.
>> >
>> > Since last week there was some discussion of including the openstack-tc
>> > mailing list among these lists to eliminate confusion caused by the fact
>> > that the list is not configured to accept messages from all subscribers
>> > (it's meant to be used for us to make sure TC members see meeting
>> > announcements).
>> >
>> > I'm inclined to include it and either use a direct mailing or the
>> > [tc] tag on the new discuss list to reach TC members, but I would
>> > like to hear feedback from TC members and other interested parties
>> > before calling that decision made. Please let me know what you think.
>> >
>> > Doug
>> >
>>
>> This makes sense to me. I would rather have any discussions where
>> everyone is
>> likely to see them than to continue with the current separation.
>>
>
> +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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Lance Bragstad]

On Thu, Sep 20, 2018 at 7:19 PM Sean McGinnis  wrote:

> On Thu, Sep 20, 2018 at 03:46:43PM -0600, Doug Hellmann wrote:
> > Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
> > > tl;dr: The openstack, openstack-dev, openstack-sigs and
> > > openstack-operators mailing lists (to which this is being sent) will
> > > be replaced by a new openstack-disc...@lists.openstack.org mailing
> > > list.
> >
> > Since last week there was some discussion of including the openstack-tc
> > mailing list among these lists to eliminate confusion caused by the fact
> > that the list is not configured to accept messages from all subscribers
> > (it's meant to be used for us to make sure TC members see meeting
> > announcements).
> >
> > I'm inclined to include it and either use a direct mailing or the
> > [tc] tag on the new discuss list to reach TC members, but I would
> > like to hear feedback from TC members and other interested parties
> > before calling that decision made. Please let me know what you think.
> >
> > Doug
> >
>
> This makes sense to me. I would rather have any discussions where everyone
> is
> likely to see them than to continue with the current separation.
>

+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] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Rico Lin]

On Fri, Sep 21, 2018 at 5:59 AM Melvin Hillsman 
wrote:
>
>  I agree all lists should be merged as discussed otherwise why not just
leave all things as they are :P
Yeah, if we merged all lists, it's much easier for all to know exactly
where they can go for trigger discussions.
I doubt all experienced developers and ops are subscribe all list that
relative to them.
>From this point, and combine with global reach out, we can easily give
correct information for newcomers.

I'm tired to put `[openstack-dev][Openstack-operators][Openstack-sigs]` in
front of my mail title, that just pure madness
--
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] Capturing Feedback/Input

[Sean McGinnis]

On Thu, Sep 20, 2018 at 05:30:32PM -0500, Melvin Hillsman wrote:
> 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.
> 
> -- 
> Kind regards,
> 
> Melvin Hillsman

I think Storyboard would be a good place to manage SIG/WG feedback. It will
take some time before the majority of projects have moved over from Launchpad,
but once they do, this will make it much easier to track SIG initiatives all
the way through to code implementation.

__
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! (was: Bringing the community together...)

[Sean McGinnis]

On Thu, Sep 20, 2018 at 03:46:43PM -0600, Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
> > tl;dr: The openstack, openstack-dev, openstack-sigs and
> > openstack-operators mailing lists (to which this is being sent) will
> > be replaced by a new openstack-disc...@lists.openstack.org mailing
> > list.
> 
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
> 
> I'm inclined to include it and either use a direct mailing or the
> [tc] tag on the new discuss list to reach TC members, but I would
> like to hear feedback from TC members and other interested parties
> before calling that decision made. Please let me know what you think.
> 
> Doug
> 

This makes sense to me. I would rather have any discussions where everyone is
likely to see them than to continue with the current separation.


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

[openstack-dev] Neutron drivers meeting on September 21st

[Miguel Lavalle]

Hi,

Since we just came back from the PTG in Denver and we reviewed / discussed
many RFEs, let's skip the Drivers meeting tomorrow, Friday 21st. We will
resume the meeting on the 28th

Best regards

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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Jeremy Stanley]

On 2018-09-20 15:46:43 -0600 (-0600), Doug Hellmann wrote:
[...]
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
[...]

I think it makes sense. The Interop WG also indicated they'd like to
do the same with theirs. In cases like these where the lists in
question have much lower volume anyway, I don't think any special
handling is needed. Basically any time after November 19 just send a
post to the old list saying that subsequent messages need to
go to openstack-discuss instead, and then immediately set it to no
longer accept new messages.
-- 
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] Are we ready to put stable/ocata into extended maintenance mode?

[Matt Riedemann]

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


--

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] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Davanum Srinivas]

+1 from me.

On Thu, Sep 20, 2018 at 5:59 PM Melvin Hillsman 
wrote:

>  I agree all lists should be merged as discussed otherwise why not just
> leave all things as they are :P
>
> On Thu, Sep 20, 2018 at 4:49 PM Emilien Macchi  wrote:
>
>>
>>
>> On Thu, Sep 20, 2018 at 5:47 PM Doug Hellmann 
>> wrote:
>>
>>> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
>>> > tl;dr: The openstack, openstack-dev, openstack-sigs and
>>> > openstack-operators mailing lists (to which this is being sent) will
>>> > be replaced by a new openstack-disc...@lists.openstack.org mailing
>>> > list.
>>>
>>> Since last week there was some discussion of including the openstack-tc
>>> mailing list among these lists to eliminate confusion caused by the fact
>>> that the list is not configured to accept messages from all subscribers
>>> (it's meant to be used for us to make sure TC members see meeting
>>> announcements).
>>>
>>> I'm inclined to include it and either use a direct mailing or the
>>> [tc] tag on the new discuss list to reach TC members, but I would
>>> like to hear feedback from TC members and other interested parties
>>> before calling that decision made. Please let me know what you think.
>>>
>>
>> +2 , easier to manage, easier to reach out.
>> --
>> 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
>>
>
>
> --
> 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
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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

[Zhipeng Huang]

big +1, really look forward to the storyboard setup

On Fri, Sep 21, 2018 at 6:31 AM Melvin Hillsman 
wrote:

> 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.
>
> --
> Kind regards,
>
> Melvin Hillsman
> mrhills...@gmail.com
> mobile: (832) 264-2646
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

[openstack-dev] Capturing Feedback/Input

[Melvin Hillsman]

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.

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

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Melvin Hillsman]

 I agree all lists should be merged as discussed otherwise why not just
leave all things as they are :P

On Thu, Sep 20, 2018 at 4:49 PM Emilien Macchi  wrote:

>
>
> On Thu, Sep 20, 2018 at 5:47 PM Doug Hellmann 
> wrote:
>
>> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
>> > tl;dr: The openstack, openstack-dev, openstack-sigs and
>> > openstack-operators mailing lists (to which this is being sent) will
>> > be replaced by a new openstack-disc...@lists.openstack.org mailing
>> > list.
>>
>> Since last week there was some discussion of including the openstack-tc
>> mailing list among these lists to eliminate confusion caused by the fact
>> that the list is not configured to accept messages from all subscribers
>> (it's meant to be used for us to make sure TC members see meeting
>> announcements).
>>
>> I'm inclined to include it and either use a direct mailing or the
>> [tc] tag on the new discuss list to reach TC members, but I would
>> like to hear feedback from TC members and other interested parties
>> before calling that decision made. Please let me know what you think.
>>
>
> +2 , easier to manage, easier to reach out.
> --
> 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
>


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

Re: [openstack-dev] [neutron] Core status

[Bhatia, Manjeet S]

Good luck for new role !

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Wednesday, September 19, 2018 11:20 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] Core status

Hi,
I have recently transitioned to a new role where I will be working on other 
parts of OpenStack. Sadly I do not have the necessary cycles to maintain my 
core responsibilities in the neutron community. Nonetheless I will continue to 
be involved.
Thanks
Gary
__
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! (was: Bringing the community together...)

[Emilien Macchi]

On Thu, Sep 20, 2018 at 5:47 PM Doug Hellmann  wrote:

> Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
> > tl;dr: The openstack, openstack-dev, openstack-sigs and
> > openstack-operators mailing lists (to which this is being sent) will
> > be replaced by a new openstack-disc...@lists.openstack.org mailing
> > list.
>
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
>
> I'm inclined to include it and either use a direct mailing or the
> [tc] tag on the new discuss list to reach TC members, but I would
> like to hear feedback from TC members and other interested parties
> before calling that decision made. Please let me know what you think.
>

+2 , easier to manage, easier to reach out.
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +:
> tl;dr: The openstack, openstack-dev, openstack-sigs and
> openstack-operators mailing lists (to which this is being sent) will
> be replaced by a new openstack-disc...@lists.openstack.org mailing
> list.

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

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

Doug

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

[openstack-dev] [StoryBoard] PTG Summary

[Kendall Nelson]

Hello Lovers of Task Tracking!

So! We talked about a lot of things, and I went to a lot of rooms to talk
about StoryBoard related things and it was already a week ago so bear with
me.

We had a lot of good discussions as we were able to include SotK in
discussions via videocalling. We also had the privilege of our outreachy
intern to come all the way from Cairo to Denver to join us :)

Onto the summaries!

Story Attachments

==

This topic has started coming up with increasing regularity. Currently,
StoryBoard doesn’t support attachments, but it’s a feature that several
projects claim to be blocking their migration. The current work around is
either to trim down logs and paste the relevant section, or to host the
file elsewhere and link to its location. After consulting with the
infrastructure team, we concluded that currently, there is no donated
storage. The next step is for me to draft a spec detailing our requirements
and implementation details and then to include infra on the review to help
them have something concrete to go to vendors with. For notes on the
proposed method see the etherpad[1].

One other thing discussed during this topic was how we could maybe migrate
the current attachments. This isn’t supported by the migration script at
this point, but it’s something we could write a separate script for. It
should be separate because it would be a painfully slow process and we
wouldn’t want to slow down the migration script more than it already is by
the Launchpad API. The attachments script would be run after the initial
migration; that being said, everything still persists in Launchpad so
things can still be referenced there.

Handling Duplicate Stories



This is also an ongoing topic for discussion. Duplicate stories if not
handled properly could dilute the database as we get more projects migrated
over. The plan we settled on is to add a ‘Mark as Duplicate’ button to the
webclient and corresponding functions to the API. The user would be
prompted for a link to the master story. The master story would get a new
timeline event that would have the link to the duplicate and the duplicate
story would have all tasks auto marked as invalid (aside from those marked
as merged) so that the story then shows as inactive. The duplicate story
could also get a timeline event that explains what happened and links to
the master story. I’ve yet to create a story for all of this, but it’s on
my todo list.

Handling Thousands of Comments Per Story

==

There’s this special flower story[2] that has literally thousands of
comments on it because of all of the gerrit comments being added to the
timeline for all the patches for all the tasks. Rendering of the timeline
portion of the webpage in the webclient is virtually impossible. It will
load the tasks and then hang forever. The discussion around this boiled
down to this: other task trackers also can’t handle this and there is a
better way to divvy up the story into several stories and contain them in a
worklist for future, similar work. For now, users can select what they want
to load in their timeline views for stories, so by unmarking all of the
timeline events in their preferences, the story will load completely sans
timeline details. Another solution we discussed to help alleviate the
timeline load on stories with lots of tasks is to have a task field that
links to the review, rather than a comment from gerrit every time a new
patch gets pushed. Essentially we want to focus on cleaning up the timeline
rather than just going straight to a pagination type of solution. It was
also concluded that we want to add another user preference for page sizes
of 1000. Tasks have not been created in the story related to this issue
yet[3], but its on my todo list.

Project Group Descriptions

=

There was a request to have project group descriptions, but currently there
is nothing in the API handling this. Discussion concluded with agreement
that this shouldn’t be too difficult. All that needs to happen is a few
additions to the API and the connection to managing group definitions in
project-config. I still need to make a story for this.

Translating storyboard-webclient

=

There was an infrastructure mailing list thread a little while back that
kicked off discussion on this topic. It was received as an interesting idea
and could help with the adoption of StoryBoard outside of OpenStack. The
biggest concern was communicating to users that are seeing the webclient
rendered in some other language that they still need to create
tasks/stories/worklists/boards in English or whatever the default language
is for the organization that is hosting StoryBoard. This could be a banner
when someone logs in, or something on user’s dashboards. One of the things
that needs to happen first is to find libraries for javascript and angular
for signaling what strings need to be translated.

[openstack-dev] [vitrage][ptg] Vitrage virtual PTG

[Ifat Afek]

Hi,

We will hold the Vitrage virtual PTG on October 10-11th.
You are welcome to join and suggest topics for discussion in the PTG
etherpad[1].

Thanks,
Ifat

[1] https://etherpad.openstack.org/p/vitrage-stein-ptg
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Denver Ops Meetup post-mortem

[Chris Morgan]

The issue I ran into with IRC was a bit more obscure. "real IRC" is
entirely blocked from all networks provided to me by my employer (even the
office wifi).

The web interface I was using (irccloud) didn't work for nickname
registration either.

When trying real (non-web-wrapped) IRC from my laptop via an LTE hotspot it
also failed. We eventually worked out that it's because Freenode has
blacklisted large IP ranges including my AT&T service.

Can't connect unless authenticated, can't register nickname for auth
because not connected.

The answer in that case is to register the nickname on
http://webchat.freenode.net

This "chicken and egg" problem is explained here:
https://superuser.com/questions/1220409/irc-how-to-register-on-freenode-using-hexchat-when-i-get-disconnected-immediat

Chris

On Thu, Sep 20, 2018 at 12:18 AM Kendall Nelson 
wrote:

> Hello!
>
> On Tue, Sep 18, 2018 at 12:36 PM Chris Morgan  wrote:
>
>>
>>
>> -- Forwarded message -
>> From: Chris Morgan 
>> Date: Tue, Sep 18, 2018 at 2:13 PM
>> Subject: Denver Ops Meetup post-mortem
>> To: OpenStack Operators 
>>
>>
>>  Hello All,
>>   Last week we had a successful Ops Meetup embedded in the OpenStack
>> Project Team Gathering in Denver.
>>
>> Despite generally being a useful gathering, there were definitely lessons
>> learned and things to work on, so I thought it would be useful to share a
>> post-mortem. I encourage everyone to share their thoughts on this as well.
>>
>> What went well:
>>
>> - some of the sessions were great and a lot of progress was made
>> - overall attendance in the ops room was good
>> - more developers were able to join the discussions
>> - facilities were generally fine
>> - some operators leveraged being at PTG to have useful involvement in
>> other sessions/discussions such as Keystone, User Committee, Self-Healing
>> SIG, not to mention the usual "hallway conversations", and similarly some
>> project devs were able to bring pressing questions directly to operators.
>>
>> What didn't go so well:
>>
>> - Merging into upgrade SIG didn't go particularly well
>> - fewer ops attended (in particular there were fewer from outside the US)
>> - Some of the proposed sessions were not well vetted
>> - some ops who did attend stated the event identity was diluted, it was
>> less attractive
>> - we tried to adjust the day 2 schedule to include late submissions,
>> however it was probably too late in some cases
>>
>> I don't think it's so important to drill down into all the whys and
>> wherefores of how we fell down here except to say that the ops meetups team
>> is a small bunch of volunteers all with day jobs (presumably just like
>> everyone else on this mailing list). The usual, basically.
>>
>> Much more important : what will be done to improve things going forward:
>>
>> - The User Committee has offered to get involved with the technical
>> content. In particular to bring forward topics from other relevant events
>> into the ops meetup planning process, and then take output from ops meetups
>> forward to subsequent events. We (ops meetup team) have welcomed this.
>>
>> - The Ops Meetups Team will endeavor to start topic selection earlier and
>> have a more critical approach. Having a longer list of possible sessions
>> (when starting with material from earlier events) should make it at least
>> possible to devise a better agenda. Agenda quality drives attendance to
>> some extent and so can ensure a virtuous circle.
>>
>> - We need to work out whether we're doing fixed schedule events (similar
>> to previous mid-cycle Ops Meetups) or fully flexible PTG-style events, but
>> grafting one onto the other ad-hoc clearly is a terrible idea. This needs
>> more discussion.
>>
>> - The Ops Meetups Team continues to explore strange new worlds, or at
>> least get in touch with more and more OpenStack operators to find out what
>> the meetups team and these events could do for them and hence drive the
>> process better. One specific work item here is to help the (widely
>> disparate) operator community with technical issues such as getting setup
>> with the openstack git/gerrit and IRC. The latter is the preferred way for
>> the community to meet, but is particularly difficult now with the
>> registered nickname requirement. We will add help documentation on how to
>> get over this hurdle.
>>
>
> After you get onto freenode at IRC you can register your nickname with a
> single command and then you should be able to join any of the channels. The
> command you need: ' /msg nickserv register $PASSWORD $EMAIL_ADDRESS'. You
> can find more instructions here about setting up IRC[1].
>
> If you get stuck or have any questions, please let me know! I am happy to
> help with the setup of IRC or gerrit or anything else that might be a
> barrier.
>
>
>> - YOUR SUGGESTION HERE
>>
>> Chris
>>
>> --
>> Chris Morgan 
>>
>>
>> --
>> Chris Morgan 
>> __
>> OpenStac

Re: [openstack-dev] [docs] Nominating Ian Y. Choi for openstack-doc-core

[Melvin Hillsman]

++

On Thu, Sep 20, 2018 at 3:11 PM Frank Kloeker  wrote:

> Am 2018-09-19 20:54, schrieb Andreas Jaeger:
> > On 2018-09-19 20:50, Petr Kovar wrote:
> >> Hi all,
> >>
> >> Based on our PTG discussion, I'd like to nominate Ian Y. Choi for
> >> membership in the openstack-doc-core team. I think Ian doesn't need an
> >> introduction, he's been around for a while, recently being deeply
> >> involved
> >> in infra work to get us robust support for project team docs
> >> translation and
> >> PDF builds.
> >>
> >> Having Ian on the core team will also strengthen our integration with
> >> the i18n community.
> >>
> >> Please let the ML know should you have any objections.
> >
> > The opposite ;), heartly agree with adding him,
> >
> > Andreas
>
> ++
>
> Frank
>
>
> __
> 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
>


-- 
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] [glance] replace locations on queued image

[iain macdonnell]

I feel like I've been chasing this issue around in circles for months,
and I need the core team to make a decision. I cannot proceed with
Rocky deployment/upgrade until this gets resolved.

It's currently possible to add to, or completely replace, the
"locations" for an image with status "queued", using HTTP PATCH. Prior
to the following fix, the "add" operation would update the status to
"active", but the "replace" operation would leave it in "queued"
status, with no way to get it out of that status (other than delete).
I thought that we agreed that that was a bug, which I submitted a fix
for:

https://review.openstack.org/592775

I don't see any API breakage from this fix. The previous state left
the image in permanently unusable state. I can't see any valid
use-case for that.

Now (this morning's meeting) it seems like we're back to debating
whether or not it's valid to "replace" "locations" for an image in
"queued" status. My interpretation of "replace" is "I want it to look
exactly like this, regardless of what's there now", as opposed to
"add", which means "append this to whatever is currently there".

If it's not valid to "replace" "locations" for an image in "queued"
status, I think that the API should reject the request, not leave the
image in limbo ('queued') status. I'm OK with that - I can use "add" -
but I'll need to update this:

https://review.openstack.org/597648

to apply only to "add".

glance core team, please make the decision.

Thanks,

~iain (slightly frustrated)

__
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] Nominating Ian Y. Choi for openstack-doc-core

[Frank Kloeker]

Am 2018-09-19 20:54, schrieb Andreas Jaeger:

On 2018-09-19 20:50, Petr Kovar wrote:

Hi all,

Based on our PTG discussion, I'd like to nominate Ian Y. Choi for
membership in the openstack-doc-core team. I think Ian doesn't need an
introduction, he's been around for a while, recently being deeply 
involved
in infra work to get us robust support for project team docs 
translation and

PDF builds.

Having Ian on the core team will also strengthen our integration with
the i18n community.

Please let the ML know should you have any objections.


The opposite ;), heartly agree with adding him,

Andreas


++

Frank


__
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] [os-upstream-institute][all] Upstream Institute training call for mentors!!

[Ildiko Vancsa]

Hi,

We have two Upstream Institute trainings [1] upcoming and we are looking for 
mentors to join us and help new contributors to start their journey in 
OpenStack.

We have a training in Stockholm on October 9 and one in Berlin right before the 
Summit on November 11-12. If you are available for each or both of these 
occasions and interested to join our crew please sign up on our wiki page [2].

If you have any questions please reply to this thread or reach out to the team 
on the #openstack-upstream-institute IRC channel.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

[1] https://docs.openstack.org/upstream-training/#upcoming-trainings
[2] https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions
__
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][api] POST /api-sig/news

[Ed Leafe]

Greetings OpenStack community,

This newsletter is very different than the past few, in that there is some 
actual news.

We, as a SIG, have recognized that we have moved into a new phase. With most of 
the API guidelines that we needed to write having been written, there is not 
"new stuff" to make demands on our time. In recognition of this, we are 
changing how we will work.

Next Thursday, Sept 27, will be our last formal IRC meeting [7] in 
#openstack-meeting-3; after that we will switch to an "office hours" format, 
where API-SIG members will be available in the #openstack-sdks channel. We will 
have at least two office hours scheduled per week, to allow for more 
participation across time zones. We will discuss that schedule at next week's 
meeting, so if you have any preferences on this, either attend that meeting, or 
reply to this email, so that we can make a schedule that works well for most 
people. We will also discontinue this weekly newsletter, and instead only send 
it when something of note needs to be shared with the wider community.

On a note, one of the biggest contributors to the SIG, Chris Dent (cdent), has 
finally realized that he is spread much too thinly these days, and needs to 
pull back from so many things demanding his time. So while he won't be as 
active in the group as before, I'm sure he'll be keeping an eye on the rest of 
us to make sure we don't mess things up too badly. So for all your good work, 
Chris, we say "Huzzah!".

If you're interested in helping out, here are some things to get you started:

* The list of bugs [5] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [6] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [6].

# Newly Published Guidelines

* None

# API Guidelines Proposed for Freeze

* None

# Guidelines that are ready for wider review by the whole community.

* None

# Guidelines Currently Under Review [3]

* Add an api-design doc with design advice
  https://review.openstack.org/592003

* Update parameter names in microversion sdk spec
  https://review.openstack.org/#/c/557773/

* Add API-schema guide (still being defined)
  https://review.openstack.org/#/c/524467/

* Version and service discovery series
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the 
OpenStack developer mailing list[1] with the tag "[api]" in the subject. In 
your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-sig,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] https://storyboard.openstack.org/#!/project/1039
[6] https://git.openstack.org/cgit/openstack/api-sig
[7] http://eavesdrop.openstack.org/#API_Special_Interest_Group

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

-- Ed Leafe






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

[Elõd Illés]

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


On 2018-09-18 21:27, Matt Riedemann wrote:
The release page says Ocata is planned to go into extended maintenance 
mode on Aug 27 [1]. There really isn't much to this except it means we 
don't do releases for Ocata anymore [2]. There is a caveat that 
project teams that do not wish to maintain stable/ocata after this 
point can immediately end of life the branch for their project [3]. We 
can still run CI using tags, e.g. if keystone goes ocata-eol, devstack 
on stable/ocata can still continue to install from stable/ocata for 
nova and the ocata-eol tag for keystone. Having said that, if there is 
no undue burden on the project team keeping the lights on for 
stable/ocata, I would recommend not tagging the stable/ocata branch 
end of life at this point.


So, questions that need answering are:

1. Should we cut a final release for projects with stable/ocata 
branches before going into extended maintenance mode? I tend to think 
"yes" to flush the queue of backports. In fact, [3] doesn't mention 
it, but the resolution said we'd tag the branch [4] to indicate it has 
entered the EM phase.


2. Are there any projects that would want to skip EM and go directly 
to EOL (yes this feels like a Monopoly question)?


[1] https://releases.openstack.org/
[2] 
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3] 
https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[4] 
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life






__
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] Release countdown for week R-28 and R-27, September 24 - October 5

[Sean McGinnis]

Welcome to the release countdown email. I am going to keep these biweekly for
now since there are not as many critical deadlines, but please let me know if
any more frequent or additional updates would be useful.

Development Focus
-

Team focus should be on spec approval and implementation of priority features.

Action Required
--

Matt Riedemann started a thread about the Ocata release entering the new
"extended maintenance" phase:


http://lists.openstack.org/pipermail/openstack-dev/2018-September/134810.html

We are actually past the published date for that transition, but this is the
first time we've done this, so I think we're all working through the process.
Matt raises the good point that any teams that have merged patches for
stable/ocata that would like to have those officially available should do a
final stable release off of stable/ocata.

After that, as part of extended maintenance, teams can choose how they handle
further stable backports, but there will no longer we official releases from
stable/ocata.

General Information
---

Please be aware of the project specific deadlines that vary slightly from the
overall release schedule [1].

Teams should now be making progress towards the cycle goals [2]. Please
prioritize reviews for these appropriately. 

[1] https://releases.openstack.org/stein/schedule.html
[2] https://governance.openstack.org/tc/goals/stein/index.html

If your project has a library that is still a 0.x release, start thinking about
when it will be appropriate to do a 1.0 version. The version number does signal
the state, real or perceived, of the library, so we strongly encourage going to
a full major version once things are in a good and usable state.

PTLs and/or release liaisons - we are still a little ways out from the first
milestone, but a reminder that we would love to have you around during our
weekly meeting [3]. It would also be very helpful if you would linger in the
#openstack-release channel during deadline weeks.

[3] http://eavesdrop.openstack.org/#Release_Team_Meeting

Upcoming Deadlines & Dates
--

Stein-1 milestone: October 25  (R-24 week)
Forum at OpenStack Summit in Berlin: November 13-15

-- 
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] [neutron] Core status

[Miguel Lavalle]

Hi Gary,

As I say during our private conversation, we don't like to see you going,
but we understand that you have other career opportunities. I wish you luck
in your next challenge and please remember that you will always be welcome
here

Best regards

Miguel

On Thu, Sep 20, 2018 at 9:49 AM Brian Haley  wrote:

> On 09/19/2018 02:19 PM, Gary Kotton wrote:
> > Hi,
> >
> > I have recently transitioned to a new role where I will be working on
> > other parts of OpenStack. Sadly I do not have the necessary cycles to
> > maintain my core responsibilities in the neutron community. Nonetheless
> > I will continue to be involved.
>
> Thanks for all your work over the years, especially in keeping the
> reviews moving along on the neutron stable branches.  Good luck in your
> new role!
>
> -Brian
>
> __
> 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] Nominating Luis Tomás Bolívar for kuryr-kubernetes core

[Daniel Mellado]

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!

Thanks!

Daniel


0x13DDF774E05F5B85.asc
Description: application/pgp-keys


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

[openstack-dev] [all] We're combining the lists! (was: Bringing the community together...)

[Jeremy Stanley]

tl;dr: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. Now on to the details...

The original proposal[1] I cross-posted to these lists in August
received overwhelmingly positive feedback (indeed only one strong
objection[2] was posted, thanks Thomas for speaking up, and my
apologies in advance if this makes things less convenient for you),
which is unusual since our community usually tends to operate on
silent assent and tacit agreement. Seeing what we can only interpret
as majority consensus for the plan among the people reading messages
posted to these lists, a group of interested individuals met last
week in the Infrastructure team room at the PTG to work out the
finer details[3]. We devised a phased timeline:

During the first phase (which begins with this announcement) the new
openstack-discuss mailing list will accept subscriptions but not
posts. Its short and full descriptions indicate this, as does the
welcome message sent to all new subscribers during this phase. The
list is configured for "emergency moderation" mode so that all
posts, even those from subscribers, immediately land in the
moderation queue and can be rejected with an appropriate message. We
strongly recommend everyone who is on any of the current general
openstack, openstack-dev, openstack-operators and openstack-sigs
lists subscribe to openstack-discuss during this phase in order to
avoid missing any messages to the new list. Phase one lasts roughly
one month and ends on Monday November 19, just after the OpenStack
Stein Summit in Berlin.

The second phase picks up at the end of the first. During this
phase, emergency moderation is no longer in effect and subscribers
can post to the list normally (non-subscribers are subject to
moderation of course in order to limit spam). Any owners/moderators
from the original lists who wish it will be added to the new one to
collaborate on moderation tasks. At this time the openstack-discuss
list address itself will be subscribed to posts from the openstack,
openstack-dev, openstack-operators and openstack-sigs mailing lists
so anyone who wishes to unsubscribe from those can do so at any time
during this phase without missing any replies sent there. The list
descriptions and welcome message will also be updated to their
production prose. Phase two runs for two weeks ending on Monday
December 3.

The third and final phase begins at the end of the second, when
further posts to the general openstack, openstack-dev,
openstack-operators and openstack-sigs lists will be refused and the
descriptions for those lists updated to indicate they're
indefinitely retired from use. The old archives will still be
preserved of course, but no new content will appear in them.

A note about DMARC/DKIM: during the planning discussion we also
spoke briefly about the problems we encounter on the current lists
whereby subscriber MTAs which check DKIM signatures appearing in
some posts reject them and cause those subscribers to get
unsubscribed after too many of these bounces. While reviewing the
various possible mitigation options available to us, we eventually
resolved that the least objectionable solution was to cease
modifying the list subject and body. As such, for the new
openstack-discuss list you won't see [openstack-discuss] prepended
to message subjects, and there will be no list footer block added to
the message body. Rest assured the usual RFC 2369 List-* headers[4]
will still be added so MUAs can continue to take filtering actions
based on them as on our other lists.

I'm also including a couple of FAQs which have come up over the
course of this...

Why make a new list instead of just directing people to join an
existing one such as the openstack general ML? For one, the above
list behavior change to address DMARC/DKIM issues is a good reason
to want a new list; making those changes to any of the existing
lists is already likely to be disruptive anyway as subscribers may
be relying on the subject mangling for purposes of filtering list
traffic. Also as noted earlier in the thread for the original
proposal, we have many suspected defunct subscribers who are not
bouncing (either due to abandoned mailboxes or MTAs black-holing
them) so this is a good opportunity to clean up the subscriber list
and reduce the overall amount of E-mail unnecessarily sent by the
server.

Why not simply auto-subscribe everyone from th

Re: [openstack-dev] Forum Topic Submission Period

[Matt Riedemann]

On 9/20/2018 10:23 AM, Jimmy McArthur wrote:
This is basically the CFP equivalent: 
https://www.openstack.org/summit/berlin-2018/vote-for-speakers  Voting 
isn't necessary, of course, but it should allow you to see submissions 
as they roll in.


Does this work for your purposes?


Yup, that should do it, thanks!

--

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

[Jimmy McArthur]

Matt,

Another good question...

Matt Riedemann wrote:

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



SNIP


Another question. In the before times, when we just had that simple 
form to submit forum sessions and then the TC/UC/Foundation reviewed 
the list and picked the sessions, it was very simple to see what other 
sessions were proposed and say, "oh good someone is covering this 
already, I don't need to worry about it". With the move to the CFP 
forms like the summit sessions, that is no longer available, as far as 
I know. There have been at least a few cases this week where someone 
has said, "this might be a good topic, but keystone is probably 
already covering it, or $FOO SIG is probably already covering it", but 
without herding the cats to ask and find out who is all doing what, 
it's hard to know.


Is there some way we can get back to having a public view of what has 
been proposed for the forum so we an avoid overlap, or at worst not 
proposing something because people assume someone else is going to 
cover it?
This is basically the CFP equivalent: 
https://www.openstack.org/summit/berlin-2018/vote-for-speakers  Voting 
isn't necessary, of course, but it should allow you to see submissions 
as they roll in.


Does this work for your purposes?

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

Re: [openstack-dev] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

[Matt Riedemann]

On 9/20/2018 4:16 AM, John Garbutt wrote:
Following on from the PTG discussions, I wanted to bring everyone's 
attention to Nova's plans to deprecate ComputeCapabilitiesFilter, 
including most of the the integration with Ironic Capabilities.


To be specific, this is my proposal in code form:
https://review.openstack.org/#/c/603102/

Once the code we propose to deprecate is removed we will stop using 
capabilities pushed up from Ironic for 'scheduling', but we would still 
pass capabilities request in the flavor down to Ironic (until we get 
some standard traits and/or deploy templates sorted for things like UEFI).


Functionally, we believe all use cases can be replaced by using the 
simpler placement traits (this is more efficient than post placement 
filtering done using capabilities):

https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/ironic-driver-traits.html

Please note the recent addition of forbidden traits that helps improve 
the usefulness of the above approach:

https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-forbidden-traits.html

For example, a flavor request for GPUs >= 2 could be replaced by a 
custom trait trait that reports if a given Ironic node has 
CUSTOM_MORE_THAN_2_GPUS. That is a bad example (longer term we don't 
want to use traits for this, but that is a discussion for another day) 
but it is the example that keeps being raised in discussions on this topic.


The main reason for reaching out in this email is to ask if anyone has 
needs that the ResourceClass and Traits scheme does not currently 
address, or can think of a problem with a transition to the newer approach.


I left a few comments in the change, but I'm assuming as part of the 
deprecation we'd remove the filter from the default enabled_filters list 
so new installs don't automatically get warnings during scheduling?


Another thing is about existing flavors configured for these 
capabilities-scoped specs. Are you saying during the deprecation we'd 
continue to use those even if the filter is disabled? In the review I 
had suggested that we add a pre-upgrade check which inspects the flavors 
and if any of these are found, we report a warning meaning those flavors 
need to be updated to use traits rather than capabilities. Would that be 
reasonable?


--

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] [neutron] Core status

[Brian Haley]

On 09/19/2018 02:19 PM, Gary Kotton wrote:

Hi,

I have recently transitioned to a new role where I will be working on 
other parts of OpenStack. Sadly I do not have the necessary cycles to 
maintain my core responsibilities in the neutron community. Nonetheless 
I will continue to be involved.


Thanks for all your work over the years, especially in keeping the 
reviews moving along on the neutron stable branches.  Good luck in your 
new role!


-Brian

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

Re: [openstack-dev] Forum Topic Submission Period

[Matt Riedemann]

On 9/17/2018 11:13 AM, Jimmy McArthur wrote:
The Forum Topic Submission session started September 12 and will run 
through September 26th.  Now is the time to wrangle the topics you 
gathered during your Brainstorming Phase and start pushing forum topics 
through. Don't rely only on a PTL to make the agenda... step on up and 
place the items you consider important front and center.


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


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

Looking forward to seeing everyone's submissions!

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


Another question. In the before times, when we just had that simple form 
to submit forum sessions and then the TC/UC/Foundation reviewed the list 
and picked the sessions, it was very simple to see what other sessions 
were proposed and say, "oh good someone is covering this already, I 
don't need to worry about it". With the move to the CFP forms like the 
summit sessions, that is no longer available, as far as I know. There 
have been at least a few cases this week where someone has said, "this 
might be a good topic, but keystone is probably already covering it, or 
$FOO SIG is probably already covering it", but without herding the cats 
to ask and find out who is all doing what, it's hard to know.


Is there some way we can get back to having a public view of what has 
been proposed for the forum so we an avoid overlap, or at worst not 
proposing something because people assume someone else is going to cover it?


--

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-I18n] [docs][i18n][ptg] Stein PTG Summary

[Cloud Suhartono]

Hi Ian,
You show us the Indonesian translations at the [1][2][3][4][5].
Thank you very much
/Suhartono

[1] https://www.openstack.org/user-survey/survey-2018/landing?lang=id_ID
[2]
https://www.openstack.org/edge-computing/cloud-edge-computing-beyond-the-data-center
[3]
https://www.openstack.org/containers/leveraging-containers-and-openstack/
[4] https://docs.openstack.org/id/
[5] https://docs.openstack.org/i18n/latest/id/release_management.html

Pada tanggal Kam, 20 Sep 2018 pukul 11.09 Ian Y. Choi 
menulis:

> Thanks a lot for nice summary on Docs part especially!
> I would like to add an additional summary with more context from I18n
> perspective.
>
> Note: I mainly participated in Docs/I18n discussion only on Monday &
> Tuesday
> (not available during Wed - Fri due to conflicts with other work in my
> country),
> and my summary would be different from current I18n PTL if he have
> parcipated in Stein PTG,
> but I would like to summarize as I18n ex-PTL (Ocata, Pike) and as one of
> active partcipants in Docs/I18n discussion.
>
> Documentation & I18n teams started to have collaborative discussions
> from Pike PTG.
> Following with Queens & Rocky cycle, I am so happy that Documentation &
> I18n teams had tight collaboration
> again at Stein PTG for horizontal discussion with sharing issues and
> tight collaboration.
>
> More details for I18n issues are available at the bottom part ("i18n
> Topics") in:
> https://etherpad.openstack.org/p/docs-i18n-ptg-stein
>
> PROJECT DOCUMENTATION TRANSLATION SUPPORT
>
> This year, I18n team actively started to support project documentation
> translation [1] and there had progress
> on defining documentation translation targets, generatepot infra jobs,
> and translation sync on from project repositories to
> Zanata for translation sources & from Zanata to project repositories for
> translated strings.
> [2] and [3] are parts of work I18n team did on previous cycle, and the
> final part would be how to support translated documentation publication
> aligned with Documentation team, since PDF support implementation is
> also related with how to publish PDF files for project repositories.
>
> Although there were so nice discussion during last Vancouver Summit [4],
> more generic idea on infra side how to better support translated
> documentation & PDF builds and translation
> would be needed after some changes on Project Testing Interface which is
> used for project documentation builds [5].
>
> [6] is a nice summary from Doug (really appreciated!) for the direction
> and plans on PDF and translation builds
> by making use of openstack-tox-docs job [7], and I18n team would like to
> continue to work with Documentation
> and Infrastructure teams on actual implementation suring Stein cycle.
>
> USER SURVEY, TRANSLATING WHITEPAPERS, AND RECOGNITION ON TRANSLATORS
>
> With nice collaboration between Foundation and I18n team, I18n team
> started to translate
> OpenStack user survey [8] after initial discussion on Pike PTG and, edge
> computing whitepaper [9],
> and container whitepaer [10] into multiple languages with many language
> coordinators and translators.
>
> Those translation effort might be different from Active Technical
> Contributor (ATC) recognition
> which translators also got for OpenStack project translation and
> techical documentation translation [11].
> Some translators shared that they would be interested in translating
> technical documents but not interested in
> OpenStack user survey and other non-technical documents.
>
> I thought that it might be due to different governance (Foundation-led &
> official projects with technical committee might be different),
> and Active User Contributor (AUC) [12] recognition might be a good idea.
> Although I could not discuss in details with User Committee members
> during PTG,
> Foundation agreed that AUC recognition for such translators would be a
> good idea and Melvin,
> one of user committee agreed with the idea during a very short
> conversation.
> In my opinion, it would take some time for more discussion and agreement
> on detail criteria
> (e.g., which number of words might be good aligning with current AUC
> recognition criteria), User Committee, and Foundation),
> but let's try to move forward on this :)
>
> Also, documentation on detail steps and activities with user survey on
> further years and more on whitepapers
> would be important, so I18n team will more document how I18n team
> members do action with steps like [13].
>
> And some translators shared concerns what there is no I18n in OpenStack
> project navigator and map.
> It would be also related with recognition on what translators contributed.
> Foundation explained that it might be the intention of the purpose of
> each artifact
> (e.g., OpenStack were designed to show OpenStack components and how
> those components interact each other with technical perspective),
> and Foundation shared that Foundation would do best to aggregate
> scattered defini

Re: [openstack-dev] [placement] [infra] [qa] tuning some zuul jobs from "it works" to "proper"

[Matthew Treinish]

On Thu, Sep 20, 2018 at 10:55:31AM +0200, Luigi Toscano wrote:
> On Thursday, 20 September 2018 04:47:20 CEST Matthew Treinish wrote:
> > On Thu, Sep 20, 2018 at 11:11:12AM +0900, Ghanshyam Mann wrote:
> > >   On Wed, 19 Sep 2018 23:29:46 +0900 Monty Taylor
> > >   wrote >  
> > >  > On 09/19/2018 09:23 AM, Monty Taylor wrote:
> > >  > > On 09/19/2018 08:25 AM, Chris Dent wrote:
> > >  > >> I have a patch in progress to add some simple integration tests to
> > >  > >> 
> > >  > >> placement:
> > >  > >>  https://review.openstack.org/#/c/601614/
> > >  > >> 
> > >  > >> They use https://github.com/cdent/gabbi-tempest . The idea is that
> > >  > >> the method for adding more tests is to simply add more yaml in
> > >  > >> gate/gabbits, without needing to worry about adding to or think
> > >  > >> about tempest.
> > >  > >> 
> > >  > >> What I have at that patch works; there are two yaml files, one of
> > >  > >> which goes through the process of confirming the existence of a
> > >  > >> resource provider and inventory, booting a server, seeing a change
> > >  > >> in allocations, resizing the server, seeing a change in allocations.
> > >  > >> 
> > >  > >> But this is kludgy in a variety of ways and I'm hoping to get some
> > >  > >> help or pointers to the right way. I'm posting here instead of
> > >  > >> asking in IRC as I assume other people confront these same
> > >  > >> confusions. The issues:
> > >  > >> 
> > >  > >> * The associated playbooks are cargo-culted from stuff labelled
> > >  > >> 
> > >  > >>"legacy" that I was able to find in nova's jobs. I get the
> > >  > >>impression that these are more verbose and duplicative than they
> > >  > >>need to be and are not aligned with modern zuul v3 coolness.
> > >  > > 
> > >  > > Yes. Your life will be much better if you do not make more legacy
> > >  > > jobs.
> > >  > > They are brittle and hard to work with.
> > >  > > 
> > >  > > New jobs should either use the devstack base job, the
> > >  > > devstack-tempest
> > >  > > base job or the devstack-tox-functional base job - depending on what
> > >  > > things are intended.
> > > 
> > > +1. All the base job from Tempest and Devstack (except grenade which is in
> > > progress) are available to use as base for legacy jobs. Using
> > > devstack-temepst in your patch is right things. In addition, you need to
> > > mention the tox_envlist as all-plugins to make tempest_test_regex work. I
> > > commented on review.
> > No, all-plugins is incorrect and should never be used. It's only there for
> > legacy support, it is deprecated and I thought we pushed a patch to
> > indicating that (but I can't find it).
> 
> This one?
> https://review.openstack.org/#/c/543974/
> 

Yep, that's the one I was thinking of.


Thanks,

Matt Treinish


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] [monasca] Berlin Forum brainstorming

[Bedyk, Witold]

Hi everyone,

As discussed in the team meeting yesterday I've created a brainstorming 
etherpad [1] for the Forum in Berlin.
Please add your ideas and add your name to the list if you're interested in 
participating.

Thanks
Witek

[1] https://etherpad.openstack.org/p/berlin-monasca-forum-brainstorming

__
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] noop role in openstack

[Lance Bragstad]

On Thu, Sep 20, 2018 at 12:22 AM Adrian Turjak 
wrote:

> For Adam's benefit continuing this a bit in email:
>
> regarding the noop role:
>
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43
>
> The first benefit of such a role (in the given policy scenario) is that
> you can now give a user explicit scope on a project (but they can't do
> anything) and then use that role for Swift ACLs with full knowledge they
> can't do anything other than auth, scope to the project, and then
> whatever the ACLs let them do. An example use case being: "a user that
> can ONLY talk to a specific container and NOTHING else in OpenStack or
> Swift" which is really useful if you want to use a single project for a
> lot of websites, or backups, or etc.
>
> Or in my MFA case, a role I can use when wanting a user to still be able
> to auth and setup their MFA, but not actually touch any resources until
> they have MFA setup at which point you give them back their real member
> role.
>
> It all relies on leaving no policy rules 'empty' unless those rules (and
> their API) really are safe for a noop role. And by empty I don't mean
> empty, really I mean "any role on a project". Because that's painful to
> then work with.
>
> With the default policies in Nova (and most other projects), you can't
> actually make proper use of Swift ACLs, because having any role on a
> project gives you access to all the resources. Like say:
> https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31
>
> ^ that rule implies, if you are scoped to the project, don't care about
> the role, you can do anything to the resources. That doesn't work for
> anything role specific. Such rules would need to be:
> "is_admin:True or (role:member and project_id:%(project_id)s)"
>
> If we stop with this assumption that "any role" on a project works,
> suddenly policy becomes more powerful and the roles are actually useful
> beyond admin vs not admin. System scope will help, but then we'll still
> only have system scope, admin on a project, and not admin on a project,
> which still makes the role mostly pointless.
>

Kind of. System-scope is only half the equation for fixing RBAC because it
gives developers an RBAC target that isn't project-scoped that they can use
to protect APIs with. When you combine that with default roles (admin,
member, and reader) [0] then you can start building a matrix, per se.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html


>
> We as a community need to stop with this assumption (that "any role" on
> a project works), because it hurts us in regards to actually useful
> RBAC. Yes deployers can edit the policy to avoid the any role on a
> project issue (we have), but it's a huge amount of work to figure out
> that we could all work together and fix upstream.
>

As I'm sure you know, even rolling custom policy files might not be enough.
Despite an override, there are APIs that still check for 'admin' roles.


>
> Part of that work is actually happening. With the default roles that
> Keystone is defining, and system scope. We can then start updating all
> the project default policies to actually require those roles explicitly,
> but that effort, needs us to get everyone on board...
>

That's the idea. We're trying to build that out in keystone now so that
other projects have a template to follow.


>
>
> __
> 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] Clearing up the gate

[Juan Antonio Osorio Robles]

We've been having a lot of timeouts and the gate is stacking up. I'm
purging out patches from the gate in order to reduce used resources
while this is sorted out.

Please do not merge patches until this issue is sorted out.


BR


__
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] manila core team cleanup

[Tom Barron]

Mark Sturdevant recently contacted me to say that due to changes in 
his job responsibilities he isn't currently able to stay sufficiently 
involved in the manila project to serve as a core reviewer.


Thanks to Mark for his great service in the past!  We'd love to have 
him back if things change.


-- Tom Barron (tbarron)



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] [neutron] Core status

[Slawomir Kaplonski]

Hi,

Thanks for all Your work for Neutron and good luck in Your new role :)

> Wiadomość napisana przez Gary Kotton  w dniu 19.09.2018, 
> o godz. 20:19:
> 
> Hi,
> I have recently transitioned to a new role where I will be working on other 
> parts of OpenStack. Sadly I do not have the necessary cycles to maintain my 
> core responsibilities in the neutron community. Nonetheless I will continue 
> to be involved.
> Thanks
> Gary
> __
> 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

— 
Slawek Kaplonski
Senior 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] [neutron] Core status

[Akihiro Motoki]

Thanks Gary for long years on Neutron.
You are the only core before I became quantum-core. I lose you now
Anyway good luck for your new role.

Thanks,
Akihiro

2018年9月20日(木) 3:20 Gary Kotton :

> Hi,
>
> I have recently transitioned to a new role where I will be working on
> other parts of OpenStack. Sadly I do not have the necessary cycles to
> maintain my core responsibilities in the neutron community. Nonetheless I
> will continue to be involved.
>
> Thanks
>
> Gary
> __
> 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] [tc]Global Reachout Proposal

[Thierry Carrez]

Melvin Hillsman wrote:

https://thelounge.chat/
   - have not tried it yet but looks promising especially self-hosted option


We had a discussion in the infra room on TheLounge: there is a 
long-standing infra spec request to offer such a service on our project 
infrastructure, and it would go a long way to solve the "default 
experience" as it provides a nice UI by default with "always connected" 
behavior that most people expect from such communication media those days.


The main blocker AIUI is to integrate it with some authentication 
mechanism(s)...


--
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] [Openstack-operators] [all] Consistent policy names

[John Garbutt]

tl;dr
+1 consistent names
I would make the names mirror the API
... because the Operator setting them knows the API, not the code
Ignore the crazy names in Nova, I certainly hate them


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").
>>
>
+1
The API is known as "compute" in api-ref, so the policy should be for
"compute", etc.

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

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] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

[John Garbutt]

Hi,

Following on from the PTG discussions, I wanted to bring everyone's
attention to Nova's plans to deprecate ComputeCapabilitiesFilter, including
most of the the integration with Ironic Capabilities.

To be specific, this is my proposal in code form:
https://review.openstack.org/#/c/603102/

Once the code we propose to deprecate is removed we will stop using
capabilities pushed up from Ironic for 'scheduling', but we would still
pass capabilities request in the flavor down to Ironic (until we get some
standard traits and/or deploy templates sorted for things like UEFI).

Functionally, we believe all use cases can be replaced by using the simpler
placement traits (this is more efficient than post placement filtering done
using capabilities):
https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/ironic-driver-traits.html

Please note the recent addition of forbidden traits that helps improve the
usefulness of the above approach:
https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-forbidden-traits.html

For example, a flavor request for GPUs >= 2 could be replaced by a custom
trait trait that reports if a given Ironic node has
CUSTOM_MORE_THAN_2_GPUS. That is a bad example (longer term we don't want
to use traits for this, but that is a discussion for another day) but it is
the example that keeps being raised in discussions on this topic.

The main reason for reaching out in this email is to ask if anyone has
needs that the ResourceClass and Traits scheme does not currently address,
or can think of a problem with a transition to the newer approach.

Many thanks,
John Garbutt

IRC: johnthetubaguy
__
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] Core status

[Miguel Angel Ajo Pelayo]

Good luck Gary, thanks for all those years on Neutron! :)

Best regards,
Miguel Ángel

On Wed, Sep 19, 2018 at 9:32 PM Nate Johnston 
wrote:

> On Wed, Sep 19, 2018 at 06:19:44PM +, Gary Kotton wrote:
>
> > I have recently transitioned to a new role where I will be working on
> other parts of OpenStack. Sadly I do not have the necessary cycles to
> maintain my core responsibilities in the neutron community. Nonetheless I
> will continue to be involved.
>
> Thanks for everything you've done over the years, Gary.  I know I
> learned a lot from your reviews back when I was a wee baby Neutron
> developer.  Best of luck on what's next!
>
> Nate
>
> __
> 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
>


-- 
Miguel Ángel Ajo
OSP / Networking DFG, OVN Squad Engineering
__
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] [placement] [infra] [qa] tuning some zuul jobs from "it works" to "proper"

[Luigi Toscano]

On Thursday, 20 September 2018 04:47:20 CEST Matthew Treinish wrote:
> On Thu, Sep 20, 2018 at 11:11:12AM +0900, Ghanshyam Mann wrote:
> >   On Wed, 19 Sep 2018 23:29:46 +0900 Monty Taylor
> >   wrote >  
> >  > On 09/19/2018 09:23 AM, Monty Taylor wrote:
> >  > > On 09/19/2018 08:25 AM, Chris Dent wrote:
> >  > >> I have a patch in progress to add some simple integration tests to
> >  > >> 
> >  > >> placement:
> >  > >>  https://review.openstack.org/#/c/601614/
> >  > >> 
> >  > >> They use https://github.com/cdent/gabbi-tempest . The idea is that
> >  > >> the method for adding more tests is to simply add more yaml in
> >  > >> gate/gabbits, without needing to worry about adding to or think
> >  > >> about tempest.
> >  > >> 
> >  > >> What I have at that patch works; there are two yaml files, one of
> >  > >> which goes through the process of confirming the existence of a
> >  > >> resource provider and inventory, booting a server, seeing a change
> >  > >> in allocations, resizing the server, seeing a change in allocations.
> >  > >> 
> >  > >> But this is kludgy in a variety of ways and I'm hoping to get some
> >  > >> help or pointers to the right way. I'm posting here instead of
> >  > >> asking in IRC as I assume other people confront these same
> >  > >> confusions. The issues:
> >  > >> 
> >  > >> * The associated playbooks are cargo-culted from stuff labelled
> >  > >> 
> >  > >>"legacy" that I was able to find in nova's jobs. I get the
> >  > >>impression that these are more verbose and duplicative than they
> >  > >>need to be and are not aligned with modern zuul v3 coolness.
> >  > > 
> >  > > Yes. Your life will be much better if you do not make more legacy
> >  > > jobs.
> >  > > They are brittle and hard to work with.
> >  > > 
> >  > > New jobs should either use the devstack base job, the
> >  > > devstack-tempest
> >  > > base job or the devstack-tox-functional base job - depending on what
> >  > > things are intended.
> > 
> > +1. All the base job from Tempest and Devstack (except grenade which is in
> > progress) are available to use as base for legacy jobs. Using
> > devstack-temepst in your patch is right things. In addition, you need to
> > mention the tox_envlist as all-plugins to make tempest_test_regex work. I
> > commented on review.
> No, all-plugins is incorrect and should never be used. It's only there for
> legacy support, it is deprecated and I thought we pushed a patch to
> indicating that (but I can't find it).

This one?
https://review.openstack.org/#/c/543974/

Ciao
-- 
Luigi



__
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] [Openstack-operators] [tc]Global Reachout Proposal

[Zhipeng Huang]

Thanks Anita, will definitely do as you kindly suggested :)

On Thu, Sep 20, 2018, 12:04 PM Anita Kuno  wrote:

> On 2018-09-18 08:40 AM, Jeremy Stanley wrote:
> > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
> > [...]
> >> I can understand that IRC cannot be used in China which is very
> >> painful and mostly it is used weChat.
> > [...]
> >
> > I have yet to hear anyone provide first-hand confirmation that
> > access to Freenode's IRC servers is explicitly blocked by the
> > mainland Chinese government. There has been a lot of speculation
> > that the usual draconian corporate firewall policies (surprise, the
> > rest of the World gets to struggle with those too, it's not just a
> > problem in China) are blocking a variety of messaging protocols from
> > workplace networks and the people who encounter this can't tell the
> > difference because they're already accustomed to much of their other
> > communications being blocked at the border. I too have heard from
> > someone who's heard from someone that "IRC can't be used in China"
> > but the concrete reasons why continue to be missing from these
> > discussions.
> >
>
> I'll reply to this email arbitrarily in order to comply with Zhipeng
> Huang's wishes that the conversation concerned with understanding the
> actual obstacles to communication takes place on the mailing list. I do
> hope I am posting to the correct thread.
>
> In response to part of your comment on the patch at
> https://review.openstack.org/#/c/602697/ which you posted about 5 hours
> ago you said "@Anita you are absolutely right it is only me stuck my
> head out speaks itself the problem I stated in the patch. Many of the
> community tools that we are comfortable with are not that accessible to
> a broader ecosystem. And please assured that I meant I refer the patch
> to the Chinese community, as Leong also did on the ML, to try to bring
> them over to join the convo." and I would like to reply.
>
> I would like to say that I am honoured by your generosity. Thank you.
> Now, when the Chinese community consumes the patch, as well as the
> conversation in the comments, please encourage folks to ask for
> clarification if any descriptions or phrases don't make sense to them.
> One of the best ways of ensuring clear communication is to start off
> slowly and take the time to ask what the other side means. It can seem
> tedious and a waste of time, but I have found it to be very educational
> and helpful in understanding how the other person perceives the
> situation. It also helps me to understand how I am creating obstacles in
> ways that I talk.
>
> Taking time to clarify helps me to adjust how I am speaking so that my
> meaning is more likely to be understood by the group to which I am
> trying to offer my perspective. I do appreciate that many people are
> trying to avoid embarrassment, but I have never found any way to
> understand people in a culture that is not the one I group up in, other
> than embarrassing myself and working through it. Usually I find the
> group I am wanting to understand is more than willing to rescue me from
> my embarrassment and support me in my learning. In a strange way, the
> embarrassment is kind of helpful in order to create understanding
> between myself and those people I am trying to understand.
>
> Thank you, Anita
>
> __
> 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] Nominating Tetsuro Nakamura for placement-core

[Balázs Gibizer]

On Wed, Sep 19, 2018 at 5:25 PM, Chris Dent  
wrote:



I'd like to nominate Tetsuro Nakamura for membership in the
placement-core team. Throughout placement's development Tetsuro has
provided quality reviews; done the hard work of creating rigorous
functional tests, making them fail, and fixing them; and implemented
some of the complex functionality required at the persistence layer.
He's aware of and respects the overarching goals of placement and has
demonstrated pragmatism when balancing those goals against the
requirements of nova, blazar and other projects.

Please follow up with a +1/-1 to express your preference. No need to
be an existing placement core, everyone with an interest is welcome.


I'm soft +1 on Tetsuro. I'm +1 as the code and reviews I read from 
Tetsuro looks solid to me. I'm only soft +1 as I did not interface with 
Tetsuro enough to express a hard opinion.


Cheers,
gibi



Thanks.

--
Chris Dent   ٩◔̯◔۶   
https://anticdent.org/

reenode: cdent tw: @anticdent
__
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