Re: [openstack-dev] [Neutron] IPAM reference driver status and other stuff
On Mon, Mar 23, 2015 at 9:03 AM, Salvatore Orlando sorla...@nicira.com wrote: Actually, I don't see this as a big deal or a failure. In fact, it may be quite common and useful for a given driver to store some state in its own tables (like the reference driver is doing). The primary goal is to enable alternate IPAM implementations, whether external or completely local. That goal is still achieved even with this change. So, I don't see a big problem with the IPAM driver being session-aware. Whether is a big deal or a failure it depends on one's expectation. If the expectation is to enable external IPAM backends, then I agree that this is not a big deal. However, my expectation (and I hope I'm not the only one), was to disentangle IPAM logic from the API request processing code. In this way 3rd party backend transactions would have been executed independently of the database operation for processing the API request. Also, this would have enabled us to integrate tools like taskflow (I think Pavel looked into that). And most importantly avoid long database transactions which include remote calls as well. +1. Well said. However, this is not achievable - and mostly for an oversight on our side. So we should welcome passing down the context to the driver, with the goal of removing it in the next release. I think it will be fair to assume the interface experimental for this release cycle - and stable for the next one. Agreed. It isn't the ideal situation but even if we had achieved what we were setting out to achieve it would probably still have been prudent to consider the interface experimental for Kilo. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Weekly subteam status report
Hi, Following is the subteam report for Ironic. Note that this is pulled from the weekly meeting we just had. (Normally it comes from the Ironic whiteboard[0], but the whiteboard seems to have been whitened out.) Testing (adam_g) == working on testing the API microversioning within tempest and as part of the ironicclient functional test suite. patches here, comments welcome: https://review.openstack.org/#/c/166386/ https://review.openstack.org/#/c/165665/ Bugs (dtantsur) (As of Mon Mar 23 17:19:40 UTC) Open: 148 (+3) 7 new (-3), 34 in progress (+1), 1 critical (+1), 14 high (-2) and 12 incomplete (+2) Drivers === IPA (jroll/JayF/JoshNang) -- cleaning feature has merged (in ironic k-3 and IPA). Need nova patches to merge, before it can be turned on by default. Until next week, --ruby [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] [UI] New design + Bootstrap 3
Hi, We're working on migrating Fuel UI from Bootstrap 2 to Bootstrap 3 and changing the design. It's mostly upgrade of styles and markup, but we also plan to implement some changes which are frequently requested (like making action buttons always available on top of the page). Here is markup for 3 pages: - Environment list http://94.127.68.84/files/fuel/ - Nodes tab http://94.127.68.84/files/fuel/nodes.html - Actions tab http://94.127.68.84/files/fuel/actions.html What do you think about the new design? Your feedback is welcome. -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo][TaskFlow] Proposal for new core reviewer (min pae)
+1 Congrats Min! On Mon, Mar 23, 2015 at 10:40 AM, Joshua Harlow harlo...@outlook.com wrote: Greetings all stackers, I propose that we add Min Pae[1] to the taskflow-core team[2]. Min has been actively contributing to taskflow for a while now, both in helping prove taskflow out (by being a user via the project that he is using it in @ https://wiki.openstack.org/wiki/Cue) and helping with the review load when he can. He has provided quality reviews and is doing an awesome job with the various taskflow concepts and helping make taskflow the best library it can be! Overall I think he would make a great addition to the core review team. Please respond with +1/-1. Thanks much! -- Joshua Harlow It's openstack, relax... | harlo...@yahoo-inc.com [1] https://launchpad.net/~sputnik13 [2] https://wiki.openstack.org/wiki/TaskFlow/CoreTeam __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
An integer index doesn't do it for me. Maybe I'm the only one. It is part of an IP address. It isn't a new concept to think about the network and host parts of an IP address separately. Why would we change the notation from dotted quad (ipv4) to integer just because we mask out the network part? Am I alone in this? Carl On Fri, Mar 20, 2015 at 3:34 PM, Kevin Benton blak...@gmail.com wrote: What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)
On 17:23 Mon 23 Mar , ClaytonLuce, Timothy wrote: I disagree with your assertion that NetApp has ignored this for a year and we are being inconsiderate of the community. The specific drivers (FC) we are discussing were added in the Kilo-1 period, so since Dec. and are net new drivers. All other NetApp drivers have had corresponding CI in place and operational. You're failing to understand the point, which is why you're in this mess to begin with. Try listening. We've been talking about CI's for a year. We started talking about CI deadlines in August. If you post a driver for Kilo, it was communicated that you're required to have a CI by the end of Kilo [1][2][3][4][5][6][7][8]. This should've been known by your engineers regardless of when you submitted your driver. NetApp posted a driver in Kilo, with no CI done, and no clear prioritization to get it done in time. I recommend you spend less time whining, own up, and take care of things so we can revisit things in RC. [1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Deadlines [2] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html [3] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html [4] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html [5] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html [6] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html [7] - http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html [8] - http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][neutron] Moving network api test development to Neutron repo
On Tue, Mar 17, 2015 at 10:22:50PM +0100, Salvatore Orlando wrote: With the API tests being now available in the neutron repository - and being actively developed, I would also mandate in reviews that API tests are provided in lieu of the usual unit tests which at the end of the day do what the API tests are supposed to do. ++ This will provide better validation, and perhaps might finally allow us to tear down the unit test non-sense we had so far. yay! It's with great shame that I must admit I introduce it as a quick way to test all plugins in Folsom. But I never expected that contributors would start building on that. Hopefullly we could start having unit tests which do what unit tests are supposed to do - white-box testing methods to provide maximum coverage and validate their behaviour with different input values. Big ++ from me. We need to make similar changes in Nova-land. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts
On Wed, Mar 18, 2015 at 8:15 AM, Sean M. Collins s...@coreitpro.com wrote: On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote: In the IPv6 meeting yesterday you mentioned doing this with an extension rather than modifying the core API. Could you go into some detail about how you see this extension looking? The easiest, is to evaluate the REST API that is being worked on by the subnet allocation spec: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html#rest-api-impact Since it also solves the issue of the CIDR being a required attribute in the subnet-create call. My recollection was that the subnet create for a PD subnet would use a specially configured subnet pool id for PD and no cidr. The subnet pool This was to allow both are efforts to continue with very little dependency between them but also be interoperable. It looks like it has diverged a bit from this resolution. This was a face-to-face discussion without any log. But, it looks like this made it in to the spec [1]. Carl [1] https://review.openstack.org/#/c/93054/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Tomorrow's IPv6 subteam meeting
Hi, My apologies for the short notice, but I will not be able to run the IPv6 subteam meeting tomorrow. If one of the attendees who has items to discuss would like to run the meeting in my absence, that would be great! -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Mon, Mar 23, 2015 at 4:23 PM, Kevin Benton blak...@gmail.com wrote: How would you represent that you want the last address in a /26 network if you don't know what address range you are getting? 0.0.0.63? That seems pretty confusing when the resulting address turns out to be 192.168.10.191. It isn't a new concept to think about the network and host parts of an IP address separately. Definitely, but with small subnets like the example above, it is impossible to know the absolute numbers for the host portion of the address. It's about setting the right expectation for the caller. Specifying '0.0.0.63' implies the caller is going to get something back that ends in '63', which is only true some of the time. By using 'ip_index', I was trying to convey that you are getting something counted from the start of whatever is chosen, rather than getting a specific address ending. I see what you're saying but it still doesn't do it for me. To me, 0.0.0.63 didn't say that I'd get something ending in .63. I know that I can get something ending in .127, .191, or .255. Also, I don't think that a raw integer like 63 would do any better at setting the expectation. I bet the same users who would be surprised by one would be surprised by the other. My vote would still be to use the dotted-quad notation. When working with ipv4 addresses, one must understand that the address is a 32-bit number. Dotted quad is just the familiar format for seeing them but, no matter the format, the concept is the same. The same is true for the host part. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
I don't think they would be surprised if we call it offset or index. To me, 0.0.0.63 didn't say that I'd get something ending in .63. Perhaps this is just a difference in backgrounds then. Even though I'm work on network stuff all of the time, when I see that it's not obvious that it will be masked with the inverse subnet mask to get the host bits and then combine it with the network to get the real address. Do you have some examples where this syntax is used elsewhere? Ignoring the usability concern since that might just be an issue with me, there are two other reasons that still make an integer preferable to me. First, the dotted-quad notation unnecessarily ties it to IPv4. If this is going to work for IPv6 subnets at some point, we would need to support both formats, each with their own validation logic, even though they are ultimately representing the same idea. Second, using an integer could allow negatives to make asking for the last address in the subnet as simple as '-1' instead of making the user calculate it out. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] updated Fedora Atomic image available - needs testing
Note to community, The various patches needed to enable the fedora-21-atomic-2 image with k8s v0.11 are merged after multiple functional tests. You will need to rebuild your devstack environment with a fresh pull if you are developing Magnum. Enjoy :) On 3/22/15, 8:10 AM, Adrian Otto adrian.o...@rackspace.com wrote: Also, Please track any progress in this task: https://bugs.launchpad.net/magnum/+bug/1434468 If any Magnum updates are needed, link them to that bug ticket, please. Also, it would be nice to see an update on this here on this thread as well. Adrian On Mar 20, 2015, at 8:33 AM, Steven Dake (stdake) std...@cisco.com wrote: Hey folks, I have manually updated the Fedora 21 Atomic image via rpm-ostree upgrade. This image includes kubernetes 0.11 which some people have said is required to use kubectl with current Magnum master. I don¹t have time for the next week to heavily test, but if someone could run this image through testing with Magnum, I¹d appreciate it. https://fedorapeople.org/groups/heat/kolla/fedora-21-atomic-2.qcow2 _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
I just think that we might bury this discussion considering what Carl said, and that I agree with. So far we don't even know if we'll ever need this feature. When a concrete use case will come for asking things like: gimme a /22 Ipv4 network and make sure I have a pool spanning from the 1st to the 444th address, and that the gateway IP is the 555th address, then we'll think about that. Just for the sake of it, in the example above I've used Kevin's proposed notation, but simply because it's a bit more natural to me. I frankly believe both address-index and relative network address not that good from a usability perspective, but probably in this case there's just no way to ensure good API UX. Salvatore On 24 March 2015 at 00:36, Kevin Benton blak...@gmail.com wrote: I don't think they would be surprised if we call it offset or index. To me, 0.0.0.63 didn't say that I'd get something ending in .63. Perhaps this is just a difference in backgrounds then. Even though I'm work on network stuff all of the time, when I see that it's not obvious that it will be masked with the inverse subnet mask to get the host bits and then combine it with the network to get the real address. Do you have some examples where this syntax is used elsewhere? Ignoring the usability concern since that might just be an issue with me, there are two other reasons that still make an integer preferable to me. First, the dotted-quad notation unnecessarily ties it to IPv4. If this is going to work for IPv6 subnets at some point, we would need to support both formats, each with their own validation logic, even though they are ultimately representing the same idea. I think this is the plan. So far we've seen only dotted-quad examples for simplicity I guess Second, using an integer could allow negatives to make asking for the last address in the subnet as simple as '-1' instead of making the user calculate it out. Just like dotted-quad notation might be usable only for people used to subnetting, masking and other IP network arithmetics, -1 would suits only developers fluent in a specific sets of languages... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))
On 21:51 Mon 23 Mar , Rochelle Grober wrote: I’d like to suggest that the myriad wiki pages and spreadsheets for Third Party CI also be consolidated to a more manageable count. Just looking for maintainers contact, you can find information (often conflicting) in Stackalytics, on the ThirdPartyDrivers page, on the Cinder PTL’s google doc and who knows where else for the Neutron maintainers. Even finding which tests to run takes linking through a number of Cinder wiki pages. The teams have done a great job documenting a process that started out as lore, but I think the beginning of L would be a great time to revisit and reorganize the documentation for clarity, conciseness and single locations (version controlled) of critical information. More than happy to update my doc. My doc was purely for me to expose a non-editable doc of what I was seeing since I made myself the point of contact for Cinder CI's. My spreadsheet came before the thirdparty CI maintainer wiki page had any useful information on it. I got the contacts from the git logs of the people who actually worked on the drivers. I also was dealing with cases where a vendor hired an outside company to do their driver, which made things difficult for contact. The one wiki page people should pay attention to is the Cinder Third Party wiki page which now has a link to the status page: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices
Neutron cores, I have submitted the change [1] which is related to the thread [2] in January. Unfortunately it did not attract the interest of many core reviewers, and only time has passed. Now it is pointed that it may need FFE/SSE, and the opinion of the core is a bit divided about implementation. Sorry for raising this too late. But I believe this is a valuable change. So I would like support for this change to be merged. [1] https://review.openstack.org/#/c/147032/ [2] http://lists.openstack.org/pipermail/openstack-dev/2015-January/053782.html Thanks. -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))
As an Engineer running the NetApp CI, I thought it would be a good time to chime in here. While I have many opinions around this whole process, I will try my best to avoid any judgement and minimize ratholes. Over the past year, we have implemented a scalable CI system that is now running tests against 5 NetApp drivers for every patch (including stable branches). We have already prevented numerous bugs, some that would completely break OpenStack/Netapp integrations and other times we caught issues with the gate before it had time to break. We promptly worked with the code contributors in each of those cases. We have run over 50k test runs in total. Now I realize *those* CI tests have nothing to do with the FibreChannel drivers specifically, however, it took significant resources to get where we are now and CI has been our top priority. In the case of FC, we do test it regularly but atm we only have one FC capable server and 2 FC capable storage controllers. We have been working diligently with IT to acquire more for CI use but as most of you know, FC gear is not cheap and IT can take time. I would agree that we haven’t been panicking and calling IT every day at 8am under the belief that the community was aware of our situation and was ok with these drivers taking a bit longer. I might add that the FC drivers are just a wrapper around our iscsi drivers (the only difference being the zoning decorator). Now enough about NetApp, I wish folks would consider their perspective on the situation. It’s a huge ask to implement a CI system that tests every patch and not everyone has unlimited resources. Third party CI systems should be a huge deal for the third party, they should care way more than Cinder core. Although I understand Cinder not wanting deployers to attempt to use broken code in their project, I am certain a vendor does not want broker integration. Given the nights and weekends I have spent on third party CI, I would appreciate some empathy on the matter. I’m sure there are plenty of other folks that would agree. Please ask me any questions out right and I will give you an answer. I may have been confused but I was under the impression that NetApp FC had an exception to the deadline given the many conversations that had occurred. -Alex On Mon, Mar 23, 2015 at 6:30 PM, Mike Perez thin...@gmail.com wrote: On 21:51 Mon 23 Mar , Rochelle Grober wrote: I’d like to suggest that the myriad wiki pages and spreadsheets for Third Party CI also be consolidated to a more manageable count. Just looking for maintainers contact, you can find information (often conflicting) in Stackalytics, on the ThirdPartyDrivers page, on the Cinder PTL’s google doc and who knows where else for the Neutron maintainers. Even finding which tests to run takes linking through a number of Cinder wiki pages. The teams have done a great job documenting a process that started out as lore, but I think the beginning of L would be a great time to revisit and reorganize the documentation for clarity, conciseness and single locations (version controlled) of critical information. More than happy to update my doc. My doc was purely for me to expose a non-editable doc of what I was seeing since I made myself the point of contact for Cinder CI's. My spreadsheet came before the thirdparty CI maintainer wiki page had any useful information on it. I got the contacts from the git logs of the people who actually worked on the drivers. I also was dealing with cases where a vendor hired an outside company to do their driver, which made things difficult for contact. The one wiki page people should pay attention to is the Cinder Third Party wiki page which now has a link to the status page: https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Steven, On Mon, Mar 23, 2015 at 11:11 PM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient Hi All, This is to have a discussion on the blueprint for implementing python-k8client for magnum. https://blueprints.launchpad.net/magnum/+spec/python-k8sclient I have committed the code generated by swagger-codegen at https://review.openstack.org/#/c/166720/. But I feel the quality of the code generated by swagger-codegen is not good. Some of the points: 1) There is lot of code duplication. If we want to generate code for two or more versions, same code is duplicated for each API version. 2) There is no modularity. CLI code for all the APIs are written in same file. So, I would like your opinion on this. How should we proceed further? Madhuri, First off, spectacular that you figured out how to do this! Great great job! I suspected the swagger code would be a bunch of garbage. Just looking over the review, the output isn’t too terribly bad. It has some serious pep8 problems. Now that we have seen the swagger code generator works, we need to see if it produces useable output. In other words, can the API be used by the magnum backend. Google is “all-in” on swagger for their API model. Realistically maintaining a python binding would be a huge job. If we could just use swagger for the short term, even though its less then ideal, that would be my preference. Even if its suboptimal. We can put a readme in the TLD saying the code was generated by a a code generator and explain how to generate the API. I have started working on it and will surely look whether some improvement can be done or not. And also will try to use it magnum. One last question. I didn’t see immediately by looking at the api, but does it support TLS auth? We will need that. I am not sure about it. I will check and let you know. Super impressed! Regards -steve Regards, Madhuri Kumari __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Regards, Madhuri Kumari __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient
Hi Hongbin, On Tue, Mar 24, 2015 at 12:37 AM, Hongbin Lu hongbin...@gmail.com wrote: Hi Madhuri, Amazing work! I wouldn't concern the code duplication and modularity issue since the codes are generated. However, there is another concern here: if we find a bug/improvement of the generated code, we probably need to modify the generator. The question is if the upstream will accept the modifications? If yes, how fast the patch will go through. I would prefer to maintain a folk of the generator. By this way, we would have full control of the generated code. Thoughts? I agree that's a concern. I will try to fix the pep8 error upstream to look how it take to push a change upstream. Thanks, Hongbin On Mon, Mar 23, 2015 at 10:11 AM, Steven Dake (stdake) std...@cisco.com wrote: From: Madhuri Rai madhuri.ra...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Monday, March 23, 2015 at 1:53 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] swagger-codegen generated code for python-k8sclient Hi All, This is to have a discussion on the blueprint for implementing python-k8client for magnum. https://blueprints.launchpad.net/magnum/+spec/python-k8sclient I have committed the code generated by swagger-codegen at https://review.openstack.org/#/c/166720/. But I feel the quality of the code generated by swagger-codegen is not good. Some of the points: 1) There is lot of code duplication. If we want to generate code for two or more versions, same code is duplicated for each API version. 2) There is no modularity. CLI code for all the APIs are written in same file. So, I would like your opinion on this. How should we proceed further? Madhuri, First off, spectacular that you figured out how to do this! Great great job! I suspected the swagger code would be a bunch of garbage. Just looking over the review, the output isn’t too terribly bad. It has some serious pep8 problems. Now that we have seen the swagger code generator works, we need to see if it produces useable output. In other words, can the API be used by the magnum backend. Google is “all-in” on swagger for their API model. Realistically maintaining a python binding would be a huge job. If we could just use swagger for the short term, even though its less then ideal, that would be my preference. Even if its suboptimal. We can put a readme in the TLD saying the code was generated by a a code generator and explain how to generate the API. One last question. I didn’t see immediately by looking at the api, but does it support TLS auth? We will need that. Super impressed! Regards -steve Regards, Madhuri Kumari __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Regards, Madhuri Kumari __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?
On Mon, Mar 23, 2015 at 09:35:50PM +, Jeremy Stanley wrote: On 2015-03-23 15:15:18 -0400 (-0400), Jay Pipes wrote: [...] I don't want it suppressed. I want the use of API extensions and the extension framework(s) to be completely dropped for all future API-affecting work. [...] Perhaps controversial, but would it be worthwhile to propose to the Defcore working group that future compliance requirements include the absence of extensions to officially covered APIs? I don't understand what you're getting at, Jeremy. Could you elaborate? What do extensions have to do with future compliance requirements? Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] About Sahara EDP New Ideas for Liberty
Hi Andrew. Thanks for response. My reply in line. From: Andrew Lazarev [mailto:alaza...@mirantis.com] Sent: Saturday, March 21, 2015 12:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] About Sahara EDP New Ideas for Liberty Hi Weiting, 1. Add a schedule feature to run the jobs on time: This request comes from the customer, they usually run the job in a specific time every day. So it should be great if there is a scheduler to help arrange the regular job to run. Looks like a great feature. And should be quite easy to implement. Feel free to create spec for that. [Weiting] We are working on the spec and the bp has already been registered in https://blueprints.launchpad.net/sahara/+spec/enable-scheduled-edp-jobs. 2. A more complex workflow design in Sahara EDP: Current EDP only provide one job that is running on one cluster. Yes. And ability to run several jobs in one oozie workflow is discussed on every summit (e.g. 'coordinated jobs' at https://etherpad.openstack.org/p/kilo-summit-sahara-edp). But for now it was not a priority But in a real case, it should be more complex, they usually use multiple jobs to calculate the data and may use several different type clusters to process it.. It means that workflow manager should be on Sahara side. Looks like a complicated feature. But we would be happy to help with designing and implementing it. Please file proposal for design session on ongoing summit. Are you going to Vancouver? [Weiting] I’m not sure I will be there because the plan is still not ready yet. We are also looking for some customer’s real case in big data area and see how they are using data processing in current environment. However, for any idea we can update later. Another concern is about Spark, for Spark it cannot use Oozie to do this. So we need to create an abstract layer to help to implement this kind of scenarios. If workflow is on Sahara side it should work automatically for all engines. [Weiting] Yes, agree. Thanks, Andrew. On Sun, Mar 8, 2015 at 3:17 AM, Chen, Weiting weiting.c...@intel.commailto:weiting.c...@intel.com wrote: Hi all. We got several feedbacks about Sahara EDP’s future from some China customers. Here are some ideas we would like to share with you and need your input if we can implement them in Sahara(Liberty). 1. Add a schedule feature to run the jobs on time: This request comes from the customer, they usually run the job in a specific time every day. So it should be great if there is a scheduler to help arrange the regular job to run. 2. A more complex workflow design in Sahara EDP: Current EDP only provide one job that is running on one cluster. But in a real case, it should be more complex, they usually use multiple jobs to calculate the data and may use several different type clusters to process it. For example: Raw Data - Job A(Cluster A) - Job B(Cluster B) - Job C(Cluster A) - Result Actually in my opinion, this kind of job could be easy to implement by using Oozie as a workflow engine. But for current EDP, it doesn’t implement this kind of complex case. Another concern is about Spark, for Spark it cannot use Oozie to do this. So we need to create an abstract layer to help to implement this kind of scenarios. However, any suggestion is welcome. Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On 03/23/2015 09:20 PM, Deepak Shetty wrote: Hi all, I was wondering if there was a neat way to override the settings file present in the devstack plugin stackforge project. For eg: stackforge/devstack-plugin-glusterfs I plan to use `enable_plugin glusterfs repo` in my local to setup GlusterFS backend for openstack But I am forced to use the settings that the above repo has. Can you explain more what you mean? The glusterfs plugin should have access to anything defined by the local.conf? -i __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On 2015-03-21 02:57, Assaf Muller wrote: Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. i'm using it in CI/test environment, where i need to connect to the vm and the control plane at the same time. (vm network is gre) I'm asking because use_namespaces complicates Neutron code for what I gather is an option that has not been relevant for years. I'd like to deprecate the option for Kilo and remove it in Liberty. in production i use namespaces, but only because is the default. we have many clouds and none of them share the same ip range. as other have said, i think is better to have less moving parts, namespaces had problems with kernel and iproute2 before and may have problems again -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?
2015-03-21 23:31 GMT+08:00 Monty Taylor mord...@inaugust.com: I would vote that we not make this pleasant or easy for vendors who are wanting to add a feature to the API. As a person who uses several clouds daily, I can tell you that a vendor chosing to do that is VERY mean to users, and provides absolutely no value to anyone, other than allowing someone to make a divergent differentiated fork. Just don't do it. Seriously. It makes life very difficult for people trying to consume these things. The API is not the place for divergence. But, what if some vendors have already implemented some on-premise features using the Nova extension mechanism, to achieve strategy of product differentiation themselves based on OpenStack? IMHO, the DefCore has already give some advise about what's OpenStack(you must pass through a lot of predefined tests). If vendors can not provide extra features by themselvs(which is backwards compatible), they will lose a little competitiveness on their product. I'm not very sure whether or not my understanding is right, but I really concern about the what's the right direction for the vendors or providers. Regards! --- Lingxian Kong __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] how to handle vendor-specific API microversions?
On 03/23/2015 03:28 AM, John Garbutt wrote: We are not stopping vendor specific API endpoints, that appear separately in the keystone catalog. Certainly, thats where I hope things that would never go upstream will move to. How would that be expected to work for things where it's fundamentally just a minor extension to an existing nova API? (Exposing additional information as part of nova show, for example.) Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] Overriding settings file for devstack plugin
On Tue, Mar 24, 2015 at 8:36 AM, Ian Wienand iwien...@redhat.com wrote: On 03/23/2015 09:20 PM, Deepak Shetty wrote: Hi all, I was wondering if there was a neat way to override the settings file present in the devstack plugin stackforge project. For eg: stackforge/devstack-plugin-glusterfs I plan to use `enable_plugin glusterfs repo` in my local to setup GlusterFS backend for openstack But I am forced to use the settings that the above repo has. Can you explain more what you mean? The glusterfs plugin should have access to anything defined by the local.conf? For eg: Look at [1], it configures 2 backends (glusterfs and lvm), but I just need glusterfs backend Also CINDER_GLUSTERFS_SHARES is hardcoded to be present locally, in my devstack setup i might have different gluster volume names and/or IP address I would like ability to change these while I use the enable_plugin apporach to setup devstack w/ GlusterFS per my local glusterfs setup [1]: https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings thanx, deepak __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
