Re: [openstack-dev] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Ghanshyam Mann]

  On Fri, 07 Sep 2018 04:41:32 +0900 Eric Fried  wrote 
 
 > Jichen-
 > 
 > That patch is not ever intended to merge; hope that was clear from the
 > start :) It was just a proving ground to demonstrate which tests still
 > pass when there's effectively no compute driver in play.
 > 
 > We haven't taken any action on this from our end, though we have done a
 > little brainstorming about how we would tool our CI to skip those tests
 > most (but not all) of the time. Happy to share our experiences with you
 > if/as we move forward with that.
 > 
 > Regarding the tempest-level automation, I certainly had z in mind when
 > I was thinking about it. If you have the time and inclination to help
 > look into it, that would be most welcome.

Sorry for late response, somehow i missed this thread. As you mentioned and 
noticed in your patch that there are ~700 tests which does not touch compute 
driver. Most of them are from neutron-tempest-plugins or other service tests. 
From Tempest compute tests, many of them are negative tests or DB layer tests 
[1].

neutron-tempest-plugin or other service test you can always avoid to run with 
regex. And i do not think compute negative or DB test will take much time to 
run. But still if you want to avoid to run then, I think it is easy to maintain 
a whitelist regex file on CI side which can run only compute driver tests(61 in 
this case). 

Tagging compute driver on tempest side is little hard to maintain i feel and it 
can goes out of date very easily. If you have any other idea on that, we can 
surly talk in PTG on this. 

[1] 
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz

 > 
 > Thanks,
 > efried
 > 
 > On 09/06/2018 12:33 AM, Chen CH Ji wrote:
 > > I see the patch is still ongoing status and do you have a follow up
 > > plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
 > > so skip non-compute related cases will be a good for 3rd part CI .. thanks
 > > 
 > > Best Regards!
 > > 
 > > Kevin (Chen) Ji 纪 晨
 > > 
 > > Engineer, zVM Development, CSTL
 > > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
 > > Phone: +86-10-82451493
 > > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
 > > District, Beijing 100193, PRC
 > > 
 > > Inactive hide details for Eric Fried ---09/04/2018 09:35:09 PM---Folks-
 > > The other day, I posted an experimental patch [1] withEric Fried
 > > ---09/04/2018 09:35:09 PM---Folks- The other day, I posted an
 > > experimental patch [1] with an effectively
 > > 
 > > From: Eric Fried 
 > > To: "OpenStack Development Mailing List (not for usage questions)"
 > > 
 > > Date: 09/04/2018 09:35 PM
 > > Subject: [openstack-dev] [tempest][CI][nova compute] Skipping
 > > non-compute-driver tests
 > > 
 > > 
 > > 
 > > 
 > > 
 > > Folks-
 > > 
 > > The other day, I posted an experimental patch [1] with an effectively
 > > empty ComputeDriver (just enough to make n-cpu actually start) to see
 > > how much of our CI would pass. The theory being that any tests that
 > > still pass are tests that don't touch our compute driver, and are
 > > therefore not useful to run in our CI environment. Because anything that
 > > doesn't touch our code should already be well covered by generic
 > > dsvm-tempest CIs. The results [2] show that 707 tests still pass.
 > > 
 > > So I'm wondering whether there might be a way to mark tests as being
 > > "compute driver-specific" such that we could switch off all the other
 > > ones [3] via a one-line conf setting. Because surely this has potential
 > > to save a lot of CI resource not just for us but for other driver
 > > vendors, in tree and out.
 > > 
 > > Thanks,
 > > efried
 > > 
 > > [1] https://review.openstack.org/#/c/599066/
 > > [2]
 > > http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz
 > > [3] I get that there's still value in running all those tests. But it
 > > could be done like once every 10 or 50 or 100 runs instead of every time.
 > > 
 > > __
 > > OpenStack Development Mailing 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:unsubsc

[openstack-dev] [Searchlight] Cancel team meeting next week

[Trinh Nguyen]

Hi team,

Due to the Denver PTG next week (Sep 10 - Sep 14), we will cancel our team
meeting on Thursday, 13 Sep.

Cheers,

*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

Re: [openstack-dev] [blazar] about reservation

[Masahito MUROI]

Hello Jaze,

In general, Blazar ensures its instance scheduling by a combination of 
its flavor or scheduler hint and Nova scheduler filter.


In case of the instance reservation, a instance with the flavor is 
scheduled to a reserved slot on a specific hypervisor. Please see the 
spec page for the details.


https://docs.openstack.org/blazar/latest/specs/pike/new-instance-reservation.html

best regards,
Masahito

On 2018/09/06 16:52, Jaze Lee wrote:

Hello,
I view the source code and do not find the check logic for
reservation a instance. It just create a lease, and nova just create a
flavor.
How do we ensure the resource is really reserved for us?
We put the host into a new aggregate? and nobody except blazar will use
the host?





__
OpenStack Development Mailing 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] [product] Retiring development-proposals

[Andreas Jaeger]

The product WG is abandoned, so it's time to retire the 
development-proposals repository.


The content of the WG is published and thus available for reference:
http://specs.openstack.org/openstack/development-proposals/

I've started the retirement process using topic retire-productwg 
following 
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project ,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

[Tony Breeds]

On Wed, Sep 05, 2018 at 10:54:25AM +0100, Dougal Matthews wrote:
> On 5 September 2018 at 10:52, Dougal Matthews  wrote:
> 
> > (Note: I added [release] to the email subject, as I think that will make
> > it visible to the right folks.)
> >
> 
> Darn. It should have been [stable]. I have added that now. Sorry for the
> noise.

Backporting a migration like that is OK as long as you don't skip
migrations, that is to say revision '030' of the database should be the
same on all branches.  Given we've only just released rocky I expect
that will be the case here.

You absolutely must have a release note and call it out as upgrade impact
and of course this is a minor release not a patch release.

If y'all push a release note (probably on master too?) then I'm okay
with the backport and release

Yours Tony.


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] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked

[Tony Breeds]

On Thu, Sep 06, 2018 at 01:33:12PM +0300, Michel Peterson wrote:

> I remember that before landing the problematic patch [1] there was some
> discussion around it. Basically the problem was not n-odl but ceilometer
> not being in pypi, but we never foresaw this problem.
> 
> Now that the problem is so critical, the question is how can we, from the
> n-odl team, help in fixing this? I am open to help in any effort that
> involves n-odl or any other project.

As other have pointed out we can just ask the Telemetry team (PTL on CC)
why we can't publish ceilometer to pypi?
https://pypi.org/project/ceilometer/ certainly seems to be the right
project.

The crux of the code issue is:
from ceilometer.network.statistics import driver

in networking_odl/ceilometer/network/statistics/opendaylight_v2/driver.py

If this is supposed to be used they way you are how are prjects supposed
to get the ceilometer code?



Yours Tony.


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] [publiccloud-wg]PTG session prep

[Zhipeng Huang]

Hi Folks,

For those of you are interested in the openstack public cloud, please take
a look at the etherpad for our agenda[0] , you are more than welcomed to
suggest/add new topics !

[0] https://etherpad.openstack.org/p/publiccloud-wg-stein-ptg

-- 
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] [qa] Canceling next week QA office hours due to PTG

[Ghanshyam Mann]

Hi All,

As many of the QA folks will be in PTG, I am canceling the QA office hours for 
next week. Same will be resumed after PTG on   20th Sept. 

-gmann





__
OpenStack Development Mailing 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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hey gilles,

Thanks your introduction for GraphQL and Relay.

> GraphQL and OpenAPI have a different feature scope and both have pros and
cons.

I totally agree with you. They can work together.
Right now, I think we have no more work to adapt OpenStack APIs for Open
API.
Firstly we could sort out Open API schemas base on the current OpenStack
APIs.
and then we can discuss how to use it.
About the micro version, we discuss with your team mate dmitry in another
email [1]

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

Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 8:37 AM Gilles Dubreuil  wrote:

>
>
> On 30/08/18 13:56, Edison Xiang wrote:
>
> Hi Ed Leafe,
>
> Thanks your reply.
> Open API defines a standard interface description for REST APIs.
> Open API 3.0 can make a description(schema) for current OpenStack REST API.
> It will not change current OpenStack API.
> I am not a GraphQL expert. I look up something about GraphQL.
> In my understanding, GraphQL will get current OpenAPI together and provide
> another APIs based on Relay,
>
>
> Not sure what you mean here, could you please develop?
>
>
> and Open API is used to describe REST APIs and GraphQL is used to describe
> Relay APIs.
>
>
> There is no such thing as "Relay APIs".
> GraphQL povides a de-facto API Schema and Relay provides extensions on top
> to facilitate re-fetching, paging and more.
> GraphQL and OpenAPI have a different feature scope and both have pros and
> cons.
> GraphQL is delivering API without using REST verbs as all requests are
> undone using POST and its data.
> Beyond that what would be great (and it will ultimately come) is to have
> both of them working together.
>
> The idea of the GraphQL Proof of Concept is see what it can bring and at
> what cost such as effort and trade-offs.
> And to compare this against the effort to adapt OpenStack APIs to use Open
> API.
>
> BTW what's the status of Open API 3.0 in regards of Microversion?
>
> Regards,
> Gilles
>
>
> Best Regards,
> Edison Xiang
>
> On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe  wrote:
>
>> On Aug 29, 2018, at 1:36 AM, Edison Xiang  wrote:
>> >
>> > As we know, Open API 3.0 was released on July, 2017, it is about one
>> year ago.
>> > Open API 3.0 support some new features like anyof, oneof and allof than
>> Open API 2.0(Swagger 2.0).
>> > Now OpenStack projects do not support Open API.
>> > Also I found some old emails in the Mail List about supporting Open API
>> 2.0 in OpenStack.
>>
>> There is currently an effort by some developers to investigate the
>> possibility of using GraphQL with OpenStack APIs. What would Open API 3.0
>> provide that GraphQL would not? I’m asking because I don’t know enough
>> about Open API to compare them.
>>
>>
>> -- 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
>>
>
>
> __
> 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
>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gil...@redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] about unified limits

[Jaze Lee]

Lance Bragstad  于2018年9月6日周四 下午10:01写道：
>
> I wish there was a better answer for this question, but currently there are 
> only a handful of us working on the initiative. If you, or someone you know, 
> is interested in getting involved, I'll happily help onboard people.

Well，I can recommend some my colleges to work on this. I wish in S,
all service can use unified limits to do quota job.

>
> On Wed, Sep 5, 2018 at 8:52 PM Jaze Lee  wrote:
>>
>> On Stein only one service?
>> Is there some methods to move this more fast?
>> Lance Bragstad  于2018年9月5日周三 下午9:29写道：
>> >
>> > Not yet. Keystone worked through a bunch of usability improvements with 
>> > the unified limits API last release and created the oslo.limit library. We 
>> > have a patch or two left to land in oslo.limit before projects can really 
>> > start using unified limits [0].
>> >
>> > We're hoping to get this working with at least one resource in another 
>> > service (nova, cinder, etc...) in Stein.
>> >
>> > [0] 
>> > https://review.openstack.org/#/q/status:open+project:openstack/oslo.limit+branch:master+topic:limit_init
>> >
>> > On Wed, Sep 5, 2018 at 5:20 AM Jaze Lee  wrote:
>> >>
>> >> Hello,
>> >> Does nova and cinder  use keystone's unified limits api to do quota 
>> >> job?
>> >> If not, is there a plan to do 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
>> >
>> > __
>> > OpenStack Development Mailing 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] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[Erik McCormick]

On Thu, Sep 6, 2018, 8:40 PM Rochelle Grober 
wrote:

> Sounds like an important discussion to have with the operators in Denver.
> Should put this on the schedule for the Ops meetup.
>
> --Rocky
>

We are planning to attend the upgrade sessions on Monday as a group. How
about we put it there?

-Erik


>
> > -Original Message-
> > From: Matt Riedemann [mailto:mriede...@gmail.com]
> > Sent: Thursday, September 06, 2018 1:59 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > ; openstack-
> > operat...@lists.openstack.org
> > Subject: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-
> > specific news on extraction
> >
> > I wanted to recap some upgrade-specific stuff from today outside of the
> > other [1] technical extraction thread.
> >
> > Chris has a change up for review [2] which prompted the discussion.
> >
> > That change makes placement only work with placement.conf, not
> > nova.conf, but does get a passing tempest run in the devstack patch [3].
> >
> > The main issue here is upgrades. If you think of this like deprecating
> config
> > options, the old config options continue to work for a release and then
> are
> > dropped after a full release (or 3 months across boundaries for CDers)
> [4].
> > Given that, Chris's patch would break the standard deprecation policy.
> Clearly
> > one simple way outside of code to make that work is just copy and rename
> > nova.conf to placement.conf and voila. But that depends on *all*
> > deployment/config tooling to get that right out of the gate.
> >
> > The other obvious thing is the database. The placement repo code as-is
> > today still has the check for whether or not it should use the placement
> > database but falls back to using the nova_api database [5]. So
> technically you
> > could point the extracted placement at the same nova_api database and it
> > should work. However, at some point deployers will clearly need to copy
> the
> > placement-related tables out of the nova_api DB to a new placement DB and
> > make sure the 'migrate_version' table is dropped so that placement DB
> > schema versions can reset to 1.
> >
> > With respect to grenade and making this work in our own upgrade CI
> testing,
> > we have I think two options (which might not be mutually
> > exclusive):
> >
> > 1. Make placement support using nova.conf if placement.conf isn't found
> for
> > Stein with lots of big warnings that it's going away in T. Then Rocky
> nova.conf
> > with the nova_api database configuration just continues to work for
> > placement in Stein. I don't think we then have any grenade changes to
> make,
> > at least in Stein for upgrading *from* Rocky. Assuming fresh devstack
> installs
> > in Stein use placement.conf and a placement-specific database, then
> > upgrades from Stein to T should also be OK with respect to grenade, but
> > likely punts the cut-over issue for all other deployment projects
> (because we
> > don't CI with grenade doing
> > Rocky->Stein->T, or FFU in other words).
> >
> > 2. If placement doesn't support nova.conf in Stein, then grenade will
> require
> > an (exceptional) [6] from-rocky upgrade script which will (a) write out
> > placement.conf fresh and (b) run a DB migration script, likely housed in
> the
> > placement repo, to create the placement database and copy the placement-
> > specific tables out of the nova_api database. Any script like this is
> likely
> > needed regardless of what we do in grenade because deployers will need to
> > eventually do this once placement would drop support for using nova.conf
> (if
> > we went with option 1).
> >
> > That's my attempt at a summary. It's going to be very important that
> > operators and deployment project contributors weigh in here if they have
> > strong preferences either way, and note that we can likely do both
> options
> > above - grenade could do the fresh cutover from rocky to stein but we
> allow
> > running with nova.conf and nova_api DB in placement in stein with plans
> to
> > drop that support in T.
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-dev/2018-
> > September/subject.html#134184
> > [2] https://review.openstack.org/#/c/600157/
> > [3] https://review.openstack.org/#/c/600162/
> > [4]
> > https://governance.openstack.org/tc/reference/tags/assert_follows-
> > standard-deprecation.html#requirements
> > [5]
> > https://github.com/openstack/placement/blob/fb7c1909/placement/db_api
> > .py#L27
> > [6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-
> > upgrade
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> > __
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Devel

Re: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[Rochelle Grober]

Sounds like an important discussion to have with the operators in Denver. 
Should put this on the schedule for the Ops meetup.

--Rocky

> -Original Message-
> From: Matt Riedemann [mailto:mriede...@gmail.com]
> Sent: Thursday, September 06, 2018 1:59 PM
> To: OpenStack Development Mailing List (not for usage questions)
> ; openstack-
> operat...@lists.openstack.org
> Subject: [openstack-dev] [nova][placement][upgrade][qa] Some upgrade-
> specific news on extraction
> 
> I wanted to recap some upgrade-specific stuff from today outside of the
> other [1] technical extraction thread.
> 
> Chris has a change up for review [2] which prompted the discussion.
> 
> That change makes placement only work with placement.conf, not
> nova.conf, but does get a passing tempest run in the devstack patch [3].
> 
> The main issue here is upgrades. If you think of this like deprecating config
> options, the old config options continue to work for a release and then are
> dropped after a full release (or 3 months across boundaries for CDers) [4].
> Given that, Chris's patch would break the standard deprecation policy. Clearly
> one simple way outside of code to make that work is just copy and rename
> nova.conf to placement.conf and voila. But that depends on *all*
> deployment/config tooling to get that right out of the gate.
> 
> The other obvious thing is the database. The placement repo code as-is
> today still has the check for whether or not it should use the placement
> database but falls back to using the nova_api database [5]. So technically you
> could point the extracted placement at the same nova_api database and it
> should work. However, at some point deployers will clearly need to copy the
> placement-related tables out of the nova_api DB to a new placement DB and
> make sure the 'migrate_version' table is dropped so that placement DB
> schema versions can reset to 1.
> 
> With respect to grenade and making this work in our own upgrade CI testing,
> we have I think two options (which might not be mutually
> exclusive):
> 
> 1. Make placement support using nova.conf if placement.conf isn't found for
> Stein with lots of big warnings that it's going away in T. Then Rocky 
> nova.conf
> with the nova_api database configuration just continues to work for
> placement in Stein. I don't think we then have any grenade changes to make,
> at least in Stein for upgrading *from* Rocky. Assuming fresh devstack installs
> in Stein use placement.conf and a placement-specific database, then
> upgrades from Stein to T should also be OK with respect to grenade, but
> likely punts the cut-over issue for all other deployment projects (because we
> don't CI with grenade doing
> Rocky->Stein->T, or FFU in other words).
> 
> 2. If placement doesn't support nova.conf in Stein, then grenade will require
> an (exceptional) [6] from-rocky upgrade script which will (a) write out
> placement.conf fresh and (b) run a DB migration script, likely housed in the
> placement repo, to create the placement database and copy the placement-
> specific tables out of the nova_api database. Any script like this is likely
> needed regardless of what we do in grenade because deployers will need to
> eventually do this once placement would drop support for using nova.conf (if
> we went with option 1).
> 
> That's my attempt at a summary. It's going to be very important that
> operators and deployment project contributors weigh in here if they have
> strong preferences either way, and note that we can likely do both options
> above - grenade could do the fresh cutover from rocky to stein but we allow
> running with nova.conf and nova_api DB in placement in stein with plans to
> drop that support in T.
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-
> September/subject.html#134184
> [2] https://review.openstack.org/#/c/600157/
> [3] https://review.openstack.org/#/c/600162/
> [4]
> https://governance.openstack.org/tc/reference/tags/assert_follows-
> standard-deprecation.html#requirements
> [5]
> https://github.com/openstack/placement/blob/fb7c1909/placement/db_api
> .py#L27
> [6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-
> upgrade
> 
> --
> 
> Thanks,
> 
> Matt
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][tc][election] TC Election Campaigning Period

[Emmet Hikory]

Developers,
The TC Election Campaigning Period has now started (1).  During the next
couple days, you are all encouraged to ask the candidates questions about
their platforms (2), opinions on OpenStack, community governance, and anything
else that will help you to better determine how you will vote.  This is the
time to raise any issues you wish the future TC to consider, and to evaluate
the opinions of the nominees prior to their election.

Candidates,
Each of you has posted a platform (2), and announced your nomination to
the developers.  From this point, you are encouraged to ask each other
questions about the posted platforms, and begin discussion of any points
that you feel are particularly important during the next cycle.  While you
are not yet TC members, your voices and opinions about the issues raised in
your platforms and questions raised by the wider community will help ensure
that the future TC has the widest possible input on the matters of community
concern, and the electorate has the best information to determine the ideal
TC composition to address these and other issues that may arise.

Scheduling Note:
This cycle, the campaigning season overlaps with PTG.  While our
community strives to have many of our persistent communications in fora that
permit participation by all, in-person discussions on some issues raised in
campaigning will be inevitable.  For those that are attending PTG, if you
feel that an in-person discussion related to campaigning is of interest to
the wider community, please summarise it to the mailing list.  For those not
attending, if you have a query raised on the mailing list that you feel is
not receiving attention, consider asking someone attending PTG to relay the
question to a candidate.

1: https://governance.openstack.org/election/
2: http://git.openstack.org/cgit/openstack/election/tree/candidates/stein/TC

-- 
Emmet HIKORY


__
OpenStack Development Mailing 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][Searchlight] Commits of searchlight-specs are not attached to the story

[Trinh Nguyen]

Hi Jeremy,

Oops. Thanks. I didn't notice that :)


*Trinh Nguyen *| Founder & Chief Architect



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



On Fri, Sep 7, 2018 at 2:04 AM Jeremy Stanley  wrote:

> On 2018-09-06 16:39:13 +0900 (+0900), Trinh Nguyen wrote:
> > Looks like the commits for searchlight-specs are not attached to
> > the story on Storyboard. Example:
> >
> > Commit: https://review.openstack.org/#/c/600316/
> > Story: https://storyboard.openstack.org/#!/story/2003677
> >
> > Is there anything that I need to do to link those 2 together?
>
> In change 600316 you included a "Task: #2619" footer, when the
> actual task you seem to have wanted to reference was 26199 (task
> 2619 is associated with unrelated story 2000403).
> --
> 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

[openstack-dev] [TC][All] Nominations End & Campaigning Begins

[Kendall Nelson]

Hello All!

The TC Nomination period is now over. The official candidate list is
available on the election website[0].

Now begins the campaigning period where candidates and electorate may
debate their statements.

Polling will start Sep 18, 2018 23:45 UTC.

Thank you,
-The Election Officials

[0] http://governance.openstack.org/election/#stein-tc-candidates
__
OpenStack Development Mailing 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] [stable][keystone] python3 goal progress and tox_install.sh removal

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-09-06 15:01:01 -0500:
> I'm noticing some odd cases with respect to the python 3 community goal
> [0]. So far my findings are specific to keystone repositories, but I can
> imagine this affecting other projects.
> 
> Doug generated the python 3 reviews for keystone repositories, including
> the ones for stable branches. We noticed some issues with the ones proposed
> to stable (keystoneauth, python-keystoneclient) and master
> (keystonemiddleware). For example, python-keystoneclient's stable/pike [1]
> and stable/ocata [2] branches are both failing with something like [3]:
> 
> ERROR: You must give at least one requirement to install (see "pip help
> install")
> 
> Both of those branches still use tox_install.sh [4][5]. Master,
> stable/rocky, and stable/queens do not, which passed fine. It was suggested
> that we backport patches to the failing branches that remove tox_install.sh
> (similar to [6]). I've attempted to do this for python-keystoneclient,
> keystonemiddleware, and keystoneauth.
> 
> The keystonemiddleware patches specifically are hitting a weird case, where
> they either fail tests due to issues installing keystonemiddleware itself,

The "installing itself" problem is related to the fact that the library
under test is also listed in the constraints list and the deps list in
tox.ini contains ".[audit_notifications]", which tries to install the
library under test while the library is constrained.

The simplest thing to do to fix that is probably just add those
test dependencies to test-requirements.txt.

> or pass tests and fail the requirements check. I'm guessing (because I

The requirements check looks legit:

  Requirement for package stestr has no lower bound

And I indeed don't see a >= value for stestr in the
test-requirements.txt file.

> don't really fully understand the whole issue yet) this is because
> keystonemiddleware has an optional dependency for tests and somehow the
> installation process worked with tox_install.sh and doesn't work with the
> new way we do things with pip and zuul.
> 
> I've attempted to remove tox_install.sh using several approaches with
> keystonemiddleware master [7]. None of which passed both unit tests and the
> requirements check.
> 
> I'm wondering if anyone has a definitive summary or context on
> tox_install.sh and removing it cleanly for cases like keystonemiddleware.
> Additionally, is anyone else noticing issues like this with their stable
> branches?
> 
> [0] https://governance.openstack.org/tc/goals/stein/python3-first.html
> [1] https://review.openstack.org/#/c/597685/
> [2] https://review.openstack.org/#/c/597679/
> [3]
> http://logs.openstack.org/85/597685/1/check/build-openstack-sphinx-docs/4f817dd/job-output.txt.gz#_2018-08-29_20_49_17_877448
> [4]
> https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/pike
> [5]
> https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/ocata
> [6] https://review.openstack.org/#/c/524828/3
> [7] https://review.openstack.org/#/c/599003/

__
OpenStack Development Mailing 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 Summit Forum in Berlin: Topic Selection Process

[Jeremy Stanley]

On 2018-09-06 15:03:52 -0500 (-0500), Matt Riedemann wrote:
> On 9/6/2018 2:56 PM, Jeremy Stanley wrote:
> > On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:
> > > On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
> > > > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur  > > > > wrote:
> > > > 
> > > > 
> > > >  Examples of typical sessions that make for a great Forum:
> > > > 
> > > >  Strategic, whole-of-community discussions, to think about the big
> > > >  picture, including beyond just one release cycle and new 
> > > > technologies
> > > > 
> > > >  e.g. OpenStack One Platform for containers/VMs/Bare Metal 
> > > > (Strategic
> > > >  session) the entire community congregates to share opinions on how
> > > >  to make OpenStack achieve its integration engine goal
> > > > 
> > > > 
> > > > Just to clarify some speculation going on in IRC: this is an example,
> > > > right? Not a new thing being announced?
> > > > 
> > > > // jim
> > > FYI for those that didn't see this on the other ML:
> > > 
> > > http://lists.openstack.org/pipermail/foundation/2018-August/002617.html
> > [...]
> > 
> > While I agree that's a great post to point out to all corners of the
> > community, I don't see what it has to do with whether "OpenStack One
> > Platform for containers/VMs/Bare Metal" was an example forum topic.
> 
> Because if I'm not mistaken it was the impetus for the hullabaloo in the tc
> channel that was related to the foundation ML post.

It would be more accurate to say that community surprise over the
StarlingX mention in Vancouver keynotes caused some people to
(either actually or merely in half-jest) start looking for subtext
everywhere indicating the next big surprise announcement. The
discussion[*] in #openstack-tc readily acknowledged that most of its
participants didn't think "OpenStack One Platform for
containers/VMs/Bare Metal" was an actual proposal for a forum
discussion much less announcement of a new project, but were just
looking for an opportunity to show feigned alarm and sarcasm.

The most recent discussion[**] leading up to the foundation ML "OSF
Open Infrastructure Projects" update occurred the previous week.
That E-mail did go out the day after the forum topic brainstorming
example discussion, but was unrelated (and already in the process of
being put together by then).

[*] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-29.log.html#t2018-08-29T16:55:37
[**] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-23.log.html#t2018-08-23T16:23:00
-- 
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] [nova][placement][upgrade][qa] Some upgrade-specific news on extraction

[Matt Riedemann]

I wanted to recap some upgrade-specific stuff from today outside of the 
other [1] technical extraction thread.


Chris has a change up for review [2] which prompted the discussion.

That change makes placement only work with placement.conf, not 
nova.conf, but does get a passing tempest run in the devstack patch [3].


The main issue here is upgrades. If you think of this like deprecating 
config options, the old config options continue to work for a release 
and then are dropped after a full release (or 3 months across boundaries 
for CDers) [4]. Given that, Chris's patch would break the standard 
deprecation policy. Clearly one simple way outside of code to make that 
work is just copy and rename nova.conf to placement.conf and voila. But 
that depends on *all* deployment/config tooling to get that right out of 
the gate.


The other obvious thing is the database. The placement repo code as-is 
today still has the check for whether or not it should use the placement 
database but falls back to using the nova_api database [5]. So 
technically you could point the extracted placement at the same nova_api 
database and it should work. However, at some point deployers will 
clearly need to copy the placement-related tables out of the nova_api DB 
to a new placement DB and make sure the 'migrate_version' table is 
dropped so that placement DB schema versions can reset to 1.


With respect to grenade and making this work in our own upgrade CI 
testing, we have I think two options (which might not be mutually 
exclusive):


1. Make placement support using nova.conf if placement.conf isn't found 
for Stein with lots of big warnings that it's going away in T. Then 
Rocky nova.conf with the nova_api database configuration just continues 
to work for placement in Stein. I don't think we then have any grenade 
changes to make, at least in Stein for upgrading *from* Rocky. Assuming 
fresh devstack installs in Stein use placement.conf and a 
placement-specific database, then upgrades from Stein to T should also 
be OK with respect to grenade, but likely punts the cut-over issue for 
all other deployment projects (because we don't CI with grenade doing 
Rocky->Stein->T, or FFU in other words).


2. If placement doesn't support nova.conf in Stein, then grenade will 
require an (exceptional) [6] from-rocky upgrade script which will (a) 
write out placement.conf fresh and (b) run a DB migration script, likely 
housed in the placement repo, to create the placement database and copy 
the placement-specific tables out of the nova_api database. Any script 
like this is likely needed regardless of what we do in grenade because 
deployers will need to eventually do this once placement would drop 
support for using nova.conf (if we went with option 1).


That's my attempt at a summary. It's going to be very important that 
operators and deployment project contributors weigh in here if they have 
strong preferences either way, and note that we can likely do both 
options above - grenade could do the fresh cutover from rocky to stein 
but we allow running with nova.conf and nova_api DB in placement in 
stein with plans to drop that support in T.


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

[2] https://review.openstack.org/#/c/600157/
[3] https://review.openstack.org/#/c/600162/
[4] 
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements
[5] 
https://github.com/openstack/placement/blob/fb7c1909/placement/db_api.py#L27

[6] https://docs.openstack.org/grenade/latest/readme.html#theory-of-upgrade

--

Thanks,

Matt

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

[openstack-dev] [openstack-helm] [Openstack-Helm] Denver PTG Schedule

[Pete Birley]

Hey!

The Openstack-Helm team has put together a rough schedule and outline for
the PTG:

   - https://etherpad.openstack.org/p/openstack-helm-ptg-stein

Really looking forward to seeing everyone all in Denver :)

Cheers

Pete
__
OpenStack Development Mailing 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] [stable][keystone] python3 goal progress and tox_install.sh removal

[Ben Nemec]

On 09/06/2018 03:01 PM, Lance Bragstad wrote:
I'm noticing some odd cases with respect to the python 3 community goal 
[0]. So far my findings are specific to keystone repositories, but I can 
imagine this affecting other projects.


Doug generated the python 3 reviews for keystone repositories, including 
the ones for stable branches. We noticed some issues with the ones 
proposed to stable (keystoneauth, python-keystoneclient) and master 
(keystonemiddleware). For example, python-keystoneclient's stable/pike 
[1] and stable/ocata [2] branches are both failing with something like [3]:


ERROR: You must give at least one requirement to install (see "pip help 
install")


We ran into this on the Oslo stable branches too. Instead of trying to 
migrate everything, we just tweaked tox_install.sh to avoid the problem: 
https://github.com/openstack/oslo.concurrency/commit/a009e7c86901473ac2273cb9ba604dc2a6b579d3




Both of those branches still use tox_install.sh [4][5]. Master, 
stable/rocky, and stable/queens do not, which passed fine. It was 
suggested that we backport patches to the failing branches that remove 
tox_install.sh (similar to [6]). I've attempted to do this for 
python-keystoneclient, keystonemiddleware, and keystoneauth.


The keystonemiddleware patches specifically are hitting a weird case, 
where they either fail tests due to issues installing keystonemiddleware 
itself, or pass tests and fail the requirements check. I'm guessing 
(because I don't really fully understand the whole issue yet) this is 
because keystonemiddleware has an optional dependency for tests and 
somehow the installation process worked with tox_install.sh and doesn't 
work with the new way we do things with pip and zuul.


I've attempted to remove tox_install.sh using several approaches with 
keystonemiddleware master [7]. None of which passed both unit tests and 
the requirements check.


I'm wondering if anyone has a definitive summary or context on 
tox_install.sh and removing it cleanly for cases like 
keystonemiddleware. Additionally, is anyone else noticing issues like 
this with their stable branches?


[0] https://governance.openstack.org/tc/goals/stein/python3-first.html
[1] https://review.openstack.org/#/c/597685/
[2] https://review.openstack.org/#/c/597679/
[3] 
http://logs.openstack.org/85/597685/1/check/build-openstack-sphinx-docs/4f817dd/job-output.txt.gz#_2018-08-29_20_49_17_877448
[4] 
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/pike
[5] 
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/ocata

[6] https://review.openstack.org/#/c/524828/3
[7] https://review.openstack.org/#/c/599003/


__
OpenStack Development Mailing 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 Summit Forum in Berlin: Topic Selection Process

[Matt Riedemann]

On 9/6/2018 2:56 PM, Jeremy Stanley wrote:

On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:

On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:

On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur mailto:ji...@openstack.org>> wrote:


 Examples of typical sessions that make for a great Forum:

 Strategic, whole-of-community discussions, to think about the big
 picture, including beyond just one release cycle and new technologies

 e.g. OpenStack One Platform for containers/VMs/Bare Metal (Strategic
 session) the entire community congregates to share opinions on how
 to make OpenStack achieve its integration engine goal


Just to clarify some speculation going on in IRC: this is an example,
right? Not a new thing being announced?

// jim

FYI for those that didn't see this on the other ML:

http://lists.openstack.org/pipermail/foundation/2018-August/002617.html

[...]

While I agree that's a great post to point out to all corners of the
community, I don't see what it has to do with whether "OpenStack One
Platform for containers/VMs/Bare Metal" was an example forum topic.


Because if I'm not mistaken it was the impetus for the hullabaloo in the 
tc channel that was related to the foundation ML post.


--

Thanks,

Matt

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

[openstack-dev] [stable][keystone] python3 goal progress and tox_install.sh removal

[Lance Bragstad]

I'm noticing some odd cases with respect to the python 3 community goal
[0]. So far my findings are specific to keystone repositories, but I can
imagine this affecting other projects.

Doug generated the python 3 reviews for keystone repositories, including
the ones for stable branches. We noticed some issues with the ones proposed
to stable (keystoneauth, python-keystoneclient) and master
(keystonemiddleware). For example, python-keystoneclient's stable/pike [1]
and stable/ocata [2] branches are both failing with something like [3]:

ERROR: You must give at least one requirement to install (see "pip help
install")

Both of those branches still use tox_install.sh [4][5]. Master,
stable/rocky, and stable/queens do not, which passed fine. It was suggested
that we backport patches to the failing branches that remove tox_install.sh
(similar to [6]). I've attempted to do this for python-keystoneclient,
keystonemiddleware, and keystoneauth.

The keystonemiddleware patches specifically are hitting a weird case, where
they either fail tests due to issues installing keystonemiddleware itself,
or pass tests and fail the requirements check. I'm guessing (because I
don't really fully understand the whole issue yet) this is because
keystonemiddleware has an optional dependency for tests and somehow the
installation process worked with tox_install.sh and doesn't work with the
new way we do things with pip and zuul.

I've attempted to remove tox_install.sh using several approaches with
keystonemiddleware master [7]. None of which passed both unit tests and the
requirements check.

I'm wondering if anyone has a definitive summary or context on
tox_install.sh and removing it cleanly for cases like keystonemiddleware.
Additionally, is anyone else noticing issues like this with their stable
branches?

[0] https://governance.openstack.org/tc/goals/stein/python3-first.html
[1] https://review.openstack.org/#/c/597685/
[2] https://review.openstack.org/#/c/597679/
[3]
http://logs.openstack.org/85/597685/1/check/build-openstack-sphinx-docs/4f817dd/job-output.txt.gz#_2018-08-29_20_49_17_877448
[4]
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/pike
[5]
https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/tools/tox_install.sh?h=stable/ocata
[6] https://review.openstack.org/#/c/524828/3
[7] https://review.openstack.org/#/c/599003/
__
OpenStack Development Mailing 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 Summit Forum in Berlin: Topic Selection Process

[Jeremy Stanley]

On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:
> On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
> > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur  > > wrote:
> > 
> > 
> > Examples of typical sessions that make for a great Forum:
> > 
> > Strategic, whole-of-community discussions, to think about the big
> > picture, including beyond just one release cycle and new technologies
> > 
> > e.g. OpenStack One Platform for containers/VMs/Bare Metal (Strategic
> > session) the entire community congregates to share opinions on how
> > to make OpenStack achieve its integration engine goal
> > 
> > 
> > Just to clarify some speculation going on in IRC: this is an example,
> > right? Not a new thing being announced?
> > 
> > // jim
> 
> FYI for those that didn't see this on the other ML:
> 
> http://lists.openstack.org/pipermail/foundation/2018-August/002617.html
[...]

While I agree that's a great post to point out to all corners of the
community, I don't see what it has to do with whether "OpenStack One
Platform for containers/VMs/Bare Metal" was an example forum topic.
-- 
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] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Eric Fried]

Jichen-

That patch is not ever intended to merge; hope that was clear from the
start :) It was just a proving ground to demonstrate which tests still
pass when there's effectively no compute driver in play.

We haven't taken any action on this from our end, though we have done a
little brainstorming about how we would tool our CI to skip those tests
most (but not all) of the time. Happy to share our experiences with you
if/as we move forward with that.

Regarding the tempest-level automation, I certainly had z in mind when
I was thinking about it. If you have the time and inclination to help
look into it, that would be most welcome.

Thanks,
efried

On 09/06/2018 12:33 AM, Chen CH Ji wrote:
> I see the patch is still ongoing status and do you have a follow up
> plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
> so skip non-compute related cases will be a good for 3rd part CI .. thanks
> 
> Best Regards!
> 
> Kevin (Chen) Ji 纪 晨
> 
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
> 
> Inactive hide details for Eric Fried ---09/04/2018 09:35:09 PM---Folks-
> The other day, I posted an experimental patch [1] withEric Fried
> ---09/04/2018 09:35:09 PM---Folks- The other day, I posted an
> experimental patch [1] with an effectively
> 
> From: Eric Fried 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 09/04/2018 09:35 PM
> Subject: [openstack-dev] [tempest][CI][nova compute] Skipping
> non-compute-driver tests
> 
> 
> 
> 
> 
> Folks-
> 
> The other day, I posted an experimental patch [1] with an effectively
> empty ComputeDriver (just enough to make n-cpu actually start) to see
> how much of our CI would pass. The theory being that any tests that
> still pass are tests that don't touch our compute driver, and are
> therefore not useful to run in our CI environment. Because anything that
> doesn't touch our code should already be well covered by generic
> dsvm-tempest CIs. The results [2] show that 707 tests still pass.
> 
> So I'm wondering whether there might be a way to mark tests as being
> "compute driver-specific" such that we could switch off all the other
> ones [3] via a one-line conf setting. Because surely this has potential
> to save a lot of CI resource not just for us but for other driver
> vendors, in tree and out.
> 
> Thanks,
> efried
> 
> [1] https://review.openstack.org/#/c/599066/
> [2]
> http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz
> [3] I get that there's still value in running all those tests. But it
> could be done like once every 10 or 50 or 100 runs instead of every time.
> 
> __
> OpenStack Development Mailing 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 Summit Forum in Berlin: Topic Selection Process

[Matt Riedemann]

On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur > wrote:



Examples of typical sessions that make for a great Forum:

Strategic, whole-of-community discussions, to think about the big
picture, including beyond just one release cycle and new technologies

e.g. OpenStack One Platform for containers/VMs/Bare Metal (Strategic
session) the entire community congregates to share opinions on how
to make OpenStack achieve its integration engine goal


Just to clarify some speculation going on in IRC: this is an example, 
right? Not a new thing being announced?


// jim


FYI for those that didn't see this on the other ML:

http://lists.openstack.org/pipermail/foundation/2018-August/002617.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

[openstack-dev] [manila] No meeting 13 September 2018

[Tom Barron]

Manila folks,

You likely already know, but we won't have our regular community 
meeting on irc next week because we'll be doing the PTG.


See you there!

-- Tom Barron (tbarron)


__
OpenStack Development Mailing 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] [election][tc] Announcing candidacy

[Rico Lin]

Dear all,

I'm announcing my candidacy for a position on the OpenStack Technical
Committee.

I'm Rico Lin. I have been in this community since 2014. And been

deeply involved with technical contributions [1], I start from working

with heat, which allows me to work on integration and management resources

from multiple projects.

I have served as Heat PTL for two years. Which allows me to learn

better on how we can join users and operators' experiences and requirements

and integrated with development workflow and technical decision processes.

Here are my major goals with this seat in TC:

* Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)

* Provide guidelines

* Strong the structure of SIGs

* Application Infra

* Cross-cooperation between Users, Operators, and Developers

* Diversity

I'm already trying to put my goals to actions, still would really hope to
join

Technical Committee to bring more attention to those domains

Thank you for your consideration.

Best Regards,

Rico Lin

IRC: ricolin

Twitter: @ricolintw

https://www.openstack.org/community/members/profile/33346/rico-lin

http://stackalytics.com/?release=all&user_id=rico-lin&metric=person-day


Here I put some explanations for my goals:

- Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV):

This is a long-term goal for our community, but would really like to see
this

getting more scenario for use cases, and a more clear target for
development.

As we talk about Edge, AI, etc. It's essential to bring real use cases

into this integration( like StarlingX bring some requirements cross-projects

to real use cases).

On the other hand, K8s-SIG, Self-healing sig, FEMDC SIG are all some nice

place for this kind of interacting and integrating to happen.


- Provide guidelines:

There is one WIP guideline from First Contact SIG I particular interesting

on. The `Guidelines for Organisations Contributing to OpenStack` [4]. This
is

something I believe is quite important for showing how can organizations

interacting with OpenStack community correctly. I try to work on the same

goal from event to event as well (give presentations like [5]). There are
some

other guidelines that need to update/renew as well (most of us, who already

reading ML and work in the community for long, might no longer require to
read

guidelines, but remember, whoever try to join now a day, still require an

up-to-date guideline to give them hints).


- Strong the structure of SIGs:

As I show in above two goals, SIGs plays some important roles. I do like to

trigger discussions on how can we strengthen the structure of SIGs. Make
them more

efficient and become someplace for users and ops can directly interact with

developers. For real use cases like an Edge computing use case issue, or

self-healing service issues. I can't think of a better place than FEMDC SIG

and Self-healing SIG to record and target these issues. We might be able to

allow Opts to feedback issues on SIG's StoryBoard and ask project teams to

connect and review with it. There might be multiple ways to do this. So

would really like to trigger this discussion.

- Application Infra:

We've updated our resolution with [3] and saying we care about what

applications needs on top of OpenStack. As for jobs from few projects are

taking the role and thinking about what application needs, we should provide

help with setting up community goals, making resolutions, or define what are

top priority applications (can be a short-term definition) we need to focus
on

and taking action items/guidelines and finding weaknesses, so others from

the community can follow (if they agree with the goals, but got no idea on
what

they can help, IMO this will be a good stuff).

- Cross-cooperation between Users, Operators, and Developers:

We have been losing some communication cross Users, Operators, and
Developers.

And it's never a good thing when users can share use cases, ops shares

experiences, developers shares code, but they won't make it to one another
not

if a user provides developers by them self. In this case, works like
StoryBoard

should be in our first priority. We need a more solid way to bring user
feedback

to developers, so we can actually learn what's working or not for each

feature. And maybe it's considerable, to strengthen the communication
between

TCs and UCs (User Committee). We take some steps (like merge PTG and

Ops-meetup) to this goal, but I believe we can make the interacting more
active.

- Diversity:

The math is easy. [2] shows we got around one-third of users from Asia (with

75% of users in China). Also IIRC, around the same percentage of developers.

But we got 0 in TC. The actual works are hard. We need forwards our

technical guideline to developers in Asia and provide chances to get more

feedback from them, so we can provide better technical resolutions which

should be able to tight developers all together. Which I think I'm a good

candidate for this.

[openstack-dev] [all][infra] Moving cover job from post to check pipeline

[Andreas Jaeger]

Citing Ian Wienand in [2]

"There was a thread some time ago that suggested coverage jobs weren't 
doing much in the "post" pipeline because nobody looks at them and the 
change numbers may be difficult to find anyway [1]. This came up again 
in a cleanup to add non-voting coverage jobs in 
I5c42530d1dda41b8dc8c13cdb10458745bec7bcc.


There really is no consistency across projects; it seems like a couple 
of different approaches have been cargo-cult copied as new projects came 
in, depending on which random project was used as a template. This 
change does a cleanup by moving all post coverage jobs into the check 
queue as non-voting jobs."


I've updated Ian's change [2] now and propose to move ahead with it - 
and suggest that projects with in-repo coverage job follow it as well. 
Let's use the new template [3] openstack-cover-jobs (and it's 
-horizon/-neutron variants) for this change.


Andreas

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099491.html
[2] https://review.openstack.org/#/c/432836/
[3] 
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-openstack-cover-jobs


--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [TripleO] Stein Forum @ Berlin Brainstorming

[Juan Antonio Osorio Robles]

Hey folks!

It's time to come up with topics to discuss on the forum in Berlin[1]!

There is an etherpad for us to bring up ideas:

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

We need to submit by September 12.

Here's is also the link to the wiki:

https://wiki.openstack.org/wiki/Forum/Berlin2018#Etherpads_from_Teams_and_Working_Groups

Best Regards


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



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

[openstack-dev] [octavia] Weekly IRC meeting cancelled Sept. 12th

[Michael Johnson]

Hello Octavia community,

As many of us will be attending the OpenStack PTG next week, I am
cancelling the weekly Octavia IRC meeting on September 12th.

We will resume our normal schedule on September 19th.

Michael

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

[openstack-dev] [TripleO] Meeting cancelled

[Juan Antonio Osorio Robles]

Due to folks being at the Denver PTG (including myself) there won't be
the weekly meeting next week.


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] [TripleO] Denver PTG Schedule

[Juan Antonio Osorio Robles]

Hello!


The Denver schedule is now available, still at the same link:
https://etherpad.openstack.org/p/tripleo-ptg-stein

And I also made a Google Calendar that folks can follow:
https://calendar.google.com/calendar?cid=MjdqZmUwNmN1dWhldDdjYm5vb3RvaGRyZTRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

In case you would prefer another tool, I also attached the ical file.


See you next week!


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

Re: [openstack-dev] [OpenStack-I18n] [storyboard] [I18n] Can Storyboard web pages be translatable to multiple languages?

[Jeremy Stanley]

On 2018-09-06 11:06:34 +0900 (+0900), Ian Y. Choi wrote:
> I wanna ask whether https://storyboard.openstack.org/ web pages
> can be translatable to multiple languages (e.g., Chinese,
> Japanese, Korean, German, French, Spanish, ...) or not.
[...]

As also discussed in #storyboard I think this is an interesting
idea, particularly for organizations who may want to use StoryBoard
deployments where most users are fluent in one of those other
languages (and perhaps not at all with English).

I do think interface translation is potentially useful for the
OpenStack community's storyboard.openstack.org service too, though
we'll want to keep in mind that for most of the projects hosted
there English is explicitly preferred to increase collaboration
(same as with most OpenStack community mailing lists, IRC channels,
code review and so on). We may discover that we need to find ways to
point out to people, particularly those arriving there for the first
time, that they should file stories in English if at all possible
even though the interface may be presented in their personally
preferred language instead.

I've added this topic to
https://etherpad.openstack.org/p/sb-stein-ptg-planning and am
looking forward to seeing you in Denver!
-- 
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] [all] Switching docs jobs to new tox-docs for specs repos

[Andreas Jaeger]

I've proposed two changes to change the docs building and publishing of 
specs repos to use the new PTI openstack-tox-docs job. This means that 
your the docs job will now run "tox -e docs". A quick check shows that 
all repos are set up properly - but if suddenly docs building fails for 
a specs repo, do the same kind of changes you did for your main repo 
when you switched to "publish-openstack-docs-pti" template.


The changes are:
https://review.openstack.org/600457
https://review.openstack.org/600458

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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][Searchlight] Commits of searchlight-specs are not attached to the story

[Jeremy Stanley]

On 2018-09-06 16:39:13 +0900 (+0900), Trinh Nguyen wrote:
> Looks like the commits for searchlight-specs are not attached to
> the story on Storyboard. Example:
> 
> Commit: https://review.openstack.org/#/c/600316/
> Story: https://storyboard.openstack.org/#!/story/2003677
> 
> Is there anything that I need to do to link those 2 together?

In change 600316 you included a "Task: #2619" footer, when the
actual task you seem to have wanted to reference was 26199 (task
2619 is associated with unrelated story 2000403).
-- 
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] [Neutron] Bug status

[Gary Kotton]

Hi,
It has been a relatively quiet week and not many issues opened. There are a few 
bugs with IPv6 subnets. Most have missing information and I have asked the 
reporters for some extra information. Not any blockers are issues that are 
concerning.
Wishing everyone a productive PTG.
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-dev] [all][api] POST /api-sig/news

[Ed Leafe]

Greetings OpenStack community,

Once again we did not have anything too controversial to discuss this week. We 
talked a bit about the Open API 3.0 discussions, but until there is something 
concrete to work with, there really isn't much for the API-SIG to do other than 
facilitate these conversations. One SIG member, elmiko, shared his tool for 
code generation from Open API [9], which led to a broader discussion on code 
generation in general. Not exactly a pure API-related topic, but interesting 
nonetheless.

As there were no new guidelines to review or bugs to fix, the remaining part of 
the meeting was to discuss the plans for the API-SIG session [7] at the 
upcoming Denver PTG [8]. We were hoping to attract a bigger crowd by including 
a topic like "Running your serverless microversioned blockchain in Kubernetes", 
but unfortunately cdent liked that topic so much he sold it to some VCs and 
retired a rich man.

As always if you're interested in helping out, in addition to coming to the 
meetings, there's also:

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

* A (shrinking) suite of several documents about doing version and service 
discovery
  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] https://etherpad.openstack.org/p/api-sig-stein-ptg
[8] https://www.openstack.org/ptg/
[9] https://gitlab.com/elmiko/deswag

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

[openstack-dev] [kolla] Meeting cancelled

[Eduardo Gonzalez]

Dear Kolla Team,

Due to the PTG in Denver, the Kolla weekly meeting on Wednesday 12th is
canceled.

Best regards
__
OpenStack Development Mailing 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] [kolla][tripleo][openstack-helm][kayobe] Cross-project discussion

[Eduardo Gonzalez]

Hi,

Kolla team is going to have 2 cross-project sessions on Wednesday.

For Tripleo: Addition of healthchecks into kolla images at 10.40 - 11:15,
this is a work

For any project consuming kolla images, CI jobs into kolla CI at 11:20 -
12:00

Hope someone of your teams can attend the sessions.

Regards
__
OpenStack Development Mailing 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] [Kolla] Denver PTG schedule

[Eduardo Gonzalez]

Hi folks,
This is the schedule for Kolla Denver PTG. If someone have a hard conflict
with any discussion please let me know if we can find a slot which matches
better.

Wednesday
9:00 - 9:45 [kolla] Image optimization
9:50 - 10:35 [kolla] Python3 images
10.40 - 11:15 [kolla] Add health checks to kolla images
11:20 - 12:00 [kolla] CI for projects consuming kolla images
12:00 - 13:30 LUNCH
1:30 - 2:15 [kolla-ansible] Compatible OCI runtime
2:20 - 3:05 [kolla-ansible] Backups
3:10 - 3:55 [kolla-ansible] DRY ansible
4:00 - 4:45 [kolla-ansible] Kayobe

Thursday
9:00 - 9:45 [kolla-ansible] Dev mode optimization
9:50 - 10:35 [kolla-ansible] Firewall configuration
10.40 - 11:15 [kolla-ansible] Fast-forward upgrade
11:20 - 12:00 [kolla-ansible] Multi release support
12:00 - 13:30 LUNCH
1:30 - 2:15 [kolla-ansible] Cells v2
2:20 - 3:05 [kolla-ansible] Running kolla at scale
3:10 - 3:55 Kolla GUI
4:00 - 4:45 PTG recap and Stein priority setting

Friday
9:00 - 9:45 [CI] Service testing and scenarios
9:50 - 10:35 [CI] Upgrade jobs
10.40 - 11:15 [CI] Usage of tempest and rally
11:20 - 12:00 Define PTG TODOs (blueprints, specs, etc)
12:00 - 13:30 LUNCH
1:30 - End of day - Open discussion

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

[openstack-dev] [cinder][nova][placement] Doodle Calendar Created for Placement Discussion

[Jay S Bryant]

All,

We discussed in our weekly meeting yesterday that it might be good to 
plan an additional meeting at the PTG to continue discussions with 
regards to Cinder's use of the Placement Service.


I have looked at the room schedule [1] and there are quite a few open 
rooms on Monday.  Fewer rooms on Tuesday but there are still some 
options each day.


Please fill out the poll [2] if you are interested in attending ASAP and 
then I will reserve a room as soon as it looks like we have quorum.


Thank you!

Jay

[1] http://ptg.openstack.org/ptg.html

[2] https://doodle.com/poll/4twwhy46bxerrthx


__
OpenStack Development Mailing 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] retrospective and forum brainstorm etherpads

[Tom Barron]

Devs, Ops, community:

We're going to start off the manila PTG sessions Monday with a 
retrospective on the Rocky cycle, using this etherpad [1].  Please
enter your thoughts on what went well and what we should improve in 
Stein so that we take it into consideration.


It's also time (until next Wednesday) to brainstorm topics for Berlin 
Forum.  Please record these here [2].  We'll discuss this subject at 
the PTG as well.


Thanks!

-- Tom Barron (tbarron)

[1] https://etherpad.openstack.org/p/manila-rocky-retrospective

[2] https://etherpad.openstack.org/p/manila-berlin-forum-brainstorm

__
OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Matthew Thode]

On 18-09-06 13:33:12, Michel Peterson wrote:
> On Wed, Sep 5, 2018 at 6:03 PM, Matthew Thode 
> wrote:
> 
> > On 18-08-31 19:52:09, Matthew Thode wrote:
> > > The requirements project has a co-installability test for the various
> > > projects, networking-odl being included.
> > >
> > > Because of the way the dependancy on ceilometer is done it is blocking
> > > all reviews and updates to the requirements project.
> > >
> > > http://logs.openstack.org/96/594496/2/check/requirements-
> > integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
> >
> > The requirements team has gone ahead and made a aweful hack to get gate
> > unwedged.  The commit message is a very good summary of our reasoning
> > why it has to be this way for now.  My comment explains our plan going
> > forward (there will be a revert prepared as soon as this merges for
> > instance).
> >
> > step 1. merge this
> > step 2. look into and possibly fix our tooling (why was the gitref
> > addition not rejected by gate)
> > step 3. fix networking-odl (release ceilometer)
> > step 4. unmerge this
> >
> 
> I remember that before landing the problematic patch [1] there was some
> discussion around it. Basically the problem was not n-odl but ceilometer
> not being in pypi, but we never foresaw this problem.
> 
> Now that the problem is so critical, the question is how can we, from the
> n-odl team, help in fixing this? I am open to help in any effort that
> involves n-odl or any other project.
> 
> Sorry this message fell through the cracks and I didn't answer before.
> 
> PS: I'm CCing Mike Kolesnik to this email, as he will be going to the PTG
> and can represent n-odl.
> 
> [1] https://review.openstack.org/557370/

I think the best choice at this point in time would be to get a
ceilometer release onto pypi.  At that time you can move to using that
version as your project minimum.  Just make sure that if you need a new
feature you ask them for a release instead of using a git SHA.

I'll be at the PTG as well, infra/upgrade/OSA rooms mostly I think.

-- 
Matthew Thode (prometheanfire)


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] [charms] 18.08 OpenStack Charms release

[David Ames]

Announcing the 18.08 release of the OpenStack Charms.

The 18.08 charms have support for the Rocky OpenStack, Ceph Mimic and
Keystone fernet token support. 51 bugs have been fixed and released
across the OpenStack charms.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/charm-guide/latest/1808.html

Thanks go to the following contributors for this release:

James Page
Frode Nordahl
David Ames
Chris MacNaughton
Ryan Beisner
Liam Young
Corey Bryant
Alex Kavanagh
Dmitrii Shcherbakov
Edward Hope-Morley
Van Hung Pham
Shane Peters
Billy Olsen
Nobuto Murata
Sean Feole
Pete Vander Giessen
daixianmeng
wangqi
Felipe Reyes
Nikolay Nikolaev
guozj
Nicolas Pochet
Nam
Xav Paice
Hua Zhang
huang.zhiping
Brin Zhang
Andrew McLeod
Tilman Baumann
yuhaijia
lvxianguo
Roger Yu
Chris Sanders
Rajat Dhasmana
zhangmin

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

[openstack-dev] [nova] Stein Forum brainstorming

[melanie witt]

Greetings all,

Apparently, we have 6 days left [1] to brainstorm topic ideas for the 
Forum at the Berlin summit and the submission period begins on September 12.


Please feel free to use this etherpad to as a place to capture topic 
ideas [2]. I've added it to the list of etherpads on the forum wiki [3].


Cheers,
-melanie

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

[2] https://etherpad.openstack.org/p/nova-forum-stein
[3] 
https://wiki.openstack.org/wiki/Forum/Berlin2018#Etherpads_from_Teams_and_Working_Groups


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

[openstack-dev] [placement] Extraction: Phase 2

[Ed Leafe]

Now that the work to create a repo of Placement extracted from Nova that is 
passing tests has finished, there is still more work to be done. To help 
organize our efforts, we have created an etherpad [0] for this. At the bottom 
of that page is a section titled "TODOs for further cleaning up”. As we come 
across issues, they will be added to that section.

If you wish to help out by working on one of those issues, please mark that 
issue with your name so that we can avoid duplicating effort. And if you have 
any questions about the issue, please ask for help in the #openstack-placement 
IRC channel.

-- Ed Leafe

[0] https://etherpad.openstack.org/p/placement-extract-stein-3



__
OpenStack Development Mailing 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]-ish : Updates required for readthedocs publishers

[Andreas Jaeger]

On 2018-09-06 14:20, Ilya Shakhat wrote:

What is the process once webhook_id is added to project's zuul.yaml?
Should I propose a change into project-config/zuul.d/projects.yaml or it 
will be done automatically?


You need to send to use docs-on-readthedocs template and set the 
variable to project-config repo.


BTW (not completely related to this topic, but since I'm touching 
zuul.yaml anyway) - what are the best practices for non-official 
projects - should zuul configuration stay in project-config or better be 
moved to local zuul.yaml?




See 
https://docs.openstack.org/infra/manual/creators.html#central-config-exceptions 
for what should stay in project-config.


Since the publishing is part of a release, the template needs to stay in 
project-config,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [keystone] No meeting or office hours September 11th

[Lance Bragstad]

I wanted to send out a reminder that we won't be having formal office hours
or a team meeting next week due to the PTG. Both will resume on the 18th of
September.

Thanks,

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

[openstack-dev] [Neutron] [Upgrades] Cancel meeting on 13th Sept.

[Lujin Luo]

Hello everyone,

We are canceling our next Upgrades subteam meeting on 13th September
due to PTG. Should you have any questions, please reach out to me on
#openstack-neutron.

Best regards,
Lujin

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

[openstack-dev] [keystone] Stein Forum Brainstorming

[Lance Bragstad]

I can't believe it's already time to start thinking about forum topics, but
it's upon us [0]!

I've created an etherpad for us to brainstorm ideas that we want to bring
to the forum in Germany [1]. I also linked it to the wiki [2].

Please feel free to throw out ideas. We can go through them as a group
before the submission phase starts if people wish.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134336.html
[1] https://etherpad.openstack.org/p/BER-keystone-forum-sessions
[2]
https://wiki.openstack.org/wiki/Forum/Berlin2018#Etherpads_from_Teams_and_Working_Groups
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] about unified limits

[Lance Bragstad]

I wish there was a better answer for this question, but currently there are
only a handful of us working on the initiative. If you, or someone you
know, is interested in getting involved, I'll happily help onboard people.

On Wed, Sep 5, 2018 at 8:52 PM Jaze Lee  wrote:

> On Stein only one service?
> Is there some methods to move this more fast?
> Lance Bragstad  于2018年9月5日周三 下午9:29写道：
> >
> > Not yet. Keystone worked through a bunch of usability improvements with
> the unified limits API last release and created the oslo.limit library. We
> have a patch or two left to land in oslo.limit before projects can really
> start using unified limits [0].
> >
> > We're hoping to get this working with at least one resource in another
> service (nova, cinder, etc...) in Stein.
> >
> > [0]
> https://review.openstack.org/#/q/status:open+project:openstack/oslo.limit+branch:master+topic:limit_init
> >
> > On Wed, Sep 5, 2018 at 5:20 AM Jaze Lee  wrote:
> >>
> >> Hello,
> >> Does nova and cinder  use keystone's unified limits api to do quota
> job?
> >> If not, is there a plan to do 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
> >
> >
> __
> > OpenStack Development Mailing 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] [nova] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 12:41 PM Dan Smith  wrote:
>
> > I think there was a period in time where the nova_api database was created
> > where entires would try to get pulled out from the original nova database 
> > and
> > then checking nova_api if it doesn't exist afterwards (or vice versa).  One
> > of the cases that this was done to deal with was for things like instance 
> > types
> > or flavours.
> >
> > I don't know the exact details but I know that older instance types exist in
> > the nova db and the newer ones are sitting in nova_api.  Something along
> > those lines?
>
> Yep, we've moved entire databases before in nova with minimal disruption
> to the users. Not just flavors, but several pieces of data came out of
> the "main" database and into the api database transparently. It's
> doable, but with placement being split to a separate
> project/repo/whatever, there's not really any option for being graceful
> about it in this case.
>
> > At this point, I'm thinking turn off placement, setup the new one, do
> > the migration
> > of the placement-specific tables (this can be a straightforward documented 
> > task
> > OR it would be awesome if it was a placement command (something along
> > the lines of `placement-manage db import_from_nova`) which would import all
> > the right things
> >
> > The idea of having a command would be *extremely* useful for deployment 
> > tools
> > in automating the process and it also allows the placement team to 
> > selectively
> > decide what they want to onboard?
>
> Well, it's pretty cut-and-dried as all the tables in nova-api are either
> for nova or placement, so there's not much confusion about what belongs.
>
> I'm not sure that doing this import in python is really the most
> efficient way. I agree a placement-manage command would be ideal from an
> "easy button" point of view, but I think a couple lines of bash that
> call mysqldump are likely to vastly outperform us doing it natively in
> python. We could script exec()s of those commands from python, but.. I
> think I'd rather just see that as a shell script that people can easily
> alter/test on their own.
>
> Just curious, but in your case would the service catalog entry change at
> all? If you stand up the new placement in the exact same spot, it
> shouldn't, but I imagine some people will have the catalog entry change
> slightly (even if just because of a VIP or port change). Am I
> remembering correctly that the catalog can get cached in various places
> such that much of nova would need a restart to notice?

We already have placement in the catalog and it's behind a load balancer
so changing the backends resolves things right away, so we likely won't
be needing any restarts (and I don't think OSA will either because it uses
the same model).

> --Dan



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

[openstack-dev] [blazar] Blazar Forum session brainstorming etherpad

[Pierre Riteau]

Hi everyone,

I created an etherpad [1] to gather Berlin Forum session ideas for the
Blazar project, or resource reservation in general. Please contribute!

Thanks,
Pierre

[1] https://etherpad.openstack.org/p/Berlin-stein-forum-blazar-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] [all]-ish : Updates required for readthedocs publishers

[Ilya Shakhat]

What is the process once webhook_id is added to project's zuul.yaml?
Should I propose a change into project-config/zuul.d/projects.yaml or it
will be done automatically?

BTW (not completely related to this topic, but since I'm touching zuul.yaml
anyway) - what are the best practices for non-official projects - should
zuul configuration stay in project-config or better be moved to local
zuul.yaml?

Thanks,
Ilya

чт, 6 сент. 2018 г. в 1:31, Ian Wienand :

> On 09/06/2018 02:10 AM, Doug Hellmann wrote:
> > Those instructions and the ones linked at
> >
> https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
> > say to "generate a web hook URL".
>
> I think you got the correct answers, thanks Dmitry.  Note it is also
> illustrated at
>
>   https://imgur.com/a/Pp4LH31
>
> Thanks
>
> -i
>
> __
> OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

[Abhishek Kekane]

Hi Rico,

Session times are not decided yet, could you please add your topic on [1]
so that it will be on discussion list.
Also glance sessions are scheduled from Wednesday to Friday between 9 to 5
PM, so you can drop by as per your convenience.

[] https://etherpad.openstack.org/p/stein-ptg-glance-planning


Thanks & Best Regards,

Abhishek Kekane

On Thu, Sep 6, 2018 at 3:48 PM, Rico Lin  wrote:

>
> On Thu, Sep 6, 2018 at 12:52 PM Abhishek Kekane 
> wrote:
>
>> Hi Rico,
>>
>> We will discuss this during PTG, however meantime you can add
>> WSGI_MODE=mod_wsgi in local.conf for testing purpose.
>>
>
> Cool, If you can let me know which session it's, I will try to be there if
> no conflict
>
> __
> OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Michel Peterson]

On Wed, Sep 5, 2018 at 6:03 PM, Matthew Thode 
wrote:

> On 18-08-31 19:52:09, Matthew Thode wrote:
> > The requirements project has a co-installability test for the various
> > projects, networking-odl being included.
> >
> > Because of the way the dependancy on ceilometer is done it is blocking
> > all reviews and updates to the requirements project.
> >
> > http://logs.openstack.org/96/594496/2/check/requirements-
> integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
>
> The requirements team has gone ahead and made a aweful hack to get gate
> unwedged.  The commit message is a very good summary of our reasoning
> why it has to be this way for now.  My comment explains our plan going
> forward (there will be a revert prepared as soon as this merges for
> instance).
>
> step 1. merge this
> step 2. look into and possibly fix our tooling (why was the gitref
> addition not rejected by gate)
> step 3. fix networking-odl (release ceilometer)
> step 4. unmerge this
>

I remember that before landing the problematic patch [1] there was some
discussion around it. Basically the problem was not n-odl but ceilometer
not being in pypi, but we never foresaw this problem.

Now that the problem is so critical, the question is how can we, from the
n-odl team, help in fixing this? I am open to help in any effort that
involves n-odl or any other project.

Sorry this message fell through the cracks and I didn't answer before.

PS: I'm CCing Mike Kolesnik to this email, as he will be going to the PTG
and can represent n-odl.

[1] https://review.openstack.org/557370/
__
OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

[Rico Lin]

On Thu, Sep 6, 2018 at 12:52 PM Abhishek Kekane  wrote:

> Hi Rico,
>
> We will discuss this during PTG, however meantime you can add
> WSGI_MODE=mod_wsgi in local.conf for testing purpose.
>

Cool, If you can let me know which session it's, I will try to be there if
no conflict
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] [placement] modified devstack using openstack/placement

[Chris Dent]

Yesterday I experimented to discover the changes needed in devstack
to get it working with the code in openstack/placement. The results
are at

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

and it is passing tempest. It isn't passing grenade but that's
expected at this stage.

Firstly, thanks to everyone who helped this week to create and merge
a bunch of placement code to get the repo working. Waking up this
morning to see a green tempest was rather nice.

Secondly, the work—as expected—exposes a few gaps, most that are
already known. If you're not interested in the details, here's a
good place to stop reading, but if you are, see below. This is
mostly notes, for sake of sharing information, not a plan. Please
help me make a plan.

1) To work around the fact that there is currently no
"placement-manage db_sync" equivalent I needed to hack up something
to make sure the database tables exist. So I faked a
"placmeent-manage db table_create". That's in

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

That uses sqlalchemy's 'create_all' functionality to create the
tables from their Models, rather than using any migrations. I did it
this way for two reasons: 1) I already had code for it in placedock[1]
that I could copy, 2) I wanted to set aside migrations for the
immediate tests.

We'll need to come back to that, because the lack of dealing with
already existing tables is _part_ of what is blocking grenade.
However, for new installs 'create_all' is fast and correct and
something we might want to keep.

2) The grenade jobs don't have 'placement' in $PROJECTS so die
during upgrade.

3) The nova upgrade.sh will need some adjustments to do the data
migrations we've talked about over the "(technical)" thread. Also
we'll need to decide how much of the placement stuff stays in there
and how much goes somewhere else.

That's all stuff we can work out, especially if some
grenade-oriented people join in the fun.

One question I have on the lib/placement changes in devstack: Is it
useful to make those changes be guarded by a conditional of the
form:

   if placement came from its own repo:
   do the new stuff
   else:
   do the old stuff

?


[1] https://github.com/cdent/placedock
--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: 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-dev] [openstack-operator] [qa] [forum] [berlin] QA Brainstorming Topic ideas for Berlin 2018

[Ghanshyam Mann]

Hi All,

I have created the below etherpad to collect the forum ideas related to QA for 
Berlin Summit.

Please write up your ideas with your irc name on etherpad.

https://etherpad.openstack.org/p/berlin-stein-forum-qa-brainstorming 

-gmann





__
OpenStack Development Mailing 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] [election][tc] TC Candidacy

[Ghanshyam Mann]

Hi All,

I’d like to announce my candidacy for OpenStack Technical Committee position. 

I am glad to work in OpenStack community and would like to thank all the 
contributors/leaders who supported me to explore new things which brings out my 
best for the community.

Let me introduce myself, briefly. I have joined the OpenStack community since 
2012 as operator and started as full time upstream contributor since 2014 
during mid of Ice-House release. Currently, I am PTL for the QA Program since 
the Rocky cycle and active contributor in QA projects and Nova. Also I have 
been randomly contributing in many other projects specially on Tempest plugins 
for bug fix and tempest compatibility changes. 
Along with that, I am actively involved in programs helping new contributors in 
OpenStack. 1. As mentor in the Upstream Institute Training since Barcelona 
Summit (Oct 2016)[1] 2. FirstContact SIG [2] to help new contributors to 
onboard in OpenStack. It's always a great experience to introduce OpenStack 
upstream workflow to new contributors and encourage them to start contribution. 
I feel that is very much needed in OpenStack because of current movement of 
experience contributors. 

TC direction has always been valuable and result oriented in technical debt or 
efforts towards Diversity of community. This kind of work/position never been 
easy task specially in such a big community like OpenStack. By observing the TC 
work from past couple of years, I am very much motivated to help in this 
direction in order to contribute more towards cross projects and collaboration 
among projects or people.   

Below are the areas I would like to Focus as TC:

* Share Project teams work for Common Goals:  Every cycle we have TC goals and 
some future direction where all the projects needs to start working. Projects 
try to do their best in that but big challenge for them is resource bandwidth. 
In Current situation, It is very hard for projects teams to accommodate those 
work by themselves. Project team are shrinking and key members are overloaded. 
My Idea is to form a temporary team of contributors under Goal champion and 
finish those common area work during starting of cycle (so that we can make 
sure to finish the work well on time and test throughout the cycle). That 
temporary team can be formed with volunteers from any project team or new part 
time contributors with help of OUI or FirstContact SIG etc. 
 
* Cross-project and cross-community testing: I would like to work more on 
collaboration of testing effort across projects and community. We have plugins 
approach for testing in OpenStack and I agree that which is not perfect at this 
stage. I would like to work on more collaboration and guidelines to improve 
that area.  From QA team point of view, I would like QA team to do more 
collaborative work for all the projects for their proper testing.  And further, 
extend the testing collaboration among adjacent communities. 

* Encourage new leaders:  new contributors and so new leaders are much required 
in community. Some internal or external leadership program etc can be very 
helpful.  

Regardless of the results of this election I will work hard towards above 
directions and help community at my best. 

Thank you for your reading and consideration.

- Ghanshyam Mann (gmann)

* Review:  
http://stackalytics.com/?release=all&metric=marks&user_id=ghanshyammann&project_type=all
 
* Commit:   
http://stackalytics.com/?release=all&metric=commits&user_id=ghanshyammann&project_type=all
 
* Foundation Profile: https://www.openstack.org/community/members/profile/6461 
* Website: https://ghanshyammann.com 
* IRC (Freenode): gmann

[1] https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions 
  https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute 
[2] https://wiki.openstack.org/wiki/First_Contact_SIG 






__
OpenStack Development Mailing 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] [blazar] about reservation

[Jaze Lee]

Hello,
   I view the source code and do not find the check logic for
reservation a instance. It just create a lease, and nova just create a
flavor.
How do we ensure the resource is really reserved for us?
We put the host into a new aggregate? and nobody except blazar will use
the host?

-- 
谦谦君子

__
OpenStack Development Mailing 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][Searchlight] Commits of searchlight-specs are not attached to the story

[Trinh Nguyen]

Hi,

Looks like the commits for searchlight-specs are not attached to the story
on Storyboard. Example:

Commit: https://review.openstack.org/#/c/600316/
Story: https://storyboard.openstack.org/#!/story/2003677

Is there anything that I need to do to link those 2 together?

Thanks,

*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