Re: [openstack-dev] [Neutron] Neutron Reference FSM difinition
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 na...@ntti3.com 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
On Thu, 25 Jul 2013 10:29:47 -0400 Sean Dague s...@dague.net 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] cells checks on patches
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 cbehr...@codestud.com 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 andrew.la...@rackspace.com 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 s...@dague.net 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
Am 24. Juli 2013 18:00:30 schrieb Monty Taylor mord...@inaugust.com: On 07/23/2013 03:02 PM, Brian Curtin wrote: On Jul 23, 2013, at 3:51 PM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton lo...@bacoosta.com mailto:lo...@bacoosta.com 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
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 john.t.gru...@gmail.com 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] Discussing Amazon API compatibility [Nova][Swift]
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] Proposal for API version discovery
- Original Message - From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org 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
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
