date:20140623

The Oslo team is pleased to announce the release of oslosphinx
2.2.0.0a1, the first pre-release in the 2.2.0 series for oslosphinx
during the Juno cycle.

oslosphinx is the package providing our theme and extension support
for Sphinx documentation.

This release includes:

$ git log --abbrev-commit --pretty=oneline 2.1.0..HEAD

ea4511e Bump hacking to 0.9.x series
616f90e Updated from global requirements
9813d18 Merge Support building wheels (PEP-427)
1933275 Merge Add Python 3 trove classifiers
b612e98 Merge Prevent left sidebar text overflow
40d720e Prevent left sidebar text overflow
4b0525f Add Python 3 trove classifiers
195ce9e Support building wheels (PEP-427)

For more details about the 2.2.0 release series, see
https://etherpad.openstack.org/p/oslosphinx-2.2.0

Please report problems using the oslo bug tracker
https://bugs.launchpad.net/oslo

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] oslo.config 1.4.0.0a1 released

The Oslo team is pleased to announce the release of oslo.config
1.4.0.0a1, the first pre-release in the 1.4.0 series for oslo.config
during the Juno cycle.

oslo.config is the configuration library for OpenStack projects.

This release includes:

$ git log --abbrev-commit --pretty=oneline 1.3.0..1.4.0.0a1
f18797a Merge Add warning about interpolating values from groups
e0172be Merge Add more tests for positional CLI opts
63784a0 Updated from global requirements
582e1a3 Merge Add test case for hyphenated option names
782fd6e Merge Remove print statement from types.Dict
ec2b604 Remove print statement from types.Dict
15ea871 Add warning about interpolating values from groups
25b8877 Add more tests for positional CLI opts
6dc86f2 Add test case for hyphenated option names
1746fd2 Merge Bump hacking to 0.9.x series
ee14fe0 Fixes an issue validating max integer values
18601d3 Bump hacking to 0.9.x series
6c283cd Merge Add a doc sample for how to use the required field
dcef87a Updated from global requirements
1bcf145 Add a doc sample for how to use the required field
8b4bf0f log: string format arguments changed to function parameters
78c2bc9 Merge Fix deprecated_opts for cli options
bdb0814 Merge Updated from global requirements
68640a4 Fix deprecated_opts for cli options
a4bb2e4 Merge Add section titles and fix markup of docstring
7240ad9 Merge Fix docstring for _Namespace._get_cli_value
f56b38c Merge Reject option names prefixed with '_'
692f00c Reject option names prefixed with '_'
b3ed1ac Graduate config fixture
a550375 Updated from global requirements
0a66c27 Fix test_version on Python 3.4
dec5186 Add section titles and fix markup of docstring
78225a5 Avoid using too generic names in _Namespace
4b8b206 Import run_cross_tests.sh from oslo-incubator
1dc9e67 Move py33 env before py2x
bbfbe35 Fix docstring for _Namespace._get_cli_value

For more details about the 1.4.0 series, see
https://etherpad.openstack.org/p/oslo.config-1.4.0

Please report problems using the oslo bug tracker
https://bugs.launchpad.net/oslo

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] oslotest 1.1.0.0a1 released

The Oslo team is pleased to announce the release of oslotest
1.1.0.0a1, the first pre-release in the 1.1.0 series for oslotest
during the Juno cycle.

oslotest provides unit test and fixture classes used by OpenStack projects.

This release includes:

$ git log --abbrev-commit --pretty=oneline 1.0.0..1.1.0.0a1
aed8d7c Update to hacking 0.9.2
3f6b742 Cleanup mock patches on BaseTestCase tearDown()
5a22a6e Add unit test for olsotest base class
14890c8 fix .gitreview after rename
859dca0 Sync new sphinx requirement spec
2df912e Merge Update cross-test directions
47f869c Set log level to default value
52617e5 Merge Updated from global requirements
b30bf3f Updated from global requirements
e2337ac Update cross-test directions
ea4d4da Update project name in doc build

For more details about the 1.1.0 release series, see
https://etherpad.openstack.org/p/oslotest-1.1.0

Please report problems using the oslo bug tracker
https://bugs.launchpad.net/oslo

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] stevedore 1.0.0.0a1

The Oslo team is pleased to announce the release of stevedore
1.0.0.0a1, the first pre-release in the 1.0.0 series for stevedore
during the Juno cycle.

stevedore provides access pattern abstractions on top of setuptools
entry points, and is used for dynamically loading plugins and drivers.

This release includes:

$ git log --abbrev-commit --pretty=oneline 0.15..1.0.0.0a1
d37b47f Merge Updated from global requirements
bc2d08a Updated from global requirements
e8e9ca1 Fix incorrect image reference in documentation
d39ef75 Fix requirement handling in tox
65fc0d2 Merge use six.add_metaclass
58ff35c Updated from global requirements
d9d11fc use six.add_metaclass
a0721b4 Merge fix link to entry point docs
ff1f0fd Merge Updated from global requirements
53b4231 Merge Add doc requirements to venv environ
d5fb7a8 Updated from global requirements
3668de2 driver: raise by default on import failure
6a37e5f Add doc requirements to venv environ
cde4b1d Merge Import run_cross_tests.sh from oslo-incubator
f2af694 Import run_cross_tests.sh from oslo-incubator
9ae8bef fix link to entry point docs

For more details about the 1.0.0 release series, see
https://etherpad.openstack.org/p/stevedore-1.0.0

Please report problems using the oslo bug tracker
https://bugs.launchpad.net/oslo

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-06-23 Thread Thomas Morin


Hi,

2014-06-22, A, Keshava:


I have some of the basic question about deployment model of using this BaGPipe 
BGP in virtual cloud network.

1. We want MPLS to start right from compute node as part Tennant traffic ?


BaGPipe BGP component is indeed adapted to be run on compute nodes to 
encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external 
to the datacenter. In this case you are interconnecting each VM at once 
with a /32 VPNv4 route.  [A]


But you could use it as well on a network node to interconnect a whole 
virtual network with one BGP route. However doing so does not simplify 
deployments and requires additional care to handle redundancy.


And to implement virtual networks with BaGPipe, the proposed target 
would be to use it on compute nodes; but in that case MPLS is not the 
only option, and what we currently support is VXLAN (E-VPN with a VXLAN 
encapsulation).




2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
Tenant = VRF ?
Tenant span can be across multiple CN nodes,  then have BGP to Full 
mesh with in CN ?


As said in another comment, a tenant (or project depending on the 
terminology) is not a network construct; tenants just own networks.


In [A] above, for a virtual network interconnected with a VPN, there 
would be one VRF on each compute node with a VM connected to this 
virtual network.


(I'm not getting your question on having BGP as a full mesh in compute 
nodes)



3. How to have  E-VPN connectivity mapping at NN/CN nodes ?
 Is there an L2 VPN psuedowire thinking from CN nodes itself ?


I'm not sure I get your question.
When BaGPipe BGP is used on compute nodes to build a virtual network, NN 
don't need to be involved.  They only will be involved once a router 
port (on a NN) is connected to a virtual network.


Note also that in E-VPN there is no notion of pseudowire; E-VPN does not 
involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and 
forwarding tables involve dynamically adding an encap header based on a 
static forwarding table (rather than tunnels or pseudowires).




4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?



When E-VPN is used, network traffic inside a virtual network is carried 
as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe 
does not support any MPLS dataplane driver for E-VPN).  When IP VPN is 
used (eg. between virtual networks, or to/from an external IP VPN), 
traffic is carried as IP traffic in MPLS or MPLS-GRE.



Help me understand the deployment model for this .



Hope that helps,

-Thomas



-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Thursday, June 19, 2014 9:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi everyone,

Sorry, I couldn't make it in time for the IRC meeting.

Just saw in the logs:
15:19:12 yamamoto are orange folks here?  they might want to
  introduce their bgp speaker.

The best intro to BaGPipe BGP is the README on github:
https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md

Beyond just speaking the BGP protocol on the wire, BaGPipe is a an 
implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. 
It can be run as a service exposing a REST API, or a library inside an agent; 
it handles the lifecylcle of VRFs and port attached/detached from them and 
appropriately circulates event to/from BGP peers based on VRF import/export 
rules and RTC publish/subscribe semantics.  It's complete enough to let us 
build neutron virtual networks with IP VPNs, and interconnect them with 
external VPNs; the parts for Opentsack integration are not on this github, I'm 
just mentioning this for the sake of illustrating the relative maturity.

Although it does not address plain IP, this would I believe by a really easy 
addition to make.

I'll do my best to attend next week IRC meeting, but until this, feel free to ask.  
We can also do a QA session on IRC if that sounds convenient.

Best,

-Thomas



2014-06-13, YAMAMOTO Takashi:

an update after today's l3 meeting:
here's a new version of ryu bgp api patch.
http://sourceforge.net/p/ryu/mailman/message/32453021/


it has been merged to the ryu master.
  https://github.com/osrg/ryu.git

here's formatted documentation:
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html

YAMAMOTO Takashi



YAMAMOTO Takashi


I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation
for BPG speaking in Neutron.  Thank you for your support.  I'll look
forward to the API and documentation refinement

Let's be sure to document any work that needs to be done so that it
will support the features we need.  We can use the comparison page
for

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-06-23 Thread Thomas Morin


Hi,

2014-06-22, A, Keshava:


I have some of the basic question about deployment model of using this BaGPipe 
BGP in virtual cloud network.

1. We want MPLS to start right from compute node as part Tennant traffic ?


BaGPipe BGP component is indeed adapted to be run on compute nodes to 
encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external 
to the datacenter. In this case you are interconnecting each VM at once 
with a /32 VPNv4 route.  [A]


But you could use it as well on a network node to interconnect a whole 
virtual network with one BGP route. However doing so does not simplify 
deployments and requires additional care to handle redundancy.


And to implement virtual networks with BaGPipe, the proposed target 
would be to use it on compute nodes; but in that case MPLS is not the 
only option, and what we currently support is VXLAN (E-VPN with a VXLAN 
encapsulation).




2. We want L3 VRF separation right on Compute nodes (or NN Node) ?
Tenant = VRF ?
Tenant span can be across multiple CN nodes,  then have BGP to Full 
mesh with in CN ?


As said in another comment, a tenant (or project depending on the 
terminology) is not a network construct; tenants just own networks.


In [A] above, for a virtual network interconnected with a VPN, there 
would be one VRF on each compute node with a VM connected to this 
virtual network.


(I'm not getting your question on having BGP as a full mesh in compute 
nodes)



3. How to have  E-VPN connectivity mapping at NN/CN nodes ?
 Is there an L2 VPN psuedowire thinking from CN nodes itself ?


I'm not sure I get your question.
When BaGPipe BGP is used on compute nodes to build a virtual network, NN 
don't need to be involved.  They only will be involved once a router 
port (on a NN) is connected to a virtual network.


Note also that in E-VPN there is no notion of pseudowire; E-VPN does not 
involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and 
forwarding tables involve dynamically adding an encap header based on a 
static forwarding table (rather than tunnels or pseudowires).




4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?



When E-VPN is used, network traffic inside a virtual network is carried 
as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe 
does not support any MPLS dataplane driver for E-VPN).  When IP VPN is 
used (eg. between virtual networks, or to/from an external IP VPN), 
traffic is carried as IP traffic in MPLS or MPLS-GRE.



Help me understand the deployment model for this .



Hope that helps,

-Thomas



-Original Message-
From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Thursday, June 19, 2014 9:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

Hi everyone,

Sorry, I couldn't make it in time for the IRC meeting.

Just saw in the logs:
15:19:12 yamamoto are orange folks here?  they might want to
  introduce their bgp speaker.

The best intro to BaGPipe BGP is the README on github:
https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md

Beyond just speaking the BGP protocol on the wire, BaGPipe is a an 
implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. 
It can be run as a service exposing a REST API, or a library inside an agent; 
it handles the lifecylcle of VRFs and port attached/detached from them and 
appropriately circulates event to/from BGP peers based on VRF import/export 
rules and RTC publish/subscribe semantics.  It's complete enough to let us 
build neutron virtual networks with IP VPNs, and interconnect them with 
external VPNs; the parts for Opentsack integration are not on this github, I'm 
just mentioning this for the sake of illustrating the relative maturity.

Although it does not address plain IP, this would I believe by a really easy 
addition to make.

I'll do my best to attend next week IRC meeting, but until this, feel free to ask.  
We can also do a QA session on IRC if that sounds convenient.

Best,

-Thomas



2014-06-13, YAMAMOTO Takashi:

an update after today's l3 meeting:
here's a new version of ryu bgp api patch.
http://sourceforge.net/p/ryu/mailman/message/32453021/


it has been merged to the ryu master.
  https://github.com/osrg/ryu.git

here's formatted documentation:
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html
  http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html

YAMAMOTO Takashi



YAMAMOTO Takashi


I have seen the Ryu team is involved and responsive to the community.
That goes a long way to support it as the reference implementation
for BPG speaking in Neutron.  Thank you for your support.  I'll look
forward to the API and documentation refinement

Let's be sure to document any work that needs to be done so that it
will support the features we need.  We can use the comparison page
for

Re: [openstack-dev] [keystone]endpoint table is missing reference to region table

2014-06-23 Thread Dolph Mathews

On Fri, Jun 20, 2014 at 12:14 AM, Manickam, Kanagaraj
kanagaraj.manic...@hp.com wrote:

A) Yes, we need to migrate.

B) I have queries:

a. Region is consumed only in the end-point object in keystone. So
when an end point is created, keystone can go ahead and create a region in
the “region” table if the region does not exist. Otherwise keystone can
bind the existing region with the endpoint. This will make sure that
endpoint is having foreign key reference to the region. I see this as
dynamic way of creating the region. Could you please validate the
understanding and correct it, if required.

+1; note this approach in a proposal to keystone-specs, though.

b. In addition, The endpoint API request response will be
provided with “region” name as like today. So user does not get affected by
this change.

+1; but we also deprecated that attribute (region) as of Identity API
v3.2 in favor of region_id [1] for consistency across the API. For
backwards compatibility, we'll need to handle both attributes.

[1]
https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#endpoints-v3endpoints

Regards,

Kanagaraj M

*From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
*Sent:* Friday, June 20, 2014 8:41 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [keystone]endpoint table is missing
reference to region table

The region table is relatively new, and no one has stepped up to link the
two together. A couple considerations:

A) a data migration will need to be performed to sync up the regions in
the endpoint table with regions in the region table (populate those foreign
keys, creating corresponding regions where necessary)

B) endpoints are created today without requiring a region to be created;
this workflow will have to continue for v2 and v3 (regions need to be
created dynamically)

On Thu, Jun 19, 2014 at 12:38 PM, Manickam, Kanagaraj
kanagaraj.manic...@hp.com wrote:

Hi,

In keystone, though “region” table is provided, it is not consumed in the
“endpoint” table. I have filed bug
https://bugs.launchpad.net/keystone/+bug/1332196 to address the same.

Can anyone please provide details on, why this disconnect between endpoint
and region table.

Thanks

Kanagaraj M

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

2014-06-23 Thread Thomas Morin


Hi Ian,

Ian Wells :


When you say things like 'tenant = VRF' (and, in fact, I presume you 
mean 'network = VRF', since networks and tenants are two different 
things) then that's actually more to do with how you implement the 
networking overlay layer in Neutron.  While interesting, and while it 
could potentially use a BGP speaker and VRFs to do it, it's not the 
same use case as advertising routes externally, or terminating an 
external MPLS VPN in Openstack.  I could do either of those things 
independently of the other. Terminating VPNs requires an extension API 
and could potentially glue on to a current plugin (much like VPNaaS). 
Writing overlays is a new plugin entirely.


Indeed.



There's a use for BGP speakers in both arenas (and additionally within 
the distributed virtual router, which is a third case) so perhaps we 
could address who's using which speaker for precisely what?


We plan to propose an implementation of the BGP VPN interconnection API 
( https://review.openstack.org/#/c/93329/1 ) that will use BaGPipe BGP 
for IP VPN VRF.
And we are also working on a mechanism driver that will use BaGPipe BGP 
and E-VPN/VXLAN.


Best,

-Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/23/2014 06:18 AM, Sean Dague wrote:
 On 06/22/2014 03:04 PM, Jay Pipes wrote:
 On 06/20/2014 02:07 PM, Sean Dague wrote:
 After seeing a bunch of code changes to enforce new hacking
 rules, I'd like to propose dropping some of the rules we have.
 The overall patch series is here - 
 https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z



 
H402 - 1 line doc strings should end in punctuation. The real statement
 is this should be a summary sentence. A sentence is not just a
 set of words that end in a period. Squirel fast bob. It's
 something deeper. This rule thus isn't really semantically
 useful, especially when you are talking about at 69 character
 maximum (79 - 4 space indent - 6 quote characters).
 
 ++ This was always a silly rule, IMO
 
 Sorry, forgot to add a period. There. Better.
 
 H803 - First line of a commit message must *not* end in a
 period. This was mostly a response to an unreasonable core
 reviewer that was -1ing people for not having periods. I think
 any core reviewer that -1s for this either way should be thrown
 off the island, or at least made fun of, a lot. Again, the
 clarity of a commit message is not made or lost by the lack or
 existence of a period at the end of the first line.
 
 +10
 
 Sorry, I meant +10. Period.
 

I'm good with removing the punctuation ones, especially for the commit
message.

 H305 - Enforcement of libraries fitting correctly into stdlib,
 3rdparty, our tree. This biggest issue here is it's built in a
 world where there was only 1 viable python version, 2.7.
 Python's stdlib is actually pretty dynamic and grows over time.
 As we embrace more python 3, and as distros start to make
 python3 be front and center, what does this even mean? The
 current enforcement can't pass on both python2 and python3 at 
 the same time in many cases because of that.
 
 +0 on this one... I find it useful to group the libs together in
 this way, as it makes it relatively easy to identify quickly at a
 glance the third party libs that are in use in the module.
 
 Sure, I'm not saying don't group. I'm saying that it's actually 
 impossible to create a formal definition for group 2. So use it as 
 guidelines don't enforce in code.

I'm -1 on manual enforcement of these rules.  I hate -1'ing a patch
(especially one that's been in review for a while) just for import
grouping issues, and if I'm not going to -1 for that then why even
pretend it's something we want to do?

I'd rather have an exception mechanism for the check where we can make
a list of modules that can be in either stdlib or third-party and
allow both.  I don't think the Python stdlib is changing so fast that
we couldn't keep such a list maintained and it would allow these
checks to still be automated.  In fact, it should be possible to
generate the list programmatically.

Obviously I am signing up to do this work if it's something we can
agree on.

 
 We have to remember we're all humans, and it's ok to have grey
 space. Like in 305, you *should* group the libraries if you
 can, but stuff like that should be labeled as 'nit' in the
 review, and only ask the author to respin it if there are other
 more serious issues to be handled.
 
 Ya, no real disagreement on that.
 
 Let's optimize a little more for fun, and stop throwing -1s for
 silly things. :)
 
 ++
 
 I would also love to get rid of H404, otherwise known as the dumb
 rule that says if you have a multiline docstring, that there must
 be a summary line, then a blank line, then a detailed
 description. It makes things like this illegal, which, IMHO, is
 stupid:
 
 def do_something(self, thing): We do something with the
 supplied thing, so that something else is also done with this
 other thing. Make sure the other thing is of type something.  
 pass
 
 Likewise, I'd love to be able to have a newline start the
 docstring, like so:
 
 def do_something(self, thing):  We do something with the
 supplied thing, so that something else is also done with this
 other thing. Make sure the other thing is of type something.  
 pass
 
 But there's a rule that prevents that as well...
 
 Yeh, I'd be happy throwing out the docstring rules all together. I
 feel like docstrings being good or bad is pretty orthoginal to
 these rules the way they enforce things.
 
 To be clear, I don't think all hacking rules are silly. To the
 contrary, there are many that are reasonable and useful. However,
 I'd prefer to focus on things that make the code more readable,
 not less readable, and rules that enforce Pythonic idioms, not
 some random hacker's idea of good style.
 
 Correct, I'm with you. But I also feel like we've wandered across a
 line in the current implementation, and it's time to prune back.
 
 Because hacking supports local rules, if any particular project
 wants to go overboard in rules, so be it. But lets not do that in
 hacking itself.

I made this comment on

[openstack-dev] [Neutron][ServiceVM] servicevm IRC meeting reminder (June 28 Tuesday 5:00(AM)UTC-)

2014-06-23 Thread Isaku Yamahata

Hi. This is a reminder mail for the servicevm IRC meeting
June 28, 2014 Tuesdays 5:00(AM)UTC-
#openstack-meeting on freenode
https://wiki.openstack.org/wiki/Meetings/ServiceVM


agenda: (feel free to add your items)
* announcements
* action items from the last week
* new repo in github and API discussion
  I hoped to use stackforge so far, but the process of config seems
  too slow. 
  So I'd like to start actual discussion with github until stackforge repo
  is created.
* API discussion for consolidation
  consolidate multiple existing implementations
* NFV meeting follow up
* blueprint follow up
* open discussion
* add your items
-- 
Isaku Yamahata isaku.yamah...@gmail.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

Could you fill out a spec using the graduation template so we can
identify the various contacts we need (maintainers, security, etc.)?
We can use the spec as a place for the team to vote on whether or not
they agree to adopt the library.

Doug

On Mon, Jun 23, 2014 at 9:41 AM, Julien Danjou jul...@danjou.info wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after discussing
 with its current maintainer, it appears that more help and workforce
 would be require:

   https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

 Since we are using it via oslo lockutils module, I proposed to adopt
 this project under the Oslo program banner. The review to copy the
 repository to our infrastructure is up at:

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

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

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

2014-06-23 Thread Julien Danjou

On Mon, Jun 23 2014, Doug Hellmann wrote:

 Could you fill out a spec using the graduation template so we can
 identify the various contacts we need (maintainers, security, etc.)?
 We can use the spec as a place for the team to vote on whether or not
 they agree to adopt the library.

Ok, but I raised my fist reading your message because of the bureaucracy
OpenStack is becoming. :-)

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


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,
 
 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:
 
 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:
 
 https://review.openstack.org/#/c/101911/

We actually don't use this in lockutils - we use our own
implementation of LockFile because there was some sort of outstanding
bug in pylockfile that made it not work for us.  The only place I can
see that we do use that project is in the oslo.db code because we
didn't want to depend on incubator modules there, but once
oslo.concurrency graduates we can switch to using our own locking
implementation again.

Basically I think this would be duplicating what we're already doing
in lockutils, so I'm -1 on it.  I'd rather focus on getting
oslo.concurrency graduated and remove pylockfile from
global-requirements to make sure no one is using it anymore.

This also makes me wonder if oslo.concurrency should not be an oslo.*
library since this functionality is more generally applicable outside
OpenStack.  Something to discuss anyway.

 
 Cheers,
 
 
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTqDvqAAoJEDehGd0Fy7uqjOIH/RyvsUstB473A8NzDBEUyLYp
alztUIjHzClZBne0weAe10UzqWGmfSFJKhpThAB3IP9xdS39ZmW4zAGQm8obk4RL
Qj9nDPt/WRb0kMlWulTckfVR2hWDc0kZ2Y5YBFR0ubWQfNoyh14rF9VEtuVsZOwW
1/F60rlXy9iZGC/Mw+XK5ZJhoG6k7EZucDR6y0bfaNLdOWDUeEaqzq1lvfULyaYS
MZxfEFnsY1GkRxSX4U/SMvu1xV3yTkrbLXmsj3fAJBW4HQfp+9bdAfkz/Z1snYl6
VtMvfDYChJogq2c7G35RD161nxmMxsOyrLm/YSqc7dPkMytdKD3YXwAuYsiVIJM=
=YBxv
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

2014-06-23 Thread Julien Danjou

On Mon, Jun 23 2014, Ben Nemec wrote:

 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.

Oh you're right, I got confused while chasing the bug.

 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.

That'd work for me.

 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.

Agreed. I also think there is some potential relation with tooz, as it
provides locking on a distributed fashion. So it can be seen as a
complement of tooz I'd say. Maybe something to think about.

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


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:

 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:

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

 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.

 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.

Which makes more sense, continuing to maintain our library or fixing
that bug and maintaining pylockfile? How big is pylockfile compared to
what we have? Does it solve problems our existing locking code doesn't
solve (and that we care about)?


 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.

That makes sense. When I made the list of libraries to release this
time, I called them all oslo.foo because I wasn't digging into the
code deep enough to figure out whether they could be something else. I
expected the person managing the spec for the release to do that step,
but I may not have made that clear.

The main thing I would be concerned with about using a non-oslo name
for oslo.concurrency is whether or not it uses another oslo library
like oslo.config. If we can completely avoid those dependencies, then
it should be safe to release it under a name other than
oslo.concurrency.

Doug



 Cheers,



 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJTqDvqAAoJEDehGd0Fy7uqjOIH/RyvsUstB473A8NzDBEUyLYp
 alztUIjHzClZBne0weAe10UzqWGmfSFJKhpThAB3IP9xdS39ZmW4zAGQm8obk4RL
 Qj9nDPt/WRb0kMlWulTckfVR2hWDc0kZ2Y5YBFR0ubWQfNoyh14rF9VEtuVsZOwW
 1/F60rlXy9iZGC/Mw+XK5ZJhoG6k7EZucDR6y0bfaNLdOWDUeEaqzq1lvfULyaYS
 MZxfEFnsY1GkRxSX4U/SMvu1xV3yTkrbLXmsj3fAJBW4HQfp+9bdAfkz/Z1snYl6
 VtMvfDYChJogq2c7G35RD161nxmMxsOyrLm/YSqc7dPkMytdKD3YXwAuYsiVIJM=
 =YBxv
 -END PGP SIGNATURE-

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

On Mon, Jun 23, 2014 at 10:37 AM, Skip Montanaro s...@pobox.com wrote:
 On Mon, Jun 23, 2014 at 9:30 AM, Doug Hellmann
 doug.hellm...@dreamhost.com wrote:
 Could you fill out a spec using the graduation template so we can
 identify the various contacts we need (maintainers, security, etc.)?
 We can use the spec as a place for the team to vote on whether or not
 they agree to adopt the library.

 Who is you in this context? Me? Or someone else? If it's me, I have
 no idea what you are referring to.

Sorry, Skip, I didn't even notice you were copied on that email. The
request was for Julien, so you don't need to do anything.

We have a process that involves writing up a formal proposal and
submitting it to a documentation repository, and that process will
give me a place to record the votes of the Oslo team on whether or not
they are willing to take over maintenance. I don't expect an issue,
but I'd like to have the votes on record for posterity.

Doug


 Skip

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers

2014-06-23 Thread Trump.Zhang

Hi, all:

Currently, there are several filesystem-based drivers in Cinder, such
as nfs, glusterfs, etc. Multiple format of volume other than raw can be
potentially supported in these drivers, such as qcow2, raw, sparse, etc.

However, Cinder does not store the actual format of volume and suppose
all volumes are raw format. It will has or already has several problems
as follows:

1. For volume migration, the generic migration implementation in Cinder
uses the dd command to copy src volume to dest volume. If the src
volume is qcow2 format, instance will not get the right data from volume
after the dest volume attached to instance, because the info returned from
Cinder states that the volume's format is raw other than qcow2
2. For volume backup, the backup driver also supposes that src volumes
are raw format, other format will not be supported

Indeed, glusterfs driver has used qemu-img info command to judge the
format of volume. However, as the comment from Duncan in [1] says, this
auto detection method has many possible error / exploit vectors. Because if
the beginning content of a raw volume happens to a qcow2 disk, auto
detection method will judge this volume to be a qcow2 volume wrongly.

I proposed that the format info should be added to admin_metadata
of volumes, and enforce it on all operations, such as create, copy, migrate
and retype. The format will be only set / updated for filesystem-based
drivers,  other drivers will not contains this metadata and have a default
raw format.

Any advice?

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

-- 
---
Best Regards

Trump.Zhang
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Running dnsmasq in Neutron: unix rights

2014-06-23 Thread Thomas Goirand

On 06/14/2014 07:26 PM, Thomas Goirand wrote:
 Hi,
 
 I've been thinking for a long time on how to fix dnsmasq unix rights
 issue in Neutron. Namely (from syslog):
 
 /var/lib/neutron/dhcp/{id}/host : Permission denied
 
 One way to fix it is to do:
 chmod o+x /var/lib/neutron
 
 Though I don't feel it's the right way to do things. Wouldn't it be
 nicer to add:
 --user=neutron
 
 in spawn_process() in neutron/agent/linux/dhcp.py? I know some Debian
 users did that, and it worked. I was tempted to add such patch, but I
 don't think it's the right thing to do without upstream approval.
 
 Yet another way would be to use adduser and add the nobody user in the
 neutron group, but I'm discarding that option as the least safe.
 
 I don't want to introduce a Debian specific security hole in my Neutron
 package, and I am therefore seeking for advices in this list. What's the
 safest way to fix that problem?
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 P.S: The issue is also tracked at https://bugs.debian.org/751524, so
 please leave 751...@bugs.debian.org as Cc: when replying.

After 10 days, nobody replied to this question... :(

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] set default cinder driver

2014-06-23 Thread John Griffith

On Mon, Jun 23, 2014 at 7:48 AM, Ivan Kolodyazhny e...@e0ne.info wrote:

 Yogesh,

 Try to modify yours /devstack/local.conf with
 CINDER_DRIVER=cinder.volume.drivers.cloudbyte.ElasticenterISCSIDriver
 and run stack.sh.

 rejoin-stack.sh doesn't update anything, it launches OpenStack services in
 screen and uses existing configuration

 Regards,
 Ivan Kolodyazhny,
 Web Developer,
 http://blog.e0ne.info/,
 http://notacash.com/,
 http://kharkivpy.org.ua/


 On Mon, Jun 23, 2014 at 1:30 PM, Yogesh Prasad 
 yogesh.pra...@cloudbyte.com wrote:

 Hi Lvan,

 Thanks for reply, but i am still facing same problem.

 I have tried all of these -

 1) Inside /etc/cinder/cinder.conf
 [DEFAULT]
 volume_driver=cinder.volume.drivers.cloudbyte.ElasticenterISCSIDriver

 and ran below script
./rejoin-stack.sh

 2) Inside /devstack/local.conf
 [[post-config|$CINDER_CONF]]
 volume_driver = cinder.volume.cloudbyte.ElasticenterISCSIDriver

  and ran below script
./rejoin-stack.sh

 3) Inside /devstack/local.conf
 [[local|localrc]]
 CINDER_DRIVER=cinder.volume.drivers.cloudbyte.ElasticenterISCSIDriver

 and ran below script
./rejoin-stack.sh

 4) Inside /devstack/local.conf
 volume_driver =
 cinder.volume.drivers.cloudbyte.ElasticenterISCSIDriver

  and ran below script
./rejoin-stack.sh

 But it is not working.

 In addition, what is the py file that reads localrc ?



 On Mon, Jun 23, 2014 at 2:14 PM, Ivan Kolodyazhny e...@e0ne.info wrote:

 Hi Yogesh,

 You need to set CINDER_DRIVER variable in your localrc file

 Regards,
 Ivan Kolodyazhny,
 Software Engineer,
 Mirantis, Inc.


 On Mon, Jun 23, 2014 at 10:38 AM, Yogesh Prasad 
 yogesh.pra...@cloudbyte.com wrote:


 Hi All,

 I have devstack setup and i want to put my cinder driver as a default
 driver.
 How i can do this?
 please guide.
 --
  *Thanks  Regards*,
   Yogesh Prasad.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 *Thanks  Regards*,
   Yogesh Prasad.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 I put this in a wiki a while back [1], might not be the clearest set of
instructions but should give you a pretty good hint.  Note the extra
variables specific for your driver.  The piece you're still going to need
is the lib/cinder_plugins which will interpret the driver settings from
your local.conf and populate cinder.conf appropriately.  Without that
you'll still get volume_driver set in the cinder.conf but none of your
options.

Also, FYI you don't have to deploy devstack with your driver enabled, just
build it normally with the default LVM, then edit /etc/cinder/cinder.conf
and put your driver parameters in.  Finally, open the screen session and
restart c-volume service and your driver will get picked up from the conf
file.

[1]:
https://wiki.openstack.org/wiki/Cinder#Configuring_devstack_to_use_your_driver_and_backend

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

On 06/23/2014 10:02 AM, Doug Hellmann wrote:
 On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:

 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:

 https://review.openstack.org/#/c/101911/
 
 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.
 
 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.
 
 Which makes more sense, continuing to maintain our library or fixing
 that bug and maintaining pylockfile? How big is pylockfile compared to
 what we have? Does it solve problems our existing locking code doesn't
 solve (and that we care about)?

It looks to me like pylockfile would provide a subset of the
functionality in lockutils (for example, I don't see anything to replace
the @lock decorator).  So I don't think we could just drop lockutils and
switch to it.  We'd just be switching out the underlying lock mechanism,
and we know how well that has gone in the past. ;-)

 
 
 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.
 
 That makes sense. When I made the list of libraries to release this
 time, I called them all oslo.foo because I wasn't digging into the
 code deep enough to figure out whether they could be something else. I
 expected the person managing the spec for the release to do that step,
 but I may not have made that clear.
 
 The main thing I would be concerned with about using a non-oslo name
 for oslo.concurrency is whether or not it uses another oslo library
 like oslo.config. If we can completely avoid those dependencies, then
 it should be safe to release it under a name other than
 oslo.concurrency.

Oh, that's probably why I didn't suggest this in the first place.
lockutils uses oslo.config, so it does need to be in the oslo namespace.

I don't think we can drop the oslo.config dep, but we might be able to
decouple it like oslo.db did.  I think that would be messy though
because Windows is where problems would come up and we don't test
Windows in the gate. :-/

 
 Doug
 
 

 Cheers,



 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

2014-06-23 Thread Monty Taylor

On 06/23/2014 11:24 AM, Ben Nemec wrote:
 On 06/23/2014 10:02 AM, Doug Hellmann wrote:
 On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:

 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:

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

 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.

 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.

 Which makes more sense, continuing to maintain our library or fixing
 that bug and maintaining pylockfile? How big is pylockfile compared to
 what we have? Does it solve problems our existing locking code doesn't
 solve (and that we care about)?
 
 It looks to me like pylockfile would provide a subset of the
 functionality in lockutils (for example, I don't see anything to replace
 the @lock decorator).  So I don't think we could just drop lockutils and
 switch to it.  We'd just be switching out the underlying lock mechanism,
 and we know how well that has gone in the past. ;-)

But if we had originally thought to use pylockfile except for the bug,
and if oslo.lockutils brings in oslo.config making it not suitable for
general usage - it seems like it would be a good thing for the wider
community if we 'fix' pylockfile and make oslo.lockutils the
oslo-ification of it?

I mean, ultimately like everything else in OpenStack we don't REALLY
want to just have our own set of parallel libs to what the rest of
python uses, do we?



 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.

 That makes sense. When I made the list of libraries to release this
 time, I called them all oslo.foo because I wasn't digging into the
 code deep enough to figure out whether they could be something else. I
 expected the person managing the spec for the release to do that step,
 but I may not have made that clear.

 The main thing I would be concerned with about using a non-oslo name
 for oslo.concurrency is whether or not it uses another oslo library
 like oslo.config. If we can completely avoid those dependencies, then
 it should be safe to release it under a name other than
 oslo.concurrency.
 
 Oh, that's probably why I didn't suggest this in the first place.
 lockutils uses oslo.config, so it does need to be in the oslo namespace.
 
 I don't think we can drop the oslo.config dep, but we might be able to
 decouple it like oslo.db did.  I think that would be messy though
 because Windows is where problems would come up and we don't test
 Windows in the gate. :-/
 

 Doug



 Cheers,



 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] default security group rules in neutron

2014-06-23 Thread Kyle Mestery

On Sun, Jun 22, 2014 at 9:23 PM, Lingxian Kong anlin.k...@gmail.com wrote:
 Greetings

 We use neutron as network functionality implementation in nova, and as
 you know, there is a feature called 'os-security-group-default-rules'
 in nova extension[1], a hook mechanism to add customized rules when
 creating default security groups, which is a very useful feature to
 the administrators or operators (at least useful to us in our
 deployment). But I found this feature is valid only when using
 nova-network.

 So, for the functionality parity between nova-network and neutron and
 for our use case, I registered a blueprint[2] about default security
 group rules in Neutron days ago and related neutron spec[3], and I
 want it to be involved in Juno, so we can upgrade our deployment that
 time for this feature. I'm ready for the code implementation[3].

 But I still want to see what's the community's thought about including
 this feature in neutron, any of your feedback and comments are
 appreciated!

Thanks for registering this BP Lingxian! This is an important feature,
and I'm keen to see this land in Juno. I've reviewed the BP briefly, I
plan to review it in detail today as well.

Thanks for taking this work on!

Kyle

 [1] 
 https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group
 [2] 
 https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
 [3] https://review.openstack.org/98966
 [4] https://review.openstack.org/99320

 --
 Regards!
 ---
 Lingxian Kong

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

2014-06-23 Thread Donald Stufft


On Jun 23, 2014, at 11:30 AM, Monty Taylor mord...@inaugust.com wrote:

 On 06/23/2014 11:24 AM, Ben Nemec wrote:
 On 06/23/2014 10:02 AM, Doug Hellmann wrote:
 On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,
 
 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:
 
 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012
 
 Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:
 
 https://review.openstack.org/#/c/101911/
 
 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.
 
 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.
 
 Which makes more sense, continuing to maintain our library or fixing
 that bug and maintaining pylockfile? How big is pylockfile compared to
 what we have? Does it solve problems our existing locking code doesn't
 solve (and that we care about)?
 
 It looks to me like pylockfile would provide a subset of the
 functionality in lockutils (for example, I don't see anything to replace
 the @lock decorator).  So I don't think we could just drop lockutils and
 switch to it.  We'd just be switching out the underlying lock mechanism,
 and we know how well that has gone in the past. ;-)
 
 But if we had originally thought to use pylockfile except for the bug,
 and if oslo.lockutils brings in oslo.config making it not suitable for
 general usage - it seems like it would be a good thing for the wider
 community if we 'fix' pylockfile and make oslo.lockutils the
 oslo-ification of it?
 
 I mean, ultimately like everything else in OpenStack we don't REALLY
 want to just have our own set of parallel libs to what the rest of
 python uses, do we?

+100

 
 
 
 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.
 
 That makes sense. When I made the list of libraries to release this
 time, I called them all oslo.foo because I wasn't digging into the
 code deep enough to figure out whether they could be something else. I
 expected the person managing the spec for the release to do that step,
 but I may not have made that clear.
 
 The main thing I would be concerned with about using a non-oslo name
 for oslo.concurrency is whether or not it uses another oslo library
 like oslo.config. If we can completely avoid those dependencies, then
 it should be safe to release it under a name other than
 oslo.concurrency.
 
 Oh, that's probably why I didn't suggest this in the first place.
 lockutils uses oslo.config, so it does need to be in the oslo namespace.
 
 I don't think we can drop the oslo.config dep, but we might be able to
 decouple it like oslo.db did.  I think that would be messy though
 because Windows is where problems would come up and we don't test
 Windows in the gate. :-/
 
 
 Doug
 
 
 
 Cheers,
 
 
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Vijay Venkatachalam

Hi:



In the LBaaS TLS termination capability specification proposal



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



TLS settings like default certificate container id and SNI cert list are part 
of the listener properties.



I think it is better to have this as a separate entity so that the listener 
properties are clean and is not corrupted with TLS settings.



I liked the original SSL proposal better where TLS settings was a separate 
entity.



It is just 2 properties now but in future the TLS settings would grow and if we 
are going to introduce a TLS profile/params/settings entity later, it is better 
to do it now (albeit with min properties).



Thanks,

Vijay V.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][nova] nova needs a new release of neutronclient for OverQuotaClient exception

2014-06-23 Thread Kyle Mestery

On Mon, Jun 23, 2014 at 8:54 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
 There are at least two changes [1][2] proposed to Nova that use the new
 OverQuotaClient exception in python-neutronclient, but the unit test jobs no
 longer test against trunk-level code of the client packages so they fail.
 So I'm here to lobby for a new release of python-neutronclient if possible
 so we can keep these fixes moving.  Are there any issues with that?

Thanks for bringing this up Matt. I've put this on the agenda for the
Neutron meeting today, I'll reply on this thread with what comes out
of that discussion.

Kyle

[1] https://wiki.openstack.org/wiki/Network/Meetings#Team_Discussion_Topics

 [1] https://review.openstack.org/#/c/62581/
 [2] https://review.openstack.org/#/c/101462/
 --

 Thanks,

 Matt Riedemann


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Running dnsmasq in Neutron: unix rights

2014-06-23 Thread Kyle Mestery

On Mon, Jun 23, 2014 at 10:10 AM, Thomas Goirand z...@debian.org wrote:
 On 06/14/2014 07:26 PM, Thomas Goirand wrote:
 Hi,

 I've been thinking for a long time on how to fix dnsmasq unix rights
 issue in Neutron. Namely (from syslog):

 /var/lib/neutron/dhcp/{id}/host : Permission denied

 One way to fix it is to do:
 chmod o+x /var/lib/neutron

 Though I don't feel it's the right way to do things. Wouldn't it be
 nicer to add:
 --user=neutron

 in spawn_process() in neutron/agent/linux/dhcp.py? I know some Debian
 users did that, and it worked. I was tempted to add such patch, but I
 don't think it's the right thing to do without upstream approval.

 Yet another way would be to use adduser and add the nobody user in the
 neutron group, but I'm discarding that option as the least safe.

 I don't want to introduce a Debian specific security hole in my Neutron
 package, and I am therefore seeking for advices in this list. What's the
 safest way to fix that problem?

 Cheers,

 Thomas Goirand (zigo)

 P.S: The issue is also tracked at https://bugs.debian.org/751524, so
 please leave 751...@bugs.debian.org as Cc: when replying.

 After 10 days, nobody replied to this question... :(

I was hoping to get some replies from other distribution maintainers
here. Given that we haven't seen any, perhaps you could file a bug in
Launchpad and submit a patch as you indicate? That would move
discussion to gerrit and we may get some other folks with input there.

Thanks,
Kyle

 Thomas


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers

2014-06-23 Thread Duncan Thomas

Write a blueprint and a patch...

On 23 June 2014 16:07, Trump.Zhang zhangleiqi...@gmail.com wrote:
 Hi, all:

 Currently, there are several filesystem-based drivers in Cinder, such as
 nfs, glusterfs, etc. Multiple format of volume other than raw can be
 potentially supported in these drivers, such as qcow2, raw, sparse, etc.

 However, Cinder does not store the actual format of volume and suppose
 all volumes are raw format. It will has or already has several problems as
 follows:

 1. For volume migration, the generic migration implementation in Cinder
 uses the dd command to copy src volume to dest volume. If the src
 volume is qcow2 format, instance will not get the right data from volume
 after the dest volume attached to instance, because the info returned from
 Cinder states that the volume's format is raw other than qcow2
 2. For volume backup, the backup driver also supposes that src volumes
 are raw format, other format will not be supported

 Indeed, glusterfs driver has used qemu-img info command to judge the
 format of volume. However, as the comment from Duncan in [1] says, this auto
 detection method has many possible error / exploit vectors. Because if the
 beginning content of a raw volume happens to a qcow2 disk, auto
 detection method will judge this volume to be a qcow2 volume wrongly.

 I proposed that the format info should be added to admin_metadata of
 volumes, and enforce it on all operations, such as create, copy, migrate and
 retype. The format will be only set / updated for filesystem-based
 drivers,  other drivers will not contains this metadata and have a default
 raw format.

 Any advice?

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

 --
 ---
 Best Regards

 Trump.Zhang

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Duncan Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS]Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Vijay Venkatachalam

Hi:



In the LBaaS TLS termination capability specification proposal



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



TLS settings like default certificate container id and SNI cert list are part 
of the listener properties.



I think it is better to have this as a separate entity so that the listener 
properties are clean and is not corrupted with TLS settings.



I liked the original SSL proposal better where TLS settings was a separate 
entity.



It is just 2 properties now but in future the TLS settings would grow and if we 
are going to introduce a TLS profile/params/settings entity later, it is better 
to do it now (albeit with min properties).



Thanks,

Vijay V.



PS:

Adding with the right subject
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] High bandwidth routers

2014-06-23 Thread A, Keshava

Hi,
I think there is no much consideration of  L3 forwarding capacity,  of the 
order of 100G in Network-Node(NN).
Not sure current software queues in NNare capable of handling 100G times of 
packet rate.
(Of course for compute node there will  SRIOV to speedup these)

Instead you can consider  of having multiple Network Nodes deployed, so that L3 
forwarding will be distributed across multiple NN.
Make sure you will have separate public  IP for each of these NNs, so that any 
session related issue will not have issues in NN.


Regards,
Keshava.A.K.


From: CARVER, PAUL [mailto:pc2...@att.com]
Sent: Monday, June 23, 2014 6:51 PM
To: OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] High bandwidth routers

Is anyone using Neutron for high bandwidth workloads? (for sake of discussion 
let's high = 50Gbps or greater)

With routers being implemented as network namespaces within x86 servers it 
seems like Neutron networks would be pretty bandwidth constrained relative to 
real routers.

As we start migrating the physical connections on our physical routers from 
multiple of 10G to multiples of 100G, I'm wondering if Neutron has a clear 
roadmap towards networks where the bandwidth requirements exceed what an x86 
box can do.

Is the thinking that x86 boxes will soon be capable of 100G and multi-100G 
throughput? Or does DVR take care of this by spreading the routing function 
over a large number of compute nodes so that we don't need to channel 
multi-100G flows through single network nodes?

I'm mostly thinking about WAN connectivity here, video and big data 
applications moving huge amounts of traffic into and out of OpenStack based 
datacenters.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Infra] Meeting Tuesday June 24rd at 19:00 UTC

2014-06-23 Thread Elizabeth K. Joseph

Hi everyone,

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday June 24th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

Meeting minutes and log from last week are available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-06-17-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-06-17-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-06-17-19.01.log.htm

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

On 06/23/2014 10:30 AM, Monty Taylor wrote:
 On 06/23/2014 11:24 AM, Ben Nemec wrote:
 On 06/23/2014 10:02 AM, Doug Hellmann wrote:
 On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:

 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:

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

 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.

 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.

 Which makes more sense, continuing to maintain our library or fixing
 that bug and maintaining pylockfile? How big is pylockfile compared to
 what we have? Does it solve problems our existing locking code doesn't
 solve (and that we care about)?

 It looks to me like pylockfile would provide a subset of the
 functionality in lockutils (for example, I don't see anything to replace
 the @lock decorator).  So I don't think we could just drop lockutils and
 switch to it.  We'd just be switching out the underlying lock mechanism,
 and we know how well that has gone in the past. ;-)
 
 But if we had originally thought to use pylockfile except for the bug,
 and if oslo.lockutils brings in oslo.config making it not suitable for
 general usage - it seems like it would be a good thing for the wider
 community if we 'fix' pylockfile and make oslo.lockutils the
 oslo-ification of it?
 
 I mean, ultimately like everything else in OpenStack we don't REALLY
 want to just have our own set of parallel libs to what the rest of
 python uses, do we?

Fair point.  I guess I've just been scarred by the fact that every
single time we've tried to change the underlying lock mechanics in
lockutils we've found some edge case that gets broken.

But that said, we could limit the changes to lockutils by simply
contributing our lockfile code as an alternative implementation in
pylockfile (it looks like there are already several options there) and
using it from there instead.  Then it's more of a refactoring with the
side benefit that anyone else can use the code too, and we have the
option of using other pylockfile implementations if need be.  I could
get behind that, so consider my objection to adopting this withdrawn.

 


 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.

 That makes sense. When I made the list of libraries to release this
 time, I called them all oslo.foo because I wasn't digging into the
 code deep enough to figure out whether they could be something else. I
 expected the person managing the spec for the release to do that step,
 but I may not have made that clear.

 The main thing I would be concerned with about using a non-oslo name
 for oslo.concurrency is whether or not it uses another oslo library
 like oslo.config. If we can completely avoid those dependencies, then
 it should be safe to release it under a name other than
 oslo.concurrency.

 Oh, that's probably why I didn't suggest this in the first place.
 lockutils uses oslo.config, so it does need to be in the oslo namespace.

 I don't think we can drop the oslo.config dep, but we might be able to
 decouple it like oslo.db did.  I think that would be messy though
 because Windows is where problems would come up and we don't test
 Windows in the gate. :-/


 Doug



 Cheers,



 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Brandon Logan

Vijay,
I think the separate entity is still going to happen.  I don't think it
has remvoed.  Or that is may just be my assumption.

Thanks,
Brandon

On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
 Hi:
 
  
 In the “LBaaS TLS termination capability specification” proposal 
  
 https://review.openstack.org/#/c/98640/
  
 TLS settings like default certificate container id and SNI cert list are part 
 of the listener properties. 
  
 I think it is better to have this as a separate entity so that the listener 
 properties are clean and is not “corrupted” with TLS settings.
  
 I liked the original SSL proposal better where TLS settings was a separate 
 entity.
  
 It is just 2 properties now but in future the TLS settings would grow and if 
 we are going to introduce a TLS profile/params/settings entity later, it is 
 better to do it now (albeit with min properties).
  
 Thanks,
 Vijay V.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] proposing specs for approval

We have 3 specs that I think are at a stage where we can approve them.

https://review.openstack.org/#/c/97228/ - Add ConfigFilter wrapper
class for ConfigOpts

This one is already approved, but since we didn't follow the process I
thought I would include it in case anyone had an objection.

https://review.openstack.org/#/c/97315/ - Graduate oslo.serialization

This has 2 core approvals and one addtional +1.

https://review.openstack.org/#/c/95870/ - remove-context-adapter

This only has one +2, but we talked about it extensively at the summit
and there were no objections there.

If you object to approving any of them, please vote -1. I will approve
them Wednesday if there are no objections by then.

Doug

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] High bandwidth routers

2014-06-23 Thread Collins, Sean

You can use the provider networking API extension for Neutron, in order
to utilize non-openstack L3 hardware.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Periodic Security Checks

2014-06-23 Thread Clark, Robert Graham

I think this is very interesting and would love to see the code for it.

The blueprint mentions performing checks beyond what Open Attestation
provides, add dynamic check to verify memory - this is probably a
stretch goal as process memory verification is extremely complex. I'm
not aware of anyone doing it well though I'd love to be corrected on
that point. I also wonder how, if working outside of Open Attestation
(and I'm assuming outside of TPM) how you will assert that attestations
are accurate.

I'm sure the intel guys will have a lot to contribute here and I'm
excited to see people working to improve Compute security with cool
projects such as this one.

-Rob



 -Original Message-
 From: Grant Murphy [mailto:gmur...@redhat.com]
 Sent: 23 June 2014 00:49
 To: OpenStack Development Mailing List (not for usage questions);
 openstack-secur...@lists.openstack.org
 Cc: Vasiliy Artemev; David Yuan
 Subject: Re: [Openstack-security] [openstack-dev] Periodic Security
Checks
 
 Adding openstack-security to the thread. In case folks on OSSG don't
 monitor this list.
 
 - Original Message -
  From: Alexandr Naumchev anaumc...@gmail.com
  To: openstack-dev@lists.openstack.org
  Cc: Amey Ghadigaonkar gamoholic...@gmail.com, Vasiliy Artemev
 vas...@gmail.com, David Yuan
  david.yuanh...@gmail.com
  Sent: Sunday, June 22, 2014 4:33:35 AM
  Subject: [openstack-dev] Periodic Security Checks
 
  Hello!
  We have blueprints here:
 
 
https://blueprints.launchpad.net/horizon/+spec/periodic-security-check
  s
 
  and here:
 
 
https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/
 
  And we already have some code. Is it necessary to approve the
  blueprint before contributing the code? In any case, could someone
  review the aforementioned blueprints?
  Thanks!
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 Openstack-security mailing list
 openstack-secur...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

2014-06-23 Thread Clint Byrum

Excerpts from Mark McLoughlin's message of 2014-06-22 00:39:29 -0700:
 The main point is that this is something worth addressing as a wider
 community rather than in individual reviews with a limited audience. And
 that doing it with a bit of humor might help take the sting out of it.
 

Yes, a private message saying Hey fellow earthling, do we really care
whether httplib is grouped with os or eventlet? is a productive thing
indeed! However, turning that into something that we can all publicly
laugh about requires some real skill, and trust between us all. Given
our digital communication mediums, it is not likely we can do it all
that regularly. I think at best we could gather them all into a couple
of keynote slides with the authors' blessings (oh please, somebody do
this!)

However, if we can all look inward and just do it with self deprecation
I'm all for it.

The main point I am making is that the less grey areas we have, the less
of this we ever have to worry about. It is worth it, to me, to look into
keeping this rule alive so that we never ever have to discuss import
grouping.

(BTW, how many release cycles does one have to deprecate themselves
before they remove themselves?)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

2014-06-23 Thread Clint Byrum

Excerpts from Christopher Yeoh's message of 2014-06-22 18:46:59 -0700:
 On Mon, Jun 23, 2014 at 4:43 AM, Jay Pipes jaypi...@gmail.com wrote:
 
  On 06/22/2014 09:41 AM, Amrith Kumar wrote:
 
  In addition to making changes to the hacking rules, why don't we mandate
  also
  that perceived problems in the commit message shall not be an acceptable
  reason to -1 a change.
 
  Would this improve the situation?
 
 
  I actually *do* think a very poor commit message for a substantial patch
  deserves a -1. The git commit message is our history for the patch, and it
  is important in its own right. Now, nits like a single misspelled word or
  the commit summary being 60 characters instead of 50 are not what I'm
  talking about, of course.
 
  I'm speaking only about when a commit message blatantly disregards the
  best practices of commit message writing [1] and doesn't offer anything of
  value to the reviewer.
 
 
 +1.
 
 Minor typos and grammatical errors I don't  care about (but will put in
 suggested fixes if the patch needs to be updated anyway). However, commit
 messages are very important for future debugging. One or two line vague
 commit messages can make life a lot harder for others in the future when
 writing a short description is not what I'd consider an excessive burden.
 And there should be no assumption that the person reading the commit
 message will have easy access to the bug database.
 

We've had this discussion already, but just remember that not everybody
reading those commit messages will be a native English speaker. The more
incorrect the grammar and punctuation is, the more confusing it will be
to somebody who is already struggling with those concepts.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopting pylockfile

On Mon, Jun 23, 2014 at 12:42 PM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 10:30 AM, Monty Taylor wrote:
 On 06/23/2014 11:24 AM, Ben Nemec wrote:
 On 06/23/2014 10:02 AM, Doug Hellmann wrote:
 On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote:
 On 06/23/2014 08:41 AM, Julien Danjou wrote:
 Hi there,

 We discovered a problem in pylockfile recently, and after
 discussing with its current maintainer, it appears that more help
 and workforce would be require:

 https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012

  Since we are using it via oslo lockutils module, I proposed to
 adopt this project under the Oslo program banner. The review to
 copy the repository to our infrastructure is up at:

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

 We actually don't use this in lockutils - we use our own
 implementation of LockFile because there was some sort of outstanding
 bug in pylockfile that made it not work for us.  The only place I can
 see that we do use that project is in the oslo.db code because we
 didn't want to depend on incubator modules there, but once
 oslo.concurrency graduates we can switch to using our own locking
 implementation again.

 Basically I think this would be duplicating what we're already doing
 in lockutils, so I'm -1 on it.  I'd rather focus on getting
 oslo.concurrency graduated and remove pylockfile from
 global-requirements to make sure no one is using it anymore.

 Which makes more sense, continuing to maintain our library or fixing
 that bug and maintaining pylockfile? How big is pylockfile compared to
 what we have? Does it solve problems our existing locking code doesn't
 solve (and that we care about)?

 It looks to me like pylockfile would provide a subset of the
 functionality in lockutils (for example, I don't see anything to replace
 the @lock decorator).  So I don't think we could just drop lockutils and
 switch to it.  We'd just be switching out the underlying lock mechanism,
 and we know how well that has gone in the past. ;-)

 But if we had originally thought to use pylockfile except for the bug,
 and if oslo.lockutils brings in oslo.config making it not suitable for
 general usage - it seems like it would be a good thing for the wider
 community if we 'fix' pylockfile and make oslo.lockutils the
 oslo-ification of it?

 I mean, ultimately like everything else in OpenStack we don't REALLY
 want to just have our own set of parallel libs to what the rest of
 python uses, do we?

 Fair point.  I guess I've just been scarred by the fact that every
 single time we've tried to change the underlying lock mechanics in
 lockutils we've found some edge case that gets broken.

 But that said, we could limit the changes to lockutils by simply
 contributing our lockfile code as an alternative implementation in
 pylockfile (it looks like there are already several options there) and
 using it from there instead.  Then it's more of a refactoring with the
 side benefit that anyone else can use the code too, and we have the
 option of using other pylockfile implementations if need be.  I could
 get behind that, so consider my objection to adopting this withdrawn.

+1





 This also makes me wonder if oslo.concurrency should not be an oslo.*
 library since this functionality is more generally applicable outside
 OpenStack.  Something to discuss anyway.

 That makes sense. When I made the list of libraries to release this
 time, I called them all oslo.foo because I wasn't digging into the
 code deep enough to figure out whether they could be something else. I
 expected the person managing the spec for the release to do that step,
 but I may not have made that clear.

 The main thing I would be concerned with about using a non-oslo name
 for oslo.concurrency is whether or not it uses another oslo library
 like oslo.config. If we can completely avoid those dependencies, then
 it should be safe to release it under a name other than
 oslo.concurrency.

 Oh, that's probably why I didn't suggest this in the first place.
 lockutils uses oslo.config, so it does need to be in the oslo namespace.

 I don't think we can drop the oslo.config dep, but we might be able to
 decouple it like oslo.db did.  I think that would be messy though
 because Windows is where problems would come up and we don't test
 Windows in the gate. :-/


 Doug



 Cheers,



 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___

Re: [openstack-dev] [OpenStack-Infra] Nomination for python-jenkins

2014-06-23 Thread Clark Boylan

On Mon, Jun 23, 2014 at 1:42 AM, Antoine Musso has...@free.fr wrote:
 Hello,

 The python-jenkins module is a thin wrapper to interact with Jenkins. It
 has been migrated from Launchpad to Stackforge a couple months ago to
 attract more developers and easily upstream work down being done in over
 OpenStack projects (such as NodePool or Jenkins Job Builder).

 I would like to propose Marc Abramowitz as a core reviewer to the
 python-jenkins module.  He wrote a test suite with 100% coverage and
 added support for python 3.

 https://review.openstack.org/#/q/reviewer:%22Marc+Abramowitz%22+project:stackforge/python-jenkins,n,z

 Please endorse/reject the nomination by replying to this thread.  Will
 find out a way to get him added if consensus is reached.

 Thank you!

 --
 Antoine hashar Musso

 ___
 OpenStack-Infra mailing list
 openstack-in...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

+1. Thank you Marc for the help!

Clark

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [infra] Nominations for jenkins-job-builder core

2014-06-23 Thread Clark Boylan

On Mon, Jun 23, 2014 at 1:35 AM, Antoine Musso has...@free.fr wrote:
 Le 23/06/2014 01:47, Jeremy Stanley a écrit :
 On 2014-06-20 14:01:01 -0700 (-0700), James E. Blair wrote:
  The Jenkins Job Builder project [...] core reviewers [...] I would
  like to add Darragh Bailey [...] and Marc Abramowitz
 [...]

 I'm very much in favor of both Darragh and Marc as additions to the
 openstack-infra/jenkins-job-builder project core reviewer team.
 Their knowledge of the project internals and support of its existing
 core reviewers has been invaluable.

 Hello,

 As Jeremy said, I definitely support both nominations.  They both have
 been a huge asset to the JJB project.

I completely agree. It has been great to see people take an interest
in JJB as a general tool and drive it with less and less input from
OpenStack Infra. +1 to both nominations from me.

Clark

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

2014-06-23 Thread Joe Gordon

Answers to the specifics of this thread here, and I will follow up with a
seperate thread on the broader topic.

On Mon, Jun 23, 2014 at 7:21 AM, Ben Nemec openst...@nemebean.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/23/2014 06:18 AM, Sean Dague wrote:
  On 06/22/2014 03:04 PM, Jay Pipes wrote:
  On 06/20/2014 02:07 PM, Sean Dague wrote:
  After seeing a bunch of code changes to enforce new hacking
  rules, I'd like to propose dropping some of the rules we have.
  The overall patch series is here -
 
 https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z
 
 
 
 
 H402 - 1 line doc strings should end in punctuation. The real statement
  is this should be a summary sentence. A sentence is not just a
  set of words that end in a period. Squirel fast bob. It's
  something deeper. This rule thus isn't really semantically
  useful, especially when you are talking about at 69 character
  maximum (79 - 4 space indent - 6 quote characters).
 
  ++ This was always a silly rule, IMO
 
  Sorry, forgot to add a period. There. Better.


After looking at http://legacy.python.org/dev/peps/pep-0257/ it says

  The docstring is a phrase ending in a period. It prescribes the function
or method's effect as a command (Do this, Return that), not as a
description; e.g. don't write Returns the pathname '


So it looks like pep257 doesn't agree with you, and I am confused at pep257
itself.

That being said since most folks aren't a fan, I am for removing it.


 
  H803 - First line of a commit message must *not* end in a
  period. This was mostly a response to an unreasonable core
  reviewer that was -1ing people for not having periods. I think
  any core reviewer that -1s for this either way should be thrown
  off the island, or at least made fun of, a lot. Again, the
  clarity of a commit message is not made or lost by the lack or
  existence of a period at the end of the first line.
 
  +10
 
  Sorry, I meant +10. Period.
 

 I'm good with removing the punctuation ones, especially for the commit
 message.



I think there is a fairly strong concensus on removing H803, it should have
never landed in the first place.



  H305 - Enforcement of libraries fitting correctly into stdlib,
  3rdparty, our tree. This biggest issue here is it's built in a
  world where there was only 1 viable python version, 2.7.
  Python's stdlib is actually pretty dynamic and grows over time.
  As we embrace more python 3, and as distros start to make
  python3 be front and center, what does this even mean? The
  current enforcement can't pass on both python2 and python3 at
  the same time in many cases because of that.
 
  +0 on this one... I find it useful to group the libs together in
  this way, as it makes it relatively easy to identify quickly at a
  glance the third party libs that are in use in the module.
 
  Sure, I'm not saying don't group. I'm saying that it's actually
  impossible to create a formal definition for group 2. So use it as
  guidelines don't enforce in code.

 I'm -1 on manual enforcement of these rules.  I hate -1'ing a patch
 (especially one that's been in review for a while) just for import
 grouping issues, and if I'm not going to -1 for that then why even
 pretend it's something we want to do?

 I'd rather have an exception mechanism for the check where we can make
 a list of modules that can be in either stdlib or third-party and
 allow both.  I don't think the Python stdlib is changing so fast that
 we couldn't keep such a list maintained and it would allow these
 checks to still be automated.  In fact, it should be possible to
 generate the list programmatically.

 Obviously I am signing up to do this work if it's something we can
 agree on.



Sounds like Ben just volunteered to fix this one up, thank you. So given
Ben's offer to fix this up I don't think we should remove it.


 
  We have to remember we're all humans, and it's ok to have grey
  space. Like in 305, you *should* group the libraries if you
  can, but stuff like that should be labeled as 'nit' in the
  review, and only ask the author to respin it if there are other
  more serious issues to be handled.
 
  Ya, no real disagreement on that.
 
  Let's optimize a little more for fun, and stop throwing -1s for
  silly things. :)
 
  ++
 
  I would also love to get rid of H404, otherwise known as the dumb
  rule that says if you have a multiline docstring, that there must
  be a summary line, then a blank line, then a detailed
  description. It makes things like this illegal, which, IMHO, is
  stupid:
 
  def do_something(self, thing): We do something with the
  supplied thing, so that something else is also done with this
  other thing. Make sure the other thing is of type something. 
  pass
 
  Likewise, I'd love to be able to have a newline start the
  docstring, like so:
 
  def do_something(self, thing):  We do something with the
  supplied thing, so that something

Re: [openstack-dev] [OpenStack-Infra] [infra] Nominations for jenkins-job-builder core

2014-06-23 Thread Zaro

+1 for both Marc and Darragh

On Mon, Jun 23, 2014 at 6:54 PM, Clark Boylan clark.boy...@gmail.com wrote:
 On Mon, Jun 23, 2014 at 1:35 AM, Antoine Musso has...@free.fr wrote:
 Le 23/06/2014 01:47, Jeremy Stanley a écrit :
 On 2014-06-20 14:01:01 -0700 (-0700), James E. Blair wrote:
  The Jenkins Job Builder project [...] core reviewers [...] I would
  like to add Darragh Bailey [...] and Marc Abramowitz
 [...]

 I'm very much in favor of both Darragh and Marc as additions to the
 openstack-infra/jenkins-job-builder project core reviewer team.
 Their knowledge of the project internals and support of its existing
 core reviewers has been invaluable.

 Hello,

 As Jeremy said, I definitely support both nominations.  They both have
 been a huge asset to the JJB project.

 I completely agree. It has been great to see people take an interest
 in JJB as a general tool and drive it with less and less input from
 OpenStack Infra. +1 to both nominations from me.

 Clark

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [DevStack] fails in lxc running ubuntu trusty amd64

2014-06-23 Thread Mike Spreitzer

Jérôme Gallard gallard.jer...@gmail.com wrote on 06/19/2014 03:55:10 AM:

 We worked with Devstack and LXC and got the same issue ( https://
 blueprints.launchpad.net/devstack/+spec/lxc-computes ).

That blames open-iscsi, but the problem is now tgt.  Cinder seems to have 
switched from open-iscsi to tgt.

The install of tgt inside the LXC fails.  Here is what that looks like:

# apt-get install tgt
...
Setting up tgt (1:1.0.43-0ubuntu4) ...
start: Job failed to start
invoke-rc.d: initscript tgt, action start failed.
dpkg: error processing package tgt (--configure):
 subprocess installed post-installation script returned error exit status 
1
Processing triggers for libc-bin (2.19-0ubuntu6) ...
Processing triggers for ureadahead (0.100.0-16) ...
Errors were encountered while processing:
 tgt
E: Sub-process /usr/bin/dpkg returned an error code (1)

What's going on is that the install script for the tgt package launches 
the daemon, tgtd.  That launch fails.  Here is a typescript showing more 
details of how it fails:

# tgtd -d 1 -f
librdmacm: couldn't read ABI version.
librdmacm: assuming: 4
CMA: unable to get RDMA device list
tgtd: iser_ib_init(3351) Failed to initialize RDMA; load kernel modules?
can't adjust oom-killer's pardon /proc/self/oom_score_adj, Permission 
denied

Thanks,
Mike

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

The separate entity makes sense for certificates participating in an SNI
configuration, but probably not so much for the 'default' certificate used
when TLS is being terminated.

Vijay: You're also right that other TLS-related attributes will probably
get added to the Listener object. This probably makes sense if they apply
to the Listener object as a whole. (This includes things like TLS version
and cipher selection.)

I don't see much of a point in creating a separate object to contain these
fields, since it would have a 1:1 relationship with the Listener. It's true
that for non-TLS-terminated Listeners, these fields wouldn't be used, but
isn't that already the case in many other objects (not just in the Neutron
LBaaS sub project)?

Thanks,
Stephen




On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Vijay,
 I think the separate entity is still going to happen.  I don't think it
 has remvoed.  Or that is may just be my assumption.

 Thanks,
 Brandon

 On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
  Hi:
 
 
  In the “LBaaS TLS termination capability specification” proposal
 
  https://review.openstack.org/#/c/98640/
 
  TLS settings like default certificate container id and SNI cert list are
 part of the listener properties.
 
  I think it is better to have this as a separate entity so that the
 listener properties are clean and is not “corrupted” with TLS settings.
 
  I liked the original SSL proposal better where TLS settings was a
 separate entity.
 
  It is just 2 properties now but in future the TLS settings would grow
 and if we are going to introduce a TLS profile/params/settings entity
 later, it is better to do it now (albeit with min properties).
 
  Thanks,
  Vijay V.
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Nomination for python-jenkins

2014-06-23 Thread Mathieu Gagné


On 2014-06-23 4:42 AM, Antoine Musso wrote:

Hello,

The python-jenkins module is a thin wrapper to interact with Jenkins. It
has been migrated from Launchpad to Stackforge a couple months ago to
attract more developers and easily upstream work down being done in over
OpenStack projects (such as NodePool or Jenkins Job Builder).

I would like to propose Marc Abramowitz as a core reviewer to the
python-jenkins module.  He wrote a test suite with 100% coverage and
added support for python 3.

https://review.openstack.org/#/q/reviewer:%22Marc+Abramowitz%22+project:stackforge/python-jenkins,n,z

Please endorse/reject the nomination by replying to this thread.  Will
find out a way to get him added if consensus is reached.

Thank you!



+1

Will be a great addition.

--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [blazar] Blazar Nova renaming patches

2014-06-23 Thread Fuente, Pablo A

I finished the Blazar-Nova renaming. The only thing left is to update
oslo with the new name, but I'll do that when the rename patches land to
master. So, cores please give your blessing to this patches:
https://review.openstack.org/98496, https://review.openstack.org/100914,
https://review.openstack.org/101953

Pablo.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers

2014-06-23 Thread Eric Harney

On 06/23/2014 11:07 AM, Trump.Zhang wrote:
 Hi, all:
 
 Currently, there are several filesystem-based drivers in Cinder, such
 as nfs, glusterfs, etc. Multiple format of volume other than raw can be
 potentially supported in these drivers, such as qcow2, raw, sparse, etc.
 
 However, Cinder does not store the actual format of volume and suppose
 all volumes are raw format. It will has or already has several problems
 as follows:
 
 1. For volume migration, the generic migration implementation in Cinder
 uses the dd command to copy src volume to dest volume. If the src
 volume is qcow2 format, instance will not get the right data from volume
 after the dest volume attached to instance, because the info returned from
 Cinder states that the volume's format is raw other than qcow2
 2. For volume backup, the backup driver also supposes that src volumes
 are raw format, other format will not be supported
 
 Indeed, glusterfs driver has used qemu-img info command to judge the
 format of volume. However, as the comment from Duncan in [1] says, this
 auto detection method has many possible error / exploit vectors. Because if
 the beginning content of a raw volume happens to a qcow2 disk, auto
 detection method will judge this volume to be a qcow2 volume wrongly.
 
 I proposed that the format info should be added to admin_metadata
 of volumes, and enforce it on all operations, such as create, copy, migrate
 and retype. The format will be only set / updated for filesystem-based
 drivers,  other drivers will not contains this metadata and have a default
 raw format.
 
 Any advice?
 
 [1] https://review.openstack.org/#/c/100529/
 

I agree with the concerns here, and I think storing the creation format
is the right idea.  Please file a blueprint describing the fix and I'll
help review from there.

Eric


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [marconi][qa] marconi check run in tempest is on experimental queue

2014-06-23 Thread David Kranz

Please remember to do 'check experimental' after uploading new marconi 
patches in tempest.


 -David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] dib-utils Release Question

2014-06-23 Thread Jay Dobies

I finished the releases for all of our existing projects and after 
poking around tarballs.openstack.org and pypi, it looks like they built 
successfully. Yay me \o/


However, it doesn't look like dib-utils build worked. I don't see it 
listed on tarballs.openstack.org. It was the first release for that 
project, but I didn't take any extra steps (I just followed the 
instructions on the releases wiki and set it to version 0.0.1).


I saw the build for it appear in zuul but I'm not sure how to go back 
and view the results of a build once it disappears off the main page.


Can someone with experience releasing a new project offer me any insight?

Thanks  :)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] default security group rules in neutron

2014-06-23 Thread Mathieu Gagné


On 2014-06-22 10:23 PM, Lingxian Kong wrote:


So, for the functionality parity between nova-network and neutron and
for our use case, I registered a blueprint[2] about default security
group rules in Neutron days ago and related neutron spec[3], and I
want it to be involved in Juno, so we can upgrade our deployment that
time for this feature. I'm ready for the code implementation[3].

But I still want to see what's the community's thought about including
this feature in neutron, any of your feedback and comments are
appreciated!



+1

That's awesome news! Glad to hear someone is working on it.

I already implemented (for our own cloud) a similar feature which allows 
an operator to override the set of default security group rules using a 
yaml config file. So yea... you can't edit it through the API, I'm not 
that fancy =)


I'm unfortunately guilty of not proposing it upstream or publishing it 
somewhere. I'll see if I can publish it somewhere this week. Though 
limited in feature, hopefully it will be useful to someone else too.


--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

2014-06-23 Thread Mathieu Gagné


On 2014-06-23 1:28 PM, Clint Byrum wrote:


We've had this discussion already, but just remember that not everybody
reading those commit messages will be a native English speaker. The more
incorrect the grammar and punctuation is, the more confusing it will be
to somebody who is already struggling with those concepts.



I often git log --grep for keywords. I would like important keywords to 
still be correctly written.


--
Mathieu

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [blazar] trust_id critical bug

2014-06-23 Thread Fuente, Pablo A

Blazar cores,
Please check https://review.openstack.org/#/c/102004/
It fixes https://launchpad.net/bugs/1333413
I found the bug using our tempest test suite ;) (I'm trying to get that
tempest suite as a gate job)

Thanks.

Pablo.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Brandon Logan

Okay so we've talked a bit about this in IRC and now I'm sending this
out as an update.  Here are the options with pros and cons that have
come from that discussion.

1) default_certificate_id is an attribute of the Listener object.

Pros:
-No extra entity needed

Cons:
-May bloat Listener object when more attributes are needed for only TLS
termination.  Sounds like TLS version and cipher selection will be
needed attributes in the future.


2) A separate TLS Entity is created that is referenced by the Listener
object.  This entity at first may only contain a certificate_id that
references barbican.  Name and description can be allowed as well.

Pros:
-TLS domain specific attributes contained in its own entity
-Future attributes would just be added to this entity and not bloat the
Listener object.

Cons:
-It's another entity

In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
go.  Anyone agree or disagree?

Thanks,
Brandon

On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
 The separate entity makes sense for certificates participating in an
 SNI configuration, but probably not so much for the 'default'
 certificate used when TLS is being terminated.
 
 
 Vijay: You're also right that other TLS-related attributes will
 probably get added to the Listener object. This probably makes sense
 if they apply to the Listener object as a whole. (This includes things
 like TLS version and cipher selection.)
 
 
 I don't see much of a point in creating a separate object to contain
 these fields, since it would have a 1:1 relationship with the
 Listener. It's true that for non-TLS-terminated Listeners, these
 fields wouldn't be used, but isn't that already the case in many other
 objects (not just in the Neutron LBaaS sub project)?
 
 
 Thanks,
 Stephen
 
 
 
 
 
 
 On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
 brandon.lo...@rackspace.com wrote:
 Vijay,
 I think the separate entity is still going to happen.  I don't
 think it
 has remvoed.  Or that is may just be my assumption.
 
 Thanks,
 Brandon
 
 On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
  Hi:
 
 
  In the “LBaaS TLS termination capability specification”
 proposal
 
  https://review.openstack.org/#/c/98640/
 
  TLS settings like default certificate container id and SNI
 cert list are part of the listener properties.
 
  I think it is better to have this as a separate entity so
 that the listener properties are clean and is not “corrupted”
 with TLS settings.
 
  I liked the original SSL proposal better where TLS settings
 was a separate entity.
 
  It is just 2 properties now but in future the TLS settings
 would grow and if we are going to introduce a TLS
 profile/params/settings entity later, it is better to do it
 now (albeit with min properties).
 
  Thanks,
  Vijay V.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Stephen Balukoff 
 Blue Box Group, LLC 
 (800)613-4305 x807
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-php-sdk] pending reviews

2014-06-23 Thread Matthew Farina

Rob,

This project is in PHP. We don't currently have a full test suite run for
the project via the gates. When we set it up we were told not to go down
that road for a PHP project, yet. Only recently have we been told to see
about getting test suite gate testing going and I've started to look at
doing it for things outside of python.

That's why I wanted to run the full test suite locally.

- Matt



On Fri, Jun 20, 2014 at 1:44 AM, Robert Collins robe...@robertcollins.net
wrote:

 What does that check that the gate doesn't?

 -Rob


 On 20 June 2014 14:20, Matthew Farina m...@mattfarina.com wrote:

 I'll dig into these on Friday. Thanks for the poke. I started to review
 them on Thursday and most of them are straight forward. But, something
 happened to my test environment and I want to run the full test suite on
 each of these. I should have that fixed and be able to finish working
 through these.


 On Thu, Jun 19, 2014 at 11:26 AM, Jamie Hannaford 
 jamie.hannaf...@rackspace.com wrote:

  Hello all,

  Could we get some reviews through the door? This one is fairly
 straight-forward - we discussed and agreed on the action item in IRC:

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

  Here are some more trivial ones:

  https://review.openstack.org/#/c/100227/
 https://review.openstack.org/#/c/99894/
 https://review.openstack.org/#/c/99889/

  I’m worried that the pace is slowing down.

  Thanks!

  Jamie



   Jamie Hannaford
 Software Developer III - CH [image: experience Fanatical Support]  [image:
 LINE]Tel: +41434303908  Mob: +41791009767   [image: Rackspace]



 Rackspace International GmbH a company registered in the Canton of
 Zurich, Switzerland (company identification number CH-020.4.047.077-1)
 whose registered office is at Pfingstweidstrasse 60, 8005 Zurich,
 Switzerland. Rackspace International GmbH privacy policy can be viewed at
 www.rackspace.co.uk/legal/swiss-privacy-policy
 -
 Rackspace Hosting Australia PTY LTD a company registered in the state of
 Victoria, Australia (company registered number ACN 153 275 524) whose
 registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW
 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be
 viewed at www.rackspace.com.au/company/legal-privacy-statement.php
 -
 Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United
 States of America
 Rackspace US, Inc privacy policy can be viewed at
 www.rackspace.com/information/legal/privacystatement
 -
 Rackspace Limited is a company registered in England  Wales (company
 registered number 03897010) whose registered office is at 5 Millington
 Road, Hyde Park Hayes, Middlesex UB3 4AZ.
 Rackspace Limited privacy policy can be viewed at
 www.rackspace.co.uk/legal/privacy-policy
 -
 Rackspace Benelux B.V. is a company registered in the Netherlands
 (company KvK nummer 34276327) whose registered office is at
 Teleportboulevard 110, 1043 EJ Amsterdam.
 Rackspace Benelux B.V privacy policy can be viewed at
 www.rackspace.nl/juridisch/privacy-policy
 -
 Rackspace Asia Limited is a company registered in Hong Kong (Company no:
 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place,
 979 King's Road, Quarry Bay, Hong Kong.
 Rackspace Asia Limited privacy policy can be viewed at
 www.rackspace.com.hk/company/legal-privacy-statement.php
 -
 This e-mail message (including any attachments or embedded documents) is
 intended for the exclusive and confidential use of the individual or entity
 to which this message is addressed, and unless otherwise expressly
 indicated, is confidential and privileged information of Rackspace. Any
 dissemination, distribution or copying of the enclosed material is
 prohibited. If you receive this transmission in error, please notify us
 immediately by e-mail at ab...@rackspace.com and delete the original
 message. Your cooperation is appreciated.



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] oslo.utils and oslo.local

2014-06-23 Thread Joshua Harlow

Just a quick comment from looking over oslo.utils;

Does it need to bring in oslo.config? Is that needed?

The only place I am seeing it being sucked in is (correct me if I am
wrong):

https://github.com/dims/oslo.utils/blob/master/oslo/utils/network_utils.py#
L25 (the logging module then brings in oslo.config, maybe this can just be
logging not via oslo logging?)

-Original Message-
From: Doug Hellmann doug.hellm...@dreamhost.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Monday, June 23, 2014 at 2:22 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] oslo.utils and oslo.local

I left a few notes on one of the cleanup commits:
https://github.com/dims/oslo.utils/commit/01bca57862633ca43c8f1c05cef761ac
d85a7011

On Thu, Jun 19, 2014 at 7:53 AM, Davanum Srinivas dava...@gmail.com
wrote:
 Hi,

 Please review the following git repo(s):
 https://github.com/dims/oslo.local
 https://github.com/dims/oslo.utils

 the corresponding specs are here:
 https://review.openstack.org/#/c/98431/
 https://review.openstack.org/#/c/99028/

 Thanks,
 dims

 --
 Davanum Srinivas :: http://davanum.wordpress.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [hacking] rules for removal

2014-06-23 Thread melanie witt

On Jun 20, 2014, at 11:07, Sean Dague s...@dague.net wrote:

 H402 - 1 line doc strings should end in punctuation. The real statement
 is this should be a summary sentence. A sentence is not just a set of
 words that end in a period. Squirel fast bob. It's something deeper.
 This rule thus isn't really semantically useful, especially when you are
 talking about at 69 character maximum (79 - 4 space indent - 6 quote
 characters).

+1

 H803 - First line of a commit message must *not* end in a period. This
 was mostly a response to an unreasonable core reviewer that was -1ing
 people for not having periods. I think any core reviewer that -1s for
 this either way should be thrown off the island, or at least made fun
 of, a lot. Again, the clarity of a commit message is not made or lost by
 the lack or existence of a period at the end of the first line.

+1

 H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty,
 our tree. This biggest issue here is it's built in a world where there
 was only 1 viable python version, 2.7. Python's stdlib is actually
 pretty dynamic and grows over time. As we embrace more python 3, and as
 distros start to make python3 be front and center, what does this even
 mean? The current enforcement can't pass on both python2 and python3 at
 the same time in many cases because of that.

I also find the grouping useful for knowing the scope of a module at a glance. 
But I definitely see the problem with not being able to fit python 2 and 3 at 
the same time. If Clint's suggestion of algorithm to sort it out wouldn't be 
too difficult to add, it would be nice.

I'm also strongly for commit messages that make sense and explain what's 
changing and why, and reference related bugs and docs whenever possible.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Brandon Logan

Whoops, [Neutron][LBaaS] got taken out of the subject line here.
Putting it back in.

On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
 Okay so we've talked a bit about this in IRC and now I'm sending this
 out as an update.  Here are the options with pros and cons that have
 come from that discussion.
 
 1) default_certificate_id is an attribute of the Listener object.
 
 Pros:
 -No extra entity needed
 
 Cons:
 -May bloat Listener object when more attributes are needed for only TLS
 termination.  Sounds like TLS version and cipher selection will be
 needed attributes in the future.
 
 
 2) A separate TLS Entity is created that is referenced by the Listener
 object.  This entity at first may only contain a certificate_id that
 references barbican.  Name and description can be allowed as well.
 
 Pros:
 -TLS domain specific attributes contained in its own entity
 -Future attributes would just be added to this entity and not bloat the
 Listener object.
 
 Cons:
 -It's another entity
 
 In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
 go.  Anyone agree or disagree?
 
 Thanks,
 Brandon
 
 On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
  The separate entity makes sense for certificates participating in an
  SNI configuration, but probably not so much for the 'default'
  certificate used when TLS is being terminated.
  
  
  Vijay: You're also right that other TLS-related attributes will
  probably get added to the Listener object. This probably makes sense
  if they apply to the Listener object as a whole. (This includes things
  like TLS version and cipher selection.)
  
  
  I don't see much of a point in creating a separate object to contain
  these fields, since it would have a 1:1 relationship with the
  Listener. It's true that for non-TLS-terminated Listeners, these
  fields wouldn't be used, but isn't that already the case in many other
  objects (not just in the Neutron LBaaS sub project)?
  
  
  Thanks,
  Stephen
  
  
  
  
  
  
  On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
  brandon.lo...@rackspace.com wrote:
  Vijay,
  I think the separate entity is still going to happen.  I don't
  think it
  has remvoed.  Or that is may just be my assumption.
  
  Thanks,
  Brandon
  
  On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
   Hi:
  
  
   In the “LBaaS TLS termination capability specification”
  proposal
  
   https://review.openstack.org/#/c/98640/
  
   TLS settings like default certificate container id and SNI
  cert list are part of the listener properties.
  
   I think it is better to have this as a separate entity so
  that the listener properties are clean and is not “corrupted”
  with TLS settings.
  
   I liked the original SSL proposal better where TLS settings
  was a separate entity.
  
   It is just 2 properties now but in future the TLS settings
  would grow and if we are going to introduce a TLS
  profile/params/settings entity later, it is better to do it
  now (albeit with min properties).
  
   Thanks,
   Vijay V.
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
  
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
  -- 
  Stephen Balukoff 
  Blue Box Group, LLC 
  (800)613-4305 x807
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..

2014-06-23 Thread Clint Byrum

Hello! I would like to turn your attention to this specification draft
that I've written:

https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst

Angus has suggested that perhaps Ceilometer is a better place to handle
this. Can you please comment on the review, or can we have a brief
mailing list discussion about how best to filter notifications?

Basically in Heat when a user boots an instance, we would like to act as
soon as it is active, and not have to poll the nova API to know when
that is. Angus has suggested that perhaps we can just tell ceilometer to
hit Heat with a web hook when that happens.

Thanks!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Also to add to pros for 2:

* Keeping the TLS stuff contained to its own objects means we can have
separate development resources on each and not worry as much about
overlapping domains. (TLS-related knowledge and knowledge of dealing with
TCP / UDP listeners are separate knowledge domains. Or at least, the former
is a more specialized subset of the latter.)

Note that what we're proposing means there's essentially a 1:0-1
relationship between Listener and this new yet-to-be-named object. (0 in
case the Listener is not terminating TLS.)

Stephen

On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 Whoops, [Neutron][LBaaS] got taken out of the subject line here.
 Putting it back in.

 On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
  Okay so we've talked a bit about this in IRC and now I'm sending this
  out as an update.  Here are the options with pros and cons that have
  come from that discussion.
 
  1) default_certificate_id is an attribute of the Listener object.
 
  Pros:
  -No extra entity needed
 
  Cons:
  -May bloat Listener object when more attributes are needed for only TLS
  termination.  Sounds like TLS version and cipher selection will be
  needed attributes in the future.
 
 
  2) A separate TLS Entity is created that is referenced by the Listener
  object.  This entity at first may only contain a certificate_id that
  references barbican.  Name and description can be allowed as well.
 
  Pros:
  -TLS domain specific attributes contained in its own entity
  -Future attributes would just be added to this entity and not bloat the
  Listener object.
 
  Cons:
  -It's another entity
 
  In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
  go.  Anyone agree or disagree?
 
  Thanks,
  Brandon
 
  On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
   The separate entity makes sense for certificates participating in an
   SNI configuration, but probably not so much for the 'default'
   certificate used when TLS is being terminated.
  
  
   Vijay: You're also right that other TLS-related attributes will
   probably get added to the Listener object. This probably makes sense
   if they apply to the Listener object as a whole. (This includes things
   like TLS version and cipher selection.)
  
  
   I don't see much of a point in creating a separate object to contain
   these fields, since it would have a 1:1 relationship with the
   Listener. It's true that for non-TLS-terminated Listeners, these
   fields wouldn't be used, but isn't that already the case in many other
   objects (not just in the Neutron LBaaS sub project)?
  
  
   Thanks,
   Stephen
  
  
  
  
  
  
   On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
   brandon.lo...@rackspace.com wrote:
   Vijay,
   I think the separate entity is still going to happen.  I don't
   think it
   has remvoed.  Or that is may just be my assumption.
  
   Thanks,
   Brandon
  
   On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
Hi:
   
   
In the “LBaaS TLS termination capability specification”
   proposal
   
https://review.openstack.org/#/c/98640/
   
TLS settings like default certificate container id and SNI
   cert list are part of the listener properties.
   
I think it is better to have this as a separate entity so
   that the listener properties are clean and is not “corrupted”
   with TLS settings.
   
I liked the original SSL proposal better where TLS settings
   was a separate entity.
   
It is just 2 properties now but in future the TLS settings
   would grow and if we are going to introduce a TLS
   profile/params/settings entity later, it is better to do it
   now (albeit with min properties).
   
Thanks,
Vijay V.
  
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
   
  
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
  
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
   --
   Stephen Balukoff
   Blue Box Group, LLC
   (800)613-4305 x807
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list

Re: [openstack-dev] [marconi][qa] marconi check run in tempest is on experimental queue

2014-06-23 Thread Malini Kamalambal

Oops- My bad!
I just started it.
Thanks for the reminder David.

On 6/23/14 4:31 PM, David Kranz dkr...@redhat.com wrote:

Please remember to do 'check experimental' after uploading new marconi
patches in tempest.

  -David

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-sdk-php] Use of final and private keywords to limit extending

2014-06-23 Thread Matthew Farina

This is the follow-up after our conversation last week.

We should have goals to 1) enable a wide array of developers using PHP
to be successful and 2) to keep things as simple as possible.

In the meeting Jamie suggested the Symfony developers and supporting
community around that might be a representative sample of PHP
developers. I don't believe this is the case. There are a few reasons.

1. There are far more Wordpress developers than Symfony by far. I'm
not suggesting we follow the style of Wordpress but a Wordpress
developer shouldn't need to know the style of Symfony to use the SDK.
2. There are far more Drupal developers than Symfony ones. Drupal 7,
which is the current stable version, is far different in style. Drupal
8 is using Symfony but isn't borrowing all the Symfony coding styles.
For example, you're not going to find it using private or final.
3. I've worked in multiple proprietary PHP codebases over the years.
The styles there have been far reaching.

In PHP there isn't one style to rule them all. We need to enable
developers in all these camps to be successful.

There is an assumption we should make as well. We're not going to know
all the ways developers are going to want to use or extend the code.
There may even be organization reasons to stop people from telling us
everything.

If we assume we aren't going to know all the ways people will want to
use and extend the codebase and the wide array or developers using the
project keeping it simple might make it easier for all the camps to
use.

I like to think of this from the outside looking in rather than
someone building the SDK. The two uses that come to mind are:

1. A developer using the library in the SDK to manage services.
2. A developer in any of these camps extending the SDK.

After these two come the developer who is building the SDK.

Since this conversation centers on private and final usage I'm looking
at the #2 case here for developers in the long tail of PHP camps. I've
had the *opportunity* to work in some of these over the years.

I'm thinking in terms of extension use cases like (from my earlier email):

 1. Someone needs to add functionality to a class but can't add it back
 upstream. That could be because they are in a hurry to get their app
 out and aren't concerned with contributing it or because the
 organization they work for won't let them release it in a timely
 manner or ever.

 2. A vendor needs to extend a class to add functionality. For example,
 extending objet storage to add CDN support.

Given that, using final would block using inheritance which many
developers would want to use for both of these use cases. For example:

class ACMEObject extends Object {

  // Add support for custom extension or fix bug that can't go
upstream right now.

}

This is a way many will pursue and many would argue is legitimate.
Given that, I'd rather sidestep that conversation all together and try
to enable everyone to be successful. We can't dictate how they should
write code. There isn't agreement on the right way to do it.

The other space is with private methods. If we have private methods
and someone extends the code they don't have access to the private
methods. That means code duplication is going to happen around that.
We alleviate their pain by not having anything private.

Note, I'm positioning the user who wants to extend the code ahead of
those who develop the code. It's a matter of priority with end users
being higher than developers.

With that in mind, I've worked on software projects where we could use
semantic versioning, protected items (for the first type of user who
calls to objects as an API), simple design, and no use of private or
final without a problem.

If we were creating something designed to be used by Drupal developers
I would do things one way. If it were designed to be used by Wordpress
devs I would do things a different way. If it were designed to be used
by those who do things the Symfony way I would target it to fit there.
Since we want to cover all of these audiences and more let's make it
accessible to all of them.

At it's simplest we can have interfaces that define things and then
check against the interfaces. Then we have objects which provide a
default implementation and building blocks. Users use those building
blocks at their own risk.

For example, we have the class Object.

$o = new Object('http://endpoint');
$o-setContainer('foo');
$o-setPath('bar/baz');
$o-load();

Now we have a loaded object. If someone wants to extend this to create
ACMEObject they can. As long as interfaces are followed behavior will
work.

Now, there is the case for internal methods in our implementation we
might want to change. We avoid making changes. If we must we use
semantic versioning. This is to prioritize our users.

The library in an SDK isn't exciting work. It's not a framework or
some fantastic application. It helps a wide variety of others do that
while consuming our services.

I can imagine there

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

2014-06-23 Thread Doug Wiegley

Put me down for being in favor of option 1.

A single attribute in a 1:1 relationship?  Putting that in a new table sounds 
like premature optimization to me; design the database change for the future 
feature when you can see the spec for it.

Thanks,
Doug


From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, June 23, 2014 at 5:25 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener 
be set through separate API/model?

Also to add to pros for 2:

* Keeping the TLS stuff contained to its own objects means we can have separate 
development resources on each and not worry as much about overlapping domains. 
(TLS-related knowledge and knowledge of dealing with TCP / UDP listeners are 
separate knowledge domains. Or at least, the former is a more specialized 
subset of the latter.)

Note that what we're proposing means there's essentially a 1:0-1 relationship 
between Listener and this new yet-to-be-named object. (0 in case the Listener 
is not terminating TLS.)

Stephen

On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Whoops, [Neutron][LBaaS] got taken out of the subject line here.
Putting it back in.

On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
 Okay so we've talked a bit about this in IRC and now I'm sending this
 out as an update.  Here are the options with pros and cons that have
 come from that discussion.

 1) default_certificate_id is an attribute of the Listener object.

 Pros:
 -No extra entity needed

 Cons:
 -May bloat Listener object when more attributes are needed for only TLS
 termination.  Sounds like TLS version and cipher selection will be
 needed attributes in the future.


 2) A separate TLS Entity is created that is referenced by the Listener
 object.  This entity at first may only contain a certificate_id that
 references barbican.  Name and description can be allowed as well.

 Pros:
 -TLS domain specific attributes contained in its own entity
 -Future attributes would just be added to this entity and not bloat the
 Listener object.

 Cons:
 -It's another entity

 In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
 go.  Anyone agree or disagree?

 Thanks,
 Brandon

 On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
  The separate entity makes sense for certificates participating in an
  SNI configuration, but probably not so much for the 'default'
  certificate used when TLS is being terminated.
 
 
  Vijay: You're also right that other TLS-related attributes will
  probably get added to the Listener object. This probably makes sense
  if they apply to the Listener object as a whole. (This includes things
  like TLS version and cipher selection.)
 
 
  I don't see much of a point in creating a separate object to contain
  these fields, since it would have a 1:1 relationship with the
  Listener. It's true that for non-TLS-terminated Listeners, these
  fields wouldn't be used, but isn't that already the case in many other
  objects (not just in the Neutron LBaaS sub project)?
 
 
  Thanks,
  Stephen
 
 
 
 
 
 
  On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
  brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
  Vijay,
  I think the separate entity is still going to happen.  I don't
  think it
  has remvoed.  Or that is may just be my assumption.
 
  Thanks,
  Brandon
 
  On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
   Hi:
  
  
   In the “LBaaS TLS termination capability specification”
  proposal
  
   https://review.openstack.org/#/c/98640/
  
   TLS settings like default certificate container id and SNI
  cert list are part of the listener properties.
  
   I think it is better to have this as a separate entity so
  that the listener properties are clean and is not “corrupted”
  with TLS settings.
  
   I liked the original SSL proposal better where TLS settings
  was a separate entity.
  
   It is just 2 properties now but in future the TLS settings
  would grow and if we are going to introduce a TLS
  profile/params/settings entity later, it is better to do it
  now (albeit with min properties).
  
   Thanks,
   Vijay V.
 
   ___
   OpenStack-dev mailing list
   
  OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?

Ok, so we've got opinions on both sides of the argument here. I'm actually
pretty ambivalent about it. Do others have strong opinions on this?


On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley do...@a10networks.com wrote:

  Put me down for being in favor of option 1.

  A single attribute in a 1:1 relationship?  Putting that in a new table
 sounds like premature optimization to me; design the database change for
 the future feature when you can see the spec for it.

  Thanks,
 Doug


   From: Stephen Balukoff sbaluk...@bluebox.net
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Monday, June 23, 2014 at 5:25 PM
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for
 listener be set through separate API/model?

   Also to add to pros for 2:

  * Keeping the TLS stuff contained to its own objects means we can have
 separate development resources on each and not worry as much about
 overlapping domains. (TLS-related knowledge and knowledge of dealing with
 TCP / UDP listeners are separate knowledge domains. Or at least, the former
 is a more specialized subset of the latter.)

  Note that what we're proposing means there's essentially a 1:0-1
 relationship between Listener and this new yet-to-be-named object. (0 in
 case the Listener is not terminating TLS.)

  Stephen

 On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan 
 brandon.lo...@rackspace.com wrote:

 Whoops, [Neutron][LBaaS] got taken out of the subject line here.
 Putting it back in.

 On Mon, 2014-06-23 at 21:10 +, Brandon Logan wrote:
  Okay so we've talked a bit about this in IRC and now I'm sending this
  out as an update.  Here are the options with pros and cons that have
  come from that discussion.
 
  1) default_certificate_id is an attribute of the Listener object.
 
  Pros:
  -No extra entity needed
 
  Cons:
  -May bloat Listener object when more attributes are needed for only TLS
  termination.  Sounds like TLS version and cipher selection will be
  needed attributes in the future.
 
 
  2) A separate TLS Entity is created that is referenced by the Listener
  object.  This entity at first may only contain a certificate_id that
  references barbican.  Name and description can be allowed as well.
 
  Pros:
  -TLS domain specific attributes contained in its own entity
  -Future attributes would just be added to this entity and not bloat the
  Listener object.
 
  Cons:
  -It's another entity
 
  In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
  go.  Anyone agree or disagree?
 
  Thanks,
  Brandon
 
  On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
   The separate entity makes sense for certificates participating in an
   SNI configuration, but probably not so much for the 'default'
   certificate used when TLS is being terminated.
  
  
   Vijay: You're also right that other TLS-related attributes will
   probably get added to the Listener object. This probably makes sense
   if they apply to the Listener object as a whole. (This includes things
   like TLS version and cipher selection.)
  
  
   I don't see much of a point in creating a separate object to contain
   these fields, since it would have a 1:1 relationship with the
   Listener. It's true that for non-TLS-terminated Listeners, these
   fields wouldn't be used, but isn't that already the case in many other
   objects (not just in the Neutron LBaaS sub project)?
  
  
   Thanks,
   Stephen
  
  
  
  
  
  
   On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
   brandon.lo...@rackspace.com wrote:
   Vijay,
   I think the separate entity is still going to happen.  I don't
   think it
   has remvoed.  Or that is may just be my assumption.
  
   Thanks,
   Brandon
  
   On Mon, 2014-06-23 at 15:59 +, Vijay Venkatachalam wrote:
Hi:
   
   
In the “LBaaS TLS termination capability specification”
   proposal
   
https://review.openstack.org/#/c/98640/
   
TLS settings like default certificate container id and SNI
   cert list are part of the listener properties.
   
I think it is better to have this as a separate entity so
   that the listener properties are clean and is not “corrupted”
   with TLS settings.
   
I liked the original SSL proposal better where TLS settings
   was a separate entity.
   
It is just 2 properties now but in future the TLS settings
   would grow and if we are going to introduce a TLS
   profile/params/settings entity later, it is better to do it
   now (albeit with min properties).
   
Thanks,
Vijay V.

Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?