Re: [openstack-dev] [Neutron] Neutron Reference FSM difinition

[Salvatore Orlando]

To add more context to what Nachi quoted, in general the operational status
of a virtual advanced network service depends on the drivers that
implements it.
So far, the drivers being developed for firewall, VPN, and possibly even
Load Balancing all implement the same architecture. In my opinion it would
therefore make sense to adopt the same approach for all of them, but I do
not regard this as a strict requirement.

>From the API users perspective, it is important to provide a consistent
behaviour. This behaviour, if I get the architecture right, is that it
should not be possible to operate on resources in 'PENDING' state, and this
is what should be enforced as a requirement in all these API extensions.
Summarizing the 'state machine' for these resources is not required to be
exactly the same - but it is important that API users have a consistent
experience.

Then it might be argued that ideally there should be no PENDING state - API
requests should always be accepted and executed; but it looks like that
with the current architecture this would have required work for queueing
requests on drivers, which is probably too much for this release.

Salvatore




On 27 July 2013 00:27, Nachi Ueno  wrote:

> Hi folks
>
> I got review comment from Salvatore about FSM management of resources
>
> ### Quote 
>
>  management of PENDING statuses. It would be great if we find an
> agreement across the LB, VPN, and FW extensions to handle them in the
> same way. Doing it differently for each extension might confuse users.
> Note that the approach is similar to FW but there are subtle
> difference, such as in the FW extension one is not allowed to update a
> firewall rule is an update is already in progess
>
> #
>
> Thanks!  Salvatore, I think this is very good topic.
>
> I'm +1 for current FWaaS design.
>
> I wrote FSM matrix here.
>
>
> https://docs.google.com/spreadsheet/ccc?key=0Ap9P99ymj9wLdEt0NTN3cV80cDJqaXdONS1jMWNDQnc#gid=0
>
> It is great if we can agree on this.
> so any comment is appreciated.
>
> Thanks
> Nachi
>
> ___
> 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] [nova] 422 status codes from API

[Christopher Yeoh]

On Thu, 25 Jul 2013 10:29:47 -0400
Sean Dague  wrote:

> Some new tempest tests have been showing up that push deeper into the 
> Nova API, and popping out seem to be a lot of places where we are 
> returning 422 status codes.
> 
> 422 is WebDav reserved code, not in a proper HTTP spec (WebDAV; RFC 
> 4918), and a lot of the other projects have purged it out of their
> APIs.
> 
> It would be good to understand if we consider this a bug that should
> get fixed in v2 / a v2 oversight that gets fixed in v3 / or par for
> the course, as that gives us some guidance on what to land in
> tempest, and what we file bugs on for nova.

Are these getting recorded anywhere currently? AFAIK we've been fixing
all of them in the v3 porting effort, but it'd be nice to know before
the H3 release if we missed anyway .

Chris

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

Re: [openstack-dev] [nova] 422 status codes from API

[George Reese]

FWIW, I consider it a bug :)

On Jul 25, 2013, at 3:29 PM, Sean Dague  wrote:

> Some new tempest tests have been showing up that push deeper into the Nova 
> API, and popping out seem to be a lot of places where we are returning 422 
> status codes.
> 
> 422 is WebDav reserved code, not in a proper HTTP spec (WebDAV; RFC 4918), 
> and a lot of the other projects have purged it out of their APIs.
> 
> It would be good to understand if we consider this a bug that should get 
> fixed in v2 / a v2 oversight that gets fixed in v3 / or par for the course, 
> as that gives us some guidance on what to land in tempest, and what we file 
> bugs on for nova.
> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
George Reese (george.re...@imaginary.com)
t: @GeorgeReese   m: +1(207)956-0217   Skype: 
nspollution






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

Re: [openstack-dev] cells checks on patches

[Sean Dague]

Comments in the review as well. There are a couple of tabs that need
to be cleaned up, then I'm good. What's the long term outlook for
floating-ips, security groups, and aggregates for cells?

On Fri, Jul 26, 2013 at 9:22 PM, Chris Behrens  wrote:
> I have just put up a review here:
>
> https://review.openstack.org/#/c/38897/
>
> which should address the exercise.sh issues when n-cell is enabled.
> Hopefully this works in the gate like it does for me locally.  Then we can
> move on to looking at tempest.
>
> - Chris
>
>
> On Jul 15, 2013, at 6:13 AM, Andrew Laski 
> wrote:
>
> I will also be working to help get cells passing tests.  I just setup a
> blueprint on the Nova side for this,
> https://blueprints.launchpad.net/nova/+spec/cells-gating.
>
> On 07/13/13 at 05:00pm, Chris Behrens wrote:
>
> I can make a commitment to help getting cells passing.  Basically, I'd like
> to do whatever I can to make sure we can have a useful gate on cells.
> Unfortunately I'm going to be mostly offline for the next 10 days or so,
> however. :)
>
> I thought there was a sec group patch up for cells, but I've not fully
> reviewed it.
>
> The generic "cannot communicate with cell 'child'" almost sounds like some
> other basic issue I'll see if I can take a peak during my layovers
> tonight.
>
> On Jul 13, 2013, at 8:28 AM, Sean Dague  wrote:
>
> On 07/13/2013 10:50 AM, Dan Smith wrote:
>
> Currently cells can even get past devstack exercises, which
> are very
> minor sanity checks for the environment (nothing tricky).
>
>
> I thought that the plan was to deprecate the devstack exercises and
> just use tempest. Is that not the case? I'd bet that the devstack
> exercises are just not even on anyone's radar. Since the excellent work
> you QA folks did to harden those tests before grizzly, I expect most
> people take them for granted now :)
>
> Digging into the logs just a bit, I see what looks like early failures
> related to missing security group issues in the cells manager log. I
> know there are some specific requirements in how things have to be set
> up for cells, so I think it's likely that we'll need to do some
> tweaking of configs to get all of this right.
>
> We enabled the test knowing that it wasn't going to pass for a while,
> and it's only been running for less than 24 hours. In the same way that
> the grenade job had (until recently) been failing on everything, the
> point of enabling the cells test now is so that we can start iterating
> on fixes so that we can hopefully have some amount of regular test
> coverage before havana.
>
>
> Like I said, as long as someone is going to work on it, I'm happy. :) I just
> don't want this to be an enable the tests and hope magically fairies come to
> fix them issue. That's what we did on full neutron tests, and it's been
> bouncing around like that for a while.
>
> We are planning on disabling the devstack exercises, it wasn't so much that,
> it's that it looks like there is fundamental lack of functioning nova on
> devstack for cells right now. The security groups stack trace is just a side
> effect of cells falling over in a really low level way (this is what's
> before and after the trace).
>
> 2013-07-13 00:12:18.605 ERROR nova.cells.scheduler
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate
> with cell 'child'
> 
> 2013-07-13 00:12:18.606 ERROR nova.cells.scheduler
> [req-dcbb868c-98a7-4d65-94b3-e1234c50e623 demo demo] Couldn't communicate
> with any cells
>
> Again, mostly I want to know that we've got a blueprint or bug that's high
> priority and someone's working on it. It did take a while to get grenade
> there (we're 2 bugs away from being able to do it repeatably in the gate),
> but during that time we did have people working on it. It just takes a while
> to get to the bottom of these issues some times, so I want people to have a
> realistic expectation on how quickly we'll go from running upstream to
> gating.
>
>   -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> 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
>



-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] Python 3

[Sascha Peilicke]

Am 24. Juli 2013 18:00:30 schrieb Monty Taylor :



On 07/23/2013 03:02 PM, Brian Curtin wrote:
> On Jul 23, 2013, at 3:51 PM, Eric Windisch  >
>  wrote:
> >>
>>
>>
>> On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton > > wrote:
>>
>> I'm sure this has been asked before, but what exactly is the plan
>> for Python 3 support?
>>
>> Is the plan to support 2 and 3 at the same time? I was looking
>> around for a blue print or something but I can't seem to find
>> anything.
>>
>>
>> I suppose a wiki page is due.  This was discussed at the last summit:
>> https://etherpad.openstack.org/havana-python3
>>
>> The plan is to support Python 2.6+ for the 2..x series and Python
>> 3.3+. This effort has begun for libraries (oslo) and clients. Work is
>> appreciated on the primary projects, but will ultimately become
>> stalled if the library work is not first completed.

I'd like to add that at some point in the future it is our desire to
drop support for 2.6, as supporting 2.7 and 3.3+ is way easier than also
supporting 2.6. At the moment, I believe our main factor on that is the
current version of RHEL. Fingers crossed for a new one soon... :)


Not to forget SLES ;-)



We are also just finishing up getting 3.3 enabled build slaves in the CI
gate, so as projects get 3.3 compliant, we should be able to start
testing that.

> FWIW, I came across https://wiki.openstack.org/wiki/Python3Deps and
> updated "routes", which currently works with 3.3. One small step, for free!
> I'm a newcomer to this list, but I'm a CPython core contributor and am
> working in Developer Relations at Rackspace, so supporting Python 3 is
> right up my alley.

Excellent! Welcome, glad to have you.

___
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] Fwd: Problem with nova add-fixed-ip or quantum port-update

[John Gruber]

Forwarding to -dev from -operators.

Any know why when a fixed-ip gets added to an external network guest port,
all connectivity on all fixedips for the guest on the external network get
block outbound on the compute node?

John

-- Forwarded message --
From: John Gruber 
Date: Fri, Jul 26, 2013 at 4:39 PM
Subject: Problem with nova add-fixed-ip or quantum port-update
To: openstack-operat...@lists.openstack.org


I am using Grizzly and I have a mix of both provider external networks
(VLANs) and tenant GRE tunnels.  The provider networks are obviously setup
as public, so VMs can start with interfaces on them.

I can start VMs just fine and get addresses via the dhcp_agent on both
external and tenant networks.

Everything is working well... until I need to add additional fixed_ips to
existing VM vif on external networks.

While I can get commands of the form:

nova add-fixed-ip vm-uuid net-uuid
repeat for each fixed-ip needed

and

quantum port-update port-uuid -- --fixed_ips type=dict list=true
ip_address='10.1.1.6' ip_address='10.1.1.7'


to execute correctly, and can see the fixed_ip addresses either allocate
from the network allocation pool (using nova command) or my explicitly
define addresses (using quantum command) associate with my vm just fine, I
have a problem with security groups.

I've simplified my security groups to just one 'default' where everything
is allowed.  I can start ICMP ping test to my VM and show them working,
until I run the commands to provision addition fixed IPs. Once the command
takes effect on the compute node, all traffic to the vm interface hosting
the network stops.

Interestingly adjacent hosts can see the ARP entries with the correct MAC
address for the added fixed_ips, but I can not make any connections to
them. If I tcpdump on the VM, I see TCP SYN requests and the VM answer with
the SYN+ACK.  On the network outside the VM (trunked to the compute node) I
see the TCP SYN request enter the compute node, and no SYN+ACK emerges. The
problem is somewhere with allowing the VM to send packets to the external
network.

Can anyone tell me how to 'HUP' the security group to allow traffic to my
new list of fixed_ips?

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

Re: [openstack-dev] Problem with nova add-fixed-ip or quantum port-update

[John Gruber]

So I got it work, but I need guidance from the OVS iptables gang on what
the reasoning was and how I fix it in a 'compliant' manner.

Q.  Why are the iptables rules on the OVS output chains for the interfaces
written as if the vif should only have ONE IP address assign where quantum
can assign multiple fixedips?

For the example where IP address 10.0.60.20 was assigned to my guest VM on
an external interface and assign at boot, and then I added 10.0.60.22 via
nova --add-fixed-ip vm-uuid net-uuid...

Here is what I had in my iptables rules after adding the second fixedip:

iptables -L quantum-openvswi-o8a508818-0 --line-numbers
Chain quantum-openvswi-o8a508818-0 (2 references)
num  target prot opt source   destination
1DROP   all  --  anywhere anywhere MAC !
FA:16:3E:41:6B:15
2RETURN udp  --  anywhere anywhere udp
spt:bootpc dpt:bootps
*3DROP   all  -- !10.0.62.20   anywhere
4DROP   all  -- !10.0.62.22   anywhere
*5DROP   udp  --  anywhere anywhere udp
spt:bootps dpt:bootpc
6DROP   all  --  anywhere anywhere state
INVALID
7RETURN all  --  anywhere anywhere state
RELATED,ESTABLISHED
8RETURN all  --  anywhere anywhere
9quantum-openvswi-sg-fallback  all  --  anywhere
anywhere


This obviously will not work.  The rules shadow each other and cut off all
outbound access from the guest VM on that network.  Which is exactly what I
was observing..

Running: iptables -D quantum-openvswi-o8a508818-0 4

And my access to 10.0.62.20 came back...

Running iptables -D quantum-openvswi-o8a508818-0 3

And my access to 10.0.62.22 started working...


Please tell me we did not intend to create a cloud where quantum has no
problems assigning multiple fixed IPs to a port, but iptables will eat them
all up!  Oh the humanity...

I know how to make it work and can hunt down the iptables root wrapper
command, but what should we do for this? I could not find an existing bug..

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

Re: [openstack-dev] Problem with nova add-fixed-ip or quantum port-update

[Eugene Nikanorov]

Hi John,

Can you take a look at https://bugs.launchpad.net/neutron/+bug/1190613 ?
Looks like the exact issue you're talking about and it was fixed just
recently.

Thanks,
Eugene.


On Sat, Jul 27, 2013 at 10:22 PM, John Gruber wrote:

>
> So I got it work, but I need guidance from the OVS iptables gang on what
> the reasoning was and how I fix it in a 'compliant' manner.
>
> Q.  Why are the iptables rules on the OVS output chains for the interfaces
> written as if the vif should only have ONE IP address assign where quantum
> can assign multiple fixedips?
>
> For the example where IP address 10.0.60.20 was assigned to my guest VM on
> an external interface and assign at boot, and then I added 10.0.60.22 via
> nova --add-fixed-ip vm-uuid net-uuid...
>
> Here is what I had in my iptables rules after adding the second fixedip:
>
> iptables -L quantum-openvswi-o8a508818-0 --line-numbers
> Chain quantum-openvswi-o8a508818-0 (2 references)
> num  target prot opt source   destination
> 1DROP   all  --  anywhere anywhere MAC !
> FA:16:3E:41:6B:15
> 2RETURN udp  --  anywhere anywhere udp
> spt:bootpc dpt:bootps
> *3DROP   all  -- !10.0.62.20   anywhere
> 4DROP   all  -- !10.0.62.22   anywhere
> *5DROP   udp  --  anywhere anywhere udp
> spt:bootps dpt:bootpc
> 6DROP   all  --  anywhere anywhere state
> INVALID
> 7RETURN all  --  anywhere anywhere state
> RELATED,ESTABLISHED
> 8RETURN all  --  anywhere anywhere
> 9quantum-openvswi-sg-fallback  all  --  anywhere
> anywhere
>
>
> This obviously will not work.  The rules shadow each other and cut off all
> outbound access from the guest VM on that network.  Which is exactly what I
> was observing..
>
> Running: iptables -D quantum-openvswi-o8a508818-0 4
>
> And my access to 10.0.62.20 came back...
>
> Running iptables -D quantum-openvswi-o8a508818-0 3
>
> And my access to 10.0.62.22 started working...
>
>
> Please tell me we did not intend to create a cloud where quantum has no
> problems assigning multiple fixed IPs to a port, but iptables will eat them
> all up!  Oh the humanity...
>
> I know how to make it work and can hunt down the iptables root wrapper
> command, but what should we do for this? I could not find an existing bug..
>
> John
>
> ___
> 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] Discussing Amazon API compatibility [Nova][Swift]

[Burt Holzman]

On 7/26/2013 10:39 AM, Jay Pipes wrote:
> On 07/26/2013 08:04 AM, Sean Dague wrote:
>> Also there are EC2 design points that have request lengths greater than
>> what Apache (or any other web front end) is compiled to support, as they
>> have the possibility of enourmous GET strings (16K at least). Again,
>> instead of sensibly requiring to move to POST in those cases. I know we
>> had to land a change for CERN to allow bigger requests on EC2 calls for
>> just this reason (we did keep the get length apache sized on OSAPI, so
>> we didn't break people's attempts to get this behind a real web server).

I wrote that patch, so now I feel qualified to jump in this thread. :)

> However, I will say that developers write code to scratch an itch -- or
> some product manager's itch. So the fact that nobody is all that
> interested in spending time to code up enhanced EC2 API support in Nova
> is, well, quite telling that the demand for such things is less than
> what some people think.

I know that my user community has little to no experience with openstack
development, but our still nascent cloud infrastructure is built around
tools that speak EC2. API translation layers like Deltacloud are just
another layer we'd need to deploy, operate, monitor, and so on, and on
the whole I think we'd prefer for the compatibility to be built-in
rather than yet another service.

I disagree about measuring user demand -- it's not a great metric here.
When I tried to throw an issue over the wall to nova development, it got
thrown back and I was asked to sign the CLA and contribute directly*. I
think it's tough to gauge user demand if that's the usual answer to
missing API bits.

- B

* I'm not complaining about this -- it's the model for community-driven
development. (And I can only contribute parasitically, development isn't
my day job.)

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

Re: [openstack-dev] Python overhead for rootwrap

[Monty Taylor]

On 07/26/2013 04:59 PM, Joe Gordon wrote:
> 
> 
> 
> On Fri, Jul 26, 2013 at 11:34 AM, Jay Pipes  > wrote:
> 
> On 07/25/2013 04:21 PM, Joe Gordon wrote:
> 
> Hi All,
> 
> We have recently hit some performance issues with nova-network.  It
> turns out the root cause of this was we do roughly 20
> rootwrapped shell
> commands, many inside of global locks.
> (https://bugs.launchpad.net/__oslo/+bug/1199433
> )
> 
> It turns out starting python itself, has a fairly significant
> overhead
> when compared to the run time of many of the binary commands we
> execute.
> 
> For example:
> 
> $ time python -c "print 'test'"
> test
> 
> real0m0.023s
> user0m0.016s
> sys0m0.004s
> 
> 
> $ time ip a
> <...>
> 
> real0m0.003s
> user0m0.000s
> sys0m0.000s
> 
> 
> While we have removed the extra overhead of using entry points,
> we are
> now hitting the overhead of just shelling out to python.
> 
> 
> Hey Joe,
> 
> Just ask a question of you personally, off list... I was curious
> about the above statement about entry points. Could you elaborate a
> bit there? I thought OpenStack had moved *to* using entry points
> with stevedore?
> 
> 
> Turns out this wasn't off the list.  So I will answer on the list.
> 
> I am not sure about how stevadore fits into this, but the issue is
> related to 'import pkg_resources' and how the binaries are built from
> the 'cmd' files.   It looks like nova doesn't use stevadore for that
> (yet?). It turns out pkg_resources scans your entire python environment
> in part to make it possible to have multiple versions of packages
> installed, but it looks like pip doesn't support that anyway so it just
> slows things down and provides us no benefit. 
> 
> You can see the issue by going into devstack and running "time python -c
> 'import pkg_resouces'"
> 
> This thread may shine more light on what we
> saw: http://mail.python.org/pipermail/distutils-sig/2013-July/021924.html
> 
> Not sure if that helps.
>  
> 
> 
> Did this change recently?

Lemme expand real quick.

We're still declaring console_script entry_points in setup.cfg and the
interface is exactly the same. However, we're now causing the generated
script to do a direct import rather than a pkg_resources look up. In the
context of the console_script, the pkg_resources look up is overhead in
support of multiple parallel installs, but since we're a pip shop, those
are not available to us anyway, so it's all cost for no benefit.

The switch to direct import in the generated script is in pbr trunk
(which means it's what devstack is using now) We should be making a new
pbr real-soon-now.

Monty

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

Re: [openstack-dev] Proposal for API version discovery

[Jamie Lennox]

- Original Message -
> From: "Dolph Mathews" 
> To: "OpenStack Development Mailing List" 
> Sent: Saturday, 27 July, 2013 4:56:10 AM
> Subject: Re: [openstack-dev] Proposal for API version discovery
> 
> 
> On Wed, Jul 24, 2013 at 12:41 AM, Jamie Lennox < jlen...@redhat.com > wrote:
> 
> 
> 
> On Thu, 2013-05-02 at 00:46 +, Gabriel Hurley wrote:
> > Based on input from several of the PTLs (and others), I'd like to propose
> > the following outline for how version discovery should be handled across
> > heterogeneous clouds:
> > 
> > https://etherpad.openstack.org/api-version-discovery-proposal
> > 
> > Further discussion is absolutely welcome, and I would like to propose it as
> > a topic for review by the Technical Committee at the next meeting since it
> > involves a significant cross-project standardization effort.
> > 
> > All the best,
> > 
> > - Gabriel
> 
> So I started on this somewhat independently before i found the blueprint
> and given I have a semi working implementation i've got a few questions
> or essentially an area i find inconsistent.
> 
> AFAIK there are no other serious attempts at this so i've got nothing to
> go off. Also for the time being I don't care about HATEOS, or future
> discovery protocols, just getting something that works for keystone now.
> 
> I think the way version is treated in the current blueprint is off.
> Looking at 'Auth with a Specified Version' point 2 says that we should
> not infer the version from the URL and point 3 says that if i provide a
> version number with a non-versioned endpoint to retrieve possible
> versions and instantiate a client if an endpoint is available for that
> version.
> 
> I don't think that we should be checking the url for what is and what
> isn't a versioned endpoint for the same reasons we shouldn't be
> retrieving the version from the URL.
> 
> What i would like to do is treat the version parameter as the requested
> version, rather than using it to prevent a lookup for versions. What
> this means is that i can say:
> client.Client(auth_url=" http://example.com:5000/ ", user=foo,
> version=2.0, ...)
> and retrieve a version 2 client from a provider that may provide both
> versions v2 & v3. This will still require a lookup of the auth_url even
> though version is specified.
> 
> I believe this is exactly what the document is trying to convey (I don't
> think it's advocating skipping the multiple choice response).
> 

Ok, I'll put it down to a mis-reading. There are a couple of additions there 
that i
took to mean that if a Version was specified then we should directly be 
creating a
client of that version without checking with the server. 

Thanks for clarifying for me. 

> 
> 
> Keystone (not sure on others) provides version information at GET /v2.0
> (and other versions) as well as GET / so if i say:
> client.Client(endpoint=" http://example.com:5000/v2.0 ",
> version=2.0, token=foo)
> It should be validated that the endpoint is capable of using the V2 api
> and doing:
> client.Client(endpoint=" http://example.com:5000/v2.0 ",
> version=3.0, token=foo)
> should fail immediately.
> 
> +1 to both
> 
> 
> 
> To summarize: every call to client.Client should result in a query to
> check available versions. The version parameter is an indicator of what
> version client should be retrieved from those specified as available and
> it should fail if it can't deliver. If you _really_ want to use a
> particular client without a lookup you should use the original
> keystoneclient.v2_0.Client which is what is returned from a successful
> client.Client (with version=2) call anyway and takes the same
> parameters.
> 
> I've posted the work for review: https://review.openstack.org/#/c/38414/
> and would appreciate comments/clarification.
> 
> 
> Thanks,
> 
> Jamie
> 
> 
> 
> 
> > ___
> > 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
> 
> 
> 
> --
> 
> -Dolph
> 
> ___
> 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] Python overhead for rootwrap

[Thomas Goirand]

On 07/26/2013 05:43 AM, Thierry Carrez wrote:
> I would rather support solution 3: create a single, separate  executable
> that does those 20 things that need to be done (can be a shell script
> with some logic in it), and have rootwrap call that *once*. That way you
> increase speed by 20 times without dumping the security model.

Hi Thierry,

Does rootwrap has to be written in Python? How much work would it be to
rewrite it in C? It doesn't seem that big to me (less than 700 lines of
python right now). Or is it too complicated, and then too dangerous, to
be in such no-safety-net type of language?

Thomas


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