date:20180912

Excerpts from Chris Friesen's message of 2018-09-12 16:52:16 -0600:
> On 9/12/2018 12:04 PM, Doug Hellmann wrote:
> 
> >> This came up in a Vancouver summit session (the python3 one I think). 
> >> General consensus there seemed to be that we should have grenade jobs that 
> >> run python2 on the old side and python3 on the new side and test the 
> >> update from one to another through a release that way. Additionally there 
> >> was thought that the nova partial job (and similar grenade jobs) could 
> >> hold the non upgraded node on python2 and that would talk to a python3 
> >> control plane.
> >>
> >> I haven't seen or heard of anyone working on this yet though.
> >>
> >> Clark
> >>
> > 
> > IIRC, we also talked about not supporting multiple versions of
> > python on a given node, so all of the services on a node would need
> > to be upgraded together.
> 
> As I understand it, the various services talk to each other using 
> over-the-wire protocols.  Assuming this is correct, why would we need to 
> ensure they are using the same python version?
> 
> Chris
> 

It's more a matter of trying to describe what test scenarios we
would run.  In this case we were saying that we're not going to try
to spend the effort upstream to test a mixed configuration on a
single node. Someone downstream might choose to do that, but we
didn't see value in it for the community to try to do it upstream.

Doug

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

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

2018-09-12 Thread Balázs Gibizer

Hi,

It seems that the Nova room (Ballroom A) does not have any projection
possibilities. In the other hand the Neutron room (
Vail Meeting Room, Atrium Level) does have a projector. So I suggest to
move the demo to the Neutron room.

Cheers,
gibi

On Fri, Aug 31, 2018 at 2:29 AM, Balázs Gibizer
wrote:

On Thu, Aug 30, 2018 at 8:13 PM, melanie witt
wrote:

On Thu, 30 Aug 2018 12:43:06 -0500, Miguel Lavalle wrote:

Gibi, Bence,

In fact, I added the demo explicitly to the Neutron PTG agenda from
1:30 to 2, to give it visiblilty

I'm interested in seeing the demo too. Will the demo be shown at the
Neutron room or the Nova room? Historically, lunch has ended at
1:30, so this will be during the same time as the Neutron/Nova
cross project time. Should we just co-locate together for the demo
and the session? I expect anyone watching the demo will want to
participate in the Neutron/Nova session as well. Either room is
fine by me.

I assume that the nova - neturon cross project session will be in the
nova room, so I propose to have the demo there as well to avoid
unnecessarily moving people around. For us it is totally OK to start
the demo at 1:30.

Cheers,
gibi

-melanie

On Thu, Aug 30, 2018 at 3:55 AM, Balázs Gibizer
> wrote:

Hi,

Based on the Nova PTG planning etherpad [1] there is a need to
talk

about the current state of the bandwidth work [2][3]. Bence
(rubasov) has already planned to show a small demo to Neutron
folks
about the current state of the implementation. So Bence and I
are
wondering about bringing that demo close to the nova - neutron
cross

project session. That session is currently planned to happen
Thursday after lunch. So we are think about showing the demo
right

before that session starts. It would start 30 minutes before the
nova - neutron cross project session.

Are Nova folks also interested in seeing such a demo?

If you are interested in seeing the demo please drop us a line
or

ping us in IRC so we know who should we wait for.

Cheers,
gibi

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

[2]

https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html

[3]

https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.html

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

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

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

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

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

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

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

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

__
OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Melvin Hillsman

You're welcome!

-- 

Kind regards,

Melvin Hillsman

mrhills...@gmail.com
mobile: (832) 264-2646

On Wed, Sep 12, 2018, 5:52 PM Matt Riedemann  wrote:

> On 9/12/2018 5:32 PM, Melvin Hillsman wrote:
> > We basically spent the day focusing on two things specific to what you
> > bring up and are in agreement with you regarding action not just talk
> > around feedback and outreach. [1]
> > We wiped the agenda clean, discussed our availability (set reasonable
> > expectations), and revisited how we can be more diligent and successful
> > around these two principles which target your first comment, "...get
> > their RFE/bug list ranked from the operator community (because some of
> > the requests are not exclusive to public cloud), and then put pressure
> > on the TC to help project manage the delivery of the top issue..."
> >
> > I will not get into much detail because again this response is specific
> > to a portion of your email so in keeping with feedback and outreach the
> > UC is making it a point to be intentional. We have already got action
> > items [2] which target the concern you raise. We have agreed to hold
> > each other accountable and adjusted our meeting structure to facilitate
> > being successful.
> >
> > Not that the UC (elected members) are the only ones who can do this but
> > we believe it is our responsibility to; regardless of what anyone else
> > does. The UC is also expected to enlist others and hopefully through our
> > efforts others are encouraged participate and enlist others.
> >
> > [1] https://etherpad.openstack.org/p/uc-stein-ptg
> > [2] https://etherpad.openstack.org/p/UC-Election-Qualifications
>
> Awesome, thank you Melvin and others on the UC.
>
> --
>
> 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] Open letter/request to TC candidates (and existing elected officials)


On 9/12/2018 5:32 PM, Melvin Hillsman wrote:
We basically spent the day focusing on two things specific to what you 
bring up and are in agreement with you regarding action not just talk 
around feedback and outreach. [1]
We wiped the agenda clean, discussed our availability (set reasonable 
expectations), and revisited how we can be more diligent and successful 
around these two principles which target your first comment, "...get 
their RFE/bug list ranked from the operator community (because some of 
the requests are not exclusive to public cloud), and then put pressure 
on the TC to help project manage the delivery of the top issue..."


I will not get into much detail because again this response is specific 
to a portion of your email so in keeping with feedback and outreach the 
UC is making it a point to be intentional. We have already got action 
items [2] which target the concern you raise. We have agreed to hold 
each other accountable and adjusted our meeting structure to facilitate 
being successful.


Not that the UC (elected members) are the only ones who can do this but 
we believe it is our responsibility to; regardless of what anyone else 
does. The UC is also expected to enlist others and hopefully through our 
efforts others are encouraged participate and enlist others.


[1] https://etherpad.openstack.org/p/uc-stein-ptg
[2] https://etherpad.openstack.org/p/UC-Election-Qualifications


Awesome, thank you Melvin and others on the UC.

--

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] Open letter/request to TC candidates (and existing elected officials)


On 9/12/2018 5:13 PM, Jeremy Stanley wrote:

Sure, and I'm saying that instead I think the influence of TC
members_can_  be more valuable in finding and helping additional
people to do these things rather than doing it all themselves, and
it's not just about the limited number of available hours in the day
for one person versus many. The successes goal champions experience,
the connections they make and the elevated reputation they gain
throughout the community during the process of these efforts builds
new leaders for us all.


Again, I'm not saying TC members should be doing all of the work 
themselves. That's not realistic, especially when critical parts of any 
major effort are going to involve developers from projects on which none 
of the TC members are active contributors (e.g. nova). I want to see TC 
members herd cats, for lack of a better analogy, and help out 
technically (with code) where possible.


Given the repeated mention of how the "help wanted" list continues to 
not draw in contributors, I think the recruiting role of the TC should 
take a back seat to actually stepping in and helping work on those items 
directly. For example, Sean McGinnis is taking an active role in the 
operators guide and other related docs that continue to be discussed at 
every face to face event since those docs were dropped from 
openstack-manuals (in Pike).


I think it's fair to say that the people generally elected to the TC are 
those most visible in the community (it's a popularity contest) and 
those people are generally the most visible because they have the luxury 
of working upstream the majority of their time. As such, it's their duty 
to oversee and spend time working on the hard cross-project technical 
deliverables that operators and users are asking for, rather than think 
of an infinite number of ways to try and draw *others* to help work on 
those gaps. As I think it's the role of a PTL within a given project to 
have a finger on the pulse of the technical priorities of that project 
and manage the developers involved (of which the PTL certainly may be 
one), it's the role of the TC to do the same across openstack as a 
whole. If a PTL doesn't have the time or willingness to do that within 
their project, they shouldn't be the PTL. The same goes for TC members IMO.


--

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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Melvin Hillsman

We basically spent the day focusing on two things specific to what you
bring up and are in agreement with you regarding action not just talk
around feedback and outreach. [1]

We wiped the agenda clean, discussed our availability (set reasonable
expectations), and revisited how we can be more diligent and successful
around these two principles which target your first comment, "...get their
RFE/bug list ranked from the operator community (because some of the
requests are not exclusive to public cloud), and then put pressure on the
TC to help project manage the delivery of the top issue..."

I will not get into much detail because again this response is specific to
a portion of your email so in keeping with feedback and outreach the UC is
making it a point to be intentional. We have already got action items [2]
which target the concern you raise. We have agreed to hold each other
accountable and adjusted our meeting structure to facilitate being
successful.

Not that the UC (elected members) are the only ones who can do this but we
believe it is our responsibility to; regardless of what anyone else does.
The UC is also expected to enlist others and hopefully through our efforts
others are encouraged participate and enlist others.

[1] https://etherpad.openstack.org/p/uc-stein-ptg
[2] https://etherpad.openstack.org/p/UC-Election-Qualifications

On Wed, Sep 12, 2018 at 6:13 PM Jeremy Stanley  wrote:

> On 2018-09-12 17:05:17 -0600 (-0600), Lance Bragstad wrote:
> [...]
> > IMHO, I think the point Matt is making here is more about ensuring
> > sure we have people to do what we've agreed upon, as a community,
> > as being mission critical. Enablement is imperative, but no matter
> > how good we are at it, sometimes we really just needs hands to do
> > the work.
> [...]
>
> Sure, and I'm saying that instead I think the influence of TC
> members _can_ be more valuable in finding and helping additional
> people to do these things rather than doing it all themselves, and
> it's not just about the limited number of available hours in the day
> for one person versus many. The successes goal champions experience,
> the connections they make and the elevated reputation they gain
> throughout the community during the process of these efforts builds
> new leaders for us all.
> --
> Jeremy Stanley
> __
> OpenStack Development Mailing 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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 2018-09-12 17:05:17 -0600 (-0600), Lance Bragstad wrote:
[...]
> IMHO, I think the point Matt is making here is more about ensuring
> sure we have people to do what we've agreed upon, as a community,
> as being mission critical. Enablement is imperative, but no matter
> how good we are at it, sometimes we really just needs hands to do
> the work.
[...]

Sure, and I'm saying that instead I think the influence of TC
members _can_ be more valuable in finding and helping additional
people to do these things rather than doing it all themselves, and
it's not just about the limited number of available hours in the day
for one person versus many. The successes goal champions experience,
the connections they make and the elevated reputation they gain
throughout the community during the process of these efforts builds
new leaders for us all.
-- 
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 2018-09-12 17:03:10 -0600 (-0600), Matt Riedemann wrote:
> On 9/12/2018 4:14 PM, Jeremy Stanley wrote:
> > I think Doug's work leading the Python 3 First effort is a great
> > example. He has helped find and enable several other goal champions
> > to collaborate on this. I appreciate the variety of other things
> > Doug already does with his available time and would rather he not
> > stop doing those things to spend all his time acting as a project
> > manager.
> 
> I specifically called out what Doug is doing as an example of
> things I want to see the TC doing. I want more/all TC members
> doing that.

With that I was replying to Zhipeng Huang's message which you have
trimmed above, specifically countering the assertion that recruiting
others to help with these efforts is a waste of time and that TC
members should simply do all the work themselves instead.
-- 
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Lance Bragstad

On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley  wrote:

> On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> [...]
> > So I encourage all elected TC members to work directly with the
> > various SIGs to figure out their top issue and then work on
> > managing those deliverables across the community because the TC is
> > particularly well suited to do so given the elected position.
> [...]
>
> I almost agree with you. I think the OpenStack TC members should be
> actively engaged in recruiting and enabling interested people in the
> community to do those things, but I don't think such work should be
> solely the domain of the TC and would hate to give the impression
> that you must be on the TC to have such an impact.
>

I agree that relaying that type of impression would be negative, but I'm
not sure this specifically would do that. I think we've been good about
letting people step up to drive initiatives without being in an elected
position [0].

IMHO, I think the point Matt is making here is more about ensuring sure we
have people to do what we've agreed upon, as a community, as being mission
critical. Enablement is imperative, but no matter how good we are at it,
sometimes we really just needs hands to do the work.

[0] Of the six goals agreed upon since we've implemented champions in
Queens, five of them have been championed by non-TC members (Chandan
championed two, in back-to-back releases).

> --
> Jeremy Stanley
> __
> OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)


On 9/12/2018 4:14 PM, Jeremy Stanley wrote:

I think Doug's work leading the Python 3 First effort is a great
example. He has helped find and enable several other goal champions
to collaborate on this. I appreciate the variety of other things
Doug already does with his available time and would rather he not
stop doing those things to spend all his time acting as a project
manager.


I specifically called out what Doug is doing as an example of things I 
want to see the TC doing. I want more/all TC members doing that.


--

Thanks,

Matt

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

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)


On 9/12/2018 3:55 PM, Jeremy Stanley wrote:

I almost agree with you. I think the OpenStack TC members should be
actively engaged in recruiting and enabling interested people in the
community to do those things, but I don't think such work should be
solely the domain of the TC and would hate to give the impression
that you must be on the TC to have such an impact.


See my reply to Thierry. This isn't what I'm saying. But I expect the 
elected TC members to be *much* more *directly* involved in managing and 
driving hard cross-project technical deliverables.


--

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] Open letter/request to TC candidates (and existing elected officials)


On 9/12/2018 3:30 PM, Dan Smith wrote:

I'm just a bit worried to limit that role to the elected TC members. If
we say "it's the role of the TC to do cross-project PM in OpenStack"
then we artificially limit the number of people who would sign up to do
that kind of work. You mention Ildiko and Lance: they did that line of
work without being elected.

Why would saying that we_expect_  the TC members to do that work limit
such activities only to those that are on the TC? I would expect the TC
to take on the less-fun or often-neglected efforts that we all know are
needed but don't have an obvious champion or sponsor.

I think we expect some amount of widely-focused technical or project
leadership from TC members, and certainly that expectation doesn't
prevent others from leading efforts (even in the areas of proposing TC
resolutions, etc) right?


Absolutely. I'm not saying the cross-project project management should 
be restricted to or solely the responsibility of the TC. It's obvious 
there are people outside of the TC that have already been doing this - 
and no it's not always elected PTLs either. What I want is elected TC 
members to prioritize driving technical deliverables to completion based 
on ranked input from operators/users/SIGs over philosophical debates and 
politics/bureaucracy and help to complete the technical tasks if possible.


--

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] [goals][python3] mixed versions?

2018-09-12 Thread Chris Friesen


On 9/12/2018 12:04 PM, Doug Hellmann wrote:


This came up in a Vancouver summit session (the python3 one I think). General 
consensus there seemed to be that we should have grenade jobs that run python2 
on the old side and python3 on the new side and test the update from one to 
another through a release that way. Additionally there was thought that the 
nova partial job (and similar grenade jobs) could hold the non upgraded node on 
python2 and that would talk to a python3 control plane.

I haven't seen or heard of anyone working on this yet though.

Clark



IIRC, we also talked about not supporting multiple versions of
python on a given node, so all of the services on a node would need
to be upgraded together.


As I understand it, the various services talk to each other using 
over-the-wire protocols.  Assuming this is correct, why would we need to 
ensure they are using the same python version?


Chris

__
OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)

On 2018-09-12 16:03:12 -0600 (-0600), Zhipeng Huang wrote:
> On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley  wrote:
> > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> > [...]
> > > So I encourage all elected TC members to work directly with the
> > > various SIGs to figure out their top issue and then work on
> > > managing those deliverables across the community because the TC is
> > > particularly well suited to do so given the elected position.
> > [...]
> >
> > I almost agree with you. I think the OpenStack TC members should be
> > actively engaged in recruiting and enabling interested people in the
> > community to do those things, but I don't think such work should be
> > solely the domain of the TC and would hate to give the impression
> > that you must be on the TC to have such an impact.
> 
> Jeremy, this is not to say that one must be on the TC to have such an
> impact, it is that TC has the duty more than anyone else to get this
> specific cross-project goal done. I would even argue it is not the job
> description of TC to enable/recruit, but to just do it.

I think Doug's work leading the Python 3 First effort is a great
example. He has helped find and enable several other goal champions
to collaborate on this. I appreciate the variety of other things
Doug already does with his available time and would rather he not
stop doing those things to spend all his time acting as a project
manager.
-- 
Jeremy Stanley


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

[openstack-dev] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

Ian has been working for a while on enabling PDF and translation
support for our documentation build job [1][2]. After exploring a
few different approaches, today at the PTG I think we were able to
agree on a plan that will let us move ahead.

The tl;dr version is that we want to add some extra steps to the
existing openstack-tox-docs job (or make a new job that includes
those steps and change the PTI project template so projects start
using it transparently). The changes to the job will be made so
that if the PDF and translation builds work the results will be
published and if they fail that will not trigger a job failure.

The longer version is that we want to continue to use the existing
tox environment in each project as the basis for the job, since
that allows teams to control the version of python used, the
dependencies installed, and add custom steps to their build (such
as for pre-processing the documentation). So, the new or updated
job will start by running "tox -e docs" as it does today. Then it
will run Sphinx again with the instructions to build PDF output,
and copy the results into the directory that the publish job will
use to sync to the web server. And then it will run the scripts to
build translated versions of the documentation as HTML, and copy
the results into place for publishing.

There are a few settings that can/should be configured via the
Sphinx conf.py file, but rather than trying to push updates into
all of the project repos we will look into passing the options on
the command line or making the openstackdocstheme inject those
settings. This would apply to the setting to control the latex
processor as well as fonts or other settings that control the output.
Those things all relate to the format of the output, so it seems
appropriate to have the theme control them.

To cut down on any delays caused by introducing several consecutive
sphinx-build runs to the documentation job we plan to have the check
and gate jobs only run the translation portion of the build if the
message catalog files for a language are modified.

Since this work will all happen inside the documentation build job,
and it will be enabled for all teams automatically, we do not need
to update the Project Testing Interface, and Ian can abandon his
governance changes.

Monty is going to work on the implementation with Ian using
openstacksdk as a test bed [3].

As usual, please let me know if I've left out or mistaken any
details.

Doug

[1] https://review.openstack.org/572559
[2] https://review.openstack.org/588110
[3] https://review.openstack.org/601659

__
OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Zhipeng Huang

On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley  wrote:

> On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> [...]
> > So I encourage all elected TC members to work directly with the
> > various SIGs to figure out their top issue and then work on
> > managing those deliverables across the community because the TC is
> > particularly well suited to do so given the elected position.
> [...]
>
> I almost agree with you. I think the OpenStack TC members should be
> actively engaged in recruiting and enabling interested people in the
> community to do those things, but I don't think such work should be
> solely the domain of the TC and would hate to give the impression
> that you must be on the TC to have such an impact.
> --
> Jeremy Stanley
>

Jeremy, this is not to say that one must be on the TC to have such an
impact, it is that TC has the duty more than anyone else to get this
specific cross-project goal done. I would even argue it is not the job
description of TC to enable/recruit, but to just do it.

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

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
[...]
> So I encourage all elected TC members to work directly with the
> various SIGs to figure out their top issue and then work on
> managing those deliverables across the community because the TC is
> particularly well suited to do so given the elected position.
[...]

I almost agree with you. I think the OpenStack TC members should be
actively engaged in recruiting and enabling interested people in the
community to do those things, but I don't think such work should be
solely the domain of the TC and would hate to give the impression
that you must be on the TC to have such an impact.
-- 
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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Davanum Srinivas

On Wed, Sep 12, 2018 at 3:30 PM Dan Smith  wrote:

> > I'm just a bit worried to limit that role to the elected TC members. If
> > we say "it's the role of the TC to do cross-project PM in OpenStack"
> > then we artificially limit the number of people who would sign up to do
> > that kind of work. You mention Ildiko and Lance: they did that line of
> > work without being elected.
>
> Why would saying that we _expect_ the TC members to do that work limit
> such activities only to those that are on the TC? I would expect the TC
> to take on the less-fun or often-neglected efforts that we all know are
> needed but don't have an obvious champion or sponsor.
>
> I think we expect some amount of widely-focused technical or project
> leadership from TC members, and certainly that expectation doesn't
> prevent others from leading efforts (even in the areas of proposing TC
> resolutions, etc) right?
>

+1 Dan!


> --Dan
>
> __
> OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Dan Smith

> I'm just a bit worried to limit that role to the elected TC members. If
> we say "it's the role of the TC to do cross-project PM in OpenStack"
> then we artificially limit the number of people who would sign up to do
> that kind of work. You mention Ildiko and Lance: they did that line of
> work without being elected.

Why would saying that we _expect_ the TC members to do that work limit
such activities only to those that are on the TC? I would expect the TC
to take on the less-fun or often-neglected efforts that we all know are
needed but don't have an obvious champion or sponsor.

I think we expect some amount of widely-focused technical or project
leadership from TC members, and certainly that expectation doesn't
prevent others from leading efforts (even in the areas of proposing TC
resolutions, etc) right?

--Dan

__
OpenStack Development Mailing 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] Ops Forum Session Brainstorming

2018-09-12 Thread Erik McCormick

Hello everyone,

I have set up an etherpad to collect Ops related session ideas for the
Forum at the Berlin Summit. Please suggest any topics that you would
like to see covered, and +1 existing topics you like.

https://etherpad.openstack.org/p/ops-forum-stein

Cheers,
Erik

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

Re: [openstack-dev] [goals][python3] mixed versions?

Excerpts from Doug Hellmann's message of 2018-09-12 12:04:02 -0600:
> Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> > On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> > > The process of operators upgrading Python versions across their fleet came
> > > up this morning. It's fairly obvious that operators will want to do this 
> > > in
> > > a rolling fashion.
> > > 
> > > Has anyone considered doing this in CI? For example, running multinode
> > > grenade with python 2 on one node and python 3 on the other node.
> > > 
> > > Should we (openstack) test this situation, or even care?
> > > 
> > 
> > This came up in a Vancouver summit session (the python3 one I think). 
> > General consensus there seemed to be that we should have grenade jobs that 
> > run python2 on the old side and python3 on the new side and test the update 
> > from one to another through a release that way. Additionally there was 
> > thought that the nova partial job (and similar grenade jobs) could hold the 
> > non upgraded node on python2 and that would talk to a python3 control plane.
> > 
> > I haven't seen or heard of anyone working on this yet though.
> > 
> > Clark
> > 
> 
> IIRC, we also talked about not supporting multiple versions of
> python on a given node, so all of the services on a node would need
> to be upgraded together.
> 
> Doug

I spent a little time talking with the QA team about setting up
this job, and Attila pointed out that we should think about what
exactly we think would break during a 2-to-3 in-place upgrade like
this.

Keeping in mind that we are still testing initial installation under
both versions and upgrades under python 2, do we have any specific
concerns about the python *version* causing upgrade issues?

Doug

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

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

2018-09-12 Thread Zane Bitter


On 4/09/18 5:39 PM, Ben Nemec wrote:
Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo PTG 
schedule for this but figured I should check if it's something we even 
want to pursue.


+1. We started discussing this today and immediately realised it was 
going to result in every project copy/pasting the code to create a 
-status executable and thae upgrade-check command itself. It 
would be great if we can avoid this from the start.



On 09/04/2018 04:29 PM, Matt Riedemann wrote:

Just a few updates this week.

1. The story is now populated with a task per project that may have 
something to complete for this goal [1]. PTLs, or their liaison(s), 
should assign the task for their project to whomever is going to work 
on the goal. The goal document in governance is being updated with the 
appropriate links to storyboard [2].


2. While populating the story and determining which projects to omit 
(like infra, docs, QA were obvious), I left in the deployment projects 
but those likely can/should opt-out of this goal for Stein since the 
goal is more focused on service projects like keystone/cinder/glance. 
I have pushed a docs updated to the goal with respect to deployment 
projects [3]. For deployment projects that don't plan on doing 
anything with this goal, feel free to just invalidate the task in 
storyboard for your project.


3. I have a developer/contributor reference docs patch up for review 
in nova [4] which is hopefully written generically enough that it can 
be consumed by and used as a guide for other projects implementing 
these upgrade checks.


4. I've proposed an amendment to the completion criteria for the goal 
[5] saying that projects with the "supports-upgrade" tag should 
integrate the checks from their project with their upgrade CI testing 
job. That could be grenade or some other upgrade testing framework, 
but it stands to reason that a project which claims to support 
upgrades and has automated checks for upgrades, should be running 
those in their CI.


Let me know if there are any questions. There will also be some time 
during a PTG lunch-and-learn session where I'll go over this goal at a 
high level, so feel free to ask questions during or after that at the 
PTG as well.


[1] https://storyboard.openstack.org/#!/story/2003657
[2] https://review.openstack.org/#/c/599759/
[3] https://review.openstack.org/#/c/599835/
[4] https://review.openstack.org/#/c/596902/
[5] https://review.openstack.org/#/c/599849/



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



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

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

Excerpts from Ben Nemec's message of 2018-09-12 13:51:16 -0600:
> 
> On 09/04/2018 06:49 PM, Matt Riedemann wrote:
> > On 9/4/2018 6:39 PM, Ben Nemec wrote:
> >> Would it be helpful to factor some of the common code out into an Oslo 
> >> library so projects basically just have to subclass, implement check 
> >> functions, and add them to the _upgrade_checks dict? It's not a huge 
> >> amount of code, but a bunch of it seems like it would need to be 
> >> copy-pasted into every project. I have a tentative topic on the Oslo 
> >> PTG schedule for this but figured I should check if it's something we 
> >> even want to pursue.
> > 
> > Yeah I'm not opposed to trying to pull the nova stuff into a common 
> > library for easier consumption in other projects, I just haven't devoted 
> > the time for it, nor will I probably have the time to do it. If others 
> > are willing to investigate that it would be great.
> > 
> 
> Okay, here's a first shot at such a library: 
> https://github.com/cybertron/oslo.upgradecheck
> 
> Lots of rough edges that would need to be addressed before it could be 
> released, but it demonstrates the basic idea I had in mind for this. The 
> upgradecheck module contains the common code, and __main__.py is a demo 
> use of the code.
> 
> -Ben
> 

Nice! Let's get that imported into gerrit and keep iterating on it to
make it usable for the goal. Maybe we can get one of the projects most
interested in working on this goal early to help with testing and UX
feedback.

Doug

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

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

2018-09-12 Thread Ben Nemec




On 09/04/2018 06:49 PM, Matt Riedemann wrote:

On 9/4/2018 6:39 PM, Ben Nemec wrote:
Would it be helpful to factor some of the common code out into an Oslo 
library so projects basically just have to subclass, implement check 
functions, and add them to the _upgrade_checks dict? It's not a huge 
amount of code, but a bunch of it seems like it would need to be 
copy-pasted into every project. I have a tentative topic on the Oslo 
PTG schedule for this but figured I should check if it's something we 
even want to pursue.


Yeah I'm not opposed to trying to pull the nova stuff into a common 
library for easier consumption in other projects, I just haven't devoted 
the time for it, nor will I probably have the time to do it. If others 
are willing to investigate that it would be great.




Okay, here's a first shot at such a library: 
https://github.com/cybertron/oslo.upgradecheck


Lots of rough edges that would need to be addressed before it could be 
released, but it demonstrates the basic idea I had in mind for this. The 
upgradecheck module contains the common code, and __main__.py is a demo 
use of the code.


-Ben

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

[openstack-dev] [horizon][plugins] Development environment for Horizon plugins

2018-09-12 Thread Ivan Kolodyazhny

Hi team,

Some time ago we've found an issue that there is no simple way to test
Horizon plugin locally with the current version of Horizon [1], [2].

It leads to the situation when plugins developers use the latest released
Horizon version instead of the latest master during new features
development. This issue is not reproduced on CI because Zuul does a great
job here.

We discussed this issue at the PTG [2] (line #163) and decided to go
forward with a such [3] solution for now instead of a custom solution in
each plugin like [4].

If anybody has any other ideas or concerns, please let me know.



[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html
[2] https://etherpad.openstack.org/p/horizon-ptg-planning-denver-2018
[3] https://review.openstack.org/#/c/601836/
[4] https://github.com/openstack/magnum-ui/blob/master/tox.ini#L23


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

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

2018-09-12 Thread Tim Bell

So +1

Tim

From: Lance Bragstad 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 12 September 2018 at 20:43
To: "OpenStack Development Mailing List (not for usage questions)" 
, OpenStack Operators 

Subject: [openstack-dev] [all] Consistent policy names

The topic of having consistent policy names has popped up a few times this 
week. Ultimately, if we are to move forward with this, we'll need a convention. 
To help with that a little bit I started an etherpad [0] that includes links to 
policy references, basic conventions *within* that service, and some examples 
of each. I got through quite a few projects this morning, but there are still a 
couple left.

The idea is to look at what we do today and see what conventions we can come up 
with to move towards, which should also help us determine how much each 
convention is going to impact services (e.g. picking a convention that will 
cause 70% of services to rename policies).

Please have a look and we can discuss conventions in this thread. If we come to 
agreement, I'll start working on some documentation in oslo.policy so that it's 
somewhat official because starting to renaming policies.

[0] https://etherpad.openstack.org/p/consistent-policy-names
__
OpenStack Development Mailing 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] Consistent policy names

2018-09-12 Thread Lance Bragstad

The topic of having consistent policy names has popped up a few times this
week. Ultimately, if we are to move forward with this, we'll need a
convention. To help with that a little bit I started an etherpad [0] that
includes links to policy references, basic conventions *within* that
service, and some examples of each. I got through quite a few projects this
morning, but there are still a couple left.

The idea is to look at what we do today and see what conventions we can
come up with to move towards, which should also help us determine how much
each convention is going to impact services (e.g. picking a convention that
will cause 70% of services to rename policies).

Please have a look and we can discuss conventions in this thread. If we
come to agreement, I'll start working on some documentation in oslo.policy
so that it's somewhat official because starting to renaming policies.

[0] https://etherpad.openstack.org/p/consistent-policy-names
__
OpenStack Development Mailing 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] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Thierry Carrez

Matt Riedemann wrote:
> [...]
> I want to see the TC be more of a cross-project project management
> group, like a group of Ildikos and what she did between nova and cinder
> to get volume multi-attach done, which took persistent supervision to
> herd the cats and get it delivered. Lance is already trying to do this
> with unified limits. Doug is doing this with the python3 goal. I want my
> elected TC members to be pushing tangible technical deliverables forward.
> 
> I don't find any value in the TC debating ad nauseam about visions and
> constellations and "what is openstack?". Scope will change over time
> depending on who is contributing to openstack, we should just accept
> this. And we need to realize that if we are failing to deliver value to
> operators and users, they aren't going to use openstack and then "what
> is openstack?" won't matter because no one will care.
> [...]

I agree that we generally need more of those cross-project champions,
and generally TC members are in a good position to do that kind of work.
The TC itself is also in a good position to "bless" those initiatives
and give them some amount of priority (with our limited influence).

I'm just a bit worried to limit that role to the elected TC members. If
we say "it's the role of the TC to do cross-project PM in OpenStack"
then we artificially limit the number of people who would sign up to do
that kind of work. You mention Ildiko and Lance: they did that line of
work without being elected.

So I would definitely support having champions to drive SIG
cross-project priorities, and use the TC both to support them and as a
natural pool of champion candidates -- I would just avoid tying the role
to the elected group?

-- 
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] [goals][python3] mixed versions?

Excerpts from Clark Boylan's message of 2018-09-12 10:44:55 -0700:
> On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> > The process of operators upgrading Python versions across their fleet came
> > up this morning. It's fairly obvious that operators will want to do this in
> > a rolling fashion.
> > 
> > Has anyone considered doing this in CI? For example, running multinode
> > grenade with python 2 on one node and python 3 on the other node.
> > 
> > Should we (openstack) test this situation, or even care?
> > 
> 
> This came up in a Vancouver summit session (the python3 one I think). General 
> consensus there seemed to be that we should have grenade jobs that run 
> python2 on the old side and python3 on the new side and test the update from 
> one to another through a release that way. Additionally there was thought 
> that the nova partial job (and similar grenade jobs) could hold the non 
> upgraded node on python2 and that would talk to a python3 control plane.
> 
> I haven't seen or heard of anyone working on this yet though.
> 
> Clark
> 

IIRC, we also talked about not supporting multiple versions of
python on a given node, so all of the services on a node would need
to be upgraded together.

Doug

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

Re: [openstack-dev] [openstack][infra]Including Functional Tests in Coverage

2018-09-12 Thread Michael Johnson

We do this in Octavia. The openstack-tox-cover calls the cover
environment in tox.ini, so you can add it there.

Check out the tox.ini in the openstack/octavia project.

Michael

On Wed, Sep 12, 2018 at 7:01 AM reedip banerjee  wrote:
>
> Hi All,
>
> Has anyone ever experimented with including Functional Tests with 
> openstack-tox-cover job?
> We would like to include Functional tests in the coverage jobs and already 
> have a dsvm-functional job in place. However,  openstack-tox-cover is , if I 
> am correct, an infra job which is directly called.
>
> Has anyone tried to include the functional tests and all its pre-requisites 
> in the cover job? If so, any pointers would be great
>
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedipb
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [goals][python3] mixed versions?

2018-09-12 Thread Clark Boylan

On Wed, Sep 12, 2018, at 10:23 AM, Jim Rollenhagen wrote:
> The process of operators upgrading Python versions across their fleet came
> up this morning. It's fairly obvious that operators will want to do this in
> a rolling fashion.
> 
> Has anyone considered doing this in CI? For example, running multinode
> grenade with python 2 on one node and python 3 on the other node.
> 
> Should we (openstack) test this situation, or even care?
> 

This came up in a Vancouver summit session (the python3 one I think). General 
consensus there seemed to be that we should have grenade jobs that run python2 
on the old side and python3 on the new side and test the update from one to 
another through a release that way. Additionally there was thought that the 
nova partial job (and similar grenade jobs) could hold the non upgraded node on 
python2 and that would talk to a python3 control plane.

I haven't seen or heard of anyone working on this yet though.

Clark

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

[openstack-dev] [goals][python3] mixed versions?

2018-09-12 Thread Jim Rollenhagen

The process of operators upgrading Python versions across their fleet came
up this morning. It's fairly obvious that operators will want to do this in
a rolling fashion.

Has anyone considered doing this in CI? For example, running multinode
grenade with python 2 on one node and python 3 on the other node.

Should we (openstack) test this situation, or even care?

// jim
__
OpenStack Development Mailing 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] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

2018-09-12 Thread Ildiko Vancsa

Hi,

Wednesday is already here so let’s meet for lunch today!

We will have a table reserved for us in the lunch room (Ballroom D), let’s meet 
there so we can catch up a little before the Berlin Summit. :)

Thanks,
Ildikó


> On 2018. Sep 9., at 15:20, Ghanshyam Mann  wrote:
> 
> I am in for Wed lunch meeting. 
> 
> -gmann
> 
>  On Sat, 08 Sep 2018 07:30:53 +0900 Ildiko Vancsa 
>  wrote  
>> Hi Training Team,
>> 
>> As a couple of us will be at the PTG next week it would be great to get 
>> together one of the days maybe for lunch.
>> 
>> Wednesday would work the best for Kendall and me, but we can look into other 
>> days as well if it would not work for the majority of people around.
>> 
>> So my questions would be:
>> 
>> * Are you interested in getting together one of the lunch slots during next 
>> week?
>> 
>> * Would Wednesday work for you or do you have another preference?
>> 
>> Please drop a response to this thread and we will figure it out by Monday or 
>> early next week based on the responses.
>> 
>> Thanks,
>> Ildikó
>> (IRC: ildikov)
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Zhipeng Huang

Well Public Cloud WG has prepared the ammo as you know and to discuss with
TC on Friday :)

A hundred percent with you on this matter.

On Wed, Sep 12, 2018 at 9:47 AM Matt Riedemann  wrote:

> Rather than take a tangent on Kristi's candidacy thread [1], I'll bring
> this up separately.
>
> Kristi said:
>
> "Ultimately, this list isn’t exclusive and I’d love to hear your and
> other people's opinions about what you think the I should focus on."
>
> Well since you asked...
>
> Some feedback I gave to the public cloud work group yesterday was to get
> their RFE/bug list ranked from the operator community (because some of
> the requests are not exclusive to public cloud), and then put pressure
> on the TC to help project manage the delivery of the top issue. I would
> like all of the SIGs to do this. The upgrades SIG should rank and
> socialize their #1 issue that needs attention from the developer
> community - maybe that's better upgrade CI testing for deployment
> projects, maybe it's getting the pre-upgrade checks goal done for Stein.
> The UC should also be doing this; maybe that's the UC saying, "we need
> help on closing feature gaps in openstack client and/or the SDK". I
> don't want SIGs to bombard the developers with *all* of their
> requirements, but I want to get past *talking* about the *same* issues
> *every* time we get together. I want each group to say, "this is our top
> issue and we want developers to focus on it." For example, the extended
> maintenance resolution [2] was purely birthed from frustration about
> talking about LTS and stable branch EOL every time we get together. It's
> also the responsibility of the operator and user communities to weigh in
> on proposed release goals, but the TC should be actively trying to get
> feedback from those communities about proposed goals, because I bet
> operators and users don't care about mox removal [3].
>
> I want to see the TC be more of a cross-project project management
> group, like a group of Ildikos and what she did between nova and cinder
> to get volume multi-attach done, which took persistent supervision to
> herd the cats and get it delivered. Lance is already trying to do this
> with unified limits. Doug is doing this with the python3 goal. I want my
> elected TC members to be pushing tangible technical deliverables forward.
>
> I don't find any value in the TC debating ad nauseam about visions and
> constellations and "what is openstack?". Scope will change over time
> depending on who is contributing to openstack, we should just accept
> this. And we need to realize that if we are failing to deliver value to
> operators and users, they aren't going to use openstack and then "what
> is openstack?" won't matter because no one will care.
>
> So I encourage all elected TC members to work directly with the various
> SIGs to figure out their top issue and then work on managing those
> deliverables across the community because the TC is particularly well
> suited to do so given the elected position. I realize political and
> bureaucratic "how should openstack deal with x?" things will come up,
> but those should not be the priority of the TC. So instead of
> philosophizing about things like, "should all compute agents be in a
> single service with a REST API" for hours and hours, every few months -
> immediately ask, "would doing that get us any closer to achieving top
> technical priority x?" Because if not, or it's so fuzzy in scope that no
> one sees the way forward, document a decision and then drop it.
>
> [1]
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
> [2]
>
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
> [3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html
>
> --
>
> Thanks,
>
> Matt
>
> ___
> 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] Open letter/request to TC candidates (and existing elected officials)

Rather than take a tangent on Kristi's candidacy thread [1], I'll bring 
this up separately.


Kristi said:

"Ultimately, this list isn’t exclusive and I’d love to hear your and 
other people's opinions about what you think the I should focus on."


Well since you asked...

Some feedback I gave to the public cloud work group yesterday was to get 
their RFE/bug list ranked from the operator community (because some of 
the requests are not exclusive to public cloud), and then put pressure 
on the TC to help project manage the delivery of the top issue. I would 
like all of the SIGs to do this. The upgrades SIG should rank and 
socialize their #1 issue that needs attention from the developer 
community - maybe that's better upgrade CI testing for deployment 
projects, maybe it's getting the pre-upgrade checks goal done for Stein. 
The UC should also be doing this; maybe that's the UC saying, "we need 
help on closing feature gaps in openstack client and/or the SDK". I 
don't want SIGs to bombard the developers with *all* of their 
requirements, but I want to get past *talking* about the *same* issues 
*every* time we get together. I want each group to say, "this is our top 
issue and we want developers to focus on it." For example, the extended 
maintenance resolution [2] was purely birthed from frustration about 
talking about LTS and stable branch EOL every time we get together. It's 
also the responsibility of the operator and user communities to weigh in 
on proposed release goals, but the TC should be actively trying to get 
feedback from those communities about proposed goals, because I bet 
operators and users don't care about mox removal [3].


I want to see the TC be more of a cross-project project management 
group, like a group of Ildikos and what she did between nova and cinder 
to get volume multi-attach done, which took persistent supervision to 
herd the cats and get it delivered. Lance is already trying to do this 
with unified limits. Doug is doing this with the python3 goal. I want my 
elected TC members to be pushing tangible technical deliverables forward.


I don't find any value in the TC debating ad nauseam about visions and 
constellations and "what is openstack?". Scope will change over time 
depending on who is contributing to openstack, we should just accept 
this. And we need to realize that if we are failing to deliver value to 
operators and users, they aren't going to use openstack and then "what 
is openstack?" won't matter because no one will care.


So I encourage all elected TC members to work directly with the various 
SIGs to figure out their top issue and then work on managing those 
deliverables across the community because the TC is particularly well 
suited to do so given the elected position. I realize political and 
bureaucratic "how should openstack deal with x?" things will come up, 
but those should not be the priority of the TC. So instead of 
philosophizing about things like, "should all compute agents be in a 
single service with a REST API" for hours and hours, every few months - 
immediately ask, "would doing that get us any closer to achieving top 
technical priority x?" Because if not, or it's so fuzzy in scope that no 
one sees the way forward, document a decision and then drop it.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
[2] 
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html

[3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html

--

Thanks,

Matt

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

Re: [openstack-dev] [charms] Propose Felipe Reyes for OpenStack Charmers team

2018-09-12 Thread Frode Nordahl

Core membership application approved, welcome aboard Felipe!

FTR; I have also gathered a off-list +1 from David Ames

On Wed, Sep 12, 2018 at 4:04 AM Alex Kavanagh 
wrote:

> +1 from me too.
>
> On Wed, Sep 12, 2018 at 7:29 AM, Liam Young 
> wrote:
>
>> +1 and thanks for all your contributions Felipe!
>>
>> On Wed, Sep 12, 2018 at 6:51 AM Chris MacNaughton <
>> chris.macnaugh...@canonical.com> wrote:
>>
>>> +1 Felipe has been a solid contributor to the Openstack Charms for some
>>> time now.
>>>
>>> Chris
>>>
>>> On 11-09-18 23:07, Ryan Beisner wrote:
>>>
>>> +1  I'm always happy to see Felipe's contributions and fixes come
>>> through.
>>>
>>> Cheers!
>>>
>>> Ryan
>>>
>>>
>>>
>>>
>>> On Tue, Sep 11, 2018 at 1:10 PM James Page 
>>> wrote:
>>>
 +1

 On Wed, 5 Sep 2018 at 15:48 Billy Olsen  wrote:

> Hi,
>
> I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
> a core member. Over the past couple of years Felipe has contributed
> numerous patches and reviews to the OpenStack charms [0]. His
> experience
> and knowledge of the charms used in OpenStack and the usage of Juju
> make
> him a great candidate.
>
> [0] -
>
> https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22
>
> Thanks,
>
> Billy Olsen
>
>
> __
> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

[openstack-dev] [goals][python3] week 5 update

This is week 5 of the "Run under Python 3 by default" goal
(https://governance.openstack.org/tc/goals/stein/python3-first.html).

== What we learned last week ==

Lance started a thread to talk about the tox_install.sh that some
projects are encountering in their stable branches.
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134391.html

A few reviewers have asked about why the patches to add zuul settings
in stable branches are being proposed directly to those branches
instead of being backported. As we describe in the goal, sometimes
it would have been possible to backport the settings from master
but in some cases projects have different jobs on different branches.
The simplest way to ensure we maintained those settings correctly
was to prepare a separate patch for each branch and submit it
directly. Since these patches do not contain production code, and
are only configuring our CI system, the normal stable backport
policy doesn't apply.
https://governance.openstack.org/tc/goals/stein/python3-first.html#moving-settings-from-project-config

A couple of reviwers have asked about why the "queue" settings are
not included in the settings being copied into each repository.
Because the queue setting ties multiple projects together in the
gate pipeline, we need to be careful about how we manage that. We
decided to manage the "integrated" queue in project-config because
that need to be coordinated between teams, but to allow project
teams to add other queue settings in-tree (for example, some projects
that are not part of the integrated gate tie their server and client
repos together into 1 queue).

== Ongoing and Completed Work ==

All of our teams have started the zuul migration work (and more
than half are finished)!

+-+--++---+---++
| Team| Open | Failed | Total | Status| 
Champion   |
+-+--++---+---++
| adjutant|0 |  0 | 4 | DONE  | Doug 
Hellmann  |
| barbican|   11 |  6 |13 | migration in progress | Doug 
Hellmann  |
| blazar  |   16 |  0 |16 | migration in progress | Nguyen 
Hai |
| Chef OpenStack  |0 |  0 | 1 | DONE  | Doug 
Hellmann  |
| cinder  |8 |  6 |22 | migration in progress | Doug 
Hellmann  |
| cloudkitty  |0 |  0 |17 | DONE  | Doug 
Hellmann  |
| congress|0 |  0 |16 | DONE  | Nguyen 
Hai |
| cyborg  |0 |  0 | 9 | DONE  | Nguyen 
Hai |
| designate   |0 |  0 |17 | DONE  | Nguyen 
Hai |
| Documentation   |0 |  0 |12 | DONE  | Doug 
Hellmann  |
| dragonflow  |1 |  0 | 4 | migration in progress | Nguyen 
Hai |
| ec2-api |0 |  0 | 7 | DONE  | 
   |
| freezer |5 |  2 |23 | migration in progress | 
   |
| glance  |   16 |  0 |16 | migration in progress | Nguyen 
Hai |
| heat|5 |  3 |27 | migration in progress | Doug 
Hellmann  |
| horizon |0 |  0 | 8 | DONE  | Nguyen 
Hai |
| I18n|0 |  0 | 2 | DONE  | Doug 
Hellmann  |
| InteropWG   |0 |  0 | 4 | DONE  | Doug 
Hellmann  |
| ironic  |   15 |  3 |60 | migration in progress | Doug 
Hellmann  |
| karbor  |   15 |  0 |15 | migration in progress | Nguyen 
Hai |
| keystone|3 |  1 |30 | migration in progress | Doug 
Hellmann  |
| kolla   |0 |  0 | 8 | DONE  | 
   |
| kuryr   |5 |  4 |16 | migration in progress | Doug 
Hellmann  |
| magnum  |7 |  2 |17 | migration in progress | 
   |
| manila  |6 |  3 |19 | migration in progress | Goutham 
Pacha Ravi |
| masakari|   16 |  0 |18 | migration in progress | Nguyen 
Hai |
| mistral |0 |  0 |25 | DONE  | Nguyen 
Hai |
| monasca |3 |  3 |66 | migration in progress | Doug 
Hellmann  |
| murano  |0 |  0 |25 | DONE  | 
   |
| neutron |   31 | 19 |74 | migration in progress | Doug 
Hellmann  |
| nova|   15 |  0 |23 | migration in progress | 
   |
| octavia |0 |  0

Re: [openstack-dev] [tripleo] VFs not configured in SR-IOV role

2018-09-12 Thread Samuel Monderer

Adding the following to neutron-sriov.yaml solved the problem
OS::TripleO::Services::NeutronSriovHostConfig:
../../puppet/services/neutron-sriov-host-config.yaml

On Wed, Sep 12, 2018 at 11:53 AM Samuel Monderer <
smonde...@vasonanetworks.com> wrote:

> Hi Saravanan,
>
> I'm using RHOSP13.
> The neutron-sriov-agent.yaml is missing "OS::TripleO::Services::
> NeutronSriovHostConfig"
>
> Regards,
> Samuel
>
> On Fri, Sep 7, 2018 at 1:08 PM Saravanan KR  wrote:
>
>> Not sure which version you are using, but the service
>> "OS::TripleO::Services::NeutronSriovHostConfig" is responsible for
>> setting up VFs. Check if this service is enabled in the deployment.
>> One of the missing place is being fixed -
>> https://review.openstack.org/#/c/597985/
>>
>> Regards,
>> Saravanan KR
>> On Tue, Sep 4, 2018 at 8:58 PM Samuel Monderer
>>  wrote:
>> >
>> > Hi,
>> >
>> > Attached is the used to deploy an overcloud with SR-IOV role.
>> > The deployment completed successfully but the VFs aren't configured on
>> the host.
>> > Can anyone have a look at what I missed.
>> >
>> > Thanks
>> > Samuel
>> > 
>> __
>> > OpenStack Development Mailing 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] [openstack][infra]Including Functional Tests in Coverage

2018-09-12 Thread reedip banerjee

Hi All,

Has anyone ever experimented with including Functional Tests with
openstack-tox-cover job?
We would like to include Functional tests in the coverage jobs and already
have a dsvm-functional job in place. However,  openstack-tox-cover is , if
I am correct, an infra job which is directly called.

Has anyone tried to include the functional tests and all its pre-requisites
in the cover job? If so, any pointers would be great


-- 
Thanks and Regards,
Reedip Banerjee
IRC: reedipb
__
OpenStack Development Mailing 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] Committing proprietary plugins to OpenStack