Re: [openstack-dev] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

I don't see any exception using bellow command


root@szxbz:/opt/stack/neutron# neutron port-update 
3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
Allowed address pairs must be a list.




At 2015-09-28 14:36:44, "masoom alam"  wrote:

stable KILO


shall I checkout the latest code are you saying this...Also can you please 
confirm if you have tested this thing at your endand there was no problem...




Thanks


On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang  wrote:

which branch do you use?  there is not this problem in master branch.






At 2015-09-28 13:43:05, "masoom alam"  wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks








网易考拉iPhone6s玫瑰金5288元，现货不加价


__
OpenStack Development Mailing 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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[masoom alam]

stable KILO

shall I checkout the latest code are you saying this...Also can you please
confirm if you have tested this thing at your endand there was no
problem...


Thanks

On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang  wrote:

> which branch do you use?  there is not this problem in master branch.
>
>
>
>
>
> At 2015-09-28 13:43:05, "masoom alam"  wrote:
>
> Can anybody highlight why the following command is throwing an exception:
>
> *Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
> --allowed-address-pairs action=clear
>
> *Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
> [req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most
> recent call last):
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result =
> method(request=request, **args)
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
> allow_bulk=self._allow_bulk)
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/base.py", line 652, in
> prepare_request_body
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
> attr_vals['validate'][rule])
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in
> _validate_allowed_address_pairs
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if
> len(address_pairs) > cfg.CONF.max_allowed_address_pair:
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of
> type 'NoneType' has no len()
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>
>
>
> There is a similar bug filed at Lauchpad for Havana
> https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there
> is no fix and the work around  - using curl, mentioned on the bug is also
> not working for KILO...it was working for havana and Icehouseany
> pointers...?
>
> Thanks
>
>
>
>
> 网易考拉iPhone6s玫瑰金5288元，现货不加价
> 
>
> __
> OpenStack Development Mailing 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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

which branch do you use?  there is not this problem in master branch.





At 2015-09-28 13:43:05, "masoom alam"  wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks



__
OpenStack Development Mailing 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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[masoom alam]

Can anybody highlight why the following command is throwing an exception:

*Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
--allowed-address-pairs action=clear

*Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most
recent call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result =
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in
prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if
len(address_pairs) > cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of
type 'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource



There is a similar bug filed at Lauchpad for Havana
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is
no fix and the work around  - using curl, mentioned on the bug is also not
working for KILO...it was working for havana and Icehouseany
pointers...?

Thanks
__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

[Brandon Logan]

Is there a lot of people requesting this meeting change?

Thanks,
Brandon

On Fri, 2015-09-25 at 23:58 +, Eichberger, German wrote:
> All,
> 
> In our last meeting [1] we discussed moving the meeting earlier to
> accommodate participants from the EMEA region. I am therefore proposing to
> move the meeting to 16:00 UTC on Wednesday. Please respond to this e-mail
> if you have alternate suggestions. I will send out another e-mail
> announcing the new time and the date we will start with that.
> 
> Thanks,
> German
> 
> [1] 
> http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-20.
> 00.log.html
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 9/21

[Dugger, Donald D]

Meeting on #openstack-meeting-alt at 1400 UTC (8:00AM MDT)



1) Mitaka planning

2) Opens

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
OpenStack Development Mailing 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] [cinder] should we use fsync when writing iscsi config file?

[Chris Friesen]

On 09/26/2015 02:48 AM, Julien Danjou wrote:

On Tue, Sep 22 2015, Chris Friesen wrote:


On 09/22/2015 05:48 PM, Joshua Harlow wrote:

A present:

  >>> import contextlib
  >>> import os
  >>>
  >>> @contextlib.contextmanager
... def synced_file(path, mode='wb'):
...   with open(path, mode) as fh:
...  yield fh
...  os.fdatasync(fh.fileno())
...
  >>> with synced_file("/tmp/b.txt") as fh:
...fh.write("b")


Isn't that missing an "fh.flush()" somewhere before the fdatasync()?


Unless proven otherwise, close() does a flush().


There's no close() before the fdatasync() in the above code.  (And it wouldn't 
make sense anyway because you need the open fd to do the fdatasync().)


Chris


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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell and Kevin,

Thanks for your detail information!
I got it.

Thanks again,
Tony

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Monday, September 28, 2015 4:18 AM
To: Kevin Benton; OpenStack Development Mailing List (not for usage questions)
Cc: WANG, Ming Hao (Tony T)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

On 09/27/2015 06:50 AM, Kevin Benton wrote:
> Assuming it implements the normal provider networks API, you just 
> specify the segmentation_id when you create the network.
> 
> neutron net-create NET_NAME --provider:network_type vlan 
> --provider:physical_network physnet1 --provider:segmentation_id 
> VLAN_TAG

Yes, the OVN plugin will implement the normal provider networks API.
It's a WIP.

My first goal was to just implement support for "--provider:network_type flat" 
end to end.  I have the OVN side merged and now I'm working on the Neutron 
plugin piece.  Once that's done, I'll go back add add VLAN support, which 
shouldn't be very difficult at that point.  I'm aiming to have all of that done 
by the Tokyo summit (among other things).

> On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T) 
>  >
> wrote:
> 
> Russell,
> 
> Another question is about "localnet". It is a very useful feature. 
> :-)
> 
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> 
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN
> tag translation done by "br-int" or "br-eth1"?


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

[openstack-dev] [oslo][doc] Oslo Doc Sprint final Tally (was Re: [oslo][doc] Oslo doc sprint 9/24-9/25)

[Davanum Srinivas]

Hello,

We had a very good Doc Sprint. Thanks everyone who contributed.

Finally tally: Merged 88 commits across 20+ repos and gained one core
commiter! :)

Huge welcome to Brant Knudson. The full list of reviews are at the bottom
of the etherpad [1]

Thanks,
Dims

[1] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint

On Wed, Sep 23, 2015 at 7:18 PM, Davanum Srinivas  wrote:

> Reminder, we are doing the Doc Sprint tomorrow. Please help out with what
> ever item or items you can.
>
> Thanks,
> Dims
>
> On Wed, Sep 16, 2015 at 5:40 PM, James Carey  > wrote:
>
>> In order to improve the Oslo libraries documentation, the Oslo team is
>> having a documentation sprint from 9/24 to 9/25.
>>
>> We'll kick things off at 14:00 UTC on 9/24 in the
>> #openstack-oslo-docsprint IRC channel and we'll use an etherpad [0].
>>
>> All help is appreciated.   If you can help or have suggestions for
>> areas of focus, please update the etherpad.
>>
>> [0] https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint
>>
>> __
>> OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [puppet] Fwd: Action required: stackforge/puppet-openstack project move

[Jeremy Stanley]

On 2015-09-27 18:37:59 -0600 (-0600), Matt Fischer wrote:
> On Sep 27, 2015 6:09 PM, "Emilien Macchi"  wrote:
> > 
> > should we delete it?
> 
> I'm not sure what value it has anymore but why not just readonly?

We aren't deleting any repos, just making them read-only and
committing a change to replace all the files with a README
indicating the repo is retired (and indicating to look at the HEAD^1
commit for its prior state).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [puppet] Fwd: Action required: stackforge/puppet-openstack project move

[Matt Fischer]

I'm not sure what value it has anymore but why not just readonly?
On Sep 27, 2015 6:09 PM, "Emilien Macchi"  wrote:

> should we delete it?
>
> FYI: the module is deprecated in Juno release.
>
> I vote for yes.
>
>
>  Forwarded Message 
> Subject: Action required: stackforge/puppet-openstack project move
> Date: Fri, 25 Sep 2015 21:57:10 +
> From: OpenStack Infrastructure Team 
> To: clayton.one...@twcable.com, coll...@gazlene.net, bod...@gmail.com,
> dpri...@redhat.com, emil...@redhat.com, francois.charl...@redhat.com,
> mga...@iweb.com, m...@mattfischer.com, wop...@gmail.com,
> sba...@redhat.com, xingc...@unitedstack.com, yguen...@redhat.com
>
> You appear to be associated with the stackforge/puppet-openstack project.
>
> The stackforge/ git repository namespace is being retired[1], and all
> projects within need to move to the openstack/ namespace or, in the
> case of inactive projects, identified as such and made read-only.
>
> For more background information, see this mailing list post and TC
> resolution:
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html
>
>
> http://governance.openstack.org/resolutions/20150615-stackforge-retirement.html
>
> To ensure we have correctly identified all of the projects, we have
> created a wiki page listing the projects that should be moved and the
> projects that should be retired.  You may find it here:
>
>   https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement
>
> Please add the stackforge/puppet-openstack project to the appropriate
> list on this page ("Active Projects to Move" or "Inactive Projects to
> Retire") as soon as possible.
>
> Projects that have not self-categorized by Friday October 2 will be
> assumed to be inactive and placed on the list of "Inactive Projects to
> Retire".
>
> Thank you for attending to this promptly,
>
> The OpenStack Infrastructure Team
>
>
>
> __
> OpenStack Development Mailing 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] [puppet] Fwd: Action required: stackforge/puppet-openstack project move

[Emilien Macchi]

should we delete it?

FYI: the module is deprecated in Juno release.

I vote for yes.


 Forwarded Message 
Subject: Action required: stackforge/puppet-openstack project move
Date: Fri, 25 Sep 2015 21:57:10 +
From: OpenStack Infrastructure Team 
To: clayton.one...@twcable.com, coll...@gazlene.net, bod...@gmail.com,
dpri...@redhat.com, emil...@redhat.com, francois.charl...@redhat.com,
mga...@iweb.com, m...@mattfischer.com, wop...@gmail.com,
sba...@redhat.com, xingc...@unitedstack.com, yguen...@redhat.com

You appear to be associated with the stackforge/puppet-openstack project.

The stackforge/ git repository namespace is being retired[1], and all
projects within need to move to the openstack/ namespace or, in the
case of inactive projects, identified as such and made read-only.

For more background information, see this mailing list post and TC
resolution:

  http://lists.openstack.org/pipermail/openstack-dev/2015-August/072140.html

http://governance.openstack.org/resolutions/20150615-stackforge-retirement.html

To ensure we have correctly identified all of the projects, we have
created a wiki page listing the projects that should be moved and the
projects that should be retired.  You may find it here:

  https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement

Please add the stackforge/puppet-openstack project to the appropriate
list on this page ("Active Projects to Move" or "Inactive Projects to
Retire") as soon as possible.

Projects that have not self-categorized by Friday October 2 will be
assumed to be inactive and placed on the list of "Inactive Projects to
Retire".

Thank you for attending to this promptly,

The OpenStack Infrastructure Team



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

Re: [openstack-dev] [Openstack-operators] [puppet] feedback request about puppet-keystone

[Matt Fischer]

On Fri, Sep 25, 2015 at 11:01 AM, Emilien Macchi  wrote:
>
>
> So after 5 days, here is a bit of feedback (13 people did the poll [1]):
>
> 1/ Providers
> Except for 1, most of people are managing a few number of Keystone
> users/tenants.
> I would like to know if it's because the current implementation (using
> openstackclient) is too slow or just because they don't need to do that
> (they use bash, sdk, ansible, etc).
>

I'm generally thinking the opposite of you, I'd actually love to know the
use case for anyone managing more than a few users with Puppet. We have
service users and a few accounts for things like backups, monitoring etc.
Beyond that, the accounts are for actual users and they have to follow an
intake and project creation process that also handles things like networks.
We found this workflow much easier to script with python and it can also be
done without a deploy. This is all handled by a manager after ensuring that
OpenStack is the right solution for them, finding project requirements,
etc. So I think this is what many folks are doing, their user creation
workflow just doesn't mesh with puppet and their puppet deployment process.
 (This also discounts password management, something I don't want to be
doing for users with puppet)



>
> 2/ Features you want
>
> * "Configuration of federation via shibboleth":
> WIP on https://review.openstack.org/#/c/216821/
>
> * "Configuration of federation via mod_mellon":
> Will come after shibboleth I guess.
>
> * "Allow to configure websso"":
> See
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/enabling-federation.html
>
> * "Management of fernet keys":
> nothing *yet* in our roadmap AFIK, adding it in our backlog [2]
>

I looked into this when we deployed but could not come up with a great
solution that didn't involve declaring a master node on which keys were
generated. Would be happy to re-investigate or work with someone on this.


>
> * "Support for hybrid domain configurations (e.g. using both LDAP and
> built in database backend)":
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/liberty/support-for-keystone-domain-configuration.html
>
> * "Full v3 API support (depends on other modules beyond just
> puppet-keystone)":
>
> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html
>
> * "the ability to upgrade modules independently of one another, like we
> do in production - currently the puppet dependencies dictate the order
> in which we do upgrades more than the OpenStack dependencies":
>
> During the last Summit, we decided [3] as a community that our modules
> branches will only support the OpenStack release of the branch.
> ie: stable/kilo supports OpenStack 2015.1 (Kilo). Maybe you can deploy
> Juno or Liberty with it, but our community does not support it.
> To give a little background, we already discussed about it [4] on the ML.
> Our interface is 100% (or should be) backward compatible for at least
> one full cycle, so you should not have issue when using a new version of
> the module with the same parameters. Though (and indeed), you need to
> keep your modules synchronized, specially because we have libraries and
> common providers (in puppet-keystone).
> AFIK, OpenStack also works like this with openstack/requirements.
> I'm not sure you can run Glance Kilo with Oslo Juno (maybe I'm wrong).
> What you're asking would be technically hard because we would have to
> support old versions of our providers & libraries, with a lot of
> backward compatible & legacy code in place, while we already do a good
> job in the parameters (interface).
> If you have any serious proposal, we would be happy to discuss design
> and find a solution.
>
> 3/ What we could improve in Puppet Keystone (and in general, regarding
> the answers)
>
> * "(...) but it would be nice to be able to deploy master and the most
> recent version immediately rather than wait. Happy to get involved with
> that as our maturity improves and we actually start to use the current
> version earlier. Contribution is hard when you folk are ahead of the
> game, any fixes and additions we have are ancient already":
>
> I would like to understand the issues here:
> do you have problems to contribute?
> is your issue "a feature is in master and not in stable/*" ? If that's
> the case, that means we can do a better job in backport policy.
> Something we already talked each others and I hope our group is aware
> about that.
>
> * "We were using keystone_user_role until we had huge compilation times
> due to the matrix (tenant x role x user) that is not scalable. With
> every single user and tenant on the environment, the catalog compilation
> increased. An improvement on that area will be useful."
>
> I understand the frustration and we are working on it [5].
>
> * "Currently does not handle deployment of hybrid domain configurations."
>
> Ditto:
>
> http://specs.openstack.org/openstack/puppet-opensta

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 06:50 AM, Kevin Benton wrote:
> Assuming it implements the normal provider networks API, you just
> specify the segmentation_id when you create the network. 
> 
> neutron net-create NET_NAME --provider:network_type vlan
> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG

Yes, the OVN plugin will implement the normal provider networks API.
It's a WIP.

My first goal was to just implement support for "--provider:network_type
flat" end to end.  I have the OVN side merged and now I'm working on the
Neutron plugin piece.  Once that's done, I'll go back add add VLAN
support, which shouldn't be very difficult at that point.  I'm aiming to
have all of that done by the Tokyo summit (among other things).

> On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T)
> mailto:tony.a.w...@alcatel-lucent.com>>
> wrote:
> 
> Russell,
> 
> Another question is about "localnet". It is a very useful feature. :-)
> 
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> 
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN
> tag translation done by "br-int" or "br-eth1"?


-- 
Russell Bryant

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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Russell Bryant]

On 09/27/2015 02:26 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your valuable information.
> I understood Geneve is some kind of tunnel format for network virtualization 
> encapsulation, just like VxLAN.
> But I'm still confused by the connection between Geneve and VTEP.
> I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should 
> be used for VxLAN only.
> 
> Does it become some "common tunnel endpoint" in OVN, and can be also used as 
> a tunnel endpoint for Geneve?

When using VTEP gateways, both the Geneve and VxLAN protocols are being
used.  Packets between hypervisors are sent using Geneve.  Packets
between a hypervisor and the gateway are sent using VxLAN.

-- 
Russell Bryant

__
OpenStack Development Mailing 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] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

[Bertrand LALLAU]

Hi all,
Living in France I prefer the previous meeting time (20:00 UTC)
regards,

On Sat, Sep 26, 2015 at 3:30 AM, Doug Wiegley 
wrote:

> Works for me.
>
> Doug
>
>
> > On Sep 25, 2015, at 5:58 PM, Eichberger, German <
> german.eichber...@hpe.com> wrote:
> >
> > All,
> >
> > In our last meeting [1] we discussed moving the meeting earlier to
> > accommodate participants from the EMEA region. I am therefore proposing
> to
> > move the meeting to 16:00 UTC on Wednesday. Please respond to this e-mail
> > if you have alternate suggestions. I will send out another e-mail
> > announcing the new time and the date we will start with that.
> >
> > Thanks,
> > German
> >
> > [1]
> >
> http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-20
> .
> > 00.log.html
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Armando M.]

On 25 September 2015 at 15:40, Chris Hoge  wrote:

> In November, the OpenStack Foundation will start requiring vendors
> requesting
> new "OpenStack Compatible" storage driver licenses to start passing the
> Cinder
> third-party integration tests.

The new program was approved by the Board at
> the July meeting in Austin and follows the improvement of the testing
> standards
> and technical requirements for the "OpenStack Powered" program. This is all
> part of the effort of the Foundation to use the OpenStack brand to
> guarantee a
> base-level of interoperability and consistency for OpenStack users and to
> protect the work of our community of developers by applying a trademark
> backed
> by their technical efforts.
>
> The Cinder driver testing is the first step of a larger effort to apply
> community determined standards to the Foundation marketing programs. We're
> starting with Cinder because it has a successful testing program in place,
> and
> we have plans to extend the program to network drivers and OpenStack
> applications. We're going require CI testing for new "OpenStack Compatible"
> storage licenses starting on November 1, and plan to roll out network and
> application testing in 2016.
>
> One of our goals is to work with project leaders and developers to help us
> define and implement these test programs. The standards for third-party
> drivers and applications should be determined by the developers and users
> in our community, who are experts in how to maintain the quality of the
> ecosystem.
>
> We welcome and feedback on this program, and are also happy to answer any
> questions you might have.
>

Thanks for spearheading this effort.

Do you have more information/pointers about the program, and how Cinder in
particular is
paving the way for other projects to follow?

Thanks,
Armando


> Thanks!
>
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> __
> OpenStack Development Mailing 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] [glance][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
> > 
> > Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> >> On Sep 25, 2015, at 1:24 PM, Brian Rosmaita  
> >> wrote:
> >>> 
> >>> I'd like to clarify something.
> >>> 
> >>> On 9/25/15, 12:16 PM, "Mark Voelker"  wrote:
> >>> [big snip]
>  Also worth pointing out here: when we talk about ³doing the same thing²
>  from a DefCore perspective, we¹re essentially talking about what¹s
>  exposed to the end user, not how that¹s implemented in OpenStack¹s source
>  code.  So from an end user¹s perspective:
>  
>  If I call nova image-create, I get an image in my cloud.  If I call the
>  Glance v2 API to create an image, I also get an image in my cloud.  I
>  neither see nor care that Nova is actually talking to Glance in the
>  background, because if I¹m writing code that uses the OpenStack API¹s, I
>  need to pick which one of those two API¹s to make my code call upon to
>  put an image in my cloud.  Or, in the worst case, I have to write a bunch
>  of if/else loops into my code because some clouds I want to use only
>  allow one way and some allow only the other.
> >>> 
> >>> The above is a bit inaccurate.
> >>> 
> >>> The nova image-create command does give you an image in your cloud.  The
> >>> image you get, however, is a snapshot of an instance that has been
> >>> previously created in Nova.  If you don't have an instance, you cannot
> >>> create an image via that command.  There is no provision in the Compute
> >>> (Nova) API to allow you to create an image out of bits that you supply.
> >>> 
> >>> The Image (Glance) APIs (both v1 and v2) allow you to supply the bits and
> >>> register them as an image which you can then use to boot instances from by
> >>> using the Compute API.  But note that if all you have available is the
> >>> Images API, you cannot create an image of one of your instances.
> >>> 
>  So from that end-user perspective, the Nova image-create API indeed does
>  ³do the same thing" as the Glance API.
> >>> 
> >>> They don't "do the same thing".  Even if you have full access to the
> >>> Images v1 or v2 API, you will still have to use the Compute (Nova) API to
> >>> create an image of an instance, which is by far the largest use-case for
> >>> image creation.  You can't do it through Glance, because Glance doesn't
> >>> know anything about instances.  Nova has to know about Glance, because it
> >>> needs to fetch images for instance creation, and store images for
> >>> on-demand images of instances.
> >> 
> >> Yup, that’s fair: this was a bad example to pick (need moar coffee I 
> >> guess).  Let’s use image-list instead. =)
> > 
> > From a "technical direction" perspective, I still think it's a bad
> 
> Ah.  Thanks for bringing that up, because I think this may be an area where 
> there’s some misconception about what DefCore is set up to do today.  In it’s 
> present form, the Board of Directors has structured DefCore to look much more 
> at trailing indicators of market acceptance rather than future technical 
> direction.  More on that over here. [1] 

And yet future technical direction does factor in, and I'm trying
to add a new heuristic to that aspect of consideration of tests:
Do not add tests that use proxy APIs.

If there is some compelling reason to add a capability for which
the only tests use a proxy, that's important feedback for the
contributor community and tells us we need to improve our test
coverage. If the reason to use the proxy is that no one is deploying
the proxied API publicly, that is also useful feedback, but I suspect
we will, in most cases (glance is the exception), say "Yeah, that's
not how we mean for you to run the services long-term, so don't
include that capability."

> 
> > situation for us to be relying on any proxy APIs like this. Yes,
> > they are widely deployed, but we want to be using glance for image
> > features, neutron for networking, etc. Having the nova proxy is
> > fine, but while we have DefCore using tests to enforce the presence
> > of the proxy we can't deprecate those APIs.
> 
> 
> Actually that’s not true: DefCore can totally deprecate things too, and can 
> do so in response to the technical community deprecating things.  See my 
> comments in this review [2].  Maybe I need to write another post about that...

Sorry, I wasn't clear. The Nova team would, I expect, view the use of
those APIs in DefCore as a reason to avoid deprecating them in the code
even if they wanted to consider them as legacy features that should be
removed. Maybe that's not true, and the Nova team would be happy to
deprecate the APIs, but I did think that part of the feedback cycle we
were establishing here was to have an indication from the outside of the
contributor base about what APIs are considered important enough to keep
alive for a long period of time.

> 
> /m

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[Kevin Benton]

Assuming it implements the normal provider networks API, you just specify
the segmentation_id when you create the network.

neutron net-create NET_NAME --provider:network_type vlan
--provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG

On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T) <
tony.a.w...@alcatel-lucent.com> wrote:

> Russell,
>
> Another question is about "localnet". It is a very useful feature. :-)
>
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> In your example in
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of the provider network, is the VLAN tag
> translation done by "br-int" or "br-eth1"?
>
>
> Thanks,
> Tony
>
> -Original Message-
> From: WANG, Ming Hao (Tony T)
> Sent: Sunday, September 27, 2015 2:26 PM
> To: 'Russell Bryant'; OpenStack Development Mailing List (not for usage
> questions)
> Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin
> support to setup multiple neutron networks for one container?
>
> Russell,
>
> Thanks for your valuable information.
> I understood Geneve is some kind of tunnel format for network
> virtualization encapsulation, just like VxLAN.
> But I'm still confused by the connection between Geneve and VTEP.
> I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which
> should be used for VxLAN only.
>
> Does it become some "common tunnel endpoint" in OVN, and can be also used
> as a tunnel endpoint for Geneve?
>
> Thanks,
> Tony
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Friday, September 25, 2015 12:04 AM
> To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for
> usage questions)
> Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin
> support to setup multiple neutron networks for one container?
>
> On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> > Russell,
> >
> > Thanks for your detail explanation and kind help!
> > I have understand how container in VM can acquire network interfaces in
> different neutron networks now.
> > For the connections between compute nodes, I think I need to study
> Geneve protocol and VTEP first.
> > Any further question, I may need to continue consulting you. :-)
>
> OVN uses Geneve in conceptually the same way as to how the Neutron
> reference implementation (ML2+OVS) uses VxLAN to create overlay networks
> among the compute nodes for tenant overlay networks.
>
> VTEP gateways or provider networks come into play when you want to connect
> these overlay networks to physical, or "underlay" networks.
>
> Hope that helps,
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

[WANG, Ming Hao (Tony T)]

Russell,

Another question is about "localnet". It is a very useful feature. :-)

Is it possible to assign which VLAN tag will be used for a specific provider 
network?
In your example in 
https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
 : "physnet1" is used as physical network, and br-eth1 is used as the provider 
network OpenFlow switch.
If we can assign the VLAN tag of the provider network, is the VLAN tag 
translation done by "br-int" or "br-eth1"?


Thanks,
Tony

-Original Message-
From: WANG, Ming Hao (Tony T) 
Sent: Sunday, September 27, 2015 2:26 PM
To: 'Russell Bryant'; OpenStack Development Mailing List (not for usage 
questions)
Subject: RE: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

Russell,

Thanks for your valuable information.
I understood Geneve is some kind of tunnel format for network virtualization 
encapsulation, just like VxLAN.
But I'm still confused by the connection between Geneve and VTEP.
I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should be 
used for VxLAN only.

Does it become some "common tunnel endpoint" in OVN, and can be also used as a 
tunnel endpoint for Geneve?

Thanks,
Tony
-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Friday, September 25, 2015 12:04 AM
To: WANG, Ming Hao (Tony T); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to 
setup multiple neutron networks for one container?

On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your detail explanation and kind help!
> I have understand how container in VM can acquire network interfaces in 
> different neutron networks now.
> For the connections between compute nodes, I think I need to study Geneve 
> protocol and VTEP first.
> Any further question, I may need to continue consulting you. :-)

OVN uses Geneve in conceptually the same way as to how the Neutron reference 
implementation (ML2+OVS) uses VxLAN to create overlay networks among the 
compute nodes for tenant overlay networks.

VTEP gateways or provider networks come into play when you want to connect 
these overlay networks to physical, or "underlay" networks.

Hope that helps,

--
Russell Bryant

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