Re: [openstack-dev] [gnocchi] influxdb driver gate error

[Mehdi Abaakouk]

Le 2016-11-30 08:06, Sam Morrison a écrit :

2016-11-30 06:50:14.969302 | + pifpaf -e GNOCCHI_STORAGE run influxdb
-- pifpaf -e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox.sh
2016-11-30 06:50:17.399380 | ERROR: pifpaf: 'ascii' codec can't decode
byte 0xc2 in position 165: ordinal not in range(128)
2016-11-30 06:50:17.415485 | ERROR: InvocationError:
'/home/jenkins/workspace/gate-gnocchi-tox-db-py27-mysql-ubuntu-xenial/run-tests.sh’


You can temporary pass '--debug' to pifpaf to get the full backtrace.

Cheers,

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] [gnocchi] influxdb driver gate error

[Sam Morrison]

Have been working on my influxdb driver [1] and have managed to figure out the 
gate to get it to install the deps ect. Now I just get this cryptic error

2016-11-30 06:50:14.969302 | + pifpaf -e GNOCCHI_STORAGE run influxdb -- pifpaf 
-e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox.sh 
2016-11-30 06:50:17.399380 | ERROR: pifpaf: 'ascii' codec can't decode byte 
0xc2 in position 165: ordinal not in range(128) 
2016-11-30 06:50:17.415485 | ERROR: InvocationError: 
'/home/jenkins/workspace/gate-gnocchi-tox-db-py27-mysql-ubuntu-xenial/run-tests.sh’

Full logs at 
http://logs.openstack.org/60/390260/8/check/gate-gnocchi-tox-db-py27-mysql-ubuntu-xenial/42da72d/console.html

Anyone have an idea what is going on here? I can’t replicate on my machine.

Cheers,
Sam


[1] https://review.openstack.org/#/c/390260/






__
OpenStack Development Mailing 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] "tempest.lib.common.ssh AuthenticationException: Authentication failed." error when run“tempest.api.compute.servers.test_create_server.ServersTestJSON.test_host_name_is_same_as_server_

[李冰]

Hello~ Anyone would concern:

We are running the API tests on our cloud with the refstack-client tool. We 
have prepared the prerequisites required by the official guide. 
However, the results reported the “tempest.lib.common.ssh 
AuthenticationException: Authentication failed.” error and the test for 
“tempest.api.compute.servers.test_create_server.ServersTestJSON.test_host_name_is_same_as_server_name”
 Failed.

We have googled this problem but no useful solutions are found. Would anyone 
pay attention on our problem and give some advices to solve the error ?

My openstack is Icehouse version,

#nova-manage version

2014.1.3

The official refstack-client guide we refer to is 
https://github.com/openstack/refstack-client.

More details related to the error are followings:

1、Execute compute cases

# ./refstack-client test -c ~/refstack-client/.tempest/etc/tempest.conf -v -- 
tempest.api.compute.servers.test_create_server.ServersTestJSON.test_host_name_is_same_as_server_name

2、The test output

==

Failed 1 tests - output below:

==

 

tempest.api.compute.servers.test_create_server.ServersTestJSON.test_host_name_is_same_as_server_name[id-ac1ad47f-984b-4441-9274-c9079b7a0666]

-

 

Captured traceback:

~~~

Traceback (most recent call last):

  File 
"/root/refstack-client/.tempest/tempest/api/compute/servers/test_create_server.py",
 line 139, in test_host_name_is_same_as_server_name

self.assertTrue(linux_client.hostname_equals_servername(self.name))

  File 
"/root/refstack-client/.tempest/tempest/common/utils/linux/remote_client.py", 
line 104, in hostname_equals_servername

actual_hostname = self.exec_command("hostname").rstrip()

  File 
"/root/refstack-client/.tempest/tempest/common/utils/linux/remote_client.py", 
line 55, in wrapper

six.reraise(*original_exception)

  File 
"/root/refstack-client/.tempest/tempest/common/utils/linux/remote_client.py", 
line 36, in wrapper

return function(self, *args, **kwargs)

  File 
"/root/refstack-client/.tempest/tempest/common/utils/linux/remote_client.py", 
line 92, in exec_command

return self.ssh_client.exec_command(cmd)

  File "/root/refstack-client/.tempest/tempest/lib/common/ssh.py", line 
118, in exec_command

ssh = self._get_ssh_connection()

  File "/root/refstack-client/.tempest/tempest/lib/common/ssh.py", line 88, 
in _get_ssh_connection

password=self.password)

tempest.lib.exceptions.SSHTimeout: Connection to the 10.20.14.210 via SSH 
timed out.

User: root, Password: L7%Md%~Ms_IPk^y

Captured pythonlogging:

~~~

2016-11-30 13:54:45,569 8867 INFO [tempest.lib.common.ssh] Creating ssh 
connection to '10.20.14.210' as 'root' with public key authentication

2016-11-30 13:55:16,911 8867 INFO [paramiko.transport] Connected 
(version 2.0, client OpenSSH_5.3)

2016-11-30 13:55:28,209 8867 INFO [paramiko.transport] Authentication 
(publickey) failed.

2016-11-30 13:55:30,143 8867 INFO [paramiko.transport] Authentication 
(password) failed.

2016-11-30 13:55:30,167 8867 WARNING  [tempest.lib.common.ssh] Failed to 
establish authenticated ssh connection to root@10.20.14.210 (Authentication 
failed.). Number attempts: 1. Retry after 2 seconds.

2016-11-30 13:55:32,683 8867 INFO [paramiko.transport] Connected 
(version 2.0, client OpenSSH_5.3)

2016-11-30 13:55:42,812 8867 INFO [paramiko.transport] Authentication 
(publickey) failed.

2016-11-30 13:55:45,175 8867 INFO [paramiko.transport] Authentication 
(password) failed.

2016-11-30 13:55:45,187 8867 WARNING  [tempest.lib.common.ssh] Failed to 
establish authenticated ssh connection to root@10.20.14.210 (Authentication 
failed.). Number attempts: 2. Retry after 3 seconds.

2016-11-30 13:55:48,703 8867 INFO [paramiko.transport] Connected 
(version 2.0, client OpenSSH_5.3)

2016-11-30 13:55:58,798 8867 INFO [paramiko.transport] Authentication 
(publickey) failed.

2016-11-30 13:56:00,883 8867 INFO [paramiko.transport] Authentication 
(password) failed.

2016-11-30 13:56:00,905 8867 WARNING  [tempest.lib.common.ssh] Failed to 
establish authenticated ssh connection to root@10.20.14.210 (Authentication 
failed.). Number attempts: 3. Retry after 4 seconds.

……（The same log messages repeat several times） 

3.Compute and validation configuration section in tempest.conf file

[compute]

image_ref = c02e19e0-dee2-4d71-bb6b-3246475cd2e9

image_ref_alt = be289150-38ac-41b9-9eb3-bdd27f0ea8bc

flavor_ref = 2

flavor_ref_alt = 4

fixed_network_name = net4

region = RegionOne

endpoint_type = adminURL

[compute-feature-enabled]

allow_port_security_disabled = true

disk_config = true

resize = true

shelve = 

[openstack-dev] [vitrage] entity_type in make_pickleable

[Yujun Zhang]

Several properties are added to entity in `DriverBase.make_pickleable`[1]
but the existence check is only applied in `_add_entity_type`.

I think it may not be necessary after we prepended vitrage namespace[2]. I
could not think of a scenario to let user shadow the built-in `entity_type`.

Is there any particular reason for keeping it? Or should we remove it?

@staticmethod
def _add_entity_type(entity, entity_type):
if DSProps.ENTITY_TYPE not in entity:
entity[DSProps.ENTITY_TYPE] = entity_type


[1]:
https://github.com/openstack/vitrage/blob/master/vitrage/datasources/driver_base.py#L54

[2]: https://review.openstack.org/#/c/399417/
__
OpenStack Development Mailing 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] [tacker] Weekly meeting time slot - doodle poll

[Sridhar Ramaswamy]

Given the natural changes in the mix of our active members and the recent
daylight savings time change, I'm opening a doodle poll to find the best
slot for our weekly meeting with max coverage. Please respond to the doodle
poll below,

http://doodle.com/poll/ee9p34kfhskd2ucc

Note, this is the same poll shared in today's weekly meeting, though I've
added more timeslots to pick from. If you've already responded, please log
back one more time and select all possible slots.

thanks,
Sridhar
__
OpenStack Development Mailing 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] [ALU] [vitrage] common vs utils

[Yujun Zhang]

Ready for review

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

On Mon, Nov 28, 2016 at 5:50 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Sounds good to me J
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Monday, November 28, 2016 10:43 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] common vs utils
>
>
>
> Currently, we have `common/utils.py`, `common/file_utils.py` and an empty
> module `utils` in `vitrage`.
>
>
>
> In my understanding, `common` means *common to vitrage package* and utils
> are more *general purpose utility* functions.
>
>
>
> Would it better that we move `utils.py`, `file_utils.py` and
> `datetime_utils.py` to `utils`?
>
>
>
> --
>
> Yujun
> __
> OpenStack Development Mailing 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] [kolla] Kolla-ansible is available

[Steven Dake (stdake)]

It’s not really about easy or hard.

We don’t want to make the gating less optimal then it was pre-repo split.  To 
achieve that objective, cross-repo gating is necessary to validate the images 
in the docker repo are correct wrt the orchestration system they were developed 
against originally (which has moved off into the kolla-ansible repository).

Hope that clears it up.

Regards
-steve

-Original Message-
From: Joshua Harlow 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, November 29, 2016 at 11:28 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] Kolla-ansible is available

I would expect nothing less, things that are worthwhile doing are 
usually not just (always) easy :)

Jeffrey Zhang wrote:
> If we can implement loose coupling, there will be optimal. But
> it is hard to do this.
>
> On Tue, Nov 29, 2016 at 2:50 PM, Joshua Harlow  > wrote:
>
> Jeffrey Zhang wrote:
>
> Because the role and dockerfile are tight couplings.
>
> For example, the container/Dockerfile may need an environment
> variable
> passed by ansible role. without it, the service may not work.
>
>
> Why do they need to be tightly coupled?
>
>
>
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Steven Dake (stdake)]

+1 from me ☺

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, November 29, 2016 at 9:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [kolla] Vote to add zhubingbing to core team

Hello team!

I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
core teams. He did great job reviewing code during last couple of
months.

Consider this proposal +1 from me, voting will be open for 1 week
(until Dec 6) or if we get unanimous agreement (or veto) before.

Regards,
Michal

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


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

[openstack-dev] [charms] Barbican + Identity Standalone - AWS

[James Beedy]

Another great day of Juju driven successes - deploying the barbican
standalone stack for identity mgmt and secrets mgmt. For those that don't
know, newton horizon brings support for identity only! This means you can
(as I am) use the openstack-dashboard for mgmt of just users, projects, and
domains, without a full Openstack! In previous Openstack releases, if you
hooked up horizon and you didn't have the core Openstack services
registered in your service catalogue, horizon would throw errors and would
be unusable. This is a huge win for those wanting object storage and
identity mgmt only, too!

AWS Barbican Stack -> http://paste.ubuntu.com/23556001/

LXD Barbican Bundle (with script to help get started setting secrets in
barbican)-> https://github.com/jamesbeedy/juju-barbican-lxd-bundle

Also, here's a utility function from barbican-client layer I've been using
to make getting secrets from barbican containers easy for charms (WIP) ->
https://github.com/jamesbeedy/juju-layer-barbican-client/blob/master/lib/charms/layer/barbican_client.py

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

I left a comment on one of the changes; after you take care of that I'll
take a closer look at the code.  Let me know if you have questions.

Tim

On Tue, Nov 29, 2016 at 4:06 AM Ruben 
wrote:

> Hi Tim,
> I've added the code of magnum_driver and its unit test to review.
> It seems everything works.
>
> Ruben
>
> - Original Message -
> From: "Tim Hinrichs" 
> To: "Ruben" 
> Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" <
> timothy.l.hinri...@gmail.com>
> Sent: Saturday, November 26, 2016 12:48:12 AM
> Subject: Re: [Congress] Magnum_driver
>
> 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'
> > > 

Re: [openstack-dev] Suspected SPAM - Re: Suspected SPAM - [vitrage] datasources terminology

[Yujun Zhang]

LGTM

On Tue, Nov 29, 2016 at 6:38 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Sounds good to me :)
>
> From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com]
> Sent: Tuesday, November 29, 2016 11:23 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Suspected SPAM - Re: [openstack-dev] Suspected SPAM - [vitrage]
> datasources terminology
>
> Hi,
>
> A new suggestion:
>
> • event_type: the type of event/notification that comes from the
> datasource. For example: ‘compute.instance.delete.end’,
>  ‘volume.detach.start’
> • graph_action: used to tell the evaluator what to do with the entity -
> create, update or delete it.
> • datasource_action: the type of action that was performed by the driver:
> init_snapshot, snapshot or update.
>
> What do you think?
> Ifat.
>
>
> From: "Afek, Ifat (Nokia - IL)"
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Tuesday, 29 November 2016 at 09:26
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Suspected SPAM - [openstack-dev] [vitrage] datasources terminology
>
> Hi,
>
> I think we have a confusing terminology in Vitrage datasources.
>
> The following parameters are used in the drivers and transformers:
> • event_type: the type of event/notification that comes from the
> datasource. For example: ‘compute.instance.delete.end’,
>  ‘volume.detach.start’
> • event_action: used to tell the evaluator what to do with the entity -
> create, update or delete it.
> • action_type: the type of action that was performed by the driver:
> init_snapshot, snapshot or update.
>
> Personally I find these names very confusing.
> My suggestion is to rename action_type to datasource_mode, or something
> similar.
>
> Your thoughts?
>
> Thanks,
> Ifat.
>
> __
> OpenStack Development Mailing 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][ptls][tc][goals] community goals for Pike

[Jeremy Stanley]

On 2016-11-29 19:39:03 -0500 (-0500), Emilien Macchi wrote:
[...]
> -  we expected all teams to respond to all goals, even if they have no
> work to do. Should we continue that way?
[...]

While it struck me as a possible source of "busy work" at first, I
now see that otherwise it can be quite challenging to determine
whether a team doesn't acknowledge a goal because it doesn't apply
to them or because they don't even know about it/didn't check. Maybe
we could be more clear about the "why" behind some of the
expectations with this process rather than focusing entirely on the
"how."
-- 
Jeremy Stanley

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

[openstack-dev] [all][ptls][tc][goals] community goals for Pike

[Emilien Macchi]

A few months ago, our community started to find and work on
OpenStack-wide goals to "achieve visible common changes, push for
basic levels of consistency and user experience, and efficiently
improve certain areas where technical debt payments have become too
high – across all OpenStack projects".

http://governance.openstack.org/goals/index.html

We started to define a first Goal in Ocata (Remove Copies of Incubated
Oslo Code) and we would like to move forward in Pike.
I see 3 actions we could take now:

1) Collect feedback of our first iteration of Community Goals in
OpenStack during Ocata. What went well? What was more challenging?

Some examples:
- should we move the goal documents into a separate repo to allow a
shorter review time, where we could just have 2 TC members approve
them instead of waiting a week?
-  we expected all teams to respond to all goals, even if they have no
work to do. Should we continue that way?
- should we improve the guidance to achieve Goals?

I created an etherpad if folks want to give feedback:
https://etherpad.openstack.org/p/community-goals-ocata-feedback

2) Goals backlog - https://etherpad.openstack.org/p/community-goals
- new Goals are highly welcome.
- each Goal would be achievable in one cycle, if not I think we need
to break it down into separated Goals (with connections).
- some Goals already have a team (ex: Python 3) but some haven't.
Maybe could we dress a list of people able to step-up and volunteer to
help on these ones.
- some Goals might require some documentation for how to achieve it.

I think for now 2) can be discussed on the etherpad, though feel free
to propose another channel.

3) Choose Goals for Pike.
Some of us already did, but we might want to start looking at what
Goals we would like to achieve during Pike cycle.
I was thinking at giving a score to the Goals, that could be
calculated by its priority (I know it's vague but we know what is
really urgent for us versus what can wait 6 months); but also the
number of people who are interested to contribute on a Goal (if this
Goal doesn't have a team yet).
For now, openstack/governance is the repository for Goals, please
propose them here.


Please give feedback, we're doing iterations here, and hopefully we'll
improve our Community Goals over the next cycles.
Thanks for your time,
-- 
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] [magnum-ui][horizon] use json-schema-form on workflow

[Shuu Mutou]

Thanks Rob. Pretty good! We have confirmed 'tabs' type is same look and feel as 
previous Workflow Service.


> -Original Message-
> From: Rob Cresswell [mailto:robert.cressw...@outlook.com]
> Sent: Friday, November 25, 2016 5:39 PM
> To: OpenStack Dev Mailer 
> Subject: Re: [openstack-dev] [magnum-ui][horizon] use json-schema-form on
> workflow
> 
> 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] broken linuxbridge gate

[Armando M.]

On 29 November 2016 at 15:46, Armando M.  wrote:

> Hi folks,
>
> A recent devstack set of changes [0,1] accidentally broke the linuxbridge
> job in that bridge_mappings are no longer applied correct. To add insult to
> injury, this got applied to both stable and master (with the stable fix
> landing first). See [2,3] for a difference.
>
> This is not the first time we accidentally break the job, therefore I
> would like to suggest that we add it to the devstack check queue. The job
> was is on the experimental queue but it's hardly exercised.
>
> Armando
>
> [0] https://review.openstack.org/#/c/404477/
> [1] https://review.openstack.org/#/c/400258/
> [2] http://logs.openstack.org/99/360799/37/check/gate-tempest-
> dsvm-neutron-linuxbridge-ubuntu-xenial/7a8736b/logs/
> etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
> [3] http://logs.openstack.org/13/397913/8/gate/gate-tempest-
> dsvm-neutron-linuxbridge-ubuntu-xenial/3a7c298/logs/
> etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
>


Just to follow up:

I attempted both a revert [1,2] and a possible fix [3,4]. Either way, I
proposed moving the job to the devstack check/gate queue [5].

[1] https://review.openstack.org/#/c/404480/
[2] https://review.openstack.org/#/c/404477/
[3] https://review.openstack.org/#/c/404482/
[4] https://review.openstack.org/#/c/404484/
[5] https://review.openstack.org/#/c/404480/
__
OpenStack Development Mailing 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] broken linuxbridge gate

[Armando M.]

Hi folks,

A recent devstack set of changes [0,1] accidentally broke the linuxbridge
job in that bridge_mappings are no longer applied correct. To add insult to
injury, this got applied to both stable and master (with the stable fix
landing first). See [2,3] for a difference.

This is not the first time we accidentally break the job, therefore I would
like to suggest that we add it to the devstack check queue. The job was is
on the experimental queue but it's hardly exercised.

Armando

[0] https://review.openstack.org/#/c/404477/
[1] https://review.openstack.org/#/c/400258/
[2]
http://logs.openstack.org/99/360799/37/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/7a8736b/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
[3]
http://logs.openstack.org/13/397913/8/gate/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/3a7c298/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-29 21:52:35 +:
> On 2016-11-29 13:40:56 -0800 (-0800), Clint Byrum wrote:
> > Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
> [...]
> > > I also feel very strongly that those alone would be terrible reasons
> > > to consider becoming an official project team under the governance
> > > of the OpenStack Technical Committee. Our project governance is not
> > > intended as a means of marketing and advertising products, and I'm
> > > going to do my best to make sure that it's extremely ineffective at
> > > that for any companies who try to (ab)use it to those ends.
> > 
> > This struck me as overly aggressive. Open Source is a social model, and
> > if a commercial entity would like to participate in that social model
> > in good faith, I think that's beneficial to everyone else. Throwing
> > up a "not for commercial use" barrier to their participation will just
> > discourage them and others from investing more.
> 
> Thanks, it was not at all my intent to be aggressive towards Sam and
> I neglected to state that I agree the first part of his reply (which
> I had trimmed) was a fine set of reasons to seek becoming an
> official OpenStack project team. So sorry, Sam (and everyone else)!
> 
> It was however my intent to be aggressive in defending our use of
> project governance for actually governing the direction of
> OpenStack, and I don't want to see it perverted into a product
> marketing platform. We need better ways to help vendors advertise
> their driver support without bringing the TC into the picture as a
> deciding body. It's more work for the TC, and it gets in the way of
> what everyone actually wants to accomplish.

Thanks for clarifying Jeremy. :)

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 13:40:56 -0800 (-0800), Clint Byrum wrote:
> Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
[...]
> > I also feel very strongly that those alone would be terrible reasons
> > to consider becoming an official project team under the governance
> > of the OpenStack Technical Committee. Our project governance is not
> > intended as a means of marketing and advertising products, and I'm
> > going to do my best to make sure that it's extremely ineffective at
> > that for any companies who try to (ab)use it to those ends.
> 
> This struck me as overly aggressive. Open Source is a social model, and
> if a commercial entity would like to participate in that social model
> in good faith, I think that's beneficial to everyone else. Throwing
> up a "not for commercial use" barrier to their participation will just
> discourage them and others from investing more.

Thanks, it was not at all my intent to be aggressive towards Sam and
I neglected to state that I agree the first part of his reply (which
I had trimmed) was a fine set of reasons to seek becoming an
official OpenStack project team. So sorry, Sam (and everyone else)!

It was however my intent to be aggressive in defending our use of
project governance for actually governing the direction of
OpenStack, and I don't want to see it perverted into a product
marketing platform. We need better ways to help vendors advertise
their driver support without bringing the TC into the picture as a
deciding body. It's more work for the TC, and it gets in the way of
what everyone actually wants to accomplish.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

[Morales, Victor]

It’s sad to read this, I’m still digesting some of your articles of your blog.  
Thanks for all of those years of making OpenStack Quantum/Neutron better.

Regards,
Victor Morales



On 11/28/16, 12:58 PM, "Assaf Muller"  wrote:

>Hi all,
>
>For the past few months I've been gaining more responsibilities within
>Red Hat. I have less time to dedicate to personal contribution and
>it's had a considerable tole on my ability to perform my duties
>upstream to the degree of effectiveness I am satisfied with. To that
>end, I've decided that the right thing to do is to hand over my
>testing lieutenant responsibilities to Jakub Libosvar, and to step
>down from the core and drivers team.
>
>This is a bitter sweet moment. I'm enormously proud to see the
>progress Neutron as a platform, community and as a reference
>implementation have made over the last 3 years and I'm thrilled to
>have taken part in that. It's grown from an experiment to a ubiquitous
>OpenStack project with a proven, robust and scalable
>batteries-included implementation used at the largest retail,
>insurance, banking, web and telco (And more!) companies in the world.
>My focus will remain on OpenStack networking but my contributions will
>be indirect through my amazing team members. The people leading
>Quantum when I joined are nearly all gone and luckily we've seen a
>continuous influx of fresh talent ready to take over leadership
>responsibilities. I'm confident the wheel will keep on spinning and
>the project will continue stepping down the right path.
>
>I'll still be on IRC and I'll be working over the upcoming couple of
>weeks to hand off any specific tasks I had going on. Have fun folks.
>
>__
>OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
> On 2016-11-29 21:00:06 + (+), Sam Betts (sambetts) wrote:
> [...]
> > Additionally, being “official” indicates a level of maturity which
> > benefits us as a project by improving the public perception of our
> > drivers, and also indicates to OpenStack users that OpenStack
> > itself is mature and has support for existing technologies and
> > physical equipment out of the box. We want to make the Cisco
> > drivers visible/discoverable so that operators evaluating
> > OpenStack for their use cases will easily be able to know if a
> > driver for their equipment exists without digging around in git
> > repos.
> > 
> > In our current state (not an official project or under an official
> > project) we can’t publish our existence, releases or docs to any
> > official location on *.openstack.org which makes it difficult for
> > those new to OpenStack to know we exist, or find any information
> > on how to deploy/use Cisco equipment with OpenStack.
> 
> [Please trim quoted material and avoid top-posting.]
> 
> Would better visibility for
> https://www.openstack.org/marketplace/drivers/ (perhaps with a more
> navigable UI and updated for the latest release) address those
> concerns? I absolutely want service teams to have a mechanism by
> which they can list known working/supported drivers in an
> official-looking place so vendors can point their customers at that.
> 
> I also feel very strongly that those alone would be terrible reasons
> to consider becoming an official project team under the governance
> of the OpenStack Technical Committee. Our project governance is not
> intended as a means of marketing and advertising products, and I'm
> going to do my best to make sure that it's extremely ineffective at
> that for any companies who try to (ab)use it to those ends.

This struck me as overly aggressive. Open Source is a social model, and
if a commercial entity would like to participate in that social model
in good faith, I think that's beneficial to everyone else. Throwing
up a "not for commercial use" barrier to their participation will just
discourage them and others from investing more.

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Sam Betts (sambetts)'s message of 2016-11-29 21:00:06 +:
> There are a couple of reasons we want to become an official OpenStack project.
> 
> From a project perspective, we want to be recognized that the project isn’t 
> just a “public source” repo for Cisco’s drivers but is a community driven 
> open source project for supporting Cisco hardware/software and we want to 
> encourage community members that are using Cisco equipment to participate 
> with us contributing to and helping improve the drivers.

Thanks, Sam. This is the spirit I think we should be encouraging for all
projects.

Doug

> 
> Additionally, being “official” indicates a level of maturity which benefits 
> us as a project by improving the public perception of our drivers, and also 
> indicates to OpenStack users that OpenStack itself is mature and has support 
> for existing technologies and physical equipment out of the box. We want to 
> make the Cisco drivers visible/discoverable so that operators evaluating 
> OpenStack for their use cases will easily be able to know if a driver for 
> their equipment exists without digging around in git repos. 
> 
> In our current state (not an official project or under an official project) 
> we can’t publish our existence, releases or docs to any official location on 
> *.openstack.org which makes it difficult for those new to OpenStack to know 
> we exist, or find any information on how to deploy/use Cisco equipment with 
> OpenStack.
> 
> Sam

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[gordon chung]

On 29/11/16 03:53 PM, Jeremy Stanley wrote:
> Perhaps they wanted to publish documentation to the
> docs.openstack.org site? That's traditionally only been allowed by
> the Docs team for official project deliverables.

that's probably it, i just couldn't find their docs.

from our experience, we don't really have any issues with their driver 
being in a separate project under our umbrella. probably biggest concern 
is that we don't actively track the powervm project so we honestly don't 
know know its current status (or at least i don't). we currently just 
say 'do your own research' regarding anything managed by a separate team 
which may or may not be the best answer.

cheers,
-- 
gord

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 21:00:06 + (+), Sam Betts (sambetts) wrote:
[...]
> Additionally, being “official” indicates a level of maturity which
> benefits us as a project by improving the public perception of our
> drivers, and also indicates to OpenStack users that OpenStack
> itself is mature and has support for existing technologies and
> physical equipment out of the box. We want to make the Cisco
> drivers visible/discoverable so that operators evaluating
> OpenStack for their use cases will easily be able to know if a
> driver for their equipment exists without digging around in git
> repos.
> 
> In our current state (not an official project or under an official
> project) we can’t publish our existence, releases or docs to any
> official location on *.openstack.org which makes it difficult for
> those new to OpenStack to know we exist, or find any information
> on how to deploy/use Cisco equipment with OpenStack.

[Please trim quoted material and avoid top-posting.]

Would better visibility for
https://www.openstack.org/marketplace/drivers/ (perhaps with a more
navigable UI and updated for the latest release) address those
concerns? I absolutely want service teams to have a mechanism by
which they can list known working/supported drivers in an
official-looking place so vendors can point their customers at that.

I also feel very strongly that those alone would be terrible reasons
to consider becoming an official project team under the governance
of the OpenStack Technical Committee. Our project governance is not
intended as a means of marketing and advertising products, and I'm
going to do my best to make sure that it's extremely ineffective at
that for any companies who try to (ab)use it to those ends.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Sam Betts (sambetts)]

There are a couple of reasons we want to become an official OpenStack project.

From a project perspective, we want to be recognized that the project isn’t 
just a “public source” repo for Cisco’s drivers but is a community driven open 
source project for supporting Cisco hardware/software and we want to encourage 
community members that are using Cisco equipment to participate with us 
contributing to and helping improve the drivers.

Additionally, being “official” indicates a level of maturity which benefits us 
as a project by improving the public perception of our drivers, and also 
indicates to OpenStack users that OpenStack itself is mature and has support 
for existing technologies and physical equipment out of the box. We want to 
make the Cisco drivers visible/discoverable so that operators evaluating 
OpenStack for their use cases will easily be able to know if a driver for their 
equipment exists without digging around in git repos. 

In our current state (not an official project or under an official project) we 
can’t publish our existence, releases or docs to any official location on 
*.openstack.org which makes it difficult for those new to OpenStack to know we 
exist, or find any information on how to deploy/use Cisco equipment with 
OpenStack.

Sam

On 28/11/2016, 19:14, "Jay Pipes"  wrote:

On 11/28/2016 01:33 PM, Doug Hellmann wrote:
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"

These questions are to the Cisco networking team.

What value do *you* think you derive from being an official OpenStack 
project team?

What value do you believe OpenStack *users* would get from you being an 
official OpenStack project team?

If you are *not* accepted as an official OpenStack project team, what 
actual impact would that have on OpenStack users, if any?

Thanks in advance for your answers.

Best,
-jay

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


__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 20:19:13 + (+), gordon chung wrote:
[...]
> i don't recall why they were moved to be officially under the Telemetry
> umbrella[3] but i remember they weren't allowed to do something if they
> weren't part of an 'official' project. if i could remember what it was
> this paragraph would be a lot more useful.
[...]

Perhaps they wanted to publish documentation to the
docs.openstack.org site? That's traditionally only been allowed by
the Docs team for official project deliverables.
-- 
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] Allowing Teams Based on Vendor-specific Drivers

[gordon chung]

On 29/11/16 01:24 PM, Doug Hellmann wrote:
> If we start by assuming that contributors may end up getting more
> value from seeming to be a part of the community than the community
> will get from their participation, and that we have to guard against
> that because it somehow diminishes us, it seems like we would be
> rejecting the notion of having an open community in the first place.
>
> Not every useful contribution is going to come from someone with
> the time to participate 100%, or even 50%, upstream.  Not every
> useful contribution is going to be code changes to the core components
> of a project.
>
> I know that our experience with third-party CI for some vendors has
> been poor in the past. I don't believe the answer is to tell all
> vendors to go away.
>
> As long as we clearly communicate to users how drivers are tested,
> and who owns failures, collaborating with vendors who only have the
> resources (or interest) to contribute a driver shouldn't be considered
> a burden. If they want more influence over the direction of a
> project, they need to participate at a level to make it possible for
> them to have that influence. In the mean time, I see no harm in making
> it possible for them to participate at the level of commitment they're
> ready to make.

i like this summary.

we had this issue in Ceilometer with our compute pollsters. we wanted to 
support polling from all the different hypervisors but obviously the 
members of the core team were not necessarily hypervisor experts. we 
were in the strange scenario where cores were reviewing stuff that we 
didn't necessarily understand. it also didn't really make sense to make 
someone a ceilometer core if all they wanted was a quick patch to 
capture a metric in one of the hypervisors.

with ceilometer-powervm[1], the IBM team wrote their own driver which 
matched our api requirements but they managed everything themselves in 
another project with the appropriate testing. we just added their 
project as an externally-managed project in our wiki.[2]

i don't recall why they were moved to be officially under the Telemetry 
umbrella[3] but i remember they weren't allowed to do something if they 
weren't part of an 'official' project. if i could remember what it was 
this paragraph would be a lot more useful.

[1] https://github.com/openstack/ceilometer-powervm
[2] https://wiki.openstack.org/wiki/Telemetry#Externally_Managed
[3] https://review.openstack.org/#/c/245894/

cheers,

-- 
gord

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Chris Friesen's message of 2016-11-29 11:55:30 -0600:
> On 11/29/2016 10:55 AM, Doug Hellmann wrote:
> 
> > I agree that clearly documenting who supports each driver, and how
> > tightly integrated that team is with the core team will be important.
> > That will be the case no matter what solution we pick (even saying
> > that drivers aren't official isn't going to avoid questions about
> > how well supported a driver is). I left the details of how to do
> > that up to the individual teams, since I know some are already
> > working on it.
> 
> For what it's worth, in the linux kernel there is a "MAINTAINERS" file which 
> documents who's in charge of each driver, any appropriate mailing lists, 
> source 
> code repositories, etc. That way people with questions about a driver can 
> communicate with the people involved with developing that driver.  The 
> overall 
> kernel maintainers make few statements about how well-supported any given 
> driver is.
> 
> Perhaps something like that could be used as a model.
> 
> Chris
> 

That does sound like a good starting point.

Doug

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

Re: [openstack-dev] [kolla] Kolla-ansible is available

[Joshua Harlow]

I would expect nothing less, things that are worthwhile doing are 
usually not just (always) easy :)


Jeffrey Zhang wrote:

If we can implement loose coupling, there will be optimal. But
it is hard to do this.

On Tue, Nov 29, 2016 at 2:50 PM, Joshua Harlow > wrote:

Jeffrey Zhang wrote:

Because the role and dockerfile are tight couplings.

For example, the container/Dockerfile may need an environment
variable
passed by ansible role. without it, the service may not work.


Why do they need to be tightly coupled?



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

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





--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me 

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Anita Kuno's message of 2016-11-29 12:37:21 -0500:
> On 2016-11-29 11:27 AM, Jeremy Stanley wrote:
> > I think we also need to look harder at the reasons for driver-only
> > developer teams seeking official status. If it's because they want
> > to be part of the community and help collaborate with the rest of
> > us, then as long as they can do that consistent with our overall
> > goals and ideals I think that's great and we should welcome them as
> > one of us. If the reason is because they feel it raises the profile
> > of their products within the OpenStack ecosystem or conveys an
> > implication of better OpenStack support on their platforms, then we
> > should work harder as a community to dispel that notion (even if it
> > means we need to actively sabotage the "tent" as a marketing
> > platform) and find other places for companies to advertise the level
> > of OpenStack support their customers should expect.
> 
> I think Jeremy raises a very important point here. What is the 
> motivation on the part of the driver-only teams?
> 
> I personally assumed far too much collaborative intent when I got 
> involved with supporting the path to third party testing for drivers. My 
> eyes have since been opened. While there are a few driver maintainers 
> that are motivated to be collaborative and help others (thank you so 
> much) they are far from the norm.
> 
> I've taken some time away from keyboard to navel gaze a bit and been 
> quite enjoying it. I've been able to think about some of the material 
> offered to us during the leadership training in June, particularly 
> thinking about groups that are successful in creating an environment of 
> collaboration. I found that one of the most important aspects of groups 
> that do create and maintain a collaborate atmosphere for all concerned 
> is the ability to ensure that all concerned are motivated to create a 
> collaborative environment. Businesses offered as case studies in the 
> literature provided by Zingermans, create a reciprocally beneficial 
> collaborative environment through rigorous filtering during interview 
> and selection processes as well as a commitment to help people move 
> along should it be evident that they are not motivated by collaborative 
> intent. OpenStack can't apply the process but it can align with the 
> spirit of the intent, should OpenStack continue to want to create a 
> collaborative environment for all concerned.
> 
> Some may feel excluded and that is their choice, as long as there is 
> always a door way in for those that make the choice of having their 
> actions motivated by collaboration for the benefit of all concerned.
> 
> Thank you,
> Anita.
> 

If we start by assuming that contributors may end up getting more
value from seeming to be a part of the community than the community
will get from their participation, and that we have to guard against
that because it somehow diminishes us, it seems like we would be
rejecting the notion of having an open community in the first place.

Not every useful contribution is going to come from someone with
the time to participate 100%, or even 50%, upstream.  Not every
useful contribution is going to be code changes to the core components
of a project.

I know that our experience with third-party CI for some vendors has
been poor in the past. I don't believe the answer is to tell all
vendors to go away.

As long as we clearly communicate to users how drivers are tested,
and who owns failures, collaborating with vendors who only have the
resources (or interest) to contribute a driver shouldn't be considered
a burden. If they want more influence over the direction of a
project, they need to participate at a level to make it possible for
them to have that influence. In the mean time, I see no harm in making
it possible for them to participate at the level of commitment they're
ready to make.

Doug

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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:
> On 29/11/16 10:28, Doug Hellmann wrote:
> > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
> >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
> >>> I'll rank my preferred solutions, because I don't actually like any of
> >>> them.
> >>
> >> Just curious...what would you "actually like"?
> >>
> >> Chris
> >>
> >
> > My preference is to have teams just handle the drivers voluntarily,
> > without needing to make it a rule or provide a way to have teams
> > that only work on a driver. That's not one of the options we proposed,
> > but the results are like what we would get with option 6 (minus the
> > precedent of the TC telling teams what code they must manage).
> 
> I don't have a lot of background on why the driver was removed from the 
> Neutron stadium, but reading between the lines it sounds like you think 
> that Neutron made the Wrong Call, and that you would like, in order of 
> preference:
> 
> a) Neutron to start agreeing with you; or
> b) The TC to tell Neutron to agree with you; or

I hope I'm not the only one who thinks drivers are important?

I would prefer not to impose obligations on anyone. I wrote up that
option to explore what it would look like, not because I think it's
the best outcome.  At the same time, the current approach is actively
harmful to the overall health of the community by pushing away
contributors and useful contributions, especially considering the
different responses to vendor-related issues in other teams.  And
this does fall within the scope of issues and policies the TC is
meant to manage.

> c) To do an end run around Neutron by adding it as a separate project

I wouldn't categorize that last one as an end-run. We wouldn't be
adding the driver team to Neutron, we would be adding it to OpenStack.
The Neutron team would have no more responsibility for the output of
a driver team than they do anyone else.

> Individual projects (like Neutron) have pretty wide latitude to add 
> repositories if they want, and are presumably closer to the issues than 
> anyone. So it seems strange that we're starting with a discussion about 
> how to override their judgement, rather than one about why we think 
> that's necessary.

I did, in the original post, try to explain why I think it's necessary.

  The OpenStack community wants to encourage collaboration by
  emphasizing contributions to projects that abstract differences
  between vendor-specific products, while still empowering vendors
  to integrate their products with OpenStack through drivers that
  can be consumed by the abstraction layers

In addition to wanting collaboration between experts in a given
field, projects support drivers to give deployers choices. Encouraging
vendors to write drivers furthers both goals. It also encourages
those same vendors to be active in the community in other ways,
such as sponsoring events and the Foundation. Whether we achieve
*that* goal depends on a lot of factors, and we're more successful
with some vendors than others. Turning away contributions does not
encourage their participation in any way I can understand.

> What are the obstacles to the Neutron team agreeing to host these 
> drivers? Perhaps the TC is in a position to remove some of those 
> obstacles? That seems preferable to imposing new obligations on projects.

I'll let someone from the Neutron team fill in the details behind their
decision, because I don't want to misrepresent them.

Doug

> 
> cheers,
> Zane.
> 

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Chris Friesen]

On 11/29/2016 10:55 AM, Doug Hellmann wrote:


I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.


For what it's worth, in the linux kernel there is a "MAINTAINERS" file which 
documents who's in charge of each driver, any appropriate mailing lists, source 
code repositories, etc. That way people with questions about a driver can 
communicate with the people involved with developing that driver.  The overall 
kernel maintainers make few statements about how well-supported any given driver is.


Perhaps something like that could be used as a model.

Chris


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

[openstack-dev] Missing records in Glance "image_locations" table

[Sergio A. de Carvalho Jr.]

Hi everyone,

A while ago I reported some issues with Glance where image files went
missing from the file system. Since then we implemented a monitoring script
that regularly verifies the state of every active image in the Glance
database, checking that:
1) it has a corresponding record in the "image_locations" table;
2) it has an image file on the disk;
3) the size of the image file matches size information in the database.

As it turns out, over the last 5 weeks we observed several cases (55 images
across 7 different clusters) where an image was successfully uploaded to
the database and reached "active" state, although there was no record in
the "images_location" table. The impact of such inconsistencies is that any
attempt to boot a VM with these images result in obscure 500 errors to
clients as Glance fails to retrieve the image from the backend.

All these cluster are running Glance Icehouse (2014.1.3-2.el6) on CentOS
6.5, using the "file" backend store.

I haven't found any bug reports or anyone complaining of similar issues in
the community, so I'm curious to hear if anyone has ever experienced this
before. Looking at the occurrences in our clusters, it appears that the
problem is more likely to manifest itself when a high number of images are
being uploaded at the same time -- for instance, we recently had to upload
around 1700 images to 2 new clusters in one go and ended up with 23 images
missing "image_locations" in one cluster, and 25 in the other.

Thanks,

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

[openstack-dev] [nova] Status of imagebackend refactor patches

[Matthew Booth]

I'm continuing to work through updating the imagebackend refactor patches.
A bunch of them at the top of the queue already have +2 from jaypipes, who
expressed an interest in getting some of these merged. I think the
following could be ready to go (in order):

https://review.openstack.org/#/c/337159/  libvirt: Rewrite
_test_finish_migration [1]
https://review.openstack.org/#/c/338993/  libvirt: Test disk creation in
test_hard_reboot
https://review.openstack.org/#/c/339114/  libvirt: Cleanup
test_create_configdrive
https://review.openstack.org/#/c/333272/  libvirt: Rename Backend snapshot
and image [2]
https://review.openstack.org/#/c/331115/  libvirt: Never copy a swap disk
during cold migration
https://review.openstack.org/#/c/331118/  libvirt: Don't re-resize disks in
finish_migration() [3]

[1] This has -1 from melwitt, but I don't personally think this issue is
worth a respin. However, she mentioned on IRC that there may be more, so
that could be moot. Anyway, being the top of the queue this is obviously a
blocker.

[2] This doesn't have +2 from jaypipes, although it's uncontroversial and
uncomplicated. Hopefully just an oversight?

[3] This patch removes the function which melwitt identified in [1] lost
some test coverage, which is why I'm hoping not to respin for that.

I'll leave it there for the moment, because I need to talk through the next
patch with ftersin. It looks like it will require a release note at least,
if not a change.

If anybody would like to slog through some of the above and add a second +2
I'd be very grateful. There's plenty more in the queue after those!

Thanks,

Matt
-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Anita Kuno]

On 2016-11-29 11:27 AM, Jeremy Stanley wrote:

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.


I think Jeremy raises a very important point here. What is the 
motivation on the part of the driver-only teams?


I personally assumed far too much collaborative intent when I got 
involved with supporting the path to third party testing for drivers. My 
eyes have since been opened. While there are a few driver maintainers 
that are motivated to be collaborative and help others (thank you so 
much) they are far from the norm.


I've taken some time away from keyboard to navel gaze a bit and been 
quite enjoying it. I've been able to think about some of the material 
offered to us during the leadership training in June, particularly 
thinking about groups that are successful in creating an environment of 
collaboration. I found that one of the most important aspects of groups 
that do create and maintain a collaborate atmosphere for all concerned 
is the ability to ensure that all concerned are motivated to create a 
collaborative environment. Businesses offered as case studies in the 
literature provided by Zingermans, create a reciprocally beneficial 
collaborative environment through rigorous filtering during interview 
and selection processes as well as a commitment to help people move 
along should it be evident that they are not motivated by collaborative 
intent. OpenStack can't apply the process but it can align with the 
spirit of the intent, should OpenStack continue to want to create a 
collaborative environment for all concerned.


Some may feel excluded and that is their choice, as long as there is 
always a door way in for those that make the choice of having their 
actions motivated by collaboration for the benefit of all concerned.


Thank you,
Anita.

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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Zane Bitter]

On 29/11/16 10:28, Doug Hellmann wrote:

Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:

On 11/29/2016 08:03 AM, Doug Hellmann wrote:

I'll rank my preferred solutions, because I don't actually like any of
them.


Just curious...what would you "actually like"?

Chris



My preference is to have teams just handle the drivers voluntarily,
without needing to make it a rule or provide a way to have teams
that only work on a driver. That's not one of the options we proposed,
but the results are like what we would get with option 6 (minus the
precedent of the TC telling teams what code they must manage).


I don't have a lot of background on why the driver was removed from the 
Neutron stadium, but reading between the lines it sounds like you think 
that Neutron made the Wrong Call, and that you would like, in order of 
preference:


a) Neutron to start agreeing with you; or
b) The TC to tell Neutron to agree with you; or
c) To do an end run around Neutron by adding it as a separate project

Individual projects (like Neutron) have pretty wide latitude to add 
repositories if they want, and are presumably closer to the issues than 
anyone. So it seems strange that we're starting with a discussion about 
how to override their judgement, rather than one about why we think 
that's necessary.


What are the obstacles to the Neutron team agreeing to host these 
drivers? Perhaps the TC is in a position to remove some of those 
obstacles? That seems preferable to imposing new obligations on projects.


cheers,
Zane.

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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Jeffrey Zhang]

+1 nice work.

On Wed, Nov 30, 2016 at 12:43 AM, Paul Bourke 
wrote:

> +1
>
>
> On 29/11/16 16:21, Michał Jastrzębski wrote:
>
>> Hello team!
>>
>> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
>> core teams. He did great job reviewing code during last couple of
>> months.
>>
>> Consider this proposal +1 from me, voting will be open for 1 week
>> (until Dec 6) or if we get unanimous agreement (or veto) before.
>>
>> Regards,
>> Michal
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Vikram Hosakote (vhosakot)]

+1

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Michał Jastrzębski >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, November 29, 2016 at 11:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] Vote to add zhubingbing to core team

Hello team!

I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
core teams. He did great job reviewing code during last couple of
months.

Consider this proposal +1 from me, voting will be open for 1 week
(until Dec 6) or if we get unanimous agreement (or veto) before.

Regards,
Michal

__
OpenStack Development Mailing 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] [telemetry][ceilometer] let's talk about volume=1 meters (again)

[Julien Danjou]

On Tue, Nov 29 2016, gordon chung wrote:

> i'm not talking about bringing back the 'instance', 'volume', etc... 
> meters because they were measuring nothing (or it measured everything as 
> some giant, unintelligible, blob meter). there are also stuff like 
> .created|deleted 'meters' which are one off events only useful 
> at maybe a project level. that said, i think some of the identity 
> volume=1 meters we generated from keystone notifications might have a 
> use case which allowed you to maybe alarm when too many 
> 'identity.authenticate.failure' events were received in a given timespan.
>
> so my question is, it it worth taking a second look at volume=1 meters 
> or is this just a gap in our events api?

Those sound interesting, so I'd vote in favor of keeping such metrics. :)

-- 
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] [ptl][release] ocata release management communication

[Thierry Carrez]

Rob C wrote:
> I'm struggling to find good info on when the adjusted PTL nomination
> cycle starts.
> 
> I've checked here:
> https://releases.openstack.org/ocata/schedule.html#pike-ptls-self-nomination
> but it looks like the 'elections' section was supposed to be added to
> the table and wasn't.
> 
> I know from the updates to the charter that the elections should happen
> on or before R-3 but it doesn't provide any clarity on how much before
> then the nominations should be made?

Hi Rob,

I just proposed a change that covers this, assuming that we keep the
one-week nomination one-week election format:

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

That said, the charter built some flexibility for election officials to
organize elections (in terms of nomination and election periods), so
they should probably confirm that they will run the Pike PTL elections
under that two-week model again.

-- 
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] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-11-29 17:19:15 +0100:
> On 28/11/16 13:33 -0500, Doug Hellmann wrote:
> >5. Consider driver teams to be a completely different animal, defined
> >   in drivers.yaml instead of projects.yaml (grey option) [6]
> >
> >   This establishes drivers as second-order objects that are necessary
> >   for the success of the main projects, and for which requirements
> >   can be loosened. It would establish a new category of team without
> >   the level playing-field requirement and some of the other team
> >   requirements that seem not to apply to driver teams because they
> >   are essentially a public facet of a single vendor.
> >
> >6. A resolution requiring projects that consume drivers to host all
> >   proposed drivers. (red option) [7]
> >
> >   This would require teams with projects providing driver interfaces
> >   to also host, in some form, drivers from vendors that ask for
> >   hosting. The drivers would not need to be in the main project
> >   repo, but would need to be in a repository "owned" by the project
> >   team. Project teams would not be considered responsible for the
> >   quality of the resulting drivers.  Contributors to the driver
> >   repos would be considered part of the electorate for team PTL.
> 
> 
> These two are my preferred options so far. They both recognize drivers and 
> allow
> for this drivers to officially exist in the community. I like the idea of 
> having
> the drivers and services under the same team. I'd prefer them to have one PTL
> and for there to be more interactions between driver owners and the rest of 
> the
> service team.
> 
> One thing that worries me about #6, which #5 solves, is that it doesn't 
> clearly
> identify drivers. We've had problems in the past communicating the status of
> projects to other members, operators and end users. I'm worried that the 
> quality
> and stability of some of these drivers would affect a project's "reputation" 
> (so
> to speak). Proposal #6 says that project teams must host these drivers but 
> they
> are not really accountable for the drivers if they don't live in-tree (note 
> this
> could happen even for drivers that are in-tree).
> 
> The above is all to say that I'd feel more comfortable with proposal #6 if it
> would provide a way to communicate that these repos are drivers, that they are
> maintained by a subset of the bigger team, etc. This is something #5 solves by
> clearly saying that some driver teams are different. This separation is not 
> only
> useful from a community perspective but also for managing these 
> projects/repos.
> It allows for setting a new set of rules instead of adding exceptions to the
> existing ones.
> 
> What I don't like about #5 is that increases the complexity of the process for
> adding new projects and it may make communication between these teams more
> difficult. It will force the creation of tiny teams w/ all the things required
> for teams to exist (PTL elections, ATC management, extra ATC, and what not).
> 
> At this point I think I'm leaning more towards #5 because it acknowledges 
> these
> drivers are useful but they are essentially managed by a different team, which
> is something that #6 doesn't do.
> 
> I'll try to come up with some proposals to have #6 communicate this, unless it
> was left out on purpose.

I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.

Doug

> 
> Thank you all for working on this,
> Flavio
> 

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

Re: [openstack-dev] [kolla][kolla-ansible][kolla-kubernetes] Kolla core election policy change - vote

[Vikram Hosakote (vhosakot)]

+1

Regards,
Vikram Hosakote
IRC:  vhosakot

From: Mauricio Lima >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, November 16, 2016 at 5:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [kolla][kolla-ansible][kolla-kubernetes] Kolla 
core election policy change - vote

+1

2016-11-16 16:55 GMT-03:00 Ryan Hallisey 
>:
+1

-Ryan

- Original Message -
From: "Michał Jastrzębski" >
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Sent: Wednesday, November 16, 2016 1:23:27 PM
Subject: [openstack-dev] [kolla][kolla-ansible][kolla-kubernetes] Kolla core 
election policy change - vote

Hello,

In light of recent events (kolla-kubernetes becoming thriving project,
kolla-ansible being split) I feel we need to change of core reviewer
election process.

Currently Kolla was single core team. That is no longer the case, as
right now we have 3 distinct core teams (kolla, kolla-ansible and
kolla-kubernetes), although for now with big overlap in terms of
people in them.

For future-proofing, as we already have difference between teams, I
propose following change to core election process:


Core reviewer voting rights are reserved by core team in question.
Which means if someone propose core reviewer to kolla-kubernetes, only
kolla-kubernetes cores has a voting right (not kolla or kolla-ansible
cores).


Voting will be open until 30 Nov '16 end of day. Reviewers from all
core teams in kolla has voting rights on this policy change.

Regards
Michal

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

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

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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Paul Bourke]

+1

On 29/11/16 16:21, Michał Jastrzębski wrote:

Hello team!

I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
core teams. He did great job reviewing code during last couple of
months.

Consider this proposal +1 from me, voting will be open for 1 week
(until Dec 6) or if we get unanimous agreement (or veto) before.

Regards,
Michal

__
OpenStack Development Mailing 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][neutron-lbaas][octavia] Not be able to ping loadbalancer ip

[Michael Johnson]

Hi Wanjing,

1. Yes, active/standby uses VRRP combined with our stickyness table
sync between the amphora.  However, since some clouds have had issues
with multicast we have opted to use the unicast mode between the
amphora instances.
2. This is a good question that we have been working on.  Currently we
do not have a working solution for containers or bare metal, but we
would like to.  We are close with nova-lxd, but we have hit some bugs.
Likewise with bare metal, I would expect we could integrate with
ironic pretty easily, it just hasn't been something the team has
worked on yet.  This is an area the project needs more work/support.

Michael

On Mon, Nov 28, 2016 at 3:45 PM, Wanjing Xu (waxu)  wrote:
> Thanks Michael
>
> I still have the following questions:
> 1)  For active-standby, do the amphorae VM pair really communicate with each 
> other using vrrp protocol, like using multicast vrrp IP?
> 2)   How do we install/configure the Octavia so that amphorae instances are 
> spun as containers or on bare metal?
>
> Thanks!
>
> Wanjing
>
> On 11/10/16, 5:12 PM, "Michael Johnson"  wrote:
>
> Hi Wanjing,
>
> Yes, active/standby is available in Mitaka.  You must enable it via
> the octavia.conf file.
>
> As for benchmarking, there has been some work done in this space (see
> the octavia meeting logs last month), but it varies greatly depending
> on how your cloud is configured and/or the hardware it is on.
>
> Michael
>
> On Thu, Nov 10, 2016 at 3:18 PM, Wanjing Xu (waxu)  wrote:
> > Thanks, Michael.  Now I have brought up this octavia.  I have a 
> question:
> > Is HA supported on octavia, or is it yet to come?  I am using
> > stable/mitaka and I only see one amphorae vm launched per loadbalancer.
> > And did anybody benchmark this octtavia against vender box?
> >
> > Regards!
> >
> > Wanjing
> >
> > On 11/7/16, 10:02 AM, "Michael Johnson"  wrote:
> >
> >>Hi Wanjing,
> >>
> >>You are not seeing the network interfaces for the VIP and member
> >>networks because they are inside a network namespace for security
> >>reasons.  You can see these by issuing "sudo ip netns exec
> >>amphora-haproxy ifconfig -a".
> >>
> >>I'm not sure what version of octavia and neutron you are using, but
> >>the issue you noted about "dns_name" was fixed here:
> >>https://review.openstack.org/#/c/337939/
> >>
> >>Michael
> >>
> >>
> >>On Thu, Nov 3, 2016 at 11:29 AM, Wanjing Xu (waxu)  
> wrote:
> >>> Going through the log , I saw the following error on o-hm
> >>>
> >>> 2016-11-03 03:31:06.441 19560 ERROR
> >>> octavia.controller.worker.controller_worker 
> request_ids=request_ids)
> >>> 2016-11-03 03:31:06.441 19560 ERROR
> >>> octavia.controller.worker.controller_worker BadRequest: Unrecognized
> >>> attribute(s) 'dns_name'
> >>> 2016-11-03 03:31:06.441 19560 ERROR
> >>> octavia.controller.worker.controller_worker Neutron server returns
> >>> request_ids: ['req-1daed46e-ce79-471c-a0af-6d86d191eeb2']
> >>>
> >>> And it seemed that I need to upgrade my neutron client.  While I am
> >>>planning
> >>> to do it, could somebody please send me the document on how this vip 
> is
> >>> supposed to plug into the lbaas vm and what the failover is about ?
> >>>
> >>> Thanks!
> >>> Wanjing
> >>>
> >>>
> >>> From: Cisco Employee 
> >>> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)"
> >>> 
> >>> Date: Wednesday, November 2, 2016 at 7:04 PM
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> 
> >>> Subject: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able
> >>>to
> >>> ping loadbalancer ip
> >>>
> >>> So I bring up octavia using devstack (stable/mitaka).   I created a
> >>> loadbalander and a listener(not create member yet) and start to look 
> at
> >>>how
> >>> things are connected to each other.  I can ssh to amphora vm and I do
> >>>see a
> >>> haproxy is up with front end point to my listener.  I tried to ping
> >>>(from
> >>> dhcp namespace) to the loadbalancer ip, and ping could not go through.
> >>>I am
> >>> wondering how packet is supposed to reach this amphora vm.  I can see
> >>>that
> >>> the vm is launched on both network(lb_mgmt network and my vipnet), 
> but I
> >>> don¹t see any nic associated with my vipnet:
> >>>
> >>> ubuntu@amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699:~$ ifconfig -a
> >>> eth0  Link encap:Ethernet  HWaddr fa:16:3e:b4:b2:45
> >>>   inet addr:192.168.0.4  Bcast:192.168.0.255  
> Mask:255.255.255.0
> >>>   inet6 addr: 

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-28 13:33:56 -0500 (-0500), Doug Hellmann wrote:
[...]
> 1. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it effectively precludes official status
>for teams which only develop drivers for proprietary systems
>(hard black) [2]
[...]
> 2. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it does not necessarily preclude official
>status for teams which only develop drivers for proprietary
>systems (soft black) [3]
[...]
> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
[...]
> 4. A resolution and policy change loosening the "level playing field"
>requirement (soft white) [5]
[...]
> [2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
> [3] https://review.openstack.org/403836 - Driver development can be level
> [4] https://review.openstack.org/403838 - Stop requiring a level playing field
> [5] https://review.openstack.org/403839 - Level playing fields, except drivers
[...]

I proposed these because I have a strong preference not to bury the
problem in additional bureaucracy. Either we determine that we want
to recognize the developers writing drivers as an official part of
our community and need to reinterpret/adjust our policies because
they're in conflict with our intent, or we decide that the intent of
our policy necessarily precludes official recognition for driver
teams. Without addressing this issue at its source, we're sort of
avoiding addressing it at all.

I'm not really a fan of the more complex solutions proposed, since
they don't seem (to me) to address the fundamental issue. I feel
like the "Big Tent" only remains true to its design if we have one
kind of team in it. As soon as we begin to define second-class teams
that are still in some way "official" we're back to much of the same
conflict and tension which drove us to our current governance model
in the first place.

The scaling concerns from allowing too many "small" teams who only
develop drivers should be dealt with as a separate issue. There are
plenty of other small, single-affiliation developer teams working
within our community and I think whatever solutions we come up with
for scaling limited resources in the tent shouldn't single out
driver development as the cause.

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Mauricio Lima]

+1

2016-11-29 13:21 GMT-03:00 Michał Jastrzębski :

> Hello team!
>
> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> core teams. He did great job reviewing code during last couple of
> months.
>
> Consider this proposal +1 from me, voting will be open for 1 week
> (until Dec 6) or if we get unanimous agreement (or veto) before.
>
> Regards,
> Michal
>
> __
> OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Flavio Percoco]

On 28/11/16 13:33 -0500, Doug Hellmann wrote:

5. Consider driver teams to be a completely different animal, defined
  in drivers.yaml instead of projects.yaml (grey option) [6]

  This establishes drivers as second-order objects that are necessary
  for the success of the main projects, and for which requirements
  can be loosened. It would establish a new category of team without
  the level playing-field requirement and some of the other team
  requirements that seem not to apply to driver teams because they
  are essentially a public facet of a single vendor.

6. A resolution requiring projects that consume drivers to host all
  proposed drivers. (red option) [7]

  This would require teams with projects providing driver interfaces
  to also host, in some form, drivers from vendors that ask for
  hosting. The drivers would not need to be in the main project
  repo, but would need to be in a repository "owned" by the project
  team. Project teams would not be considered responsible for the
  quality of the resulting drivers.  Contributors to the driver
  repos would be considered part of the electorate for team PTL.



These two are my preferred options so far. They both recognize drivers and allow
for this drivers to officially exist in the community. I like the idea of having
the drivers and services under the same team. I'd prefer them to have one PTL
and for there to be more interactions between driver owners and the rest of the
service team.

One thing that worries me about #6, which #5 solves, is that it doesn't clearly
identify drivers. We've had problems in the past communicating the status of
projects to other members, operators and end users. I'm worried that the quality
and stability of some of these drivers would affect a project's "reputation" (so
to speak). Proposal #6 says that project teams must host these drivers but they
are not really accountable for the drivers if they don't live in-tree (note this
could happen even for drivers that are in-tree).

The above is all to say that I'd feel more comfortable with proposal #6 if it
would provide a way to communicate that these repos are drivers, that they are
maintained by a subset of the bigger team, etc. This is something #5 solves by
clearly saying that some driver teams are different. This separation is not only
useful from a community perspective but also for managing these projects/repos.
It allows for setting a new set of rules instead of adding exceptions to the
existing ones.

What I don't like about #5 is that increases the complexity of the process for
adding new projects and it may make communication between these teams more
difficult. It will force the creation of tiny teams w/ all the things required
for teams to exist (PTL elections, ATC management, extra ATC, and what not).

At this point I think I'm leaning more towards #5 because it acknowledges these
drivers are useful but they are essentially managed by a different team, which
is something that #6 doesn't do.

I'll try to come up with some proposals to have #6 communicate this, unless it
was left out on purpose.

Thank you all for working on this,
Flavio

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

[openstack-dev] [kolla] Vote to add zhubingbing to core team

[Michał Jastrzębski]

Hello team!

I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
core teams. He did great job reviewing code during last couple of
months.

Consider this proposal +1 from me, voting will be open for 1 week
(until Dec 6) or if we get unanimous agreement (or veto) before.

Regards,
Michal

__
OpenStack Development Mailing 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] [telemetry][ceilometer] let's talk about volume=1 meters (again)

[gordon chung]

hi,

i should preface the below is arguably not important if we have ability 
to count events and alarm against panko.

~~

we recently removed all our volume=1 meters in ceilometer and while i 
cleaning things up some residual stuff i started to wonder if we took 
out too much. (yes, i'm aware of that i was that guy who led this effort)

i'm not talking about bringing back the 'instance', 'volume', etc... 
meters because they were measuring nothing (or it measured everything as 
some giant, unintelligible, blob meter). there are also stuff like 
.created|deleted 'meters' which are one off events only useful 
at maybe a project level. that said, i think some of the identity 
volume=1 meters we generated from keystone notifications might have a 
use case which allowed you to maybe alarm when too many 
'identity.authenticate.failure' events were received in a given timespan.

so my question is, it it worth taking a second look at volume=1 meters 
or is this just a gap in our events api?

cheers,
-- 
gord
__
OpenStack Development Mailing 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] cirros images to change default password

[Scott Moser]

On Tue, 29 Nov 2016, Ihar Hrachyshka wrote:

> Hi,
>
> It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].
>
> I hope it helps someone in the future.
>
> [1] 
> http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
> [2] 
> https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477

Hi all,

I will at some point in the 0.4 line of cirros release images with that
change.  I would not intend to change it back to 0.3.

I want to be clear that I didn't make the change "just because".
I did fail to reference the bug in the commit you linked above, but it
I did in commit 95f4ffa2 [3].  It fixed Bug 1454144 [4].  For non-english
speaking users, the colon and right parentheses were difficult to type.
I suspect this was related to a keyboard mapping issue through qemu or
elsewhere, but the fix seems sane.

I picked gocubsgo as the new password.  It had to be something, other
options 'beatohio' [5] or some phrase indicating how bad the Cardinals
are. ;)

I'm quite grateful for all the good karma that you all sent to the
Cubs to help them win.  Thanks.

Scott
--
[3] 
https://git.launchpad.net/cirros/commit/?id=95f4ffa2f5339aa04226718895a780f2994817b9
[4] https://bugs.launchpad.net/cirros/+bug/1454144
[5] https://www.google.com/search?q=beat+ohio=G=en=isch=u__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
> > I'll rank my preferred solutions, because I don't actually like any of
> > them.
> 
> Just curious...what would you "actually like"?
> 
> Chris
> 

My preference is to have teams just handle the drivers voluntarily,
without needing to make it a rule or provide a way to have teams
that only work on a driver. That's not one of the options we proposed,
but the results are like what we would get with option 6 (minus the
precedent of the TC telling teams what code they must manage).

Doug

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

Re: [openstack-dev] [all] cirros images to change default password

[Ihar Hrachyshka]

:) My pleasure.

While it’s fun and all, I see some code/docs relying on the old value.

I suggest projects to check if they make an assumption, and if so, prepare for 
the change.

Alternatively, we can try to convince cirros folks to revert.

Ihar

> On 29 Nov 2016, at 16:11, Jay S. Bryant  wrote:
> 
> Thank you for sharing this.
> 
> This gave me a much needed smile this morning.  :-)
> 
> Jay
> 
> 
> On 11/29/2016 06:48 AM, Ihar Hrachyshka wrote:
>> Hi,
>> 
>> It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].
>> 
>> I hope it helps someone in the future.
>> 
>> [1] 
>> http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
>> [2] 
>> https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477
>> 
>> 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 Development Mailing 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] [keystone] Pike PTL

[Brad Topol]

+1!  Great job Steve


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Henry Nash 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   11/23/2016 11:08 AM
Subject:Re: [openstack-dev] [keystone] Pike PTL



Steve,

It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy
taking some time back!

Henry
  On 21 Nov 2016, at 19:38, Steve Martinelli 
  wrote:

  one of these days i'll learn how to spell :)

  On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli <
  s.martine...@gmail.com> wrote:
Keystoners,

I do not intend to run for the PTL position of the Pike development
cycle. I'm sending this out early so I can work with folks
interested in the role, If you intend to run for PTL in Pike and
are interested in learning the ropes (or just want to hear more
about what the role means) then shoot me an email.

It's been an unforgettable ride. Being PTL a is very rewarding
experience, I encourage anyone interested to put your name forward.
I'm not going away from OpenStack, I just think three terms as PTL
has been enough. It'll be nice to have my evenings back :)

To *all* the keystone contributors (cores and non-cores), thank you
for all your time and commitment. More importantly thank you for
putting up with my many questions, pings, pokes and -1s. Each of
you are amazing and together you make an awesome team. It has been
an absolute pleasure to serve as PTL, thank you for letting me do
so.

stevemar




Thanks for the idea Lana [1]
[1]

http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html

  __

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


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

Re: [openstack-dev] [all] cirros images to change default password

[Jay S. Bryant]

Thank you for sharing this.

This gave me a much needed smile this morning.  :-)

Jay


On 11/29/2016 06:48 AM, Ihar Hrachyshka wrote:

Hi,

It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].

I hope it helps someone in the future.

[1] 
http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
[2] 
https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477

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 Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Chris Friesen]

On 11/29/2016 08:03 AM, Doug Hellmann wrote:

I'll rank my preferred solutions, because I don't actually like any of
them.


Just curious...what would you "actually like"?

Chris


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

Re: [openstack-dev] [neutron] Stepping down as testing lieutenant and from the core & drivers teams

[Miguel Lavalle]

Assaf,

We will miss you. Thanks for all your hard work for the community

Good luck

On Tue, Nov 29, 2016 at 7:19 AM, Trinath Somanchi 
wrote:

> Hi Assaf -
>
> It's a sad moment to miss you here.  Hope you will find some more time in
> the future to come back.
>
> It's very nice to work with you.
>
> All the best. Don't stop your blog.
>
> / Trinath
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Tuesday, November 29, 2016 12:29 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and
> from the core & drivers teams
>
> Hi all,
>
> For the past few months I've been gaining more responsibilities within Red
> Hat. I have less time to dedicate to personal contribution and it's had a
> considerable tole on my ability to perform my duties upstream to the degree
> of effectiveness I am satisfied with. To that end, I've decided that the
> right thing to do is to hand over my testing lieutenant responsibilities to
> Jakub Libosvar, and to step down from the core and drivers team.
>
> This is a bitter sweet moment. I'm enormously proud to see the progress
> Neutron as a platform, community and as a reference implementation have
> made over the last 3 years and I'm thrilled to have taken part in that.
> It's grown from an experiment to a ubiquitous OpenStack project with a
> proven, robust and scalable batteries-included implementation used at the
> largest retail, insurance, banking, web and telco (And more!) companies in
> the world.
> My focus will remain on OpenStack networking but my contributions will be
> indirect through my amazing team members. The people leading Quantum when I
> joined are nearly all gone and luckily we've seen a continuous influx of
> fresh talent ready to take over leadership responsibilities. I'm confident
> the wheel will keep on spinning and the project will continue stepping down
> the right path.
>
> I'll still be on IRC and I'll be working over the upcoming couple of weeks
> to hand off any specific tasks I had going on. Have fun folks.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-*] Refactor of segments db

[Ihar Hrachyshka]

Folks, note that this change basically changes ml2 driver API that was supposed 
to be stable (now drivers receive context objects instead of sqlalchemy 
sessions). I would like folks to chime in the review. I would also suggest to 
announce the change during the next team meetings.

> On 22 Nov 2016, at 18:09, Anna Taraday  wrote:
> 
> Hello everyone! 
> I'm working on implementation new engine facade in Neutron. [1]   
> 
> 
> We have a number of functions that expect to get session as one the 
> arguments. Passing session is not correct and this prevents of usage new 
> enginefacade which expect context to be passed and session to be injected in 
> current context. And also when we use new enginefacade the concept of a 
> "subtransaction" is completely different. So, I made refactor patch for 
> Neutron [2].
>   As these changes affect other projects that use these functions, I propose 
> patches to fix them [3]. 
> 
> Kindly, please be aware of these changes.
> 
> 
> [1] - 
> https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
> [2] - https://review.openstack.org/#/c/398873/ 
> [4] - 
> https://review.openstack.org/#/q/message:%22Change+passing+session+to+context+in+segments+db+functions%22
> -- 
> Regards,
> Ann Taraday
> __
> OpenStack Development Mailing 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] cirros images to change default password

[Brian Curtin]

On Tue, Nov 29, 2016 at 7:48 AM, Ihar Hrachyshka  wrote:
> Hi,
>
> It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].
>
> I hope it helps someone in the future.
>
> [1] 
> http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
> [2] 
> https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477
>
> Ihar

Feel free to sing along to "Go Cubs Go" to celebrate this password
change and/or the Cubs world series victory --
https://www.youtube.com/watch?v=A9XtDyDUjIU

__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

I'll rank my preferred solutions, because I don't actually like any of
them.

Excerpts from Doug Hellmann's message of 2016-11-28 13:33:56 -0500:

> 6. A resolution requiring projects that consume drivers to host all
>proposed drivers. (red option) [7]
> 
>This would require teams with projects providing driver interfaces
>to also host, in some form, drivers from vendors that ask for
>hosting. The drivers would not need to be in the main project
>repo, but would need to be in a repository "owned" by the project
>team. Project teams would not be considered responsible for the
>quality of the resulting drivers.  Contributors to the driver
>repos would be considered part of the electorate for team PTL.

Ideally this question wouldn't even need to be discussed because
teams would accept all drivers, in some form, because they recognize
the importance of contribution of drivers to the success of their
project and OpenStack as a whole. The result would be some drivers
in-tree and others in a separate repository, as described in option
6, without the TC requiring teams to accept the code. This would
encourage collaboration and stem the proliferation of extra teams,
which forestalls some of the issues we're anticipating with resources
at the PTG, Summit, etc.

I understand that the actual social interactions within some teams,
and between teams and contributors from vendors, hasn't been ideal,
but I'm still not convinced that the current path is the right
solution. It will not encourage anyone who is not contributing to
the common parts of a project to do so, and it sets the wrong tone
for the necessary future interactions that happen between contributors
discussing code at driver API boundaries.

The proposal Sean has for the Cinder team to allow a "class 2"
driver type that is basically marked as unsupported by the core
team seems like it's a good compromise and something we could do
in all projects to help users understand the support level of all
the drivers they use (with some of the implementation details to
be worked out).

> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
> 
>This would completely remove the problematic wording from the
>governance documents (eliminate the restriction on benefiting a
>single company and consider access to specific information for
>some contributors to not be a problem).

If there's no general agreement that teams should host driver
contributions, then I would prefer option 3, which simplifies our
rules instead of adding more. The TC can recognize when a single-vendor
project does not benefit the overall community, and reject it on
those grounds, while allowing driver development teams. We can manage
PTG space and other scarce resources using similar judgment.

> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

If we feel the need to codify the differences between two types of
teams, then I'll help refine some version of option 5 to do that.

Doug

> [0] http://governance.openstack.org/reference/new-projects-requirements.html 
> - requirements for new projects
> [1] https://review.openstack.org/363709 - Add networking-cisco back into the 
> Big Tent
> [2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
> [3] https://review.openstack.org/403836 - Driver development can be level
> [4] https://review.openstack.org/403838 - Stop requiring a level playing field
> [5] https://review.openstack.org/403839 - Level playing fields, except drivers
> [6] https://review.openstack.org/403829 - establish a new "driver team" 
> concept
> [7] https://review.openstack.org/403830 - add resolution requiring teams to 
> accept driver contributions
> [8] https://review.openstack.org/403826 - add a resolution allowing teams 
> based on vendor-specific drivers

__
OpenStack Development Mailing 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] Stepping down as testing lieutenant and from the core & drivers teams

[Trinath Somanchi]

Hi Assaf -

It's a sad moment to miss you here.  Hope you will find some more time in the 
future to come back.

It's very nice to work with you.

All the best. Don't stop your blog.

/ Trinath

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Tuesday, November 29, 2016 12:29 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and from 
the core & drivers teams

Hi all,

For the past few months I've been gaining more responsibilities within Red Hat. 
I have less time to dedicate to personal contribution and it's had a 
considerable tole on my ability to perform my duties upstream to the degree of 
effectiveness I am satisfied with. To that end, I've decided that the right 
thing to do is to hand over my testing lieutenant responsibilities to Jakub 
Libosvar, and to step down from the core and drivers team.

This is a bitter sweet moment. I'm enormously proud to see the progress Neutron 
as a platform, community and as a reference implementation have made over the 
last 3 years and I'm thrilled to have taken part in that. It's grown from an 
experiment to a ubiquitous OpenStack project with a proven, robust and scalable 
batteries-included implementation used at the largest retail, insurance, 
banking, web and telco (And more!) companies in the world.
My focus will remain on OpenStack networking but my contributions will be 
indirect through my amazing team members. The people leading Quantum when I 
joined are nearly all gone and luckily we've seen a continuous influx of fresh 
talent ready to take over leadership responsibilities. I'm confident the wheel 
will keep on spinning and the project will continue stepping down the right 
path.

I'll still be on IRC and I'll be working over the upcoming couple of weeks to 
hand off any specific tasks I had going on. Have fun folks.

__
OpenStack Development Mailing 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] [infra][neutron] Intel NFV CI voting permission in Neutron

[Znoinski, Waldemar]

Hi Ihar et al,
Apologies for late reply. We were fighting couple of issues with the CI in last 
couple of days. The networking problem mentioned by Ihar was one of them.
We're running fine as of yesterday [1]. To stay on the safe side let's wait a 
few days so CI proves stable before making it voting. I'll ping you this Friday 
- hope that's ok.


1. http://ci-watch.tintri.com/project?project=neutron=7+days

 >-Original Message-
 >From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
 >Sent: Monday, November 28, 2016 4:24 PM
 >To: OpenStack Development Mailing List (not for usage questions)
 >
 >Cc: openstack-in...@lists.openstack.org
 >Subject: Re: [openstack-dev] [infra][neutron] Intel NFV CI voting permission
 >in Neutron
 >
 >
 >> On 28 Nov 2016, at 12:18, Ihar Hrachyshka  wrote:
 >>
 >> I suggest we disable votes for the setup until it’s fixed.
 >
 >UPD: done, the CI is disabled for voting.
 >
 >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 Development Mailing 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] [ptl][release] ocata release management communication

[Rob C]

I'm struggling to find good info on when the adjusted PTL nomination cycle
starts.

I've checked here:
https://releases.openstack.org/ocata/schedule.html#pike-ptls-self-nomination
but it looks like the 'elections' section was supposed to be added to the
table and wasn't.

I know from the updates to the charter that the elections should happen on
or before R-3 but it doesn't provide any clarity on how much before then
the nominations should be made?

Cheers
Rob

On 1 Nov 2016 19:45, "Doug Hellmann"  wrote:

> PTLs,
>
> As we did for the Mitaka and Newton cycles, I want to start this
> cycle by making sure the expectations for communications with the
> release team are clear to everyone so there is no confusion or
> miscommunication about any of the process or deadlines. This
> email is being sent to the openstack-dev mailing list as well as
> the PTLs of all official OpenStack projects individually, to
> improve the odds that all of the PTLs see it.  I will not be
> taking the extra step of CCing individual PTLs or liaisons for
> future emails.
>
> (If you were a PTL last cycle, you may want to skip ahead to the
> Things for you to do right now section at the end.)
>
> Volunteers filling PTL and liaison positions are responsible for
> ensuring communication between project teams happens smoothly. As
> a community, we rely on three primary communication
> strategies/tools for different purposes:
>
> 1. Email, for announcements and for asynchronous communication.
>
>   We will be using the "[release]" topic tag on the openstack-dev
>   mailing list for important messages related to release
>   management.  Besides special announcements and instructions, I
>   will send the countdown emails I sent last cycle, with weekly
>   updates on focus, tasks, and upcoming dates. PTLs and release
>   liaisons should configure your mailing list subscription and
>   email client to ensure that those messages are visible (and
>   then read them) so that you are aware of all deadlines, process
>   changes, etc.
>
> 2. IRC, for time-sensitive interactions.
>
>   There are far too many of you (56) to make it realistic for the
>   three members of the release team to track you down
>   individually when there is a deadline. We need you to do your
>   part by making yourself available by configuring your IRC
>   bouncer to listen in #openstack-release. You are, of course,
>   welcome to stay in channel all the time, but you need to be
>   there at least during deadline periods (the week before and
>   week of each deadline).
>
> 3. Written documentation, for relatively stable information.
>
>   The release team has published the schedule for the Ocata cycle
>   to http://releases.openstack.org/ocata/schedule.html. Although
>   I will highlight dates in the countdown emails, you may want to
>   add important dates from the schedule to your calendar.
>
>   Some projects have also added their own project-specific
>   deadlines to that list. If you have something unique, please
>   feel free to update it by patching the openstack/releases
>   repository. There is no need to add a project-specific deadline
>   that is the same as the global deadline.
>
> The Ocata cycle overlaps with several major holidays, including
> the new year. If you are planning time off, please make sure your
> duties are being covered by someone else on the team. Its best to
> let the release team know in advance so we dont delay approval
> for release requests from someone we dont recognize, waiting for
> your +1.
>
> Please ensure that the release liaison for your project has the
> time and ability to handle the communication necessary to manage
> your release.  The release team is here to facilitate, but
> finishing the work of preparing the release is ultimately the
> responsibility of the project team. Failing to follow through on
> a needed process step may block you from successfully meeting
> deadlines or releasing.  Our release milestones and deadlines are
> date-based, not feature-based.  When the date passes, so does the
> milestone. If you miss it, you miss it. A few of you ran into
> problems in past cycles because of missed communications. My goal
> is to have all teams meet all deadlines during Ocata. We came
> very very close for Newton; please help by keeping up to date on
> deadlines.
>
>
> Things for you to do right now:
>
> 1. Update your cross-project liaison on
>https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> 2. Make sure your IRC nickname and email address listed in
>http://git.openstack.org/cgit/openstack/governance/tree/
> reference/projects.yaml
>are correct. The release team, foundation staff, and TC all
>use those contact details to try to reach you at important
>points during the cycle.  Please make sure they are correct,
>and that the email address delivers messages to a mailbox you
>check regularly.
>
> 3. Update your mail filters to ensure you see 

[openstack-dev] [all] cirros images to change default password

[Ihar Hrachyshka]

Hi,

It was ‘cubswin:)’ before, but now that Cubs won [1] it’s ‘gocubsgo’ [2].

I hope it helps someone in the future.

[1] 
http://www.chicagotribune.com/sports/baseball/cubs/ct-cubs-win-world-series-sullivan-spt-1103-20161102-story.html
[2] 
https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477

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] 答复: Re: [aodh] about alarm update with --query

[dong . wenjuan]

Hi Julien Danjou,

Thanks for your suggestion.
Already report a bug:
https://bugs.launchpad.net/ubuntu/+source/aodh/+bug/1645694

BR,
dwj




Julien Danjou  
2016-11-29 18:12

收件人
dong.wenj...@zte.com.cn
抄送
openstack-dev@lists.openstack.org
主题
Re: [openstack-dev] [aodh] about alarm update with --query






On Tue, Nov 29 2016, dong.wenj...@zte.com.cn wrote:

Hi dongwenjuan,

I'd suggest to open a bug against aodh on Launchpad. I've no idea if
it's a bug or not, but at least it'll be logged and we'll be able to dig
into that. :)

> Hi all,
>
> I use aodh cli to create a event alarm with query condition, the cli 
runs 
> successfully.
> But when i want to update the query condition, the cli runs failed.
> The help info about `--query` para with these two cli  have no 
difference. 
>
> The information is as follows, Does anyone else know why? Thanks~
>
> stack@cloud:~$ aodh alarm create --name test --type event --event-type 
> compute.instance.update --query 
> "traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49"
> 
+---+---+
> | Field | Value  |
> 
+---+---+
> | alarm_actions | []  |
> | alarm_id  | 8d1018bd-8f14-4f34-b47c-54588488d658 |
> | description   | Alarm when compute.instance.update event 
> occurred.|
> | enabled   | True  |
> | event_type| compute.instance.update  |
> | insufficient_data_actions | []  |
> | name  | test  |
> | ok_actions| []  |
> | project_id| f0895991f44044ccba8e62b201b70360   |
> | query | traits.instance_id = 
> 3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49 |
> | repeat_actions| False  |
> | severity  | low  |
> | state | insufficient data  |
> | state_timestamp   | 2016-11-29T06:31:50.094836  |
> | time_constraints  | []  |
> | timestamp | 2016-11-29T06:31:50.094836  |
> | type  | event  |
> | user_id   | 7d7531a2030d4537b60a5193bf6ab286   |
> 
+---+---+
> stack@cloud:~$ 
> stack@cloud:~$ 
> stack@cloud:~$ aodh alarm update 8d1018bd-8f14-4f34-b47c-54588488d658 
> --event-type computer.instance.delete --query 
> "traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88"
> Invalid input for field/attribute data. Value: '{'alarm_actions': [], 
> 'event_rule': {'query': 
> 'traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88', 
> 'event_type': 'computer.instance.delete'}, 'ok_actions': [], 'name': 
> 'test', 'state': 'insufficient data', 'timestamp': 
> '2016-11-29T06:31:50.094836', 'enabled': True, 'state_timestamp': 
> '2016-11-29T06:31:50.094836', 'severity': 'low', 'alarm_id': 
> '8d1018bd-8f14-4f34-b47c-54588488d658', 'time_constraints': [], 
> 'insufficient_data_actions': [], 'repeat_actions': False, 'user_id': 
> '7d7531a2030d4537b60a5193bf6ab286', 'project_id': 
> 'f0895991f44044ccba8e62b201b70360', 'type': 'event', 'description': 
'Alarm 
> when compute.instance.update event occurred.'}'. Value not a valid list: 

> traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88 (HTTP 
400) 
> (Request-ID: req-ad8bd440-2784-43b7-98d7-7e0ae27dcebc)
> stack@cloud:~$ 
>
>
>
>

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




signature.asc
Description: Binary data
__
OpenStack Development Mailing 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,
I've added the code of magnum_driver and its unit test to review.
It seems everything works.

Ruben

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

Sent: Saturday, November 26, 2016 12:48:12 AM
Subject: Re: [Congress] Magnum_driver

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

Re: [openstack-dev] [neutron]Do we need to rfe to implement active-active router?

[huangdenghui]

Hi Thomas
 I have already filed a RFE bug.Please refer to bug #1645625


发自网易邮箱手机版



On 2016-11-18 01:27 , Thomas Morin Wrote:


Hi,

What would active-active exactly be in DVR mode ?

-Thomas

Le 16/11/2016 à 16:42, huangdenghui a écrit :

hi
Currently, neutron support DVR router and legacy router.  For high 
availability, there is HA router in reference implementation of legacy mode and 
DVR  mode. I am considering whether is active-active router needed in both mode?





 




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


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

Re: [openstack-dev] Suspected SPAM - Re: Suspected SPAM - [vitrage] datasources terminology

[Weyl, Alexey (Nokia - IL)]

Sounds good to me :)

From: Afek, Ifat (Nokia - IL) [mailto:ifat.a...@nokia.com] 
Sent: Tuesday, November 29, 2016 11:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Suspected SPAM - Re: [openstack-dev] Suspected SPAM - [vitrage] 
datasources terminology

Hi,

A new suggestion:

• event_type: the type of event/notification that comes from the datasource. 
For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
• graph_action: used to tell the evaluator what to do with the entity - create, 
update or delete it.
• datasource_action: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

What do you think?
Ifat.


From: "Afek, Ifat (Nokia - IL)"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 29 November 2016 at 09:26
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Suspected SPAM - [openstack-dev] [vitrage] datasources terminology

Hi,

I think we have a confusing terminology in Vitrage datasources. 

The following parameters are used in the drivers and transformers: 
• event_type: the type of event/notification that comes from the datasource. 
For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
• event_action: used to tell the evaluator what to do with the entity - create, 
update or delete it.
• action_type: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

Personally I find these names very confusing. 
My suggestion is to rename action_type to datasource_mode, or something similar.

Your thoughts?

Thanks,
Ifat.

__
OpenStack Development Mailing 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] [oslo][osprofiler] Sampling rate in OSProfiler

[vin...@vn.fujitsu.com]

Hey guys,

cc: harlowja, DinaBelova, boris-42

I saw a lot of great work in OSProfiler.

I see that "Trace every N request configuration (not done yet)". [1]
Both Zipkin [2] and OpenTracing [3] have this feature.
OSProfiler aim to be a small library --> May this feature make any overhead?

Do you guys have any idea how to implement this?

[1] Mitaka spec: 
https://specs.openstack.org/openstack/oslo-specs/specs/mitaka/osprofiler-cross-service-project-profiling.html#performance-impact
[2] Zipkin: http://zipkin.io/pages/instrumenting.html
[3] OpenTracing: 
http://opentracing.io/documentation/pages/api/data-conventions.html

Best regards,

Vinh Nguyen Trong (tovin07/Tovin Seven)
PODC - Fujitsu Vietnam Ltd. 


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

Re: [openstack-dev] [aodh] about alarm update with --query

[Julien Danjou]

On Tue, Nov 29 2016, dong.wenj...@zte.com.cn wrote:

Hi dongwenjuan,

I'd suggest to open a bug against aodh on Launchpad. I've no idea if
it's a bug or not, but at least it'll be logged and we'll be able to dig
into that. :)

> Hi all,
>
> I use aodh cli to create a event alarm with query condition, the cli runs 
> successfully.
> But when i want to update the query condition, the cli runs failed.
> The help info about `--query` para with these two cli  have no difference. 
>
> The information is as follows, Does anyone else know why? Thanks~
>
> stack@cloud:~$ aodh alarm create --name test --type event --event-type 
> compute.instance.update --query 
> "traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49"
> +---+---+
> | Field | Value  |
> +---+---+
> | alarm_actions | []  |
> | alarm_id  | 8d1018bd-8f14-4f34-b47c-54588488d658   |
> | description   | Alarm when compute.instance.update event 
> occurred.|
> | enabled   | True  |
> | event_type| compute.instance.update  |
> | insufficient_data_actions | []  |
> | name  | test  |
> | ok_actions| []  |
> | project_id| f0895991f44044ccba8e62b201b70360   |
> | query | traits.instance_id = 
> 3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac49 |
> | repeat_actions| False  |
> | severity  | low  |
> | state | insufficient data  |
> | state_timestamp   | 2016-11-29T06:31:50.094836  |
> | time_constraints  | []  |
> | timestamp | 2016-11-29T06:31:50.094836  |
> | type  | event  |
> | user_id   | 7d7531a2030d4537b60a5193bf6ab286   |
> +---+---+
> stack@cloud:~$ 
> stack@cloud:~$ 
> stack@cloud:~$ aodh alarm update 8d1018bd-8f14-4f34-b47c-54588488d658 
> --event-type computer.instance.delete --query 
> "traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88"
> Invalid input for field/attribute data. Value: '{'alarm_actions': [], 
> 'event_rule': {'query': 
> 'traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88', 
> 'event_type': 'computer.instance.delete'}, 'ok_actions': [], 'name': 
> 'test', 'state': 'insufficient data', 'timestamp': 
> '2016-11-29T06:31:50.094836', 'enabled': True, 'state_timestamp': 
> '2016-11-29T06:31:50.094836', 'severity': 'low', 'alarm_id': 
> '8d1018bd-8f14-4f34-b47c-54588488d658', 'time_constraints': [], 
> 'insufficient_data_actions': [], 'repeat_actions': False, 'user_id': 
> '7d7531a2030d4537b60a5193bf6ab286', 'project_id': 
> 'f0895991f44044ccba8e62b201b70360', 'type': 'event', 'description': 'Alarm 
> when compute.instance.update event occurred.'}'. Value not a valid list: 
> traits.instance_id=string::3ed4fbc1-023e-4c4e-85d3-cf6d73c9ac88 (HTTP 400) 
> (Request-ID: req-ad8bd440-2784-43b7-98d7-7e0ae27dcebc)
> stack@cloud:~$ 
>
>
>
>

-- 
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] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

The problem we have with that is that for changes to take effect we will need a 
reboot after it.
This is suboptimal for production environments, where there are large amount of 
nodes and with an slow hardware. And also the reboot needs to be carefully 
synced, to only take place after all puppet changes have been applied.
That's why we wanted to consider some other solutions that are done 
pre-deployment, they will be much more effective in terms of performance.

- Original Message -
From: "Jay Faulkner" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, November 28, 2016 4:46:56 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
parameterson local boot


> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota  wrote:
> 
> Hi, good afternoon
> 
> I wanted to start an email thread about how to properly setup kernel 
> parameters on local boot, for our overcloud images on TripleO.
> These parameters may vary depending on the needs of our end users, and even 
> can be different ( for different roles ) per deployment. As an example, we 
> need it for:
> - enable FIPS kernel in terms of security 
> (https://bugs.launchpad.net/tripleo/+bug/1640235)
> - enable functionality for DPDK/SR-IOV 
> (https://review.openstack.org/#/c/331564/)
> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
> - etc..
> 
> So far, the solutions we got were on several directions:
> 
> 1. Update the golden overcloud-full image with virt-customize, modifying 
> /etc/default/grub settings according to our needs: this is a manual process, 
> not really driven by TripleO. End users will want to avoid manual steps as 
> much as possible. Also if we announce that OpenStack ships features in 
> TripleO like DPDK, SR-IOV... doesn't make sense to tell end users that if 
> they want to consume that feature, they need to do manual updates on the 
> image. It shall be natively supported, or configurable per TripleO 
> environments.
> 
> 2. Create our own images using diskimage-builder and custom elements: in this 
> case, we have the problem that the partners will loose support, as building 
> their own images is good for upstream, but not accepted into the OSP 
> environment. Also the combination of images needed can be huge, that can be a 
> blocker for QA.
> 
> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
> properties can be set on metadata, like a json with kernel parameters. Ironic 
> will modify these kernel parameters when deploying the image (in a similar 
> way that when it installs bootloader, or generates partitions).
> 

This has been proposed before in ironic-specs 
(https://review.openstack.org/#/c/331564/) and was rejected, as it would 
require Ironic to reach out and modify image contents, which traditionally has 
been considered out of scope for Ironic. I would personally recommend #4, as 
post-boot automation is the safest way to configure node-specific options 
inside an image.

Thanks,
Jay Faulkner
OSIC


> 4. Configure it post-deployment: there can be some puppet element that 
> updates kernel parameters. But it will need a node reboot to be applied, and 
> it's very far from being optimal and acceptable for the end users. Reboots 
> are slow, they can be a problem depending on the number of nodes/hardware, 
> and also the timing of reboot shall be totally controlled (after all puppet 
> has been applied properly).
> 
> 
> In the first three cases, we also hit the problem that TripleO only accepts 
> one single overcloud image for all deployments - there is no way to instruct 
> TripleO to upload and use several images, depending on the node type 
> (although Ironic supports it). Also, we are worried about upgrade paths if we 
> do image customizations. We need a clear way to move forward on it.
> 
> So, we'd like to discuss the possible options there and the action items to 
> take (raise bugs, create some blueprints...). To summarize, our end goal is 
> the following:
> 
> - need to map overcloud-full images to roles
> - need to be done in an automated way, no manual steps enforced, and in a way 
> that can pass properly quality controls
> - reboots are sub-optimal
> 
> What are your thoughts there?
> 
> Best,
> 
> 
> Yolanda Robla
> yrobl...@redhat.com
> Principal Software Engineer - NFV Partner Engineer
> 
> 
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] Suspected SPAM - [vitrage] datasources terminology

[Afek, Ifat (Nokia - IL)]

Hi,

A new suggestion:


  *   event_type: the type of event/notification that comes from the 
datasource. For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
  *   graph_action: used to tell the evaluator what to do with the entity - 
create, update or delete it.
  *   datasource_action: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

What do you think?
Ifat.


From: "Afek, Ifat (Nokia - IL)"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 29 November 2016 at 09:26
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Suspected SPAM - [openstack-dev] [vitrage] datasources terminology

Hi,

I think we have a confusing terminology in Vitrage datasources.

The following parameters are used in the drivers and transformers:

  *   event_type: the type of event/notification that comes from the 
datasource. For example: ‘compute.instance.delete.end’,  ‘volume.detach.start’
  *   event_action: used to tell the evaluator what to do with the entity - 
create, update or delete it.
  *   action_type: the type of action that was performed by the driver: 
init_snapshot, snapshot or update.

Personally I find these names very confusing.
My suggestion is to rename action_type to datasource_mode, or something similar.

Your thoughts?

Thanks,
Ifat.

__
OpenStack Development Mailing 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] Stepping down as testing lieutenant and from the core & drivers teams

[Anna Taraday]

It was real pleasure to work with you!
Thank you for your guidance and comments, we will miss that :(
Wish you all the best!

On Tue, Nov 29, 2016 at 9:55 AM Vikram Choudhary <
vikram.choudh...@huawei.com> wrote:

> Hi Assaf,
>
> Wish you all the best for your future endeavor!
>
> Thanks
> Vikram
>
>
> -Original Message-
> From: Vasudevan, Swaminathan (PNB Roseville) [mailto:
> swaminathan.vasude...@hpe.com]
> Sent: 29 November 2016 00:35
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Stepping down as testing lieutenant
> and from the core & drivers teams
>
> Hi Assaf,
> Sorry to hear that you are stepping down. Thanks for your contribution to
> neutron and making the test suite more stable.
> Wish you all success in your current job.
>
> Thanks
> Swami
>
> -Original Message-
> From: Assaf Muller [mailto:as...@redhat.com]
> Sent: Monday, November 28, 2016 10:59 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [neutron] Stepping down as testing lieutenant and
> from the core & drivers teams
>
> Hi all,
>
> For the past few months I've been gaining more responsibilities within Red
> Hat. I have less time to dedicate to personal contribution and it's had a
> considerable tole on my ability to perform my duties upstream to the degree
> of effectiveness I am satisfied with. To that end, I've decided that the
> right thing to do is to hand over my testing lieutenant responsibilities to
> Jakub Libosvar, and to step down from the core and drivers team.
>
> This is a bitter sweet moment. I'm enormously proud to see the progress
> Neutron as a platform, community and as a reference implementation have
> made over the last 3 years and I'm thrilled to have taken part in that.
> It's grown from an experiment to a ubiquitous OpenStack project with a
> proven, robust and scalable batteries-included implementation used at the
> largest retail, insurance, banking, web and telco (And more!) companies in
> the world.
> My focus will remain on OpenStack networking but my contributions will be
> indirect through my amazing team members. The people leading Quantum when I
> joined are nearly all gone and luckily we've seen a continuous influx of
> fresh talent ready to take over leadership responsibilities. I'm confident
> the wheel will keep on spinning and the project will continue stepping down
> the right path.
>
> I'll still be on IRC and I'll be working over the upcoming couple of weeks
> to hand off any specific tasks I had going on. Have fun folks.
>
> __
> OpenStack Development Mailing 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
>
-- 
Regards,
Ann Taraday
__
OpenStack Development Mailing 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] [tricircle]Weekly meeting(Nov.30) cancelled for we can have a f2f meetup in bug-smash

[joehuang]

Hello, team,

There is bug-smash this week, and many of us will attend this event[1], so 
let's have a f2f meetup there, and the weekly meeting(Nov.30) will be cancelled 
accordingly.

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing 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] Allowing Teams Based on Vendor-specific Drivers

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

My preference goes to this option.

I think it's important to continue to say that all OpenStack projects
are expected to be developed as a fair and open collaboration. This is
the reason why we are here. However, some teams work on implementing
drivers for those projects, using established plug-in points to enable
external software, proprietary solutions or hardware to work with
OpenStack. Those drivers are an integral part of the success of our
openly-developed projects, but by their very nature we can't enforce the
same level playing field over proprietary driver development. As a
community, we need those drivers for the success of our mission.

This option basically says that we welcome those driver teams as a part
of our community, while recognizing that they are a different animal. In
this specific and narrow case (second-order objects that implement a
pluggable extension point defined by an OpenStack project) we accept a
different set of team requirements (removing the level playing field
principle). Tracking those teams and their requirements separately
ensures that this deviation is not affecting the message for the main
projects.

An alternative would be the "soft white" option, but I think that if
those teams have different requirements and very limited scope, it's
simpler to list them separately rather than put them all in the same
file. It avoids diluting the "open collaboration" message we send to the
main projects.

I would also be fine with the the "soft black" option (which is
basically repeating the current situation).

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