date:20180830

Adjutant should be should be good to go. I don't believe there are any
blockers (unless I've missed some).

On 31/08/18 11:24 AM, Doug Hellmann wrote:
> Below is the list of project teams that have not yet started migrating
> their zuul configuration. If you're ready to go, please respond to this
> email to let us know so we can start proposing patches.
>
> Doug
>
> | adjutant| 3 repos   |
> | barbican| 5 repos   |
> | Chef OpenStack  | 19 repos  |
> | cinder  | 6 repos   |
> | cloudkitty  | 5 repos   |
> | I18n| 2 repos   |
> | Infrastructure  | 158 repos |
> | loci| 1 repos   |
> | nova| 6 repos   |
> | OpenStack Charms| 80 repos  |
> | Packaging-rpm   | 4 repos   |
> | Puppet OpenStack| 47 repos  |
> | Quality Assurance   | 22 repos  |
> | Telemetry   | 8 repos   |
> | trove   | 5 repos   |
>
> __
> OpenStack Development Mailing 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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

2018-08-30 Thread Jacky Hu

+1
Definitely a good contributor for the octavia community.

发自我的 iPhone

> 在 2018年8月31日，上午11:24，Michael Johnson  写道：
> 
> Hello Octavia community,
> 
> I would like to propose Carlos Goncalves as a core reviewer on the
> Octavia project.
> 
> Carlos has provided numerous enhancements to the Octavia project,
> including setting up the grenade gate for Octavia upgrade testing.
> 
> Over the last few releases he has also been providing quality reviews,
> in line with the other core reviewers [1]. I feel that Carlos would
> make an excellent addition to the Octavia core reviewer team.
> 
> Existing Octavia core reviewers, please reply to this email with your
> support or concerns with adding Jacky to the core team.
> 
> Michael
> 
> [1] http://stackalytics.com/report/contribution/octavia-group/90
> 
> __
> OpenStack Development Mailing 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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

2018-08-30 Thread Michael Johnson

Hello Octavia community,

I would like to propose Carlos Goncalves as a core reviewer on the
Octavia project.

Carlos has provided numerous enhancements to the Octavia project,
including setting up the grenade gate for Octavia upgrade testing.

Over the last few releases he has also been providing quality reviews,
in line with the other core reviewers [1]. I feel that Carlos would
make an excellent addition to the Octavia core reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

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

__
OpenStack Development Mailing 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] [kolla][tripleo][oslo][all] Bumping eventlet to 0.24.1

On 18-08-30 20:52:46, Matthew Thode wrote:
> On 18-08-23 09:50:13, Matthew Thode wrote:
> > This is your warning, if you have concerns please comment in
> > https://review.openstack.org/589382 .  cross tests pass, so that's a
> > good sign... atm this is only for stein.
> > 
> 
> Consider yourself on notice, https://review.openstack.org/589382 is
> planned to be merged on monday.
> 

A bit more of follow up since that was so dry.  There are some projects
that have not branched (mainly cycle-trailing and plugins).

There has historically been some breakage with each eventlet update,
this one is not expected to be much different unfortunately.  Currently
there are known issues with oslo.service but they look solvable.  A list
of all projects using eventlet is attached.

The full list of non-branched projects will be at the bottom of this
message, but the projects that I think should be more careful are the
following.

kolla kolla-ansible heat-agents heat-dashboard tripleo-ipsec

the rest of the repos seem to be plugins, which I'm personally less
concerned about, but should still be branched (preferably sooner rather
than later).

ansible-role-container-registry
ansible-role-redhat-subscription
ansible-role-tripleo-modify-image
barbican-tempest-plugin
blazar-tempest-plugin
cinder-tempest-plugin
cloudkitty-tempest-plugin
congress-tempest-plugin
designate-tempest-plugin
devstack-plugin-amqp1
devstack-plugin-kafka
ec2api-tempest-plugin
heat-agents
heat-dashboard
heat-tempest-plugin
ironic-tempest-plugin
keystone-tempest-plugin
kolla-ansible
kolla
kuryr-tempest-plugin
magnum-tempest-plugin
manila-tempest-plugin
mistral-tempest-plugin
monasca-kibana-plugin
monasca-tempest-plugin
murano-tempest-plugin
networking-generic-switch-tempest-plugin
neutron-tempest-plugin
octavia-tempest-plugin
oswin-tempest-plugin
patrole
release-test
sahara-tests
senlin-tempest-plugin
solum-tempest-plugin
telemetry-tempest-plugin
tempest-tripleo-ui
tempest
tripleo-ipsec
trove-tempest-plugin
vitrage-tempest-plugin
watcher-tempest-plugin
zaqar-tempest-plugin
zun-tempest-plugin

-- 
Matthew Thode (prometheanfire)
++--+--++
| Repository | Filename 
| Line | Text   
|
++--+--++
| airship-drydock| requirements-lock.txt
|   12 | eventlet==0.23.0   
|
| airship-promenade  | requirements-frozen.txt  
|   17 | eventlet==0.23.0   
|
| apmec  | requirements.txt 
|   11 | 
eventlet!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2 # MIT   |
| astara | requirements.txt 
|5 | 
eventlet!=0.18.3,>=0.18.2 # MIT|
| astara-appliance   | requirements.txt 
|7 | 
eventlet!=0.18.3,>=0.18.2 # MIT|
| astara-horizon | test-requirements.txt
|9 | 
eventlet!=0.18.3,>=0.18.2 # MIT|
| barbican   | requirements.txt 
|8 | 
eventlet>=0.18.2,!=0.18.3,!=0.20.1  # MIT  |
| bareon | requirements.txt 
|5 | 
eventlet!=0.18.3,>=0.18.2 # MIT|
| bilean | requirements.txt 
|7 | eventlet>=0.17.4   
|
| blazar | requirements.txt 
|8 | 
eventlet!=0.18.3,!=0.20.1,>=0.18.2 # MIT   |
| ceilometer-zvm

Re: [openstack-dev] Bumping eventlet to 0.24.1

On 18-08-23 09:50:13, Matthew Thode wrote:
> This is your warning, if you have concerns please comment in
> https://review.openstack.org/589382 .  cross tests pass, so that's a
> good sign... atm this is only for stein.
> 

Consider yourself on notice, https://review.openstack.org/589382 is
planned to be merged on monday.

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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

2018-08-30 Thread Edison Xiang

Hey doug,

Thanks your reply. Very good question.
It is not a conflict with current API Documents work that has already been
done.
We can use some tools to generate Open API schema from existing machine
readable API-def in every project like nova [1]
We can still use the existing tools to generate the API Documents website.

[1] https://github.com/openstack/nova/tree/master/api-ref/source

Best Regards,
Edison Xiang

On Fri, Aug 31, 2018 at 1:46 AM Doug Hellmann  wrote:

> Excerpts from Edison Xiang's message of 2018-08-30 14:08:12 +0800:
> > Hey dims,
> >
> > Thanks your reply. Your suggestion is very important.
> >
> > > what would be the impact to projects?
> > > what steps they would have to take?
> >
> > We can launch a project to publish OpenStack Projects APIs Schema for
> users
> > and  developers.
> > But now OpenStack Projects have no APIs Schema definition.
> > Open API will not impact OpenStack Projects features they have,
> > but we need some volunteers to define every project APIs Schema by Open
> API
> > 3.0.
> >
> > > Do we have a sample/mock API where we can show that the Action and
> > Microversions can be declared to reflect reality and it can actually work
> > with the generated code?
> > Yeah, you can copy this yaml [1] into editor [2] to generate server or
> > client codes or try it out.
> > We can do more demos later.
> >
> > [1]
> >
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml
> > [2] https://editor.swagger.io
> >
> > Best Regards,
> > Edison Xiang
>
> How does this proposal relate to the work that has already been
> done to build the API guide
> https://developer.openstack.org/api-guide/quick-start/ documentation?
>
> Doug
>
> >
> > On Wed, Aug 29, 2018 at 6:31 PM Davanum Srinivas 
> wrote:
> >
> > > Edison,
> > >
> > > This is definitely a step in the right direction if we can pull it off.
> > >
> > > Given the previous experiences and the current situation of how and
> where
> > > we store the information currently and how we generate the website for
> the
> > > API(s), can you please outline
> > > - what would be the impact to projects?
> > > - what steps they would have to take?
> > >
> > > Also, the whole point of having these definitions is that the generated
> > > code works. Do we have a sample/mock API where we can show that the
> Action
> > > and Microversions can be declared to reflect reality and it can
> actually
> > > work with the generated code?
> > >
> > > Thanks,
> > > Dims
> > >
> > > On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang 
> > > wrote:
> > >
> > >> Hi team,
> > >>
> > >> 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.
> > >>
> > >> Some limitations are mentioned in the Mail List for OpenStack API:
> > >> 1. The POST */action APIs.
> > >> These APIs are exist in lots of projects like nova, cinder.
> > >> These APIs have the same URI but the responses will be different
> when
> > >> the request is different.
> > >> 2. Micro versions.
> > >> These are controller via headers, which are sometimes used to
> > >> describe behavioral changes in an API, not just request/response
> schema
> > >> changes.
> > >>
> > >> About the first limitation, we can find the solution in the Open API
> 3.0.
> > >> The example [2] shows that we can define different request/response in
> > >> the same URI by anyof feature in Open API 3.0.
> > >>
> > >> About the micro versions problem, I think it is not a limitation
> related
> > >> a special API Standard.
> > >> We can list all micro versions API schema files in one directory like
> > >> nova/V2,
> > >> or we can list the schema changes between micro versions as tempest
> > >> project did [3].
> > >>
> > >> Based on Open API 3.0, it can bring lots of benefits for OpenStack
> > >> Community and does not impact the current features the  Community has.
> > >> For example, we can automatically generate API documents, different
> > >> language Clients(SDK) maybe for different micro versions,
> > >> and generate cloud tool adapters for OpenStack, like ansible module,
> > >> terraform providers and so on.
> > >> Also we can make an API UI to provide an online and visible API
> search,
> > >> API Calling for every OpenStack API.
> > >> 3rd party developers can also do some self-defined development.
> > >>
> > >> [1] https://github.com/OAI/OpenAPI-Specification
> > >> [2]
> > >>
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> > >> [3]
> > >>
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> > >>
> > >> Best Regards,
> > >> Edison Xiang
> > >>
> > >>
>

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

Actually now that I think about it, another problem is that (at least in
our case) Keystone is really a cluster wide service present across
regions, so if it was to use Barbican (or Vault for that matter) then
the secret store service would too need to be cluster wide and across
all regions.

Our current plan for our deployment of Barbican is per region. Is that
the norm? Because if so, then it kind of means using it for Keystone
becomes less useful.

On 31/08/18 12:02 PM, Adrian Turjak wrote:
>
> Oh I was literally just thinking about the 'credential' type key value
> items we store in the Keystone DB. Rather than storing them in the
> Keystone db and worrying about encryption (and encryption keys) in
> Keystone around what is otherwise a plaintext secret, just offload
> that to a service specific for handling those (which Keystone isn't).
>
> My only really worry then is if tying MFA credential values to an
> external service is a great idea as now Keystone and Barbican have to
> be alive for auth to occur (plus auth could be marginally slower).
> Although by using an external service security could potentially be
> enhanced and deployers don't need to worry about credential encryption
> key rotation (and re-encryption of credentials) in Keystone.
>
> As for fernet keys in Barbican... that that does sound like a fairly
> terrifying chicken and egg problem. Although Castellan with a Vault
> plugin sounds doable (not tied back to Keystone's own auth), and could
> actually be useful for multi-host keystone deployments since Vault now
> handles your Key replication/distribution provided Keystone rotates
> keys into it.
>
> On 31/08/18 1:50 AM, Lance Bragstad wrote:
>> This topic has surfaced intermittently ever since keystone
>> implemented fernet tokens in Kilo. An initial idea was written down
>> shortly afterwords [0], then we targeted it to Ocata [1], and removed
>> from the backlog around the Pike timeframe [2]. The commit message of
>> [2] includes meeting links. The discussion usually tripped attempting
>> to abstract enough of the details about rotation and setup of keys to
>> work in all cases.
>>
>> [0] https://review.openstack.org/#/c/311268/
>> [1] https://review.openstack.org/#/c/363065/
>> [2] https://review.openstack.org/#/c/439194/
>>
>> On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles
>> mailto:jaosor...@redhat.com>> wrote:
>>
>> FWIW, instead of barbican, castellan could be used as a key manager.
>>
>>
>> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>>>
>>>
>>> On 30/08/18 6:29 AM, Lance Bragstad wrote:

 Is that what is being described here ? 
 
 https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html


 This is a separate mechanism for storing secrets, not
 necessarily passwords (although I agree the term credentials
 automatically makes people assume passwords). This is used if
 consuming keystone's native MFA implementation. For example,
 storing a shared secret between the user and keystone that is
 provided as a additional authentication method along with a
 username and password combination.
  
>>>
>>> Is there any interest or plans to potentially allow Keystone's
>>> credential store to use Barbican as a storage provider?
>>> Encryption already is better than nothing, but if you already
>>> have (or will be deploying) a proper secret store with a
>>> hardware backend (or at least hardware stored encryption keys)
>>> then it might make sense to throw that in Barbican.
>>>
>>> Or is this also too much of a chicken/egg problem? How safe is
>>> it to rely on Barbican availability for MFA secrets and auth?
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing 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

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [all] Bringing the community together (combine the lists!)

On 2018-08-30 18:08:56 -0500 (-0500), Melvin Hillsman wrote:
[...]
> I also recall us discussing having some documentation or way of
> notifying net new signups of how to interact with the ML
> successfully. An example was having some general guidelines around
> tagging. Also as a maintainer for at least one of the mailing
> lists over the past 6+ months I have to inquire about how that
> will happen going forward which again could be part of this
> documentation/initial message.
[...]

Mailman supports customizable welcome messages for new subscribers,
so the *technical* implementation there is easy. I do think (and
failed to highlight it explicitly earlier I'm afraid) that this
proposal comes with an expectation that we provide recommended
guidelines for mailing list use/etiquette appropriate to our
community. It could be contained entirely within the welcome
message, or merely linked to a published document (and whether
that's best suited for the Infra Manual or New Contributor Guide or
somewhere else entirely is certainly up for debate), or even
potentially both.
-- 
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][tc] Nominations now open!

2018-08-30 Thread Tony Breeds


Nominations for the Technical Committee positions (6 positions)
are now open and will remain open until Sep 06, 2018 23:45 UTC.

All nominations must be submitted as a text file to the
openstack/election repository as explained on the election website[1].

Please note that the name of the file should match an email
address in the foundation member profile of the candidate.

Also for TC candidates election officials refer to the community
member profiles at [2] please take this opportunity to ensure that
your profile contains current information.

Candidates for the Technical Committee Positions: Any Foundation
individual member can propose their candidacy for an available,
directly-elected TC seat.

The election will be held from Sep 18, 2018 23:45 UTC through to Sep 27, 2018 
23:45 UTC. The electorate
are the Foundation individual members that are also committers
for one of the official teams[3] over the Aug 11, 2017 00:00 UTC - Aug 30, 2018 
00:00 UTC timeframe (Queens to
Rocky, as well as the extra-ATCs who are acknowledged by the TC[4].

Please see the website[5] for additional details about this election.
Please find below the timeline:

TC nomination starts   @ Aug 30, 2018 23:45 UTC
TC nomination ends @ Sep 06, 2018 23:45 UTC
TC campaigning starts  @ Sep 06, 2018 23:45 UTC
TC campaigning ends@ Sep 18, 2018 23:45 UTC
TC elections starts@ Sep 18, 2018 23:45 UTC
TC elections ends  @ Sep 27, 2018 23:45 UTC

If you have any questions please be sure to either ask them on the
mailing list or to the elections officials[6].

Thank you,

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] http://www.openstack.org/community/members/
[3] https://governance.openstack.org/tc/reference/projects/
[4] https://releases.openstack.org/rocky/schedule.html#p-extra-atcs
[5] https://governance.openstack.org/election/
[6] http://governance.openstack.org/election/#election-officials


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] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Tony Breeds

On Thu, Aug 30, 2018 at 09:12:57PM +, Jeremy Stanley wrote:
> On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote:
> [...]
> > What needs to be done for this is full topic categories support
> > under `options` page so people get to filter emails properly.
> [...]
> 
> Unfortunately, topic filtering is one of the MM2 features the
> Mailman community decided nobody used (or at least not enough to
> warrant preserving it in MM3). I do think we need to be consistent
> about tagging subjects to make client-side filtering more effective
> for people who want that, but if we _do_ want to be able to upgrade
> we shouldn't continue to rely on server-side filtering support in
> Mailman unless we can somehow work with them to help in
> reimplementing it.

The suggestion is to implement it as a 3rd party plugin or work with the
mm community to implement:
https://wiki.mailman.psf.io/DEV/Dynamic%20Sublists

So if we decide we really want that in mm3 we have options.

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] [keystone] [barbican] Keystone's use of Barbican ?

Oh I was literally just thinking about the 'credential' type key value
items we store in the Keystone DB. Rather than storing them in the
Keystone db and worrying about encryption (and encryption keys) in
Keystone around what is otherwise a plaintext secret, just offload that
to a service specific for handling those (which Keystone isn't).

My only really worry then is if tying MFA credential values to an
external service is a great idea as now Keystone and Barbican have to be
alive for auth to occur (plus auth could be marginally slower). Although
by using an external service security could potentially be enhanced and
deployers don't need to worry about credential encryption key rotation
(and re-encryption of credentials) in Keystone.

As for fernet keys in Barbican... that that does sound like a fairly
terrifying chicken and egg problem. Although Castellan with a Vault
plugin sounds doable (not tied back to Keystone's own auth), and could
actually be useful for multi-host keystone deployments since Vault now
handles your Key replication/distribution provided Keystone rotates keys
into it.

On 31/08/18 1:50 AM, Lance Bragstad wrote:
> This topic has surfaced intermittently ever since keystone implemented
> fernet tokens in Kilo. An initial idea was written down shortly
> afterwords [0], then we targeted it to Ocata [1], and removed from the
> backlog around the Pike timeframe [2]. The commit message of [2]
> includes meeting links. The discussion usually tripped attempting to
> abstract enough of the details about rotation and setup of keys to
> work in all cases.
>
> [0] https://review.openstack.org/#/c/311268/
> [1] https://review.openstack.org/#/c/363065/
> [2] https://review.openstack.org/#/c/439194/
>
> On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles
> mailto:jaosor...@redhat.com>> wrote:
>
> FWIW, instead of barbican, castellan could be used as a key manager.
>
>
> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>>
>>
>> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>>
>>> Is that what is being described here ? 
>>> 
>>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>>
>>>
>>> This is a separate mechanism for storing secrets, not
>>> necessarily passwords (although I agree the term credentials
>>> automatically makes people assume passwords). This is used if
>>> consuming keystone's native MFA implementation. For example,
>>> storing a shared secret between the user and keystone that is
>>> provided as a additional authentication method along with a
>>> username and password combination.
>>>  
>>
>> Is there any interest or plans to potentially allow Keystone's
>> credential store to use Barbican as a storage provider?
>> Encryption already is better than nothing, but if you already
>> have (or will be deploying) a proper secret store with a hardware
>> backend (or at least hardware stored encryption keys) then it
>> might make sense to throw that in Barbican.
>>
>> Or is this also too much of a chicken/egg problem? How safe is it
>> to rely on Barbican availability for MFA secrets and auth?
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

2018-08-30 Thread Samuel Cassiba

On Thu, Aug 30, 2018 at 4:24 PM, Doug Hellmann  wrote:
> Below is the list of project teams that have not yet started migrating
> their zuul configuration. If you're ready to go, please respond to this
> email to let us know so we can start proposing patches.
>
> Doug
>
> | adjutant| 3 repos   |
> | barbican| 5 repos   |
> | Chef OpenStack  | 19 repos  |
> | cinder  | 6 repos   |
> | cloudkitty  | 5 repos   |
> | I18n| 2 repos   |
> | Infrastructure  | 158 repos |
> | loci| 1 repos   |
> | nova| 6 repos   |
> | OpenStack Charms| 80 repos  |
> | Packaging-rpm   | 4 repos   |
> | Puppet OpenStack| 47 repos  |
> | Quality Assurance   | 22 repos  |
> | Telemetry   | 8 repos   |
> | trove   | 5 repos   |
>

On behalf of Chef OpenStack, that one is good to go.

Best,
Samuel (scas)

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

[openstack-dev] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

Below is the list of project teams that have not yet started migrating
their zuul configuration. If you're ready to go, please respond to this
email to let us know so we can start proposing patches.

Doug

| adjutant| 3 repos   |
| barbican| 5 repos   |
| Chef OpenStack  | 19 repos  |
| cinder  | 6 repos   |
| cloudkitty  | 5 repos   |
| I18n| 2 repos   |
| Infrastructure  | 158 repos |
| loci| 1 repos   |
| nova| 6 repos   |
| OpenStack Charms| 80 repos  |
| Packaging-rpm   | 4 repos   |
| Puppet OpenStack| 47 repos  |
| Quality Assurance   | 22 repos  |
| Telemetry   | 8 repos   |
| trove   | 5 repos   |

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

Re: [openstack-dev] [Openstack-operators] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Melvin Hillsman

I think the more we can reduce the ML sprawl the better. I also recall us
discussing having some documentation or way of notifying net new signups of
how to interact with the ML successfully. An example was having some
general guidelines around tagging. Also as a maintainer for at least one of
the mailing lists over the past 6+ months I have to inquire about how that
will happen going forward which again could be part of this
documentation/initial message.

Also there are many times I miss messages that for one reason or another do
not hit the proper mailing list. I mean we could dive into the minutia or
start up the mountain of why keeping things the way they are is worst than
making this change and vice versa but I am willing to bet there are more
advantages than disadvantages.

On Thu, Aug 30, 2018 at 4:45 PM Jimmy McArthur  wrote:

>
>
> Jeremy Stanley wrote:
>
> On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
> [...]
>
> I really don't want this. I'm happy with things being sorted in
> multiple lists, even though I'm subscribed to multiples.
>
> IMO this is easily solved by tagging.  If emails are properly tagged
> (which they typically are), most email clients will properly sort on rules
> and you can just auto-delete if you're 100% not interested in a particular
> topic.
>

Yes, there are definitely ways to go about discarding unwanted mail
automagically or not seeing it at all. And to be honest I think if we are
relying on so many separate MLs to do that for us it is better community
wide for the responsibility for that to be on individuals. It becomes very
tiring and inefficient time wise to have to go through the various issues
of the way things are now; cross-posting is a great example that is
steadily getting worse.

> SNIP
>
> As the years went by, it's become apparent to me that this is
> actually an antisocial behavior pattern, and actively harmful to the
> user base. I believe OpenStack actually wants users to see the
> development work which is underway, come to understand it, and
> become part of that process. Requiring them to have their
> conversations elsewhere sends the opposite message.
>
> I really and truly believe that it has become a blocker for our
> community.  Conversations sent to multiple lists inherently splinter and we
> end up with different groups coming up with different solutions for a
> single problem.  Literally the opposite desired result of sending things to
> multiple lists.  I believe bringing these groups together, with tags, will
> solve a lot of immediate problems. It will also have an added bonus of
> allowing people "catching up" on the community to look to a single place
> for a thread i/o 1-5 separate lists.  It's better in both the short and
> long term.
>

+1

>
> Cheers,
> Jimmy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-- 
Kind regards,

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

Re: [openstack-dev] [Openstack-operators] [all] Bringing the community together (combine the lists!)




Jeremy Stanley wrote:

On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
[...]

I really don't want this. I'm happy with things being sorted in
multiple lists, even though I'm subscribed to multiples.
IMO this is easily solved by tagging.  If emails are properly tagged 
(which they typically are), most email clients will properly sort on 
rules and you can just auto-delete if you're 100% not interested in a 
particular topic.



SNIP

As the years went by, it's become apparent to me that this is
actually an antisocial behavior pattern, and actively harmful to the
user base. I believe OpenStack actually wants users to see the
development work which is underway, come to understand it, and
become part of that process. Requiring them to have their
conversations elsewhere sends the opposite message.
I really and truly believe that it has become a blocker for our 
community.  Conversations sent to multiple lists inherently splinter and 
we end up with different groups coming up with different solutions for a 
single problem.  Literally the opposite desired result of sending things 
to multiple lists.  I believe bringing these groups together, with tags, 
will solve a lot of immediate problems. It will also have an added bonus 
of allowing people "catching up" on the community to look to a single 
place for a thread i/o 1-5 separate lists.  It's better in both the 
short and long term.


Cheers,
Jimmy

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


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

Re: [openstack-dev] [Openstack-operators] [all] Bringing the community together (combine the lists!)

On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
[...]
> I really don't want this. I'm happy with things being sorted in
> multiple lists, even though I'm subscribed to multiples.

I understand where you're coming from, and I used to feel similarly.
I was accustomed to communities where developers had one mailing
list, users had another, and whenever a user asked a question on the
developer mailing list they were told to go away and bother the user
mailing list instead (not even a good, old-fashioned "RTFM" for
their trouble). You're probably intimately familiar with at least
one of these communities. ;)

As the years went by, it's become apparent to me that this is
actually an antisocial behavior pattern, and actively harmful to the
user base. I believe OpenStack actually wants users to see the
development work which is underway, come to understand it, and
become part of that process. Requiring them to have their
conversations elsewhere sends the opposite message.
-- 
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] [all] Bringing the community together (combine the lists!)

On 2018-08-30 12:57:31 -0600 (-0600), Chris Friesen wrote:
[...]
> Do we want to merge usage and development onto one list? That
> could be a busy list for someone who's just asking a simple usage
> question.

A counterargument though... projecting the number of unique posts to
all four lists combined for this year (both based on trending for
the past several years and also simply scaling the count of messages
this year so far based on how many days are left) comes out roughly
equal to the number of posts which were made to the general
openstack mailing list in 2012.

> Alternately, if we are going to merge everything then why not just
> use the "openstack" mailing list since it already exists and there
> are references to it on the web.

This was an option we discussed in the "One Community" forum session
as well. There seemed to be a slight preference for making a new
-disscuss list and retiring the old general one. I see either as an
potential solution here.

> (Or do you want to force people to move to something new to make them
> recognize that something has changed?)

That was one of the arguments made. Also I believe we have a *lot*
of "black hole" subscribers who aren't actually following that list
but whose addresses aren't bouncing new posts we send them for any
of a number of possible reasons.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote:
[...]
> What needs to be done for this is full topic categories support
> under `options` page so people get to filter emails properly.
[...]

Unfortunately, topic filtering is one of the MM2 features the
Mailman community decided nobody used (or at least not enough to
warrant preserving it in MM3). I do think we need to be consistent
about tagging subjects to make client-side filtering more effective
for people who want that, but if we _do_ want to be able to upgrade
we shouldn't continue to rely on server-side filtering support in
Mailman unless we can somehow work with them to help in
reimplementing it.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

2018-08-30 Thread Amy

Andy,

We’ll miss you! Thanks so much for all your hard work and leadership. 

Don’t be a stranger!

Amy (spotz)

Sent from my iPhone

> On Aug 30, 2018, at 11:05 AM, Ian Y. Choi  wrote:
> 
> Hello Andy,
> 
> Thanks a lot for your work on OpenStack-Ansible team.
> 
> It was very happy to collaborate with you as different teams (me: I18n team) 
> during Ocata and Pike release cycles,
> and I think I18n team now has better insight on OpenStack-Ansible thanks to 
> the help from you and so many kind contributors.
> 
> 
> With many thanks,
> 
> /Ian
> 
> Andy McCrae wrote on 8/31/2018 2:40 AM:
>> Now that Rocky is all but ready it seems like a good time! Since changing 
>> roles I've not been able to keep up enough focus on reviews and other 
>> obligations - so I think it's time to step aside as a core reviewer.
>> 
>> I want to say thanks to everybody in the community, I'm really proud to see 
>> the work we've done and how the OSA team has grown. I've learned a tonne 
>> from all of you - it's definitely been a great experience.
>> 
>> Thanks,
>> Andy
>> 
>> 
>> __
>> OpenStack Development Mailing 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-ansible] Stepping down from OpenStack-Ansible core


Thanks for all you do and have done for the OpenStack Community, Andy :)

Andy McCrae wrote:
Now that Rocky is all but ready it seems like a good time! Since 
changing roles I've not been able to keep up enough focus on reviews 
and other obligations - so I think it's time to step aside as a core 
reviewer.


I want to say thanks to everybody in the community, I'm really proud 
to see the work we've done and how the OSA team has grown. I've 
learned a tonne from all of you - it's definitely been a great experience.


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



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

Re: [openstack-dev] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Thomas Goirand

On 08/30/2018 08:57 PM, Chris Friesen wrote:
> On 08/30/2018 11:03 AM, Jeremy Stanley wrote:
> 
>> The proposal is simple: create a new openstack-discuss mailing list
>> to cover all the above sorts of discussion and stop using the other
>> four.
> 
> Do we want to merge usage and development onto one list?
I really don't want this. I'm happy with things being sorted in multiple
lists, even though I'm subscribed to multiples.

Thomas

__
OpenStack Development Mailing 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] [senlin] weekly meeting

2018-08-30 Thread Duc Truong

Hi everyone,

We'll be having our weekly meeting today at 0530 UTC in the #senlin channel.
The meeting agenda has been posted:
https://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282018-08-31_0530_UTC.29

Regards,

Duc

__
OpenStack Development Mailing 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] Guidelines for Organisations Contributing to OpenStack

2018-08-30 Thread Kendall Nelson

Hello,

Backstory on this topic: conversations started before the Vancouver Summit
about drafting a base set of necessities that we could give to companies to
help them understand what their employees will need if they are going to be
effective contributors to OpenStack.

There was initial brainstorming on this list of guidelines[1]. Then the
Forum discussion in Vancouver[2] happened. Next there was the traditional,
post-forum summary that went out to the dev list[3]. Lastly, we finally
have a draft patch that needs some attention[4] to keep it moving forward.

This is where we'd love some help: What are we missing? Were there any
stumbling blocks for you and your workplace? Anything we should wordsmith
better?

The hope is that once this is complete, its something we can present to the
board, new sponsors, or other companies interested in getting involved
upstream on OpenStack along with the contributor guide[5] and contributor
portal[6] to help people integrate into the community faster.

Your thoughts and input would be greatly appreciated!

-Kendall (diablo_rojo)

[1] https://etherpad.openstack.org/p/Contributing_Organization_Guide
[2]
https://etherpad.openstack.org/p/Reqs-for-Organisations-Contributing-to-OpenStack

[3]
http://lists.openstack.org/pipermail/openstack-sigs/2018-June/000410.html
[4] https://review.openstack.org/#/c/578676/
[5] https://docs.openstack.org/contributors/
[6] https://www.openstack.org/community/
__
OpenStack Development Mailing 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] [goal][python3] week 3 update

Excerpts from Doug Hellmann's message of 2018-08-29 20:04:16 -0400:
> Excerpts from Doug Hellmann's message of 2018-08-29 15:22:56 -0400:
> > Excerpts from David Peacock's message of 2018-08-29 15:12:03 -0400:
> > > On Wed, Aug 29, 2018 at 1:02 PM Doug Hellmann  
> > > wrote:
> > > 
> > > > Excerpts from Doug Hellmann's message of 2018-08-29 09:50:58 -0400:
> > > > > Excerpts from David Peacock's message of 2018-08-29 08:53:26 -0400:
> > > > > > On Mon, Aug 27, 2018 at 3:38 PM Doug Hellmann 
> > > > > > 
> > > > wrote:
> > > > > >
> > > > > > > If your team is ready to have your zuul settings migrated, please
> > > > > > > let us know by following up to this email. We will start with the
> > > > > > > volunteers, and then work our way through the other teams.
> > > > > > >
> > > > > >
> > > > > > TripleO team is ready to participate.  I'll coordinate on our end.
> > > > >
> > > > > I will generate the patches today and watch for a time when the CI 
> > > > > load
> > > > > is low to submit them.
> > > > >
> > > > > Doug
> > > > >
> > > >
> > > > It appears that someone who is not listed as a goal champion has
> > > > already submitted a bunch of patches for importing the zuul settings
> > > > into the TripleO repositories without updating our tracking story.
> > > > The keystone team elected to abandon a similar set of patches because
> > > > some of them were incorrect. I don't know whether that applies to
> > > > these.
> > > >
> > > > Do you want to review the ones that are open, or would you like for me
> > > > to generate a new batch?
> > > >
> > > > Doug
> > > >
> > > 
> > > Please would you mind pasting me the reviews in question, then I'll take a
> > > look and let you know which direction.
> > > 
> > > Thanks!
> > 
> > Here's the list of open changes I see right now:
> > 
> > +--+-++--+-+---+
> > | Subject  | Repo   
> >  | Tests  | Workflow | URL 
> > | Branch|
> > +--+-++--+-+---+
> > | fix tox python3 overrides| openstack-infra/tripleo-ci 
> >  | PASS   | REVIEWED | https://review.openstack.org/588587 
> > | master|
> > | import zuul job settings from project-config | 
> > openstack/ansible-role-k8s-glance   | FAILED | NEW  | 
> > https://review.openstack.org/596021 | master|
> > | import zuul job settings from project-config | 
> > openstack/ansible-role-k8s-keystone | FAILED | NEW  | 
> > https://review.openstack.org/596022 | master|
> > | import zuul job settings from project-config | 
> > openstack/ansible-role-k8s-mariadb  | FAILED | NEW  | 
> > https://review.openstack.org/596023 | master|
> > | import zuul job settings from project-config | openstack/dib-utils
> >  | PASS   | NEW  | https://review.openstack.org/596024 
> > | master|
> > | fix tox python3 overrides| openstack/instack  
> >  | PASS   | REVIEWED | https://review.openstack.org/572904 
> > | master|
> > | import zuul job settings from project-config | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596025 
> > | master|
> > | add python 3.6 unit test job | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596026 
> > | master|
> > | add python 3.6 unit test job | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596027 
> > | master|
> > | import zuul job settings from project-config | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596085 
> > | stable/ocata  |
> > | import zuul job settings from project-config | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596105 
> > | stable/pike   |
> > | import zuul job settings from project-config | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596121 
> > | stable/queens |
> > | import zuul job settings from project-config | openstack/instack  
> >  | PASS   | NEW  | https://review.openstack.org/596138 
> > | stable/rocky  |
> > | import zuul job settings from project-config | 
> > openstack/instack-undercloud| FAILED | NEW  | 
> > https://review.openstack.org/596086 | stable/ocata  |
> > | import zuul job settings from project-config | 
> > openstack/instack-undercloud|

Re: [openstack-dev] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Kristi Nikolla

I’m strongly in support of merging the lists.

> On Aug 30, 2018, at 2:57 PM, Chris Friesen  
> wrote:
> 
> On 08/30/2018 11:03 AM, Jeremy Stanley wrote:
> 
>> The proposal is simple: create a new openstack-discuss mailing list
>> to cover all the above sorts of discussion and stop using the other
>> four.
> 
> Do we want to merge usage and development onto one list?  That could be a 
> busy list for someone who's just asking a simple usage question.

True, but it would bring more visibility to the developers about troubles that 
users are having.

> 
> Alternately, if we are going to merge everything then why not just use the 
> "openstack" mailing list since it already exists and there are references to 
> it on the web.
> 
> (Or do you want to force people to move to something new to make them 
> recognize that something has changed?)
> 
> Chris
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-30 Thread James Slagle

On Mon, Aug 20, 2018 at 4:47 PM James Slagle  wrote:
> https://etherpad.openstack.org/p/tripleo-edge-squad-status

Several folks have signed up for the squad, so I've added a poll in
the etherpad to pick a meeting time.

> --
> -- James Slagle
> --



-- 
-- James Slagle
--

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

[openstack-dev] [goals][python3] small change of schedule for changing packaging jobs

I had originally been planning to wait for the cycle-trailing
projects to finish Rocky before updating the release jobs to use
the python3 versions. However, Sean reminded me today that we
extended the deadline for cycle-trailing projects to 2 months from
now, and I don't think we want to wait that long to change the other
projects.

I have prepared a patch [1] to switch all official python projects
to the python3 publishing job right away, so we have time to resolve
any issues that causes before the first milestone of the Stein
cycle.

As I mentioned before, when that patch lands, it will add a new
check job to all projects so that if any packaging-related files
are changed the ability to package the project is tested. Let me
know if you run into any difficulties.

Doug

[1] https://review.openstack.org/598323

__
OpenStack Development Mailing 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] Bringing the community together (combine the lists!)

2018-08-30 Thread Chris Friesen


On 08/30/2018 11:03 AM, Jeremy Stanley wrote:


The proposal is simple: create a new openstack-discuss mailing list
to cover all the above sorts of discussion and stop using the other
four.


Do we want to merge usage and development onto one list?  That could be a busy 
list for someone who's just asking a simple usage question.


Alternately, if we are going to merge everything then why not just use the 
"openstack" mailing list since it already exists and there are references to it 
on the web.


(Or do you want to force people to move to something new to make them recognize 
that something has changed?)


Chris

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

Re: [openstack-dev] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0

On 18-08-30 20:48:39, Yossi Boaron wrote:
> Hi Matthew,
> 
> Seems that Openshift version 0.7 was released few hours ago, this version
> should work properly with kubernetes.
> I"ll update my PR to change openshift upper constraint to 0.7 and leave K8S
> at 7.0.0
> 
> 10x
> Yossi
> 
> בתאריך יום ה׳, 30 באוג׳ 2018, 19:12, מאת Matthew Thode ‏<
> prometheanf...@gentoo.org>:
> 
> > On 18-08-30 17:54:24, Yossi Boaron wrote:
> > > Hi All,
> > >
> > > Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1].
> > > Currently, the Openshift python client can't work with Kubernetes 7.0.0,
> > > this caused by a version pinning issue (pulled in Kubernetes 7.0.0).
> > > As a result of that, we are unable to run some of our tempest tests in
> > > kuryr-kubernetes project.
> > >
> > > As a temporary (till an Openshift version that supports kubernets 7.0.0
> > > will be released) we would like to suggest to set back kubernetes upper
> > > constraint to 6.0.0 [2].
> >
> > How long til a version that supports >=7.0.0 comes out?
> >
> > >
> > > Do you see any problem with this approach?
> > >

Sounds great, thanks

-- 
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] [goals][python3] modifying the zuul setting import patches

A few reviewers have suggested using some YAML features that allow
repeated sections to be inserted by reference, instead of copying
and pasting content in different parts of the Zuul configuration.
That's a great idea! However, please do that AFTER the migration
is complete. For now, to make the transition smooth, please just
take the patches as they are (unless there is something wrong with
them, of course).

If significant changes to existing jobs are made before the cleanup
is done, then those versions of the job variants might not be used
when the patch is tested, and when the clean-up patch lands your
project might be broken.  When we approve the change in project-config
to remove the settings there, then any other changes to the job
settings in-tree can be self-testing, and even if it's not self-testing
it will be easier to see that a job setting changed right before the job
started failing.

So, again, please don't block the migration work on aesthetic concerns.
This will all go much more smoothly and quickly if we save those changes
for later.

Doug

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

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

2018-08-30 Thread melanie witt

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

Gibi, Bence,

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

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

-melanie

On Thu, Aug 30, 2018 at 3:55 AM, Balázs Gibizer
mailto:balazs.gibi...@ericsson.com>> wrote:

Hi,

Based on the Nova PTG planning etherpad [1] there is a need to talk
about the current state of the bandwidth work [2][3]. Bence
(rubasov) has already planned to show a small demo to Neutron folks
about the current state of the implementation. So Bence and I are
wondering about bringing that demo close to the nova - neutron cross
project session. That session is currently planned to happen
Thursday after lunch. So we are think about showing the demo right
before that session starts. It would start 30 minutes before the
nova - neutron cross project session.

Are Nova folks also interested in seeing such a demo?

If you are interested in seeing the demo please drop us a line or
ping us in IRC so we know who should we wait for.

Cheers,
gibi

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

[2]

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

[3]

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

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

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

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

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

2018-08-30 Thread Ian Y. Choi


Hello Andy,

Thanks a lot for your work on OpenStack-Ansible team.

It was very happy to collaborate with you as different teams (me: I18n 
team) during Ocata and Pike release cycles,
and I think I18n team now has better insight on OpenStack-Ansible thanks 
to the help from you and so many kind contributors.



With many thanks,

/Ian

Andy McCrae wrote on 8/31/2018 2:40 AM:
Now that Rocky is all but ready it seems like a good time! Since 
changing roles I've not been able to keep up enough focus on reviews 
and other obligations - so I think it's time to step aside as a core 
reviewer.


I want to say thanks to everybody in the community, I'm really proud 
to see the work we've done and how the OSA team has grown. I've 
learned a tonne from all of you - it's definitely been a great experience.


Thanks,
Andy


__
OpenStack Development Mailing 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] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0

2018-08-30 Thread Yossi Boaron

Hi Matthew,

Seems that Openshift version 0.7 was released few hours ago, this version
should work properly with kubernetes.
I"ll update my PR to change openshift upper constraint to 0.7 and leave K8S
at 7.0.0

10x
Yossi

בתאריך יום ה׳, 30 באוג׳ 2018, 19:12, מאת Matthew Thode ‏<
prometheanf...@gentoo.org>:

> On 18-08-30 17:54:24, Yossi Boaron wrote:
> > Hi All,
> >
> > Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1].
> > Currently, the Openshift python client can't work with Kubernetes 7.0.0,
> > this caused by a version pinning issue (pulled in Kubernetes 7.0.0).
> > As a result of that, we are unable to run some of our tempest tests in
> > kuryr-kubernetes project.
> >
> > As a temporary (till an Openshift version that supports kubernets 7.0.0
> > will be released) we would like to suggest to set back kubernetes upper
> > constraint to 6.0.0 [2].
>
> How long til a version that supports >=7.0.0 comes out?
>
> >
> > Do you see any problem with this approach?
> >
> > Best regards
> > Yossi
> >
> > [1] - https://review.openstack.org/#/c/594495/
> > [2] - https://review.openstack.org/#/c/595569/
>
> --
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing 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] [api] Open API 3.0 for OpenStack API

Excerpts from Edison Xiang's message of 2018-08-30 14:08:12 +0800:
> Hey dims,
> 
> Thanks your reply. Your suggestion is very important.
> 
> > what would be the impact to projects?
> > what steps they would have to take?
> 
> We can launch a project to publish OpenStack Projects APIs Schema for users
> and  developers.
> But now OpenStack Projects have no APIs Schema definition.
> Open API will not impact OpenStack Projects features they have,
> but we need some volunteers to define every project APIs Schema by Open API
> 3.0.
> 
> > Do we have a sample/mock API where we can show that the Action and
> Microversions can be declared to reflect reality and it can actually work
> with the generated code?
> Yeah, you can copy this yaml [1] into editor [2] to generate server or
> client codes or try it out.
> We can do more demos later.
> 
> [1]
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml
> [2] https://editor.swagger.io
> 
> Best Regards,
> Edison Xiang

How does this proposal relate to the work that has already been
done to build the API guide
https://developer.openstack.org/api-guide/quick-start/ documentation?

Doug

> 
> On Wed, Aug 29, 2018 at 6:31 PM Davanum Srinivas  wrote:
> 
> > Edison,
> >
> > This is definitely a step in the right direction if we can pull it off.
> >
> > Given the previous experiences and the current situation of how and where
> > we store the information currently and how we generate the website for the
> > API(s), can you please outline
> > - what would be the impact to projects?
> > - what steps they would have to take?
> >
> > Also, the whole point of having these definitions is that the generated
> > code works. Do we have a sample/mock API where we can show that the Action
> > and Microversions can be declared to reflect reality and it can actually
> > work with the generated code?
> >
> > Thanks,
> > Dims
> >
> > On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang 
> > wrote:
> >
> >> Hi team,
> >>
> >> 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.
> >>
> >> Some limitations are mentioned in the Mail List for OpenStack API:
> >> 1. The POST */action APIs.
> >> These APIs are exist in lots of projects like nova, cinder.
> >> These APIs have the same URI but the responses will be different when
> >> the request is different.
> >> 2. Micro versions.
> >> These are controller via headers, which are sometimes used to
> >> describe behavioral changes in an API, not just request/response schema
> >> changes.
> >>
> >> About the first limitation, we can find the solution in the Open API 3.0.
> >> The example [2] shows that we can define different request/response in
> >> the same URI by anyof feature in Open API 3.0.
> >>
> >> About the micro versions problem, I think it is not a limitation related
> >> a special API Standard.
> >> We can list all micro versions API schema files in one directory like
> >> nova/V2,
> >> or we can list the schema changes between micro versions as tempest
> >> project did [3].
> >>
> >> Based on Open API 3.0, it can bring lots of benefits for OpenStack
> >> Community and does not impact the current features the  Community has.
> >> For example, we can automatically generate API documents, different
> >> language Clients(SDK) maybe for different micro versions,
> >> and generate cloud tool adapters for OpenStack, like ansible module,
> >> terraform providers and so on.
> >> Also we can make an API UI to provide an online and visible API search,
> >> API Calling for every OpenStack API.
> >> 3rd party developers can also do some self-defined development.
> >>
> >> [1] https://github.com/OAI/OpenAPI-Specification
> >> [2]
> >> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> >> [3]
> >> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> >>
> >> Best Regards,
> >> Edison Xiang
> >>
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

__

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

2018-08-30 Thread Miguel Lavalle

Gibi, Bence,

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

Cheers

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

> Hi,
>
> Based on the Nova PTG planning etherpad [1] there is a need to talk about
> the current state of the bandwidth work [2][3]. Bence (rubasov) has already
> planned to show a small demo to Neutron folks about the current state of
> the implementation. So Bence and I are wondering about bringing that demo
> close to the nova - neutron cross project session. That session is
> currently planned to happen Thursday after lunch. So we are think about
> showing the demo right before that session starts. It would start 30
> minutes before the nova - neutron cross project session.
>
> Are Nova folks also interested in seeing such a demo?
>
> If you are interested in seeing the demo please drop us a line or ping us
> in IRC so we know who should we wait for.
>
> Cheers,
> gibi
>
> [1] https://etherpad.openstack.org/p/nova-ptg-stein
> [2] https://specs.openstack.org/openstack/neutron-specs/specs/ro
> cky/minimum-bandwidth-allocation-placement-api.html
> [3] https://specs.openstack.org/openstack/nova-specs/specs/rocky
> /approved/bandwidth-resource-provider.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0

2018-08-30 Thread Yossi Boaron

בתאריך יום ה׳, 30 באוג׳ 2018, 19:12, מאת Matthew Thode ‏<
prometheanf...@gentoo.org>:

> On 18-08-30 17:54:24, Yossi Boaron wrote:
> > Hi All,
> >
> > Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1].
> > Currently, the Openshift python client can't work with Kubernetes 7.0.0,
> > this caused by a version pinning issue (pulled in Kubernetes 7.0.0).
> > As a result of that, we are unable to run some of our tempest tests in
> > kuryr-kubernetes project.
> >
> > As a temporary (till an Openshift version that supports kubernets 7.0.0
> > will be released) we would like to suggest to set back kubernetes upper
> > constraint to 6.0.0 [2].
>
> How long til a version that supports >=7.0.0 comes out?
>
> >
> > Do you see any problem with this approach?
> >
> > Best regards
> > Yossi
> >
> > [1] - https://review.openstack.org/#/c/594495/
> > [2] - https://review.openstack.org/#/c/595569/
>
> --
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

2018-08-30 Thread Andy McCrae

Now that Rocky is all but ready it seems like a good time! Since changing
roles I've not been able to keep up enough focus on reviews and other
obligations - so I think it's time to step aside as a core reviewer.

I want to say thanks to everybody in the community, I'm really proud to see
the work we've done and how the OSA team has grown. I've learned a tonne
from all of you - it's definitely been a great experience.

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

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

2018-08-30 Thread Miguel Lavalle

Gibi, Bence,

Thanks for putting this demo together. Please count me in

Regards

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

> Hi,
>
> Based on the Nova PTG planning etherpad [1] there is a need to talk about
> the current state of the bandwidth work [2][3]. Bence (rubasov) has already
> planned to show a small demo to Neutron folks about the current state of
> the implementation. So Bence and I are wondering about bringing that demo
> close to the nova - neutron cross project session. That session is
> currently planned to happen Thursday after lunch. So we are think about
> showing the demo right before that session starts. It would start 30
> minutes before the nova - neutron cross project session.
>
> Are Nova folks also interested in seeing such a demo?
>
> If you are interested in seeing the demo please drop us a line or ping us
> in IRC so we know who should we wait for.
>
> Cheers,
> gibi
>
> [1] https://etherpad.openstack.org/p/nova-ptg-stein
> [2] https://specs.openstack.org/openstack/neutron-specs/specs/ro
> cky/minimum-bandwidth-allocation-placement-api.html
> [3] https://specs.openstack.org/openstack/nova-specs/specs/rocky
> /approved/bandwidth-resource-provider.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [goal][python3] week 3 update

Excerpts from Michel Peterson's message of 2018-08-30 09:43:30 +0300:
> On Thu, Aug 30, 2018 at 3:11 AM, Doug Hellmann 
> wrote:
> 
> > > OK, there are somewhere just over 100 patches for all of the neutron
> > > repositories, so I'm going to wait for a quieter time of day to submit
> > > them to avoid blocking other, smaller, bits of work.
> > >
> > > Doug
> >
> > Those patches are up for review now. - Doug
> >
> >
> Doug, just a heads up the tool for python3-first is duplicating the same
> block of code (e.g. https://review.openstack.org/#
> /c/597873/1/.zuul.d/project.yaml ) and in some cases duplicating code that
> already exists (e.g. https://review.openstack.org/#
> /c/597872/1/.zuul.d/project.yaml ).
> 
> Perhaps it will be good to review the tool before moving forward.

Thanks for the heads-up.

We ran into similar issues in one or two other places. The tool is,
frankly, not all that smart. *Most* teams don't have any settings
like this in their local zuul config, and given the relatively few
cases where it's a problem I think it's going to be easier to just
fix the patches by hand than to make the tool smarter.

Doug

> 
> Best,
> M
> 
> P.S. I've sent you the same through #openstack-infra

__
OpenStack Development Mailing 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] [goal][python3] week 3 update

Excerpts from Michel Peterson's message of 2018-08-30 12:51:04 +0300:
> On Thu, Aug 30, 2018 at 3:11 AM, Doug Hellmann 
> wrote:
> 
> > | import zuul job settings from project-config | openstack/networking-odl
> >  | https://review.openstack.org/597870 | master|
> > | switch documentation job to new PTI  | openstack/networking-odl
> >  | https://review.openstack.org/597871 | master|
> > | add python 3.5 unit test job | openstack/networking-odl
> >  | https://review.openstack.org/597872 | master|
> > | add python 3.6 unit test job | openstack/networking-odl
> >  | https://review.openstack.org/597873 | master|
> > | import zuul job settings from project-config | openstack/networking-odl
> >  | https://review.openstack.org/597911 | stable/ocata  |
> > | import zuul job settings from project-config | openstack/networking-odl
> >  | https://review.openstack.org/597923 | stable/pike   |
> > | import zuul job settings from project-config | openstack/networking-odl
> >  | https://review.openstack.org/597938 | stable/queens |
> > | import zuul job settings from project-config | openstack/networking-odl
> >  | https://review.openstack.org/597953 | stable/rocky  |
> 
> 
> In the case of networking-odl I know we also need a 'fix tox python3
> overrides' patch but that was not generated. I'm wondering if I should do
> it manually or it will be generated at a later stage?

Those patches were done a while ago, and are not part of the set of
patches generated by the current scripts. I'm not sure why
networking-odl didn't receive one.

I suggest going ahead and creating that patch by hand.

Doug

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

Re: [openstack-dev] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

2018-08-30 Thread Emilien Macchi

On Thu, Aug 30, 2018 at 1:21 PM Julia Kreger 
wrote:

> Greetings everyone,
>
> It looks like the most agreeable time on the doodle[1] seems to be
> Tuesday September 4th at 13:00 UTC. Are there any objections to using
> this time?
>
> If not, I'll go ahead and create an etherpad, and setup a bluejeans
> call for that time to enable high bandwidth discussion.
>

TripleO sessions start on Wednesday, so +1 from us (unless I missed
something).
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][python3] Neutron and stadium - python 3 community goal changes coming soon

Excerpts from Andreas Jaeger's message of 2018-08-30 17:32:46 +0200:
> On 2018-08-30 17:16, Nate Johnston wrote:
> > On Thu, Aug 30, 2018 at 08:28:40AM -0400, Doug Hellmann wrote:
> >> Excerpts from Michel Peterson's message of 2018-08-30 14:38:00 +0300:
> >>> On Thu, Aug 30, 2018 at 12:14 AM, Nate Johnston 
> >>> wrote:
> >>>
>  Progress is also being tracked in a wiki page [4].
> 
>  [4] https://wiki.openstack.org/wiki/Python3
> 
> >>>
> >>> That wiki page should only track teams or subteams should also be included
> >>> there? I'm asking because it seems that some subteams appear there while
> >>> the majority doesn't and perhaps we want to standarize that.
> >>
> >> It would be great to include information about sub-teams. If there
> >> are several, like in the neutron case, it probably makes sense to
> >> create a separate section of the page with a table for all of them,
> >> just to keep things organized.
> > 
> > Great!  I'll do that today.
> > 
> > Nate
> > 
> > P.S. By the way, at the top there is a note encouraging people to join
> > #openstack-python3, but when I try to do so I get rejected:
> > 
> > 11:13  Error(473): #openstack-python3 Cannot join channel (+i) - 
> > you must be invited
> > 
> > I figure either the wiki page or the channel is out of sync, but I am
> > not sure which one.
> 
> wiki page is wrong - the channel is dead. I'll update the wiki page,
> 
> Andreas

Thanks, Andreas!

__
OpenStack Development Mailing 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] Bringing the community together (combine the lists!)

2018-08-30 Thread Julia Kreger

I fully support merging the lists proposed, as well as the interop-wg
list that Chris Hodge proposed. I look forward to the day when cross
posting is no longer a necessary evil.

-Julia
On Thu, Aug 30, 2018 at 10:04 AM Jeremy Stanley  wrote:
>
> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
>
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
>
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
>
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
>
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
>
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
>
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
>
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
>
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics
> --
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

2018-08-30 Thread Julia Kreger

Greetings everyone,

It looks like the most agreeable time on the doodle[1] seems to be
Tuesday September 4th at 13:00 UTC. Are there any objections to using
this time?

If not, I'll go ahead and create an etherpad, and setup a bluejeans
call for that time to enable high bandwidth discussion.

-Julia
[1]: https://doodle.com/poll/y355wt97heffvp3m

On Mon, Aug 27, 2018 at 9:53 AM Julia Kreger
 wrote:
>
> Greetings everyone!
>
> We in Ironic land would like to go into the PTG with some additional
> thoughts, requirements, and ideas as it relates to distributed and
> geographically distributed deployments.
>
[trim]

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

Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Chris Hoge

I also propose that we merge the interop-wg mailing list also,
as the volume on that list is small but topics posted to it are of
general interest to the community.

Chris Hoge
(Interop WG Secretary, amongst other things)

> On Aug 30, 2018, at 10:03 AM, Jeremy Stanley  wrote:
> 
> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
> 
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
> 
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
> 
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
> 
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
> 
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
> 
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
> 
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
> 
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics
> -- 
> Jeremy Stanley
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs


__
OpenStack Development Mailing 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] Bringing the community together (combine the lists!)


Absolutely support merging.

Jeremy Stanley wrote:

The openstack, openstack-dev, openstack-sigs and openstack-operators
mailing lists on lists.openstack.org see an increasing amount of
cross-posting and thread fragmentation as conversants attempt to
reach various corners of our community with topics of interest to
one or more (and sometimes all) of those overlapping groups of
subscribers. For some time we've been discussing and trying ways to
bring our developers, distributors, operators and end users together
into a less isolated, more cohesive community. An option which keeps
coming up is to combine these different but overlapping mailing
lists into one single discussion list. As we covered[1] in Vancouver
at the last Forum there are a lot of potential up-sides:

1. People with questions are no longer asking them in a different
place than many of the people who have the answers to those
questions (the "not for usage questions" in the openstack-dev ML
title only serves to drive the wedge between developers and users
deeper).

2. The openstack-sigs mailing list hasn't seem much uptake (an order
of magnitude fewer subscribers and posts) compared to the other
three lists, yet it was intended to bridge the communication gap
between them; combining those lists would have been a better
solution to the problem than adding yet another turned out to be.

3. At least one out of every ten messages to any of these lists is
cross-posted to one or more of the others, because we have topics
that span across these divided groups yet nobody is quite sure which
one is the best venue for them; combining would eliminate the
fragmented/duplicative/divergent discussion which results from
participants following up on the different subsets of lists to which
they're subscribed,

4. Half of the people who are actively posting to at least one of
the four lists subscribe to two or more, and a quarter to three if
not all four; they would no longer be receiving multiple copies of
the various cross-posts if these lists were combined.

The proposal is simple: create a new openstack-discuss mailing list
to cover all the above sorts of discussion and stop using the other
four. As the OpenStack ecosystem continues to mature and its
software and services stabilize, the nature of our discourse is
changing (becoming increasingly focused with fewer heated debates,
distilling to a more manageable volume), so this option is looking
much more attractive than in the past. That's not to say it's quiet
(we're looking at roughly 40 messages a day across them on average,
after deduplicating the cross-posts), but we've grown accustomed to
tagging the subjects of these messages to make it easier for other
participants to quickly filter topics which are relevant to them and
so would want a good set of guidelines on how to do so for the
combined list (a suggested set is already being brainstormed[2]).
None of this is set in stone of course, and I expect a lot of
continued discussion across these lists (oh, the irony) while we try
to settle on a plan, so definitely please follow up with your
questions, concerns, ideas, et cetera.

As an aside, some of you have probably also seen me talking about
experiments I've been doing with Mailman 3... I'm hoping new
features in its Hyperkitty and Postorius WebUIs make some of this
easier or more accessible to casual participants (particularly in
light of the combined list scenario), but none of the plan above
hinges on MM3 and should be entirely doable with the MM2 version
we're currently using.

Also, in case you were wondering, no the irony of cross-posting this
message to four mailing lists is not lost on me. ;)

[1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
[2] https://etherpad.openstack.org/p/common-openstack-ml-topics
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

Excerpts from Jeremy Stanley's message of 2018-08-30 17:03:50 +:
> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
> 
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
> 
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
> 
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
> 
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
> 
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
> 
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
> 
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
> 
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics

I fully support the idea of merging the lists.

Doug

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

Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Rico Lin

+1 on this idea, people been posting around for the exactly same topic and
got feedback from ops or devs, but never together, this will help people do
discussion on the same table.

What needs to be done for this is full topic categories support under
`options` page so people get to filter emails properly.


On Fri, Aug 31, 2018 at 1:04 AM Jeremy Stanley  wrote:

> The openstack, openstack-dev, openstack-sigs and openstack-operators
> mailing lists on lists.openstack.org see an increasing amount of
> cross-posting and thread fragmentation as conversants attempt to
> reach various corners of our community with topics of interest to
> one or more (and sometimes all) of those overlapping groups of
> subscribers. For some time we've been discussing and trying ways to
> bring our developers, distributors, operators and end users together
> into a less isolated, more cohesive community. An option which keeps
> coming up is to combine these different but overlapping mailing
> lists into one single discussion list. As we covered[1] in Vancouver
> at the last Forum there are a lot of potential up-sides:
>
> 1. People with questions are no longer asking them in a different
> place than many of the people who have the answers to those
> questions (the "not for usage questions" in the openstack-dev ML
> title only serves to drive the wedge between developers and users
> deeper).
>
> 2. The openstack-sigs mailing list hasn't seem much uptake (an order
> of magnitude fewer subscribers and posts) compared to the other
> three lists, yet it was intended to bridge the communication gap
> between them; combining those lists would have been a better
> solution to the problem than adding yet another turned out to be.
>
> 3. At least one out of every ten messages to any of these lists is
> cross-posted to one or more of the others, because we have topics
> that span across these divided groups yet nobody is quite sure which
> one is the best venue for them; combining would eliminate the
> fragmented/duplicative/divergent discussion which results from
> participants following up on the different subsets of lists to which
> they're subscribed,
>
> 4. Half of the people who are actively posting to at least one of
> the four lists subscribe to two or more, and a quarter to three if
> not all four; they would no longer be receiving multiple copies of
> the various cross-posts if these lists were combined.
>
> The proposal is simple: create a new openstack-discuss mailing list
> to cover all the above sorts of discussion and stop using the other
> four. As the OpenStack ecosystem continues to mature and its
> software and services stabilize, the nature of our discourse is
> changing (becoming increasingly focused with fewer heated debates,
> distilling to a more manageable volume), so this option is looking
> much more attractive than in the past. That's not to say it's quiet
> (we're looking at roughly 40 messages a day across them on average,
> after deduplicating the cross-posts), but we've grown accustomed to
> tagging the subjects of these messages to make it easier for other
> participants to quickly filter topics which are relevant to them and
> so would want a good set of guidelines on how to do so for the
> combined list (a suggested set is already being brainstormed[2]).
> None of this is set in stone of course, and I expect a lot of
> continued discussion across these lists (oh, the irony) while we try
> to settle on a plan, so definitely please follow up with your
> questions, concerns, ideas, et cetera.
>
> As an aside, some of you have probably also seen me talking about
> experiments I've been doing with Mailman 3... I'm hoping new
> features in its Hyperkitty and Postorius WebUIs make some of this
> easier or more accessible to casual participants (particularly in
> light of the combined list scenario), but none of the plan above
> hinges on MM3 and should be entirely doable with the MM2 version
> we're currently using.
>
> Also, in case you were wondering, no the irony of cross-posting this
> message to four mailing lists is not lost on me. ;)
>
> [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
> [2] https://etherpad.openstack.org/p/common-openstack-ml-topics
> --
> Jeremy Stanley
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Bringing the community together (combine the lists!)

The openstack, openstack-dev, openstack-sigs and openstack-operators
mailing lists on lists.openstack.org see an increasing amount of
cross-posting and thread fragmentation as conversants attempt to
reach various corners of our community with topics of interest to
one or more (and sometimes all) of those overlapping groups of
subscribers. For some time we've been discussing and trying ways to
bring our developers, distributors, operators and end users together
into a less isolated, more cohesive community. An option which keeps
coming up is to combine these different but overlapping mailing
lists into one single discussion list. As we covered[1] in Vancouver
at the last Forum there are a lot of potential up-sides:

1. People with questions are no longer asking them in a different
place than many of the people who have the answers to those
questions (the "not for usage questions" in the openstack-dev ML
title only serves to drive the wedge between developers and users
deeper).

2. The openstack-sigs mailing list hasn't seem much uptake (an order
of magnitude fewer subscribers and posts) compared to the other
three lists, yet it was intended to bridge the communication gap
between them; combining those lists would have been a better
solution to the problem than adding yet another turned out to be.

3. At least one out of every ten messages to any of these lists is
cross-posted to one or more of the others, because we have topics
that span across these divided groups yet nobody is quite sure which
one is the best venue for them; combining would eliminate the
fragmented/duplicative/divergent discussion which results from
participants following up on the different subsets of lists to which
they're subscribed,

4. Half of the people who are actively posting to at least one of
the four lists subscribe to two or more, and a quarter to three if
not all four; they would no longer be receiving multiple copies of
the various cross-posts if these lists were combined.

The proposal is simple: create a new openstack-discuss mailing list
to cover all the above sorts of discussion and stop using the other
four. As the OpenStack ecosystem continues to mature and its
software and services stabilize, the nature of our discourse is
changing (becoming increasingly focused with fewer heated debates,
distilling to a more manageable volume), so this option is looking
much more attractive than in the past. That's not to say it's quiet
(we're looking at roughly 40 messages a day across them on average,
after deduplicating the cross-posts), but we've grown accustomed to
tagging the subjects of these messages to make it easier for other
participants to quickly filter topics which are relevant to them and
so would want a good set of guidelines on how to do so for the
combined list (a suggested set is already being brainstormed[2]).
None of this is set in stone of course, and I expect a lot of
continued discussion across these lists (oh, the irony) while we try
to settle on a plan, so definitely please follow up with your
questions, concerns, ideas, et cetera.

As an aside, some of you have probably also seen me talking about
experiments I've been doing with Mailman 3... I'm hoping new
features in its Hyperkitty and Postorius WebUIs make some of this
easier or more accessible to casual participants (particularly in
light of the combined list scenario), but none of the plan above
hinges on MM3 and should be entirely doable with the MM2 version
we're currently using.

Also, in case you were wondering, no the irony of cross-posting this
message to four mailing lists is not lost on me. ;)

[1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
[2] https://etherpad.openstack.org/p/common-openstack-ml-topics
-- 
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][api] POST /api-sig/news

2018-08-30 Thread Chris Dent



Greetings OpenStack community,

There was nothing specific on the agenda this week, so much of the API-SIG meeting was 
spent discussing API-related topics that we'd encountered recently. One was: K8s Custom 
Resources [9] Cool or Chaos? The answer is, of course, "it depends". Another 
was a recent thread asking about the relevance of Open API 3.0 in the OpenStack 
environment [10]. We had trouble deciding what the desired outcome is, so for now are 
merely tracking the thread.

In the world of guidelines and bugs, not a lot of recent action. Some approved 
changes need to be rebased to actually get published, and the stack about 
version discovery [11] needs to be refreshed and potentially adopted by someone 
who is not Monty. If you're reading, Monty, and have thoughts on that, share 
them.

Next week we will be actively planning [7] for the PTG [8]. We have a room on 
Monday. We always have interesting and fun discussions when we're at the PTG, 
join us.

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://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
[10] http://lists.openstack.org/pipermail/openstack-dev/2018-August/133960.html
[11] https://review.openstack.org/#/c/459405/

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

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

Re: [openstack-dev] Inquiry about an opportunity to do a thesis project in collaboration with a OpenStack project.

Thank you for your intereset :) Another great place to start is here: 
https://www.openstack.org/community  This page has links to the 
Contributor Guide, as well as info on all of the OpenStack projects.


Another great way to catch up with the community is the OpenStack 
Summit.  We have one coming up in Berlin and we also offer travel 
support (this is the last day to apply):


https://www.openstack.org/summit/berlin-2018/
https://www.openstack.org/summit/berlin-2018/travel/#travel-support

In addition to travel support we offer very generous discounts to 
students.  Please email summit...@openstack.org if you want more info on 
this.


If you aren't able to make it to the summit, you can catch up on most of 
the presentations here: https://www.openstack.org/videos/summits  We 
typically post all the videos within a week or so of the end of the event.


Cheers and welcome to the OpenStack Community!
Jimmy

Julia Kreger wrote:

Greetings!

Welcome to the community!

Your interests seem to span quite a bit of the OpenStack community, so
I think it might be a good idea for you possibly look at the
individual teams that interest you the most, and reach out to those
teams and engage in discussion from there.

What may be a good idea is to look at the Rocky cycle release
highlights[1] as they provide high level summaries and what the
recently added features were for each project as part of this past
development cycle. We're just now starting the Stein cycle, so now is
really the perfect time to join in.

-Julia

[1]: https://releases.openstack.org/rocky/highlights.html
On Thu, Aug 30, 2018 at 9:31 AM Aniketh Gireesh
  wrote:

Hi,

I am Aniketh Girish, a Junior year Computer Science Engineering student at the 
Amrita University, Kerala, India. I’m writing to you to inquire about the 
possibility to do my thesis project in accordance with the OpenStack community 
and a project in the community.

I had initiated to contribute towards OpenStack a few months back. I took some 
time off since I was selected to participate in Google Summer of code with GNU 
Linux organization. For the last few months, I have been mainly focusing on 
implementing and learning about advanced internet protocols. My primary 
interest leans towards network security, with a particular interest in the 
Networking protocol and cloud computing infrastructures.

A selected project in my field of interest would be when, I was selected as a 
Google Summer of Code 2018, where I am working on the project Wget2 under GNU 
Linux organisation. This project involves adding support for DNS over HTTPS in 
Wget2. DNS over HTTPS(DoH) is a web protocol that argues for sending DNS 
requests and receiving DNS responses via HTTPS connections, hence providing 
query confidentiality. Therefore to provide such a name resolution, I devised a 
library where I implemented the DNS protocol by facilitating the library to 
create the DNS packet/request, queried A, , CNAME records and implemented 
the DoH protocol by parsing the DNS wire format from the HTTPS response body.

It is about time for me to look for a promising bachelor thesis project in my 
field of interest. I would like to know if there are any possibilities for me 
to work together with OpenStack in a project as a part of my thesis research.

Hope to hear back soon.

Cheers.
--
Aniketh Girish
Member at FOSS@Amrita
Amrita University
Github | GitLab | Blog | Website

"For the Love of Code."

__
OpenStack Development Mailing 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] Inquiry about an opportunity to do a thesis project in collaboration with a OpenStack project.

2018-08-30 Thread Julia Kreger

Greetings!

Welcome to the community!

Your interests seem to span quite a bit of the OpenStack community, so
I think it might be a good idea for you possibly look at the
individual teams that interest you the most, and reach out to those
teams and engage in discussion from there.

What may be a good idea is to look at the Rocky cycle release
highlights[1] as they provide high level summaries and what the
recently added features were for each project as part of this past
development cycle. We're just now starting the Stein cycle, so now is
really the perfect time to join in.

-Julia

[1]: https://releases.openstack.org/rocky/highlights.html
On Thu, Aug 30, 2018 at 9:31 AM Aniketh Gireesh
 wrote:
>
> Hi,
>
> I am Aniketh Girish, a Junior year Computer Science Engineering student at 
> the Amrita University, Kerala, India. I’m writing to you to inquire about the 
> possibility to do my thesis project in accordance with the OpenStack 
> community and a project in the community.
>
> I had initiated to contribute towards OpenStack a few months back. I took 
> some time off since I was selected to participate in Google Summer of code 
> with GNU Linux organization. For the last few months, I have been mainly 
> focusing on implementing and learning about advanced internet protocols. My 
> primary interest leans towards network security, with a particular interest 
> in the Networking protocol and cloud computing infrastructures.
>
> A selected project in my field of interest would be when, I was selected as a 
> Google Summer of Code 2018, where I am working on the project Wget2 under GNU 
> Linux organisation. This project involves adding support for DNS over HTTPS 
> in Wget2. DNS over HTTPS(DoH) is a web protocol that argues for sending DNS 
> requests and receiving DNS responses via HTTPS connections, hence providing 
> query confidentiality. Therefore to provide such a name resolution, I devised 
> a library where I implemented the DNS protocol by facilitating the library to 
> create the DNS packet/request, queried A, , CNAME records and implemented 
> the DoH protocol by parsing the DNS wire format from the HTTPS response body.
>
> It is about time for me to look for a promising bachelor thesis project in my 
> field of interest. I would like to know if there are any possibilities for me 
> to work together with OpenStack in a project as a part of my thesis research.
>
> Hope to hear back soon.
>
> Cheers.
> --
> Aniketh Girish
> Member at FOSS@Amrita
> Amrita University
> Github | GitLab | Blog | Website
>
> "For the Love of Code."
>
> __
> OpenStack Development Mailing 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] [nova][placement] Freezing placement for extraction

2018-08-30 Thread Eric Fried

Greetings.

The captains of placement extraction have declared readiness to begin
the process of seeding the new repository (once [1] has finished
merging). As such, we are freezing development in the affected portions
of the openstack/nova repository until this process is completed. We're
relying on our active placement reviewers noticing any patches that
touch these "affected portions" and, if that reviewer is not a nova
core, bringing them to the attention of one, so we can put a -2 on it.

Once the extraction is complete [2], any such frozen patches should be
abandoned and reproposed to the openstack/placement repository.

Since there will be an interval during which placement code will exist
in both repositories, but before $world has cut over to using
openstack/placement, it is possible that some crucial fix will still
need to be merged into the openstack/nova side. In this case, the fix
must be proposed to *both* repositories, and the justification for its
existence in openstack/nova made clear.

For more details on the technical aspects of the extraction process,
refer to this thread [3].

For information on the procedural/governance process we will be
following, see [4].

Please let us know if you have any questions or concerns, either via
this thread or in #openstack-placement.

[1] https://review.openstack.org/#/c/597220/
[2] meaning that we've merged the initial glut of patches necessary to
repath everything and get tests passing
[3]
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133781.html
[4] https://docs.openstack.org/infra/manual/creators.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

Re: [openstack-dev] [Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

2018-08-30 Thread Sean McGinnis

> >
> > Yeah it's already on the PTG agenda [1][2]. I started the thread because I
> > wanted to get the ball rolling as early as possible, and with people that
> > won't attend the PTG and/or the Forum, to weigh in on not only the known
> > issues with cross-cell migration but also the things I'm not thinking about.
> >
> > [1] https://etherpad.openstack.org/p/nova-ptg-stein
> > [2] https://etherpad.openstack.org/p/nova-ptg-stein-cells
> >
> > --
> >
> > Thanks,
> >
> > Matt
> >
> 
> Should we also add the topic to the Thursday Cinder-Nova slot in case
> there are some questions where the Cinder team can assist?
> 
> Cheers,
> Gorka.
> 

Good idea. That will be a good time to circle back between the teams to see if
any Cinder needs come up that we can still have time to talk through and see if
we can get work started.

__
OpenStack Development Mailing 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] Inquiry about an opportunity to do a thesis project in collaboration with a OpenStack project.

2018-08-30 Thread Aniketh Gireesh

Hi,

I am Aniketh Girish, a Junior year Computer Science Engineering student at
the Amrita University, Kerala, India. I’m writing to you to inquire about
the possibility to do my thesis project in accordance with the OpenStack
community and a project in the community.

I had initiated to contribute towards OpenStack a few months back. I took
some time off since I was selected to participate in Google Summer of code
with GNU Linux organization. For the last few months, I have been mainly
focusing on implementing and learning about advanced internet protocols. My
primary interest leans towards network security, with a particular interest
in the Networking protocol and cloud computing infrastructures.

A selected project in my field of interest would be when, I was selected as
a Google Summer of Code 2018, where I am working on the project Wget2 under
GNU Linux organisation. This project involves adding support for DNS over
HTTPS in Wget2. DNS over HTTPS(DoH) is a web protocol that argues for
sending DNS requests and receiving DNS responses via HTTPS connections,
hence providing query confidentiality. Therefore to provide such a name
resolution, I devised a library where I implemented the DNS protocol by
facilitating the library to create the DNS packet/request, queried A, ,
CNAME records and implemented the DoH protocol by parsing the DNS wire
format from the HTTPS response body.

It is about time for me to look for a promising bachelor thesis project in
my field of interest. I would like to know if there are any possibilities
for me to work together with OpenStack in a project as a part of my thesis
research.

Hope to hear back soon.

Cheers.
-- 
Aniketh Girish
Member at FOSS@Amrita 
Amrita University 
Github  | GitLab
 | Blog  |
Website 

"For the Love of Code."
__
OpenStack Development Mailing 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][nova] Nominating melwitt for nova stable core

2018-08-30 Thread Lee Yarwood

On 28-08-18 15:26:02, Matt Riedemann wrote:
> I hereby nominate Melanie Witt for nova stable core. Mel has shown that she
> knows the stable branch policy and is also an active reviewer of nova stable
> changes.
> 
> +1/-1 comes from the stable-maint-core team [1] and then after a week with
> no negative votes I think it's a done deal. Of course +1/-1 from existing
> nova-stable-maint [2] is also good feedback.
> 
> [1] https://review.openstack.org/#/admin/groups/530,members
> [2] https://review.openstack.org/#/admin/groups/540,members
 
+1 from me FWIW.

Thanks,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] Stepping down as keystone core

2018-08-30 Thread Gage Hugo

Thanks for all the help Samuel.  I remember a couple instances when I first
started contributing to keystone where you helped me out and I am extremely
grateful.  It was great working with you, and hopefully we will still see
you around!

On Wed, Aug 29, 2018 at 2:33 PM Lance Bragstad  wrote:

> Samuel,
>
> Thanks for all the dedication and hard work upstream. I'm relieved that
> you won't be too far away and that you're still involved with the Outreachy
> programs. You played an instrumental role in getting keystone involved with
> that community.
>
> As always, we'd be happy to have you back in the event your work involves
> keystone again.
>
> Best,
>
> Lance
>
> On Wed, Aug 29, 2018 at 2:25 PM Samuel de Medeiros Queiroz <
> samuel...@gmail.com> wrote:
>
>> Hi Stackers!
>>
>> It has been both an honor and privilege to serve this community as a
>> keystone core.
>>
>> I am in a position that does not allow me enough time to devote reviewing
>> code and participating of the development process in keystone. As a
>> consequence, I am stepping down as a core reviewer.
>>
>> A big thank you for your trust and for helping me to grow both as a
>> person and as professional during this time in service.
>>
>> I will stay around: I am doing research on interoperability for my
>> masters degree, which means I am around the SDK project. In addition to
>> that, I recently became the Outreachy coordinator for OpenStack.
>>
>> Let me know if you are interested on one of those things.
>>
>> Get in touch on #openstack-outreachy, #openstack-sdks or
>> #openstack-keystone.
>>
>> Thanks,
>> Samuel de Medeiros Queiroz (samueldmq)
>> __
>> OpenStack Development Mailing 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] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0

On 18-08-30 17:54:24, Yossi Boaron wrote:
> Hi All,
> 
> Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1].
> Currently, the Openshift python client can't work with Kubernetes 7.0.0,
> this caused by a version pinning issue (pulled in Kubernetes 7.0.0).
> As a result of that, we are unable to run some of our tempest tests in
> kuryr-kubernetes project.
> 
> As a temporary (till an Openshift version that supports kubernets 7.0.0
> will be released) we would like to suggest to set back kubernetes upper
> constraint to 6.0.0 [2].

How long til a version that supports >=7.0.0 comes out?

> 
> Do you see any problem with this approach?
> 
> Best regards
> Yossi
> 
> [1] - https://review.openstack.org/#/c/594495/
> [2] - https://review.openstack.org/#/c/595569/

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

Re: [openstack-dev] [tripleo] PTG topics and agenda

2018-08-30 Thread Giulio Fidente

On 8/28/18 2:50 PM, Juan Antonio Osorio Robles wrote:
> Hello folks!
> 
> 
> With the PTG being quite soon, I just wanted to remind folks to add your
> topics on the etherpad: https://etherpad.openstack.org/p/tripleo-ptg-stein

thanks Juan,

I think the Edge (line 53) and Split Control Plane (line 74) sessions
can probably be merged into a single one.

I'd be fine with James driving it, I think it'd be fine to discuss the
"control plane updates" issue [1] in that same session.

1.
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html

-- 
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [neutron][python3] Neutron and stadium - python 3 community goal changes coming soon

2018-08-30 Thread Andreas Jaeger


On 2018-08-30 17:16, Nate Johnston wrote:

On Thu, Aug 30, 2018 at 08:28:40AM -0400, Doug Hellmann wrote:

Excerpts from Michel Peterson's message of 2018-08-30 14:38:00 +0300:

On Thu, Aug 30, 2018 at 12:14 AM, Nate Johnston 
wrote:


Progress is also being tracked in a wiki page [4].

[4] https://wiki.openstack.org/wiki/Python3



That wiki page should only track teams or subteams should also be included
there? I'm asking because it seems that some subteams appear there while
the majority doesn't and perhaps we want to standarize that.


It would be great to include information about sub-teams. If there
are several, like in the neutron case, it probably makes sense to
create a separate section of the page with a table for all of them,
just to keep things organized.


Great!  I'll do that today.

Nate

P.S. By the way, at the top there is a note encouraging people to join
#openstack-python3, but when I try to do so I get rejected:

11:13  Error(473): #openstack-python3 Cannot join channel (+i) - you 
must be invited

I figure either the wiki page or the channel is out of sync, but I am
not sure which one.


wiki page is wrong - the channel is dead. I'll update the wiki page,

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] [neutron][python3] Neutron and stadium - python 3 community goal changes coming soon

2018-08-30 Thread Nate Johnston

On Thu, Aug 30, 2018 at 08:28:40AM -0400, Doug Hellmann wrote:
> Excerpts from Michel Peterson's message of 2018-08-30 14:38:00 +0300:
> > On Thu, Aug 30, 2018 at 12:14 AM, Nate Johnston 
> > wrote:
> > 
> > > Progress is also being tracked in a wiki page [4].
> > >
> > > [4] https://wiki.openstack.org/wiki/Python3
> > >
> > 
> > That wiki page should only track teams or subteams should also be included
> > there? I'm asking because it seems that some subteams appear there while
> > the majority doesn't and perhaps we want to standarize that.
> 
> It would be great to include information about sub-teams. If there
> are several, like in the neutron case, it probably makes sense to
> create a separate section of the page with a table for all of them,
> just to keep things organized.

Great!  I'll do that today.

Nate

P.S. By the way, at the top there is a note encouraging people to join
#openstack-python3, but when I try to do so I get rejected:

11:13  Error(473): #openstack-python3 Cannot join channel (+i) - you 
must be invited

I figure either the wiki page or the channel is out of sync, but I am
not sure which one.


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

Re: [openstack-dev] [tripleo] quickstart for humans

2018-08-30 Thread Jason E. Rist

On 08/30/2018 08:28 AM, Honza Pokorny wrote:
> Hello!
>
> Over the last few months, it seems that tripleo-quickstart has evolved
> into a CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of feature sets.  However, it's become less useful for
> setting up development environments by humans.  For example, devmode.sh
> was recently deprecated without a user-friendly replacement. Moreover,
> during some informal irc conversations in #oooq, some developers even
> mentioned the plan to merge tripleo-quickstart and tripleo-ci.
>
> I think it would be beneficial to create a set of defaults for
> tripleo-quickstart that can be used to spin up new environments; a set
> of defaults for humans.  This can either be a well-maintained script in
> tripleo-quickstart itself, or a brand new project, e.g.
> tripleo-quickstart-humans.  The number of settings, knobs, and flags
> should be kept to a minimum.
>
> This would accomplish two goals:
>
> 1.  It would bring uniformity to the team.  Each environment is
>     installed the same way.  When something goes wrong, we can
>     eliminate differences in setup when debugging.  This should save a
>     lot of time.
>
> 2.  Quicker and more reliable environment setup.  If the set of defaults
>     is used by many people, it should container fewer bugs because more
>     people using something should translate into more bug reports, and
>     more bug fixes.
>
> These thoughts are coming from the context of tripleo-ui development.  I
> need an environment in order to develop, but I don't necessarily always
> care about how it's installed.  I want something that works for most
> scenarios.
>
> What do you think?  Does this make sense?  Does something like this
> already exist?
>
> Thanks for listening!
>
> Honza
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Thanks for bringing this up, Honza.  If something like this does exist, please 
share.  Otherwise, we're moving further and further away from Quickstart being 
useful for Devs which is a problem for the entire community, in my opinion.

-J
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
OpenStack Development Mailing 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] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0

2018-08-30 Thread Yossi Boaron

Hi All,

Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1].
Currently, the Openshift python client can't work with Kubernetes 7.0.0,
this caused by a version pinning issue (pulled in Kubernetes 7.0.0).
As a result of that, we are unable to run some of our tempest tests in
kuryr-kubernetes project.

As a temporary (till an Openshift version that supports kubernets 7.0.0
will be released) we would like to suggest to set back kubernetes upper
constraint to 6.0.0 [2].

Do you see any problem with this approach?

Best regards
Yossi

[1] - https://review.openstack.org/#/c/594495/
[2] - https://review.openstack.org/#/c/595569/
__
OpenStack Development Mailing 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][nova] Nominating melwitt for nova stable core

2018-08-30 Thread Sylvain Bauza

On Wed, Aug 29, 2018 at 4:42 AM, Tony Breeds 
wrote:

> On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote:
> > I hereby nominate Melanie Witt for nova stable core. Mel has shown that
> she
> > knows the stable branch policy and is also an active reviewer of nova
> stable
> > changes.
> >
> > +1/-1 comes from the stable-maint-core team [1] and then after a week
> with
> > no negative votes I think it's a done deal. Of course +1/-1 from existing
> > nova-stable-maint [2] is also good feedback.
> >
> > [1] https://review.openstack.org/#/admin/groups/530,members
> > [2] https://review.openstack.org/#/admin/groups/540,members
>
> +1 from me!
>
>
+1 (just depiling emails)

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

[openstack-dev] [tripleo] quickstart for humans

2018-08-30 Thread Honza Pokorny

Hello!

Over the last few months, it seems that tripleo-quickstart has evolved
into a CI tool.  It's primarily used by computers, and not humans.
tripleo-quickstart is a helpful set of ansible playbooks, and a
collection of feature sets.  However, it's become less useful for
setting up development environments by humans.  For example, devmode.sh
was recently deprecated without a user-friendly replacement. Moreover,
during some informal irc conversations in #oooq, some developers even
mentioned the plan to merge tripleo-quickstart and tripleo-ci.

I think it would be beneficial to create a set of defaults for
tripleo-quickstart that can be used to spin up new environments; a set
of defaults for humans.  This can either be a well-maintained script in
tripleo-quickstart itself, or a brand new project, e.g.
tripleo-quickstart-humans.  The number of settings, knobs, and flags
should be kept to a minimum.

This would accomplish two goals:

1.  It would bring uniformity to the team.  Each environment is
installed the same way.  When something goes wrong, we can
eliminate differences in setup when debugging.  This should save a
lot of time.

2.  Quicker and more reliable environment setup.  If the set of defaults
is used by many people, it should container fewer bugs because more
people using something should translate into more bug reports, and
more bug fixes.

These thoughts are coming from the context of tripleo-ui development.  I
need an environment in order to develop, but I don't necessarily always
care about how it's installed.  I want something that works for most
scenarios.

What do you think?  Does this make sense?  Does something like this
already exist?

Thanks for listening!

Honza

__
OpenStack Development Mailing 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] [L2-Gateway]

2018-08-30 Thread Mike Oliveras

 Hello,

I am trying to get the l2gw feature installed on an openstack install on
centos 7 using the rdo queens repo.

Initially I installed the l2gw rpms form the repo:

 yum install openstack-neutron-l2gw-agent
==
PackageArch   Version
Repository
==
Installing:
 openstack-neutron-l2gw-agent  noarch 1:12.0.1-1.el7
centos-openstack-queens
Installing for dependencies:
 python2-networking-l2gw   noarch 1:12.0.1-1.el7
centos-openstack-queens

I enabled the service plugin in /etc/neutron/neutron.conf:
[root@gullwing-controller neutron]# grep service_plugin neutron.conf
service_plugins =
router,networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin

I pointed my l2gw plugin to my gw in l2gateway_agent.ini:
[root@gullwing-controller neutron]# grep ovsdb1 l2gateway_agent.ini
ovsdb_hosts = 'ovsdb1:10.0.0.31:6632'

I upgraded the neutron DB

systemctl stop neutron-server
neutron-db-manage --config-file /etc/neutron/neutron.conf
--config-file /etc/neutron/l2gw_plugin.ini  upgrade head
systemctl start neutron-server

I then added the "--config-file /etc/neutron/l2gw_plugin.ini" to the
ExecStart of the nova-server systemd unit file.

When I try to restart nova, it fails with:
2018-08-30 09:59:32.605 21059 ERROR neutron Invalid: Driver
networking_l2gw.services.l2gateway.service_drivers.rpc_l2gw.L2gwRpcDriver
is not unique across providers


One web page 
https://lonelypacket.co.uk/post/openstack-pike-l2gw-setup-on-ubuntu-16-04/
 suggested adding a service_providers
section to neutron.conf but it made no difference.
[service_providers]
service_provider=L2GW:l2gw:networking_l2gw.services.l2gateway.service_drivers.rpc_l2gw.L2gwRpcDriver:default

I also tried uninstalling the l2gw rpms and used a clone of
https://github.com/openstack/networking-l2gw, also tried
branch stable/queens.

When I tried that version, I got an error "AttributeError: 'module'
object has no attribute 'L3'" which seems to be related to
https://lists.launchpad.net/yahoo-eng-team/msg73944.html

I would appreciate any insight that you can give me and would be happy
to provide any requested info.

Thanks,

Mike Oliveras
__
OpenStack Development Mailing 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] [Freezer] Set up the Freezer team meeting

2018-08-30 Thread Trinh Nguyen

Hi Geng,

Could you please help us to set up the team meeting as you're the new PTL?
It supposes to be now on #openstack-meeting-alt. I sent you messages about
this but haven't got anything back from you.

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

Re: [openstack-dev] [neutron] tox-siblings alternative for local testing

2018-08-30 Thread Boden Russell

On 8/30/18 5:49 AM, Michel Peterson wrote:
> 
> There are pre releases available in PyPI [1]. You can use those from
> your requirements like we did in n-odl [2].
> 
> That might be an acceptable solution.
> 
> [1] https://pypi.org/project/neutron/#history
> [2] https://review.openstack.org/#/c/584791/
> 

IIUC, I don't think consuming pre-releases is really a solution; it's a
work-around for this particular case.

Any solution should be pulling the appropriate dependencies from source;
mimicking what tox-siblings does. This ensures the local testing is done
on the latest source regardless of what's on PYPI (a point-in-time
snapshot of the code).

I believe the same applies to [2] in your email; things aren't going to
work as expected locally until you account for pulling from source.

We can discuss this more at the PTG, but moving forward I think any
projects wanting to get the neutron-lib consumption patches (for free)
will need to make sure they have tox/zuul setup properly for both local
and gate testing.

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

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Lance Bragstad

This topic has surfaced intermittently ever since keystone implemented
fernet tokens in Kilo. An initial idea was written down shortly afterwords
[0], then we targeted it to Ocata [1], and removed from the backlog around
the Pike timeframe [2]. The commit message of [2] includes meeting links.
The discussion usually tripped attempting to abstract enough of the details
about rotation and setup of keys to work in all cases.

[0] https://review.openstack.org/#/c/311268/
[1] https://review.openstack.org/#/c/363065/
[2] https://review.openstack.org/#/c/439194/

On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles <
jaosor...@redhat.com> wrote:

> FWIW, instead of barbican, castellan could be used as a key manager.
>
> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>
>
> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>
> Is that what is being described here ?
>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>
>
> This is a separate mechanism for storing secrets, not necessarily
> passwords (although I agree the term credentials automatically makes people
> assume passwords). This is used if consuming keystone's native MFA
> implementation. For example, storing a shared secret between the user and
> keystone that is provided as a additional authentication method along with
> a username and password combination.
>
>
> Is there any interest or plans to potentially allow Keystone's credential
> store to use Barbican as a storage provider? Encryption already is better
> than nothing, but if you already have (or will be deploying) a proper
> secret store with a hardware backend (or at least hardware stored
> encryption keys) then it might make sense to throw that in Barbican.
>
> Or is this also too much of a chicken/egg problem? How safe is it to rely
> on Barbican availability for MFA secrets and auth?
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Manila] no meeting today

2018-08-30 Thread Tom Barron

I've had to travel unexpectedly, won't be able to chair the meeting 
today, and no one posted any agenda topics this week.


The rocky release is imminent so we'll open up stable/rocky for 
backports soon.


Stein specs repo is open.

Please put PTG planning ideas in the etherpad [1].  PTG is less than 
two weeks away!


-- Tom Barron (tbarron)

[1] https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018


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

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

2018-08-30 Thread Jay Pipes


On 08/30/2018 04:55 AM, Balázs Gibizer wrote:

Hi,

Based on the Nova PTG planning etherpad [1] there is a need to talk 
about the current state of the bandwidth work [2][3]. Bence (rubasov) 
has already planned to show a small demo to Neutron folks about the 
current state of the implementation. So Bence and I are wondering about 
bringing that demo close to the nova - neutron cross project session. 
That session is currently planned to happen Thursday after lunch. So we 
are think about showing the demo right before that session starts. It 
would start 30 minutes before the nova - neutron cross project session.


Are Nova folks also interested in seeing such a demo?

If you are interested in seeing the demo please drop us a line or ping 
us in IRC so we know who should we wait for.


+1 from me. I'd be very interested in seeing it.

Best,
-jay

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

Re: [openstack-dev] [neutron][python3] Neutron and stadium - python 3 community goal changes coming soon

Excerpts from Michel Peterson's message of 2018-08-30 14:38:00 +0300:
> On Thu, Aug 30, 2018 at 12:14 AM, Nate Johnston 
> wrote:
> 
> > Progress is also being tracked in a wiki page [4].
> >
> > [4] https://wiki.openstack.org/wiki/Python3
> >
> 
> That wiki page should only track teams or subteams should also be included
> there? I'm asking because it seems that some subteams appear there while
> the majority doesn't and perhaps we want to standarize that.

It would be great to include information about sub-teams. If there
are several, like in the neutron case, it probably makes sense to
create a separate section of the page with a table for all of them,
just to keep things organized.

Doug

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

Re: [openstack-dev] [neutron] tox-siblings alternative for local testing

On Wed, Aug 29, 2018 at 9:06 AM, Takashi Yamamoto 
wrote:

> is there any preferred solution for this?
> i guess the simplest solution is to make an intermediate release of neutron
> and publish it on pypi.  i wonder if it's acceptable or not.
>

There are pre releases available in PyPI [1]. You can use those from your
requirements like we did in n-odl [2].

That might be an acceptable solution.

[1] https://pypi.org/project/neutron/#history
[2] https://review.openstack.org/#/c/584791/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][python3] Neutron and stadium - python 3 community goal changes coming soon

On Thu, Aug 30, 2018 at 12:14 AM, Nate Johnston 
wrote:

> Progress is also being tracked in a wiki page [4].
>
> [4] https://wiki.openstack.org/wiki/Python3
>

That wiki page should only track teams or subteams should also be included
there? I'm asking because it seems that some subteams appear there while
the majority doesn't and perhaps we want to standarize that.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Juan Antonio Osorio Robles

FWIW, instead of barbican, castellan could be used as a key manager.


On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>
>
> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>
>> Is that what is being described here ? 
>> 
>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>
>>
>> This is a separate mechanism for storing secrets, not necessarily
>> passwords (although I agree the term credentials automatically makes
>> people assume passwords). This is used if consuming keystone's native
>> MFA implementation. For example, storing a shared secret between the
>> user and keystone that is provided as a additional authentication
>> method along with a username and password combination.
>>  
>
> Is there any interest or plans to potentially allow Keystone's
> credential store to use Barbican as a storage provider? Encryption
> already is better than nothing, but if you already have (or will be
> deploying) a proper secret store with a hardware backend (or at least
> hardware stored encryption keys) then it might make sense to throw
> that in Barbican.
>
> Or is this also too much of a chicken/egg problem? How safe is it to
> rely on Barbican availability for MFA secrets and auth?
>
>
>
> __
> OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

2018-08-30 Thread Rico Lin

Hi Glance team

Glance V1 image API been deprecated for a long while, and V2 has been used
widely. Heat image resource would like to change to use V2 as well, but
there is an unsolved issue, which blocks us from adopting V2. Right now, to
image create require Heat to download the image to Heat service and
re-upload it to Glance. This behavior causes heat service a great burden
which in a heat team discussion (years ago), we decide to deprecated V1
Image resource in Heat and will add V2  image resource once this is
resolved.
So I have been wondering if there's some workaround for this issue? Or if
glance can support accept URL as image import (and then reuse client lib
to download to glance side)? Or if anyone got a better solution for this?

-- 
May The Force of OpenStack Be With You,

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

Re: [openstack-dev] [goal][python3] week 3 update

On Thu, Aug 30, 2018 at 3:11 AM, Doug Hellmann 
wrote:

> | import zuul job settings from project-config | openstack/networking-odl
>  | https://review.openstack.org/597870 | master|
> | switch documentation job to new PTI  | openstack/networking-odl
>  | https://review.openstack.org/597871 | master|
> | add python 3.5 unit test job | openstack/networking-odl
>  | https://review.openstack.org/597872 | master|
> | add python 3.6 unit test job | openstack/networking-odl
>  | https://review.openstack.org/597873 | master|
> | import zuul job settings from project-config | openstack/networking-odl
>  | https://review.openstack.org/597911 | stable/ocata  |
> | import zuul job settings from project-config | openstack/networking-odl
>  | https://review.openstack.org/597923 | stable/pike   |
> | import zuul job settings from project-config | openstack/networking-odl
>  | https://review.openstack.org/597938 | stable/queens |
> | import zuul job settings from project-config | openstack/networking-odl
>  | https://review.openstack.org/597953 | stable/rocky  |

In the case of networking-odl I know we also need a 'fix tox python3
overrides' patch but that was not generated. I'm wondering if I should do
it manually or it will be generated at a later stage?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

On 30/08/18 6:29 AM, Lance Bragstad wrote:
>
> Is that what is being described here ? 
> 
> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>
>
> This is a separate mechanism for storing secrets, not necessarily
> passwords (although I agree the term credentials automatically makes
> people assume passwords). This is used if consuming keystone's native
> MFA implementation. For example, storing a shared secret between the
> user and keystone that is provided as a additional authentication
> method along with a username and password combination.
>  

Is there any interest or plans to potentially allow Keystone's
credential store to use Barbican as a storage provider? Encryption
already is better than nothing, but if you already have (or will be
deploying) a proper secret store with a hardware backend (or at least
hardware stored encryption keys) then it might make sense to throw that
in Barbican.

Or is this also too much of a chicken/egg problem? How safe is it to
rely on Barbican availability for MFA secrets and auth?

__
OpenStack Development Mailing 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] [neutron-fwaas] roadmap

2018-08-30 Thread Glenn VAN DE WATER

Hi,



The FWaaS V2 spec (https://specs.openstack.org/
openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html) describes quite
some changes.



Currently only some of that functionality seems to be implemented i.e.
applying firewall groups on a L2/L3 port.



Does a roadmap exist, describing when/whether other features will be
implemented as well?

Not implemented features mentioned in the spec include:

   - firewall group construct as well as a way to specify allowed sources
   and destinations in firewall rules
   - indirections through address group and service group
   - allow multiple firewall group associations for the same Neutron port



Best regards,

Glenn
__
OpenStack Development Mailing 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][nova] Small bandwidth demo on the PTG

2018-08-30 Thread Balázs Gibizer


Hi,

Based on the Nova PTG planning etherpad [1] there is a need to talk 
about the current state of the bandwidth work [2][3]. Bence (rubasov) 
has already planned to show a small demo to Neutron folks about the 
current state of the implementation. So Bence and I are wondering about 
bringing that demo close to the nova - neutron cross project session. 
That session is currently planned to happen Thursday after lunch. So we 
are think about showing the demo right before that session starts. It 
would start 30 minutes before the nova - neutron cross project session.


Are Nova folks also interested in seeing such a demo?

If you are interested in seeing the demo please drop us a line or ping 
us in IRC so we know who should we wait for.


Cheers,
gibi

[1] https://etherpad.openstack.org/p/nova-ptg-stein
[2] 
https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html
[3] 
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.html



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

Re: [openstack-dev] [Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

2018-08-30 Thread Gorka Eguileor

On 29/08, Matt Riedemann wrote:
> On 8/29/2018 3:21 PM, Tim Bell wrote:
> > Sounds like a good topic for PTG/Forum?
>
> Yeah it's already on the PTG agenda [1][2]. I started the thread because I
> wanted to get the ball rolling as early as possible, and with people that
> won't attend the PTG and/or the Forum, to weigh in on not only the known
> issues with cross-cell migration but also the things I'm not thinking about.
>
> [1] https://etherpad.openstack.org/p/nova-ptg-stein
> [2] https://etherpad.openstack.org/p/nova-ptg-stein-cells
>
> --
>
> Thanks,
>
> Matt
>

Should we also add the topic to the Thursday Cinder-Nova slot in case
there are some questions where the Cinder team can assist?

Cheers,
Gorka.

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

Re: [openstack-dev] [nova][neutron] numa aware vswitch

2018-08-30 Thread Stephen Finucane

On Thu, 2018-08-30 at 00:15 +, Guo, Ruijing wrote:
> Hi, Stephen, Sean
> 
> It worked as expected.

Good to hear. What were you missing? If there are other gaps in the
documentation, I'd be happy to fix them.

Stephen

> Thanks,
> -Ruijing
> 
> -Original Message-
> From: Stephen Finucane [mailto:sfinu...@redhat.com] 
> Sent: Monday, August 27, 2018 5:37 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [nova][neutron] numa aware vswitch
> 
> On Mon, 2018-08-27 at 10:24 +0100, Sean Mooney wrote:
> > 
> > 
> > On Mon 27 Aug 2018, 04:20 Guo, Ruijing,  wrote:
> > > Hi, Stephen,
> > > 
> > > After setting flavor, VM was created in node 0 (expect in node1). How to 
> > > debug it?
> > > 
> > > Nova.conf
> > > [neutron]
> > > physnets = physnet0,physnet1
> > > 
> > > [neutron_physnet_physnet1]
> > > numa_nodes = 1
> > 
> > Have you enabled the numa topology filter its off by default and without it 
> > the numa aware vswitch code is disabled.
> 
> Yeah, make sure this is enabled. You should turn on debug-level logging as 
> this will give you additional information about how things are being 
> scheduled. Also, is this a new deployment? If not, you're going to need to 
> upgrade and restart all the nova-* services since there are object changes 
> which will need to be propagated.
> 
> Stephen
> 
> > > openstack network create net1 --external 
> > > --provider-network-type=vlan --provider-physical-network=physnet1 
> > > --provider-segment=200 ...
> > > openstack server create --flavor 1 --image=cirros-0.3.5-x86_64-disk 
> > > --nic net-id=net1 vm1
> > > 
> > > 
> > > 1024
> > > 
> > > 
> > >   
> > > 
> > > available: 2 nodes (0-1)
> > > node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 
> > > 64412 MB node 0 free: 47658 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 
> > > 25 26 27 28 29 30 31 node 1 size: 64502 MB node 1 free: 44945 MB 
> > > node distances:
> > > node   0   1 
> > >   0:  10  21 
> > >   1:  21  10
> > > 
> > > Thanks,
> > > -Ruijing
> > > 
> > > -Original Message-
> > > From: Stephen Finucane [mailto:sfinu...@redhat.com]
> > > Sent: Saturday, August 25, 2018 12:15 AM
> > > To: OpenStack Development Mailing List (not for usage questions) 
> > > 
> > > Subject: Re: [openstack-dev] [nova][neutron] numa aware vswitch
> > > 
> > > On Fri, 2018-08-24 at 09:13 -0500, Matt Riedemann wrote:
> > > > On 8/24/2018 8:58 AM, Stephen Finucane wrote:
> > > > > Using this won't add a NUMA topology - it'll just control how 
> > > > > any topology present will be mapped to the guest. You need to 
> > > > > enable dedicated CPUs or a explicitly request a NUMA topology 
> > > > > for this to work.
> > > > > 
> > > > > openstack flavor set --property hw:numa_nodes=1 1
> > > > > 
> > > > > 
> > > > > 
> > > > > openstack flavor set --property hw:cpu_policy=dedicated 1
> > > > > 
> > > > > 
> > > > > This is perhaps something that we could change in the future, 
> > > > > though I haven't given it much thought yet.
> > > > 
> > > > Looks like the admin guide [1] should be updated to at least refer 
> > > > to the flavor user guide on setting up these types of flavors?
> > > > 
> > > > [1]
> > > > https://docs.openstack.org/nova/latest/admin/networking.html#numa-
> > > > affi
> > > > nity
> > > 
> > > Good idea.
> > > 
> > > https://review.openstack.org/596393
> > > 
> > > Stephen
> 
> 
> __
> OpenStack Development Mailing 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] [goal][python3] week 3 update