Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On Mon, Aug 5, 2013 at 11:03 AM, Mac Innes, Kiall ki...@hp.com wrote: While the topic of WSME is open - Has anyone actually tried using it? snip I would be very cautious about assuming WSME can support anything we need when the absolute fundamentals of building a REST API are totally MIA. There was a whole thread about this a couple of months ago [1]. tl;dr Ceilometer is already using it. I have a rough patch for what would be v3 of Cinder using Pecan/WSME for J if we decide we need a bump [2]. Neutron will likely be using it when it switches to Pecan. For Cinder, WSME raises a 400 on type checking in the body as I need it to. Everything else I have raised in the controller as needed. Thanks, Mike Perez [1] - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html [2] - http://lists.openstack.org/pipermail/openstack-dev/2013-June/010857.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
Hi, What about saying that you are not restricted to use H302 in test code test_*.py ? On Mon, Aug 05, 2013 at 08:03:26PM -0700, Clint Byrum wrote: Excerpts from Robert Collins's message of 2013-08-05 19:26:20 -0700: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are designed to be used as a dsl: self.assertThat(foo, Or(Equals(1), Equals(2))) rather than what H302 enforces: self.assertThat(foo, matchers.Or(matchers.Equals(1), matchers.Equals(2))) Further, conflicting module names become harder to manage, when one could import just the thing. Some arguments for requiring imports of modules: - makes the source of symbols obvious - Actually, it has no impact on that as the import is still present and clear in the file. import * would obfuscate things, but I'm not arguing for that. - and package/module names can (and are!) still ambiguous. Like 'test.' - whats that? - consult the imports. - makes mocking more reliable - This is arguably the case, but it's a mirage: it isn't a complete solution because modules still need to be mocked at every place they are dereferenced : only import modules helps to the extent that one never mocks modules. Either way this failure mode of mocking is usually very obvious IME : but keeping the rule as a recommendation, *particularly* when crossing layers to static resources is a good idea. - It's in the Google Python style guide (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports) - shrug :) What I'd like us to do is weaken it from a MUST to a MAY, unless noone cares about it at all, in which case lets just turn it off entirely. You've convinced me. Monty's point about the complexity of making sure what is imported in code is actually a module makes it expensive without much benefit. I say remove it entirely. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] async worker design meeting tomorrow!
On 08/05/2013 04:34 AM, Brian Rosmaita wrote: Well, it's tomorrow as I write this, maybe it's today as you read this. Anyway: - asynchronous worker meeting Tuesday 6 Aug 2013 14:00 UTC in #openstack-glance - the etherpad https://etherpad.openstack.org/havana-glance-requirements was updated after the last meeting - if you missed the last meeting, the log is at https://etherpad.openstack.org/havana-glance-requirements-meeting-02-aug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev All, I am very interested in this work but I cannot make the meeting because it is at 4am my time and I am still sitting at my laptop as I stare down the barrel of midnight. I first want to thank Brain et al for the great work. The wiki pages they have are well thought out and defined. I am very interested in seeing that this work is successfully completed because I feel it is a key part in making Glance a significantly more useful service. When discussing this with the community in the past I have fallen into the trap of getting lost in implementation details and thereby confused the focus of the efforts first steps. I am slightly concerned that this meeting could take a turn into too much concern for details that are better covered later (for example: how a task is implemented, what does the plug in interface look like, will these tasks be scheduled via messaging, etc). Thus I thought I would send out what deliverables I now hope will come from this meeting. Here they are: A near complete user facing REST API -- Brian has this well described in the previously linked wiki pages, all that is needed is a y or n. I vote y. An agreed upon (initial/direction setting) set of use cases that this API can handle. As an example: 1) validate an incoming image as bootable 2) check an incoming image for a license 3) convert an image from one format to another (ex: raw-qcow2) 4) extract size information (image size vs storage size) 5) information injection/scrubbing from the image 6) perform an operator defined processor time intensive operation upon an image before allow it to be a) registered as a valid image location, b) downloaded. A set of requirements for that REST API -- ex: 1) The lifespan of the client connection can be shorter than that of the workload. 2) An image can be deleted without deleting the task associated with it (just an example!) 3) multiple tasks can be performed on a single image safely at the same time 4) A single task request is guaranteed to only happen once. Two threads of execution will never iterate over the same byte, neither at the same time nor in serial (again, an example and one that admittedly may be beyond the scope of the API discussion). -- on this point I am concerned with cases where a task fails and is restarted. Do we guarantee that all tasks failed as well and thus can safely be restarted? Thanks! John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation
Hi Dina and All, Please see comments inline. We can drill down on the specifics off-line if that's more practical. Thanks in advance, Patrick On 8/5/13 3:19 PM, Dina Belova wrote: Hello, everyone! Patrick, Julien, thank you so much for your comments. As for the moments Patrick mentioned in his letter, I'll describe our vision for them below. 1) Patrick, thank you for the idea! I think it would be great to add not only 'post-lease actions policy', but also 'start-lease actions policy'. I mean like having two types of what can be done with resource (virtual one) on lease starting - 'start VM automatically' or 'start VM manually'. This means user may not use reserved resources at all, if he needs such a behaviour. Something along those lines would work but I think the 'start VM manually' keeps over specifying the behavior IMO since you still make the assumption that reserved resources are always started using a term 'manually' that is misleading because if not automatically started by the reservation service they can still be automatically started elsewhere like in Heat. I general I agree that users can take advantage of being able to specify pre and post lease actions / conditions although it shouldn't be prescriptive of something binary like start automatically or manually. Another beneficial usage could be to send parametrized notifications. I would also make the pre and post action optional so that if the user choose not to associate an action with the realization of a lease, he doesn't have to specify anything. Finally, I would also that the specification of a pre and post action is assorted of a time offset to take into account the lead time to provision certain types of resources like physical hosts. That's a possible solution to point 4. 2) We really believe that creating lease first, and going with its id to all the OpenStack projects to use is a better idea than 'filling' the lease with resources just at the moment of its creation. I'll try to explain why. First of all, as for virtual reservations, we'll need to proxy Nova, Cinder, etc. APIs through Reservation API to reserve VM or volume or something else. Workflow for VM/volume/etc. creation is really complicated and only services written to do this have to do it, in our opinion. Second, this makes adding new reservations to the created lease simple and user friendly. And the last moment, we should not copy all these dashboard pages for instance/volume/... creation to the reservation Dashboard tab in this case. As for the physical reservations, as you mentioned, there is no way to 'create' them like virtual resources in the Nova's, for example, API now. That's why there are two ways to solve this problem and reserve them. First way is to reserve them from Reservation Service as it is implemented now and described also in our document (WF-2b part of it). The second variant (that seems to be more elegant, but more complicated as well) is to implement needed parts as Nova API extension to let Nova do the things it does the best way - managing hosts, VMs, etc. Our concern in this question is not doing things Nova (or any other service) can do much better. Well, I am under the impression that you put forward an argumentation that is mostly based on an implementation artifact which takes advantage of the actual resource provisioning workflow and dashboard rather than taking into account the most common use cases and practices. There maybe use cases that mandate for an iterative workflow that is similar to what you describe. I may be wrong, but I am doubtful it is going to be a common use case. We tend to think of AWS as being a reference and you've probably noticed that reservations in AWS are performed by chunk (the more I reserve for the longer period of time, the cheaper). The problem with adding reservations into a lease on a continuous basis is that as a user I may end up undo what I have done (e.g. I got only 900 out of the 1000 VMs I want) and keep trying forever. That's potentially a lot of overhead. Also, as a cloud operator, I'd like to know what my reservation pipeline looks like ahead of time so that I can provision new hardware in due time. That's capacity planning. As an operator, I also want to be able grant reservations and charge for it even if I don't have the capacity right now provided the lead time to provisioning new hardware doesn't conflict with the terms of the pending leases. If a user can add reservations to a lease at the last moment, that flexibility may be compromised. In any events, this is how we envision the behavior of the reservation service for the reservation of physical capacity and so, it is important the service API can support that interaction model. I think it's probably okay to do it in two separate steps 1) create the lease, 2) add reservation (although it seems problematic in the case of immediate lease) but the actual
[openstack-dev] [Ceilometer] Another introduction
Hey everyone, I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of the EU research project Contrail, dealing with cloud federation, and I got hired to work on Contrail-Openstack integration. Firstly I'm trying to integrate alarming and since alarming in Ceilometer is still a work in progress, I'm free to work on Ceilometer :) I've already familiarized myself with the code a bit, any suggestions what I could help with? Perhaps something with the alarm or alarm audit API? Cheers! Nejc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
On 08/05/2013 10:38 PM, Monty Taylor wrote: On 08/05/2013 11:26 PM, Robert Collins wrote: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are designed to be used as a dsl: self.assertThat(foo, Or(Equals(1), Equals(2))) rather than what H302 enforces: self.assertThat(foo, matchers.Or(matchers.Equals(1), matchers.Equals(2))) Further, conflicting module names become harder to manage, when one could import just the thing. Some arguments for requiring imports of modules: - makes the source of symbols obvious - Actually, it has no impact on that as the import is still present and clear in the file. import * would obfuscate things, but I'm not arguing for that. - and package/module names can (and are!) still ambiguous. Like 'test.' - whats that? - consult the imports. - makes mocking more reliable - This is arguably the case, but it's a mirage: it isn't a complete solution because modules still need to be mocked at every place they are dereferenced : only import modules helps to the extent that one never mocks modules. Either way this failure mode of mocking is usually very obvious IME : but keeping the rule as a recommendation, *particularly* when crossing layers to static resources is a good idea. - It's in the Google Python style guide (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports) - shrug :) What I'd like us to do is weaken it from a MUST to a MAY, unless noone cares about it at all, in which case lets just turn it off entirely. Enforcing it is hard. The code that does it has to import and then make guesses on failures. Also - I agree with Robert on this. I _like_ writing my code to not import bazillions of things... but I think the hard and fast rule makes things crappy at times. The reason we go hard and fast on certain rules is to reduce review time by people. If something is up for debate we get bikeshedding in reviews where one reviewer tells someone to do it one way, 2 days later they update their review, another reviewer comes in and tells them to do it the otherway. (This is not theoretical, it happens quite often, if you do a lot of reviews you see it all the time.) It also ends up being something reviewers can stop caring about, because the machine will pick it up. Giving them the ability to focus on higher order issues, and still keeping the code from natural entropy. MUST == computer can do it, less work for core review time (which is realistically one of our most constrained resources in OpenStack) MAY == humans have to make a judgement call, which means more work for our already constrained review teams I've found H302 to really be useful on reviewing large chunks of code I've not been in much before. And get seriously annoyed being in projects that don't have it enforced yet (tempest is guilty of that). Being able to quickly know what namespace things are out of saves time. Honestly, after spending the year with the constraint in OpenStack, I'm never going to import modules directly in my personal projects, as I think the benefits of the explicitness have shown themselves pretty well. So I'm a soft -1 on dropping it from hacking. -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
Re: [openstack-dev] [nova][glance] Future of nova's image API
Joe Gordon wrote: On Mon, Aug 5, 2013 at 9:11 AM, Roman Bogorodskiy rbogorods...@mirantis.com wrote: Joe Gordon wrote: Hi All, even though Glance, has been pulled out of Nova years ago, Nova still has a images API that proxies back to Glance. Since Nova is in the process of creating a new, V3, API, we know have a chance to re-evaluate this API. * Do we still need this in Nova, is there any reason to not just use Glance directly? I have vague concerns about making Glance API publicly accessible, but I am not sure what the underlying reason is From the end user point of view, images are strongly tied to logical models nova operates with, such as servers, flavors etc. So for an API user, it would be move convenient to manage all these in a single API, IMHO. -1, I think Monty stated this well Honestly, I think we should ditch it. Glance is our image service, not nova, we should use it. For user-experience stuff, python-openstackclient should be an excellent way to expose both through a single tool without needing to proxy one service through another. Well, end user doesn't have to know such internals of the cloud such as if it's using separate image service or not. But... We don't want nova to be the proxy for all other services, that partially defeats the purpose of splitting them off. We have better ways of making everything look like a single API, such as: * better python-openstackclient * Make sure all services can run as one endpoint, on the same port. So a REST call to $IP/images/ would go to glance and a call to $IP/instances would go to nova ... this thing sounds reasonable. Also, there could be many reasons not to use python-openstackclient, so making API more complex and simplifying things for users through openstackclient will not work for everybody. * If it is still needed in Nova today, can we remove it in the future and if so what is the timeline? best, Joe Gordon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Roman Bogorodskiy ___ 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 Roman Bogorodskiy pgp794awItr0S.pgp 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] [Neutron] Network Information Sharing with OpenFlow Controller
Hi Kyle, Thanks for information. We want to follow different approach like non-intrusive approach. We will share more details on this later. Regards, Balaji.P -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Monday, August 05, 2013 7:34 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Network Information Sharing with OpenFlow Controller On Aug 4, 2013, at 1:20 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, Anyone in the community is working on the OpenStack Controller and OpenFlow Controller Integration for Network and VM Information sharing. High level approach on this is attached to this mail as PPT. Idea is to share the Network and VM information to OpenFlow Controller for DC Network OpenFlow Switches. Based on this Network/VM information OpenFlow Controller can add flows to these OF-Switches based on the shared Network/Port Information. This use case is for Data Centre Networks where OpenStack Controller deployed for SDN Network. Any comments or thoughts on this are appreciated. Hi Balaji.P: There is already integration with Ryu [1] which has been upstream as a Quantum/Neutron plugin since Folsom. And we are currently working on integration with OpenDaylight [2] as well. Both of those are capable of being OpenFlow controllers. Can you explain how your design is different or could build upon either of those? Thanks, Kyle [1] https://github.com/osrg/ryu/wiki/OpenStack [2] http://www.opendaylight.org/ Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Friday, August 02, 2013 4:41 PM To: OpenStack Development Mailing List Cc: Addepalli Srini-B22160; B Veera-B37207; Mannidi Purandhar Sairam-B39209; Lingala Srikanth Kumar-B37208; Somanchi Trinath-B39208; Vetcha Sarat Babu-B37147 Subject: [openstack-dev] [Neutron] OpenStack Controller and OpenFlow Controller Network Information Sharing Hi, Please find that attachment to this mail as high level architecture of OpenStack and OpenFlow Controller Integration for Network/VM/Network Services Information sharing, We are planning to publish blue-print for this. Let us know your comments and suggestions. Regards, Balaji.P OSC-OFC-Integration.pptx___ 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] Adding extra_specs to flavor show and detail call
Hi, We are working on a blueprinthttps://blueprints.launchpad.net/nova/+spec/add-extra-specs-to-flavor-list, which adds extra specs to the flavor show and detail calls. As a part of this, we have added a new extension called FlavorWithExtraSpecs. When this extension is enabled, the extra_specs of the flavor will be included as part of the response. Since this extension will add extra fields (extra_specs of the flavor) to the response, the clients consuming this API will have to support the same. Ideally none of the clients should fail, but we found the tempest tests on gerrit fail because the response has a new key which is not handled by the existing flavor format method. We have made the required code fixes to tempest and it is in reviewhttps://review.openstack.org/#/c/40384/ . With this extension loaded, we will now see an extra field in the response. Do you have any concerns with the approach we have taken? Thanks, Aditi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] container-sync problems in global data sync senario
Hi, Iām interested in container-sync to take a snapshot of swift. I want to sync data between two swift clusters distributed in multiple locations. It is assumed that there are two swift clusters located in two places, and the container-sync syncs data from one cluster to the other cluster through WAN. I tried container-sync with Folsom in this case, and faced one problem with this scenario. Container-sync always sends multiple PUT request with whole object transfer, which puts pressure on network bandwidth between swift clusters. I checked Grizzly and latest 1.9.0, but I cannot find any progress with the issues. Does anyone experiences similar issues or tackled to improve performance? IMHO, it may be fixed with a little changes to the container-sync. If it can be, I'd like to try it. :-) Does anybody have any idea or suggestions? Thanks in advance. Takashi Kajinami ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Nomination for Mehdi Abaakouk
Darn, thought I'd replied to this already! Anyways, a belated +1 and a hearty welcome to Mehdi :) Cheers, Eoghan - Original Message - Hi, I'd like to propose to add Mehdi Abaakouk (sileht) to ceilometer-core. He has been a valuable contributor for the last months, doing a lot of work in the alarming blueprints, and useful code reviews. -- Julien Danjou -- Free Software hacker - freelance consultant -- 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] [Ceilometer] Another introduction
On 08/06/2013 08:31 AM, Nejc Saje wrote: Hey everyone, I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of the EU research project Contrail, dealing with cloud federation, and I got hired to work on Contrail-Openstack integration. Firstly I'm trying to integrate alarming and since alarming in Ceilometer is still a work in progress, I'm free to work on Ceilometer :) I've already familiarized myself with the code a bit, any suggestions what I could help with? Perhaps something with the alarm or alarm audit API? Cool, welcome! I'm sure Angus, Eoghan or Mehdi will have some great suggestions for you but testing, finding and squashing bugs are always a great place to start. Cheers -S Cheers! Nejc ___ 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] [Swift] gate on functional tests
They were non-voting. The change is that they are now voting. --John On Aug 5, 2013, at 9:17 PM, Chmouel Boudjnah chmo...@enovance.com wrote: On Mon, Aug 5, 2013 at 10:59 PM, John Dickinson m...@not.mn wrote: The Swift functional tests have been running as an advisory for a bit now on all Swift patches. Everything appears to be plumbed together correctly, and the tests have been added as gating tests for every merge into master. would it be too soon to make those gates as voting gates [1]? I haven't seen false positive with those yet (except we really should fix https://bugs.launchpad.net/python-swiftclient/+bug/1201376 so we don't get all those keystoneclient cnx messages filling up the logs) Chmouel. [1] I think they are running as non-voting for now. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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] devstack modifying git repository
Hey Chmouel! Good point. I think we could add a check to see if there are any changes in the repo and skip the update if there are not. Or, we could protect that action in a variable and have devstack-gate set that variable... what do you guys think? On 08/06/2013 12:56 AM, Chmouel Boudjnah wrote: Hello, I just saw that https://github.com/openstack-dev/devstack/commit/6c84463071e1ff23e20e4ef4fb863aba0732bebc as just landed. I understand the good reasons for that and thanks for the works that has been done into it but this has come to some weird side effects of having devstack modifying your source tree when running it. My workflow when working on a feature/bug and I suspect I am not the only one is usually, run devstack, hack the source, unittests, unstack.sh/stack.sh run the devstack again etc. When I commit those I would be commited that updated requirements, is it the side effect we want to force, should the commiter commit those or remove them before git-review it ? This seems to me some extra works for commiters/reviewers. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API. I'm not certain that the extensions should really be in the v2 or v3. It always seemed to me that Extensions should be parallel to, and separate from, the core API. Is this intentional? I was starting to make a review to add it to identity-api but is there the intention that extensions should show up within the endpoint APIs? There is no reason it couldn't work that way and DELETE would just fail. I am not convinced that it is a good idea though and I just want to check if this is something that has been discussed or purposefully handled this way or something we need to add. 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
Re: [openstack-dev] devstack modifying git repository
Hey Monty, On Tue, Aug 6, 2013 at 3:18 PM, Monty Taylor mord...@inaugust.com wrote: Good point. I think we could add a check to see if there are any changes in the repo and skip the update if there are not. Or, we could protect that action in a variable and have devstack-gate set that variable... what do you guys think? I think most of the times, trying to modifiy automaticaly a user/dev source code is recipes for problems. Why don't we fo that it only when devstack is run in `gating mode` ? Chmouel. PS: Apologies if this has been discussed earlier as I didn't follow the full threads about this. On 08/06/2013 12:56 AM, Chmouel Boudjnah wrote: Hello, I just saw that https://github.com/openstack-dev/devstack/commit/6c84463071e1ff23e20e4ef4fb863aba0732bebc as just landed. I understand the good reasons for that and thanks for the works that has been done into it but this has come to some weird side effects of having devstack modifying your source tree when running it. My workflow when working on a feature/bug and I suspect I am not the only one is usually, run devstack, hack the source, unittests, unstack.sh/stack.sh run the devstack again etc. When I commit those I would be commited that updated requirements, is it the side effect we want to force, should the commiter commit those or remove them before git-review it ? This seems to me some extra works for commiters/reviewers. Chmouel ___ 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] [Ceilometer] Another introduction
On 8/6/13 7:52 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 08/06/2013 08:31 AM, Nejc Saje wrote: Hey everyone, I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of the EU research project Contrail, dealing with cloud federation, and I got hired to work on Contrail-Openstack integration. Firstly I'm trying to integrate alarming and since alarming in Ceilometer is still a work in progress, I'm free to work on Ceilometer :) I've already familiarized myself with the code a bit, any suggestions what I could help with? Perhaps something with the alarm or alarm audit API? Cool, welcome! I'm sure Angus, Eoghan or Mehdi will have some great suggestions for you but testing, finding and squashing bugs are always a great place to start. Cheers -S Welcome! I just started a few days ago myself. Good luck! :) -Thomas Cheers! Nejc ___ 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] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On Tue, Aug 6, 2013 at 5:35 AM, Mac Innes, Kiall ki...@hp.com wrote: So, From experimenting with, and looking at the WSME code - raising a status with `pecan.abort(404)` etc doesn't actually work. WSME sees that, and helpfully swaps it out for a HTTP 500 ;) The author of WSME even says there is currently no way to return a 404. So, ceilometer must be either not using anything but http 400 and http 500, or have replaced WSMEs error handling :/ I'll have to have a look a ceilometers API to see if they ran into/fixed the issue. WSME + pecan is being used in Tuskar: https://github.com/tuskar/tuskar (OpenStack management API) We encountered the same issue discussed here. A solution we settled on for now was to use a custom Renderer class that could handle different response codes. You set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. Here's the commit with all the details: https://github.com/tuskar/tuskar/commit/16d3fec0e7d28be04252ad6b779ca6460b4918f5 -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
as a general principle I would think it is a good idea for clients to be able to interrogate Keystone to determine what extensions it supports. Most protocols have some mechanism for determining what extensions/versions are supported by the server, and what optional features are implemented. regards David On 06/08/2013 06:19, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API. Is this intentional? I was starting to make a review to add it to identity-api but is there the intention that extensions should show up within the endpoint APIs? There is no reason it couldn't work that way and DELETE would just fail. I am not convinced that it is a good idea though and I just want to check if this is something that has been discussed or purposefully handled this way or something we need to add. 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
Re: [openstack-dev] instances fail to boot on el6 (glance schema error issue)
Okay. The quick fix is to remove the extra Glance V2 call when CONF.allowed_direct_url_schemes is disabled. https://review.openstack.org/#/c/40426/1 This effectively avoids calling the Glance V2 API on python 2.6 (thus avoiding the schema validation issue). The real issue here is still unresolved however and it looks like we still have some work to do to get all the fancy new Glance V2 stuff fully working on python 2.6 distros (RHEL/Centos, etc). Dan - Original Message - From: Dan Prince dpri...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Sent: Monday, August 5, 2013 9:01:40 PM Subject: [openstack-dev] instances fail to boot on el6 (glance schema error issue) As of an hour ago the el6 (Centos) builds in SmokeStack all started failing. I've documented the initial issue I'm seeing in this ticket: https://bugs.launchpad.net/nova/+bug/1208656 The issue seems to be that we now hit a SchemaError which bubbles up from glanceclient when the new direct download plugin code runs. This only seems to happen on distributions using python 2.6 as I'm not seeing the same thing on Fedora. This stack trace also highlights the fact that the Glance v2 API now seems to be a requirement for Nova... and I'm not sure this is a good thing considering we still use the v1 API for many things as well. Ideally we'd have all Nova - Glance communication use a single version of the Glance API (either v1 or v2... not both) right? Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On Aug 6, 2013, at 8:36 AM, Adam Young wrote: On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API. I'm not certain that the extensions should really be in the v2 or v3. It always seemed to me that Extensions should be parallel to, and separate from, the core API. I agree. Extensions should not be in core, but the mechanism by which extensions are discovered should be part of the core...right? -jOrGe W. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation meetings has their own agenda to follow: their preferences, likes, dislikes, must have features, etc. This is why standards end up with optional extensions. If you dont have them, then you cannot get buy in from sufficient stakeholders. If you do have them, then you end up with extensibility. But actually extensibility in my opinion is a must have feature, since no protocol or standard (or Keystone) remains static for ever, and new features are continually being added to it. Therefore you must have a way for clients to know what functionality the remote server currently supports so that it can talk the correct protocol flavour to it. regards David Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams jorge.willi...@rackspace.com wrote: On Aug 6, 2013, at 8:36 AM, Adam Young wrote: On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensionsand then realized that GET /extensions is only a V2 API. I'm not certain that the extensions should really be in the v2 or v3. It always seemed to me that Extensions should be parallel to, and separate from, the core API. I agree. Extensions should not be in core, but the mechanism by which extensions are discovered should be part of the core...right? Agree. The fact that you call GET /v2.0/extensions or GET /v3/extensions instead of GET /extensions just means that we can iterate on the extensions response itself, not necessarily that the extension *only* applies to particular version API being queried (that's a different issue). -jOrGe W. ___ 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
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 08/06/2013 10:54 AM, Dolph Mathews wrote: On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams jorge.willi...@rackspace.com mailto:jorge.willi...@rackspace.com wrote: On Aug 6, 2013, at 8:36 AM, Adam Young wrote: On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API. I'm not certain that the extensions should really be in the v2 or v3. It always seemed to me that Extensions should be parallel to, and separate from, the core API. I agree. Extensions should not be in core, but the mechanism by which extensions are discovered should be part of the core...right? Agree. The fact that you call GET /v2.0/extensions or GET /v3/extensions instead of GET /extensions just means that we can iterate on the extensions response itself, not necessarily that the extension *only* applies to particular version API being queried (that's a different issue). Agreed. That makes sense. So the APIs should be: v2.0/extensions or v3/extensions but those should return links to: extensions/some_extension -jOrGe W. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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
[openstack-dev] Hyper-V meeting canceled
Hi All, I need to cancel the hyper-v meeting today. We will return to the normal meeting schedule next week. Best, pp Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research Development Center One Memorial Drive,Cambridge, MA 02142 ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] async worker design meeting tomorrow!
John, Thanks for your input, we discussed your points at the meeting. The results are here: https://etherpad.openstack.org/glance-async-worker-mtg-agenda There's one point we postponed to discuss until Thursday's regular glance meeting, you can explain it more then. Also, the complete meeting log is here: https://etherpad.openstack.org/havana-glance-requirements-meeting-06-aug cheers, brian From: John Bresnahan [jbres...@redhat.com] Sent: Tuesday, August 06, 2013 6:04 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance] async worker design meeting tomorrow! On 08/05/2013 04:34 AM, Brian Rosmaita wrote: Well, it's tomorrow as I write this, maybe it's today as you read this. Anyway: - asynchronous worker meeting Tuesday 6 Aug 2013 14:00 UTC in #openstack-glance - the etherpad https://etherpad.openstack.org/havana-glance-requirements was updated after the last meeting - if you missed the last meeting, the log is at https://etherpad.openstack.org/havana-glance-requirements-meeting-02-aug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev All, I am very interested in this work but I cannot make the meeting because it is at 4am my time and I am still sitting at my laptop as I stare down the barrel of midnight. I first want to thank Brain et al for the great work. The wiki pages they have are well thought out and defined. I am very interested in seeing that this work is successfully completed because I feel it is a key part in making Glance a significantly more useful service. When discussing this with the community in the past I have fallen into the trap of getting lost in implementation details and thereby confused the focus of the efforts first steps. I am slightly concerned that this meeting could take a turn into too much concern for details that are better covered later (for example: how a task is implemented, what does the plug in interface look like, will these tasks be scheduled via messaging, etc). Thus I thought I would send out what deliverables I now hope will come from this meeting. Here they are: A near complete user facing REST API -- Brian has this well described in the previously linked wiki pages, all that is needed is a y or n. I vote y. An agreed upon (initial/direction setting) set of use cases that this API can handle. As an example: 1) validate an incoming image as bootable 2) check an incoming image for a license 3) convert an image from one format to another (ex: raw-qcow2) 4) extract size information (image size vs storage size) 5) information injection/scrubbing from the image 6) perform an operator defined processor time intensive operation upon an image before allow it to be a) registered as a valid image location, b) downloaded. A set of requirements for that REST API -- ex: 1) The lifespan of the client connection can be shorter than that of the workload. 2) An image can be deleted without deleting the task associated with it (just an example!) 3) multiple tasks can be performed on a single image safely at the same time 4) A single task request is guaranteed to only happen once. Two threads of execution will never iterate over the same byte, neither at the same time nor in serial (again, an example and one that admittedly may be beyond the scope of the API discussion). -- on this point I am concerned with cases where a task fails and is restarted. Do we guarantee that all tasks failed as well and thus can safely be restarted? Thanks! 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] [Keystone] V3 Extensions Discoverability
On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation meetings has their own agenda to follow: their preferences, likes, dislikes, must have features, etc. This is why standards end up with optional extensions. Which standards are you referring to? *Good* standards, like the HTTP or ANSI SQL standards, just have a set of interfaces that correspond to a version. It's only when vendors go outside of the standard to define what they want when things get fuzzy. Case in point: the HTTP extension framework: http://tools.ietf.org/html/rfc2774.html Last updated in the year 2000. Nobody uses or cares about it. Why? Because it isn't a standard, and provides the ability for every Tom, Dick, and Rackspace to reinvent their own HTTP interfaces. It doesn't make sense. Then, or now. The point of standards and standards committees is to come to a compromise and develop a single standard. API Extensions are merely punting on that responsibility in the name of customization. If you dont have them, then you cannot get buy in from sufficient stakeholders. If you do have them, then you end up with extensibility. But actually extensibility in my opinion is a must have feature, since no protocol or standard (or Keystone) remains static for ever, and new features are continually being added to it. Therefore you must have a way for clients to know what functionality the remote server currently supports so that it can talk the correct protocol flavour to it. Extensibility is only a must have for *implementations*, IMHO, not for the *API*. API extensions are just a way around the hard work of creating a good, standardized, well-documented API. Case in point: The Nova API extensions. How many of them are: a) not documented at all, including the code itself, b) not documented in some online document somewhere, and c) directly contradict the functionality in other extensions? Extensibility, at least in my view, belongs on the implementation/driver layer. Keystone has done a good job keeping extensibility at its driver layer so far. It's a shame it doesn't keep it there. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Looking for some help understanding default meters
On 8/5/13 4:02 PM, Monsyne Dragon mdra...@rackspace.com wrote: On 8/5/13 8:40 AM, Julien Danjou jul...@danjou.info wrote: On Mon, Aug 05 2013, Thomas Maddox wrote: Thinking about it, the latter option seems to describe a very real concern going forward that didn't occur to me when I was wandering around the code. Specifically regarding option 2a, if message 2 arrives at CM before message 1 because it ended up on a faster route, then message 1 will overwrite the metadata from message 2 and we record an incorrect state. Isn't the nature of network comms for messages at the application layer to potentially be out of order and in the case of UDP, even lost? What is the leftover purpose of resource-show when we can't trust its output to represent the actual state of whatever resource is in question? It seems that timestamps could be used to prevent overwriting of the latest state by checking that the incoming notification doesn't have a timestamp less than the already recorded one. I hope I'm not seeing a problem that doesn't exist here or misunderstanding something. If so, please correct me! No you're absolutely right. Checking the timestamp before we override resource metadata would be a great idea. Would you mind reporting a bug first, so we can schedule to fix it? It's probably good to keep in mind that AMQP does not guarantee order of delivery. At any point in the future, if we need to rely on ordering, we will need to check timestamps too. Definitely. Thanks for the help, Dragon! -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On Tue, Aug 6, 2013 at 10:53 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation meetings has their own agenda to follow: their preferences, likes, dislikes, must have features, etc. This is why standards end up with optional extensions. Which standards are you referring to? *Good* standards, like the HTTP or ANSI SQL standards, just have a set of interfaces that correspond to a version. It's only when vendors go outside of the standard to define what they want when things get fuzzy. Case in point: the HTTP extension framework: http://tools.ietf.org/html/**rfc2774.htmlhttp://tools.ietf.org/html/rfc2774.html Last updated in the year 2000. Nobody uses or cares about it. Why? Because it isn't a standard, and provides the ability for every Tom, Dick, and Rackspace to reinvent their own HTTP interfaces. It doesn't make sense. Then, or now. The point of standards and standards committees is to come to a compromise and develop a single standard. API Extensions are merely punting on that responsibility in the name of customization. First of all, I totally understand, appreciate and agree with your sentiment. Extensions are very frequently painful, but I'd argue that they don't have to be. If you dont have them, then you cannot get buy in from sufficient stakeholders. If you do have them, then you end up with extensibility. But actually extensibility in my opinion is a must have feature, since no protocol or standard (or Keystone) remains static for ever, and new features are continually being added to it. Therefore you must have a way for clients to know what functionality the remote server currently supports so that it can talk the correct protocol flavour to it. Extensibility is only a must have for *implementations*, IMHO, not for the *API*. API extensions are just a way around the hard work of creating a good, standardized, well-documented API. I especially don't see an API extension as a way to avoid producing well documented API's. For example, the accepted extensions to the v3 Identity API are fully documented from use case through API behavior: https://github.com/openstack/identity-api/tree/master/openstack-identity-api/v3/src/markdown Case in point: The Nova API extensions. How many of them are: a) not documented at all, including the code itself, b) not documented in some online document somewhere, and c) directly contradict the functionality in other extensions? That makes me cringe... API extensions shouldn't be treated as hacks! That's a cultural problem :( Extensibility, at least in my view, belongs on the implementation/driver layer. Keystone has done a good job keeping extensibility at its driver layer so far. To be fair, extensibility at the driver layer is basically keystone's core use case: allowing OpenStack to take advantage of your identity data, wherever it is. It's a shame it doesn't keep it there. Best, -jay __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://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
Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
On 08/06/2013 11:19 AM, Dean Troyer wrote: And that is the crux of the problem. When both can be installed side-by-side and sys.path is in control of the order, things work. This is such a fundamental problem in the distro that I am beginning to thing that we need to address it ourselves. Everything else is treating symptoms. Are you aware of Software Collections? It's relatively new. What Are Software Collections? Software Collections is a way to concurrently install multiple versions of specific software on the same system without affecting standard software packages that are installed on the system with the classic RPM package manager. http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/ http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Introducing_Dynamic_Software_Collections.html https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/1/html/Software_Collections_Guide/ -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
On Tue, Aug 6, 2013 at 8:35 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: I think jay your usage also was before anvil started to build all the *missing* dependencies automatically (something u inspired me to get going in the first place) so hopefully said updates to rhel.yaml are only now needed for exceptions and not the common path :) +1 I'm glad to hear that. I don't think any of the problems I saw with Anvil were intractable, but I do think packaging up the venv is much less error prone. My major complaints are issues related to yum. First off, yum can't resolve a version range (see my message to the yum list: http://lists.baseurl.org/pipermail/yum/2013-February/023922.html) which seems like a pretty basic task for a package manager. Also, Yum seems to do dependency resolution in a single pass. So yum can't provide an install solution for cases like this even when a valid one exists: package foo depends on pkgdep = 2.0 package bar depends on pkgdep = 1.0, = 2.0 pkgdep 2.1 and 2.0 are available for install sudo yum install foo when none of those three packages are installed results in an error. Yum tries to install pkgdep 2.1 and then gives up when it sees foo doesn't work with pkgdep 2.1 rather than doing a second pass at building a dependency graph and finding that pkgdep 2.0 would satisfy all dependencies. Cases like these come up regularly with the 100+ python packages that openstack depends on (in requirements.txt) when building packages continuously. I came to the conclusion that yum is bad software and I should avoid it globbing up most everything into one big rpm. Three months into making the switch I'm happy with that decision. Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 06/08/2013 16:53, Jay Pipes wrote: On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation meetings has their own agenda to follow: their preferences, likes, dislikes, must have features, etc. This is why standards end up with optional extensions. Which standards are you referring to? Virtually all standards from every standards organisations OASIS, IETF, ISO etc. e.g. SMTP is ubiquitous yet it has dozens of extensions. The DNS and LDAP have multiple extensions as well. So you can and need to have extensions and that does not stop a standard from gaining wide acceptance and applicability. *Good* standards, like the HTTP or ANSI SQL standards, just have a set of interfaces that correspond to a version. It's only when vendors go outside of the standard to define what they want when things get fuzzy. Case in point: the HTTP extension framework: http://tools.ietf.org/html/rfc2774.html Last updated in the year 2000. Nobody uses or cares about it. Why? Because it isn't a standard, and provides the ability for every Tom, Dick, and Rackspace to reinvent their own HTTP interfaces. It doesn't make sense. Then, or now. The point of standards and standards committees is to come to a compromise and develop a single standard. API Extensions are merely punting on that responsibility in the name of customization. If you dont have them, then you cannot get buy in from sufficient stakeholders. If you do have them, then you end up with extensibility. But actually extensibility in my opinion is a must have feature, since no protocol or standard (or Keystone) remains static for ever, and new features are continually being added to it. Therefore you must have a way for clients to know what functionality the remote server currently supports so that it can talk the correct protocol flavour to it. Extensibility is only a must have for *implementations*, IMHO, not for the *API*. API extensions are just a way around the hard work of creating a good, standardized, well-documented API. No, you need extensibility in the protocols as well. Cases in point, SMTP and LDAP. regards David Case in point: The Nova API extensions. How many of them are: a) not documented at all, including the code itself, b) not documented in some online document somewhere, and c) directly contradict the functionality in other extensions? Extensibility, at least in my view, belongs on the implementation/driver layer. Keystone has done a good job keeping extensibility at its driver layer so far. It's a shame it doesn't keep it there. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Please release new client library releases
Hey all! As you know, we're been battling the effects of the setuptools/distribute re-merge and upgrade for about a month now. It's mostly settled down, but there are still cases where transitive dependencies on things that depend on things that depend on distribute can screw us. At the moment, there are two depends that do this that we are aware of- d2to1 and python-mysqldb. The second is slow-moving, so installing it from distro packages in devstack is fine. The first, d2to1, we've removed from trunk of things. I've sent changes in to all the client libs: https://review.openstack.org/#/q/status:open+branch:master+topic:openstack/requirements,n,z It would help both the CI infrastructure, and honestly our end users, if you could take a moment to merge these, and once you have to cut a new release. It will remove us as being a link to setuptools related breakage. Thanks! Monty ___ 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
Personally I'm of the opinion that from an architectural POV, use of either rootwrap or sudo is a bad solution, so arguing about which is better is really missing the bigger picture. In Linux, there has been a move away from use of sudo or similar approaches, towards the idea of having privileged separated services. So if you wanted todo stuff related to storage, you'd have some small daemon running privilegd, which exposed APIs over DBus, which the non-privileged thing would call to make storage changes. Operations exposed by the service would have access control configured via something like PolicyKit, and/or SELinux/AppArmour. The more I think about this problem the more I'm convinced that rootwrap simply exists to work around a fundamental design flaw in most (all?) of the components: a single, threaded, process with poor job/workflow mnemonics. If the architecture was such that every operation was a task which could be carried out by any process (even a process running on a different host) and each process publishes job types that it can do, then you could do proper isolation for just those processes that need to do privileged tasks. https://wiki.openstack.org/wiki/TaskFlow looks to be headed in the right direction, but I worry it's got a very long road ahead. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 06/08/2013 18:11, Jay Pipes wrote: What SMTP, DNS and LDAP extensions are in use by systems that need to interoperate in the same way that Keystone does? -- This is a genuine question, not sarcasm. I'm truly curious. Take SMTP for example. My Thunderbird client needs to know what authentication extensions are implemented by the POP3 server and SMTP server that it is talking to, in order to send and receive email in a secure manner. In the same way, once Keystone supports say federated login as an extension, a client will need to know if this extension is supported or not. If not, it wont be able to offer it to the end user. (It is not a sensible design for a client to send an extension protocol message to a server and get a 400 Bad Request response. This tells the client nothing. 501 Not Implemented might be a more informative response, but in this case the server has to know that an extension was requested and we have to document that this is the standard response to an unimplemented extension). regards David Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 08/06/2013 01:21 PM, David Chadwick wrote: On 06/08/2013 18:11, Jay Pipes wrote: What SMTP, DNS and LDAP extensions are in use by systems that need to interoperate in the same way that Keystone does? -- This is a genuine question, not sarcasm. I'm truly curious. Take SMTP for example. My Thunderbird client needs to know what authentication extensions are implemented by the POP3 server and SMTP server that it is talking to, in order to send and receive email in a secure manner. In the same way, once Keystone supports say federated login as an extension, a client will need to know if this extension is supported or not. If not, it wont be able to offer it to the end user. (It is not a sensible design for a client to send an extension protocol message to a server and get a 400 Bad Request response. This tells the client nothing. 501 Not Implemented might be a more informative response, but in this case the server has to know that an extension was requested and we have to document that this is the standard response to an unimplemented extension). Ah, OK, so I think we're actually closer to one another than first glance. So, I *entirely* agree that if API extensions are available/supported by an API, then there should be an easy way to discover those extensions -- /endpoints is perfectly fine. I also agree that a *protocol* should have the flexibility, within its bytestream construct, to extend its scope over time, *without needing to change the underlying protocol*. So, for example, a protocol that leaves itself some way of growing over time is, by nature, A Good Thing (tm). However, I do *not* believe that resource additions to a REST-ful API necessitate a new API extension that must be treated like something that is fundamentally different from the existing resources published in the API. Por ejemplo, I do not believe the adding a /regions resource should require me to add an API extension just to add the resource to the API. I believe we should be able to propose the adding of the /regions resource, debate it, and then add it to a v3.x Keystone API. There isn't anything about a region resource that is fundamentally different from some other resource managed by Keystone -- like domains or endpoints -- and therefore I don't believe that adding a /regions resource endpoint should require anything more than a bump in the version of the API. Hope this makes more sense, -jay p.s. Despite my opinion that /regions resource addition should not be an extension, I'm still submitting a proposed API extension for it ;) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
another -1 from me for dropping it from hacking. I've been bitten by both lack of explicit usage and review bikeshedding on this exact thing. -Alex -Original Message- From: Sean Dague s...@dague.net Sent: Tuesday, August 6, 2013 7:32am To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302 On 08/05/2013 10:38 PM, Monty Taylor wrote: On 08/05/2013 11:26 PM, Robert Collins wrote: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are designed to be used as a dsl: self.assertThat(foo, Or(Equals(1), Equals(2))) rather than what H302 enforces: self.assertThat(foo, matchers.Or(matchers.Equals(1), matchers.Equals(2))) Further, conflicting module names become harder to manage, when one could import just the thing. Some arguments for requiring imports of modules: - makes the source of symbols obvious - Actually, it has no impact on that as the import is still present and clear in the file. import * would obfuscate things, but I'm not arguing for that. - and package/module names can (and are!) still ambiguous. Like 'test.' - whats that? - consult the imports. - makes mocking more reliable - This is arguably the case, but it's a mirage: it isn't a complete solution because modules still need to be mocked at every place they are dereferenced : only import modules helps to the extent that one never mocks modules. Either way this failure mode of mocking is usually very obvious IME : but keeping the rule as a recommendation, *particularly* when crossing layers to static resources is a good idea. - It's in the Google Python style guide (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports) - shrug :) What I'd like us to do is weaken it from a MUST to a MAY, unless noone cares about it at all, in which case lets just turn it off entirely. Enforcing it is hard. The code that does it has to import and then make guesses on failures. Also - I agree with Robert on this. I _like_ writing my code to not import bazillions of things... but I think the hard and fast rule makes things crappy at times. The reason we go hard and fast on certain rules is to reduce review time by people. If something is up for debate we get bikeshedding in reviews where one reviewer tells someone to do it one way, 2 days later they update their review, another reviewer comes in and tells them to do it the otherway. (This is not theoretical, it happens quite often, if you do a lot of reviews you see it all the time.) It also ends up being something reviewers can stop caring about, because the machine will pick it up. Giving them the ability to focus on higher order issues, and still keeping the code from natural entropy. MUST == computer can do it, less work for core review time (which is realistically one of our most constrained resources in OpenStack) MAY == humans have to make a judgement call, which means more work for our already constrained review teams I've found H302 to really be useful on reviewing large chunks of code I've not been in much before. And get seriously annoyed being in projects that don't have it enforced yet (tempest is guilty of that). Being able to quickly know what namespace things are out of saves time. Honestly, after spending the year with the constraint in OpenStack, I'm never going to import modules directly in my personal projects, as I think the benefits of the explicitness have shown themselves pretty well. So I'm a soft -1 on dropping it from hacking. -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] [Nova] nova-api won't start in devstack
I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File /usr/local/bin/nova-api, line 10, in module 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/cmd/api.py, line 51, in main 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api, use_ssl=should_use_ssl) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/service.py, line 311, in __init__ 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/wsgi.py, line 488, in load_app 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name, **kw) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2013-08-06 11:28:28.938 TRACE nova return context.create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1]) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object, context.global_conf, **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory 2013-08-06 11:28:28.938 TRACE nova return cls() 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/compute/__init__.py, line 141, in __init__ 2013-08-06 11:28:28.938 TRACE nova super(APIRouterV3, self).__init__(init_only) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 323, in __init__ 2013-08-06 11:28:28.938 TRACE nova missing_apis=missing_core_extensions) 2013-08-06 11:28:28.938 TRACE nova CoreAPIMissing: Core API extensions are missing: set(['flavors', 'limits', 'consoles', 'servers', 'ips', 'server-metadata', 'extensions']) 2013-08-06 11:28:28.938 TRACE nova 2013-08-06 11:28:28.999 INFO nova.openstack.common.service [-] Parent process has died unexpectedly, exiting 2013-08-06 11:28:28.999 INFO nova.wsgi [-] Stopping WSGI server. My localrc is: disable_service n-net enable_service q-svc enable_service q-agt enable_service q-dhcp enable_service q-l3 enable_service q-meta enable_service neutron disable_service tempest Q_PLUGIN=linuxbridge DATABASE_PASSWORD=nova RABBIT_PASSWORD=nova SERVICE_TOKEN=nova SERVICE_PASSWORD=nova
Re: [openstack-dev] Blueprint for Nova native image building
On 08/06/2013 12:20 PM, Russell Bryant wrote: On 08/06/2013 11:53 AM, Ian Mcleod wrote: Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be further customized by other tools that expect an existing image as an input, such as disk image builder. Blueprint - https://blueprints.launchpad.net/nova/+spec/base-image-creation Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI If this is a topic that interests you, please have a look (the spec is not very long) and join the conversation. Please note that this blueprint follows on from proof of concept work for native image building discussed on this list in April: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html Thanks of the update on this work. I see that your proof of concept shows how this can work as a tool outside of Nova: https://github.com/redhat-openstack/image-building-poc So, my biggest question is whether or not it makes sense for this to be a Nova feature or not. If something can be implemented as a consumer of Nova, my default answer is that it should stay outside of nova until I am convinced otherwise. :-) It sounds like this is mostly an extension to nova that implements a series of operations that can be done just as well outside of Nova. Are there enhancements you are making or scenarios that won't work at all unless it lives inside of Nova? If it doesn't end up on the server side, it could potentially be implemented as an extension to novaclient. Also, whatever we end up with, I'd like to see it hypervisor agnostic as much as possible. I just came across this xen specific patch: https://review.openstack.org/#/c/38650/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] Should image size/checksum be immutable for active images?
Do u know what cases the 'size' or 'checksum' needs to be modified? I'd hope for immutability in these 2 things. On 8/6/13 10:39 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2013 01:30 PM, stuart.mcla...@hp.com wrote: Hi, There are cases where an image's 'size' or 'checksum' values need to be modified before an image becomes active; but do we need, as I think we currently do, to allow users to change them once an image becomes active? Without the 'size' pinned down an operator can't necessarily trust the current value. Total agreement. -jay ___ 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] Python dependencies: PyPI vs distro packages
On 08/06/2013 02:44 PM, Mate Lakat wrote: Hi, I would say, use a separated virtual environment in devstack - without the --system-site-packages switch, of course, and set it up as a user. Install the packages that are needed in order to be able to pip install them (like libxslt-dev). It's a development environment. I think my email is equivalent to a +1 to (Monty's change + virtualenv). YUP - except we can't do it without system-site-packages, because of nova and libvirt. We should still be ok though with a single venv, as long as all of the installs into the venv use the -U flag to pip, which will override the system env with teh venv one. That said - I think there are a few different assumptions about what we are trying to test that we need to sort out. Is the we want to install things globally via pip an actual requirement, or one that has grown out of implementation? On Tue, Aug 06, 2013 at 10:29:14AM -0500, Dean Troyer wrote: On Tue, Aug 6, 2013 at 3:50 AM, Bob Ball bob.b...@citrix.com wrote: I think we need a further constraint: We must ensure that yum/etc believes that the python-* packages are installed. If we want the rest of the system to use them, yes. If we want to install a newer version of the python-* packages then we have to make sure the package manager for the OS knows that they are installed. Or knows to ignore them. By keeping them away from the places the package manager is likely to overwrite them with older versions. Sounds like a venv? Because it is, a global-always-available-never-needs-explicit-acvtivation venv: /usr/local In my mind this restricts us to having to do something with RPMs - whether that is packaging all of the python components up as RPMs or using the dummy RPM proposed by Ian. The packaging work is already being done (will be done) for each platform that wants to ship OpenStack. It just isn't up-to-date with development cycles. Out of these two, I think the cleanest solution for us is to use the dummy RPM for RPMs that we explicitly remove. If this is only python-lxml and python-crypto (and maybe a couple of others) then this is probably fine. One final thought - if we have to jump through lots of hoops to get this working correctly in devstack, then should we re-evaluate the use of virtual environments? We're looking at departing a long way from how this can be deployed in the real world - so perhaps virtual environments would be a useful way to encapsulate what we're testing? venvs, as implemented by the current tools, doesn't work well here. BUT, if there was a single global venv available that could override rpm-installed packages at will without disturbing them, would that work? BTW, that's how Debian/Ubuntu do it. pip installs to /usr/local and sys.path has it ahead of /usr * Fedora and RHEL6 have a nasty configuration of telling pip to install packages into the same location as RPM-installed packages setting up hard-to-diagnose problems and irritating sysadmins everywhere. FTR, Debian/Ubuntu configure pip to install into /usr/local and put '/usr/local/lib/python2.7/dist-packages' ahead of '/usr/lib/python2.7/dist-packages' in sys.path. I guess what I am saying is that if we're going to 'trick' something on the system to behaving the way that we want, let's do the right trick that doesn't have to be continually maintained. dt -- Dean Troyer dtro...@gmail.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
Re: [openstack-dev] Blueprint for Nova native image building
On 08/06/2013 03:46 PM, Russell Bryant wrote: On 08/06/2013 12:20 PM, Russell Bryant wrote: On 08/06/2013 11:53 AM, Ian Mcleod wrote: Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be further customized by other tools that expect an existing image as an input, such as disk image builder. Blueprint - https://blueprints.launchpad.net/nova/+spec/base-image-creation Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI If this is a topic that interests you, please have a look (the spec is not very long) and join the conversation. Please note that this blueprint follows on from proof of concept work for native image building discussed on this list in April: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html Thanks of the update on this work. I see that your proof of concept shows how this can work as a tool outside of Nova: https://github.com/redhat-openstack/image-building-poc So, my biggest question is whether or not it makes sense for this to be a Nova feature or not. If something can be implemented as a consumer of Nova, my default answer is that it should stay outside of nova until I am convinced otherwise. :-) It sounds like this is mostly an extension to nova that implements a series of operations that can be done just as well outside of Nova. Are there enhancements you are making or scenarios that won't work at all unless it lives inside of Nova? If it doesn't end up on the server side, it could potentially be implemented as an extension to novaclient. Also, whatever we end up with, I'd like to see it hypervisor agnostic as much as possible. I just came across this xen specific patch: https://review.openstack.org/#/c/38650/ Yes to everything Russel said. I'd like to see the tool be standalone. Then, if there is a desire to provide the ability to run it via an api, the tool could be consumed (similar discussions have happened around putting diskimage-builder behind a service as well) That said - if we did service-ify the tool, wouldn't glance be a more appropriate place for that sort of thing? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] nova-api won't start in devstack
On Aug 6, 2013, at 1:33 PM, Edgar Magana emag...@plumgrid.com wrote: I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File /usr/local/bin/nova-api, line 10, in module 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/cmd/api.py, line 51, in main 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api, use_ssl=should_use_ssl) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/service.py, line 311, in __init__ 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/wsgi.py, line 488, in load_app 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name, **kw) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2013-08-06 11:28:28.938 TRACE nova return context.create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1]) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object, context.global_conf, **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory 2013-08-06 11:28:28.938 TRACE nova return cls() 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/compute/__init__.py, line 141, in __init__ 2013-08-06 11:28:28.938 TRACE nova super(APIRouterV3, self).__init__(init_only) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 323, in __init__ 2013-08-06 11:28:28.938 TRACE nova missing_apis=missing_core_extensions) 2013-08-06 11:28:28.938 TRACE nova CoreAPIMissing: Core API extensions are missing: set(['flavors', 'limits', 'consoles', 'servers', 'ips', 'server-metadata', 'extensions']) 2013-08-06 11:28:28.938 TRACE nova 2013-08-06 11:28:28.999 INFO nova.openstack.common.service [-] Parent process has died unexpectedly, exiting 2013-08-06 11:28:28.999 INFO nova.wsgi [-] Stopping WSGI server. My localrc is: disable_service n-net enable_service q-svc enable_service q-agt
[openstack-dev] Proposing Morgan Fainberg for keystone-core
Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core
On 08/06/2013 03:20 PM, Dolph Mathews wrote: Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core
+1 Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 08/06/2013 02:23 PM Subject:[openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! Ā Ā https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev inline: graycol.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core
+1 from me, Morgan would be a great addition. Henry On 6 Aug 2013, at 20:20, Dolph Mathews wrote: Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -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] Proposing Morgan Fainberg for keystone-core
Easy +1 Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.com From: Yee, Guang guang@hp.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 08/06/2013 03:42 PM Subject:Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core +1! Guang From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Tuesday, August 06, 2013 12:20 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph [attachment smime.p7s deleted by Steve Martinelli/Toronto/IBM] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev inline: graycol.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core
+1 on Morgan. He is an outstanding contributor! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/06/2013 03:22 PM Subject:[openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -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] Proposing Morgan Fainberg for keystone-core
+1 from me. -- Brant On Tue, Aug 6, 2013 at 3:10 PM, Brad Topol bto...@us.ibm.com wrote: +1 on Morgan. He is an outstanding contributor! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From:Dolph Mathews dolph.math...@gmail.com To:OpenStack Development Mailing List openstack-dev@lists.openstack.org Date:08/06/2013 03:22 PM Subject:[openstack-dev] Proposing Morgan Fainberg for keystone-core -- Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! *https://review.openstack.org/#/dashboard/2903*https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On 06/08/2013 20:40, Clint Byrum wrote: Agreed Jay. The successful extensible protocols like IMAP and SMTP are merely allowing new arguments to existing fundamental functions. But the key thing with these protocols is that they have a defined and standardised way of adding new extensions - any extension - to the protocol, which is followed by all the new extensions when they are defined. This is what needs to be documented by Keystone i.e. how to add any new type of extension. regards David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
While I'm torn on this as a developer, it comes down to an ease of understanding the code. In all cases, it is easier to understand where something comes from if you only import modules. Enforcing the import of modules tends to also ensure namespace conflicts don't occur as often. When it comes to review, I am going to agree with Sean here, it is a boon on large changes. I am against lessening/removing H302; but I understand why people desire it eased up. Cheers, Morgan Fainberg IRC: morganfainberg On Tue, Aug 6, 2013 at 1:18 PM, Christopher Armstrong chris.armstr...@rackspace.com wrote: On Tue, Aug 6, 2013 at 6:32 AM, Sean Dague s...@dague.net wrote: The reason we go hard and fast on certain rules is to reduce review time by people. If something is up for debate we get bikeshedding in reviews where one reviewer tells someone to do it one way, 2 days later they update their review, another reviewer comes in and tells them to do it the otherway. (This is not theoretical, it happens quite often, if you do a lot of reviews you see it all the time.) It also ends up being something reviewers can stop caring about, because the machine will pick it up. Giving them the ability to focus on higher order issues, and still keeping the code from natural entropy. MUST == computer can do it, less work for core review time (which is realistically one of our most constrained resources in OpenStack) MAY == humans have to make a judgement call, which means more work for our already constrained review teams I've found H302 to really be useful on reviewing large chunks of code I've not been in much before. And get seriously annoyed being in projects that don't have it enforced yet (tempest is guilty of that). Being able to quickly know what namespace things are out of saves time. I think it's really unfortunate that people will block patches based on stylistic concerns. The answer, IMO, is to codify in policy that stylistic issues *cannot* block a patch from landing. I recommend having humility in our reviews. Instead of This bike shed needs to be painted red. -1 One should say I prefer red for the color of bike sheds. You can do that if you want, but go ahead and merge anyway if you don't want to. +0 and don't mark a review as -1 if it *only* has bikeshedding in it. I would love to see a culture of reviewing that emphasizes functional correctness, politeness, and mutual education. And given the rationale from Robert Collins, I agree that the module-import thing should be one of the flakes that allows exceptions. -- IRC: radix Christopher Armstrong Rackspace ___ 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] Blueprint for Nova native image building
The patch referred to (https://review.openstack.org/#/c/38650/) isn't really around adding support to build native images. We're using the existing boot from ISO support feature to load an iPXE ISO into Glance which then can then chain load a menu of installation options from an http server. This allows us to netboot any operating system. We're using it primarily with XenServer today but this method should work with all of the other hypervisors. The goal of this specific patch is to provide support for Xen service providers that utilize static networking, so that customers of that service provider can utilize this tool without having to manually input the networking information of their instance. The iPXE iso can be set in DHCP mode or require manual input of the address of the instance. The patch automates the input without having to use DHCP by regenerating the ISO with the networking information required to bring the instance onto the network when in the virtual BIOS. For providers using DHCP, no additional code is needed, just an iPXE iso registered into Glance. It makes for a really handy way to provision a new image from scratch. Ant On Aug 6, 2013, at 2:02 PM, Monty Taylor mord...@inaugust.com wrote: On 08/06/2013 03:46 PM, Russell Bryant wrote: On 08/06/2013 12:20 PM, Russell Bryant wrote: On 08/06/2013 11:53 AM, Ian Mcleod wrote: Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be further customized by other tools that expect an existing image as an input, such as disk image builder. Blueprint - https://blueprints.launchpad.net/nova/+spec/base-image-creation Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI If this is a topic that interests you, please have a look (the spec is not very long) and join the conversation. Please note that this blueprint follows on from proof of concept work for native image building discussed on this list in April: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html Thanks of the update on this work. I see that your proof of concept shows how this can work as a tool outside of Nova: https://github.com/redhat-openstack/image-building-poc So, my biggest question is whether or not it makes sense for this to be a Nova feature or not. If something can be implemented as a consumer of Nova, my default answer is that it should stay outside of nova until I am convinced otherwise. :-) It sounds like this is mostly an extension to nova that implements a series of operations that can be done just as well outside of Nova. Are there enhancements you are making or scenarios that won't work at all unless it lives inside of Nova? If it doesn't end up on the server side, it could potentially be implemented as an extension to novaclient. Also, whatever we end up with, I'd like to see it hypervisor agnostic as much as possible. I just came across this xen specific patch: https://review.openstack.org/#/c/38650/ Yes to everything Russel said. I'd like to see the tool be standalone. Then, if there is a desire to provide the ability to run it via an api, the tool could be consumed (similar discussions have happened around putting diskimage-builder behind a service as well) That said - if we did service-ify the tool, wouldn't glance be a more appropriate place for that sort of thing? ___ 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] Motion to start using Gerrit for TC votes
On Tue, Aug 6, 2013 at 1:32 PM, Monty Taylor mord...@inaugust.com wrote: Hi! Currently, we make motions by email, then we discuss them by mailing list, then we discuss them more in IRC, then we vote on them - at which point the actual thing voted on may or may not get recorded somewhere easy to find. What if instead we had a repo with a bunch of ReStructureText in it - perhaps a copy of the TC charter and then a dir for additional things the TC has decided. That repo would be autopublished to a non-wiki website ... and the core team for the repo was the TC. EXCEPT, we didnt' do a 2 core +2 thing ... we'd have some slightly different rules. Such as - certain number of days it has to be open, certain number of +1 votes, etc. And then only the TC chair has the actual APRV vote, which is used to codify the vote tallies. This would allow for clear voting by both the TC and others - is consistent with tooling we ALL know how to use, and has the benefit of producing a clear published record of the results when it's done. That way also, TC members and others can do a decent amount of the actual discussion outside of TC meeting, and we can save meeting time for resolution of issues/questions that simply cannot be sorted out via gerrit process. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I really like this concept. This would be a very nice level of transparency (not that the TC hides anything) and makes it much easier to see what is/has been going on and how we got there. It also ensures we have the comments recorded along the way. Cheers, Morgan Fainberg IRC: morganfainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
James Slagle james.sla...@gmail.com wrote: WSME + pecan is being used in Tuskar: https://github.com/tuskar/tuskar (OpenStack management API) We encountered the same issue discussed here. A solution we settled on for now was to use a custom Renderer class that could handle different response codes. You set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. If there is anything I can do on the Pecan side, let me know! Happy to build in new functionality to make this easier, in general. It does seem to make sense to be fixed on the WSME side, though. Best -- - Jonathan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Motion to start using Gerrit for TC votes
Monty Taylor mord...@inaugust.com writes: Hi! Currently, we make motions by email, then we discuss them by mailing list, then we discuss them more in IRC, then we vote on them - at which point the actual thing voted on may or may not get recorded somewhere easy to find. What if instead we had a repo with a bunch of ReStructureText in it - perhaps a copy of the TC charter and then a dir for additional things the TC has decided. That repo would be autopublished to a non-wiki website ... and the core team for the repo was the TC. EXCEPT, we didnt' do a 2 core +2 thing ... we'd have some slightly different rules. Such as - certain number of days it has to be open, certain number of +1 votes, etc. And then only the TC chair has the actual APRV vote, which is used to codify the vote tallies. This would allow for clear voting by both the TC and others - is consistent with tooling we ALL know how to use, and has the benefit of producing a clear published record of the results when it's done. That way also, TC members and others can do a decent amount of the actual discussion outside of TC meeting, and we can save meeting time for resolution of issues/questions that simply cannot be sorted out via gerrit process. I like this idea because it also solves the following problems: * Votes are more strongly authenticated (and not affected by random people in IRC (I grant this has not been a huge problem so far, it's easy to mentally subtract a vote from someone who wanders in). * There is a clear and easy record of not only exactly what the TC voted on, but the current present state of the project governance. An easy reference for what resolutions, rules, processes, etc are in effect. That last one seems important to me, because sometimes it seems like understanding of project governance is verging on tribal knowledge, with even members of the TC disagreeing over what may or may not have been decided previously. This will help everyone whether new to the project or not, understand what our current processes and decisions are. -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Motion to start using Gerrit for TC votes
+1 2013/8/6 Morgan Fainberg m...@metacloud.com: On Tue, Aug 6, 2013 at 1:32 PM, Monty Taylor mord...@inaugust.com wrote: Hi! Currently, we make motions by email, then we discuss them by mailing list, then we discuss them more in IRC, then we vote on them - at which point the actual thing voted on may or may not get recorded somewhere easy to find. What if instead we had a repo with a bunch of ReStructureText in it - perhaps a copy of the TC charter and then a dir for additional things the TC has decided. That repo would be autopublished to a non-wiki website ... and the core team for the repo was the TC. EXCEPT, we didnt' do a 2 core +2 thing ... we'd have some slightly different rules. Such as - certain number of days it has to be open, certain number of +1 votes, etc. And then only the TC chair has the actual APRV vote, which is used to codify the vote tallies. This would allow for clear voting by both the TC and others - is consistent with tooling we ALL know how to use, and has the benefit of producing a clear published record of the results when it's done. That way also, TC members and others can do a decent amount of the actual discussion outside of TC meeting, and we can save meeting time for resolution of issues/questions that simply cannot be sorted out via gerrit process. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I really like this concept. This would be a very nice level of transparency (not that the TC hides anything) and makes it much easier to see what is/has been going on and how we got there. It also ensures we have the comments recorded along the way. Cheers, Morgan Fainberg IRC: morganfainberg ___ 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] Change in openstack/keystone[master]: Implement domain specific Identity backends
Hi Mark, Of particular interest are your views on the changes to keystone/common/config.py. The requirement is that we need to be able to instantiate multiple conf objects (built from different sets of config files). We tried two approaches to this: https://review.openstack.org/#/c/39530/11 which attempts to keep the current keystone config helper apps (register_bool() etc.) by passing on the conf instance, and https://review.openstack.org/#/c/39530/12 which removes these helper apps and just calls the methods on the conf itself (conf.register_opt()) Both functionally work, but interested in your views on both approaches. Henry On 6 Aug 2013, at 19:26, ayoung (Code Review) wrote: Hello Mark McLoughlin, I'd like you to do a code review. Please visit https://review.openstack.org/39530 to review the following change. Change subject: Implement domain specific Identity backends .. Implement domain specific Identity backends A common scenario in shared clouds will be that a cloud provider will want to be able to offer larger customers the ability to interface to their chosen identity provider. In the base case, this might well be their own corporate LDAP/AD directory. A cloud provider might also want smaller customers to have their identity managed solely within the OpenStack cloud, perhaps in a shared SQL database. This patch allows domain specifc backends for identity objects (namely User and groups), which are specified by creation of a domain configuration file for each domain that requires its own backend. A side benefit of this change is that it clearly separates the backends into those that are domain-aware and those that are not, allowing, for example, the removal of domain validation from the LDAP identity backend. Implements bp multiple-ldap-servers Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab --- M doc/source/configuration.rst M etc/keystone.conf.sample M keystone/auth/plugins/password.py M keystone/catalog/backends/templated.py M keystone/common/config.py M keystone/common/controller.py M keystone/common/ldap/fakeldap.py M keystone/common/utils.py M keystone/config.py M keystone/identity/backends/kvs.py M keystone/identity/backends/ldap.py M keystone/identity/backends/pam.py M keystone/identity/backends/sql.py M keystone/identity/controllers.py M keystone/identity/core.py M keystone/test.py M keystone/token/backends/memcache.py M keystone/token/core.py A tests/backend_multi_ldap_sql.conf A tests/keystone.Default.conf A tests/keystone.domain1.conf A tests/keystone.domain2.conf M tests/test_backend.py M tests/test_backend_ldap.py 24 files changed, 1,028 insertions(+), 372 deletions(-) git pull ssh://review.openstack.org:29418/openstack/keystone refs/changes/30/39530/12 -- To view, visit https://review.openstack.org/39530 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab Gerrit-PatchSet: 12 Gerrit-Project: openstack/keystone Gerrit-Branch: master Gerrit-Owner: henry-nash hen...@linux.vnet.ibm.com Gerrit-Reviewer: Brant Knudson bknud...@us.ibm.com Gerrit-Reviewer: Dolph Mathews dolph.math...@gmail.com Gerrit-Reviewer: Jenkins Gerrit-Reviewer: Mark McLoughlin mar...@redhat.com Gerrit-Reviewer: Sahdev Zala spz...@us.ibm.com Gerrit-Reviewer: SmokeStack Gerrit-Reviewer: ayoung ayo...@redhat.com Gerrit-Reviewer: henry-nash hen...@linux.vnet.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On 06/08/13 21:56, Jonathan LaCour wrote: James Slagle james.sla...@gmail.com wrote: WSME + pecan is being used in Tuskar: https://github.com/tuskar/tuskar (OpenStack management API) We encountered the same issue discussed here. A solution we settled on for now was to use a custom Renderer class that could handle different response codes. You set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. If there is anything I can do on the Pecan side, let me know! Happy to build in new functionality to make this easier, in general. It does seem to make sense to be fixed on the WSME side, though. Best -- - Jonathan Nah - this is entirely on the WSME side :) WSME translate all exceptions that don't extend their ClientExcption to HTTP 500, and anything that does to HTTP 400. Beyond that, you only have the default status code to work with - 401, 404, 503 etc are all off limits with stock WSME. Literally you have a default code for successful requests, and 400 or 500. Nothing else. It seems like Ceilometer has worked there way around it using the _lookup method for 404's (but I can't find how they return any other status codes..), and libra + tuskar have replaced the WSME error handling for something entirely custom. We're not massively interested in replacing WSME's error handling with something custom, so our plan is to just use Pecan and ignore WSME for the Designate v2 API. When it's ready, hopefully the switch won't be too painful! Thanks, Kiall ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [ml2] [devstack] Per MechanismDriver configuration for ML2 in devstack
Neutron and devstack folks: I've written up some notes [1] on how I'd like to add per-MechanismDriver support into devstack for ML2. This will be very nice to have as the number of ML2 MechanismDrivers increase. My approach for this will allow for complex configurations via localrc variables with very minimal changes to the existing ML2 devstack code (likely a handful of lines). I'd appreciate some reviews of this. I've filed a BP in devstack [2] for this as well, and I should have an initial implementation of this by tomorrow. We'll discuss this in more detail at the ML2 sub-team meeting tomorrow. Thanks, Kyle [1] https://docs.google.com/document/d/1vvfey4SCFA5Ih9e6VUdjnRAVj6YIusfXlbPT8yxVOvY/edit?usp=sharing [2] https://blueprints.launchpad.net/devstack/+spec/ml2-devstack-mechanism-driver ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Motion to start using Gerrit for TC votes
On Tue, Aug 6, 2013 at 3:32 PM, Monty Taylor mord...@inaugust.com wrote: Hi! Currently, we make motions by email, then we discuss them by mailing list, then we discuss them more in IRC, then we vote on them - at which point the actual thing voted on may or may not get recorded somewhere easy to find. What if instead we had a repo with a bunch of ReStructureText in it - perhaps a copy of the TC charter and then a dir for additional things the TC has decided. That repo would be autopublished to a non-wiki website ... and the core team for the repo was the TC. EXCEPT, we didnt' do a 2 core +2 thing ... we'd have some slightly different rules. Such as - certain number of days it has to be open, certain number of +1 votes, etc. And then only the TC chair has the actual APRV vote, which is used to codify the vote tallies. This would allow for clear voting by both the TC and others - is consistent with tooling we ALL know how to use, and has the benefit of producing a clear published record of the results when it's done. That way also, TC members and others can do a decent amount of the actual discussion outside of TC meeting, and we can save meeting time for resolution of issues/questions that simply cannot be sorted out via gerrit process. Easy +1! I think this is a use case for version control + gerrit. Monty ___ 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] [Nova][Cinder] Guest Assisted Snapshots
Greetings, The following blueprint is targeted at Havana. I was reading over the design notes today. I wanted to check on the status of this as well as discuss some of the design details. https://wiki.openstack.org/wiki/Cinder/GuestAssistedSnapshotting https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots As a quick overview, the purpose of this is to provide the ability to do volume snapshots for certain volume types that do not support it internally, such as the GlusterFS or NFS drivers. Some comments/questions ... On the Nova side, the wiki page lists adding an API to snapshot all attached volumes at once. This seems fine, but I would personally put it at a lower priority than just making basic snapshots work. The Nova patch I've seen come by so far [1] was for this API, but like I said, I would just come back to this once regular snapshots work. The page also indicates that a snapshot request through the Cinder API will only work through if it's not attached. That seems fairly undesirable. Can we try to address that with the first pass? It seems like we could do something like: on the cinder side: cinder snapshot API if snapshot requires guest assist while in use, and is in use: call nova's guest assisted snapshot API else: do snapshot in cinder on the nova side: nova's new guest assisted snapshot API if volume type is a local file: do local magic to create a snapshot and call the new create-snapshot-metadata API call in cinder else: do cinder API call to do a snapshot, but potentially adding some guest assistance here (to get the filesystem in a consistent state first, for example) Similarly to create, I think having delete work through Nova, but not Cinder isn't ideal. Can we address that as well with a similar smart-redirect approach? My final comment on all of this is that I'm not a huge fan of having snapshot create/delete in both the nova and cinder APIs. I can't think of a better way to accomplish this, though. We don't have a nova API only exposed internally to the deployment, and I don't think this feature is enough to warrant adding one. [1] https://review.openstack.org/#/c/38251/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Blueprint for Nova native image building
On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote: On 08/06/2013 03:46 PM, Russell Bryant wrote: On 08/06/2013 12:20 PM, Russell Bryant wrote: On 08/06/2013 11:53 AM, Ian Mcleod wrote: Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be further customized by other tools that expect an existing image as an input, such as disk image builder. Blueprint - https://blueprints.launchpad.net/nova/+spec/base-image-creation Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI If this is a topic that interests you, please have a look (the spec is not very long) and join the conversation. Please note that this blueprint follows on from proof of concept work for native image building discussed on this list in April: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html Thanks of the update on this work. I see that your proof of concept shows how this can work as a tool outside of Nova: https://github.com/redhat-openstack/image-building-poc So, my biggest question is whether or not it makes sense for this to be a Nova feature or not. If something can be implemented as a consumer of Nova, my default answer is that it should stay outside of nova until I am convinced otherwise. :-) The proof of concept approach is limited to full-virt hypervisors. It's unclear to me if there's a way we can make this work for Xen-backed installs without the kind of lower level access to the virt environment that we'll get if we exist inside of Nova. More generally, it's likely that we'll have more flexibility to behave in a sane/optimized manner based on backing hypervisor if the code is inside of Nova. For example, we've talked about improving our detection of a failed install by monitoring disk IO. It sounds like this is mostly an extension to nova that implements a series of operations that can be done just as well outside of Nova. Are there enhancements you are making or scenarios that won't work at all unless it lives inside of Nova? Other than the Xen issue above, I'm not sure there's anything that simply won't work at all, though there are things that perhaps won't scale as well or won't run as quickly. If it doesn't end up on the server side, it could potentially be implemented as an extension to novaclient. Also, whatever we end up with, I'd like to see it hypervisor agnostic as much as possible. I just came across this xen specific patch: https://review.openstack.org/#/c/38650/ Yes to everything Russel said. I'd like to see the tool be standalone. Then, if there is a desire to provide the ability to run it via an api, the tool could be consumed (similar discussions have happened around putting diskimage-builder behind a service as well) That said - if we did service-ify the tool, wouldn't glance be a more appropriate place for that sort of thing? Possibly, though the proof of concept (and we hope our proposed nova-based re-implementation) can build both glance images and cinder volume backed images. ___ 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][Cinder] Guest Assisted Snapshots
On Tue, Aug 6, 2013 at 4:05 PM, Russell Bryant rbry...@redhat.com wrote: Greetings, The following blueprint is targeted at Havana. I was reading over the design notes today. I wanted to check on the status of this as well as discuss some of the design details. https://wiki.openstack.org/wiki/Cinder/GuestAssistedSnapshotting https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots As a quick overview, the purpose of this is to provide the ability to do volume snapshots for certain volume types that do not support it internally, such as the GlusterFS or NFS drivers. Some comments/questions ... On the Nova side, the wiki page lists adding an API to snapshot all attached volumes at once. This seems fine, but I would personally put it at a lower priority than just making basic snapshots work. The Nova patch I've seen come by so far [1] was for this API, but like I said, I would just come back to this once regular snapshots work. +1 from me on this for sure The page also indicates that a snapshot request through the Cinder API will only work through if it's not attached. That seems fairly undesirable. Can we try to address that with the first pass? It seems like we could do something like: on the cinder side: cinder snapshot API if snapshot requires guest assist while in use, and is in use: call nova's guest assisted snapshot API else: do snapshot in cinder on the nova side: nova's new guest assisted snapshot API if volume type is a local file: do local magic to create a snapshot and call the new create-snapshot-metadata API call in cinder else: do cinder API call to do a snapshot, but potentially adding some guest assistance here (to get the filesystem in a consistent state first, for example) Part of this reminds me of my whole debate about shared FS storage mixed in Cinder to begin with. The capabilties are different, and I think mixing around this if this: do nova-; else: do cinder-xxx results in a poor end-user experience to say the least. My proposal would be to change a couple of things here: 1. As Russell suggests leave the API calls in Cinder. I don't see a strong reason why we can't have a nova driver to send requests to Compute for things like this. Even if implementation wise we're still looking at things spread between the two (which I still don't find very appealing) at least from an end-users perspective it's not so confusing as to what's going on. 2. Consider rather than using the existing cinder snapshot command we introduce something unique for this special case. This would give the ability to do what we want here and would be considered acceptable in terms of the cinder minimum qualifications requirement. I don't care what it's called, cinder snapshot-share or whatever, but it seems like it's a different semantic so should be a different call. Similarly to create, I think having delete work through Nova, but not Cinder isn't ideal. Can we address that as well with a similar smart-redirect approach? Again, agree on this... having the mix between the two seems like it will just create confusion IMO. The same strategy as suggested above could work here as well. My final comment on all of this is that I'm not a huge fan of having snapshot create/delete in both the nova and cinder APIs. I can't think of a better way to accomplish this, though. We don't have a nova API only exposed internally to the deployment, and I don't think this feature is enough to warrant adding one. So the internal nova API direction is more along the lines of what I was suggesting. To be honest I suspect there's the possibility of more things fitting here in the future but I see your point. The problem I have is if these features aren't enough to justify it then are these features worth enough to justify the confusion of using multiple services/api's do do a volume snapshot? [1] https://review.openstack.org/#/c/38251/ -- Russell Bryant ___ 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] Proposing Morgan Fainberg for keystone-core
+1 On Tue, 2013-08-06 at 14:20 -0500, Dolph Mathews wrote: Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -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] [DevStack] Python dependencies: PyPI vs distro packages
On Tue, Aug 6, 2013 at 12:00 PM, Monty Taylor mord...@inaugust.com wrote: On 08/06/2013 02:44 PM, Mate Lakat wrote: I would say, use a separated virtual environment in devstack - without the --system-site-packages switch, of course, and set it up as a user. Install the packages that are needed in order to be able to pip install them (like libxslt-dev). It's a development environment. I think my email is equivalent to a +1 to (Monty's change + virtualenv). YUP - except we can't do it without system-site-packages, because of nova and libvirt. We should still be ok though with a single venv, as long as all of the installs into the venv use the -U flag to pip, which will override the system env with teh venv one. I'm building my virtualenv without system site-packages. It's super lame, but my nova rpm has a dep on a specific version of libvirt-python and then includes these symlinks: ln -s /usr/lib64/python2.6/site-packages/libvirt.py $(VENV)/lib/python2.6/site-packages/ ln -s /usr/lib64/python2.6/site-packages/libvirt_qemu.py $(VENV)/lib/python2.6/site-packages/ ln -s /usr/lib64/python2.6/site-packages/libvirtmod.so $(VENV)/lib/python2.6/site-packages/ ln -s /usr/lib64/python2.6/site-packages/libvirtmod_qemu.so $(VENV)/lib/python2.6/site-packages/ Why isn't libvirt-python on pypi? AFAICT, nothing is stopping us from uploading it. Maybe we should just stick it on there and this issue will be resolved once and for all. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] V3 Extensions Discoverability
On Tue, 2013-08-06 at 11:17 -0400, Adam Young wrote: On 08/06/2013 10:54 AM, Dolph Mathews wrote: On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams jorge.willi...@rackspace.com wrote: On Aug 6, 2013, at 8:36 AM, Adam Young wrote: On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openstack.org/#/c/38414/ ) I was thinking about how we should be able to know what/if an extension is available. I even made a basic blueprint for how i think it should work: https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API. I'm not certain that the extensions should really be in the v2 or v3. It always seemed to me that Extensions should be parallel to, and separate from, the core API. I agree. Extensions should not be in core, but the mechanism by which extensions are discovered should be part of the core...right? Agree. The fact that you call GET /v2.0/extensions or GET /v3/extensions instead of GET /extensions just means that we can iterate on the extensions response itself, not necessarily that the extension *only* applies to particular version API being queried (that's a different issue). Agreed. That makes sense. So the APIs should be: v2.0/extensions or v3/extensions but those should return links to: extensions/some_extension This was my thoughts as well, there is no reason for the extension to be versioned behind our keystone API because we don't expect the extension api to change with the core api. Extension discoverability should be behind our API because we reserve the right to change how extensions are discovered. I think it also somewhat answers my question that we should be providing a /v3/extensions rather than putting these into /v3/endpoints. -jOrGe W. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
On Tue, Aug 6, 2013 at 2:17 PM, Mac Innes, Kiall ki...@hp.com wrote: On 06/08/13 21:56, Jonathan LaCour wrote: James Slagle james.sla...@gmail.com wrote: WSME + pecan is being used in Tuskar: https://github.com/tuskar/tuskar (OpenStack management API) We encountered the same issue discussed here. A solution we settled on for now was to use a custom Renderer class that could handle different response codes. You set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. If there is anything I can do on the Pecan side, let me know! Happy to build in new functionality to make this easier, in general. It does seem to make sense to be fixed on the WSME side, though. Best -- - Jonathan Nah - this is entirely on the WSME side :) WSME translate all exceptions that don't extend their ClientExcption to HTTP 500, and anything that does to HTTP 400. Beyond that, you only have the default status code to work with - 401, 404, 503 etc are all off limits with stock WSME. Literally you have a default code for successful requests, and 400 or 500. Nothing else. It seems like Ceilometer has worked there way around it using the _lookup method for 404's (but I can't find how they return any other status codes..), and libra + tuskar have replaced the WSME error handling for something entirely custom. We're not massively interested in replacing WSME's error handling with something custom, so our plan is to just use Pecan and ignore WSME for the Designate v2 API. When it's ready, hopefully the switch won't be too painful! Thanks, Kiall Ironic is also using WSME, and has been bitten by this issue. In certain situations we want to return either a 200 or a 202, which doesn't work for the same reasons. -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] The way to use one config file with new oslo module
On 06/08/13 18:09 +0200, Emilien Macchi wrote: Hi, Since https://review.openstack.org/#/c/36476/ has been merged, heat could use only one configuration file : heat.conf instead of heat-engine.conf, heat-api.conf, etc. I would like your thoughts about deleting old configuration files, since that could break something in the CI. I already made a first patch here : https://review.openstack.org/#/c/40257/ But let's discuss about it before continuing to work on this patch. +1, we can be a bit more consistant with the other projects. Better do this sooner rather than later. -Angus Cheers, -- Emilien Macchi # OpenStack Engineer // eNovance Inc. http://enovance.com // ā emil...@enovance.com ā +33 (0)1 49 70 99 80 // 10 rue de la Victoire 75009 Paris ___ 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] [Heat] The way to use one config file with new oslo module
On 08/07/2013 12:08 PM, Angus Salkeld wrote: On 06/08/13 18:09 +0200, Emilien Macchi wrote: Hi, Since https://review.openstack.org/#/c/36476/ has been merged, heat could use only one configuration file : heat.conf instead of heat-engine.conf, heat-api.conf, etc. I would like your thoughts about deleting old configuration files, since that could break something in the CI. I already made a first patch here : https://review.openstack.org/#/c/40257/ But let's discuss about it before continuing to work on this patch. +1, we can be a bit more consistant with the other projects. Better do this sooner rather than later. I'm keen for the transition to progress. A devstack commit which switches over to heat.conf.sample would be useful. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Blueprint for Nova native image building
On Tue, Aug 6, 2013 at 9:23 PM, Ian Mcleod imcl...@redhat.com wrote: Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be further customized by other tools that expect an existing image as an input, such as disk image builder. Blueprint - https://blueprints.launchpad.net/nova/+spec/base-image-creation Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI If this is a topic that interests you, please have a look (the spec is not very long) and join the conversation. Please note that this blueprint follows on from proof of concept work for native image building discussed on this list in April: http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html In one of the cloud product that I work on has same feature and when I looked at OpenStack I was thinking why we should rely on third party tool for this and do not have OpenStack backed solution. I think I can help to add autoyast. I have not tried this tool yet. I will try it and let you know. Thanks and Regards Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] nova-api won't start in devstack
Edgar Magana emag...@plumgrid.com writes: I found the problem: python-boto and python-cmd2 had the wrong version. I have already installed those libraries. Remove them, they are installed using pip (at least python-cmd2) I believe. Thanks and Regards Noorul Cheers, Edgar From: Edgar Magana emag...@plumgrid.com Date: Tuesday, August 6, 2013 11:33 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: [Nova] nova-api won't start in devstack I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File /usr/local/bin/nova-api, line 10, in module 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/cmd/api.py, line 51, in main 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api, use_ssl=should_use_ssl) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/service.py, line 311, in __init__ 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/wsgi.py, line 488, in load_app 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name, **kw) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2013-08-06 11:28:28.938 TRACE nova return context.create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1]) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object, context.global_conf, **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory 2013-08-06 11:28:28.938 TRACE nova return cls() 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/compute/__init__.py, line 141, in __init__ 2013-08-06 11:28:28.938 TRACE nova super(APIRouterV3, self).__init__(init_only) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 323, in __init__ 2013-08-06 11:28:28.938 TRACE nova missing_apis=missing_core_extensions) 2013-08-06 11:28:28.938 TRACE nova CoreAPIMissing: Core API extensions are missing: set(['flavors', 'limits',
Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
On 7 August 2013 11:22, Jay Buffington m...@jaybuff.com wrote: ln -s /usr/lib64/python2.6/site-packages/libvirtmod_qemu.so $(VENV)/lib/python2.6/site-packages/ Why isn't libvirt-python on pypi? AFAICT, nothing is stopping us from uploading it. Maybe we should just stick it on there and this issue will be resolved once and for all. Please please oh yes please :). -Rob -- 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
Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
On 6 August 2013 05:03, Dean Troyer dtro...@gmail.com wrote: * Continue to factor the prereq setup out of stack.sh such that requirements.txt is satisfied one way or another before it begins to install OpenStack. tools/install_prereqs.sh and tools/install_pip.sh are the prototypes for this. Each distro gets a chance to get it right here whether by package or by PyPI. I think in the devstack context this makes a lot of sense. As you know I kicked bindep of to aid in making this approach shareable in the same way PyPI dependencies are. One thing thats tricky there is /reliably/ mapping back from distro package versions to PyPI (and vice versa). -Rob -- 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
Re: [openstack-dev] [Nova] nova-api won't start in devstack
One of the things that has definitely shaken out of global requirements in the devstack gate is that our global requirements list was just wrong. There are about 10 changes in flux that bump up the minimum versions of various packages in global requirements to get us past things. If you find an environment where an old version of a pip is causing you to not function correctly, now is the time to bring that up, so we can fix global requirements and get everything working again. -Sean On 08/06/2013 09:35 PM, Noorul Islam K M wrote: Edgar Magana emag...@plumgrid.com writes: I found the problem: python-boto and python-cmd2 had the wrong version. I have already installed those libraries. Remove them, they are installed using pip (at least python-cmd2) I believe. Thanks and Regards Noorul Cheers, Edgar From: Edgar Magana emag...@plumgrid.com Date: Tuesday, August 6, 2013 11:33 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: [Nova] nova-api won't start in devstack I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File /usr/local/bin/nova-api, line 10, in module 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/cmd/api.py, line 51, in main 2013-08-06 11:28:28.938 TRACE nova server = service.WSGIService(api, use_ssl=should_use_ssl) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/service.py, line 311, in __init__ 2013-08-06 11:28:28.938 TRACE nova self.app = self.loader.load_app(name) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/wsgi.py, line 488, in load_app 2013-08-06 11:28:28.938 TRACE nova return deploy.loadapp(config:%s % self.config_path, name=name) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 247, in loadapp 2013-08-06 11:28:28.938 TRACE nova return loadobj(APP, uri, name=name, **kw) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 272, in loadobj 2013-08-06 11:28:28.938 TRACE nova return context.create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/urlmap.py, line 160, in urlmap_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(app_name, global_conf=global_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 144, in invoke 2013-08-06 11:28:28.938 TRACE nova **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/auth.py, line 59, in pipeline_factory 2013-08-06 11:28:28.938 TRACE nova app = loader.get_app(pipeline[-1]) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 350, in get_app 2013-08-06 11:28:28.938 TRACE nova name=name, global_conf=global_conf).create() 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 710, in create 2013-08-06 11:28:28.938 TRACE nova return self.object_type.invoke(self) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py, line 146, in invoke 2013-08-06 11:28:28.938 TRACE nova return fix_call(context.object, context.global_conf, **context.local_conf) 2013-08-06 11:28:28.938 TRACE nova File /usr/lib/python2.7/dist-packages/paste/deploy/util.py, line 56, in fix_call 2013-08-06 11:28:28.938 TRACE nova val = callable(*args, **kw) 2013-08-06 11:28:28.938 TRACE nova File /opt/stack/nova/nova/api/openstack/__init__.py, line 251, in factory 2013-08-06 11:28:28.938 TRACE nova return cls() 2013-08-06 11:28:28.938 TRACE nova File
Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
On 08/06/2013 11:14 PM, Robert Collins wrote: On 7 August 2013 11:22, Jay Buffington m...@jaybuff.com wrote: ln -s /usr/lib64/python2.6/site-packages/libvirtmod_qemu.so $(VENV)/lib/python2.6/site-packages/ Why isn't libvirt-python on pypi? AFAICT, nothing is stopping us from uploading it. Maybe we should just stick it on there and this issue will be resolved once and for all. Please please oh yes please :). It doesn't build from a setup.py, so there is nothing to upload. It's built as part of the libvirt C library, and its build depends on scripts that autogenerate source code from the C library headers (think swig, except homegrown) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Validating Flavor IDs
It seems like this is a bug in python-novaclient. I believe the recent change to enforce that flavor ids are either int-like or uuid-like may have been made in error. At minimum, I believe it is backwards-incompatible, despite being part of a minor point release (changed from 2.13 to 2.14). See https://review.openstack.org/#/c/29086/ for the review where this behavior was changed. See also https://bugs.launchpad.net/python-novaclient/+bug/1209060 On Thu, Jul 25, 2013 at 10:36 AM, Vishvananda Ishaya vishvana...@gmail.comwrote: The data type is string. Vish On Jul 24, 2013, at 1:41 AM, Karajgi, Rohit rohit.kara...@nttdata.com wrote: Hi, Referring to https://bugs.launchpad.net/nova/+bug/1202136, it seems that the novaclient validates the flavor ID to be either an integer or a UUID string. This check does not exist in Nova, so currently strings are also accepted as flavor IDs by Nova when direct restful API calls are made. What should the data type of a flavor's ID be? -Rohit __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ 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] [Heat] The way to use one config file with new oslo module
Excerpts from Emilien Macchi's message of 2013-08-06 09:09:08 -0700: Hi, Since https://review.openstack.org/#/c/36476/ has been merged, heat could use only one configuration file : heat.conf instead of heat-engine.conf, heat-api.conf, etc. I would like your thoughts about deleting old configuration files, since that could break something in the CI. I already made a first patch here : https://review.openstack.org/#/c/40257/ But let's discuss about it before continuing to work on this patch. Cheers, Does oslo.config or anything in oslo-incubator give us some help with deprecating old config files? We haven't had a release with the current layout, which was done somewhat aggressively because grizzly's Heat wasn't really integrated. But I don't like the idea of moving config files that have been in place for a long time without giving users some heads up about the move. As for removing the old sample confs, I am all for it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Cinder] Guest Assisted Snapshots
On Tue, Aug 6, 2013 at 7:25 PM, Russell Bryant rbry...@redhat.com wrote: On 08/06/2013 06:55 PM, John Griffith wrote: On Tue, Aug 6, 2013 at 4:05 PM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: Greetings, The following blueprint is targeted at Havana. I was reading over the design notes today. I wanted to check on the status of this as well as discuss some of the design details. https://wiki.openstack.org/wiki/Cinder/GuestAssistedSnapshotting https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots As a quick overview, the purpose of this is to provide the ability to do volume snapshots for certain volume types that do not support it internally, such as the GlusterFS or NFS drivers. Some comments/questions ... On the Nova side, the wiki page lists adding an API to snapshot all attached volumes at once. This seems fine, but I would personally put it at a lower priority than just making basic snapshots work. The Nova patch I've seen come by so far [1] was for this API, but like I said, I would just come back to this once regular snapshots work. +1 from me on this for sure The page also indicates that a snapshot request through the Cinder API will only work through if it's not attached. That seems fairly undesirable. Can we try to address that with the first pass? It seems like we could do something like: on the cinder side: cinder snapshot API if snapshot requires guest assist while in use, and is in use: call nova's guest assisted snapshot API else: do snapshot in cinder on the nova side: nova's new guest assisted snapshot API if volume type is a local file: do local magic to create a snapshot and call the new create-snapshot-metadata API call in cinder else: do cinder API call to do a snapshot, but potentially adding some guest assistance here (to get the filesystem in a consistent state first, for example) Part of this reminds me of my whole debate about shared FS storage mixed in Cinder to begin with. The capabilties are different, and I think mixing around this if this: do nova-; else: do cinder-xxx results in a poor end-user experience to say the least. My proposal would be to change a couple of things here: 1. As Russell suggests leave the API calls in Cinder. I don't see a strong reason why we can't have a nova driver to send requests to Compute for things like this. Even if implementation wise we're still looking at things spread between the two (which I still don't find very appealing) at least from an end-users perspective it's not so confusing as to what's going on. 2. Consider rather than using the existing cinder snapshot command we introduce something unique for this special case. This would give the ability to do what we want here and would be considered acceptable in terms of the cinder minimum qualifications requirement. I don't care what it's called, cinder snapshot-share or whatever, but it seems like it's a different semantic so should be a different call. I buy keeping a single API for snapshots (Cinder), but why should it be a new Cinder API? Is it really different from the end user's perspective? It's obviously wildly different on the backend. It requires some cooperation from nova, but it's all done with the VM still running AFAIK. So maybe that last part isn't all that necessary, but part of the reason I mention that has to do with some history. I'm pretty adamant about behavior consistency and expectations regardless of the backend (a somewhat unpopular stance with vendors). Part of the reason for this suggestion is the fact that I *believe* some of these back-ends actually require the volume be attached to an instance in order to perform the snapshot. Most of the block devices don't care and do snapshots strictly internally on the device itself. I may be wrong about how this shakes out so I'm perfectly happy to be wrong and not require an extension or new API call here. Similarly to create, I think having delete work through Nova, but not Cinder isn't ideal. Can we address that as well with a similar smart-redirect approach? Again, agree on this... having the mix between the two seems like it will just create confusion IMO. The same strategy as suggested above could work here as well. My final comment on all of this is that I'm not a huge fan of having snapshot create/delete in both the nova and cinder APIs. I can't think of a better way to accomplish this, though. We don't have a nova API only exposed internally to the deployment, and
[openstack-dev] [Neutron] Configuration of Openflow controller reachability information in OVS from Openstack
Hi, Using OVS Quantum Plugin and agent, it is possible to configure OVS with - Openflow logical switches. - Tables - Ports to the logical switches (VLAN, VXLAN, GRE etc..) OVS Agent in each compute node uses local ovs-vsctl command to configure above. But, there is no simple way for Openstack quantum to configure OVS in compute nodes with OF controller IP address, TCP Port, SSL Certificates etc.. Also, there is no mechanism today to get hold of DPID of the OVS logical switches by Openstack controller. Do you think that it is good to enhance Openstack OVS Quantum Plugin and agent to pass above information? At very high level, we are thinking to introduce following: - Configuration of OF Controller reachability information o Quantum extension API though which is used to set following: * Set of Openflow controllers - For each OF controller * IP address, Port * SSL Enabled Yes/No. * If SSL enabled o CA certificate chain to validate OF controller identification by the OVS. * Zone/Cell for which this OF controller is applicable for. o Changes to QuantumClient to configure above. o OVS Quantum Plugin to store above information in the database. o OVS Quantum Agent to Plugin communication to get hold of OF controller information. o OVS Quantum Agent to add the information in OVS using ovs-vsctl. - Generation of logical switch certificates o OVS Quantum agent requests the plugin to generate local certificate and private key for each one of the logical switches * Agent to send DPID o Plugin to generate certificate private key pair and sending them as response. o Plugin configuration file to have CA certificate to use to sign the logical switch certificates. Does that make sense? Is this work going on somewhere else? Thanks Srini ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] OVS Agent and OF bridges
Thanks Kyle. It confirms our understanding. Thanks. We would be starting this work very soon and will update. Thanks Srini -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Friday, August 02, 2013 6:30 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] OVS Agent and OF bridges On Aug 2, 2013, at 7:02 AM, Addepalli Srini-B22160 b22...@freescale.com wrote: Hi, As I understand, current OVS Quantum agent is assuming that there are two Openflow bridges (br-int and br-tun). br_tun, I think, is introduced to take care of overlay tunnels. With flow based tunnel selection and tunnel parameters definition, I think br-tun is no longer required. Removal of br-tun increases the performance as one less OF bridge in the packet path. Is there any interest in community to remove br-tun? If so, we can work on it and provide a blue print and the code. Thanks Srini Hi Srini: I am very interested in this, and I think this would be a nice performance improvement. We'd have to maintain backwards compatibility with the existing code, since only version of OVS = 1.10 have flow-based tunneling code. If you want, I'd be happy to review your BP and code for this, or even work with you on this. Thanks, Kyle ___ 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
