Re: [openstack-dev] [L2-Gateway] RPM packaging and Agent configuration

[Thomas Bechtold]

Hi,

On Thu, Dec 22, 2016 at 04:16:28PM +0100, Ricardo Noriega De Soto wrote:
> Thanks a lot Ofer!!
> 
> Just one more question, the command to start the agent is fine, but, do we
> need to include the l2gateway_plugin.ini to Neutron server???

with a recent oslo.config, you can just drop a config snippet into
/etc/neutron/neutron-server.conf.d/ . But that only works if
neutron-server does not override the default config dirs while starting
(so *no* --config-dir must be given).

Also it would be nice if you could propose your spec file to the
rpm-packaging project (https://wiki.openstack.org/wiki/Rpm-packaging ).

Best,

Tom

> 
> Something like:
> 
> /usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf
> --config-dir /usr/share/neutron/server --config-file
> /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini
> --config-dir /etc/neutron/conf.d/common --config-dir
> /etc/neutron/conf.d/neutron-server --log-file
> /var/log/neutron/server.log *--config-file
> /etc/neutron/l2gateway_plugin.ini *???
> 
> Thanks!!
> 
> On Sun, Dec 18, 2016 at 8:33 AM, Ofer Ben-Yacov 
> wrote:
> 
> > The command that you've wrote for the agent is correct.
> > No need to add anything.
> >
> > Ofer.
> >
> > On 16 December 2016 at 16:12, Ricardo Noriega De Soto  > > wrote:
> >
> >> Hello L2GW devs!
> >>
> >> I'm currently working on the RPM packaging of networking-l2gw project.
> >>
> >> My undestanding is that depending on the config, I could use whether
> >> OpenDaylight or the neutron-l2gw-agent as backend.
> >>
> >> For the latter case, I'm writing a systemd unit file, but I'd love to get
> >> the command of how you launch the agent itself. I would say it's something
> >> like:
> >>
> >> https://paste.fedoraproject.org/507402/89715214/
> >>
> >> /usr/bin/neutron-l2gw-agent --config-file /etc/neutron/neutron.conf
> >> --config-file /etc/neutron/l2gateway_agent.ini  --log-file
> >> /var/log/neutron/l2gw-agent.log
> >>
> >> Anything to add??
> >>
> >> Thanks!
> >>
> >> --
> >> Ricardo Noriega
> >>
> >> Senior Software Engineer - NFV Partner Engineer | Office of Technology
> >>  | Red Hat
> >> irc: rnoriega @freenode
> >>
> >>
> >> 
> >> __
> >> 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
> >
> >
> 
> 
> -- 
> Ricardo Noriega
> 
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode

> __
> OpenStack Development Mailing 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] [mistral][ptg] PTG in Atlanta

[Renat Akhmerov]

Hi,

The first PTG event is less than in two months which is, in fact, very soon.

I kindly would like to ask you to register for the PTG if you haven’t yet. The 
price is now $100. 
All necessary information about the event and the link to buy a ticket and book 
a hotel is at [1].

[2] is an etherpad where we will prepare a list of topics to discuss. Please 
feel free to add yours.
At this point it can be weakly structured, it is ok. Moving forward we’ll 
adjust them according to
the schedule, needs in interactions with other projects etc.

[1] https://www.openstack.org/ptg/ 
[2] https://etherpad.openstack.org/p/mistral-ptg-pike 


Renat Akhmerov
@Nokia

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

[openstack-dev] [Cinder] Refactor reset-status command for cinder resources at client side

[TommyLike Hu]

Hi cinder members,

   Eharney recently add a comment about 'resource-reset-status' command
here [1] on Dec 22, and I'd like to paste his comment here to get more
attention and discussion before the patch can go on.

 *I'd like to discuss the general design here and get input from others
before landing more reset-state commands.*
* I get the feeling that we are just copying existing things because
they are already there, but I think we can come up with something better.*
* (Note: I asked for more details about the CLI in the spec review, but
the only thing that showed up there was a command example that doesn't say
anything about defaults and  mirrors what existed already. So I think
we can get further into details now that there's code here.)*
* We also need to stop defaulting these commands to "available". It's
dangerous and almost guaranteed to produce an undesirable result for
someone who runs this without  studying --help first, which is not
good design.(I know we do this in other commands. It's wrong there, too.)*
* We could at least require input of "--state " rather than having a
default here.*

I try to figure out the his concerns there:

1. We should consider redesign the 'resource-rest-status' in the
cinderclient as we could have too many reset commands here:
   - reset-state
   - snapshot-reset-state
   - backup-reset-state
   - group-reset-state with this patch
   - group-snapshot-reset-state with this patch

  Additionly, he add a new patch [2] and try to have them covered with
a single reset command:

  (draft)cinder reset-state --type snapshot abcd-1234 --status error

2. Stop using default value 'available' for reset-status command.

3. The codes there just mirror what existed already (If the main point
here is about reduce duplication, I think this could be easily fixed by
another patch, and could be ignored).

Please leave comments here or in the patches if you are interested in.

Merry Christmas
TommyLike

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

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Matt Riedemann]

On 12/22/2016 8:26 PM, Tony Breeds wrote:

Hi All,
I know this comes up from time to time, but as the subject says, is it time
to retire nova-docker.

The nova-docker has lagged behind the last 6 months of nova development and no
longer passes simple CI unit tests.  There are open patches to at least get the
unit tests to pass[1] but if the current core team no longer has time (no
offence intended) then perhaps we should just archive it.

Thoughts?

Yours Tony.
[1] 
https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master



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



+1 for what it's worth.

People show up in the nova channel in IRC from time to time (maybe once 
or twice per year) asking about the state of the driver and I send them 
to the nova-docker IRC channel, but also explain it's not really maintained.


I know people are running it and hacking on it outside of the community 
repo, which is fine, and if someone doing that wanted to stand up and 
say they wanted to own the repo and be the core team I'd be fine with 
that too, but so far no one has done that in the last few years. If 
you're already maintaining it outside of the community I don't know why 
you wouldn't just do that development in the open, and maybe get a free 
bug fix at times from another contributor, but I suppose people have 
their reasons (secret sauce and all that). So meh.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Intermittent gate failures across multiple projects

[Tony Breeds]

On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> pushed today to PyPi
> 
> Thanks to everyone working together on this issue in #openstack-infra !
> 
> A patch is proposed to blacklist that release and we are testing it now.

The fix is now merged so if you're jobs failed with 'Illegal Instruction' feel
free to recheck without swamping our CI.  I believe that eleastic-recheck should
tell you if you match this case.

Thanks to those that found the root cause and worked on the fix

Yours Tony.


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

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Tony Breeds]

On Thu, Dec 22, 2016 at 09:43:34PM -0500, Davanum Srinivas wrote:
> yep, it's time to pull the plug Tony
> 
> fyi, http://lists.openstack.org/pipermail/openstack-dev/2016-July/098940.html

Okay I knew it'd come up before.  If noone objects befoerm Monday Dec 26th,
I'll send the announcement to openstack-annouce, openstack-dev and
openstck-operators setting the EOL date for March 1.  I feel like that is
oodles[1] of warning. and it wont detract from any of the ocata development or
release work.

Yours Tony.

[1] Yes that's a technical term[2]
[2] http://www.dictionary.com/browse/oodles


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

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[ChangBo Guo]

+1

2016-12-23 10:43 GMT+08:00 Davanum Srinivas :

> yep, it's time to pull the plug Tony
>
> fyi, http://lists.openstack.org/pipermail/openstack-dev/2016-
> July/098940.html
>
> -- Dims
>
> On Thu, Dec 22, 2016 at 9:26 PM, Tony Breeds 
> wrote:
> > Hi All,
> > I know this comes up from time to time, but as the subject says, is
> it time
> > to retire nova-docker.
> >
> > The nova-docker has lagged behind the last 6 months of nova development
> and no
> > longer passes simple CI unit tests.  There are open patches to at least
> get the
> > unit tests to pass[1] but if the current core team no longer has time (no
> > offence intended) then perhaps we should just archive it.
> >
> > Thoughts?
> >
> > Yours Tony.
> > [1] https://review.openstack.org/#/q/status:open+project:
> openstack/nova-docker+branch:master+topic:fixes_for_master
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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] FW: [neutron][all] Intermittent gate failures across multiple projects

[Bhatia, Manjeet S]

Hi neutrinos !

There is an Intermittent failure observed on gate jobs,
I saw same failure of one of my patches, It was on keystone
Phase for twice I checked.

Thanks and Regards !
Manjeet Singh Bhatia

From: John Villalovos [mailto:openstack@sodarock.com]
Sent: Thursday, December 22, 2016 3:41 PM
To: openstack-dev 
Subject: [openstack-dev] [all] Intermittent gate failures across multiple 
projects

Gate jobs seem to be intermittently broken across all of OpenStack.

Bug filed:
https://bugs.launchpad.net/openstack-gate/+bug/1652186
They appear during the keystone phase of devstack and look like this:

http://logs.openstack.org/39/414339/2/check/gate-tempest-dsvm-ironic-ipa-partition-pxe_snmp-tinyipa-ubuntu-xenial-nv/1d5e63d/logs/devstacklog.txt.gz#_2016-12-22_22_25_10_787

2016-12-22 
22:25:08.607
 | 2016-12-22 22:25:08.606 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created domain default

2016-12-22 
22:25:08.637
 | 2016-12-22 22:25:08.637 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created project admin

2016-12-22 
22:25:08.657
 | 2016-12-22 22:25:08.656 31714 DEBUG passlib.registry 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] registered 'sha512_crypt' 
handler:  
register_crypt_handler 
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:294

2016-12-22 
22:25:08.684
 | 2016-12-22 22:25:08.684 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created user admin

2016-12-22 
22:25:08.700
 | 2016-12-22 22:25:08.699 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created role admin

2016-12-22 
22:25:08.714
 | 2016-12-22 22:25:08.714 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Granted admin on admin to 
user admin.

2016-12-22 
22:25:08.731
 | 2016-12-22 22:25:08.730 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created region RegionOne

2016-12-22 
22:25:08.763
 | 2016-12-22 22:25:08.763 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created admin endpoint 
http://15.184.67.84/identity_admin

2016-12-22 
22:25:08.775
 | 2016-12-22 22:25:08.774 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created internal endpoint 
http://15.184.67.84/identity

2016-12-22 
22:25:08.787
 | 2016-12-22 22:25:08.787 31714 INFO keystone.cmd.cli 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created public endpoint 
http://15.184.67.84/identity

2016-12-22 
22:25:08.793
 | 2016-12-22 22:25:08.793 31714 INFO keystone.assignment.core 
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Creating the default role 
9fe2ff9ee4384b1894a90878d3e92bab because it does not exist.

2016-12-22 
22:25:08.923
 | + ./stack.sh:main:1065

Re: [openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Davanum Srinivas]

yep, it's time to pull the plug Tony

fyi, http://lists.openstack.org/pipermail/openstack-dev/2016-July/098940.html

-- Dims

On Thu, Dec 22, 2016 at 9:26 PM, Tony Breeds  wrote:
> Hi All,
> I know this comes up from time to time, but as the subject says, is it 
> time
> to retire nova-docker.
>
> The nova-docker has lagged behind the last 6 months of nova development and no
> longer passes simple CI unit tests.  There are open patches to at least get 
> the
> unit tests to pass[1] but if the current core team no longer has time (no
> offence intended) then perhaps we should just archive it.
>
> Thoughts?
>
> Yours Tony.
> [1] 
> https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [nova][nova-docker] Time to retire nova-docker?

[Tony Breeds]

Hi All,
I know this comes up from time to time, but as the subject says, is it time
to retire nova-docker.

The nova-docker has lagged behind the last 6 months of nova development and no
longer passes simple CI unit tests.  There are open patches to at least get the
unit tests to pass[1] but if the current core team no longer has time (no
offence intended) then perhaps we should just archive it.

Thoughts?

Yours Tony.
[1] 
https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master


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

Re: [openstack-dev] [all] Using \ for multiline statements

[Ian Cordasco]

On Thu, Dec 22, 2016 at 6:02 PM, Sean McGinnis  wrote:
>>
>> By the way, can we finally all agree that commit message titles need to be a
>> proper ('merican) English grammatically correct sentence that begins with a
>> capital letter and ends with a period. And flavor is flavor, it's not
>> flavour.
>>
>> Happy holidays.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>
> Hah, now you're just trying to start the flames! :D

In my opinion, the Queen's English is imperially better... or is it
empirically? =P

As a side note, I could have sworn I remembered pep8/pycodestyle
warning on using backslashes instead of ()s but I seem to have been
wrong. All it warns about is using a backslash inside parentheses
because it's redundant.

As a maintainer of pycodestyle, I'd be happy to add one, especially
since the PEP-0008 document's preferred way is ()s [1]. That said,
it's possible that check was removed at some point and I'm just too
tired to do the archaeology for it. (It also might have been buggy at
the time.)

Either way, -1'ing over style issues is silly if the tool allows it
(or as is usually the case in OpenStack, is configured to allow it).
At that point it's subjective and a bit of a waste of people's time to
argue over it. From a perspective of personal preference, I prefer ()s
but that's just my $0.02.

[1]: https://www.python.org/dev/peps/pep-0008/#maximum-line-length
-- 
Ian Cordasco

__
OpenStack Development Mailing 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] Intermittent gate failures across multiple projects

[John Villalovos]

We believe the error is caused by a bad wheel for lxml 3.7.0 that was
pushed today to PyPi

Thanks to everyone working together on this issue in #openstack-infra !

A patch is proposed to blacklist that release and we are testing it now.
__
OpenStack Development Mailing 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] Intermittent gate failures across multiple projects

[Matt Riedemann]

On 12/22/2016 5:40 PM, John Villalovos wrote:

Gate jobs seem to be intermittently broken across all of OpenStack.

Bug filed:
https://bugs.launchpad.net/openstack-gate/+bug/1652186


They appear during the keystone phase of devstack and look like this:

http://logs.openstack.org/39/414339/2/check/gate-tempest-dsvm-ironic-ipa-partition-pxe_snmp-tinyipa-ubuntu-xenial-nv/1d5e63d/logs/devstacklog.txt.gz#_2016-12-22_22_25_10_787


2016-12-22 22:25:08.607

| 2016-12-22 22:25:08.606 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created domain
default 2016-12-22 22:25:08.637

| 2016-12-22 22:25:08.637 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created project
admin 2016-12-22 22:25:08.657

| 2016-12-22 22:25:08.656 31714 DEBUG passlib.registry
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] registered
'sha512_crypt' handler:  register_crypt_handler
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:294
2016-12-22 22:25:08.684

| 2016-12-22 22:25:08.684 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created user admin
2016-12-22 22:25:08.700

| 2016-12-22 22:25:08.699 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created role admin
2016-12-22 22:25:08.714

| 2016-12-22 22:25:08.714 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Granted admin on
admin to user admin. 2016-12-22 22:25:08.731

| 2016-12-22 22:25:08.730 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created region
RegionOne 2016-12-22 22:25:08.763

| 2016-12-22 22:25:08.763 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created admin
endpoint http://15.184.67.84/identity_admin
 2016-12-22 22:25:08.775

| 2016-12-22 22:25:08.774 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created internal
endpoint http://15.184.67.84/identity 2016-12-22 22:25:08.787

| 2016-12-22 22:25:08.787 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created public
endpoint http://15.184.67.84/identity 2016-12-22 22:25:08.793

| 2016-12-22 22:25:08.793 31714 INFO keystone.assignment.core
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Creating the
default role 9fe2ff9ee4384b1894a90878d3e92bab because it does not exist.
2016-12-22 22:25:08.923

| + ./stack.sh:main:1065 : create_keystone_accounts 2016-12-22
22:25:08.927

Re: [openstack-dev] [all] Using \ for multiline statements

[Sean McGinnis]

> 
> By the way, can we finally all agree that commit message titles need to be a
> proper ('merican) English grammatically correct sentence that begins with a
> capital letter and ends with a period. And flavor is flavor, it's not
> flavour.
> 
> Happy holidays.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 

Hah, now you're just trying to start the flames! :D


__
OpenStack Development Mailing 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] Using \ for multiline statements

[Matt Riedemann]

On 12/22/2016 5:52 PM, Matt Riedemann wrote:

On 12/22/2016 5:28 PM, Sean McGinnis wrote:

Looking for input from everyone, particularly those with more in-depth
Python knowledge.

In Cinder for some time we have been trying to enforce using () or
reformatting code to avoid using \ to have statements span multiple
lines. I'm not sure when this actually started, but I think it may
be one of those things where someone got a review disagreement, so
then that person started downvoting on it, then the next person, etc.

I've seen some allusions to the use of \ having some issues, but I
can't find any concrete examples where this can cause problems. I do
seem to remember trying to write a hacking check or a code parsing
tool to do something that choked on these, but it's long enough ago
that I don't remember the details, and I could very well be mixing
that up with something else.

So my question is - is there a technical reason for enforcing this
rule, or is this just a bad downvote that's gotten out of control?

Thanks!

Sean


__

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



I wouldn't -1 it. I've noticed \ showing up a bit more in Nova recently
simply for the exact reason I think people used to -1 it, because it was
considered ugly to use. But we've also had cases of () gone haywire. I
typically see \ used in unit tests or in DB API code when chaining
sqlalchemy ORM objects together to generate a single query.

Like most things like this, I'd rather than squabble over it, and take
it on a case by case basis. If a patch is hard to read and could be
improved using one or the other, then I'd comment as such, but wouldn't
-1 for using \ as a rule.



By the way, can we finally all agree that commit message titles need to 
be a proper ('merican) English grammatically correct sentence that 
begins with a capital letter and ends with a period. And flavor is 
flavor, it's not flavour.


Happy holidays.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Using \ for multiline statements

[Matt Riedemann]

On 12/22/2016 5:28 PM, Sean McGinnis wrote:

Looking for input from everyone, particularly those with more in-depth
Python knowledge.

In Cinder for some time we have been trying to enforce using () or
reformatting code to avoid using \ to have statements span multiple
lines. I'm not sure when this actually started, but I think it may
be one of those things where someone got a review disagreement, so
then that person started downvoting on it, then the next person, etc.

I've seen some allusions to the use of \ having some issues, but I
can't find any concrete examples where this can cause problems. I do
seem to remember trying to write a hacking check or a code parsing
tool to do something that choked on these, but it's long enough ago
that I don't remember the details, and I could very well be mixing
that up with something else.

So my question is - is there a technical reason for enforcing this
rule, or is this just a bad downvote that's gotten out of control?

Thanks!

Sean


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



I wouldn't -1 it. I've noticed \ showing up a bit more in Nova recently 
simply for the exact reason I think people used to -1 it, because it was 
considered ugly to use. But we've also had cases of () gone haywire. I 
typically see \ used in unit tests or in DB API code when chaining 
sqlalchemy ORM objects together to generate a single query.


Like most things like this, I'd rather than squabble over it, and take 
it on a case by case basis. If a patch is hard to read and could be 
improved using one or the other, then I'd comment as such, but wouldn't 
-1 for using \ as a rule.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] Using \ for multiline statements

[Mike Carden]

I note that it was rejected as PEP-3125 back in 2007:

https://www.python.org/dev/peps/pep-3125/


-- 
MC
__
OpenStack Development Mailing 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] Intermittent gate failures across multiple projects

[John Villalovos]

Gate jobs seem to be intermittently broken across all of OpenStack.

Bug filed:
https://bugs.launchpad.net/openstack-gate/+bug/1652186

They appear during the keystone phase of devstack and look like this:

http://logs.openstack.org/39/414339/2/check/gate-tempest-
dsvm-ironic-ipa-partition-pxe_snmp-tinyipa-ubuntu-xenial-nv/
1d5e63d/logs/devstacklog.txt.gz#_2016-12-22_22_25_10_787

2016-12-22 22:25:08.607

| 2016-12-22 22:25:08.606 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created domain
default2016-12-22 22:25:08.637

| 2016-12-22 22:25:08.637 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created project
admin2016-12-22 22:25:08.657

| 2016-12-22 22:25:08.656 31714 DEBUG passlib.registry
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] registered
'sha512_crypt' handler:  register_crypt_handler
/usr/local/lib/python2.7/dist-packages/passlib/registry.py:2942016-12-22
22:25:08.684 

| 2016-12-22 22:25:08.684 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created user
admin2016-12-22 22:25:08.700

| 2016-12-22 22:25:08.699 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created role
admin2016-12-22 22:25:08.714

| 2016-12-22 22:25:08.714 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Granted admin on
admin to user admin.2016-12-22 22:25:08.731

| 2016-12-22 22:25:08.730 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created region
RegionOne2016-12-22 22:25:08.763

| 2016-12-22 22:25:08.763 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created admin
endpoint http://15.184.67.84/identity_admin2016-12-22 22:25:08.775

| 2016-12-22 22:25:08.774 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created internal
endpoint http://15.184.67.84/identity2016-12-22 22:25:08.787

| 2016-12-22 22:25:08.787 31714 INFO keystone.cmd.cli
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Created public
endpoint http://15.184.67.84/identity2016-12-22 22:25:08.793

| 2016-12-22 22:25:08.793 31714 INFO keystone.assignment.core
[req-f336127d-0628-4b9d-bcc7-a87863c3127e - - - - -] Creating the
default role 9fe2ff9ee4384b1894a90878d3e92bab because it does not
exist.2016-12-22 22:25:08.923

| + ./stack.sh:main:1065 :
create_keystone_accounts2016-12-22 22:25:08.927

| + lib/keystone:create_keystone_accounts:371 :   local
admin_project2016-12-22 22:25:08.931

Re: [openstack-dev] [all] Using \ for multiline statements

[John Villalovos]

I for one do not like \ continuation lines. I think they look ugly and
prefer using () and formatting code to avoid them.

On Thu, Dec 22, 2016 at 3:28 PM, Sean McGinnis 
wrote:

> Looking for input from everyone, particularly those with more in-depth
> Python knowledge.
>
> In Cinder for some time we have been trying to enforce using () or
> reformatting code to avoid using \ to have statements span multiple
> lines. I'm not sure when this actually started, but I think it may
> be one of those things where someone got a review disagreement, so
> then that person started downvoting on it, then the next person, etc.
>
> I've seen some allusions to the use of \ having some issues, but I
> can't find any concrete examples where this can cause problems. I do
> seem to remember trying to write a hacking check or a code parsing
> tool to do something that choked on these, but it's long enough ago
> that I don't remember the details, and I could very well be mixing
> that up with something else.
>
> So my question is - is there a technical reason for enforcing this
> rule, or is this just a bad downvote that's gotten out of control?
>
> Thanks!
>
> Sean
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Using \ for multiline statements

[Sean McGinnis]

Looking for input from everyone, particularly those with more in-depth
Python knowledge.

In Cinder for some time we have been trying to enforce using () or
reformatting code to avoid using \ to have statements span multiple
lines. I'm not sure when this actually started, but I think it may
be one of those things where someone got a review disagreement, so
then that person started downvoting on it, then the next person, etc.

I've seen some allusions to the use of \ having some issues, but I
can't find any concrete examples where this can cause problems. I do
seem to remember trying to write a hacking check or a code parsing
tool to do something that choked on these, but it's long enough ago
that I don't remember the details, and I could very well be mixing
that up with something else.

So my question is - is there a technical reason for enforcing this
rule, or is this just a bad downvote that's gotten out of control?

Thanks!

Sean


__
OpenStack Development Mailing 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] [glance] question for OpenStack User Survey

[Brian Rosmaita]

Glancers,

We have the opportunity to submit one question for the upcoming User
Survey, which launches on or before February 1.  We'd receive responses
in advance of the February PTG, so this would be a good opportunity for
glancers who are thinking of organizing design sessions at the PTG to
get some user input to discuss at the PTG.

The question is due on January 9, so I'll put an item on the January 5
meeting agenda, and if there are multiple contenders, we can discuss and
vote to select the question likely to have the most impact.

As far as the question format goes, you can have one of:
* multiple choice, pick one of up to 6 items
* multiple choice, pick all that apply of up to 6 items
* short answer
(Both multiple choice formats allow an "other" option for a write-in
candidate.)

You also get to specify who you want the question aimed at:
* people using Glance in a production/test cloud
* people testing Glance in a production/test cloud
* people interested in Glance
(You can pick more than one group.)

Add your question to the agenda for the January 5 meeting:
https://etherpad.openstack.org/p/glance-team-meeting-agenda

cheers,
brian

__
OpenStack Development Mailing 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] [glance] priorities for the next 2 weeks (12/23-01/05)

[Brian Rosmaita]

Item number 1 is the same as last week, but it was reviewed and has a
new patch coming soon, so please keep an eye out for it.  Everything
else is new.

(1) Patch to enable better request-id tracking:
https://review.openstack.org/#/c/352892/


(2) Community images
The current patch:
https://review.openstack.org/#/c/369110/

There's a discussion about the implementation happening on the ML:
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109370.html

Please monitor the discussion (and weigh in if you are so inclined).


(3) Port Glance migrations to Alembic
https://review.openstack.org/#/c/382958/
https://review.openstack.org/#/c/392993/


People working on items not on the list: please keep in mind that many
reviewers will be on vacation during the next two weeks.  If you have
something you'd like to discuss, you can put a shout in
#openstack-glance on IRC to see if anyone is around, or send a topic to
the mailing list (tagged with [glance] in the subject line).

No Glance meeting on December 29.
Next Glance meeting is January 5, 2017.



__
OpenStack Development Mailing 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] [glance][tempest][api] community images, tempest tests, and API stability

[Matthew Treinish]

On Thu, Dec 22, 2016 at 02:57:20PM -0500, Brian Rosmaita wrote:
> Something has come up with a tempest test for Glance and the community
> images implementation, and I think it could use some mailing list
> discussion, as everyone might not be aware of the patch where the
> discussion is happening now [1].
> 
> First, the Glance background, to get everyone on the same page:
> 
> As part of implementing community images [2], the 'visibility' field of
> an image is going from being 2-valued to being 4-valued.  Up to now, the
> only values have been 'private' and 'public', which meant that shared
> images were 'private', which was inaccurate and confusing (and bugs were
> filed with Glance about shared images not having visibility 'shared'
> [3a,b]).
> 
> With the new visibility enum, the Images API v2 will behave as follows:
> 
> * An image with visibility == 'private' is not shared, and is not
> shareable until its visibility is changed to 'shared'.
> 
> * An image must have visibility == 'shared' in order to do member
> operations or be accessible to image members.
> 
> * The default visibility of a freshly-created image is 'shared'.  This
> may seem weird, but a freshly-created image has no members, so it's
> effectively private, behaving exactly as a freshly-created image does,
> pre-Ocata.  It's also ready to immediately accept a member-create call,
> as freshly-created images are pre-Ocata.  So from a workflow
> perspective, this change is backward compatible.
> 
> * After much discussion [4], including discussion with operators and an
> operator's survey [5], we decided that the correct migration of
> 'visibility' values for existing images when a cloud is updated would
> be: public images stay 'public', private images with members become
> 'shared', and private images without images stay 'private'.  (Thus, if
> you have a 'private' image, you'll have to change it to 'shared' before
> you can add members.  On the other hand, now it's *really* private.)
> 
> * You can specify a visibility at the time of image-creation, as you can
> now.  But if you specify 'private', what you get is *really* private.
> This either introduces a minor backward incompatibility, or it fixes a
> bug, depending on how you look at it.  The key thing is, if you *don't*
> specify a visibility, an image with the default visibility will behave
> exactly as it does now, from the perspective of being able to make API
> calls on it (e.g., adding members).
> 
> Thanks for reading this far.  (There's a much more detailed discussion
> in the spec; see the "Other end user impact" section. [2])  Here's the
> point of this email:
> 
> The community images patch [6] is causing a recently added tempest test
> [7] to fail.  The test in question uses an image that was created by a
> request that explicitly specified visibility == private.  Eventually it
> tries to add a member to this image, and as discussed above, this
> operation will fail once we have merged Community Images (because the
> image visibility is not 'shared').  If the image had been created with
> the default visibility (that is, not explicitly specifying a visibility
> in the image-create call), this problem would not arise.  Keep in mind
> that prior to Ocata, there was no reason for end users to specify an
> image visibility explicitly upon image creation because there were only
> two possible values, one of which required special permissions in order
> to use successfully.

While you say there was no reason for a user to do it was still part of the
glance API and part of your contract with end users. It's something anyone
could be doing today, (which is obvious because tempest is doing it)
regardless of whether you think there is a use case for it or not. The whole
point of a stable api is that you don't break things like this. I'd really
recommend reading Sean Dague's blog post here about Nova's api here:

https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

because it does a very good job explaining typical api use cases and how to
think about api compatibility.

> Thus, we feel that the situation occurring in the
> test is not one that many end users will come across.  We have discussed
> the situation extensively with the broader OpenStack community, and the
> consensus is that this change to the API is acceptable.

The guidelines for API compatiblity [1] are there for a reason, and breaking
existing users is **never** the right answer. You'll never get full coverage of
end users by just asking for feedback on the ML and IRC meetings. Heck, I hadn't
heard of any of these proposed changes until that tempest review, and I'm hardly
a disconnected user. The thing to remember is that all APIs have warts and
aspects which are less than ideal, our first priority when making improvements
should be to not randomly break our users in the process. If the goal of
OpenStack is to provide an interoperable cloud platform, ensuring we don't break
our users is kinda 

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

[Andy McCrae]

Hi Sean,

I assume you're talking about OpenStack-Ansible (was OS-A-D before moving
to the OpenStack namespace), if not, feel free to ignore my response!

This is actually something we're working on - we have in role testing for
some key OpenStack services (Nova, Neutron, Swift, Keystone, Cinder,
Glance), and upgrade testing for the rabbitmq_server and galera_server
roles.

This is a first pass effort, the testing right now deploys the Newton
version of the service and then upgrades it and runs a functional test.
This isn't perfect but should help ensure individual services can upgrade
successfully - and can be built upon.

The next step is to add an integrated build upgrade test, and we have plans
to get that done (it's been an action item in our meetings for a few weeks,
but hasn't landed just yet). If you have any questions or would like to get
involved feel free to stop by and discuss in the #openstack-ansible channel
on freenode.

As an aside, we have some upgrade documentation here:
http://docs.openstack.org/developer/openstack-ansible/upgrade-guide/index.html
which may be useful, but it's due for an overhaul in the near future.

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

Re: [openstack-dev] [Ironic] python-ironicclient weird behaviour

[Maxime Belanger]

It has been moved as a bug:

https://bugs.launchpad.net/python-ironicclient/+bug/1652142

Fix proposition:

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


Max


From: Loo, Ruby 
Sent: December 22, 2016 2:56:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] python-ironicclient weird behaviour


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

Date: Thursday, December 22, 2016 at 9:32 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [Ironic] python-ironicclient weird behaviour


Hi Ironic folks,



Yesterday I come across a weird behaviour in python-ironicclient. I discussed 
briefly with the problem with Julia and befor creating a bug I would like your 
opinion on the problem and potential fix.



When doing nodes.get(resource_id=None), I get back a Node object set with 
attribute nodes={nodes: [{uuid: 'blah'}, {uuid: 'bleh'}]}. I guess that is not 
expected which is the bug I found and I know where to fix it if we agree to not 
change the behavour: If resource_id=None the client is doing a GET on /v1/nodes 
which is expected here : 
https://github.com/openstack/python-ironicclient/blob/1.8.0/ironicclient/common/base.py#L55.



The thing is, returning the first item of the list while doing a get on 
something that doesn't exists is a bit strange. I do not want to do extra 
validation on my application side to not pass None to the ironicclient. I would 
it to behave correctly: 404 or a even a 400.



What do you think/or prefer?



A. Fixing the bug and not changing actual behaviour of the API

B. Changing the API behaviour and returning a 404 error since resource None is 
not found

C. Changing the API behaviour and returning a 400 error because None is not a 
valid request. The will be identical to the command line that is doing this:
ironic node-show None
Invalid input for field/attribute node_ident. Value: 'None'. unable to convert 
to uuid_or_name (HTTP 400)

Thanks
Max

Thanks for tripping over this! :-( I think this is a bug in the API. I think it 
is just a coincidence that it happens to return the list of nodes (because the 
generated HTTP request works). That code should be checking that resource_id is 
non-empty -- that's what the CLI does. And if it isn't, raise an exception. I 
vote for B, sort of. It shouldn't return an http status error since no http 
request should be made. Looking at the existing exceptions, I'm guessing 
InvalidAttribute or ValidationError?

Your C above is a different situation, 'None' is a string that is the name of a 
node, but that string doesn't conform to the allowed name syntax.

--ruby

__
OpenStack Development Mailing 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] [os-ansible-deployment] Periodic job in infra to test upgrades?

[Sean M. Collins]

Hi,

A couple weeks ago I did some manual testing of upgrades from Liberty ->
Mitaka and Mitaka -> Newton using OSAD and a AIO node.

Whenever I hit an issue, I'd report it.

I'd be great if we could automate this work. The only challenge I can
think of is the fact that building up an AIO node, installing the base
version, then doing the upgrade takes quite a bit of time. I don't know
if periodic jobs have the same time constraints as jobs in the check and
gate queue though.

At least on my local machine, I sped up the process by snapshotting the
AIO box (disk and running memory) in VBox so that I could re-run the upgrade
quickly. Worst case perhaps set up a 3rd party CI system that could use
that trick? Just throwing ideas out there.

Thoughts?

-- 
Sean M. Collins

__
OpenStack Development Mailing 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] [glance][tempest][api] community images, tempest tests, and API stability

[Brian Rosmaita]

Something has come up with a tempest test for Glance and the community
images implementation, and I think it could use some mailing list
discussion, as everyone might not be aware of the patch where the
discussion is happening now [1].

First, the Glance background, to get everyone on the same page:

As part of implementing community images [2], the 'visibility' field of
an image is going from being 2-valued to being 4-valued.  Up to now, the
only values have been 'private' and 'public', which meant that shared
images were 'private', which was inaccurate and confusing (and bugs were
filed with Glance about shared images not having visibility 'shared'
[3a,b]).

With the new visibility enum, the Images API v2 will behave as follows:

* An image with visibility == 'private' is not shared, and is not
shareable until its visibility is changed to 'shared'.

* An image must have visibility == 'shared' in order to do member
operations or be accessible to image members.

* The default visibility of a freshly-created image is 'shared'.  This
may seem weird, but a freshly-created image has no members, so it's
effectively private, behaving exactly as a freshly-created image does,
pre-Ocata.  It's also ready to immediately accept a member-create call,
as freshly-created images are pre-Ocata.  So from a workflow
perspective, this change is backward compatible.

* After much discussion [4], including discussion with operators and an
operator's survey [5], we decided that the correct migration of
'visibility' values for existing images when a cloud is updated would
be: public images stay 'public', private images with members become
'shared', and private images without images stay 'private'.  (Thus, if
you have a 'private' image, you'll have to change it to 'shared' before
you can add members.  On the other hand, now it's *really* private.)

* You can specify a visibility at the time of image-creation, as you can
now.  But if you specify 'private', what you get is *really* private.
This either introduces a minor backward incompatibility, or it fixes a
bug, depending on how you look at it.  The key thing is, if you *don't*
specify a visibility, an image with the default visibility will behave
exactly as it does now, from the perspective of being able to make API
calls on it (e.g., adding members).

Thanks for reading this far.  (There's a much more detailed discussion
in the spec; see the "Other end user impact" section. [2])  Here's the
point of this email:

The community images patch [6] is causing a recently added tempest test
[7] to fail.  The test in question uses an image that was created by a
request that explicitly specified visibility == private.  Eventually it
tries to add a member to this image, and as discussed above, this
operation will fail once we have merged Community Images (because the
image visibility is not 'shared').  If the image had been created with
the default visibility (that is, not explicitly specifying a visibility
in the image-create call), this problem would not arise.  Keep in mind
that prior to Ocata, there was no reason for end users to specify an
image visibility explicitly upon image creation because there were only
two possible values, one of which required special permissions in order
to use successfully.  Thus, we feel that the situation occurring in the
test is not one that many end users will come across.  We have discussed
the situation extensively with the broader OpenStack community, and the
consensus is that this change to the API is acceptable.

To conclude: before and after this change, the "default" visibility of
an image will allow adding members to the image. We would hope that the
failing tempest test could be revised to not explicitly request
"private" visibility but to allow Glance to use its default visibility
instead [10]. We have wide cross-project support [8, 9] for the
"Community Images" work and the only thing blocking us now is tempest.
Due to the shortened cycle in Ocata, we'd really appreciate finding
common ground with the QA team quickly.

thanks,
brian

[1] https://review.openstack.org/#/c/412731/
[2]
http://specs.openstack.org/openstack/glance-specs/specs/newton/approved/glance/community_visibility.html
[3a] https://bugs.launchpad.net/glance/+bug/1394299
[3b] https://bugs.launchpad.net/glance/+bug/1452443
[4] https://review.openstack.org/#/c/396919/
[5]
http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html
[6] https://review.openstack.org/#/c/369110/
[7] https://review.openstack.org/#/c/317088/
[8]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107349.html
[9]
http://eavesdrop.openstack.org/meetings/api_wg/2016/api_wg.2016-06-09-15.59.log.html#l-84
[10] https://review.openstack.org/#/c/414261

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

Re: [openstack-dev] [Ironic] python-ironicclient weird behaviour

[Loo, Ruby]

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

Date: Thursday, December 22, 2016 at 9:32 AM
To: "openstack-dev@lists.openstack.org" 
Subject: [openstack-dev] [Ironic] python-ironicclient weird behaviour


Hi Ironic folks,



Yesterday I come across a weird behaviour in python-ironicclient. I discussed 
briefly with the problem with Julia and befor creating a bug I would like your 
opinion on the problem and potential fix.



When doing nodes.get(resource_id=None), I get back a Node object set with 
attribute nodes={nodes: [{uuid: 'blah'}, {uuid: 'bleh'}]}. I guess that is not 
expected which is the bug I found and I know where to fix it if we agree to not 
change the behavour: If resource_id=None the client is doing a GET on /v1/nodes 
which is expected here : 
https://github.com/openstack/python-ironicclient/blob/1.8.0/ironicclient/common/base.py#L55.



The thing is, returning the first item of the list while doing a get on 
something that doesn't exists is a bit strange. I do not want to do extra 
validation on my application side to not pass None to the ironicclient. I would 
it to behave correctly: 404 or a even a 400.



What do you think/or prefer?



A. Fixing the bug and not changing actual behaviour of the API

B. Changing the API behaviour and returning a 404 error since resource None is 
not found

C. Changing the API behaviour and returning a 400 error because None is not a 
valid request. The will be identical to the command line that is doing this:
ironic node-show None
Invalid input for field/attribute node_ident. Value: 'None'. unable to convert 
to uuid_or_name (HTTP 400)

Thanks
Max

Thanks for tripping over this! :-( I think this is a bug in the API. I think it 
is just a coincidence that it happens to return the list of nodes (because the 
generated HTTP request works). That code should be checking that resource_id is 
non-empty -- that's what the CLI does. And if it isn't, raise an exception. I 
vote for B, sort of. It shouldn't return an http status error since no http 
request should be made. Looking at the existing exceptions, I'm guessing 
InvalidAttribute or ValidationError?

Your C above is a different situation, 'None' is a string that is the name of a 
node, but that string doesn't conform to the allowed name syntax.

--ruby

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

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Mike Bayer]

On 12/20/2016 06:50 PM, Cathy Zhang wrote:

Hi Bernard,

Thanks for the email. I will take a look at this. Xiaodong has been working on 
tempest test scripts.
I will work with Xiaodong on this issue.


I've added a comment to the issue which refers to upstream SQLAlchemy 
issue https://bitbucket.org/zzzeek/sqlalchemy/issues/3803 as a potential 
contributor, though looking at the logs linked from the issue it appears 
that database deadlocks are also occurring which may also be a precursor 
here.   There are many improvements in SQLAlchemy 1.1 such that the 
"rollback()" state should not be as susceptible to a corrupted database 
connection as seems to be the case here.







Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
Sent: Tuesday, December 20, 2016 3:00 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] Intermittent database transaction 
issues, affecting the tempest gate

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that follow the 
same pattern: at some point in the test suite, the service gets warnings/errors 
from the DB layer (reentrant call, closed transaction, nested rollback, …), and 
all following tests fail.

This affects both master and stable/newton branches (not many changes for now 
in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed pymysql 
bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and fix the 
problem, it would be great! Especially with the upcoming multinode tempest gate

Thanks,
--
Bernard Cafarelli

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



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

[openstack-dev] [tripleo] Adding a LateServices ResourceChain

[Lars Kellogg-Stedman]

I've been working along with a few others on some "opstools"
composable services for TripleO: that is, services that provide
things like centralized logging, performance monitoring, or
availability/health monitoring.

We've been running into a persistent problem with TripleO's
architecture: our services in many cases need configuration
information to be provided by other services in the stack, but there's
no way to introspect this data from inside a composable service
template.  This has led to some rather messy and invasive changes to
things like puppet/services/services.yaml.

In https://review.openstack.org/#/c/413748/, I've proposed the
addition of a secondary chain of services called LateServiceChain.
This is, like the existing ServiceChain resource, just a Heat
ResourceChain.  Unlike the existing ServiceChain, it receives an
additional "RoleData" parameter that contains the role_data outputs
from all the services realized in ServiceChain.

This permits composable services in the LateServices chain to access
per-service configuration information provided by the other services,
leading to much cleaner implementations of these auxiliary services.

I am attempting to use this right now for a collectd composable
service implementation, but this model would ultimately allow us to
remove several of the changes made in services.yaml to support Sensu
and Fluentd and put them back into the appropriate composable service
templates.

I'd appreciate your feedback on this idea.  Thanks!

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



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] [release] Release countdown for week R-8, 26-30 Dec

[Doug Hellmann]

Focus
-

Feature work and major refactoring should be well under way as we pass
the second milestone.

The deadline for non-client library releases is R-5 (19 Jan). We do not
grant Feature Freeze Extensions for any libraries, so that is a hard
freeze date. Any feature work that requires updates to non-client
libraries should be prioritized so it can be completed by that time.

General Notes
-

Project teams should identify contributors who have had a significant
impact this cycle but who would not qualify for ATC status using the
regular process because they have not submitted a patch. Those names
should be added to the governance repo for consideration as ATC for the
future. The list needs to be approved by the TC by 20 Jan to qualify for
contributor discount codes for the event. In order to appear on the
agenda to be discussed, the proposals need to happen by 5 Jan.

Important Dates
---

Extra ATCs deadline: 5 Jan
Final release of non-client libraries: 19 Jan
Ocata 3 Milestone, with Feature and Requirements Freezes: 26 Jan

Ocata release schedule:
http://releases.openstack.org/ocata/schedule.html




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

[openstack-dev] [tripleo][heat] Hacky validation of get_param

[Lars Kellogg-Stedman]

Maybe my fingers are flubbier than most, but I keep running into this
problem:

1. I have a typo in a get_param call somewhere in a composable service
   template.
2. Tripleo validation fails, but produces an error for a higher level
   {role.name}ServiceChain template because it ultimately wasn't able
   to resolve the outputs of the nested composable service template.

Because the error is identified at the wrong place and contains no
useful information about the root cause, it means you lose a bunch of
time manually inspecting templates for errors.

While there is a bug on this
(https://bugs.launchpad.net/heat/+bug/1599114), I wanted something now
that I could at least stick in my pre-commit hooks to identify really
obvious problems.  And here it is:

  https://github.com/larsks/heat-check-params

That will validate all calls to get_param in a template against the
parameter names defined in the 'parameters' section. It's not really
very pretty, but it has at least prevented me from committing some
changes with egregious spelling errors.

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Anne Gentle]

On Thu, Dec 22, 2016 at 10:47 AM, Andreas Jaeger  wrote:

> On 12/22/2016 04:52 PM, Anne Gentle wrote:
> >
> >
> > On Thu, Dec 22, 2016 at 8:32 AM, Doug Hellmann  > > wrote:
> >
> > Excerpts from Ian Cordasco's message of 2016-12-22 06:46:29 -0600:
> > >
> > > There is some ambiguity right now with projects as to where to put
> > > easy-to-find documentation (even if it is just a brief paragraph
> with
> > > a link to longer-form documentation) into our repositories. Let's
> > > focus on that discussion here. We can come up with a productive
> > > conclusion and work with this contributor. While you've chosen (and
> > > yes, you've chosen this) to have a negative assumption about this
> > > contributor's efforts, I've chosen to believe they're looking to
> fill
> > > a gap. Increasing the productivity of new contributors to
> OpenStack is
> > > a positive improvement for our community. It may not fix a bug or
> add
> > > a feature, but it helps ramp up the people who will do that.
> >
> > I thought we started adding these contributing files specifically
> > because of how they are rendered on github, as a way to try to
> prevent
> > folks from submitting pull requests there and then having them
> rejected
> > by the bot. It seemed more positive to give direction ahead of time
> than
> > through a rejection message.
> >
> >
> > +1 to this and Ian and Alex's sentiments.
> >
> > It'd be great to get people to click one more time (to a more specific
> > contributor guide), but let's face it, there has to be a lot of traffic
> > directly to github.com . Let's make sure there's a
> > decent entry.
> >
> > Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be .md
> > for github, Ian?) for all projects? Is it similar to the nova 2012
> > version or is there a more modern take?
>
>
> I'm against *only* adding a CONTRIBUTING.rst file. Any such change,
> should remove the existing content so that we have no duplication. If we
> document in two or three places how to contribute, one will be out of sync.
>
> So, a well done patch would be welcome - but not just adding a file with
> wrong information and no integration into existing content,.
>


Sure, let's get accurate info, but the scenario I'm thinking of is this one:
https://help.github.com/articles/setting-guidelines-for-repository-contributors/

Where the link is automatically displayed.

Anne


>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Retiring ironic-webclient

[Julia Kreger]

Thank you Gerard!  I saw the commit go through and sent you a message on IRC, 
but I guess you didn’t see it. :)

The consensus seemed to be retire instead of move to the attic since it was 
never released.  That being said, if you know of users using it off master that 
are actually finding it useful, then I feel like that plan may need to change.

-Julia

> On Dec 22, 2016, at 5:22 AM, Gerard Braad  wrote:
> 
> I made a small contribution to the documentation in July and made sure this 
> got rechecked and included. If this will move to the attic, at least people 
> will be able to deploy and use it.


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

[openstack-dev] openstack-dev] [Neutron][L3-subteam] Weekly IRC meeting canceled on December 29th

[Miguel Lavalle]

Dear L3 sub team members,

Due to the holidays period, we will cancel our weekly IRC meeting on
December 29th. We will resume it normally on January 5th.

Happy holidays and a successful 2017 for everybody!

Best regards

Miguel
__
OpenStack Development Mailing 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] [acceleration]Team Bi-weekly Meeting 2016.12.21 Agenda

[Harm Sluiman]

Assuming we have a room/place and objectives, I can attend.

On Wed, Dec 21, 2016 at 11:15 AM, Zhipeng Huang 
wrote:

> Hi all,
>
> Thanks for attending the last team meeting in year 2016 :) Please find the
> meeting notes at https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2016-
> 12-21 .
>
> Our next meeting will be held at Jan 4th, 2017.
>
> At the meantime, could you indicate whether you would attend Atlanta PTG
> by replying to this email ? Many thanks :)
>
> On Wed, Dec 21, 2016 at 3:14 PM, Zhipeng Huang 
> wrote:
>
>> Hi Team,
>>
>> Please find the agenda at https://wiki.openstack.org/
>> wiki/Meetings/CyborgTeamMeeting#Next_meeting_:_UTC_1500.2C_Dec_21th
>>
>> Remember that our IRC channel is #openstack-cyborg
>>
>> --
>> Zhipeng (Howard) Huang
>>
>> Standard Engineer
>> IT Standard & Patent/IT Prooduct Line
>> Huawei Technologies Co,. Ltd
>> Email: huangzhip...@huawei.com
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>> (Previous)
>> Research Assistant
>> Mobile Ad-Hoc Network Lab, Calit2
>> University of California, Irvine
>> Email: zhipe...@uci.edu
>> Office: Calit2 Building Room 2402
>>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
宋慢
Harm Sluiman
__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Andreas Jaeger]

On 12/22/2016 04:52 PM, Anne Gentle wrote:
> 
> 
> On Thu, Dec 22, 2016 at 8:32 AM, Doug Hellmann  > wrote:
> 
> Excerpts from Ian Cordasco's message of 2016-12-22 06:46:29 -0600:
> >
> > There is some ambiguity right now with projects as to where to put
> > easy-to-find documentation (even if it is just a brief paragraph with
> > a link to longer-form documentation) into our repositories. Let's
> > focus on that discussion here. We can come up with a productive
> > conclusion and work with this contributor. While you've chosen (and
> > yes, you've chosen this) to have a negative assumption about this
> > contributor's efforts, I've chosen to believe they're looking to fill
> > a gap. Increasing the productivity of new contributors to OpenStack is
> > a positive improvement for our community. It may not fix a bug or add
> > a feature, but it helps ramp up the people who will do that.
> 
> I thought we started adding these contributing files specifically
> because of how they are rendered on github, as a way to try to prevent
> folks from submitting pull requests there and then having them rejected
> by the bot. It seemed more positive to give direction ahead of time than
> through a rejection message.
> 
> 
> +1 to this and Ian and Alex's sentiments.
> 
> It'd be great to get people to click one more time (to a more specific
> contributor guide), but let's face it, there has to be a lot of traffic
> directly to github.com . Let's make sure there's a
> decent entry.
> 
> Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be .md
> for github, Ian?) for all projects? Is it similar to the nova 2012
> version or is there a more modern take?


I'm against *only* adding a CONTRIBUTING.rst file. Any such change,
should remove the existing content so that we have no duplication. If we
document in two or three places how to contribute, one will be out of sync.

So, a well done patch would be welcome - but not just adding a file with
wrong information and no integration into existing content,

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


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

[openstack-dev] [fuel] Weekly meetings Dec22, Dec29 and Jan5 are cancelled

[Alexey Shtokolov]

Fuelers,

As we agreed next 3 meetings (Dec22, Dec29 and Jan5) are cancelled due to
holidays.

Please feel free to put your topics to agenda [0] for Jan12 meeting.

[0] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

---
WBR, Alexey Shtokolov
OpenStack Fuel PTL
__
OpenStack Development Mailing 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] killing non-dvr ovs scenario job

[Ihar Hrachyshka]

Hi all,

currently, we have three experimental scenario jobs:

1. linuxbridge single node
2. ovs non-dvr single node
3. ovs dvr multi node

I don’t see why we should at this point care about the 2nd one. I think we  
decided some time ago that the future we see is most if not all tempest  
jobs in neutron gate to be multinode, and dvr+ha enabled. In this context,  
trying to make the 2nd job work is not very productive, and I think we  
should instead focus on the 3rd one.


I proposed a patch killing the 2nd job here:  
https://review.openstack.org/#/c/414210/


Of course, linuxbridge is not dvr compatible yet, so we don’t touch it just  
now (though it could probably use some transition to multinode).


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] [neutron] [fullstack] Test of DHCP agent HA

[Sławek Kapłoński]

Hello,

Some time ago I introduced basic test for DHCP agent in fullstack tests
([1]).
Now I want to add test(s) for HA of DHCP agent - I started it in [2]. I
want to add which will:
* create environment with 2 hosts and 2 dhcp agents,
* spawn FakeMachine and check if it will get IP address,
* kill DHCP agent which hosts DHCP for created network,
* wait a while and check if another DHCP agent starts hosting this
  network,
* spawn new FakeMachine and check if it will get IP address from DHCP

So it looks quite easy but there is one problem. Dhcp agent creates
network namespace with name "qdhcp-" and spawn there dnsmasq
process. This dnsmasq is using tap interface in this namespace. So when
I killed first dhcp agent, it not removes qdhcp- namespace
so second agent want's to "reuse" it. Problem is that in this namespace
still is running dnsmasq spawned by first agent.
So I think that best solution would be to change somehow DHCP agent that
each agent will create namespaces with names like
"qdhcp--some-random-suffix". And my question is how to do it
in easiest way? I wanted to do it in same way how it is in L3 agent in
fullstack but I would need to "override" couple methods from agent only
for tests and I don't think it's good idea.
Maybe someone more experienced will have some better ideas how to do it.


[1] https://review.openstack.org/#/c/409432/
[2] https://review.openstack.org/#/c/413994/

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl



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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Flavio Percoco]

On 21/12/16 07:22 -0800, Ian Cordasco wrote:

Hey everyone,

It seems a contributor has written a script to add CONTRIBUTING.rst
files to each OpenStack project that exists. [1]

As a community we've struggled with new contributors creating tonnes
of patches like this at once, and that is emphatically not the purpose
of this email. Instead, I'd like to discuss the actual merits of this
change for OpenStack.

What is CONTRIBUTING.rst?
=

It's a convention created by GitHub to make up for the lack of issue
templating and encourage collaborators/contributors to read some
documentation before filing new issues or pull requests. It does this
by adding an unobtrusive link at the top of the New Issue and New Pull
Request pages for projects that have these files.

In my experience using these files on projects, they've been wildly ineffective.

Is there value in having a CONTRIBUTING.rst to OpenStack?
=

Well, let's consider a few things:

* The canonical source for OpenStack repositories is https://git.openstack.org/
* OpenStack /mirrors/ to GitHub so when we add Badges to our README,
they're displayed there for people who find the projects there
* OpenStack auto-closes all pull requests made to the GitHub mirrors
with instructions on how to contribute
* Having these files isn't really a *standard*. Other services
(GitLab, BitBucket) have added support for these files, but when you
look at projects not hosted on one of those service, these files
aren't as common.
* GitHub now allows the files that they look for to be in a .github
directory so the root of the repository isn't cluttered with markdown
and other files that only GitHub cares about for providing poorly made
bandaids for serious issues in their platform.

I'm not sure there's a great deal of benefit to OpenStack projects in
these patches. I'm sure most of us don't ever look to see how many
pull requests get opened against the GitHub mirrors. I doubt these
files would stop anyone from sending pull requests there in the first
place (based entirely on my own, purely anecdotal experiences).

Further, OpenStack already has a great deal of cross-project and
project-specific documentation around contributing that's easily
findable. Making that slightly more discoverable probably isn't a bad
thing.

On top of that, some projects have had CONTRIBUTING.rst files for a
while (Glance's goes back at least to 2014). Standardization about
where to look for that info wouldn't hurt us at all.

That said, I think there are two better places for this information
that are already standards in OpenStack:

* README.rst
* HACKING.rst

Most projects include links to the contributing documentation in at
least one of these files. I think the effort here is to standardize,
albeit in a brand new file, and that's admirable.



So, I'd even take it a step further. Standardizing the README files wouldn't
hurt either. I'm not suggesting that the entire README file should be the same
for everyone but we could have a common header/top sections for every project.

I recently hit this issue when submitting patches to add badges to the README
file and, understandably, some projects weren't too happy with how the top title
section looked like. If we can make this a simple community goal, I believe it'd
be valuable.

Recardless of whether the README and HACKING files are rendered, I believe some
consistency across repos would be great. I look at README files on cloned repos
too, I don't use GH to read these files if I already have them locally.

Flavio



If you look at the gerrit query, some projects have already merged or
abandoned some of the patches. Let's see if we can come to an
agreement about how to improve the experience for people finding our
projects and wanting to collaborate with us.

[1]: 
https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur.com+topic:addCONTRIBUTING.rst
--
Ian Cordasco

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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Anne Gentle]

On Thu, Dec 22, 2016 at 8:32 AM, Doug Hellmann 
wrote:

> Excerpts from Ian Cordasco's message of 2016-12-22 06:46:29 -0600:
> >
> > There is some ambiguity right now with projects as to where to put
> > easy-to-find documentation (even if it is just a brief paragraph with
> > a link to longer-form documentation) into our repositories. Let's
> > focus on that discussion here. We can come up with a productive
> > conclusion and work with this contributor. While you've chosen (and
> > yes, you've chosen this) to have a negative assumption about this
> > contributor's efforts, I've chosen to believe they're looking to fill
> > a gap. Increasing the productivity of new contributors to OpenStack is
> > a positive improvement for our community. It may not fix a bug or add
> > a feature, but it helps ramp up the people who will do that.
>
> I thought we started adding these contributing files specifically
> because of how they are rendered on github, as a way to try to prevent
> folks from submitting pull requests there and then having them rejected
> by the bot. It seemed more positive to give direction ahead of time than
> through a rejection message.
>

+1 to this and Ian and Alex's sentiments.

It'd be great to get people to click one more time (to a more specific
contributor guide), but let's face it, there has to be a lot of traffic
directly to github.com. Let's make sure there's a decent entry.

Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be .md
for github, Ian?) for all projects? Is it similar to the nova 2012 version
or is there a more modern take?

Anne


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



-- 

Read my blog: justwrite.click 
Subscribe to Docs|Code: docslikecode.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [L2-Gateway] RPM packaging and Agent configuration

[Ricardo Noriega De Soto]

Thanks a lot Ofer!!

Just one more question, the command to start the agent is fine, but, do we
need to include the l2gateway_plugin.ini to Neutron server???

Something like:

/usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf
--config-dir /usr/share/neutron/server --config-file
/etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini
--config-dir /etc/neutron/conf.d/common --config-dir
/etc/neutron/conf.d/neutron-server --log-file
/var/log/neutron/server.log *--config-file
/etc/neutron/l2gateway_plugin.ini *???

Thanks!!

On Sun, Dec 18, 2016 at 8:33 AM, Ofer Ben-Yacov 
wrote:

> The command that you've wrote for the agent is correct.
> No need to add anything.
>
> Ofer.
>
> On 16 December 2016 at 16:12, Ricardo Noriega De Soto  > wrote:
>
>> Hello L2GW devs!
>>
>> I'm currently working on the RPM packaging of networking-l2gw project.
>>
>> My undestanding is that depending on the config, I could use whether
>> OpenDaylight or the neutron-l2gw-agent as backend.
>>
>> For the latter case, I'm writing a systemd unit file, but I'd love to get
>> the command of how you launch the agent itself. I would say it's something
>> like:
>>
>> https://paste.fedoraproject.org/507402/89715214/
>>
>> /usr/bin/neutron-l2gw-agent --config-file /etc/neutron/neutron.conf
>> --config-file /etc/neutron/l2gateway_agent.ini  --log-file
>> /var/log/neutron/l2gw-agent.log
>>
>> Anything to add??
>>
>> Thanks!
>>
>> --
>> Ricardo Noriega
>>
>> Senior Software Engineer - NFV Partner Engineer | Office of Technology
>>  | Red Hat
>> irc: rnoriega @freenode
>>
>>
>> 
>> __
>> 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
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing 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] [release] reno 2.0.0

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2016-12-21 15:54:44 -0500:
> This new version of reno is a major rewrite of the repository scanner
> logic and includes some breaking changes to the internal API (the
> command line remains the same). Those changes broke the release
> announcement job, and we're working on getting that fixed. In the
> mean time, I wanted to make sure folks were aware that the new
> version is out there, in case you start seeing build issues.
> 
> The release notes at http://docs.openstack.org/developer/reno/history.html
> are up to date, even though the version number looks wrong there.
> 
> Doug
> 

We've just tagged 2.0.1 to fix the issue some projects saw gathering
release notes on branches that had no tag at their base.

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

[openstack-dev] [neutron] team meeting calendar

[Armando M.]

Hi folks,

Due to the holiday period we'll cancel the following meeting occurrences:

Dec 26
Jan 3

We'll meet again on Jan 9.

Happy holidays!
Armando
__
OpenStack Development Mailing 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] drivers meeting calendar

[Armando M.]

Hi folks,

Due to the holiday period we'll cancel the following meeting occurrences:

Dec 22
Dec 29
Jan 5

We'll meet again on Jan 12.

Happy holidays!
Armando
__
OpenStack Development Mailing 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] [Ironic] python-ironicclient weird behaviour

[Maxime Belanger]

Hi Ironic folks,


Yesterday I come across a weird behaviour in python-ironicclient. I discussed 
briefly with the problem with Julia and befor creating a bug I would like your 
opinion on the problem and potential fix.


When doing nodes.get(resource_id=None), I get back a Node object set with 
attribute nodes={nodes: [{uuid: 'blah'}, {uuid: 'bleh'}]}. I guess that is not 
expected which is the bug I found and I know where to fix it if we agree to not 
change the behavour: If resource_id=None the client is doing a GET on /v1/nodes 
which is expected here : 
https://github.com/openstack/python-ironicclient/blob/1.8.0/ironicclient/common/base.py#L55.


The thing is, returning the first item of the list while doing a get on 
something that doesn't exists is a bit strange. I do not want to do extra 
validation on my application side to not pass None to the ironicclient. I would 
it to behave correctly: 404 or a even a 400.


What do you think/or prefer?


A. Fixing the bug and not changing actual behaviour of the API

B. Changing the API behaviour and returning a 404 error since resource None is 
not found

C. Changing the API behaviour and returning a 400 error because None is not a 
valid request. The will be identical to the command line that is doing this:

ironic node-show None
Invalid input for field/attribute node_ident. Value: 'None'. unable to convert 
to uuid_or_name (HTTP 400)

Thanks
Max

__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Doug Hellmann]

Excerpts from Ian Cordasco's message of 2016-12-22 06:46:29 -0600:
> 
> There is some ambiguity right now with projects as to where to put
> easy-to-find documentation (even if it is just a brief paragraph with
> a link to longer-form documentation) into our repositories. Let's
> focus on that discussion here. We can come up with a productive
> conclusion and work with this contributor. While you've chosen (and
> yes, you've chosen this) to have a negative assumption about this
> contributor's efforts, I've chosen to believe they're looking to fill
> a gap. Increasing the productivity of new contributors to OpenStack is
> a positive improvement for our community. It may not fix a bug or add
> a feature, but it helps ramp up the people who will do that.

I thought we started adding these contributing files specifically
because of how they are rendered on github, as a way to try to prevent
folks from submitting pull requests there and then having them rejected
by the bot. It seemed more positive to give direction ahead of time than
through a rejection message.

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] [docs] Stepping down from core

[Christian Berendt]

Matt, I wish you the best and much success on your further journey. In the past 
I was able to learn a lot from you and I always appreciated your work.

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Alexandra Settle]

My recommendation, as a documenter for OpenStack, would be to include a link to 
each project’s contributor guidelines (as most tend to keep in their developer 
documentation pages) in the README file.

I appreciate the README as previously not always been for this purpose, but I 
believe it would be beneficial to include a link and not to create a whole new 
file for the purpose of 3 lines.

I have had people in the past ask me how to contribute to individual project 
repositories, not knowing that each project has developer documentation that 
includes contributing documentation. There is clearly a gap, and this is just 
one option to fix that.

I appreciate if people disagree whoever, I don’t overly believe this is a 
necessary step as the contributor guidelines are already documented and this is 
a form of duplication.

Cheers,

Alex

On 12/22/16, 12:46 PM, "Ian Cordasco"  wrote:

On Wed, Dec 21, 2016 at 11:20 PM, Zhenyu Zheng
 wrote:
> Agreed with Amrith, it might be useful and maybe also good for new
> contributors to learn how to have a commit to OpenStack. BUT over 130
> identical patches to 130 different projects from one company/person in one
> run? I don't think this is going to help OpenStack growing. We should not
> let this happen.
>
> On Thu, Dec 22, 2016 at 12:44 AM, Amrith Kumar  wrote:
>>
>> For those who would like to know exactly what this set of changes cost in
>> the CI, the answer is approximately 1050 jobs which consumed 190 compute
>> hours of CI time.
>>
>> -amrith
>>
>> -Original Message-
>> From: Amrith Kumar [mailto:amr...@tesora.com]
>> Sent: Wednesday, December 21, 2016 11:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
>> projects
>>
>> Ian, Andreas, Emilien,
>>
>> My sentiments on the subject of these kinds of "production line" changes
>> is unchanged from [1] and [2]. A complete list of these changes is at 
[3].
>>
>> I've updated all of the changes in this thread with a block comment and a
>> -1. My apologies to other reviewers (and active contributors in those
>> projects) for this automated comment across 131 commits.
>>
>> It is high time we eliminated these kinds of changes which do little to
>> improve the overall quality of the product and serve merely to generate a
>> huge amount of pointless work on the CI systems, and boost some 
meaningless
>> statistics that someone wants to put on a slide someplace.
>>
>> -amrith
>>
>> [1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
>> [2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
>> [3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

So, I want to reiterate why I started this thread:

I want a productive outcome of this contributor's efforts. -1'ing
everyone of their changes was not something I was looking for. Having
people pile on after those -1s is also not something that leads to a
productive outcome.

Yes, these mass produced changes are annoying. I get it. We're all a
little jaded, ostensibly because we've all seen the statistical
nonsense that people at our very own companies use for marketing or
whatever else. I understand it quite well.

All of that aside, I specifically asked that we not turn this thread into 
that.

There is some ambiguity right now with projects as to where to put
easy-to-find documentation (even if it is just a brief paragraph with
a link to longer-form documentation) into our repositories. Let's
focus on that discussion here. We can come up with a productive
conclusion and work with this contributor. While you've chosen (and
yes, you've chosen this) to have a negative assumption about this
contributor's efforts, I've chosen to believe they're looking to fill
a gap. Increasing the productivity of new contributors to OpenStack is
a positive improvement for our community. It may not fix a bug or add
a feature, but it helps ramp up the people who will do that.

So please, let's keep this productive. If you want to discuss ways of
ratelimiting patchset contributions or some other nonsense, please
start a new thread.

Cheers,
-- 
Ian Cordasco

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

[openstack-dev] [swg][tc] meeting today (12/22) cancelled

[Colette Alexander]

Hi there everyone!

On account of it being a vacation week for many of us who have holidays
coming up, I'm going to cancel today's meeting.

We'll be continuing discussion of work items towards our next meeting (Jan
5) in the #openstack-swg channel. Please join us there!

Thanks!

-colette/gothicmindfood
__
OpenStack Development Mailing 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] Adding CONTRIBUTING.rst files to projects

[Ian Cordasco]

On Wed, Dec 21, 2016 at 11:20 PM, Zhenyu Zheng
 wrote:
> Agreed with Amrith, it might be useful and maybe also good for new
> contributors to learn how to have a commit to OpenStack. BUT over 130
> identical patches to 130 different projects from one company/person in one
> run? I don't think this is going to help OpenStack growing. We should not
> let this happen.
>
> On Thu, Dec 22, 2016 at 12:44 AM, Amrith Kumar  wrote:
>>
>> For those who would like to know exactly what this set of changes cost in
>> the CI, the answer is approximately 1050 jobs which consumed 190 compute
>> hours of CI time.
>>
>> -amrith
>>
>> -Original Message-
>> From: Amrith Kumar [mailto:amr...@tesora.com]
>> Sent: Wednesday, December 21, 2016 11:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
>> projects
>>
>> Ian, Andreas, Emilien,
>>
>> My sentiments on the subject of these kinds of "production line" changes
>> is unchanged from [1] and [2]. A complete list of these changes is at [3].
>>
>> I've updated all of the changes in this thread with a block comment and a
>> -1. My apologies to other reviewers (and active contributors in those
>> projects) for this automated comment across 131 commits.
>>
>> It is high time we eliminated these kinds of changes which do little to
>> improve the overall quality of the product and serve merely to generate a
>> huge amount of pointless work on the CI systems, and boost some meaningless
>> statistics that someone wants to put on a slide someplace.
>>
>> -amrith
>>
>> [1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
>> [2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
>> [3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

So, I want to reiterate why I started this thread:

I want a productive outcome of this contributor's efforts. -1'ing
everyone of their changes was not something I was looking for. Having
people pile on after those -1s is also not something that leads to a
productive outcome.

Yes, these mass produced changes are annoying. I get it. We're all a
little jaded, ostensibly because we've all seen the statistical
nonsense that people at our very own companies use for marketing or
whatever else. I understand it quite well.

All of that aside, I specifically asked that we not turn this thread into that.

There is some ambiguity right now with projects as to where to put
easy-to-find documentation (even if it is just a brief paragraph with
a link to longer-form documentation) into our repositories. Let's
focus on that discussion here. We can come up with a productive
conclusion and work with this contributor. While you've chosen (and
yes, you've chosen this) to have a negative assumption about this
contributor's efforts, I've chosen to believe they're looking to fill
a gap. Increasing the productivity of new contributors to OpenStack is
a positive improvement for our community. It may not fix a bug or add
a feature, but it helps ramp up the people who will do that.

So please, let's keep this productive. If you want to discuss ways of
ratelimiting patchset contributions or some other nonsense, please
start a new thread.

Cheers,
-- 
Ian Cordasco

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

Re: [openstack-dev] [Ironic] Retiring ironic-webclient

[Gerard Braad]

Hi


On Tuesday, December 20, 2016, Julia Kreger 
wrote:
> As discussed at the last summit during the contributor meet-up, as well
as during today’s Ironic team meeting[0], we will be retiring the
ironic-webclient.

> no contributions have landed in the last six months

I made a small contribution to the documentation in July and made sure this
got rechecked and included. If this will move to the attic, at least people
will be able to deploy and use it.

Thanks,


Gerard

-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]
__
OpenStack Development Mailing 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][dragonflow] advertise_mtu option to be removed

[Ihar Hrachyshka]

Hi all,

I plan to remove the deprecated advertise_mtu option with  
https://review.openstack.org/413567


I checked projects still using the option, and the only project to be hit  
by the change seems to be dragonflow. I proposed a fix at:  
https://review.openstack.org/414047


Please make sure that your plugin does not access the option  
programatically, otherwise your plugin may break after we land the neutron  
patch. If you have more related patches for your project, please reuse the  
topic:


https://review.openstack.org/#/q/topic:advertise-mtu-removal

We will also announce the patch on one of next team meetings.

Thanks,
Ihar

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

Re: [openstack-dev] Proposing Steve Martinelli for project-team-guide core

[Steve Martinelli]

Thanks! Happy to help guard another gate :)

On Dec 22, 2016 4:52 AM, "Thierry Carrez"  wrote:

> Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2016-12-20 16:18:15 +0100:
> >> Hi everyone,
> >>
> >> As you probably know, the OpenStack Project Team Guide is a piece of
> >> documentation geared towards project teams, to help them navigate the
> >> troubled and complex waters of being an official OpenStack team:
> >>
> >> http://docs.openstack.org/project-team-guide/
> >>
> >> Steve Martinelli has been doing a great job of proposing and reviewing
> >> changes proposed to the guide, and we can always use some help there, so
> >> I'd like to propose that he joins the core team.
> >>
> >
> > +1, Steve has been helpful with reviews lately.
>
> Added!
>
> --
> 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
>
__
OpenStack Development Mailing 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] Proposing Steve Martinelli for project-team-guide core

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2016-12-20 16:18:15 +0100:
>> Hi everyone,
>>
>> As you probably know, the OpenStack Project Team Guide is a piece of
>> documentation geared towards project teams, to help them navigate the
>> troubled and complex waters of being an official OpenStack team:
>>
>> http://docs.openstack.org/project-team-guide/
>>
>> Steve Martinelli has been doing a great job of proposing and reviewing
>> changes proposed to the guide, and we can always use some help there, so
>> I'd like to propose that he joins the core team.
>>
> 
> +1, Steve has been helpful with reviews lately.

Added!

-- 
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] [docs] Stepping down from core

[Alexandra Settle]

I’m sorry to see you go, Matt ☹

Thank you for being an amazing and consistent contributor to the documentation 
project. Your work has been invaluable to the Networking community and I know 
many (including myself) have appreciated your tireless efforts on the 
Installation Guide.

Good luck and all the best,

Alex

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

Date: Wednesday, December 21, 2016 at 4:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [docs] Stepping down from core

Howdy!

After several years of contributing to OpenStack documentation, a significant 
change in my career path warrants resigning from my role as a core reviewer. 
Working with the OpenStack community was a great experience and I hope it 
continues to grow... with sufficient documentation, of course.

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