[openstack-dev] [neutron] NeutronLibImpact: Removing deprecated model_base mixins from core

[Henry Gessau]

The deprecated model_base mixins are be being removed from
neutron/db/model_base.py and neutron/db/models_v2.py in [1].
The mixins from neutron_lib.db.model_base should be used instead.

All subproject maintainers should update their code to use the model_base
mixins from neutron-lib.

I have submitted patches [2] for the stragglers that I found.

[1] https://review.openstack.org/403329
[2] https://review.openstack.org/#/q/status:open+topic:use-lib-model_base

__
OpenStack Development Mailing 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] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

[Henry Gessau]

The following _MAX_LEN constants are being removed from
neutron/api/v2/attributes.py in [1]. The corresponding DB field size
constants from neutron_lib.db.constants should be used instead.

All subproject maintainers should update their code to use the
the db *_FIELD_SIZE constants from neutron-lib.

I have submitted patches [2] for most subprojects.

 NAME_MAX_LEN  -->  NAME_FIELD_SIZE
 TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
 DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
 LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
 DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
 DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE

In alembic migration scripts, the raw numerical value shall be used.

For more information, see [3].

[1] https://review.openstack.org/399891
[2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html

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

[openstack-dev] [neutron][lbaas-v2] LBaaS v2 can't consume messages

[zhi]

Dear all,

Recently, I built up a " all-in-one " environment about LBaaS v2 by using "
haproxy " driver and the lbaas code are from master branch. And I met a
strange problem. LBaaS v2 agent can not consume messages when creating
loadbalancers in neutron server. I can see some queued messages by using
rabbitmq command, like this:

[root@server-233 ~]# rabbitmqctl list_queues messages name | grep -v ^0
Listing queues ...
25 n-lbaasv2_agent.server-233
...
...done.

What should I do? I think that LBaaS v2 agent doesn't subscribe topics in
RabbitMQ normally. In RabbitMQ, the queue " n-lbaasv2_agent.server-233 " is
created by lbaasv2 agent. And why agent can't consume messages from
neutron-server?

Could someone give me some advice to analysis this?


Many Thanks!
Zhi Chang
__
OpenStack Development Mailing 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] NeutronLibImpact: Adoption of ExtensionDescriptor from neutron-lib

[Henry Gessau]

The ExtensionDescriptor class has been rehomed to neutron-lib and is being
removed from neutron core, see [1].

All subproject maintainers should update their code to use the
ExtensionDescriptor class from neutron-lib.

I have submitted patches [2] for most subprojects.

This will be highlighted in the next Neutron team meeting [3].


[1] https://review.openstack.org/398113
[2] https://review.openstack.org/#/q/status:open+topic:ExtensionDescriptor
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
OpenStack Development Mailing 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] [Congress] Magnum_driver

[Tim Hinrichs]

Definitely push that code up into Gerrit so we can all take a look.  Data
like pods and containers is probably the most valuable data from Magnum, so
I'd definitely recommend adding that.  But push the code you have to Gerrit
first.  (As long as you leave the ChangeId the same each time you push to
Gerrit, Gerrit will keep all of the versions you pushed organized together,
yet keep the versions separate.)

Tim

On Fri, Nov 25, 2016 at 3:06 PM Ruben 
wrote:

> Hi Tim,
> You are great. It works! Thanks a lot!
> I've also solved the problem with py27. The unit test seems to work.
> The only thing that seems not to work is populate the 'clusters_links' and
> 'cluster_templates_links' tables: they are empty.
> Also, the 'labels' table is empty.
> I've no errors anyway.
> Are these problems according to you?
>
> Should I to try to add the translation of pods, containers and services?
>
> I've add the code to review.
>
> Ruben
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Friday, November 25, 2016 10:36:29 PM
> Subject: Re: [Congress] Magnum_driver
>
> Hi Ruben,
>
> Glad you got that worked out.  Once in a while I end up deleting my .tox
> dir because it gets out of date.  I guess that's what the --recreate option
> to tox does.  So I learned something.  :)
>
> The new error message looks to be saying that an object of type 'Cluster'
> cannot be iterated.  Congress's _translate_clusters method assumes that
> what you give it is basically JSON (arrays, dictionaries, numbers, strings,
> bools).   In this case Congress is trying to iterate over the keys of a
> dictionary but is getting a 'Cluster' Python object instead.  What's
> happening is that when you do the cluster.list() (or whatever it's called)
> on the magnum-python you're getting back a list of Cluster Python objects
> instead of a list of dictionaries.
>
> To fix the problem, you'll want to take the results of cluster.list() and
> translate it into a list of dictionaries, and then hand that off to
> _translate_clusters.  Probably you'll need to do the same for the
> cluster_template.  So instead of ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': self.magnum.clusters.list()})
>
> You'll want to do something like ...
>
> clusters_method = lambda: self._translate_clusters(
> {'clusters': [x.__dict__ for x in self.magnum.clusters.list()]
>  })
>
> Or at least, that's what I'd start trying.  __dict__ grabs all the fields
> of an object and returns a dictionary.  (If some of the values of that
> dictionary are also Python objects, then you might need something that's
> more complicated to recursively walk the result of clusters.list() and
> translate everything into lists and dictionaries.  And I'm not sure that
> __dict__ will give you exactly what you want, but it's worth a try.).
>
> Tim
>
>
> On Thu, Nov 24, 2016 at 12:11 PM Ruben 
> wrote:
>
> > Hi Tim,
> > I solved the problem with:
> >
> > tox --recreate -e py27
> >
> > Now I no have the error on the import. The unit test still has some
> > errors, but I don't know why..
> >
> > Anyway, I've this error when I try to add the magnum_driver:
> >
> > 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> > magnum:: polling
> > 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-]
> > update table clusters. from (pid=18720) update_from_datasource
> > /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> > 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> > CLUSTERS: {'clusters': [ > u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b', u'uuid':
> > u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> > http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'self'}, {u'href': u'
> > http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> > u'rel': u'bookmark'}], u'stack_id':
> > u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1, u'keypair':
> > u'testkey', u'node_count': 1, u'create_timeout': 60, u'name':
> > u'k8s-cluster'}>]} from (pid=18720) _translate_clusters
> > /opt/stack/congress/congress/datasources/magnum_driver.py:165
> > 2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-]
> > Datasource driver raised exception
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> > Traceback (most recent call last):
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  File "/opt/stack/congress/congress/datasources/datasource_driver.py",
> line
> > 1384, in poll
> > 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> >  self.update_from_datasource()  # sets self.state
> 

Re: [openstack-dev] [keytone] Pike PTL

[Marek Denis]

Steve,

You've done amazing job. Thanks for that and making keystone even better!
Marek Denis
​
__
OpenStack Development Mailing 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] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

[Ihar Hrachyshka]

Hi all,

I am looking at 
http://stackalytics.com/?project_type=openstack=neutron-group and I see 
some reviews counted for projects that are for long out of neutron stadium 
(f.e. dragonflow or kuryr or networking-hyperv). How can we get them excluded 
from the official neutron stats?

I’ve briefly looked at the code, and it seems like the project should reflect 
what’s defined in governance repo, but apparently it’s not the case. So what 
does it reflect?

Ihar
__
OpenStack Development Mailing 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] [Congress] Magnum_driver

[Ruben]

Hi Tim,
You are great. It works! Thanks a lot!
I've also solved the problem with py27. The unit test seems to work.
The only thing that seems not to work is populate the 'clusters_links' and 
'cluster_templates_links' tables: they are empty.
Also, the 'labels' table is empty.
I've no errors anyway.
Are these problems according to you?

Should I to try to add the translation of pods, containers and services?

I've add the code to review.

Ruben
- Original Message -
From: "Tim Hinrichs" 
To: "Ruben" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Sent: Friday, November 25, 2016 10:36:29 PM
Subject: Re: [Congress] Magnum_driver

Hi Ruben,

Glad you got that worked out.  Once in a while I end up deleting my .tox
dir because it gets out of date.  I guess that's what the --recreate option
to tox does.  So I learned something.  :)

The new error message looks to be saying that an object of type 'Cluster'
cannot be iterated.  Congress's _translate_clusters method assumes that
what you give it is basically JSON (arrays, dictionaries, numbers, strings,
bools).   In this case Congress is trying to iterate over the keys of a
dictionary but is getting a 'Cluster' Python object instead.  What's
happening is that when you do the cluster.list() (or whatever it's called)
on the magnum-python you're getting back a list of Cluster Python objects
instead of a list of dictionaries.

To fix the problem, you'll want to take the results of cluster.list() and
translate it into a list of dictionaries, and then hand that off to
_translate_clusters.  Probably you'll need to do the same for the
cluster_template.  So instead of ...

clusters_method = lambda: self._translate_clusters(
{'clusters': self.magnum.clusters.list()})

You'll want to do something like ...

clusters_method = lambda: self._translate_clusters(
{'clusters': [x.__dict__ for x in self.magnum.clusters.list()]
 })

Or at least, that's what I'd start trying.  __dict__ grabs all the fields
of an object and returns a dictionary.  (If some of the values of that
dictionary are also Python objects, then you might need something that's
more complicated to recursively walk the result of clusters.list() and
translate everything into lists and dictionaries.  And I'm not sure that
__dict__ will give you exactly what you want, but it's worth a try.).

Tim


On Thu, Nov 24, 2016 at 12:11 PM Ruben 
wrote:

> Hi Tim,
> I solved the problem with:
>
> tox --recreate -e py27
>
> Now I no have the error on the import. The unit test still has some
> errors, but I don't know why..
>
> Anyway, I've this error when I try to add the magnum_driver:
>
> 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> magnum:: polling
> 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-]
> update table clusters. from (pid=18720) update_from_datasource
> /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> CLUSTERS: {'clusters': [ u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b', u'uuid':
> u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> u'rel': u'self'}, {u'href': u'
> http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> u'rel': u'bookmark'}], u'stack_id':
> u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1, u'keypair':
> u'testkey', u'node_count': 1, u'create_timeout': 60, u'name':
> u'k8s-cluster'}>]} from (pid=18720) _translate_clusters
> /opt/stack/congress/congress/datasources/magnum_driver.py:165
> 2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-]
> Datasource driver raised exception
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> Traceback (most recent call last):
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1384, in poll
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  self.update_from_datasource()  # sets self.state
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1371, in update_from_datasource
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  self.update_methods[registered_table]()
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/magnum_driver.py", line
> 150, in 
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  {'clusters': self.magnum.clusters.list()})
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File 

Re: [openstack-dev] [infra][neutron] Intel NFV CI voting permission in Neutron

[Ihar Hrachyshka]

> On 14 Nov 2016, at 11:44, Znoinski, Waldemar  
> wrote:
> 
> Hi Neutron, Infra Cores et al,
> I would like to acquire voting (+/-1 Verified) permission for our Intel NFV 
> CI.
>  
> 1. It's running on Neutron changes since Q1'2015.
> 2. Wiki [1].
> 3. It's using openstack-infra/puppet-openstackci [2] with Zuul 2.1.1 for last 
> 8 months: zuul, gearman, Jenkins, nodepool, local Openstack cloud with VMs 
> and baremetal servers (where needed).
> 4. We have a team of 2 people + me + Nagios looking after it. Its problems 
> are fixed promptly and rechecks triggered after non-code related issues. It's 
> being reconciled against ci-watch [3] and gerrit using [4].
> 5. It has a good record of testing for Nova, also voting for last 4 months 
> [5].
>  
> [1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI
> [2] https://github.com/openstack-infra/puppet-openstackci
> [3] http://ci-watch.tintri.com/project?project=neutron
> [4] https://review.openstack.org/#/c/382262/
> [5] 
> https://review.openstack.org/#/q/reviewer:%22Intel+NFV-CI+%253Copenstack-nfv-ci%2540intel.com%253E%22
>  

This CI just -1d a patch that I don’t believe may break NFV: 
https://review.openstack.org/#/c/308005/

Looking into logs, it seems like job took too much time, so it timed out. It’s 
hard to tell why it happens, partly because console.html doesn’t give proper 
timestamps. Per test times don’t look suspicious. BTW are tests executed with a 
single test runner? (I see only {0} runner in the console output).

Ihar
__
OpenStack Development Mailing 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] [Congress] Magnum_driver

[Tim Hinrichs]

Hi Ruben,

Glad you got that worked out.  Once in a while I end up deleting my .tox
dir because it gets out of date.  I guess that's what the --recreate option
to tox does.  So I learned something.  :)

The new error message looks to be saying that an object of type 'Cluster'
cannot be iterated.  Congress's _translate_clusters method assumes that
what you give it is basically JSON (arrays, dictionaries, numbers, strings,
bools).   In this case Congress is trying to iterate over the keys of a
dictionary but is getting a 'Cluster' Python object instead.  What's
happening is that when you do the cluster.list() (or whatever it's called)
on the magnum-python you're getting back a list of Cluster Python objects
instead of a list of dictionaries.

To fix the problem, you'll want to take the results of cluster.list() and
translate it into a list of dictionaries, and then hand that off to
_translate_clusters.  Probably you'll need to do the same for the
cluster_template.  So instead of ...

clusters_method = lambda: self._translate_clusters(
{'clusters': self.magnum.clusters.list()})

You'll want to do something like ...

clusters_method = lambda: self._translate_clusters(
{'clusters': [x.__dict__ for x in self.magnum.clusters.list()]
 })

Or at least, that's what I'd start trying.  __dict__ grabs all the fields
of an object and returns a dictionary.  (If some of the values of that
dictionary are also Python objects, then you might need something that's
more complicated to recursively walk the result of clusters.list() and
translate everything into lists and dictionaries.  And I'm not sure that
__dict__ will give you exactly what you want, but it's worth a try.).

Tim


On Thu, Nov 24, 2016 at 12:11 PM Ruben 
wrote:

> Hi Tim,
> I solved the problem with:
>
> tox --recreate -e py27
>
> Now I no have the error on the import. The unit test still has some
> errors, but I don't know why..
>
> Anyway, I've this error when I try to add the magnum_driver:
>
> 2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-]
> magnum:: polling
> 2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-]
> update table clusters. from (pid=18720) update_from_datasource
> /opt/stack/congress/congress/datasources/datasource_driver.py:1370
> 2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-]
> CLUSTERS: {'clusters': [ u'cluster_template_id': u'8d25a1ed-faa6-4305-a6a1-6559708c805b', u'uuid':
> u'1634beb9-25de-4cdd-bafa-67537069f0cc', u'links': [{u'href': u'
> http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> u'rel': u'self'}, {u'href': u'
> http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc',
> u'rel': u'bookmark'}], u'stack_id':
> u'17f1248d-286a-4fd4-9639-af5773670f03', u'master_count': 1, u'keypair':
> u'testkey', u'node_count': 1, u'create_timeout': 60, u'name':
> u'k8s-cluster'}>]} from (pid=18720) _translate_clusters
> /opt/stack/congress/congress/datasources/magnum_driver.py:165
> 2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-]
> Datasource driver raised exception
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
> Traceback (most recent call last):
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1384, in poll
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  self.update_from_datasource()  # sets self.state
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1371, in update_from_datasource
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  self.update_methods[registered_table]()
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/magnum_driver.py", line
> 150, in 
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  {'clusters': self.magnum.clusters.list()})
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_utils.py", line
> 57, in inner
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  result = f(self, raw_data, *args, **kw)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/magnum_driver.py", line
> 167, in _translate_clusters
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  obj['clusters'], MagnumDriver.clusters_translator)
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  File "/opt/stack/congress/congress/datasources/datasource_driver.py", line
> 1048, in convert_objs
> 2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver
>  rows, _ = 

[openstack-dev] [neutron] NeutronLibImpact: Removal of PLURALS

[Henry Gessau]

The PLURALS dict in neutron.api.v2.attributes is written to but never used.
Before rehoming neutron.api.v2.attributes to neutron-lib I am removing all
references to PLURALS [1].

All subproject maintainers should remove the use of PLURALS from their code.
I have submitted patches [2] for most subprojects.

This will be highlighted in the next Neutron team meeting [3].


[1] https://review.openstack.org/398489
[2] https://review.openstack.org/#/q/status:open+topic:remove-PLURALS
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
OpenStack Development Mailing 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] [telemetry] PostgreSQL gate broken

[Sylvain Bauza]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Le 25/11/2016 18:24, Sylvain Bauza a écrit :
> 
> 
> Le 24/11/2016 13:58, Sylvain Bauza a écrit :
> 
> 
>> Le 24/11/2016 11:57, Julien Danjou a écrit :
>>> Hi,
> 
>>> It seems Nova broke its PostgreSQL support recently, and that 
>>> impacts Telemetry as we do gate on PostgreSQL. I opened a bug:
> 
>>> https://bugs.launchpad.net/nova/+bug/1644513
> 
>>> Could somebody from Nova indicates if this is something you 
>>> want to fix quickly or if we should just stop caring about 
>>> Nova+PostgreSQL in our integration test gate?
> 
> 
> 
>> Good question. Since today is Thanksgiving for US folks, it could
>> be a bit more difficult for find the RCA and fix it but we can
>> still try.
> 
>> For the moment, trying to understand when the regression happened
>> and with which merged change, so we could see if we could just
>> revert it.
> 
> 
> 
> As some of you could see with the bug report, we have a possible 
> solution https://review.openstack.org/#/c/403035/
> 
> A Depends-On is provided for the Ceilometer gate, let's see if that
> fixes the problem.


I made a stupid mistake when writing the Depends-On tag so it was
gating against something invalid hence not getting the right fix, but
I just modified the commit msg so that would hopefully work.

I need to step down for a bit while the CI is testing that, but if
Nova core folks are around and can see if
https://review.openstack.org/#/c/403101/ goes green, I would surely
appreciate some +2 on https://review.openstack.org/#/c/403035/

- -Sylvain




> 
> -Sylvain
> 
>> -Sylvain
> 
> 
>>> Thanks!
> 
>>> Cheers,
> 
> 
> 
>>> 
_
>
>>>
>>> 
_
> 
>>> 
> 
> 
> 
>> OpenStack Development Mailing 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYOIGhAAoJEO+lyg5yIElqkqIIANsBzyLEsrCB2Nqces/IEuVY
DZQq5NH28LPCXPsyWM6mBEftfosMJLuj+gtbV9MGL7M6yj7v4ocZmjvtt0ASqOzh
aSx8+DMkKCsl04ZBc2ml3dBEHWsdR7uboyX5WWwXuu/VcS63yUoTRNobbeLMCeJ5
Eyon5LC+3dJjsB3X7ZmikxJQH0b7AFNtfFWdd4N/N1abC64KoDhWekK2vT0e0Tp1
17JZxtQZtqgKAqPK7unYUQC7fIiXsxq3U9o8gta/wvj6jtxAuwsc8bmt+HlKyAVE
Qv6v08SUACzkW7Hn47pg2ewbDDMfboxP0ACyzPKdobaCWQ04tT+XF8d0XeKO+1Y=
=F142
-END 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][tc] Exposing project team's metadata in README files

[Zara Zaimeche]

On 25/11/16 17:51, Jeremy Stanley wrote:

On 2016-11-25 17:41:07 + (+), Miles Gould wrote:

I don't think this is an insurmountable problem: it should be possible to
allow users to switch between "code view" and "rendered view" for file-types
that support rendering.


Yes, it's "just" a matter of writing some code (and convincing cgit
upstream to support it). However, we already have automation to
continuously deploy rendered readme files and any other
documentation you want to write on docs.openstack.org or
readthedocs.org. Why would having a rendered readme at
http://git.openstack.org/cgit/openstack-infra/bindep/tree/README.rst
be a better user experience than
http://docs.openstack.org/infra/bindep/readme.html ?


Hi,

To add some detail, if you wanted to patch cgit, I believe you would 
need to extend the filter API, to include something between about-filter 
(https://git.zx2c4.com/cgit/tree/cgitrc.5.txt#n666 ; this renders a 
specific file differently in the 'about' tab of the repo) and 
source-filter (https://git.zx2c4.com/cgit/tree/cgitrc.5.txt#n690 ; this 
renders all source code with a particular extension, in-place ), and 
then patch the specific cgit instance config to use the new filter. I 
don't know whether cgit upstream would be receptive to this change, and 
I think OpenStack's existing infrastructure for documentation means 
there's little gain from doing it.


Best Wishes,

Zara

__
OpenStack Development Mailing 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] TripleO Squads - What's next?

[Emilien Macchi]

I'm happy to announce we officially accepted TripleO Squads in our project:
http://specs.openstack.org/openstack/tripleo-specs/specs/policy/squads.html

We hope it will help us to scale our team and improve our way to work together.

The next steps... I started a new etherpad:
https://etherpad.openstack.org/p/tripleo-squads
We'll use it to start building our squads.

Actions to take now:

- If you are a TripleO regular contributor (ie contributing to TripleO
is part of your daily work), please add your name in the squads.
- Feel free to adjust the name of the squads, add more squads if
something is missing. Also, feel free to improve the description, give
more thoughts about the work done in the squad, etc. This etherpad
will only be built by the team!
- For each squad, we need to find a mission statement, that defines
the scope of work being done.
- For each squad, we need to find a liaison. The liaison will act as a
squad lead and PTL will collaborate with liaison first when dealing
with some work related to the squad. If you volunteer, please put your
name.

This new squad thing is really new for us, please keep giving feedback
and propose new ideas,
Thanks!
-- 
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] [all][tc] Exposing project team's metadata in README files

[Jeremy Stanley]

On 2016-11-25 17:41:07 + (+), Miles Gould wrote:
> I don't think this is an insurmountable problem: it should be possible to
> allow users to switch between "code view" and "rendered view" for file-types
> that support rendering.

Yes, it's "just" a matter of writing some code (and convincing cgit
upstream to support it). However, we already have automation to
continuously deploy rendered readme files and any other
documentation you want to write on docs.openstack.org or
readthedocs.org. Why would having a rendered readme at
http://git.openstack.org/cgit/openstack-infra/bindep/tree/README.rst
be a better user experience than
http://docs.openstack.org/infra/bindep/readme.html ?
-- 
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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Miles Gould]

On 25/11/16 17:12, Jeremy Stanley wrote:


It came down less to safety and more to the fact that if you force
cgit to present rendered content then you lose the ability to
reference the source code for the same files.


I don't think this is an insurmountable problem: it should be possible 
to allow users to switch between "code view" and "rendered view" for 
file-types that support rendering.


Miles

__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 09:15 -0800, Christopher Aedo wrote:

On Fri, Nov 25, 2016 at 3:38 AM, Flavio Percoco  wrote:

Greetings,

Just a heads up for everyone. The work on this front has moved forward and
the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite obvious,
the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the
projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of "viral
changes" but I've done my best to explain what's changing, provide
references
and examples on the commit message. These changes are being submitted using
the
tag 'project-badges'[2].

Note that these badges are *JUST* a graphical representation of what's in
the
governance repo. If you don't want to have them in the README file, I guess
it's
fine. I'd, however, encourage everyone to add them to provide consistency
and a
more immediate information of what the project is about, what some of the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well but I'll
leave that to every team to do.


Thanks for doing the work to get this automated Flavio!  As a few
others have noted, I did not like the placement at the very top but I
understand it's not reasonably possible to automate this in a way that
find the idea insertion point.  For me at any rate, I've moved them
down to just under the first paragraph explaining the project.


This sounds perfect, thanks for doing that :)


One other important thing that's missing however is the :alt: tag
underneath the image.  For accessibility purposes (and considering
this is all automated anyway) I don't think these badges should be
merged without text describing the image.


Gosh, I thought I had added the :alt: tag. FWIW, I did remember this, freudian
slip, I guess.

Flavio


-Christopher


Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better ideas
please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/


On 12/10/16 14:50 +0200, Flavio Percoco wrote:


Greetings,

One of the common complains about the existing project organization in the
big
tent is that it's difficult to wrap our heads around the many projects
there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page
is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing
the
many repos (most likely on github), I'd like to propose that we include
the
information of each deliverable in the readme file. This information would
be
rendered along with the rest of the readme (at least on Github, which
might not
be our main repo but it's the place most humans go to to check our
projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge
goes, I
believe it'd be quite simple. We can do it the same way CI tags are
exposed when
using travis (just include an image). As for the rest of the tags, it
might
require some extra hacking.

So, before I start digging more into this, I wanted to get other
opinions/ideas
on this topic and how we can make this information more evident to the
rest of
the community (and people not as familiar with our processes as some of us
are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco





--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing 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


--
@flaper87
Flavio Percoco


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] [nova] [telemetry] PostgreSQL gate broken

[Sylvain Bauza]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Le 24/11/2016 13:58, Sylvain Bauza a écrit :
> 
> 
> Le 24/11/2016 11:57, Julien Danjou a écrit :
>> Hi,
> 
>> It seems Nova broke its PostgreSQL support recently, and that 
>> impacts Telemetry as we do gate on PostgreSQL. I opened a bug:
> 
>> https://bugs.launchpad.net/nova/+bug/1644513
> 
>> Could somebody from Nova indicates if this is something you want
>> to fix quickly or if we should just stop caring about
>> Nova+PostgreSQL in our integration test gate?
> 
> 
> 
> Good question. Since today is Thanksgiving for US folks, it could
> be a bit more difficult for find the RCA and fix it but we can
> still try.
> 
> For the moment, trying to understand when the regression happened
> and with which merged change, so we could see if we could just
> revert it.
> 


As some of you could see with the bug report, we have a possible
solution https://review.openstack.org/#/c/403035/

A Depends-On is provided for the Ceilometer gate, let's see if that
fixes the problem.

- -Sylvain

> -Sylvain
> 
> 
>> Thanks!
> 
>> Cheers,
> 
> 
> 
>> _
_
>
>> 

> 
> 
> OpenStack Development Mailing 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYOHPIAAoJEO+lyg5yIElq3OwIAKpKKiLl5C7hHYsqfbWFwZLK
PM+BVO7tY2dSiZ/c+yNpVU+oQ8EKU8lVzxemwBmTbyRvBd3wRCD13J0Bu88ypEfh
7mbNHT8yGEyYzPBXriEOD8KfTK+5leb203OxluPH1qnBcx+8S4if8RVdv3R683uN
nqjmucwalM8fbarsnlhfz9w7JquzVcg8w7SVkTThoWOqvliEg0xX80XVwJdBiLCn
8M6gZaLQsvi0KBFUWmpgle3BP0GBOqtPA8UY7rwBFRc0Pnw+CgZ78bGc914l8lk5
AGgXQ1d3SOSI2KrhqG6s6NdeM+v+1ZdwhfIYYpkOHd9zKiTR2NYQgpnu7hDRlxQ=
=7aNb
-END 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] amend reference/PTI (governance) with supported distros

[Emilien Macchi]

Hi,

I recently found out that some projects in OpenStack do not gate on
CentOS platform, while it's one of the most popular disto used to
deploy OpenStack in production, after Ubuntu.
I've decided to start a discussion and see if we would agree to
officially make the statement that we support Ubuntu and CentOS and we
commit to test these distros in project gates, like it's already the
case for a lot of projects.

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

Feel free to give any feedback,
Thanks!
-- 
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] [all][tc] Exposing project team's metadata in README files

[Christopher Aedo]

On Fri, Nov 25, 2016 at 3:38 AM, Flavio Percoco  wrote:
> Greetings,
>
> Just a heads up for everyone. The work on this front has moved forward and
> the
> badges are now being generated as part of the governance CI[0].
>
> You can find the list of badges here[1] and the pattern is quite obvious,
> the
> name of the image is based on the project repo name.
>
> I've edited the README files for all repositories listed in the
> projects.yaml
> file and I've started to submit these patches[2]. I'm not a fan of "viral
> changes" but I've done my best to explain what's changing, provide
> references
> and examples on the commit message. These changes are being submitted using
> the
> tag 'project-badges'[2].
>
> Note that these badges are *JUST* a graphical representation of what's in
> the
> governance repo. If you don't want to have them in the README file, I guess
> it's
> fine. I'd, however, encourage everyone to add them to provide consistency
> and a
> more immediate information of what the project is about, what some of the
> project capabilities are and what its status is.
>
> Ideally this should also be added in projects documentation as well but I'll
> leave that to every team to do.

Thanks for doing the work to get this automated Flavio!  As a few
others have noted, I did not like the placement at the very top but I
understand it's not reasonably possible to automate this in a way that
find the idea insertion point.  For me at any rate, I've moved them
down to just under the first paragraph explaining the project.

One other important thing that's missing however is the :alt: tag
underneath the image.  For accessibility purposes (and considering
this is all automated anyway) I don't think these badges should be
merged without text describing the image.

-Christopher

> Happy to answer questions,
> Flavio
>
> P.S: The current layout is being improved[3], if you have better ideas
> please
> help out.
>
> [0] https://review.openstack.org/#/c/391588/
> [1] http://governance.openstack.org/badges/
> [2] https://review.openstack.org/#/q/topic:project-badges
> [3] https://review.openstack.org/#/c/399278/
>
>
> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>>
>> Greetings,
>>
>> One of the common complains about the existing project organization in the
>> big
>> tent is that it's difficult to wrap our heads around the many projects
>> there
>> are, their current state (in/out the big tent), their tags, etc.
>>
>> This information is available on the governance website[0]. Each official
>> project team has a page there containing the information related to the
>> deliverables managed by that team. Unfortunately, I don't think this page
>> is
>> checked often enough and I believe it's not known by everyone.
>>
>> In the hope that we can make this information clearer to people browsing
>> the
>> many repos (most likely on github), I'd like to propose that we include
>> the
>> information of each deliverable in the readme file. This information would
>> be
>> rendered along with the rest of the readme (at least on Github, which
>> might not
>> be our main repo but it's the place most humans go to to check our
>> projects).
>>
>> Rather than duplicating this information, I'd like to find a way to just
>> "include it" in the Readme file. As far as showing the "official" badge
>> goes, I
>> believe it'd be quite simple. We can do it the same way CI tags are
>> exposed when
>> using travis (just include an image). As for the rest of the tags, it
>> might
>> require some extra hacking.
>>
>> So, before I start digging more into this, I wanted to get other
>> opinions/ideas
>> on this topic and how we can make this information more evident to the
>> rest of
>> the community (and people not as familiar with our processes as some of us
>> are).
>>
>> Thanks in advance,
>> Flavio
>>
>> [0] http://governance.openstack.org/reference/projects/index.html
>>
>> --
>> @flaper87
>> Flavio Percoco
>
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Jeremy Stanley]

On 2016-11-25 11:37:02 -0500 (-0500), Paul Belanger wrote:
[...]
> We do have an abandoned path in gerrit to support this[3], but
> infra decided to abandon it since it wasn't very safe. So, it is
> possible to render markdown in cgit, we just need to confirm how
> safe it is today.
[...]

It came down less to safety and more to the fact that if you force
cgit to present rendered content then you lose the ability to
reference the source code for the same files.

Ultimately we decided we have a place to display rendered documents
already (docs.openstack.org), and so should leave the source code
browser configured for what it does best: browsing source code.
-- 
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

Re: [openstack-dev] [nova] [telemetry] PostgreSQL gate broken

[John Garbutt]

On 24 November 2016 at 13:52, Chris Friesen  wrote:
> On 11/24/2016 05:57 AM, Julien Danjou wrote:
>>
>> Hi,
>>
>> It seems Nova broke its PostgreSQL support recently, and that impacts
>> Telemetry as we do gate on PostgreSQL. I opened a bug:
>>
>>https://bugs.launchpad.net/nova/+bug/1644513
>>
>> Could somebody from Nova indicates if this is something you want to fix
>> quickly or if we should just stop caring about Nova+PostgreSQL in our
>> integration test gate?
>
>
> As someone using Nova+PostgreSQL in production, I sure hope that we don't
> stop caring about it!

So Nova did stop gating on PostgreSQL a little while back:
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101892.html

We probably need help to turn that back on, but will need help tidying
that job up I believe. Any takers to look into tidying that job up,
and getting it non-voting on the check queue?

Thanks,
John

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

Re: [openstack-dev] [new][nimble] New project: Nimble

[Sean McGinnis]

On Fri, Nov 25, 2016 at 05:41:28PM +0800, Zhenguo Niu wrote:
> hi all,
> 
> We are pleased to introduce Nimble, a new OpenStack project which aims to
> provide bare metal computing management.

Has this name been cleared for use? Nimble is the name of a company, so
like Quantum, this seems to me to be a short lived name.

__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Paul Belanger]

On Thu, Oct 13, 2016 at 01:06:43PM +0200, Flavio Percoco wrote:
> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> > Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> > > Greetings,
> > > 
> > > One of the common complains about the existing project organization in 
> > > the big
> > > tent is that it's difficult to wrap our heads around the many projects 
> > > there
> > > are, their current state (in/out the big tent), their tags, etc.
> > > 
> > > This information is available on the governance website[0]. Each official
> > > project team has a page there containing the information related to the
> > > deliverables managed by that team. Unfortunately, I don't think this page 
> > > is
> > > checked often enough and I believe it's not known by everyone.
> > > 
> > > In the hope that we can make this information clearer to people browsing 
> > > the
> > > many repos (most likely on github), I'd like to propose that we include 
> > > the
> > > information of each deliverable in the readme file. This information 
> > > would be
> > > rendered along with the rest of the readme (at least on Github, which 
> > > might not
> > > be our main repo but it's the place most humans go to to check our 
> > > projects).
> > > 
> > > Rather than duplicating this information, I'd like to find a way to just
> > > "include it" in the Readme file. As far as showing the "official" badge 
> > > goes, I
> > > believe it'd be quite simple. We can do it the same way CI tags are 
> > > exposed when
> > > using travis (just include an image). As for the rest of the tags, it 
> > > might
> > > require some extra hacking.
> > > 
> > > So, before I start digging more into this, I wanted to get other 
> > > opinions/ideas
> > > on this topic and how we can make this information more evident to the 
> > > rest of
> > > the community (and people not as familiar with our processes as some of 
> > > us are).
> > > 
> > > Thanks in advance,
> > > Flavio
> > > 
> > > [0] http://governance.openstack.org/reference/projects/index.html
> > > 
> > 
> > Is your proposal that a tag like release:cycle-with-milestones would
> > result in a badge being added when the README.rst is rendered on
> > github.com? Would that work for git.openstack.org, too?
> 
> I don't think it'd work for git.openstack.org because it doesn't render the
> README's[0] like github does. One thing I'd like to avoid is for this
> information to result in new changes to the README file everytime the tags are
> updated because I'd like for this information to not be duplicated and to make
> it clear that this information is not meant to be updated manually.
> 
We do have an abandoned path in gerrit to support this[3], but infra decided to
abandon it since it wasn't very safe. So, it is possible to render markdown in
cgit, we just need to confirm how safe it is today.

[3] https://review.openstack.org/#/c/60375/

> Here's[1] an example of what it would look like (or kinda).
> 
> [0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
> [1] https://github.com/celery/kombu/blob/master/README.rst
> 
> 
> > I agree that the governance site is not the best place to put the
> > info to make it discoverable. Do users look first at the source
> > repository, or at some other documentation?
> 
> The feedback* I've gotten is that users normally look at repos first and they 
> go
> from there to docs (which are normally linked in the README file).
> 
> * Neither based on a survey nor on any empirical research. This is based on
>  hallway talks.
> 
> Flavio
> 
> -- 
> @flaper87
> Flavio Percoco



> __
> OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 14:35 +, Amrith Kumar wrote:

Thanks Flavio,

I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I
assume that other projects which want to do this kind of manual cleanup can
either use this bug or create their own.


Thanks Amrith, I think this is the right approach for teams that prefer to
modify the README further. Do you intend to land the patches as they are and
modify the README with follow-up patches? or are you going to wait for the
patches to be updated? I would advise for the former but I'm biased :D

Also, https://review.openstack.org/#/c/399278/ landed. I'll be improving the
layout a bit better based on the feedback from your email.

Thanks,
Flavio


-amrith


-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Friday, November 25, 2016 9:00 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
README files

On 25/11/16 13:46 +, Amrith Kumar wrote:
>Flavio,
>
>I see a number of patches[1] which have been landed on this project but
>I find that at least the ones that were landed for Trove, and a random
>sampling of the others all to be different from what you proposed
>below[2] in one important aspect.
>
>In [2] you proposed a structure where the title of the document; or the
>first, and most prominent heading, would be the existing heading of the
>document, and the tags would be below that. In [2] for example, that was:
>
>"kombu - Messaging library for Python"
>
>and the tags would be in smaller font below that.

Hey Amrith,

One reason it's different from Kombu is because Kombu uses shields as a
backend for this SVGs, whereas we don't. We generate the badges
ourselves[0], which probably ended up in some differences.

The other main difference in the kombu case, there are multiple images in
the README, wherease in our case there's one SVG containing multiple svgs.
The motivation behind this is being able to update the badges without
sending patches to projects everytime the governance repo is modified.

This layout and format can of couse be modified, the font size and family
can
be changed, etc. See[1].

>What I see in [3] the patch for Trove and the proposed example [4] is:
>
>"Team and repository tags" as the first, and most conspicuous header,
>and the header "Trove" below that.
>
>In some cases the second header is the same font as the "Team and
>repository tags" header.

I explained this a bit here[2]. The reason for prepending these secion to
the
README's instead of finding a good place in it is that READMEs throughout
OpenStack are quite different from each other and putting this at the top
helped in making the process of adding the badges simpler.

>I think this change (these 124 changes) as proposed are not consistent
>with the proposal you made below, and certainly seem to be less
>suitable than that proposal. The end product for the four trove
>repositories [4], [5], [6], and [7]
>
>I think we should have a discussion on the ML whether we feel that this
>new structure is the appropriate one, and before some projects approve
>these changes and others don't that these be all marked WF-1.

I honestly don't think the current proposal is bad, it's different from
Kombu
for the reasons I mentioned above but it can be improved. Not that
improving the badges and their layout doesn't require submitting these
patches again. It'll be enough to modify the governance repo that generates
these images.

Hope this helps,
Flavio


[0]
http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts
/badges.py
[1] https://review.openstack.org/#/c/399278/
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-
November/107969.html

>Thanks,
>
>-amrith
>
>[1] https://review.openstack.org/#/q/topic:project-badges
>[2] https://github.com/celery/kombu/blob/master/README.rst
>[3] https://review.openstack.org/#/c/402547/
>[4]
https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
>[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
>[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
>[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
>
>
>
>
>> -Original Message-
>> From: Flavio Percoco [mailto:fla...@redhat.com]
>> Sent: Thursday, October 13, 2016 7:07 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [all][tc] Exposing project team's
>> metadata in README files
>>
>> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> >> Greetings,
>> >>
>> >> One of the common complains about the existing project
>> >> organization in the big tent is that it's difficult to wrap our
>> >> heads around the many projects there are, their current state
>> >> (in/out the big tent), their
>> tags, etc.
>> >>
>> >> 

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 23:49 +0900, Ian Y. Choi wrote:

Hello Flavio,

I have two questions on this thread:

1) I have just written my review on training-guides repository
: https://review.openstack.org/#/c/402607/1 .
Then would you revise your initialized patchset by yourself? Or Your 
intention
would be to discuss more on each repository team members and revise 
patch(es) by themselves?


Each team is free to modify the patch as they want but I'd prefer there to be
consistency across README files. Putting it at the top was simply more
convinient for me doing the job and I also believe it's better for people that
land on the README.

By all means, feel free to modify it if you think it's not ok to have it there.

2) Can I18n team (openstack/i18n and openstack/i18n-specs) have such 
image tag? :)


Yes, these are coming :D

Thanks for reviewing and reaching out,
Flavio

P.S: The commit message b and \n was just me being bitten by python 3.5. I fixed
that for other commits but it's harmless to have it in yours. :D



With many thanks,

/Ian

Flavio Percoco wrote on 11/25/2016 11:00 PM:

On 25/11/16 13:46 +, Amrith Kumar wrote:

Flavio,

I see a number of patches[1] which have been landed on this 
project but I find
that at least the ones that were landed for Trove, and a random 
sampling of

the others all to be different from what you proposed below[2] in one
important aspect.

In [2] you proposed a structure where the title of the document; 
or the first,
and most prominent heading, would be the existing heading of the 
document, and

the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.


Hey Amrith,

One reason it's different from Kombu is because Kombu uses shields 
as a backend
for this SVGs, whereas we don't. We generate the badges 
ourselves[0], which

probably ended up in some differences.

The other main difference in the kombu case, there are multiple 
images in the
README, wherease in our case there's one SVG containing multiple 
svgs. The

motivation behind this is being able to update the badges without sending
patches to projects everytime the governance repo is modified.

This layout and format can of couse be modified, the font size and 
family can be

changed, etc. See[1].


What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous 
header, and the

header "Trove" below that.

In some cases the second header is the same font as the "Team and 
repository

tags" header.


I explained this a bit here[2]. The reason for prepending these 
secion to the

README's instead of finding a good place in it is that READMEs throughout
OpenStack are quite different from each other and putting this at 
the top helped

in making the process of adding the badges simpler.

I think this change (these 124 changes) as proposed are not 
consistent with
the proposal you made below, and certainly seem to be less 
suitable than that
proposal. The end product for the four trove repositories [4], 
[5], [6], and

[7]

I think we should have a discussion on the ML whether we feel that 
this new

structure is the appropriate one, and before some projects approve these
changes and others don't that these be all marked WF-1.


I honestly don't think the current proposal is bad, it's different 
from Kombu
for the reasons I mentioned above but it can be improved. Not that 
improving the
badges and their layout doesn't require submitting these patches 
again. It'll be

enough to modify the governance repo that generates these images.

Hope this helps,
Flavio


[0] 
http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts/badges.py
[1] https://review.openstack.org/#/c/399278/
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107969.html


Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258





-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Thursday, October 13, 2016 7:07 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's 
metadata in

README files

On 12/10/16 11:01 -0400, Doug Hellmann wrote:

Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:

Greetings,

One of the common complains about the existing project organization
in the big tent is that it's difficult to wrap our heads around the
many projects there are, their current state (in/out the big 

tent), their
tags, etc.


This 

[openstack-dev] [nova] placement/resource providers update 3

[Chris Dent]

More on what's happening in the resource provider and placement API
world.

See the first message[0] for what this about.

If you have any additions or corrections please followup to this
message; this is being done to help keep things moving along, if it is
wrong we'll go the wrong way and that will be :(.

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107171.html

# Stuff What Merged

* Increased gabbi test coverage (stack of 3):
https://review.openstack.org/#/c/396363/

* Aggregates support in placement api (stack of 2):
https://review.openstack.org/#/c/355263/
Review of this stack identified a race condition which has been
fixed but now we're not sure how/if to test it.

* Spec for modifying the scheduler to query the api:
https://review.openstack.org/#/c/300178/

* Custom resource classes spec:
https://review.openstack.org/#/c/312696/

* Custom resource classes code:
https://review.openstack.org/#/q/topic:bp/custom-resource-classes
Some, but not all (see below) of the code has merged.

# Leftovers from Previous Work

This section describes work that was left unfinished for one reason or
another, was discovered as a result of doing other work, or is work on
a bug[1]. It included items from a newton leftovers etherpad[2]. That
etherpad lists additional work that needs to be picked up.

Ready for review:

* Improved 404 responses (1 merged, 1 pending):
https://review.openstack.org/#/c/392321/

* Demo inventory update script:
https://review.openstack.org/#/c/382613/
This one might be considered a WIP because how it chooses to do
things (rather simply and dumbly) may not be in line with expecations.

* CORS support in placement API:
https://review.openstack.org/#/c/392891/

Need response to reviews:

* Handle maximum limit in schema for int and float type parameters
  https://review.openstack.org/#/c/399002/

* Return 400 when name is more than 200 characters
  https://review.openstack.org/#/c/398998/

(Both of these are fixes for bugs with insufficient input validation.
There's some debate on the reviews about whether validation needs to
happen about both the API and the OVO level. I don't know, do you?)

Needs discussion to figure out the best solution:

* [WIP] Placement api: Add json_error_formatter to defaults
  https://review.openstack.org/#/c/395194/

[1] https://bugs.launchpad.net/nova/+bugs?field.tag=placement
[2] https://etherpad.openstack.org/p/placement-newton-leftovers

# Filtering compute nodes with the placement API

This section is related to the collection of changes in both the
placement API, the resource tracker and nova-scheduler such that the
filtering of compute nodes by the scheduler can be augmented by the
placement API.

Specs for the placement API changes (to filter a list of resource
providers based on a set of resource requirements) have merged.

* Code that satisfies those two specs (stack of 2):
https://review.openstack.org/#/c/386242/

What's not yet been started is the work to change the scheduler.

As the get and set aggregate handling in the placement API has now
merged (see above) it's also time to start thinking about how
association with shared disk will be managed from the resource tracker
and in the filtering process.

# Custom Resource Classes

* Code to make them work in the api (stack of 3):
https://review.openstack.org/#/c/391918/
Some of this code has merged (see above) but some bit still under
review.

# Nested Resource Providers

* The spec
https://review.openstack.org/#/c/386710/

* Code to implement the object and HTTP API changes (stack of 4):
https://review.openstack.org/#/c/377138/
This stuff was racing with aggregates for object and api
microversions and aggregates won, so it's all had to be rebased.

# Allocations for generic PCI devices

* Code (stack of 3):
https://review.openstack.org/#/c/396963/

# Important stuff not in other categories

(Note that nothing has changed from here to the end of the message since
the previous message (except for footnote numbers) so you can stop here if
you already know it. It's here to keep it on the radar.)

This section is for lose ends that don't fit in elsewhere. Stuff
we're going to need to figure out at some point.

## Placement DB

No new discussion or progress on this. The etherpad[3] and related
code changes[4] remain the same. The todo here is to resolve the
questions on the etherpad and make an explicit plan.

[3] https://etherpad.openstack.org/p/placement-optional-db-spec
[4] https://review.openstack.org/#/c/362766/ (this is -2d pending
resolution of the stuff on the etherpad)

## Placement Docs

Matt R made a great start[5] to this setting the foundation for
the rest of us to build on. The major portion left as a TODO is
docs of the API. Because, for the time being, the API is relatively
simple, it has been decided that creating the docs by hand is okay.

So the todo here is: get started on the 

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Ian Y. Choi]

Hello Flavio,

I have two questions on this thread:

1) I have just written my review on training-guides repository
: https://review.openstack.org/#/c/402607/1 .
Then would you revise your initialized patchset by yourself? Or Your 
intention
would be to discuss more on each repository team members and revise 
patch(es) by themselves?


2) Can I18n team (openstack/i18n and openstack/i18n-specs) have such 
image tag? :)



With many thanks,

/Ian

Flavio Percoco wrote on 11/25/2016 11:00 PM:

On 25/11/16 13:46 +, Amrith Kumar wrote:

Flavio,

I see a number of patches[1] which have been landed on this project 
but I find
that at least the ones that were landed for Trove, and a random 
sampling of

the others all to be different from what you proposed below[2] in one
important aspect.

In [2] you proposed a structure where the title of the document; or 
the first,
and most prominent heading, would be the existing heading of the 
document, and

the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.


Hey Amrith,

One reason it's different from Kombu is because Kombu uses shields as 
a backend
for this SVGs, whereas we don't. We generate the badges ourselves[0], 
which

probably ended up in some differences.

The other main difference in the kombu case, there are multiple images 
in the
README, wherease in our case there's one SVG containing multiple svgs. 
The

motivation behind this is being able to update the badges without sending
patches to projects everytime the governance repo is modified.

This layout and format can of couse be modified, the font size and 
family can be

changed, etc. See[1].


What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, 
and the

header "Trove" below that.

In some cases the second header is the same font as the "Team and 
repository

tags" header.


I explained this a bit here[2]. The reason for prepending these secion 
to the

README's instead of finding a good place in it is that READMEs throughout
OpenStack are quite different from each other and putting this at the 
top helped

in making the process of adding the badges simpler.

I think this change (these 124 changes) as proposed are not 
consistent with
the proposal you made below, and certainly seem to be less suitable 
than that
proposal. The end product for the four trove repositories [4], [5], 
[6], and

[7]

I think we should have a discussion on the ML whether we feel that 
this new

structure is the appropriate one, and before some projects approve these
changes and others don't that these be all marked WF-1.


I honestly don't think the current proposal is bad, it's different 
from Kombu
for the reasons I mentioned above but it can be improved. Not that 
improving the
badges and their layout doesn't require submitting these patches 
again. It'll be

enough to modify the governance repo that generates these images.

Hope this helps,
Flavio


[0] 
http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts/badges.py

[1] https://review.openstack.org/#/c/399278/
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107969.html



Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258





-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Thursday, October 13, 2016 7:07 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's 
metadata in

README files

On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> Greetings,
>>
>> One of the common complains about the existing project organization
>> in the big tent is that it's difficult to wrap our heads around the
>> many projects there are, their current state (in/out the big 
tent), their

tags, etc.
>>
>> This information is available on the governance website[0]. Each
>> official project team has a page there containing the information
>> related to the deliverables managed by that team. Unfortunately, I
>> don't think this page is checked often enough and I believe it's not
>> known
by everyone.
>>
>> In the hope that we can make this information clearer to people
>> browsing the many repos (most likely on github), I'd like to propose
>> that we include the information of each deliverable in the readme
>> file. This information would be rendered along with the rest of the
>> 

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

The same for Rally project...

On Thu, Oct 13, 2016 at 2:56 PM, Qiming Teng 
wrote:

> project-navigator? http://www.openstack.org/software/
>
> It is often misinterpreted as: OpenStack has 6 core services which are
> all mandatory (because they are *core* services) plus 13 optional
> services that can be selectively installed.
>
> I tried hard to find out how the lists are generated, but I failed.
> There are at least the following projects which are neither *core* nor
> *optional* services:
>
> cloudkitty
> dragonflow
> freezer
> karbor
> kolla
> kuryr
> mistral
> monasca
> searchlight
> senlin
> solum
> tacker
> vitrage
> watcher
>
> Looks like this is something causing some confusions. Should/can we fix
> that?
>
> Regards,
>   Qiming
>
>
> On Wed, Oct 12, 2016 at 02:43:45PM -0700, Mike Perez wrote:
> > On 14:50 Oct 12, Flavio Percoco wrote:
> > > Greetings,
> > >
> > > One of the common complains about the existing project organization in
> the big
> > > tent is that it's difficult to wrap our heads around the many projects
> there
> > > are, their current state (in/out the big tent), their tags, etc.
> > >
> > > This information is available on the governance website[0]. Each
> official
> > > project team has a page there containing the information related to the
> > > deliverables managed by that team. Unfortunately, I don't think this
> page is
> > > checked often enough and I believe it's not known by everyone.
> >
> > Besides the governance site, there is also the project navigator [1]
> which is
> > a more friendly landing page on projects and their tags. Although it
> does not
> > today capture separate deliverables.
> >
> > Assuming the README files aren't being manually updated, I don't have a
> problem
> > with this idea.
> >
> > [1] - https://www.openstack.org/software/project-navigator/
> >
> > --
> > Mike Perez
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Amrith Kumar]

Thanks Flavio,

I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I 
assume that other projects which want to do this kind of manual cleanup can 
either use this bug or create their own.

-amrith

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Friday, November 25, 2016 9:00 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
> README files
>
> On 25/11/16 13:46 +, Amrith Kumar wrote:
> >Flavio,
> >
> >I see a number of patches[1] which have been landed on this project but
> >I find that at least the ones that were landed for Trove, and a random
> >sampling of the others all to be different from what you proposed
> >below[2] in one important aspect.
> >
> >In [2] you proposed a structure where the title of the document; or the
> >first, and most prominent heading, would be the existing heading of the
> >document, and the tags would be below that. In [2] for example, that was:
> >
> >"kombu - Messaging library for Python"
> >
> >and the tags would be in smaller font below that.
>
> Hey Amrith,
>
> One reason it's different from Kombu is because Kombu uses shields as a
> backend for this SVGs, whereas we don't. We generate the badges
> ourselves[0], which probably ended up in some differences.
>
> The other main difference in the kombu case, there are multiple images in
> the README, wherease in our case there's one SVG containing multiple svgs.
> The motivation behind this is being able to update the badges without
> sending patches to projects everytime the governance repo is modified.
>
> This layout and format can of couse be modified, the font size and family 
> can
> be changed, etc. See[1].
>
> >What I see in [3] the patch for Trove and the proposed example [4] is:
> >
> >"Team and repository tags" as the first, and most conspicuous header,
> >and the header "Trove" below that.
> >
> >In some cases the second header is the same font as the "Team and
> >repository tags" header.
>
> I explained this a bit here[2]. The reason for prepending these secion to 
> the
> README's instead of finding a good place in it is that READMEs throughout
> OpenStack are quite different from each other and putting this at the top
> helped in making the process of adding the badges simpler.
>
> >I think this change (these 124 changes) as proposed are not consistent
> >with the proposal you made below, and certainly seem to be less
> >suitable than that proposal. The end product for the four trove
> >repositories [4], [5], [6], and [7]
> >
> >I think we should have a discussion on the ML whether we feel that this
> >new structure is the appropriate one, and before some projects approve
> >these changes and others don't that these be all marked WF-1.
>
> I honestly don't think the current proposal is bad, it's different from 
> Kombu
> for the reasons I mentioned above but it can be improved. Not that
> improving the badges and their layout doesn't require submitting these
> patches again. It'll be enough to modify the governance repo that generates
> these images.
>
> Hope this helps,
> Flavio
>
>
> [0]
> http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts
> /badges.py
> [1] https://review.openstack.org/#/c/399278/
> [2] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107969.html
>
> >Thanks,
> >
> >-amrith
> >
> >[1] https://review.openstack.org/#/q/topic:project-badges
> >[2] https://github.com/celery/kombu/blob/master/README.rst
> >[3] https://review.openstack.org/#/c/402547/
> >[4]
> https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
> >[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
> >[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
> >[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
> >
> >
> >
> >
> >> -Original Message-
> >> From: Flavio Percoco [mailto:fla...@redhat.com]
> >> Sent: Thursday, October 13, 2016 7:07 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [all][tc] Exposing project team's
> >> metadata in README files
> >>
> >> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >> >> Greetings,
> >> >>
> >> >> One of the common complains about the existing project
> >> >> organization in the big tent is that it's difficult to wrap our
> >> >> heads around the many projects there are, their current state
> >> >> (in/out the big tent), their
> >> tags, etc.
> >> >>
> >> >> This information is available on the governance website[0]. Each
> >> >> official project team has a page there containing the information
> >> >> related to the deliverables managed by that team. Unfortunately, I
> >> >> don't think this page is checked often enough and I 

[openstack-dev] [release] Re: [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Ihar Hrachyshka]

> On 25 Nov 2016, at 15:23, Takashi Yamamoto  wrote:
> 
> On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka  wrote:
>> 
>>> On 25 Nov 2016, at 11:02, Takashi Yamamoto  wrote:
>>> 
>>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka  
>>> wrote:
 
> On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:
> 
> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  
> wrote:
>> 
>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto  
>>> wrote:
>>> 
>>> hi,
>>> 
>>> networking-midonet doesn't have stable/newton branch yet.
>>> newton jobs failures are false alarms.
>>> 
>>> branching has been delayed because development of some futures
>>> planned for newton has not been completed yet.
>>> 
>>> the plan is to revert ocata-specific changes after branching newton.
>> 
>> I don’t think it’s a good idea since you will need to tag a release on 
>> branch creation, that is supposed to be compatible with next releases in 
>> that same branch.
> 
> can't we create the tag after the revert?
> 
 
 No, that’s release team requirement that they branch on a release tag.
>>> 
>>> ok, i didn't know the requirement. thank you.
>>> 
 
> anyway no one think this is a good idea.
> it's just an unfortunate compromise we ended up.
> we are trying to make the schedule better for next release.
 
 It would make more sense to tag on a compatible commit from the past and 
 consider it a first stable release. (Of course it means that feature 
 development would need to be aligned appropriately.)
>>> 
>>> in that case, can we backport the features?
>>> (namely qos and lbaas drivers are in my mind)
>> 
>> No, I don’t think so. Though maybe we can release an RC as the first tag in 
>> the branch and backport features before releasing a final version? I dunno, 
>> I guess you will need to talk to OpenStack release folks on how to proceed.
> 
> is it a release team matter?
> i thought these were a policy inside neutron.
> after all networking-midonet is release:independent.

Neutron does not override global policies. I explicitly asked during the last 
summit if we can branch before a tag; the answer was no, it’s not an option.

Adding [release] tag since it becomes a matter beyond neutron.

Ihar
__
OpenStack Development Mailing 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][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 8:02 PM, Ihar Hrachyshka  wrote:
>
>> On 25 Nov 2016, at 11:02, Takashi Yamamoto  wrote:
>>
>> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka  wrote:
>>>
 On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:

 On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  
 wrote:
>
>> On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:
>>
>> hi,
>>
>> networking-midonet doesn't have stable/newton branch yet.
>> newton jobs failures are false alarms.
>>
>> branching has been delayed because development of some futures
>> planned for newton has not been completed yet.
>>
>> the plan is to revert ocata-specific changes after branching newton.
>
> I don’t think it’s a good idea since you will need to tag a release on 
> branch creation, that is supposed to be compatible with next releases in 
> that same branch.

 can't we create the tag after the revert?

>>>
>>> No, that’s release team requirement that they branch on a release tag.
>>
>> ok, i didn't know the requirement. thank you.
>>
>>>
 anyway no one think this is a good idea.
 it's just an unfortunate compromise we ended up.
 we are trying to make the schedule better for next release.
>>>
>>> It would make more sense to tag on a compatible commit from the past and 
>>> consider it a first stable release. (Of course it means that feature 
>>> development would need to be aligned appropriately.)
>>
>> in that case, can we backport the features?
>> (namely qos and lbaas drivers are in my mind)
>
> No, I don’t think so. Though maybe we can release an RC as the first tag in 
> the branch and backport features before releasing a final version? I dunno, I 
> guess you will need to talk to OpenStack release folks on how to proceed.

is it a release team matter?
i thought these were a policy inside neutron.
after all networking-midonet is release:independent.

>
> Ihar

__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 13:46 +, Amrith Kumar wrote:

Flavio,

I see a number of patches[1] which have been landed on this project but I find
that at least the ones that were landed for Trove, and a random sampling of
the others all to be different from what you proposed below[2] in one
important aspect.

In [2] you proposed a structure where the title of the document; or the first,
and most prominent heading, would be the existing heading of the document, and
the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.


Hey Amrith,

One reason it's different from Kombu is because Kombu uses shields as a backend
for this SVGs, whereas we don't. We generate the badges ourselves[0], which
probably ended up in some differences.

The other main difference in the kombu case, there are multiple images in the
README, wherease in our case there's one SVG containing multiple svgs. The
motivation behind this is being able to update the badges without sending
patches to projects everytime the governance repo is modified.

This layout and format can of couse be modified, the font size and family can be
changed, etc. See[1].


What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, and the
header "Trove" below that.

In some cases the second header is the same font as the "Team and repository
tags" header.


I explained this a bit here[2]. The reason for prepending these secion to the
README's instead of finding a good place in it is that READMEs throughout
OpenStack are quite different from each other and putting this at the top helped
in making the process of adding the badges simpler.


I think this change (these 124 changes) as proposed are not consistent with
the proposal you made below, and certainly seem to be less suitable than that
proposal. The end product for the four trove repositories [4], [5], [6], and
[7]

I think we should have a discussion on the ML whether we feel that this new
structure is the appropriate one, and before some projects approve these
changes and others don't that these be all marked WF-1.


I honestly don't think the current proposal is bad, it's different from Kombu
for the reasons I mentioned above but it can be improved. Not that improving the
badges and their layout doesn't require submitting these patches again. It'll be
enough to modify the governance repo that generates these images.

Hope this helps,
Flavio


[0] 
http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts/badges.py
[1] https://review.openstack.org/#/c/399278/
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107969.html


Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258





-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Thursday, October 13, 2016 7:07 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
README files

On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> Greetings,
>>
>> One of the common complains about the existing project organization
>> in the big tent is that it's difficult to wrap our heads around the
>> many projects there are, their current state (in/out the big tent), their
tags, etc.
>>
>> This information is available on the governance website[0]. Each
>> official project team has a page there containing the information
>> related to the deliverables managed by that team. Unfortunately, I
>> don't think this page is checked often enough and I believe it's not
>> known
by everyone.
>>
>> In the hope that we can make this information clearer to people
>> browsing the many repos (most likely on github), I'd like to propose
>> that we include the information of each deliverable in the readme
>> file. This information would be rendered along with the rest of the
>> readme (at least on Github, which might not be our main repo but it's the
place most humans go to to check our projects).
>>
>> Rather than duplicating this information, I'd like to find a way to
>> just "include it" in the Readme file. As far as showing the
>> "official" badge goes, I believe it'd be quite simple. We can do it
>> the same way CI tags are exposed when using travis (just include an
>> image). As for the rest of the tags, it might require some extra hacking.
>>
>> So, before I start digging more into this, I wanted 

Re: [openstack-dev] [Rally][all] Gitter as an alternative way for communication

[Andrey Kurilin]

Hi Thierry,

On Fri, Nov 25, 2016 at 12:51 PM, Thierry Carrez 
wrote:

> Andrey Kurilin wrote:
> > I'm happy to announce our new chats at gitter.im  :
> > [...]
>
> While I understand where you're coming from, I would like to remind you
> that the OpenStack community standardized on IRC for community
> communication. Maintaining alternate communication channels might make
> it slightly easier for your team members, but it makes it more difficult
> for others in the OpenStack community to follow what is happening, and
> participate to Rally development.


As I said before, we do not plan to abandon our regular IRC channel and we
have a bot for synchronisation messages between gitter and irc channels, so
users from Gitter can participate in IRC discussions, and vice versa users
from IRC
can ping guys from our Gitter channel. It is just an extension of rally
communication
workflow, not replacement of IRC at all.



> This is why as part of the official
> OpenStack project team requirements we have usage of IRC baked in.
>
> IRC is a standard protocol, implemented in a lot of open source clients.
> Alternatives like Slack or Gitter are closed-source services with terms
> of use (and future decisions on openness and pricing) that may or may
> not be acceptable by our community members -- using them creates
> fragmentation within the OpenStack community.
>
> That is not saying that IRC is perfect and that we will never move to
> something else. But when we do, it will be as a community (and after an
> open community discussion) and not project per project.


I can believe that OpenStack community will move from Freenode to another
IRC service (if Freenode dies) someday, but moving to another protocol is
unbelievable
thing for me. OpenStack community will never do it. :) We'd rather maintain
IRC protocol by ourself...

That is why Rally-community decided to use "not-irc tool" without
cross-project
discussion. BUT, as I said before, we did it without breaking compatibility
with
other OpenStack projects and we will not do it..


> It is also
> likely to be toward an open protocol supported by open source software,
> rather than one specific third-party proprietary web service.
>

Why? Why we can not use convenient free for opensource projects things?
Why not enjoy all the advantages of the modern world?:) It is out of
current topic, but
why we use inconvenient launchpad instead of bitbucket and so on?


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



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Julien Danjou]

On Fri, Nov 25 2016, Amrith Kumar wrote:

> I see a number of patches[1] which have been landed on this project but I 
> find 
> that at least the ones that were landed for Trove, and a random sampling of 
> the others all to be different from what you proposed below[2] in one 
> important aspect.
>
> In [2] you proposed a structure where the title of the document; or the 
> first, 
> and most prominent heading, would be the existing heading of the document, 
> and 
> the tags would be below that. In [2] for example, that was:
>
> "kombu - Messaging library for Python"
>
> and the tags would be in smaller font below that.
>
> What I see in [3] the patch for Trove and the proposed example [4] is:
>
> "Team and repository tags" as the first, and most conspicuous header, and the 
> header "Trove" below that.
>
> In some cases the second header is the same font as the "Team and repository 
> tags" header.

Just FTR, this also is why I -1ed the Telemetry patches.

Cheers,
-- 
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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][tc] Exposing project team's metadata in README files

[Amrith Kumar]

Flavio,

I see a number of patches[1] which have been landed on this project but I find 
that at least the ones that were landed for Trove, and a random sampling of 
the others all to be different from what you proposed below[2] in one 
important aspect.

In [2] you proposed a structure where the title of the document; or the first, 
and most prominent heading, would be the existing heading of the document, and 
the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.

What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, and the 
header "Trove" below that.

In some cases the second header is the same font as the "Team and repository 
tags" header.

I think this change (these 124 changes) as proposed are not consistent with 
the proposal you made below, and certainly seem to be less suitable than that 
proposal. The end product for the four trove repositories [4], [5], [6], and 
[7]

I think we should have a discussion on the ML whether we feel that this new 
structure is the appropriate one, and before some projects approve these 
changes and others don't that these be all marked WF-1.

Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258




> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Thursday, October 13, 2016 7:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
> README files
>
> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >> Greetings,
> >>
> >> One of the common complains about the existing project organization
> >> in the big tent is that it's difficult to wrap our heads around the
> >> many projects there are, their current state (in/out the big tent), their
> tags, etc.
> >>
> >> This information is available on the governance website[0]. Each
> >> official project team has a page there containing the information
> >> related to the deliverables managed by that team. Unfortunately, I
> >> don't think this page is checked often enough and I believe it's not 
> >> known
> by everyone.
> >>
> >> In the hope that we can make this information clearer to people
> >> browsing the many repos (most likely on github), I'd like to propose
> >> that we include the information of each deliverable in the readme
> >> file. This information would be rendered along with the rest of the
> >> readme (at least on Github, which might not be our main repo but it's the
> place most humans go to to check our projects).
> >>
> >> Rather than duplicating this information, I'd like to find a way to
> >> just "include it" in the Readme file. As far as showing the
> >> "official" badge goes, I believe it'd be quite simple. We can do it
> >> the same way CI tags are exposed when using travis (just include an
> >> image). As for the rest of the tags, it might require some extra hacking.
> >>
> >> So, before I start digging more into this, I wanted to get other
> >> opinions/ideas on this topic and how we can make this information
> >> more evident to the rest of the community (and people not as familiar
> with our processes as some of us are).
> >>
> >> Thanks in advance,
> >> Flavio
> >>
> >> [0] http://governance.openstack.org/reference/projects/index.html
> >>
> >
> >Is your proposal that a tag like release:cycle-with-milestones would
> >result in a badge being added when the README.rst is rendered on
> >github.com? Would that work for git.openstack.org, too?
>
> I don't think it'd work for git.openstack.org because it doesn't render the
> README's[0] like github does. One thing I'd like to avoid is for this
> information to result in new changes to the README file everytime the tags
> are updated because I'd like for this information to not be duplicated and 
> to
> make it clear that this information is not meant to be updated manually.
>
> Here's[1] an example of what it would look like (or kinda).
>
> [0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
> [1] https://github.com/celery/kombu/blob/master/README.rst
>
>
> >I agree that the governance site is not the best place to put the info
> >to make it discoverable. Do users look first at the source repository,
> >or at some other documentation?
>
> The feedback* I've gotten is that users normally look at repos first and 
> they
> go from there to docs 

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

[Emilien Macchi]

On Fri, Nov 25, 2016 at 7:22 AM, Gabriele Cerami  wrote:
> On 22 Nov, Emilien Macchi wrote:
>> 1) Re-use experience from Puppet OpenStack CI and have environments
>> that are in a branched repository.
>> a) Move CI environments and pingtest into
>> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
>> is branched and we could add a README to explain these files are used
>> in CI and we don't guarantee they would work outside TripleO CI tools.
>
> I would consider it a big step for tht repo, to include test specific
> code in it. *Upstream CI specific code* even
>
>> b) Branch tripleo-ci repository. Personally I don't like this solution
>> because a lot of patches in this repo are not related to OpenStack
>> versions, which means we would need to backport most of the things
>> from master.
>
> I agree, we should be able to branch only the options and configuration,
> not the entire process. Process is constantly changing and it would be
> a pain to backport all this changes.
>
>> 2) Introduce branch-based scenario tests -
>> https://review.openstack.org/#/c/396008/
>> It duplicates a lot of code and it's imho not really effective, though
>> this solution would correctly works.
>
> I don't understand why you consider this code duplication and don't
> consider branching code duplication too.
> With branches you're duplicating even if you don't see all the
> duplicates at once. Consider that with this method it could be easier to
> "backport" a scenario modification, since you can do everything with a
> single commit.
> I would prefer a different format tough
> templates/$BRANCH/scenario-001.yaml
> test-environments/$BRANCH/scenario-001.yaml

With branches, we might see the "duplication" as a simple backport.
Remember, we don't backport features, so once we cut a release, we
should not backport any change in our scenarios environments, since we
don't had features (again).

Which means, once we implement the CI templates in THT, we shouldn't
backport anything but bugfixes in stable branches. Scenarios will
evolve as we add features in master (ex: barbican service, etc).
That said, 2) would also work. It's just a lot of files and lines of
code in tripleo-ci, that could live in a branched repo (THT), which is
why I took the simplest solution with 1)a).

>> 3) Introduce a new scenario each time we have new services (like we
>> did with scenario004).
>
> This doesn't scale well, we would have to be able to select which
> scenario to run anyway
>
>
> I have one last consideration to make.
> With the transition to quickstart, we're effectively moving the process
> part of tripleo-ci to another repo.
> After the transition we could consider tripleo-ci more options and
> configuration that process, and the we could start branching it, without
> all the drawbacks we considered here.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
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] [all][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 12:33 +, Dulko, Michal wrote:

On Fri, 2016-11-25 at 12:38 +0100, Flavio Percoco wrote:

Greetings,

Just a heads up for everyone. The work on this front has moved
forward and the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite
obvious, the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the
projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of
"viral
changes" but I've done my best to explain what's changing, provide
references
and examples on the commit message. These changes are being submitted
using the
tag 'project-badges'[2].


Looks like Cinder patch is missing there?


Probably still loading it! I got a bit ahead of the submission process because I
didn't want it to catch everyone by surprise. I'll let you know when the command
is done submitting patches.

Thanks for reaching out,
Flavio



Note that these badges are *JUST* a graphical representation of
what's in the
governance repo. If you don't want to have them in the README file, I
guess it's
fine. I'd, however, encourage everyone to add them to provide
consistency and a
more immediate information of what the project is about, what some of
the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well
but I'll
leave that to every team to do.

Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better
ideas please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/

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


--
@flaper87
Flavio Percoco


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][tc] Exposing project team's metadata in README files

[Dulko, Michal]

On Fri, 2016-11-25 at 12:38 +0100, Flavio Percoco wrote:
> Greetings,
> 
> Just a heads up for everyone. The work on this front has moved
> forward and the
> badges are now being generated as part of the governance CI[0].
> 
> You can find the list of badges here[1] and the pattern is quite
> obvious, the
> name of the image is based on the project repo name.
> 
> I've edited the README files for all repositories listed in the
> projects.yaml
> file and I've started to submit these patches[2]. I'm not a fan of
> "viral
> changes" but I've done my best to explain what's changing, provide
> references
> and examples on the commit message. These changes are being submitted
> using the
> tag 'project-badges'[2].

Looks like Cinder patch is missing there?

> 
> Note that these badges are *JUST* a graphical representation of
> what's in the
> governance repo. If you don't want to have them in the README file, I
> guess it's
> fine. I'd, however, encourage everyone to add them to provide
> consistency and a
> more immediate information of what the project is about, what some of
> the
> project capabilities are and what its status is.
> 
> Ideally this should also be added in projects documentation as well
> but I'll
> leave that to every team to do.
> 
> Happy to answer questions,
> Flavio
> 
> P.S: The current layout is being improved[3], if you have better
> ideas please
> help out.
> 
> [0] https://review.openstack.org/#/c/391588/
> [1] http://governance.openstack.org/badges/
> [2] https://review.openstack.org/#/q/topic:project-badges
> [3] https://review.openstack.org/#/c/399278/
__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 13:16 +0100, Flavio Percoco wrote:

On 25/11/16 12:38 +0100, Flavio Percoco wrote:

Greetings,

Just a heads up for everyone. The work on this front has moved forward and the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite obvious, the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of "viral
changes" but I've done my best to explain what's changing, provide references
and examples on the commit message. These changes are being submitted using the
tag 'project-badges'[2].


I also wanted to add that these patches are just for projects that are using rst
for their README files (sorry markdown) and that each commit has a preview link
that you can go and look at.

If the layout doesn't look perfect and the whitespace under the svg image
annoyes you, let me tell you that it was improved in the new layout, which is
under review. Also, Github does some funky things to the svg when it renders the
README file, hence the whitespace that was added for the first layout.


One last thing. You may/may not like the placement of these badges in the README
file. It's fine if you don't. The reason they are at the top is because they
normally are at the top :) Putting them at the top also made it simple to
automate the process accross all the *very* (trust me VERY) different README
files across the community.

If you don't like the placement of these badges, you're free to move them around
as prefer. I've done the job to help pushing the first patch, you're all free to
take it over, modify it, reject it or just merge it as is.

Hope this helps,
Flavio


Flavio


Note that these badges are *JUST* a graphical representation of what's in the
governance repo. If you don't want to have them in the README file, I guess it's
fine. I'd, however, encourage everyone to add them to provide consistency and a
more immediate information of what the project is about, what some of the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well but I'll
leave that to every team to do.

Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better ideas please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/

On 12/10/16 14:50 +0200, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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] CI scenarios design - how to add more services

[Gabriele Cerami]

On 22 Nov, Emilien Macchi wrote:
> 1) Re-use experience from Puppet OpenStack CI and have environments
> that are in a branched repository.
> a) Move CI environments and pingtest into
> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
> is branched and we could add a README to explain these files are used
> in CI and we don't guarantee they would work outside TripleO CI tools.

I would consider it a big step for tht repo, to include test specific
code in it. *Upstream CI specific code* even

> b) Branch tripleo-ci repository. Personally I don't like this solution
> because a lot of patches in this repo are not related to OpenStack
> versions, which means we would need to backport most of the things
> from master.

I agree, we should be able to branch only the options and configuration,
not the entire process. Process is constantly changing and it would be
a pain to backport all this changes.

> 2) Introduce branch-based scenario tests -
> https://review.openstack.org/#/c/396008/
> It duplicates a lot of code and it's imho not really effective, though
> this solution would correctly works.

I don't understand why you consider this code duplication and don't
consider branching code duplication too.
With branches you're duplicating even if you don't see all the
duplicates at once. Consider that with this method it could be easier to
"backport" a scenario modification, since you can do everything with a
single commit.
I would prefer a different format tough
templates/$BRANCH/scenario-001.yaml
test-environments/$BRANCH/scenario-001.yaml

> 3) Introduce a new scenario each time we have new services (like we
> did with scenario004).

This doesn't scale well, we would have to be able to select which
scenario to run anyway


I have one last consideration to make.
With the transition to quickstart, we're effectively moving the process
part of tripleo-ci to another repo.
After the transition we could consider tripleo-ci more options and
configuration that process, and the we could start branching it, without
all the drawbacks we considered here.

__
OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 25/11/16 12:38 +0100, Flavio Percoco wrote:

Greetings,

Just a heads up for everyone. The work on this front has moved forward and the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite obvious, the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of "viral
changes" but I've done my best to explain what's changing, provide references
and examples on the commit message. These changes are being submitted using the
tag 'project-badges'[2].


I also wanted to add that these patches are just for projects that are using rst
for their README files (sorry markdown) and that each commit has a preview link
that you can go and look at.

If the layout doesn't look perfect and the whitespace under the svg image
annoyes you, let me tell you that it was improved in the new layout, which is
under review. Also, Github does some funky things to the svg when it renders the
README file, hence the whitespace that was added for the first layout.

Flavio


Note that these badges are *JUST* a graphical representation of what's in the
governance repo. If you don't want to have them in the README file, I guess it's
fine. I'd, however, encourage everyone to add them to provide consistency and a
more immediate information of what the project is about, what some of the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well but I'll
leave that to every team to do.

Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better ideas please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/

On 12/10/16 14:50 +0200, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

Greetings,

Just a heads up for everyone. The work on this front has moved forward and the
badges are now being generated as part of the governance CI[0].

You can find the list of badges here[1] and the pattern is quite obvious, the
name of the image is based on the project repo name.

I've edited the README files for all repositories listed in the projects.yaml
file and I've started to submit these patches[2]. I'm not a fan of "viral
changes" but I've done my best to explain what's changing, provide references
and examples on the commit message. These changes are being submitted using the
tag 'project-badges'[2].

Note that these badges are *JUST* a graphical representation of what's in the
governance repo. If you don't want to have them in the README file, I guess it's
fine. I'd, however, encourage everyone to add them to provide consistency and a
more immediate information of what the project is about, what some of the
project capabilities are and what its status is.

Ideally this should also be added in projects documentation as well but I'll
leave that to every team to do.

Happy to answer questions,
Flavio

P.S: The current layout is being improved[3], if you have better ideas please
help out.

[0] https://review.openstack.org/#/c/391588/
[1] http://governance.openstack.org/badges/
[2] https://review.openstack.org/#/q/topic:project-badges
[3] https://review.openstack.org/#/c/399278/

On 12/10/16 14:50 +0200, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Ihar Hrachyshka]

> On 25 Nov 2016, at 11:02, Takashi Yamamoto  wrote:
> 
> On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka  wrote:
>> 
>>> On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:
>>> 
>>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  
>>> wrote:
 
> On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:
> 
> hi,
> 
> networking-midonet doesn't have stable/newton branch yet.
> newton jobs failures are false alarms.
> 
> branching has been delayed because development of some futures
> planned for newton has not been completed yet.
> 
> the plan is to revert ocata-specific changes after branching newton.
 
 I don’t think it’s a good idea since you will need to tag a release on 
 branch creation, that is supposed to be compatible with next releases in 
 that same branch.
>>> 
>>> can't we create the tag after the revert?
>>> 
>> 
>> No, that’s release team requirement that they branch on a release tag.
> 
> ok, i didn't know the requirement. thank you.
> 
>> 
>>> anyway no one think this is a good idea.
>>> it's just an unfortunate compromise we ended up.
>>> we are trying to make the schedule better for next release.
>> 
>> It would make more sense to tag on a compatible commit from the past and 
>> consider it a first stable release. (Of course it means that feature 
>> development would need to be aligned appropriately.)
> 
> in that case, can we backport the features?
> (namely qos and lbaas drivers are in my mind)

No, I don’t think so. Though maybe we can release an RC as the first tag in the 
branch and backport features before releasing a final version? I dunno, I guess 
you will need to talk to OpenStack release folks on how to proceed.

Ihar
__
OpenStack Development Mailing 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] [Rally][all] Gitter as an alternative way for communication

[Thierry Carrez]

Andrey Kurilin wrote:
> I'm happy to announce our new chats at gitter.im  :
> [...]

While I understand where you're coming from, I would like to remind you
that the OpenStack community standardized on IRC for community
communication. Maintaining alternate communication channels might make
it slightly easier for your team members, but it makes it more difficult
for others in the OpenStack community to follow what is happening, and
participate to Rally development. This is why as part of the official
OpenStack project team requirements we have usage of IRC baked in.

IRC is a standard protocol, implemented in a lot of open source clients.
Alternatives like Slack or Gitter are closed-source services with terms
of use (and future decisions on openness and pricing) that may or may
not be acceptable by our community members -- using them creates
fragmentation within the OpenStack community.

That is not saying that IRC is perfect and that we will never move to
something else. But when we do, it will be as a community (and after an
open community discussion) and not project per project. It is also
likely to be toward an open protocol supported by open source software,
rather than one specific third-party proprietary web service.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 6:54 PM, Ihar Hrachyshka  wrote:
>
>> On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:
>>
>> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  wrote:
>>>
 On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:

 hi,

 networking-midonet doesn't have stable/newton branch yet.
 newton jobs failures are false alarms.

 branching has been delayed because development of some futures
 planned for newton has not been completed yet.

 the plan is to revert ocata-specific changes after branching newton.
>>>
>>> I don’t think it’s a good idea since you will need to tag a release on 
>>> branch creation, that is supposed to be compatible with next releases in 
>>> that same branch.
>>
>> can't we create the tag after the revert?
>>
>
> No, that’s release team requirement that they branch on a release tag.

ok, i didn't know the requirement. thank you.

>
>> anyway no one think this is a good idea.
>> it's just an unfortunate compromise we ended up.
>> we are trying to make the schedule better for next release.
>
> It would make more sense to tag on a compatible commit from the past and 
> consider it a first stable release. (Of course it means that feature 
> development would need to be aligned appropriately.)

in that case, can we backport the features?
(namely qos and lbaas drivers are in my mind)

>
> I see that subprojects do the same mistake over and over (the previous time 
> it was sfc, but I’ve heard similar concerns from bgpvpn). I believe that we 
> should set clear expectations for all stadium participants about when they 
> first stable releases happen and when branches are created. The current lack 
> of guidelines for participants just makes it harder for the core team to 
> maintain the setting, and for subprojects to become good citizens.
>
> Ihar

__
OpenStack Development Mailing 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][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Ihar Hrachyshka]

> On 25 Nov 2016, at 09:25, Takashi Yamamoto  wrote:
> 
> On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  wrote:
>> 
>>> On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:
>>> 
>>> hi,
>>> 
>>> networking-midonet doesn't have stable/newton branch yet.
>>> newton jobs failures are false alarms.
>>> 
>>> branching has been delayed because development of some futures
>>> planned for newton has not been completed yet.
>>> 
>>> the plan is to revert ocata-specific changes after branching newton.
>> 
>> I don’t think it’s a good idea since you will need to tag a release on 
>> branch creation, that is supposed to be compatible with next releases in 
>> that same branch.
> 
> can't we create the tag after the revert?
> 

No, that’s release team requirement that they branch on a release tag.

> anyway no one think this is a good idea.
> it's just an unfortunate compromise we ended up.
> we are trying to make the schedule better for next release.

It would make more sense to tag on a compatible commit from the past and 
consider it a first stable release. (Of course it means that feature 
development would need to be aligned appropriately.)

I see that subprojects do the same mistake over and over (the previous time it 
was sfc, but I’ve heard similar concerns from bgpvpn). I believe that we should 
set clear expectations for all stadium participants about when they first 
stable releases happen and when branches are created. The current lack of 
guidelines for participants just makes it harder for the core team to maintain 
the setting, and for subprojects to become good citizens.

Ihar
__
OpenStack Development Mailing 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] [new][nimble] New project: Nimble

[Zhenguo Niu]

hi all,

We are pleased to introduce Nimble, a new OpenStack project which aims to
provide bare metal computing management.
Compared with Nova, it's more bare metal specific and with more advanced
features that VM users don't need, it's not
bounded by Nova's API.

As we know, Ironic API should never be exposed to end users, users have to
talk to Nova to request a bare metal compute
instance even if you're only providing bare metal, even if it's only
internally, you still have to talk to nova, Ironic doesn't have
a concept of users, tenants, and quotas. Nimble wants to decouple
virtualization and baremetal technologies by breaking
baremetal computing management into its own set of application program
interfaces.

Not only does Nimble provide pre-set configuration servers, but it also
wants to support RSD(Rack Scale Design) which makes
it possible to dynamically compose physical resouces.

For more information, including architecture, use cases, etc., are
described on the project wiki [0].
And please feel free to browse our source code [1][2].

If you're intreasted in Nimble, please join!

Thanks,

[0] https://wiki.openstack.org/wiki/Nimble
[1] https://github.com/openstack/nimble
[2] https://github.com/openstack/python-nimbleclient
__
OpenStack Development Mailing 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] [magnum-ui][horizon] use json-schema-form on workflow

[Rob Cresswell]

From a quick scan, it looks like you're using it several times in the same 
workflow? Why not just use the existing tabs type and create a single form? 
Have a look at https://review.openstack.org/#/c/348969/for reference.

Rob

On 25 Nov 2016 08:28, "Shuu Mutou" 
> wrote:
Hi Thai,

We're trying to use json-schema-form in workflow, but 'required' attribute 
doesn't work. So we can push 'create' button without input. Could you check 
following patch?

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

best regards,
Shu Muto


__
OpenStack Development Mailing 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] [neutron][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Takashi Yamamoto]

On Fri, Nov 25, 2016 at 5:18 PM, Ihar Hrachyshka  wrote:
>
>> On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:
>>
>> hi,
>>
>> networking-midonet doesn't have stable/newton branch yet.
>> newton jobs failures are false alarms.
>>
>> branching has been delayed because development of some futures
>> planned for newton has not been completed yet.
>>
>> the plan is to revert ocata-specific changes after branching newton.
>
> I don’t think it’s a good idea since you will need to tag a release on branch 
> creation, that is supposed to be compatible with next releases in that same 
> branch.

can't we create the tag after the revert?

anyway no one think this is a good idea.
it's just an unfortunate compromise we ended up.
we are trying to make the schedule better for next release.

>
>>
>> On Fri, Nov 25, 2016 at 9:14 AM, Ihar Hrachyshka  wrote:
>>> Hi,
>>>
>>> could anyone from the midonet subproject take ownership of repo stable
>>> branches? Newton branch is broken for weeks with no apparent actions from
>>> the core team side.
>>>
>>> Begin forwarded message:
>>>
>>> From: "A mailing list for the OpenStack Stable Branch test reports."
>>> 
>>> Subject: [Openstack-stable-maint] Stable check of
>>> openstack/networking-midonet failed
>>> Date: 24 November 2016 at 07:11:42 GMT+1
>>> To: openstack-stable-ma...@lists.openstack.org
>>> Reply-To: openstack-dev@lists.openstack.org
>>>
>>> Build failed.
>>>
>>> - periodic-networking-midonet-docs-liberty
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
>>> : SUCCESS in 4m 58s
>>> - periodic-networking-midonet-python27-liberty
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
>>> : SUCCESS in 9m 57s
>>> - periodic-networking-midonet-docs-mitaka
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
>>> : SUCCESS in 2m 19s
>>> - periodic-networking-midonet-python27-mitaka
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
>>> : SUCCESS in 7m 06s
>>> - periodic-networking-midonet-docs-newton
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
>>> : SUCCESS in 2m 34s
>>> - periodic-networking-midonet-python27-newton
>>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
>>> : FAILURE in 3m 57s
>>>
>>> ___
>>> Openstack-stable-maint mailing list
>>> openstack-stable-ma...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>>>
>>>
>

__
OpenStack Development Mailing 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] [magnum-ui][horizon] use json-schema-form on workflow

[Shuu Mutou]

Hi Thai,

We're trying to use json-schema-form in workflow, but 'required' attribute 
doesn't work. So we can push 'create' button without input. Could you check 
following patch?

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

best regards, 
Shu Muto


__
OpenStack Development Mailing 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][networking-midonet] [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

[Ihar Hrachyshka]

> On 25 Nov 2016, at 05:26, Takashi Yamamoto  wrote:
> 
> hi,
> 
> networking-midonet doesn't have stable/newton branch yet.
> newton jobs failures are false alarms.
> 
> branching has been delayed because development of some futures
> planned for newton has not been completed yet.
> 
> the plan is to revert ocata-specific changes after branching newton.

I don’t think it’s a good idea since you will need to tag a release on branch 
creation, that is supposed to be compatible with next releases in that same 
branch.

> 
> On Fri, Nov 25, 2016 at 9:14 AM, Ihar Hrachyshka  wrote:
>> Hi,
>> 
>> could anyone from the midonet subproject take ownership of repo stable
>> branches? Newton branch is broken for weeks with no apparent actions from
>> the core team side.
>> 
>> Begin forwarded message:
>> 
>> From: "A mailing list for the OpenStack Stable Branch test reports."
>> 
>> Subject: [Openstack-stable-maint] Stable check of
>> openstack/networking-midonet failed
>> Date: 24 November 2016 at 07:11:42 GMT+1
>> To: openstack-stable-ma...@lists.openstack.org
>> Reply-To: openstack-dev@lists.openstack.org
>> 
>> Build failed.
>> 
>> - periodic-networking-midonet-docs-liberty
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
>> : SUCCESS in 4m 58s
>> - periodic-networking-midonet-python27-liberty
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
>> : SUCCESS in 9m 57s
>> - periodic-networking-midonet-docs-mitaka
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
>> : SUCCESS in 2m 19s
>> - periodic-networking-midonet-python27-mitaka
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
>> : SUCCESS in 7m 06s
>> - periodic-networking-midonet-docs-newton
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
>> : SUCCESS in 2m 34s
>> - periodic-networking-midonet-python27-newton
>> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
>> : FAILURE in 3m 57s
>> 
>> ___
>> Openstack-stable-maint mailing list
>> openstack-stable-ma...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>> 
>> 


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