Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core
+1 On 01/14/2015 12:14 PM, Clint Byrum wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [horizon] static files handling, bower/
On 1/14/15 11:49 AM, Michael Krotscheck wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. I think Oracle's got enough money to support Node.js on SPARC. How is money relevant here? I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Under no circumstances am I refusing to use it. I stated in my original email ... ---8--- For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. ---8--- ... that Node.js is an issue because we can not use it. Not because we don't WANT to use it. This is an important distinction that you seem to have missed. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? I'm sorry, what? Python is fully supported on Solaris (both x86 and SPARC). This discussion has nothing whatsoever to do with the 'language-du-jour'. I continued this thread because we came across the and the blueprint suggesting moving to using Bower rather than XStatic and I'm attempting to voice the concerns we have for moving to Node. It may be that nothing can be done in the short term (for Kilo) with the long term action being to get Node ported to SPARC. -Drew __ 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] noVNC disabled by default?
If you rewrite the noNVC installation in devstack to work from a release URL that includes the released version on it, I think that would be sufficient to turn it back on. Again, ideally this should be in distros, but I think we could work on doing release installs until then, especially if the install process is crisp. I'll see if I can find some time to do this. I've been rather busy with a few other things (chiefly, getting my Nova patch series all ready and tested before next week). I am looking at the upstream release tarball right now though, and don't see and INSTALL instructions in it. So lets see what the devstack patch would look like to do the install. The bulk of noVNC is a series of Javascript and HTML files. Installation may differ depending on how you plan on serving the noVNC files themselves. That's the main reason why there's no INSTALLATION file for noVNC. That being said, it is not uncommon for people to serve noVNC using websockify's built-in web server -- this is what the utils/launch.sh script does. Fedora places the noVNC source in /usr/share/novnc, so I think that's a reasonable place for devstack to install (mainly just unzip the sources) noVNC for the time being. Thoughts? __ 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][AdvancedServices][telco] Confusion about the solution of the service chaining!
- Original Message - From: Kyle Mestery mest...@mestery.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org On Wed, Jan 7, 2015 at 6:25 AM, lv.erc...@zte.com.cn wrote: Hi, I want to confirm that how is the project about Neutron Services Insertion, Chaining, and Steering going, I found that all the code implementation about service insertion、service chaining and traffic steering list in JunoPlan were Abandoned . https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan and I also found that we have a new project about GBP and group-based-policy-service-chaining be located at: https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-abstraction https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining so I'm confused with solution of the service chaining. We are developing the service chaining feature, so we need to know which one is the neutron's choice. Are the blueprints about the service insertion, service chaining and traffic steering list in JunoPlan all Abandoned ? Service chaining isn't in the plan for Kilo [1], but I expect it to be something we talk about in Vancouver for the Lxxx release. The NFV/Telco group has been talking about this as well. I'm hopeful we can combine efforts and come up with a coherent service chaining solution that solves a handful of useful use cases during Lxxx. Thanks, Kyle [1] http://specs.openstack.org/openstack/neutron-specs/priorities/kilo-priorities.html In the hope of 'crossing the streams' on this the discussion in the context of the telco working group resulted in this etherpad: https://etherpad.openstack.org/p/kKIqu2ipN6 This was also raised on the list here: http://lists.openstack.org/pipermail/openstack-dev/2015-January/053841.html Thanks, Steve __ 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] [TripleO] nominating James Polley for tripleo-core
+1 On 01/14/2015 02:26 PM, Gregory Haynes wrote: Excerpts from Clint Byrum's message of 2015-01-14 18:14:45 +: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! Definite +1. -Greg __ 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] [nova] Networks are not cleaned up in build failure
On 01/14/2015 12:57 PM, Murray, Paul (HP Cloud) wrote: Hi All, I recently experienced failures getting images from Glance while spawning instances. This step comes after building the networks in the guild sequence. When the Glance failure occurred the instance was cleaned up and rescheduled as expected, but the networks were not cleaned up. On investigation I found that the cleanup code for the networks is in the compute manager’s _/do_build_run/_instance() method as follows: # NOTE(comstud): Deallocate networks if the driver wants # us to do so. if self.driver.deallocate_networks_on_reschedule(instance): self._cleanup_allocated_networks(context, instance, requested_networks) The default behavior in for the deallocate_networks_on_schedule() method defined in ComputeDriver is: def deallocate_networks_on_reschedule(self, instance): Does the driver want networks deallocated on reschedule? return False Only the Ironic driver over rides this method to return True, so I think this means the networks will not be cleaned up for any other virt driver. Is this really the desired behavior? Yes. Other than when using Ironic there is nothing specific to a particular host in the networking setup. This means it is not necessary to deallocate and reallocate networks when an instance is rescheduled, so we can avoid the unnecessary work of doing it. If the instance goes to ERROR then the network will get cleaned up when the instance is deleted. I have filed a bug for this and plan to fix it: https://bugs.launchpad.net/nova/+bug/1410739 My initial thought is to fix this either by making the method in the base class return True or by adding the method to virt drivers returning True (I would expect the former). But I wanted to check if there is a reason for the base class behavior (and so the default behavior) to be **NOT** to clean up the networks? Paul Paul Murray Nova Technical Lead, HP Cloud +44 117 316 2527 Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as HP CONFIDENTIAL. __ 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] [TripleO] nominating James Polley for tripleo-core
Thanks for the nomination Clint (and +1s from people who have already responded) At this stage, I believe we've traditionally[1] asked[2] the potential new Core Reviewer to commit to 3 reviews per work-day. I don't feel that that's a commitment I can make at this point. It's not something I've been able to achieve in the past - I've come close over the last 30 days, but the 90 day report shows me barely above 2 per day. I think my current throughput is something I can commit to maintaining, and I'd like to think that it can grow over time; but I don't think I can commit to doing anything more than I've already been able to do. If the rest of the core reviewers think I'm still making a valuable contribution, I'm more than happy to accept this nomination. [1] At least for the last 12 months or so, since I first started working on TripleO [2] more accurately, I believe we don't usually nominate a new Core until they've demonstrated their commitment by having already sustained 3 reviews per work-day for a few months [3] http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt On Wed, Jan 14, 2015 at 6:14 PM, Clint Byrum cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [TripleO] nominating James Polley for tripleo-core
On 15/01/15 07:14, Clint Byrum wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Very well deserved. +1! -- Steve In the beginning was the word, and the word was content-type: text/plain __ 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] [horizon] function expressions vs function declarations in JavaScript
Thai, I'm still poking around at JavaScript things and did a little testing on function declarations vs function expressions. Seems Firefox is faster with function expressions by quite a bit at parse time. For reference see http://jsperf.com/mfer-function-types. I'm not suggesting what we do. I'm just sharing a data point I found surprising. I'm curious about the process for proposing changes to https://wiki.openstack.org/wiki/Horizon/Javascript. Is there any process? On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran tqt...@us.ibm.com wrote: It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it. For me, function declarations can get convoluted very fast if not use correctly. Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement. But they do have their uses when used correctly. I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions. As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much. -Matthew Farina m...@mattfarina.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Matthew Farina m...@mattfarina.com Date: 01/14/2015 07:04AM Subject: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript JavaScript has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions). In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/Javascript. Thanks, Matt __ 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] [Telco] [NFV] [neutron][advancedservices][group-based-policy] Service function chaining
- Original Message - From: Zhipeng Huang zhipengh...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi Yuriy, FYI there is a project proposal on opnfv wiki on this issue: https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Hi Zhipeng, The OPNFV project page you linked mentions that it is dependent on current development work for Policy Based Specification of Service Chaining [1] and Service Instance Registration Integration [2] targeted at the OpenStack Kilo release. I'm assuming this is in the context of the group-based-policy project - is anyone from the OPNFV side interacting with the project directly with a view to working on this? Thanks, Steve [1] https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining [2] https://blueprints.launchpad.net/group-based-policy/+spec/service-registration-and-integration On Wed, Jan 7, 2015 at 12:22 AM, yuriy.babe...@telekom.de wrote: Hi all, as discussed per last IRC meeting we prepared first thoughts on the requirements on Service Function Chaining (SFC) and relevant use-case. We have an etherpad for initial draft ideas. Later on we should move it to wiki. All comments are very welcome. https://etherpad.openstack.org/p/kKIqu2ipN6 Best, Yuriy Deutsche Telekom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Zhipeng (Howard) Huang Standard Engineer IT Standard Patent/IT Prooduct Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OpenDaylight, OpenCompute affcienado __ 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 -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform __ 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] [horizon] static files handling, bower/
Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. I think Oracle's got enough money to support Node.js on SPARC. I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Don't get me wrong: Node.js run as a server is a horrible, horrible idea, and I *like* javascript. But then, running PHP3 on a server is *also* a horrible, horrible idea, but that didn't really stop anyone 15 years ago. The same goes for lots of other languages. So let me reframe this argument a bit: If you refuse to allow us frontend developers to use node, npm, and bower, then I expect you to reciprocate and no longer use the python executable or pip to write your code, and you can only debug using wsgi. Since those fill equivalent roles in our various languages-du-jour, it seems like a perfectly fair exchange. Deal? Michael __ 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] [TripleO] nominating James Polley for tripleo-core
Excerpts from Clint Byrum's message of 2015-01-14 18:14:45 +: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! Definite +1. -Greg __ 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] Devstack failures related to q-vpn service
Can you provide more info on what failures you are seeing? Regards, PCM PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Wed, Jan 14, 2015 at 12:35 PM, Sukhdev Kapur sukhdevka...@gmail.com wrote: Hi All, I am seeing very frequent failures of devstack on our CI because of q-vpn service failures. This has happened very recently. Is this a know issue? I am tempted to disable q-vpn service on our CI to avoid this noise. I wanted to reach out to see if others are also seeing this issue. please advise.. -Sukhdev __ 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] [TripleO] nominating James Polley for tripleo-core
Excerpts from James Polley's message of 2015-01-14 12:46:37 -0800: Thanks for the nomination Clint (and +1s from people who have already responded) At this stage, I believe we've traditionally[1] asked[2] the potential new Core Reviewer to commit to 3 reviews per work-day. I don't feel that that's a commitment I can make at this point. It's not something I've been able to achieve in the past - I've come close over the last 30 days, but the 90 day report shows me barely above 2 per day. I think my current throughput is something I can commit to maintaining, and I'd like to think that it can grow over time; but I don't think I can commit to doing anything more than I've already been able to do. If the rest of the core reviewers think I'm still making a valuable contribution, I'm more than happy to accept this nomination. IMO we need to re-evaluate that requirement. None of us has done a great job at sustaining it, however as a team we've managed to at least get enough reviews done to keep the tubes flowing. I know that at one point we got really backed up, but what solved that was a combination of a few less patches getting submitted (probably because of the long wait time) and a few more reviewers being added. So having more good reviewers like yourself seems more important than having more perfect reviewers. Also the main reason for wanting people to do 3 per day is to maintain familiarity with the code. I think you've been able to remain familiar with your traditional rate just fine. __ 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] [Glance] Gentle reminder: Glance mid-cycle meetup for Kilo.
Hi, For those of you, who might have missed my previous announcement [0], please find the venue and tentative schedule for the Glance mid-cycle meetup for Kilo cycle here [1]. It asks for your participation confirmation in the list so, if you are planning to attend please do fill out the needful information. [0] http://osdir.com/ml/openstack-dev/2015-01/msg00098.html [1] https://etherpad.openstack.org/p/kilo-glance-mid-cycle-meetup Thanks again! Cheers, -Nikhil __ 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] Devstack failures related to q-vpn service
Hi All, I am seeing very frequent failures of devstack on our CI because of q-vpn service failures. This has happened very recently. Is this a know issue? I am tempted to disable q-vpn service on our CI to avoid this noise. I wanted to reach out to see if others are also seeing this issue. please advise.. -Sukhdev __ 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] API Definition Formats
On 1/13/15, 04:16, Chris Dent chd...@redhat.com wrote: On Tue, 13 Jan 2015, Ian Cordasco wrote: On 1/12/15, 17:21, Chris Dent chd...@redhat.com wrote: On Mon, 12 Jan 2015, Ian Cordasco wrote: This worked extremely well in my experience and helped improve development time for new endpoints and new endpoint versions. The documentation was also heavily used for the multiple internal clients for that API. This idea of definition formats seems like a reasonable idea (see my response to Anne over on the gabbi thread[1]) but I worry about a few things: Your response below suggests that I didn't make the point above about how I think this is a reasonable idea strongly enough. My comments were not to disparage the idea but rather to start applying some flesh on the bare bones of some concerns that might arise as people try to apply the idea. Yes, I misunderstood you. Sorry about that. * Unless you're auto generating the code from the formal defition you run into a lot of opportunities for truth to get out of sync between the definition and the implementation. The /documentation/ was used by /developers/ to build the internal clients. It was also used by the front-end developers who built the user-facing interface that consumed these APIs. Yes, that restates the problem nicely: all code always has the problem I stated: documentation (in whatever form) is highly likely to get out of sync with implementations. You made some motions towards ways to guard against this problem when you described how tests and documentation can be interlinked. Sounds great! But it doesn't entirely ameliorate the concern. So if the schemas are part of the test suite (enforcing them and ensuring that the endpoints return responses compliant with it) then we’ll catch changes that aren’t documented by the schema. Using the schema (with its examples) to document the endpoint’s request/response cycle means that the documentation of what the endpoint expects and what it returns is at the very least technically correct. Good descriptions of the endpoints and the data in the schema will only improve the generated documentation. I’m not sure how that doesn’t reduce the overhead of writing documentation for the API. * Specifying every single endpoint or many endpoints is just about as anti-REST as you can get if you're a HATEOAS believer. I suspect this line of concern is well-trod ground and not worth bringing back up, but all this stuff about versioning is meh and death to client diversity. Except that we don’t even try to achieve HATEOAS (or at least the OpenStack APIs I’ve seen don’t). If we’re being practical about it, then the idea that we have a contract between the API consumer (also read: user) and the server makes for a drastic simplification. The fact that the documentation is auto-generated means that writing tests with gabbi would be so much simpler for you (than waiting for people familiar with it to help you). We don't try to achieve HATEOAS _now_ but why should it be off the radar for things we do in the future? There's a frequent tension in the API discussions between describing and validating the existing APIs and describing a target for future improvements. I think we should be doing both. There could be room for discussion about increased hypermedia. It is _one_ of the ways to allow robust longevity of APIs. I don't personally want to open that can of worms if it has been opened many times before, but it is worth noting the option as it provides a much different technique for addressing the concerns about versioning and documentation. All that said, what you describe in the following would be nice if it can be made true and work well. I suspect I'm still scarred from WSDL and company but I'm not optimistic that culturally it can be made to work. Simple HTTP APIs wins over SOAP and pragmatic HTTP wins over true REST and JSON wins over XML because all of the latter have a flavor of flexibility and easy to diddle that does not exist in the former. The problem is social, not technical. Well I’ve only seen it used with JSON, so I’m not sure where you got XML from (or SOAP for that matter). Besides, this is a tool that will help the API developers more than it will hurt them. In-tree definitions in a (fairly) human readable format that clearly states what is accepted and generated by an endpoint means that scrutinizing Pecan and WSME isn’t necessary (until you start writing the endpoint itself). What I was expressing in that paragraph was a bit of allegoric thinking: This thing you're suggesting smells a bit like these other things that although they sounded like good ideas failed to have long-lived success all for much the same reason. I guess I should have made the implicit questions explicit: How is this formalism that you are suggesting different from those? How can we guard against the social tendency of devs who have freedom of choice to choose tools that
Re: [openstack-dev] [Keystone][Horizon] User self registration and management
Hello everyone, Thanks for the info and the feedback. Looking at our current situation, it seems unlikely we are to be switching to a federated Keystone. Is the preferred approach these days to use a federated Keystone? What we'd like to do is ideally have this service work using the Keystone API. It should fit neatly into and add missing features to the current OpenStack ecosystem, plus be easy to setup and gain access to these features for people like ourselves who are using just Keystone itself for identity. Our primary purpose with OpenStack at present is running a semi-public cloud. All our users are new or incoming so storing them in Keystone isn't an issue, plus any users on our internal idp needing to use the Cloud would ideally get signed up and managed by the project/client on the cloud they are working in. Enrique, if you have a github repo or some project pages you can point me to that would be wonderful. I'm currently in the very early stages of our proof of concept/prototype, so it would be great to see some work others have done to solve similar issues. If I can find something that works for a few of our use cases it might be a better starting point or good to see what an approach others might find useful is. I'd much rather not duplicate work, nor build something only useful for our use cases, so collaboration towards a community variant would be ideal. We will be discussing federated Keystone options, but it looks like too much complexity at present, and most of the useful features we'd want I assume won't be in until after Kilo. Cheers, Adrian Turjak On 15/01/15 03:26, Enrique Garcia wrote: Hi all, I'm working in a European project that uses OpenStack and I am using horizon and keystone for our users and organization management solution. We have some requirements similar to yours Adrian: we need to allow users to sign up themselves (with all the common functionality of email activation, forgot password) plus support authentication using OAuth2.0. We are interested in having a standard open-source solution for these problems, therefore we are really interested in participating in this discussion to see other solutions for the problem, discuss them and collaborate in making such a service. I think this kind of requirements are common to anyone wanting to use OpenStack to build a public cloud system where there is no admin to create users. In the meantime, we have developed our open-source system for them using keystone extensions and django apps which satisfy our requirements. If there is interest in them I can share and explain in more detail our approach to both problems, and help build a well-integrated solution for everyone. Cheers, Enrique Garcia Navalon 2015-01-14 13:14 GMT+01:00 David Chadwick d.w.chadw...@kent.ac.uk: Hi Adrian You might be glad to know that we have already produced a blueprint and implementation for this, based on federated keystone and Horizon. You can read the specs here https://blueprints.launchpad.net/keystone/+spec/vo-management and see a demo here http://icehouse.sec.cs.kent.ac.uk/ (However you will not be able to perform federated login without a Facebook or Google account, and you will also need the name of the VO role that you are to join, plus a secret/PIN - Contact me if you want one) Briefly, the administrator (could be keystone or domain admin) sets up a VO role, sends the details to the users who are to become members of it, along with a secret, and the user then logs in via his IdP (you can use Facebook or Google), quoting the secret and VO role. He is then enrolled in Keystone, either automatically, or pending admin approval (as a config option). The user can resign from the VO role anytime he wishes. I have updated your etherpad giving my comments regards David __ 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] [Keystone][Horizon] User self registration and management
On Jan 13, 2015, at 9:06 PM, Adrian Turjak adri...@catalyst.net.nz wrote: Hello openstack-dev, I'm wondering if there is any interest or need for an open-source user registration and management service for people using OpenStack. We're currently at a point where we need a way for users to sign up themselves, choose their own password, and request new users to be added to their project. There doesn't seem to be anything out there, and most vendors seem to have built their own systems to handle this or even their own dashboard systems that do. Horizon is built around the client tools, and your own personal token, so it can't handle creating new users. Plus Keystone doesn't really have any good way of handling temporary (unapproved) users and projects. The suggested approach seems to be to build a service to sit along Keystone, have it's own admin creds so it can create new users, and also store temp user data locally until the user is approved. Unless we can find a suitable solution for us quickly, we're likely to be developing such a service. It would ideally have a pluggable approval workflow, allowing new user requests, new project requests, creation of clients in external client database/ERP systems. Plus it would have a password reset-token system for having new users supply their password once they are approved, which would also allow existing users to request password resets. Part of our requirements are easy to integrate into Horizon, fitting neatly into the OpenStack ecosystem along other services, and being easy to update/alter once we have hierarchical multi-tenancy and if it makes some things easier. I've written up a proposal to help us define our requirements, and a copy of that is attached, and on etherpad: https://etherpad.openstack.org/p/User_Management_Service Plus I've attached a couple of diagrams, which are sadly not UML, but should give you some idea of two of the primary use cases. Is this useful to anyone? Is this entirely the wrong approach? If it is a useful service is there any interest in collaboration? Thanks for any feedback. Cheers, -Adrian Turjak I have an alternative recommendation (rather than using Keystone’s API and user-management). Keystone’s user management is lacking a lot of features a full fledged IDP (identity provider) would have. “Password reset”, “password complexity”, “password reuse”, failed login locking, etc. I would recommend that you implement this service to write to a full featured IDP (LDAP, FreeIPA, Active Directory, etc) and have Keystone hook into that more-full featured IDP. You might even find that the IDP selected has a lot of these features built-in (and/or could be fronted in a horizon panel). This recommendation comes from past experience implementing almost exactly this feature (and having it go through a number of incarnations). The benefits of using a full-fledged IDP outweigh the ease of using the Keystone API to manage users, especially since there is non-trivial engineering that will go into the project. You could also utilize an IDP that can issue SAML assertions and go with a Federated Identity setup for Keystone. Again your tool could work with an IDP that has a better set of features that Keystone’s current build-in identity (user/group) store does. Cheers, Morgan __ 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] Quota management and enforcement across projects
I'm resurrecting this thread to provide an update on this effort. I have been looking at Boson [1] as a base for starting developing a service for managing quotas and reservations [2]. Boson's model would satisfy most of the requirements for this service, and implementing additional requirements, such as hierarchical multi-tenancy should be quite easy (at least from the high-level design perspective). In the rest of this post I'm going to refer to this service both as Boson and quota service. Without going into too many technical details (which I am happy to discuss separately), the quota service will need to provide the 4 interfaces depicted in [3]. 1) The admin interface has the main purpose of keeping track of the services which use boson, registering resources to track, and managing their lifecycle. 2) The quota mgmt interface does pretty much what the quota extension does for many openstack project - manage resource limits per project/users, configure quota classes, etc. 3) The reservation interface handles the request/commit/cancel process supported by many Openstack projects 4) the usage interface provides abstraction to access the resource usage tracker and feed information to it. These interfaces are then implemented by the Boson object model, depicted in [4]. This object model is not very different from the one originally proposed for Boson [5] The proposed object model simplifies a bit the original one, merging the reservation and request concepts, as well as doing without the SpecificResource concept (at least for the moment). However, the proposed object model adds the Quota class concept and introduces the possibility of having child-parent relationships between Resources and User Info. The former will allow for applying quota to resources which are scoped within a parent resource (e.g.: static routes per logical router), whereas the latter should enable the hierarchical multi-tenancy use case. Keeping in mind the interfaces discussed in [3], the component diagram [6] can be devised. There is a distinct component for each interface - plus one component for DB management. Most of the interactions are, of course, with the DB manager. Component design should be done in a way that the various components are as independent as possible. There are some interactions among components, but they can likely be replaced with interactions with the DB manager component. The Boson quota service therefore represents a centralized endpoint for managing quotas, tracking resource usage, and performing resource reservation. Conceptually, this is all good; however, would it scale from an architectural perspective? The main problem with this approach indeed is that the quota service itself can become a huge bottleneck and add more latency to resource processing. This problem can probably be solved looking at the above mentioned interfaces as roles, and expecting Boson to scale horizontally via deployment of several instances of the service which can implement different roles, some of which can be dedicated to specific services. For instance, let's consider the example architecture depicted in [7]. Here there are 3 boson instances. One instance has the quota management and admin role and takes care of registering resources for enabled services, and setting/retrieving resource limits. It might expose its own REST API endpoint over HTTP to this aim. The other two instances have the reservation and usage roles, and communicate with client applications over AMQP. However one instance will listen only to neutron messages and the other only to nova messages (nova and neutron have been used merely as an example, the same applies to any project). This architecture will enable some sort of horizontal scale out as every project will then have its own instance for tracking resources and managing reservations. However, there will still be need for some communication across the various Boson instances. For instance in order to make a reservation, current resource limits should be fetched interacting with the management component or from the database. This overhead can be reduced considerably by introducing caches, which would result particularly effective for data such as resource limits which do not tend to change a lot over time. Finally, it is also worth noting that in theory nothing prevents us from running Boson's management interface as a Keystone 3rd party component and therefore running its API on the Keystone endpoint. Summarising, I hope I managed to convey the essentials of where I think Boson should be place in the OpenStack ecosystem, and how would it work from a conceptual and architectural perspective. I am aware that this is not exhaustive at al, but is probably the best that can be achieved in a mailing list post. Nevertheless, there are still some fundamental questions that I am trying to answer in a convincing way. 1) would anyone ever deploy a service aimed exclusively at managing quotas and
Re: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript
Wow, that IS interesting. No process required, just modify /horizon/doc/source/contributing.rst and submit a patch.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 12:20PMSubject: Re: [openstack-dev] [horizon] function expressions vs function declarations in _javascript_Thai, I'm still poking around at _javascript_ things and did a little testing on function declarations vs function expressions. Seems Firefox is faster with function expressions by quite a bit at parse time. For reference see http://jsperf.com/mfer-function-types.I'm not suggesting what we do. I'm just sharing a data point I found surprising.I'm curious about the process for proposing changes to https://wiki.openstack.org/wiki/Horizon/_javascript_. Is there any process?On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran tqt...@us.ibm.com wrote:It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it.For me, function declarations can get convoluted very fast if not use correctly.Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement.But they do have their uses when used correctly.I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions.As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 07:04AMSubject: [openstack-dev] [horizon] function expressions vs functiondeclarations in _javascript__javascript_ has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions).In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/_javascript_.Thanks,Matt __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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-dev] [Keystone] Symbol not found: _BIO_new_CMS
Hi All,
I am new to MAC OS, trying to setup Keystone development environment and stuck
at running the keystone tests, getting error (below) related to openssl while
running tox. I am having “OpenSSL 1.0.1k 8 Jan 2015” version of OpenSSL.
Thanks in advance for any help,
Arvind
$ tox -e py27
py27 develop-inst-noop: /Users/arvtiwar/cloudDev/openstack/keystone
py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | python setup.py testr --slowest --testr-args=
running testr
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./ ./keystone/tests --list
--- import errors ---
Failed to import test module: keystone.tests
Traceback (most recent call last):
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
line 479, in _find_test_path
package = self._get_module_from_name(name)
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
line 384, in _get_module_from_name
__import__(name)
File keystone/tests/__init__.py, line 41, in module
from keystone.tests.core import * # noqa
File keystone/tests/core.py, line 41, in module
environment.use_eventlet()
File keystone/common/environment/__init__.py, line 51, in wrapper
return func(*args, **kwargs)
File keystone/common/environment/__init__.py, line 66, in use_eventlet
import eventlet
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/__init__.py,
line 10, in module
from eventlet import convenience
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/convenience.py,
line 3, in module
from eventlet import greenio
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/greenio.py,
line 644, in module
from OpenSSL import SSL
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/__init__.py,
line 8, in module
from OpenSSL import rand, crypto, SSL
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/rand.py,
line 11, in module
from OpenSSL._util import (
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/_util.py,
line 4, in module
binding = Binding()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py,
line 113, in __init__
self._ensure_ffi_initialized()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py,
line 123, in _ensure_ffi_initialized
cls._modules,
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/utils.py,
line 31, in load_library_for_binding
lib = ffi.verifier.load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/verifier.py,
line 75, in load_library
return self._load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/verifier.py,
line 151, in _load_library
return self._vengine.load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/vengine_cpy.py,
line 149, in load_library
raise ffiplatform.VerificationError(error)
VerificationError: importing
'/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_70441dc9x8be47966.so':
dlopen(/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_70441dc9x8be47966.so,
2): Symbol not found: _BIO_new_CMS
Referenced from:
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_70441dc9x8be47966.so
Expected in: flat namespace
in
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_70441dc9x8be47966.so
Non-zero exit code (2) from test listing.
error: testr failed (3)
ERROR: InvocationError:
'/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/bin/python setup.py
testr --slowest --testr-args='
_
summary
_
ERROR: py27: commands failed
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core
+1 On 14 Jan 2015 19:15, Clint Byrum cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [nova] bug 1334398 and libvirt live snapshot support
On 1/14/2015 4:03 PM, Matt Riedemann wrote: On 12/8/2014 3:12 PM, Jeremy Stanley wrote: On 2014-12-08 11:45:36 +0100 (+0100), Kashyap Chamarthy wrote: As Dan Berrangé noted, it's nearly impossible to reproduce this issue independently outside of OpenStack Gating environment. I brought this up at the recently concluded KVM Forum earlier this October. To debug this any further, one of the QEMU block layer developers asked if we can get QEMU instance running on Gate run under `gdb` (IIRC, danpb suggested this too, previously) to get further tracing details. We document thoroughly how to reproduce the environments we use for testing OpenStack. There's nothing rarified about a Gate run that anyone with access to a public cloud provider would be unable to reproduce, save being able to run it over and over enough times to expose less frequent failures. FWIW, I myself couldn't reproduce it independently via libvirt alone or via QMP (QEMU Machine Protocol) commands. Dan's workaround (enable it permanently, except for under the gate) sounds sensible to me. [...] I'm dubious of this as it basically says we know this breaks sometimes, so we're going to stop testing that it works at all and possibly let it get even more broken, but you should be safe to rely on it anyway. The QA team tries very hard to make our integration testing environment as closely as possible mimic real-world deployment configurations. If these sorts of bugs emerge more often because of, for example, resource constraints in the test environment then it should be entirely likely they'd also be seen in production with the same frequency if run on similarly constrained equipment. And as we've observed in the past, any code path we stop testing quickly accumulates new bugs that go unnoticed until they impact someone's production environment at 3am. Bringing this back up since Jesse Keating in IRC was asking about this again today. Sounds like we've heard from a few people that are running this in labs without problems, maybe they are patching libvirt/qemu, I don't know, but we have other things that we know have broken parts and that's why they run on the experimental queue, e.g. cells, nova + ceph/rbd. We also know we're a bit busted in the ec2 API right now with the latest boto release (2.35.1), so we have a cap on that. These issues are being worked, but regarding this particular way that we've disabled the function (with a version cap in the code), someone has to go in and patch that out, which kind of sucks if they could have just used a config option to enable it at their own risk. That's why I'm proposing something like an [experimental] group. We could put this into the [workarounds] group but this isn't really a workaround for anything so that doesn't really make sense to me. I'd personally be OK with putting it into the [libvirt] group with a warning in the config option help and code that this isn't currently tested in the gate so we aren't sure it's going to work, which we've done for cells and some of the virt drivers, e.g. libvirt on non-x86_64/QEMU systems. I'm going to play with this revert [1] on the Fedora 21 experimental queue which is running libvirt 1.2.9 and qemu 2.1.2. Join me, won't you? :) [1] https://review.openstack.org/#/c/147332/ -- Thanks, Matt Riedemann __ 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] 6.0 is out: where to get the ISO?
Hi all, with a little delay (looks like holidays were long for me... sorry), I'd like to announce that we have pushed official 6.0 tags in our Fuel repositories. Please use the following links to download the ISO IMG of Fuel 6.0: http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-6.0.iso.torrent http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-6.0.img.torrent You can always build the ISO yourself following instructions [1]. Major features: - Juno support - Pluggable architecture MVP, with a few sample plugins (including very well tested and production ready) - A number of bug fixes and improvements enabling Fuel to run on scale up to 100 nodes (more to come in the next release...) - Multiple Neutron L3 agents support - Image based provisioning Please see all the blueprints implemented [2]. [1] http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso [2] https://launchpad.net/fuel/+milestone/6.0 Thanks guys for the hard work! -- Mike Scherbakov #mihgen __ 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] [horizon] static files handling, bower/
I won't stop to comment on this statement other than to say Javascript is quite relevant to Oracle, Oracle's customers, and Oracle's partners. Your argument is a boondoggle. Refusing to use node because your favorite platform doesn't support it is not the fault of node.js, it's the fault of the platform. Not to belabor the thread, but yes, of course JavaScript is very relevant to Oracle, Solaris, our customers/partners, etc. And that includes both client and server-side. As Drew stated, as of this moment we haven't yet made Node.js available on SPARC but I expect that to change in the future. But the question or potential concern remains as to whether adding a non-Python/pip build dependency makes sense. I'm not particularly well-versed in the Horizon build process so perhaps I'm way off base. But given that a distribution's Horizon build package embeds various JavaScript libraries to be used by the browser, how those libraries are obtained during the build process is an interesting build detail. I thought the intent of the XStatic work was to provide Python wrappers around the various JavaScript libraries so they could be pulled down via pip. Since there's already a Python requirements.txt file for versioning information, that seemed to be a nice way of indicating which versions of the JavaScript libraries could be used by Horizon and Python was used all the way through the build. I realize that it takes work to build the XStatic packages but given the Python packages are basically wrappers, it seems creating those and uploading them to pypi could be automated by using Bower and setup.py but perhaps translating the metadata isn't straightforward. __ 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] Devstack failures related to q-vpn service
Do you have access to the screen-q-vpn.log? Regards, PCM PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Wed, Jan 14, 2015 at 2:24 PM, Sukhdev Kapur sukhdevka...@gmail.com wrote: HI Paul, Here is one of the typical log when this failure hits. http://arista-ci.arista.com:8000/January-2015/Arista_Tempest_Test/97/146597/5/stack.sh.log.gz regards.. -Sukhdev On Wed, Jan 14, 2015 at 1:06 PM, Paul Michali p...@michali.net wrote: Can you provide more info on what failures you are seeing? Regards, PCM PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Wed, Jan 14, 2015 at 12:35 PM, Sukhdev Kapur sukhdevka...@gmail.com wrote: Hi All, I am seeing very frequent failures of devstack on our CI because of q-vpn service failures. This has happened very recently. Is this a know issue? I am tempted to disable q-vpn service on our CI to avoid this noise. I wanted to reach out to see if others are also seeing this issue. please advise.. -Sukhdev __ 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 __ 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] [Keystone] Symbol not found: _BIO_new_CMS
As discussed on IRC: Unfortunately OS X Yosemite ships with a woefully out of
date OpenSSL, LDAP Lib, etc. Some of these are not easy to replace with
homebrew (some are). These out of date libs are usually left only for
compatibility while people move to Apple’s specific alternative libs.
Recently I ran into a couple issues with python packages that would not work
without updating the setup.py (and not in a friendly way that should be done
for up-stream, I think LDAP was the culprit this time). This headache made the
packages unsuitable for installation in a venv via tox. As of before the 2014
holidays Keystone (and it’s Unit tests) are no longer supported on OS X. Your
milage may vary with OS X older than Yosemite.
I recommend using Linux in a VM if you’re on OS X. Alternatively a bootcamp
install of Linux would also work on most Apple laptops / machines.
Sorry for the bad news in this case.
—Morgan
On Jan 14, 2015, at 2:45 PM, Arvind Tiwari (arvtiwar) arvti...@cisco.com
wrote:
Hi All,
I am new to MAC OS, trying to setup Keystone development environment and
stuck at running the keystone tests, getting error (below) related to
openssl while running tox. I am having “OpenSSL 1.0.1k 8 Jan 2015” version of
OpenSSL.
Thanks in advance for any help,
Arvind
$ tox -e py27
py27 develop-inst-noop: /Users/arvtiwar/cloudDev/openstack/keystone
py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | python setup.py testr --slowest --testr-args=
running testr
running=
OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} \
${PYTHON:-python} -m subunit.run discover -t ./ ./keystone/tests --list
--- import errors ---
Failed to import test module: keystone.tests
Traceback (most recent call last):
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
line 479, in _find_test_path
package = self._get_module_from_name(name)
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/unittest2/loader.py,
line 384, in _get_module_from_name
__import__(name)
File keystone/tests/__init__.py, line 41, in module
from keystone.tests.core import * # noqa
File keystone/tests/core.py, line 41, in module
environment.use_eventlet()
File keystone/common/environment/__init__.py, line 51, in wrapper
return func(*args, **kwargs)
File keystone/common/environment/__init__.py, line 66, in use_eventlet
import eventlet
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/__init__.py,
line 10, in module
from eventlet import convenience
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/convenience.py,
line 3, in module
from eventlet import greenio
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/eventlet/greenio.py,
line 644, in module
from OpenSSL import SSL
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/__init__.py,
line 8, in module
from OpenSSL import rand, crypto, SSL
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/rand.py,
line 11, in module
from OpenSSL._util import (
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/OpenSSL/_util.py,
line 4, in module
binding = Binding()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py,
line 113, in __init__
self._ensure_ffi_initialized()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py,
line 123, in _ensure_ffi_initialized
cls._modules,
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/bindings/utils.py,
line 31, in load_library_for_binding
lib = ffi.verifier.load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/verifier.py,
line 75, in load_library
return self._load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/verifier.py,
line 151, in _load_library
return self._vengine.load_library()
File
/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cffi/vengine_cpy.py,
line 149, in load_library
raise ffiplatform.VerificationError(error)
VerificationError: importing
'/Users/arvtiwar/cloudDev/openstack/keystone/.tox/py27/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_70441dc9x8be47966.so':
Re: [openstack-dev] [nova] bug 1334398 and libvirt live snapshot support
On 12/8/2014 3:12 PM, Jeremy Stanley wrote: On 2014-12-08 11:45:36 +0100 (+0100), Kashyap Chamarthy wrote: As Dan Berrangé noted, it's nearly impossible to reproduce this issue independently outside of OpenStack Gating environment. I brought this up at the recently concluded KVM Forum earlier this October. To debug this any further, one of the QEMU block layer developers asked if we can get QEMU instance running on Gate run under `gdb` (IIRC, danpb suggested this too, previously) to get further tracing details. We document thoroughly how to reproduce the environments we use for testing OpenStack. There's nothing rarified about a Gate run that anyone with access to a public cloud provider would be unable to reproduce, save being able to run it over and over enough times to expose less frequent failures. FWIW, I myself couldn't reproduce it independently via libvirt alone or via QMP (QEMU Machine Protocol) commands. Dan's workaround (enable it permanently, except for under the gate) sounds sensible to me. [...] I'm dubious of this as it basically says we know this breaks sometimes, so we're going to stop testing that it works at all and possibly let it get even more broken, but you should be safe to rely on it anyway. The QA team tries very hard to make our integration testing environment as closely as possible mimic real-world deployment configurations. If these sorts of bugs emerge more often because of, for example, resource constraints in the test environment then it should be entirely likely they'd also be seen in production with the same frequency if run on similarly constrained equipment. And as we've observed in the past, any code path we stop testing quickly accumulates new bugs that go unnoticed until they impact someone's production environment at 3am. Bringing this back up since Jesse Keating in IRC was asking about this again today. Sounds like we've heard from a few people that are running this in labs without problems, maybe they are patching libvirt/qemu, I don't know, but we have other things that we know have broken parts and that's why they run on the experimental queue, e.g. cells, nova + ceph/rbd. We also know we're a bit busted in the ec2 API right now with the latest boto release (2.35.1), so we have a cap on that. These issues are being worked, but regarding this particular way that we've disabled the function (with a version cap in the code), someone has to go in and patch that out, which kind of sucks if they could have just used a config option to enable it at their own risk. That's why I'm proposing something like an [experimental] group. We could put this into the [workarounds] group but this isn't really a workaround for anything so that doesn't really make sense to me. I'd personally be OK with putting it into the [libvirt] group with a warning in the config option help and code that this isn't currently tested in the gate so we aren't sure it's going to work, which we've done for cells and some of the virt drivers, e.g. libvirt on non-x86_64/QEMU systems. -- Thanks, Matt Riedemann __ 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] [TripleO] nominating James Polley for tripleo-core
On 15 January 2015 at 10:07, Clint Byrum cl...@fewbar.com wrote: Excerpts from James Polley's message of 2015-01-14 12:46:37 -0800: Thanks for the nomination Clint (and +1s from people who have already responded) At this stage, I believe we've traditionally[1] asked[2] the potential new Core Reviewer to commit to 3 reviews per work-day. I don't feel that that's a commitment I can make at this point. It's not something I've been able to achieve in the past - I've come close over the last 30 days, but the 90 day report shows me barely above 2 per day. I think my current throughput is something I can commit to maintaining, and I'd like to think that it can grow over time; but I don't think I can commit to doing anything more than I've already been able to do. If the rest of the core reviewers think I'm still making a valuable contribution, I'm more than happy to accept this nomination. IMO we need to re-evaluate that requirement. None of us has done a great job at sustaining it, however as a team we've managed to at least get enough reviews done to keep the tubes flowing. I know that at one point we got really backed up, but what solved that was a combination of a few less patches getting submitted (probably because of the long wait time) and a few more reviewers being added. So having more good reviewers like yourself seems more important than having more perfect reviewers. I agree. The point of making a commitment is a social mechanism for 'this is a marathon, not a sprint'. Also the main reason for wanting people to do 3 per day is to maintain familiarity with the code. I think you've been able to remain familiar with your traditional rate just fine. 3 was an arbitrary number pulled out of the air. If folk can and do remain familiar with a lower review rate, thats fine IMO. Nothing should be considered permanent or set in stone. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] Devstack failures related to q-vpn service
HI Paul, Here is one of the typical log when this failure hits. http://arista-ci.arista.com:8000/January-2015/Arista_Tempest_Test/97/146597/5/stack.sh.log.gz regards.. -Sukhdev On Wed, Jan 14, 2015 at 1:06 PM, Paul Michali p...@michali.net wrote: Can you provide more info on what failures you are seeing? Regards, PCM PCM (Paul Michali) IRC pc_m (irc.freenode.com) Twitter... @pmichali On Wed, Jan 14, 2015 at 12:35 PM, Sukhdev Kapur sukhdevka...@gmail.com wrote: Hi All, I am seeing very frequent failures of devstack on our CI because of q-vpn service failures. This has happened very recently. Is this a know issue? I am tempted to disable q-vpn service on our CI to avoid this noise. I wanted to reach out to see if others are also seeing this issue. please advise.. -Sukhdev __ 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] [stable] Stable branch status and proposed stable-maint members mentoring
Thanks, Ihar. Lets make this the 'official' tracking pad for stable branches. We were previously using branch-specific pads (ie, https://etherpad.openstack.org/p/StableJuno) but it makes sense to track both releases in one place. I've updated it with current staus there and added a reference on the stable branch wiki page [1] Cheers, Adam [1] https://wiki.openstack.org/wiki/StableBranch#Gate_Status On Wed, Jan 14, 2015 at 4:37 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: On 01/09/2015 01:02 PM, Ihar Hrachyshka wrote: I think we should have some common document (etherpad?) with branch status and links. OK, I moved forward and created an Etherpad. I also filed it in with current state. Please fill it in with updates. https://etherpad.openstack.org/p/stable-tracker __ 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-dev] [all] OpenStack Bootstrapping Hour - oslo.messaging anti-patterns - Friday Jan 16th 17:00 UTC
Join us for the next OpenStack Bootstrapping Hour this friday at 17:00 UTC (12:00 Americas/New_York) on olso.messaging. A oslo.messaging API presentation with some anti-patterns and pit-falls. oslo.messaging is the standard library that OpenStack projects use to communicate with message buses in OpenStack. This is how services within a project communicate with one another. Come learn about oslo.messaging and the right and wrong ways to consume it in your project. Presented by core team members Mehdi Abaakouk and Flavio Percoco. Host(s): Sean Dague, Dan Smith, Jay Pipes Experts(s): Mehdi Abaakouk, Flavio Percoco Time/Date: Friday, Jan 16th 17:00 UTC (12:00 Americas/New_York) Youtube Stream: https://www.youtube.com/watch?v=NJhciX4lIVE Etherpad: https://etherpad.openstack.org/p/obh-oslo-messaging-antipatterns Full info at - https://wiki.openstack.org/wiki/BootstrappingHour/Oslo_Messaging_Antipatterns Hope to see many of you there. -Sean -- Sean Dague http://dague.net __ 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] Empty role - status
Hi, Empty role is ready [1], thanks to granular deployment feature I didn't have to hardcode some hacks in Astute again. But there are several things which I want to mention/discuss: 1. in the patch you can see the name of the role and its description I would like to ask you to verify it and provide some other options if you have any 2. we have a minor problem with the progress bar, we will figure out how to fix it in Astute with Vladimir S. 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific and it doesn't allow us to make efficient partitioning schema, e.g. it means that we cannot allocate root partition for all of the disks (provisioning will fail), the current workaround is to allocate root partition with minimal size (about 15G) and leave the rest of the space as is (unallocated). As far as I can see from the bug it's not so easy to fix the problem, actually image based provisioning fixes the problem, but it's not an option for the current release. Maybe you have some other ideas how to fix this problem? Thanks, [1] https://review.openstack.org/#/c/147230/ [2] https://bugs.launchpad.net/fuel/+bug/1278964 __ 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] Doubts regarding OpenStack Tempest
Hi, I am going through tempest in OpenStack and have some questions that I would like to get answered. Q1. How can we debug test cases in OpenStack ? (We can debug the code through import pdb but the same doesn't work for test cases and we have a bdb quit error) Q2. The run_tests.sh script or tox -e does it only run the unit test cases for that components or it runs the complete set of tests covered in the Tempest test integration suite ? Q3. Suppose I need to add a test case in the tempest suite how can I do that ? Q4. As it is said that tempest interacts only with the OpenStack Rest Api's , then how are the test cases for the various clients run, by clients here I mean the python-novaclient,keystoneclient etc. Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ 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 Havana installation using devstack
Go with stable/icehouse then. On Thu Jan 15 2015 at 11:13:37 AM masoom alam masoom.a...@gmail.com wrote: Hi every one, How can I install Openstack Havana using devstack. The problem is that Havana branch does not exist on Github. git clone https://github.com/openstack-dev/devstack.git -b stable/havana Please guide. __ 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-dev] [QA] Meeting Thursday January 15th at 17:00 UTC
Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, January 15th at 17:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agenda. It's also worth noting that a few weeks ago we started having a regular dedicated Devstack topic during the meetings. So if anyone is interested in Devstack development please join the meetings to be a part of the discussion. To help people figure out what time 17:00 UTC is in other timezones tomorrow's meeting will be at: 12:00 EST 02:00 JST 03:30 ACDT 18:00 CET 11:00 CST 09:00 PST -David Kranz __ 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 DVR limit
Hi, Swami, Thanks for your reply. Maybe I did not explain clearly, my suggestion is: Add one more configuration, enable_distributed_FIP to configure the FIP will be run as distributed mode or centralized mode. If enable_distributed_FIP = True, then FIP can be both in centralized node (dvr_snat) and distributed “dvr” compute nodes. If enable_distributed_FIP = False, then FIP can be only in centralized node (dvr_snat). Best Regards Chaoyi Huang ( Joe Huang ) From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasude...@hp.com] Sent: Wednesday, January 14, 2015 1:41 PM To: joehuang; OpenStack Development Mailing List (not for usage questions); 龚永生 Subject: RE: [openstack-dev] About DVR limit Hi Joehuang, FIP today as of Juno can be both in centralized node (dvr_snat) and distributed “dvr” compute nodes. Thanks Swami From: joehuang [mailto:joehu...@huawei.com] Sent: Tuesday, January 13, 2015 7:49 PM To: OpenStack Development Mailing List (not for usage questions); 龚永生 Cc: Vasudevan, Swaminathan (PNB Roseville) Subject: RE: [openstack-dev] About DVR limit Hi, Swami, I would like to know whether the FIP under DVR could be configured to distributed mode or central mode in Kilo, not find relevant information from http://specs.openstack.org/openstack/neutron-specs/. For example, it will be helpful for following FIP use cases: 1) FIP will be addressed centrally by dedicated hardware 2) not all compute nodes have public address. Best Regards Chaoyi Huang ( Joe Huang ) From: Stamina than Valued an [mailto:souminat...@yahoo.com] Sent: Wednesday, January 14, 2015 11:05 AM To: 龚永生 Cc: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] About DVR limit Hi yong Zheng, Yes your understanding is right. We only support ovs driver. Regarding HA and multi network support, it will be available in kilo. Public address consumption for north south traffic for compute node is also true. But to address this issue we do have a proposal that is worked out by the l3 sub team. I hope this clarifies your doubts. Please let me know if I can help you with anything else. Thanks Swami Sent from my iPad On Jan 13, 2015, at 6:01 PM, 龚永生 gong.yongsh...@99cloud.netmailto:gong.yongsh...@99cloud.net wrote: Hi, I am yong sheng gong, I want to know if the DVR has these limits besides the documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html: 1. one subnet can be connected to DVR router only once, which is confirmed by BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway 2. one network cannot have more than one subnet connecting to DVR routers So the DVR limits the neutron model to: one network has just one subnet, and one subnet cannot connect to more than one DVR routers. ps. req and limits documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:: DVR requirements ·You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR. ·Be sure that your firewall or security groups allows UDP traffic over the VLAN, GRE, or VXLAN port to pass between the compute hosts. DVR limitations ·Distributed virtual router configurations work with the Open vSwitch Modular Layer 2 driver only for Juno. ·In order to enable true north-south bandwidth between hypervisors (compute nodes), you must use public IP addresses for every compute node and enable floating IPs. ·For now, based on the current neutron design and architecture, DHCP cannot become distributed across compute nodes. thanks, Yong sheng gong __ 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] [gantt] Google hangout tomorrow to discuss scheduler specs
As promised at the weekly IRC meeting this week I'll setup up a hangout tomorrow, 1/15, at 1500 UTC (8:00AM MST) where we can discuss the one remaining spec that needs approval for Kilo: Remove direct nova DB/API access by Scheduler Filters - https://review.openstack.org/138444 I'll send out the link shortly before the meeting (I have to play games to drop off the corporate internet) and also put up the link on IRC (#openstack-nova). -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 __ 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] Openstack Havana installation using devstack
Hi every one, How can I install Openstack Havana using devstack. The problem is that Havana branch does not exist on Github. git clone https://github.com/openstack-dev/devstack.git -b stable/havana Please guide. __ 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] Doubts regarding OpenStack Tempest
1. There's a process outlined here for debugging tests using testtools, pdb should work: http://docs.openstack.org/developer/neutron/devref/development.environment.html#debugging FWIW, you can also look into using the olso debug helper script, but looks like tempest doesn't support it ATM: http://docs.openstack.org/developer/oslotest/features.html#debugging-with-oslo-debug-helper 2. To determine which suites that tox -e will run by default, look at tox.ini: https://github.com/openstack/tempest/blob/master/tox.ini#L2 To determine which tests get run by default look at: https://github.com/openstack/tempest/blob/master/.testr.conf 3. Add a new test to a file for starters, or make a new file called test_foo.py. I'm sure there has to be info about it here: http://docs.openstack.org/developer/tempest/ 4. There is a read-only policy for the clients, the tests are all here: https://github.com/openstack/tempest/tree/master/tempest/cli/simple_read_only With way more info here: http://docs.openstack.org/developer/tempest/field_guide/cli.html Thanks, Steve Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com wrote on 01/15/2015 12:09:27 AM: From: Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com To: openstack-dev@lists.openstack.org Date: 01/15/2015 12:19 AM Subject: [openstack-dev] Doubts regarding OpenStack Tempest Hi, I am going through tempest in OpenStack and have some questions that I would like to get answered. Q1. How can we debug test cases in OpenStack ? (We can debug the code through import pdb but the same doesn't work for test cases and we have a bdb quit error) Q2. The run_tests.sh script or tox -e does it only run the unit test cases for that components or it runs the complete set of tests covered in the Tempest test integration suite ? Q3. Suppose I need to add a test case in the tempest suite how can Ido that ? Q4. As it is said that tempest interacts only with the OpenStack Rest Api's , then how are the test cases for the various clients run, by clients here I mean the python-novaclient,keystoneclient etc. Thanks and Regards Abhishek Talwar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you __ 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] [glance] Replication on image create
I also recommend approach #2. For, approach #1, 1) You have to maintain a state machine if you want to synchronize the image to 3 or more backend. 2) Not always 3 or more backend will be synchronized successfully, unless you make it like a transaction, it's hard to process the synchronization broken, and re-sync. 3) As more and more backend, the transaction will often failed to synchronize the image to all destination. For approach #2 The image status is required to enhanced to reflect the image availability for each location. And the consumer of the glance api can check to see whether the image is ready for specific location, if not ready, either trigger a synchronization immediately or report failure. If the image is available only after all backend have been synchronized, the end user experience is good, but you have to wait for all location is ready, and it's not easy to do that: considering the synchronization broken, backend leave and join. the more backend, the harder is. Another recommendation is to trigger the synchronization on demand: when the first VM using this image is booted, the image will be synchronized to the proper backend for the new VM. The shortage for this approach is that the first VM booting will last longer than usual, but the process is much more stable. Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, January 14, 2015 10:25 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [glance] Replication on image create On 01/13/2015 04:55 PM, Boden Russell wrote: Looking for some feedback from the glance dev team on a potential BP… The use case I’m trying to solve is — As an admin, I want my glance image bits replicated to multiple store locations (of the same store type) during a glance create operation. For example, I have 3 HTTP based backend locations I want to store my glance image bits on. When I create / upload a new glance image, I want those bits put onto all 3 HTTP based locations and have the image's 'locations' metadata properly reflect all stored locations. There are obviously multiple approaches to getting this done. [1] Allow per glance store drivers the ability to manage config and connectivity to multiple backends. For example in the glance-api.conf: [DEFAULT] store_backends = http1,http2,http3 ... [http1] # http 1 backend props ... [http2] # http 2 backend props ... [http2] # http 2 backend props ... And then in the HTTP store driver use a configuration approach like cinder multi-backend does (e.g.: https://github.com/openstack/cinder/blob/2f09c3031ef2d2db598ec4c56f6127e33d29b2cc/cinder/volume/configuration.py#L52). Here, the store driver handles all the logic w/r/t pushing the image bits to all backends, etc.. The problem with this solution is that the HTTP Glance storage backend is readonly. You cannot upload an image to Glance using the http backend. [2] A separate (3rd party) process which handles the image replication and location metadata updates... For example listens for the glance notification on create and then takes the steps necessary to replicate the bits elsewhere and update the image metadata (locations). This is the solution that I would recommend. Frankly, this kind of replication should be an async out-of-band process similar to bittorrent. Just have bittorrent or rsync or whatever replicate the image bits to a set of target locations and then call the glanceclient.v2.client.images.add_location() method: https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211 to add the URI of the replicated image bits. [3] etc... In a prototype I implemented #1 which can be done with no impact outside of the store driver code itself. I'm not entirely sure how you did that considering the http storage backend is readonly. Are you saying you implemented the add() method for the glance_store._drivers.http.Store class? Best, -jay I prefer #1 over #2 given approach #2 may need pull the image bits back down from the initial location in order to push for replication; additional processing. Is the dev team adverse to option #1 for the store driver's who wish to implement it and / or what are the other (preferred) options here? Thank you, - boden __ 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] [Fuel][Docs] Move fuel-web/docs to fuel-docs
Adjusting fuel-web/docs to build ONLY the API and Objects reference is here: https://review.openstack.org/147348 Meg should have the inclusion of fuel-web/docs content in fuel-docs tomorrow. Once these two are done, we can sort out that last step: And finally we will have CI job to publish final documentation in one place. And this job will build and publish every part into separate subfolder, so we'll get final docs in one place but built independently. -Christopher __ 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] [API] Upgrading to API WG Recommendations
Hey all, In the last meeting of the working group, we discussed what the goals of the group are and how those affect existing projects and new ones. In particular, some people seem confused as to whether the group’s goal is to create recommendations for ideal APIs or to document the existing APIs and choose the best practices from those. This is still somewhat up for debate, but most want to shoot for the stars while being willing to compromise. Keep in mind, right now nothing committed to openstack/api-wg is a set in stone. Most of the reviews that are currently in progress are undergoing heavy discussion both on gerrit and in meetings. The point was brought up that some recommendations that the working group forms will be jarring for APIs to implement when going from vN.* to vN+1.0 for both developers and consumers. Client libraries often provide compatibility (or upgrade-path) versions to help bridge the gap between going from vN.* to vN+1.0. As a group, we’re looking for feedback from the developers on the following topics: - Does this seem preferable? - Does it sound reasonable and maintainable? - Does it seem reasonable as a way of improving user experience and upgradability? If you have a positive feeling for this idea, there are a couple follow-ups: - Should the API WG recommend a strategy for this versioning path? - If so, should the versioning path work like: - vN.M - vN.99 - vN+1.0 We would use .99 to indicate that you it’s compatible with vN.* but also provides information/endpoints in vN+1) - or vN.M - vN+1.0 - vN+2.0 In this case we would make N+1 be the compatibility version (perhaps do not allow increments of the minor version) and N+2 would be the version of the API that is fully in-compliance with the Working Group’s final recommendations. Thanks in advance for your feedback, Ian __ 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 DVR limit
Hello, Yongseng, correct, your description is much more concise, we need a configuration: east-west, DVR south-north, legacy mode. Best Regards Chaoyi Huang ( Joe Huang ) From: 龚永生 [mailto:gong.yongsh...@99cloud.net] Sent: Thursday, January 15, 2015 10:18 AM To: Vasudevan, Swaminathan (PNB Roseville) Cc: joehuang; OpenStack Development Mailing List (not for usage questions) Subject: Re:RE: [openstack-dev] About DVR limit Hi, Swami, Joehuang, in dvr compute nodes, it is 1:1 NAT FIP, means the floatingip for VM, and it is in the namespace of qrouter-. but in dvr_snat node, it is 1:N NAT IP, it is for neutron router, and for the VMs which have no 1:1 FIP, implemented in namesapce snat-xxx. Joehuang's case can be implemented in legacy mode, I.E. non DVR, but for the east-west traffic, we should consider the DVR, So I think there is a case: east-west, DVR south-north, legacy mode. Thanks yong sheng gong 在 2015-01-14 13:40:32，Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com 写道： Hi Joehuang, FIP today as of Juno can be both in centralized node (dvr_snat) and distributed “dvr” compute nodes. Thanks Swami From: joehuang [mailto:joehu...@huawei.commailto:joehu...@huawei.com] Sent: Tuesday, January 13, 2015 7:49 PM To: OpenStack Development Mailing List (not for usage questions); 龚永生 Cc: Vasudevan, Swaminathan (PNB Roseville) Subject: RE: [openstack-dev] About DVR limit Hi, Swami, I would like to know whether the FIP under DVR could be configured to distributed mode or central mode in Kilo, not find relevant information from http://specs.openstack.org/openstack/neutron-specs/. For example, it will be helpful for following FIP use cases: 1) FIP will be addressed centrally by dedicated hardware 2) not all compute nodes have public address. Best Regards Chaoyi Huang ( Joe Huang ) From: Stamina than Valued an [mailto:souminat...@yahoo.com] Sent: Wednesday, January 14, 2015 11:05 AM To: 龚永生 Cc: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] About DVR limit Hi yong Zheng, Yes your understanding is right. We only support ovs driver. Regarding HA and multi network support, it will be available in kilo. Public address consumption for north south traffic for compute node is also true. But to address this issue we do have a proposal that is worked out by the l3 sub team. I hope this clarifies your doubts. Please let me know if I can help you with anything else. Thanks Swami Sent from my iPad On Jan 13, 2015, at 6:01 PM, 龚永生 gong.yongsh...@99cloud.netmailto:gong.yongsh...@99cloud.net wrote: Hi, I am yong sheng gong, I want to know if the DVR has these limits besides the documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html: 1. one subnet can be connected to DVR router only once, which is confirmed by BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway 2. one network cannot have more than one subnet connecting to DVR routers So the DVR limits the neutron model to: one network has just one subnet, and one subnet cannot connect to more than one DVR routers. ps. req and limits documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:: DVR requirements *You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR. *Be sure that your firewall or security groups allows UDP traffic over the VLAN, GRE, or VXLAN port to pass between the compute hosts. DVR limitations *Distributed virtual router configurations work with the Open vSwitch Modular Layer 2 driver only for Juno. *In order to enable true north-south bandwidth between hypervisors (compute nodes), you must use public IP addresses for every compute node and enable floating IPs. *For now, based on the current neutron design and architecture, DHCP cannot become distributed across compute nodes. thanks, Yong sheng gong __ 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] Why all OpenStack Foundation Individual Members should vote now [all]
HOW TO VOTE: If you are an eligible voter[1], you should have received an email with the subject “OpenStack Foundation – 2015 Individual Director Election” from secret...@openstack.org. This email includes your unique voting link. If you did not receive an email, please contact secret...@openstack.org. If you are an active member of the OpenStack Foundation, you should have received an email in your inbox with a link to vote for renewal of the Board of Directors and to change the Foundation’s bylaws. The changes to the bylaws make this election different from others and require your vote. During 2014, the OpenStack community created several revisions of the Bylaws as part of the process to define what makes up core OpenStack functionality. The proposed revisions to the Bylaws are meant to provide flexibility in determining the software required for use of the OpenStack trademarks. The revisions also permit the adoption of the “DefCore” procedures and any changes to those procedures in the future. These amendments have already gone through fifteen revisions with comments from the Technical Committee, DefCore Committee, OpenStack Foundation management, Legal Affairs Committee and the Board of Directors. Now it’s your turn: the change to the bylaws require that least 25% of the eligible voters cast a vote. If the quorum is not reached, the bylaws won’t change and the work of the Foundation will be more complicated. You have a duty to fulfill and it won’t take much of your time. You can learn more about the amendments https://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment. We need your click to reach the quorum to improve the Foundation. [1] Eligible voters are individual members of the OpenStack Foundation who joined the foundation more than 180 days ago. __ 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 Havana installation using devstack
No I want Havana purposefully. Thanks On Thu, Jan 15, 2015 at 10:45 AM, iKhan ik.ibadk...@gmail.com wrote: Go with stable/icehouse then. On Thu Jan 15 2015 at 11:13:37 AM masoom alam masoom.a...@gmail.com wrote: Hi every one, How can I install Openstack Havana using devstack. The problem is that Havana branch does not exist on Github. git clone https://github.com/openstack-dev/devstack.git -b stable/havana Please guide. __ 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] Request for comments for a possible solution
Hi Mathieu,
Please see comments inline.
Regards,
Mike
- Original Message -
Hi Mike,
after reviewing your latest patch [1], I think that a possible solution could
be to add a new entry in fdb RPC message.
This entry would specify whether the port is multi-bound or not.
The new fdb message would look like this :
{net_id:
{port:
{agent_ip:
{mac, ip, multi-bound }
}
}
network_type:
vxlan,
segment_id:
id
}
When the multi-bound option would be set, the ARP responder would be
provisioned but the underlying module (ovs or kernel vxlan) would be
provisioned to flood the packet to every tunnel concerned by this overlay
segment, and not only the tunnel to agent that is supposed to host the port.
In the LB world, this means not adding fdb entry for the MAC of the
multi-bound port, whereas in the OVS world, it means not adding a flow that
send the trafic that matches the MAC of the multi-bound port to only one
tunnel port, but to every tunnel port of this overlay segment.
So let me see if I understand what you suggest correctly..
You suggest that instead of not sending the FDB we do send it along with an
optional third parameter?
Mind you that FDBs are sent as a list so for example an l2pop message would
look like:
{
'61a00edd-018e-4923-9524-df91b3f3083b': {
'ports': {
'30.0.0.2': [
[
'00:00:00:00:00:00',
'0.0.0.0'
],
[
'00:00:00:00:12:34',
'10.0.0.1'
]
],
'30.0.0.1': [
[
'00:00:00:00:00:00',
'0.0.0.0'
],
[
'00:00:00:00:56:78',
'10.1.1.1'
]
]
},
'network_type': u'vxlan',
'segment_id': 1
}
}
So the parameter you suggest to add will be at index 2 of each FDB list?
I'm not sure it will be optional then, otherwise it could be quite hard to
decode these messages..
Also, you suggest that each agent will know what to do according to this
parameter?
This way, traffic to multi-bound port will behave as unknown unicast traffic.
First packet will be flood to every tunnel and local bridge will learn the
correct tunnel for the following packets based on which tunnel received the
answer.
Once learning occurs with first ingress packet, following packets would be
sent to the correct tunnel and not flooded anymore.
IIUC then we still need to send all nodes where the HA port is scheduled on,
this just adds on top of it and moves out the decision regarding the FDB to the
agent level.
The FDB is then only needed for populating the ARP responder?
I've tested this with linuxbridge and it works fine. Based on code overview,
this should work correctly with OVS too. I'll test it ASAP.
I know that DVR team already add such a flag in RPC messages, but they revert
it in later patches. I would be very interested in having their opinion on
this proposal.
It seems that DVR port could also use this flag. This would result in having
ARP responder activated for DVR port too.
This shouldn't need a bump in RPC versioning since this flag would be
optionnal. So their shouldn't have any issue with backward compatibility.
I'm not sure if it's backwards compatible since you're actually changing the
construct of the RPC message so it's a bit unexpected how the old agents will
react.
It's not adding a new key-value, it's modifying each fdb's list..
Regards,
Mathieu
[1] https://review.openstack.org/#/c/141114/2
On Sun, Dec 21, 2014 at 12:14 PM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
Hi Mike,
Just one comment [Vivek]
-Original Message-
From: Mike Kolesnik [mailto: mkole...@redhat.com ]
Sent: Sunday, December 21, 2014 11:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Robert Kukura
Subject: Re: [openstack-dev] [Neutron][L2Pop][HA Routers] Request for
comments for a possible solution
Hi Mathieu,
Comments inline
Regards,
Mike
- Original Message -
Mike,
I'm not even sure that your solution works without being able to bind
a router HA port to several hosts.
What's happening currently is that you :
1.create the router on two l3agent.
2. those l3agent trigger the sync_router() on the l3plugin.
3. l3plugin.sync_routers() will trigger
l2plugin.update_port(host=l3agent).
4. ML2 will bind the port to the host mentioned in the last
update_port().
From a l2pop perspective, this will result in creating only one tunnel
to the host lastly specified.
I can't find any code that forces that only the master router binds
its router port. So we don't even know if the host which binds the
router port is hosting the master router or the slave one, and so if
l2pop is creating the tunnel to the master or to the slave.
Can you confirm that the above sequence is correct? or am I missing
something?
Are you referring to the alternative solution?
In that case it seems that you're correct so that there would need to be
awareness
Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Hi Ramy,
I think i managed to setup SCP plugin and updated zuul.conf but it only
uploads the console.html not the logs
I have an SCP site pointing to the apache server and the root location is
/srv/static, and in the dsvm job manually added a post-build step, Publish
Artifacts to SCP Repository, with source: logs/** and destination
logs/${LOG_PATH} and also checked Copy Console Log.
The destination path is created, but it only contains console.html.
I tried to manually scp the directory, but the jenkins user in the
devstack_slave asks for a password when trying to ssh to apache server.
Thanks,
Eduard
On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei
eduard.ma...@cloudfounders.com wrote:
Thanks Ramy, i'll try to set it up manually.
Meanwhile i found another problem: jobs are failing because of error or
are being aborted.
FATAL: java.io.IOException: Unexpected termination of the
channelhudson.remoting.RequestAbortedException
http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
java.io.IOException: Unexpected termination of the channel
Is this related to another warning i got:
WARNING: devstack run took 15 minutes, this is a very slow node.
Is there a timeout for how long a job is allowed to run?
Most jobs take between 40 and 60 minutes, some are able to run successfully,
some are aborted or get this error.
Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB
vHDD).
Thanks,
Eduard
On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com
wrote:
Hi Eduard,
Apache logs server address is set here (should probably add some
comment/doc for that)
https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10
Jenkins will get configured here:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
Note that you need to restart Jenkins for those changes to take effect.
After it’s set, you can use the Jenkins UI to ‘test’ the connection.
Jenkins Job Builder publishers are here:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110
Use the publishers as shown here:
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
Zuul will then use this url when commenting in gerrit:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18
Ramy
*From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
*Sent:* Tuesday, January 13, 2015 2:31 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
help setting up CI
Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set
before starting first time nodepool, so template got incorrect key)
Next question: where do i configure the apache logs server address? I
have a separate vm with jenkins account and running apache2 exposing
/srv/static/logs, but where do i enter its ip address ? (in jenkins,
nodepool or... )
Thanks,
Eduard
On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy ramy.asse...@hp.com
wrote:
You are correct to run nodepoold as nodepool user.
I didn’t see any issues…
Could you double check the public keys listed in .ssh/authorized_keys in
the template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY?
Ramy
*From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
*Sent:* Monday, January 12, 2015 5:30 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
help setting up CI
Hi,
Regarding the last issue, i fixed it by logging in and manually pip
install docutils. Image was created successfully.
Now the problem is that nodepool is not able to login into instances
created from that image.
I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running,
and also i am able to login to the instance from user nodepool, but
nodepoold gives error:
2015-01-12 14:19:03,095 DEBUG paramiko.transport: Switch to new keys ...
2015-01-12 14:19:03,109 DEBUG paramiko.transport: Trying key
c03fbf64440cd0c2ecbc07ce4ed59804 from /home/nodepool/.ssh/id_rsa
2015-01-12 14:19:03,135 DEBUG paramiko.transport: userauth is OK
2015-01-12 14:19:03,162 INFO paramiko.transport: Authentication
(publickey) failed.
2015-01-12 14:19:03,185 DEBUG paramiko.transport: Trying discovered key
c03fbf64440cd0c2ecbc07ce4ed59804 in /home/nodepool/.ssh/id_rsa
2015-01-12 14:19:03,187 DEBUG paramiko.transport: userauth is OK
^C2015-01-12 14:19:03,210 INFO paramiko.transport: Authentication
(publickey) failed.
Re: [openstack-dev] [horizon] static files handling, bower/
On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew __ 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] [horizon] function expressions vs function declarations in JavaScript
JavaScript has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions). In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/Javascript. Thanks, Matt __ 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] [Keystone][Horizon] User self registration and management
Hi all, I'm working in a European project that uses OpenStack and I am using horizon and keystone for our users and organization management solution. We have some requirements similar to yours Adrian: we need to allow users to sign up themselves (with all the common functionality of email activation, forgot password) plus support authentication using OAuth2.0. We are interested in having a standard open-source solution for these problems, therefore we are really interested in participating in this discussion to see other solutions for the problem, discuss them and collaborate in making such a service. I think this kind of requirements are common to anyone wanting to use OpenStack to build a public cloud system where there is no admin to create users. In the meantime, we have developed our open-source system for them using keystone extensions and django apps which satisfy our requirements. If there is interest in them I can share and explain in more detail our approach to both problems, and help build a well-integrated solution for everyone. Cheers, Enrique Garcia Navalon 2015-01-14 13:14 GMT+01:00 David Chadwick d.w.chadw...@kent.ac.uk: Hi Adrian You might be glad to know that we have already produced a blueprint and implementation for this, based on federated keystone and Horizon. You can read the specs here https://blueprints.launchpad.net/keystone/+spec/vo-management and see a demo here http://icehouse.sec.cs.kent.ac.uk/ (However you will not be able to perform federated login without a Facebook or Google account, and you will also need the name of the VO role that you are to join, plus a secret/PIN - Contact me if you want one) Briefly, the administrator (could be keystone or domain admin) sets up a VO role, sends the details to the users who are to become members of it, along with a secret, and the user then logs in via his IdP (you can use Facebook or Google), quoting the secret and VO role. He is then enrolled in Keystone, either automatically, or pending admin approval (as a config option). The user can resign from the VO role anytime he wishes. I have updated your etherpad giving my comments regards David On 14/01/2015 05:06, Adrian Turjak wrote: Hello openstack-dev, I'm wondering if there is any interest or need for an open-source user registration and management service for people using OpenStack. We're currently at a point where we need a way for users to sign up themselves, choose their own password, and request new users to be added to their project. There doesn't seem to be anything out there, and most vendors seem to have built their own systems to handle this or even their own dashboard systems that do. Horizon is built around the client tools, and your own personal token, so it can't handle creating new users. Plus Keystone doesn't really have any good way of handling temporary (unapproved) users and projects. The suggested approach seems to be to build a service to sit along Keystone, have it's own admin creds so it can create new users, and also store temp user data locally until the user is approved. Unless we can find a suitable solution for us quickly, we're likely to be developing such a service. It would ideally have a pluggable approval workflow, allowing new user requests, new project requests, creation of clients in external client database/ERP systems. Plus it would have a password reset-token system for having new users supply their password once they are approved, which would also allow existing users to request password resets. Part of our requirements are easy to integrate into Horizon, fitting neatly into the OpenStack ecosystem along other services, and being easy to update/alter once we have hierarchical multi-tenancy and if it makes some things easier. I've written up a proposal to help us define our requirements, and a copy of that is attached, and on etherpad: https://etherpad.openstack.org/p/User_Management_Service Plus I've attached a couple of diagrams, which are sadly not UML, but should give you some idea of two of the primary use cases. Is this useful to anyone? Is this entirely the wrong approach? If it is a useful service is there any interest in collaboration? Thanks for any feedback. Cheers, -Adrian Turjak __ 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] [horizon] static files handling, bower/
On 2015-01-14 17:25:46 +0400 (+0400), Anton Zemlyanov wrote: Solaris is supported by node.js: Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/ node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/ node-v0.10.35-sunos-x64.tar.gz I believe the point made was that without SPARC (probably only the 64-bit variant these days but still) support, that's not enough. Solaris targets more than just Intel's processors. (So does Linux for that matter!) I think Solaris is no longer relevant The Solaris developer community probably disagrees with you on this point. ;) -- Jeremy Stanley __ 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] request spec freeze exception for Improving performance of unshelve-api
Hi Devs, Please consider my spec for spec freeze exception. I am ready with the code and also submitted the patches for review on community gerrit. Nova-specs: https://review.openstack.org/#/c/135387/ Nova: https://review.openstack.org/#/c/147078/ Tempest: https://review.openstack.org/#/c/147079/ Please review the specs and let me know your valuable suggestions. Thank you, Abhishek Kekane From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] Sent: 08 January 2015 19:57 To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [nova] request spec freeze exception for Improving performance of unshelve-api Hi Devs, I have submitted a nova-spec [1] for improving the performance of unshelve-api. The aim of this feature is to improve the performance of unshelve instance by eliminating downloading/copying snapshot time. All instance files will be retained in the instance store backed by shared or non-shared storage on the compute node when an instance is shelved. Please review this spec, and consider this spec for request spec freeze exception. [1] https://review.openstack.org/#/c/135387/ Thank You, Abhishek Kekane __ 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. __ 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 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][AdvancedServices] Confusion about the solution of the service chaining!
Hi, we really like the idea to address the SFC use-case in Neutron working group. We would be happy to work with the community to work out the way to consume service-chains via standardized neutron-api and provide use-cases and blueprints. Some initial ideas on the use-case can be found in the following etherpad [1]. Keshava, we think that it would be ideal to have two type of use-cases: one which you described below (“dynamic” one) with the usage of IETF-defined header but also one “static” one where the whole chain can be pre-provisioned by the orchestrator via Neutron-API w/o usage of classifier and header extensions. [1] https://etherpad.openstack.org/p/kKIqu2ipN6 Kind regards/Mit freundlichen Grüßen Yuriy Babenko Von: A, Keshava [mailto:keshav...@hp.com] Gesendet: Donnerstag, 8. Januar 2015 07:19 An: mest...@mestery.com; OpenStack Development Mailing List (not for usage questions) Betreff: Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining! Yes, I agree with Kyle decision. First we should define what is Service. Service is within OpenStack infrastructure ? or Service belongs to NFV vNF/Service-VM ? Based on that its Chaining needs to be defined. If it is chaining of vNFs(which are service/set of services) then it will be based on ietf ‘service header insertion’ at the ingress. This header will have all the set services that needs to be executed across vNFV, will be carried in each of the Tennant packet. So it requires coordinated effort along with NFV/Telco working groups. keshava From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Wednesday, January 07, 2015 8:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining! On Wed, Jan 7, 2015 at 6:25 AM, lv.erc...@zte.com.cnmailto:lv.erc...@zte.com.cn wrote: Hi, I want to confirm that how is the project about Neutron Services Insertion, Chaining, and Steering going, I found that all the code implementation about service insertion、service chaining and traffic steering list in JunoPlan were Abandoned . https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan and I also found that we have a new project about GBP and group-based-policy-service-chaining be located at: https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-abstraction https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining so I'm confused with solution of the service chaining. We are developing the service chaining feature, so we need to know which one is the neutron's choice. Are the blueprints about the service insertion, service chaining and traffic steering list in JunoPlan all Abandoned ? Service chaining isn't in the plan for Kilo [1], but I expect it to be something we talk about in Vancouver for the Lxxx release. The NFV/Telco group has been talking about this as well. I'm hopeful we can combine efforts and come up with a coherent service chaining solution that solves a handful of useful use cases during Lxxx. Thanks, Kyle [1] http://specs.openstack.org/openstack/neutron-specs/priorities/kilo-priorities.html BR Alan ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org 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] [horizon] static files handling, bower/
On 01/14/2015 09:14 AM, Matthew Farina wrote: I think we're discussing two different situations with slightly different requirements. First, there is development and test. I believe the stated goal is to have node.js here. Would an environment not supporting node.js be needed for development or testing? Note, the JavaScript under test and to be executed by users is in browser rather than server side. The important execution environment is in their browser. The second environment is production. In that case the system packages would be used. What's still unclear is who creates and maintains those packages since many of them don't exist today. On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew Seems to me like you'd want to test using packages for SPARC, not using a dev sort of environment. Packages again for production. My two cents is that you need to contribute to the node community if you require SPARC compatibility for node for development, since SPARC is an outlier. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen __ 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] oslo.concurrency 1.4.1 released
The Oslo team is pleased to announce the release of oslo.concurrency 1.4.1: oslo.concurrency library This release reverts a patch which introduced a regression in oslo_concurrency.processutils.execute(). Although the previous release was 0.4.0, this release has a whole extra version number, just for you. Enjoy. For more details, please see the git log history below and http://launchpad.net/oslo.concurrency/+milestone/1.4.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo.concurrency Changes in openstack/oslo.concurrency 0.4.0..1.4.1 acb55ef Revert Port processutils to Python 3 diffstat (except docs and test files): oslo_concurrency/processutils.py | 21 + tests/test_processutils.py | 16 3 files changed, 17 insertions(+), 36 deletions(-) __ 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] [horizon] static files handling, bower/
I think we're discussing two different situations with slightly different requirements. First, there is development and test. I believe the stated goal is to have node.js here. Would an environment not supporting node.js be needed for development or testing? Note, the JavaScript under test and to be executed by users is in browser rather than server side. The important execution environment is in their browser. The second environment is production. In that case the system packages would be used. What's still unclear is who creates and maintains those packages since many of them don't exist today. On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher drew.fis...@oracle.com wrote: On 1/14/15 6:25 AM, Anton Zemlyanov wrote: Solaris is supported by node.js: x86 is certainly supported. Always has been. That's not the issue in question. My point was that SPARC is not supported. Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant I won't stoop to comment on this statement other than to say Solaris is quite relevant to Oracle, Oracle's customers and Oracle's partners. -Drew __ 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-dev] [nova] Networks are not cleaned up in build failure
Hi All, I recently experienced failures getting images from Glance while spawning instances. This step comes after building the networks in the guild sequence. When the Glance failure occurred the instance was cleaned up and rescheduled as expected, but the networks were not cleaned up. On investigation I found that the cleanup code for the networks is in the compute manager's _do_build_run_instance() method as follows: # NOTE(comstud): Deallocate networks if the driver wants # us to do so. if self.driver.deallocate_networks_on_reschedule(instance): self._cleanup_allocated_networks(context, instance, requested_networks) The default behavior in for the deallocate_networks_on_schedule() method defined in ComputeDriver is: def deallocate_networks_on_reschedule(self, instance): Does the driver want networks deallocated on reschedule? return False Only the Ironic driver over rides this method to return True, so I think this means the networks will not be cleaned up for any other virt driver. Is this really the desired behavior? I have filed a bug for this and plan to fix it: https://bugs.launchpad.net/nova/+bug/1410739 My initial thought is to fix this either by making the method in the base class return True or by adding the method to virt drivers returning True (I would expect the former). But I wanted to check if there is a reason for the base class behavior (and so the default behavior) to be *NOT* to clean up the networks? Paul Paul Murray Nova Technical Lead, HP Cloud +44 117 316 2527 Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England. The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as HP CONFIDENTIAL. __ 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-Infra] [ThirdPartyCI] Need help setting up CI
See in-line From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com] Sent: Wednesday, January 14, 2015 12:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Thanks Ramy, i'll try to set it up manually. Meanwhile i found another problem: jobs are failing because of error or are being aborted. FATAL: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedExceptionhttp://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel RA: This means there’s some communication failure between the Jenkins master and Jenkins slave. If it happens every time, then likely some issue on the slave changing network settings. Is this related to another warning i got: WARNING: devstack run took 15 minutes, this is a very slow node. RA: I get that too…it likely means you have a slow network or didn’t cache sufficient packages in the image, or repos server the necessary data are overloaded, etc. Is there a timeout for how long a job is allowed to run? Most jobs take between 40 and 60 minutes, some are able to run successfully, some are aborted or get this error. Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD. Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB vHDD). RA: m1.large should be fine. Thanks, Eduard On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.commailto:ramy.asse...@hp.com wrote: Hi Eduard, Apache logs server address is set here (should probably add some comment/doc for that) https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10 Jenkins will get configured here: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb Note that you need to restart Jenkins for those changes to take effect. After it’s set, you can use the Jenkins UI to ‘test’ the connection. Jenkins Job Builder publishers are here: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110 Use the publishers as shown here: https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7 Zuul will then use this url when commenting in gerrit: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18 Ramy From: Eduard Matei [mailto:eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com] Sent: Tuesday, January 13, 2015 2:31 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set before starting first time nodepool, so template got incorrect key) Next question: where do i configure the apache logs server address? I have a separate vm with jenkins account and running apache2 exposing /srv/static/logs, but where do i enter its ip address ? (in jenkins, nodepool or... ) Thanks, Eduard On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy ramy.asse...@hp.commailto:ramy.asse...@hp.com wrote: You are correct to run nodepoold as nodepool user. I didn’t see any issues… Could you double check the public keys listed in .ssh/authorized_keys in the template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY? Ramy From: Eduard Matei [mailto:eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com] Sent: Monday, January 12, 2015 5:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Hi, Regarding the last issue, i fixed it by logging in and manually pip install docutils. Image was created successfully. Now the problem is that nodepool is not able to login into instances created from that image. I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running, and also i am able to login to the instance from user nodepool, but nodepoold gives error: 2015-01-12 14:19:03,095 DEBUG paramiko.transport: Switch to new keys ... 2015-01-12 14:19:03,109 DEBUG paramiko.transport: Trying key c03fbf64440cd0c2ecbc07ce4ed59804 from /home/nodepool/.ssh/id_rsa 2015-01-12 14:19:03,135 DEBUG paramiko.transport: userauth is OK 2015-01-12 14:19:03,162 INFO paramiko.transport: Authentication (publickey) failed. 2015-01-12 14:19:03,185 DEBUG paramiko.transport: Trying discovered key c03fbf64440cd0c2ecbc07ce4ed59804 in /home/nodepool/.ssh/id_rsa 2015-01-12 14:19:03,187 DEBUG paramiko.transport: userauth is OK ^C2015-01-12 14:19:03,210 INFO paramiko.transport: Authentication (publickey) failed. 2015-01-12 14:19:03,253 DEBUG
Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Double check your ssh public/private key, authorized keys configuration in the
slave log server.
They should all match up. No passwords should be requested.
Try doing a manual scp as Jenkins user from the slave to the log server (as
Jenkins user there too).
Regarding manually setting up the publisher, I don’t know. Jenkins Job Builder
configuration I referenced below should work correctly.
Ramy
From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Wednesday, January 14, 2015 6:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting
up CI
Hi Ramy,
I think i managed to setup SCP plugin and updated zuul.conf but it only uploads
the console.html not the logs
I have an SCP site pointing to the apache server and the root location is
/srv/static, and in the dsvm job manually added a post-build step, Publish
Artifacts to SCP Repository, with source: logs/** and destination
logs/${LOG_PATH} and also checked Copy Console Log.
The destination path is created, but it only contains console.html.
I tried to manually scp the directory, but the jenkins user in the
devstack_slave asks for a password when trying to ssh to apache server.
Thanks,
Eduard
On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei
eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com wrote:
Thanks Ramy, i'll try to set it up manually.
Meanwhile i found another problem: jobs are failing because of error or are
being aborted.
FATAL: java.io.IOException: Unexpected termination of the channel
hudson.remoting.RequestAbortedExceptionhttp://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
java.io.IOException: Unexpected termination of the channel
Is this related to another warning i got:
WARNING: devstack run took 15 minutes, this is a very slow node.
Is there a timeout for how long a job is allowed to run?
Most jobs take between 40 and 60 minutes, some are able to run successfully,
some are aborted or get this error.
Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB vHDD).
Thanks,
Eduard
On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy
ramy.asse...@hp.commailto:ramy.asse...@hp.com wrote:
Hi Eduard,
Apache logs server address is set here (should probably add some comment/doc
for that)
https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10
Jenkins will get configured here:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
Note that you need to restart Jenkins for those changes to take effect. After
it’s set, you can use the Jenkins UI to ‘test’ the connection.
Jenkins Job Builder publishers are here:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110
Use the publishers as shown here:
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
Zuul will then use this url when commenting in gerrit:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18
Ramy
From: Eduard Matei
[mailto:eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com]
Sent: Tuesday, January 13, 2015 2:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting
up CI
Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set before
starting first time nodepool, so template got incorrect key)
Next question: where do i configure the apache logs server address? I have a
separate vm with jenkins account and running apache2 exposing /srv/static/logs,
but where do i enter its ip address ? (in jenkins, nodepool or... )
Thanks,
Eduard
On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy
ramy.asse...@hp.commailto:ramy.asse...@hp.com wrote:
You are correct to run nodepoold as nodepool user.
I didn’t see any issues…
Could you double check the public keys listed in .ssh/authorized_keys in the
template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY?
Ramy
From: Eduard Matei
[mailto:eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com]
Sent: Monday, January 12, 2015 5:30 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting
up CI
Hi,
Regarding the last issue, i fixed it by logging in and manually pip install
docutils. Image was created successfully.
Now the problem is that nodepool is not able to login into instances created
from that image.
I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running, and
also i am able to login
Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver
Maxime Leroy maxime.le...@6wind.com writes: Ok, thank you for the details. I will look how to implement this feature. Hi Maxime, Did you have time yet to start looking at this? My team now has a use case that could be met by using vif_plug_script, so I would be happy to help with writing the spec for that. Would that be of interest to you? Thanks, Neil __ 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] [nova] how to regenerate doc/api_samples?
How do I regenerate the doc/api_samples tests if I change the corresponding template? The instructions in nova/tests/functional/api_samples/README.rst say to run GENERATE_SAMPLES=True tox -epy27 nova.tests.unit.integrated, but that path doesn't exist anymore. I suspect the instructions should have been updated when the templates were moved under nova/tests/functional. Thanks, 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
[openstack-dev] [nova] The constraints from flavor and image metadata
Resend because I forgot the [nova] in subject. Hi, There are some discussion and disagreement on the requirement from flavor and image metadata at nova spec https://review.openstack.org/#/c/138937/ and I want to get more input from the community. When launch a VM, some requirements may come from image metadata and flavor. There are a lot of such cases like serial_port_count, memory_pagesize, hw_numa_nodes, hw:cpu_max_sockets etc. Most of them are done in nova/virt/hardware.py. Both the nova-spec and the current implementation seems agree that if flavor has the requirement, the image's metadata should not require more than the flavor requirement. However, the disagreement comes when no requirement from flavor, i.e. only image has the resource requirement. For example, for serial_port_count, If flavor extra specs is not set, then any image meta value is permitted. For hw_mem_page_size, it's forbidden if only image request and no flavor request (https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L873 ), and hw_numa_nodes will fail if both flavor and image metadata are specified (https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L852 ). As to this nova spec at https://review.openstack.org/#/c/138937/ , someone (Don, Malini) think if image requires some feature/resource that is not specified in flavor, it should be ok, while I think it should be forbidden. I discussed with Jay Pipe on IRC before and he thought if flavor has no requirement, image requirement should be failed, and I created a bug at https://bugs.launchpad.net/nova/+bug/1403276 at that time. But according to the discussion on this BP, seems this is not always accepted by others. I hope to get feedback from the mailing list on the relationship of requirement from image/flavor. Possibly we should take different policy for different resource requirement, but some general rule and the reason for those rules will be helpful. Thanks --jyh __ 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] [TripleO] nominating James Polley for tripleo-core
Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [horizon] function expressions vs function declarations in JavaScript
It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it.For me, function declarations can get convoluted very fast if not use correctly.Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement.But they do have their uses when used correctly.I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions.As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 07:04AMSubject: [openstack-dev] [horizon] function expressions vs function declarations in _javascript__javascript_ has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions).In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/_javascript_.Thanks,Matt __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [TripleO] nominating James Polley for tripleo-core
Hi +1! Cheers, -- Chris Jones On 14 Jan 2015, at 18:14, Clint Byrum cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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] [TripleO] nominating James Polley for tripleo-core
+1 On 15 Jan 2015 07:15, Clint Byrum cl...@fewbar.com wrote: Hello! It has been a while since we expanded our review team. The numbers aren't easy to read with recent dips caused by the summit and holidays. However, I believe James has demonstrated superb review skills and a commitment to the project that shows broad awareness of the project. Below are the results of a meta-review I did, selecting recent reviews by James with comments and a final score. I didn't find any reviews by James that I objected to. https://review.openstack.org/#/c/133554/ -- Took charge and provided valuable feedback. +2 https://review.openstack.org/#/c/114360/ -- Good -1 asking for better commit message and then timely follow-up +1 with positive comments for more improvement. +2 https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec. 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this is only really about 7 - 10 working days and acceptable. +2 https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of recent change with alternatives to the approach submitted as patches. https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in agreement with everyone else. +1 https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with consideration for other reviewers. +2 https://review.openstack.org/#/c/113983/ -- Thorough spec review with grammar pedantry noted as something that would not prevent a positive review score. +2 All current tripleo-core members are invited to vote at this time. Thank you! __ 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-dev] [sahara] team meeting Jan 15 1400 UTC
Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-3 channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150115T14 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer 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
[openstack-dev] [Neutron] grenade failures
Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ 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] [Fuel] Dropping Python-2.6 support
I just made a general remark regarding why migrating to 2.7 is profitable (I understood Bartek's question this way). The point about Red Hat guaranteeing security fixes to 2.6 is a good one. Also, it's true we don't use SSL for fuelclient so yes, if other OpenStack projects keep 2.6 we should stick to it also. P. On 01/14/2015 08:32 AM, Bartłomiej Piotrowski wrote: On 01/13/2015 11:16 PM, Tomasz Napierala wrote: On 13 Jan 2015, at 10:51, Przemyslaw Kaminski pkamin...@mirantis.com wrote: For example https://www.python.org/download/releases/2.6.9/ All official maintenance for Python 2.6, including security patches, has ended. https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS Especially the SSL stuff is interesting http://bugs.python.org/issue22935 This looks like final word here. We cannot provide software, that has no security support. Regards, I can hardly see it as a justification for maintaining yet another package on our own while Red Hat is supposed to provide backports of security fixes to python 2.6 until 2020. I wanted to hear exact use cases of 2.7 features that allow us to accomplish things easier than it is now with 2.6. As Doug already said, clients and Oslo libraries will maintain compatibility with 2.6. So what is the real gain? Regards, Bartłomiej __ 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-dev] [Neutron][FWaaS] No FWaaS meeting on Jan 14th
We will skip today's FWaaS IRC meeting since a number of people in the team are not available. Thanks, ~Sumit. __ 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] [Fuel] Dropping Python-2.6 support
Guys, The question not about Do we want to drop 2.6 or not?. The question about Do we have resources to do that in this release cycle?. It may be not as easy at it seems and it obviously requires additional testing. - Igor On Wed, Jan 14, 2015 at 11:18 AM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: I just made a general remark regarding why migrating to 2.7 is profitable (I understood Bartek's question this way). The point about Red Hat guaranteeing security fixes to 2.6 is a good one. Also, it's true we don't use SSL for fuelclient so yes, if other OpenStack projects keep 2.6 we should stick to it also. P. On 01/14/2015 08:32 AM, Bartłomiej Piotrowski wrote: On 01/13/2015 11:16 PM, Tomasz Napierala wrote: On 13 Jan 2015, at 10:51, Przemyslaw Kaminski pkamin...@mirantis.com wrote: For example https://www.python.org/download/releases/2.6.9/ All official maintenance for Python 2.6, including security patches, has ended. https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS Especially the SSL stuff is interesting http://bugs.python.org/issue22935 This looks like final word here. We cannot provide software, that has no security support. Regards, I can hardly see it as a justification for maintaining yet another package on our own while Red Hat is supposed to provide backports of security fixes to python 2.6 until 2020. I wanted to hear exact use cases of 2.7 features that allow us to accomplish things easier than it is now with 2.6. As Doug already said, clients and Oslo libraries will maintain compatibility with 2.6. So what is the real gain? Regards, Bartłomiej __ 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] [glance] Replication on image create
On 13/01/15 21:24 -0500, Jay Pipes wrote: On 01/13/2015 04:55 PM, Boden Russell wrote: Looking for some feedback from the glance dev team on a potential BP… The use case I’m trying to solve is — As an admin, I want my glance image bits replicated to multiple store locations (of the same store type) during a glance create operation. For example, I have 3 HTTP based backend locations I want to store my glance image bits on. When I create / upload a new glance image, I want those bits put onto all 3 HTTP based locations and have the image's 'locations' metadata properly reflect all stored locations. There are obviously multiple approaches to getting this done. [1] Allow per glance store drivers the ability to manage config and connectivity to multiple backends. For example in the glance-api.conf: [DEFAULT] store_backends = http1,http2,http3 ... [http1] # http 1 backend props ... [http2] # http 2 backend props ... [http2] # http 2 backend props ... And then in the HTTP store driver use a configuration approach like cinder multi-backend does (e.g.: https://github.com/openstack/cinder/blob/2f09c3031ef2d2db598ec4c56f6127e33d29b2cc/cinder/volume/configuration.py#L52). Here, the store driver handles all the logic w/r/t pushing the image bits to all backends, etc.. The problem with this solution is that the HTTP Glance storage backend is readonly. You cannot upload an image to Glance using the http backend. [2] A separate (3rd party) process which handles the image replication and location metadata updates... For example listens for the glance notification on create and then takes the steps necessary to replicate the bits elsewhere and update the image metadata (locations). This is the solution that I would recommend. Frankly, this kind of replication should be an async out-of-band process similar to bittorrent. Just have bittorrent or rsync or whatever replicate the image bits to a set of target locations and then call the glanceclient.v2.client.images.add_location() method: https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211 to add the URI of the replicated image bits. It recently landed in Glance an async workers engine (?) that allows for this kind of things to exists. For instance, it'll be used for image introspection to extract information from images after they have been *imported* into glance. The right hooks that trigger this async workers maybe need to be defined better but the infrastructure is there. Once that's more solid, you'll be able to write your own plugin that will do that job on every glance image import. That said, I'd suggest you to follow Jay's advice for now. Cheers, Flavio [3] etc... In a prototype I implemented #1 which can be done with no impact outside of the store driver code itself. I'm not entirely sure how you did that considering the http storage backend is readonly. Are you saying you implemented the add() method for the glance_store._drivers.http.Store class? Best, -jay I prefer #1 over #2 given approach #2 may need pull the image bits back down from the initial location in order to push for replication; additional processing. Is the dev team adverse to option #1 for the store driver's who wish to implement it and / or what are the other (preferred) options here? Thank you, - boden __ 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 -- @flaper87 Flavio Percoco pgpv3A6hG5r81.pgp Description: PGP signature __ 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-Infra] [ThirdPartyCI] Need help setting up CI
Thanks Ramy, i'll try to set it up manually. Meanwhile i found another problem: jobs are failing because of error or are being aborted. FATAL: java.io.IOException: Unexpected termination of the channelhudson.remoting.RequestAbortedException http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel Is this related to another warning i got: WARNING: devstack run took 15 minutes, this is a very slow node. Is there a timeout for how long a job is allowed to run? Most jobs take between 40 and 60 minutes, some are able to run successfully, some are aborted or get this error. Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD. Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB vHDD). Thanks, Eduard On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com wrote: Hi Eduard, Apache logs server address is set here (should probably add some comment/doc for that) https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10 Jenkins will get configured here: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb Note that you need to restart Jenkins for those changes to take effect. After it’s set, you can use the Jenkins UI to ‘test’ the connection. Jenkins Job Builder publishers are here: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110 Use the publishers as shown here: https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7 Zuul will then use this url when commenting in gerrit: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18 Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Tuesday, January 13, 2015 2:31 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set before starting first time nodepool, so template got incorrect key) Next question: where do i configure the apache logs server address? I have a separate vm with jenkins account and running apache2 exposing /srv/static/logs, but where do i enter its ip address ? (in jenkins, nodepool or... ) Thanks, Eduard On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy ramy.asse...@hp.com wrote: You are correct to run nodepoold as nodepool user. I didn’t see any issues… Could you double check the public keys listed in .ssh/authorized_keys in the template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY? Ramy *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com] *Sent:* Monday, January 12, 2015 5:30 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI Hi, Regarding the last issue, i fixed it by logging in and manually pip install docutils. Image was created successfully. Now the problem is that nodepool is not able to login into instances created from that image. I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running, and also i am able to login to the instance from user nodepool, but nodepoold gives error: 2015-01-12 14:19:03,095 DEBUG paramiko.transport: Switch to new keys ... 2015-01-12 14:19:03,109 DEBUG paramiko.transport: Trying key c03fbf64440cd0c2ecbc07ce4ed59804 from /home/nodepool/.ssh/id_rsa 2015-01-12 14:19:03,135 DEBUG paramiko.transport: userauth is OK 2015-01-12 14:19:03,162 INFO paramiko.transport: Authentication (publickey) failed. 2015-01-12 14:19:03,185 DEBUG paramiko.transport: Trying discovered key c03fbf64440cd0c2ecbc07ce4ed59804 in /home/nodepool/.ssh/id_rsa 2015-01-12 14:19:03,187 DEBUG paramiko.transport: userauth is OK ^C2015-01-12 14:19:03,210 INFO paramiko.transport: Authentication (publickey) failed. 2015-01-12 14:19:03,253 DEBUG paramiko.transport: EOF in transport thread 2015-01-12 14:19:03,254 INFO nodepool.utils: Password auth exception. Try number 4... echo $NODEPOOL_SSH_KEY B3NzaC1yc2EDAQABAAABAQC9gP6qui1fmHrj02p6OGvnz7kMTJ2rOC3SBYP/Ij/6yz+SU8rL5rqL6jqT30xzy9t1q0zsdJCNB2jExD4xb+NFbaoGlvjF85m12eFqP4CQenxUOdYAepf5sjV2l8WAO3ylspQ78ipLKec98NeKQwLrHB+xon6QfAHXr6ZJ9NRZbmWw/OdpOgAG9Cab+ELTmkfEYgQz01cZE22xEAMvPXz57KlWPvxtE7YwYWy180Yib97EftylsNkrchbSXCwiqgKUf04qWhTgNrVuRJ9mytil6S82VNDxHzTzeCCxY412CV6dDJNLzJItpf/CXQelj/6wJs1GgFl5GWJnqortMR2v cat /home/nodepool/.ssh/id_rsa.pub ssh-rsa
Re: [openstack-dev] [Neutron] grenade failures
Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe (mailto: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] [tc][python-clients] More freedom for all python clients
On 13/01/15 14:31 -0500, Sean Dague wrote: On 01/13/2015 02:10 PM, Jay Pipes wrote: On 01/13/2015 12:39 PM, Zane Bitter wrote: On 13/01/15 10:01, Jeremy Stanley wrote: On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote: Why doesn't rally just remove itself from projects.txt, then there would be no restrictions on what it adds. I second this recommendation. If Rally wants to depend on things which are not part of OpenStack and not required to run or test OpenStack in an official capacity (and since it's not an official OpenStack project it's entirely within its rights to want to do that), then forcing it to comply with the list of requirements for official OpenStack projects is an unnecessarily restrictive choice. FWIW I don't really agree with this advice. The purpose of openstack/requirements is to ensure that it's possible to create a distribution of OpenStack without conflicting version requirements, not to force every project to use every dependency listed. As such, some co-ordination around client libraries for related projects seems like it ought to be an uncontroversial addition. (Obviously it's easy to imagine potential additions that would legitimately be highly controversial, but IMHO this isn't one of them.) Saying that we require people to use our tools to get into the club but that our tools are not going to accommodate them in any way until they are in sounds a bit too close to Go away to my ears. +1 I think as we grow global-requirements probably needs to be broken up into functional lists. What's allowed in base-iass, what's allowed in application services, what's allowed in docs, etc, etc. The complexity of keeping the g-r list actually working goes up sort of n^2 as the size of it, because pip doesn't have a real solver. This is a barely functional set of plate spinning so just add everything misses the point that the breaks get more and more difficult to unwind. If someone is up for stepping up and contributing to breaking up into domains, please do. But I think while this remains a global list we really do need to be a bit careful here. Do we really need a per-domain g-r? With the upcoming changes in the openstack governance model, I believe this won't scale even if we break it into per-domain basis. Some questions that need answeres are: - Who's going to review the per domain g-r ? If it's a centralized team, then it won't definitely scale. If it's the domain team then, what's the real point of having these requirements? - How are we going to support the creation and maintnance of these g-r in the gate? Are they actually worth it? While I understand why we have g-r, I really don't think it'll scale for a broader community as we're envisioning it. With that in mind, I'd probably recommend to have 1 requirements group for the base-caas integrated gate and let other projects and groups have their own requirements. That is, non base-caas projects should get the versions of their common requirements from g-r so that they won't conflict if they're installed alongside with any of the base-caas projects. But other than those base requirements, I'd let non base-caas projects have what they need (which is pretty much what heat's team has done with the contrib packages, AFAICT). I know this opens the doors for version conflicts between the requirements of non base-caas projects but I think this is a more welcoming (and non-blocking) way to do things until we've a better one. Hope the above makes some sense I blame the lack of coffee if it doesn't, Flavio That said, I'd like to suggest another possible workaround: in Heat we keep resource plugins for non-official projects in the /contrib tree, and each plugin has it's own setup.cfg and requirements.txt. For example: http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican So the user has the option to install each plugin, and it comes with its own requirements, independent of the main Heat installation. Perhaps Rally could consider something similar. Seems like a very reasonable solution to me. Thanks for bringing it up, -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 -- Sean Dague http://dague.net __ 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 -- @flaper87 Flavio Percoco pgpSTIBS8VTg9.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
Am 14/01/15 um 05:17 schrieb Adam Gandelman: So eventlet 0.16.x has started hitting slaves and breaking stable branches (its not like we weren't warned :\ ) https://bugs.launchpad.net/nova/+bug/1410626 Should hopefully be resolved by eventlet versions caps in icehouse + juno's requirements: https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z It was discussed already in the context of https://bugs.launchpad.net/nova/+bug/1407685 that capping eventlet would not be the proper solution, instead there is a fix already in master which has backports to icehouse + juno pending: https://review.openstack.org/#/c/145955/ https://review.openstack.org/#/c/146096/ Or is this new bug triggered by a different piece of code relating to the newly released eventlet 0.16.1? __ 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][client] new client implementation ideas
Hi all,
We are working on fuel certification script
https://github.com/stgleb/fuel-web
and have yet-one-more implementation of fuel-client, which cover very small
of Fuel API, yet we have some ideas, which you might be interesting in.
1) high-level primitives for REST operations.
a) GET/PUT/POST/etc function, which returns closure, bonded to url and
method
class Cluster(RestObj):
Class represents Cluster in Fuel
add_node_call = PUT('api/nodes')
start_deploy = PUT('api/clusters/{id}/changes')
get_status = GET('api/clusters/{id}')
delete = DELETE('api/clusters/{id}')
GET(url_template) returns function/class method, which accepts set
of parameters,
format part of them into url_template to obtain final url and pass
other parameters
as data in http request. E.g.
get_some_objs = GET('some/objects/{cluster_id}/really_get')
get_some_objs(cluster_id=12, kind=db objects) will result in
HTTP request GET '/some/objects/12/really_get' data =
{'kind':'db objects'}
in case of class method it also extracts missing format parameters
from self.__dict__.
E.g.
node = Node.get_all()[0]
nnode = node.get() takes id from node.id
b) Auto generate API for strict restfull cases, e.g.
class Node(RestfulObj):
Represents node in Fuel
__url__ = '/api/nodes/{id}'
==
class Node(RestObj):
Represents node in Fuel
get_all = GET('/api/nodes')
get = GET('/api/nodes/{id}')
delete = DELETE('/api/nodes/{id}')
create = POST('/api/nodes/{id}')
2) API for create cluster from yaml description. Allow to deploy whole
openstack cluster from single yaml file. We being asking a lot whenever
this call would be available in fuel client
by different team/persons.
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
3) I have a semi-implemented ideas for future-based API for background
tasks (e.g. cluster deployment)
Code is available in repo and we would be glad to help you to merge it to
new fuel-client
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
__
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] [Heat] [Horizon] Precursor to Phase 1 Convergence
Horizon also needs the retry option. It solves a major problem specified in this blueprint: https://blueprints.launchpad.net/horizon/+spec/relaunch-failed-stack Regards, Nikunj -Original Message- From: Patil, Anant (HP Converged Cloud RD) Sent: Wednesday, January 14, 2015 5:54 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Heat] Precursor to Phase 1 Convergence On 09-Jan-15 19:19, Zane Bitter wrote: On 09/01/15 01:07, Angus Salkeld wrote: I am not in favor of the --continue as an API. I'd suggest responding to resource timeouts and if there is no response from the task, then re-start (continue) the task. Yeah, I am not in favour of a new API either. In fact, I believe we already have this functionality: if you do another update with the same template and parameters then it will break the lock and continue the update if the engine running the previous update has failed. And when we switch over to convergence it will still do the Right Thing without any extra implementation effort. There is one improvement we can make to the API though: in Juno, Ton added a PATCH method to stack update such that you can reuse the existing parameters without specifying them again. We should extend this to the template also, so you wouldn't have to supply any data to get Heat to start another update with the same template and parameters. I'm not sure if there is a blueprint for this already; co-ordinate with Ton if you are planning to work on it. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev IMHO, there are two different things here: 1. Failures external to Heat engine (or out-of-band failures). A convenient way to issue a stack-update on a stack that fails due to out-of-band failures is needed. When a stack fails due to service unavailability or infrastructure issues, operators/admins can fix those issues and then re-start the provisioning or tell users to restart. Currently, it is done by issuing a stack-update on the failed stack. It will be convenient to have an option to the stack-update command to retry the stack operation without having to specify the templates and parameters + environment again. User shouldn't need to supply any data again to start the update of failed stack. Folks working in Horizon would definitely need something like this. Horizon UI need not save a local copy of template and parameter + environment supplied by user, but rely on Heat because Heat already has the data. It would be convenient for Horizon to issue a --retry for stack-create or stack-update when the stack fails due to external problems that the operators/users fix. 2. Internal failures (or Heat engine failing). Continuing a stack operation even after a Heat engine fails due to internal error. I think Vishnu is talking about this part. When an engine fails, other engines should be able to take up the task of provisioning the stack without any user intervention. No new API or any option to stack-create or update is needed. Something like a periodic timer is needed to check if the engine provisioning a stack is up. If not, the lock is stolen and stack is restarted... may be by again issuing stack-update with same template and parameters. This is like an interim solution to continuous observer...the stack timer would periodically check for stacks that are stuck because the engine failed and issue another update or something equivalent to proceed with other Heat engines. Or as a first step, like Steve said, put the stack to FAILED state and let user initiate a stack-update (probably with the option specified 1). Please share your thoughts. - Anant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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] [horizon] static files handling, bower/
Solaris is supported by node.js: Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz I think Solaris is no longer relevant On Tue, Jan 13, 2015 at 7:13 PM, Drew Fisher drew.fis...@oracle.com wrote: On 1/13/15 7:59 AM, Jeremy Stanley wrote: On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. -Drew __ 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] [Glance] IRC logging
John Griffith wrote: Also just to reiterate something that Sean pointed out that's bugged me for a while proliferation of channels and what I view as limited usage of openstack-dev. Honestly I think it's more detrimental to have all the silos of communication going on as opposed to all of us actually working together in openstack-dev. Sub channels are great, but I think there are folks solving problems in their specific project that likely have already been solved elsewhere. Sure there's conversations that belong in a sub-channel but honestly maybe more should start in the dev channel and progress from there. At this point openstack-dev is only used for two things: cross-project discussions, and as a general directory of who is online. The second usage is fading as people no longer systematically join that channel. It's difficult to go back to a single channel, or to split discussions between the general channel and the team-oriented one. I would also like more activity on #openstack-dev, but I'm not sure how to trigger that. -- Thierry Carrez (ttx) __ 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] grenade failures
Mine in cinder failed too. https://review.openstack.org/#/c/143765/ Please check it, thanks. liu 新国刘 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: 地址：深圳市龙岗区坂田华为基地 邮编：518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China http://www.huawei.com 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! 发件人: yatin kumbhare [mailto:yatinkumbh...@gmail.com] 发送时间: 2015年1月14日 17:58 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] [Neutron] grenade failures Many of them on gerrit page. Mine is also one of them. https://review.openstack.org/#/c/145290/ Regards, Yatin On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com wrote: Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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: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] [Neutron] grenade failures
On 01/14/2015 10:58 AM, yatin kumbhare wrote: Many of them on gerrit page. Mine is also one of them. https://review.openstack.org/#/c/145290/ Regards, Yatin The cause is that nova-compute cannot start on stable/juno branch: http://logs.openstack.org/90/145290/2/check/check-grenade-dsvm-neutron/b328def/logs/old/screen-n-cpu.txt.gz I'm looking into this issue and will update once I have more info. Kuba On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe mailto: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://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] [fuel][client] new client implementation ideas
Igor,
Yep, I knew that you start to rewrite fuel-client, but it seemd for me that
this ideas is not for
https://etherpad.openstack.org/p/fuelclient-redesign document because it's
implementation details. Should I create a new notepad for it?
On Wed, Jan 14, 2015 at 11:58 AM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
Hi, Konstantin,
Thank you for sharing ideas. Your yet-one-more implementation of
fuel-client one more time confirms that currently we have completely
unusable implementation.
Just for your information: we have plans for python-fuelclient
refactoring [1]. The main point of this blueprint is to provide
fuelclient which will be useful as both: library and cli. Please, do
not hesitate share your ideas in blueprint or in the working ehterpad
[2].
- Igor
[1]: https://review.openstack.org/#/c/135915/
[2]: https://etherpad.openstack.org/p/fuelclient-redesign
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov
kdani...@mirantis.com wrote:
Hi all,
We are working on fuel certification script
https://github.com/stgleb/fuel-web
and have yet-one-more implementation of fuel-client, which cover very
small
of Fuel API, yet we have some ideas, which you might be interesting in.
1) high-level primitives for REST operations.
a) GET/PUT/POST/etc function, which returns closure, bonded to url
and
method
class Cluster(RestObj):
Class represents Cluster in Fuel
add_node_call = PUT('api/nodes')
start_deploy = PUT('api/clusters/{id}/changes')
get_status = GET('api/clusters/{id}')
delete = DELETE('api/clusters/{id}')
GET(url_template) returns function/class method, which accepts
set
of parameters,
format part of them into url_template to obtain final url and
pass
other parameters
as data in http request. E.g.
get_some_objs = GET('some/objects/{cluster_id}/really_get')
get_some_objs(cluster_id=12, kind=db objects) will result in
HTTP request GET '/some/objects/12/really_get' data =
{'kind':'db objects'}
in case of class method it also extracts missing format
parameters
from self.__dict__.
E.g.
node = Node.get_all()[0]
nnode = node.get() takes id from node.id
b) Auto generate API for strict restfull cases, e.g.
class Node(RestfulObj):
Represents node in Fuel
__url__ = '/api/nodes/{id}'
==
class Node(RestObj):
Represents node in Fuel
get_all = GET('/api/nodes')
get = GET('/api/nodes/{id}')
delete = DELETE('/api/nodes/{id}')
create = POST('/api/nodes/{id}')
2) API for create cluster from yaml description. Allow to deploy whole
openstack cluster from single yaml file. We being asking a lot whenever
this
call would be available in fuel client
by different team/persons.
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
3) I have a semi-implemented ideas for future-based API for background
tasks
(e.g. cluster deployment)
Code is available in repo and we would be glad to help you to merge it to
new fuel-client
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
__
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
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
__
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] [heat][tripleo] Making diskimage-builder install from forked repo?
On Tue, Jan 13, 2015 at 09:12:59AM +1300, Steve Baker wrote:
On 09/01/15 07:06, Gregory Haynes wrote:
Excerpts from Steven Hardy's message of 2015-01-08 17:37:55 +:
Hi all,
I'm trying to test a fedora-software-config image with some updated
components. I need:
- Install latest master os-apply-config (the commit I want isn't released)
- Install os-refresh-config fork from
https://review.openstack.org/#/c/145764
I can't even get the o-a-c from master part working:
export PATH=${PWD}/dib-utils/bin:$PATH
export
ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements
export DIB_INSTALLTYPE_os_apply_config=source
diskimage-builder/bin/disk-image-create vm fedora selinux-permissive \
os-collect-config os-refresh-config os-apply-config \
heat-config-ansible \
heat-config-cfn-init \
heat-config-docker \
heat-config-puppet \
heat-config-salt \
heat-config-script \
ntp \
-o fedora-software-config.qcow2
This is what I'm doing, both tools end up as pip installed versions AFAICS,
so I've had to resort to manually hacking the image post-DiB using
virt-copy-in.
Pretty sure there's a way to make DiB do this, but don't know what, anyone
able to share some clues? Do I have to hack the elements, or is there a
better way?
The docs are pretty sparse, so any help would be much appreciated! :)
Thanks,
Steve
Hey Steve,
source-repositories is your friend here :) (check out
dib/elements/source-repositires/README). One potential gotcha is that
because source-repositires is an element it really only applies to tools
used within images (and os-apply-config is used outside the image). To
fix this we have a shim in tripleo-incubator/scripts/pull-tools which
emulates the functionality of source-repositories.
Example usage:
* checkout os-apply-config to the ref you wish to use
* export DIB_REPOLOCATION_os_apply_config=/path/to/oac
* export DIB_REPOREF_os_refresh_config=refs/changes/64/145764/1
* start your devtesting
The good news is that devstack is already set up to do this. When
HEAT_CREATE_TEST_IMAGE=True devstack will build packages from the currently
checked-out os-*-config tools, build a pip repo and configure apache to
serve it.
Then the elements *should* install from these packages - we're not gating on
this functionality (yet) so its possible it has regressed but shouldn't be
too hard to get going again.
Thanks for this - after a small fix, it works great! :)
https://review.openstack.org/147109
It'd be good if we could expose image_elements as a variable, and provide a
little script which enables easy rebuilding of the image without
re-stacking. I'll probably take a look at both when I get time.
Steve
__
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]nova not work with eventlet 0.16.0
On Jan 14, 2015 10:09 PM, Dr. Jens Rosenboom j.rosenb...@x-ion.de wrote: Am 14/01/15 um 05:17 schrieb Adam Gandelman: So eventlet 0.16.x has started hitting slaves and breaking stable branches (its not like we weren't warned :\ ) https://bugs.launchpad.net/nova/+bug/1410626 Should hopefully be resolved by eventlet versions caps in icehouse + juno's requirements: https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z It was discussed already in the context of https://bugs.launchpad.net/nova/+bug/1407685 that capping eventlet would not be the proper solution, instead there is a fix already in master which has backports to icehouse + juno pending: https://review.openstack.org/#/c/145955/ https://review.openstack.org/#/c/146096/ Or is this new bug triggered by a different piece of code relating to the newly released eventlet 0.16.1? This is the same bug. Until we pick which fix to use all grenade jobs will fail. __ 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] [Neutron] grenade failures
Many of them on gerrit page. Mine is also one of them. https://review.openstack.org/#/c/145290/ Regards, Yatin On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo majop...@redhat.com wrote: Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ 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] [fuel][client] new client implementation ideas
Hi, Konstantin,
Thank you for sharing ideas. Your yet-one-more implementation of
fuel-client one more time confirms that currently we have completely
unusable implementation.
Just for your information: we have plans for python-fuelclient
refactoring [1]. The main point of this blueprint is to provide
fuelclient which will be useful as both: library and cli. Please, do
not hesitate share your ideas in blueprint or in the working ehterpad
[2].
- Igor
[1]: https://review.openstack.org/#/c/135915/
[2]: https://etherpad.openstack.org/p/fuelclient-redesign
On Wed, Jan 14, 2015 at 12:38 PM, Konstantin Danilov
kdani...@mirantis.com wrote:
Hi all,
We are working on fuel certification script
https://github.com/stgleb/fuel-web
and have yet-one-more implementation of fuel-client, which cover very small
of Fuel API, yet we have some ideas, which you might be interesting in.
1) high-level primitives for REST operations.
a) GET/PUT/POST/etc function, which returns closure, bonded to url and
method
class Cluster(RestObj):
Class represents Cluster in Fuel
add_node_call = PUT('api/nodes')
start_deploy = PUT('api/clusters/{id}/changes')
get_status = GET('api/clusters/{id}')
delete = DELETE('api/clusters/{id}')
GET(url_template) returns function/class method, which accepts set
of parameters,
format part of them into url_template to obtain final url and pass
other parameters
as data in http request. E.g.
get_some_objs = GET('some/objects/{cluster_id}/really_get')
get_some_objs(cluster_id=12, kind=db objects) will result in
HTTP request GET '/some/objects/12/really_get' data =
{'kind':'db objects'}
in case of class method it also extracts missing format parameters
from self.__dict__.
E.g.
node = Node.get_all()[0]
nnode = node.get() takes id from node.id
b) Auto generate API for strict restfull cases, e.g.
class Node(RestfulObj):
Represents node in Fuel
__url__ = '/api/nodes/{id}'
==
class Node(RestObj):
Represents node in Fuel
get_all = GET('/api/nodes')
get = GET('/api/nodes/{id}')
delete = DELETE('/api/nodes/{id}')
create = POST('/api/nodes/{id}')
2) API for create cluster from yaml description. Allow to deploy whole
openstack cluster from single yaml file. We being asking a lot whenever this
call would be available in fuel client
by different team/persons.
https://github.com/stgleb/fuel-web/blob/sertification-script/certification_script/certification_script/cert_script.py#L165
3) I have a semi-implemented ideas for future-based API for background tasks
(e.g. cluster deployment)
Code is available in repo and we would be glad to help you to merge it to
new fuel-client
--
Kostiantyn Danilov aka koder.ua
Principal software engineer, Mirantis
skype:koder.ua
http://koder-ua.blogspot.com/
http://mirantis.com
__
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] 答复: [devstack] Opensatck installation issue.
Hi all, For the past few days I have been trying to install Openstack through Devsatck on Ubuntu 13.10 14.04, but while installing I was getting the following errors: 1. *ERROR :* ln: failed to create symbolic link `/logs/screen/screen- key.log': No such file or directory 2. *ERROR :* mkdir: cannot create directory '/logs': Permission denied find: `/logs': No such file or directory Traceback (most recent call last): File /home/devstack/devstack/tools/outfilter.py, line 85, in module sys.exit(main()) File /home/devstack/devstack/tools/outfilter.py, line 53, in main outfile = open(opts.outfile, 'a', 0) IOError: [Errno 2] No such file or directory: '/logs/stack.sh.log.2015-01-14-144819' To find the root cause of this problem, I played with the $DEST variable on my local.conf file found the installation was running fine. But later I found that the problem was not actually the DEST variable, but it was something else. It was actually the shell script that I had created and was using for installing devstack was not able to write '$DEST' in the local.conf file. Error Code in my script: SCREEN_LOGDIR=$DEST/logs/screen LOGFILE=$DEST/logs/stack.sh.log Rectified Code of my script: SCREEN_LOGDIR=*\$DEST*/logs/screen LOGFILE=*\$DEST*/logs/stack.sh.log Now after rectifying my script the Openstack installation is working fine. Sorry for the confusion created earlier. On Mon, Jan 12, 2015 at 4:07 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: Its showing the same error on Ubuntu 13.10, so I think its not a Ubuntu Version issue. On Mon, Jan 12, 2015 at 4:02 PM, Amit Das amit@cloudbyte.com wrote: Is this related to the version of Ubuntu being used ? Its 12.04 as per the email. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Mon, Jan 12, 2015 at 3:55 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: I tried that also but still the error is same. On Mon, Jan 12, 2015 at 3:32 PM, Pasquale Porreca pasquale.porr...@dektech.com.au wrote: Since it seems a permission error, this may help: http://docs.openstack.org/developer/devstack/guides/single-machine.html#installation-shake-and-bake NB: in my environment I had to edit the file sudoers with a text editor (echoing the string didn't work). On 01/12/15 09:33, Abhishek Shrivastava wrote: Hi all, I am still getting the same error while installing the Openstack through devstack, If someone know the solution please reply. On Fri, Jan 9, 2015 at 1:53 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: Hi Liuxinguo, Thanks for the suggestion, I'll try and make it work. On Fri, Jan 9, 2015 at 1:24 PM, liuxinguo liuxin...@huawei.com wrote: Hi Abhishek, For the error in the first line: “mkdir: cannot create directory `/logs': Permission denied” and the error at the end: “ln: failed to create symbolic link `/logs/screen/screen-key.log': No such file or directory” The stack user does not have the permission on “/” so it can not create directory `/logs'. Please check the permission. liu *发件人:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] *发 送时间:* 2015年1月9日 15:26 *收件人:* OpenStack Development Mailing List (not for usage questions) *主题:* [openstack-dev] [devstack] Opensatck installation issue. Hi, I'm trying to install *Openstack *through* devstack master* on my *Ubuntu* *12.04 VM*, but it is failing and generating the following error. If anyone can help me resolving this issue please do reply. -- *Thanks Regards,* *Abhishek* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks Regards, * *Abhishek* -- *Thanks Regards, * *Abhishek* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Pasquale Porreca DEK Technologies Via dei Castelli Romani, 22 00040 Pomezia (Roma) Mobile +39 3394823805 Skype paskporr __ 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 -- *Thanks Regards,* *Abhishek* __ 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] [Fuel] Dropping Python-2.6 support
On 14 Jan 2015, at 09:18, Przemyslaw Kaminski pkamin...@mirantis.com wrote: I just made a general remark regarding why migrating to 2.7 is profitable (I understood Bartek's question this way). The point about Red Hat guaranteeing security fixes to 2.6 is a good one. Also, it's true we don't use SSL for fuelclient so yes, if other OpenStack projects keep 2.6 we should stick to it also. I have problems understanding this „SSL” case. It was just one example, and I mean security support in general. For me it does not matter that RH provides security fixes. They do it, because with their enterprise policies they need to. We could use their fixces, but in our case it would also require supporting other distros (Ubuntu for now). Regards, -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com __ 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] [glance] Replication on image create
On 1/14/15 1:38 AM, Flavio Percoco wrote: On 13/01/15 21:24 -0500, Jay Pipes wrote: On 01/13/2015 04:55 PM, Boden Russell wrote: Looking for some feedback from the glance dev team on a potential BP… This is the solution that I would recommend. Frankly, this kind of replication should be an async out-of-band process similar to bittorrent. Just have bittorrent or rsync or whatever replicate the image bits to a set of target locations and then call the glanceclient.v2.client.images.add_location() method: https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211 to add the URI of the replicated image bits. It recently landed in Glance an async workers engine (?) that allows for this kind of things to exists. For instance, it'll be used for image introspection to extract information from images after they have been *imported* into glance. The right hooks that trigger this async workers maybe need to be defined better but the infrastructure is there. Once that's more solid, you'll be able to write your own plugin that will do that job on every glance image import. While I understand the motivation for suggesting the out of band approach (async workers or separate process), my major concern here is the additional processing required. In my particular scenario this would require the out of band process to pull the image bits back down from the remote location and then push them back up to the replication locations. If the image size is decent, this could be a fairly expensive operation. Moreover an out of band process (IMO) would make for a less than optimal user experience as users would have to query the image locations metadata to understand if the image has replicated yet. Perhaps async workers improves this user experience a bit (can query worker status), but it still seems cleaner (IMO) to have the replication happen in-line with the image create flow. In a prototype I implemented #1 which can be done with no impact outside of the store driver code itself. I'm not entirely sure how you did that considering the http storage backend is readonly. Are you saying you implemented the add() method for the glance_store._drivers.http.Store class? I was trying to generalize my use case to other glance store drivers, but my generalization using the http store driver was obviously a poor choice... My interest and PoC is based on the VMware datastore driver. Let me ask more directly -- if we wanted to enhance the VMware datastore driver to support replication (as I described in approach #1 of my initial email) is this something the community would consider (assume changes are contained to the VMware datastore driver), or would such an enhancement be an uphill battle to get reviewed / merged? __ 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] [tc][python-clients] More freedom for all python clients
On 01/14/2015 03:55 AM, Flavio Percoco wrote: On 13/01/15 14:31 -0500, Sean Dague wrote: On 01/13/2015 02:10 PM, Jay Pipes wrote: On 01/13/2015 12:39 PM, Zane Bitter wrote: On 13/01/15 10:01, Jeremy Stanley wrote: On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote: Why doesn't rally just remove itself from projects.txt, then there would be no restrictions on what it adds. I second this recommendation. If Rally wants to depend on things which are not part of OpenStack and not required to run or test OpenStack in an official capacity (and since it's not an official OpenStack project it's entirely within its rights to want to do that), then forcing it to comply with the list of requirements for official OpenStack projects is an unnecessarily restrictive choice. FWIW I don't really agree with this advice. The purpose of openstack/requirements is to ensure that it's possible to create a distribution of OpenStack without conflicting version requirements, not to force every project to use every dependency listed. As such, some co-ordination around client libraries for related projects seems like it ought to be an uncontroversial addition. (Obviously it's easy to imagine potential additions that would legitimately be highly controversial, but IMHO this isn't one of them.) Saying that we require people to use our tools to get into the club but that our tools are not going to accommodate them in any way until they are in sounds a bit too close to Go away to my ears. +1 I think as we grow global-requirements probably needs to be broken up into functional lists. What's allowed in base-iass, what's allowed in application services, what's allowed in docs, etc, etc. The complexity of keeping the g-r list actually working goes up sort of n^2 as the size of it, because pip doesn't have a real solver. This is a barely functional set of plate spinning so just add everything misses the point that the breaks get more and more difficult to unwind. If someone is up for stepping up and contributing to breaking up into domains, please do. But I think while this remains a global list we really do need to be a bit careful here. Do we really need a per-domain g-r? With the upcoming changes in the openstack governance model, I believe this won't scale even if we break it into per-domain basis. Some questions that need answeres are: - Who's going to review the per domain g-r ? If it's a centralized team, then it won't definitely scale. If it's the domain team then, what's the real point of having these requirements? - How are we going to support the creation and maintnance of these g-r in the gate? Are they actually worth it? While I understand why we have g-r, I really don't think it'll scale for a broader community as we're envisioning it. With that in mind, I'd probably recommend to have 1 requirements group for the base-caas integrated gate and let other projects and groups have their own requirements. That is, non base-caas projects should get the versions of their common requirements from g-r so that they won't conflict if they're installed alongside with any of the base-caas projects. But other than those base requirements, I'd let non base-caas projects have what they need (which is pretty much what heat's team has done with the contrib packages, AFAICT). I know this opens the doors for version conflicts between the requirements of non base-caas projects but I think this is a more welcoming (and non-blocking) way to do things until we've a better one. Hope the above makes some sense I blame the lack of coffee if it doesn't, Flavio We have the base infrastructure of that in devstack today with a SOFT requirements update - https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704 If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft in your devstack run, we will leave extra dependencies untouched. Probably a few more bits required to make it really easy to expose, but that direction is also feasable. The reason I brought up domains though is that some groups really want the facility to have common requirements lists across a domain. Like the OpenStack Docs team. They've currently inserted a ton of stuff in g-r that really shouldn't be there because they have a lot of git trees, and the synchronization is a nice feature. However, if there were domain specific lists, that would be fine. A collection of projects that want to coordinate could all agree on a domain specific set of lists, and off we go. Maybe that list wouldn't even need to be contained in the main repo, it could be in a sub repo so have different approvers. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [tc][python-clients] More freedom for all python clients
Flavio, fyi, nova-docker is aspiring to be part of nova tree itself, but we had a couple of python libraries we needed for docker that are not in global, so we used the soft requirements to do that. https://github.com/stackforge/nova-docker/blob/master/contrib/devstack/gate_hook.sh#L16 thanks, dims On Wed, Jan 14, 2015 at 7:50 AM, Sean Dague s...@dague.net wrote: On 01/14/2015 03:55 AM, Flavio Percoco wrote: On 13/01/15 14:31 -0500, Sean Dague wrote: On 01/13/2015 02:10 PM, Jay Pipes wrote: On 01/13/2015 12:39 PM, Zane Bitter wrote: On 13/01/15 10:01, Jeremy Stanley wrote: On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote: Why doesn't rally just remove itself from projects.txt, then there would be no restrictions on what it adds. I second this recommendation. If Rally wants to depend on things which are not part of OpenStack and not required to run or test OpenStack in an official capacity (and since it's not an official OpenStack project it's entirely within its rights to want to do that), then forcing it to comply with the list of requirements for official OpenStack projects is an unnecessarily restrictive choice. FWIW I don't really agree with this advice. The purpose of openstack/requirements is to ensure that it's possible to create a distribution of OpenStack without conflicting version requirements, not to force every project to use every dependency listed. As such, some co-ordination around client libraries for related projects seems like it ought to be an uncontroversial addition. (Obviously it's easy to imagine potential additions that would legitimately be highly controversial, but IMHO this isn't one of them.) Saying that we require people to use our tools to get into the club but that our tools are not going to accommodate them in any way until they are in sounds a bit too close to Go away to my ears. +1 I think as we grow global-requirements probably needs to be broken up into functional lists. What's allowed in base-iass, what's allowed in application services, what's allowed in docs, etc, etc. The complexity of keeping the g-r list actually working goes up sort of n^2 as the size of it, because pip doesn't have a real solver. This is a barely functional set of plate spinning so just add everything misses the point that the breaks get more and more difficult to unwind. If someone is up for stepping up and contributing to breaking up into domains, please do. But I think while this remains a global list we really do need to be a bit careful here. Do we really need a per-domain g-r? With the upcoming changes in the openstack governance model, I believe this won't scale even if we break it into per-domain basis. Some questions that need answeres are: - Who's going to review the per domain g-r ? If it's a centralized team, then it won't definitely scale. If it's the domain team then, what's the real point of having these requirements? - How are we going to support the creation and maintnance of these g-r in the gate? Are they actually worth it? While I understand why we have g-r, I really don't think it'll scale for a broader community as we're envisioning it. With that in mind, I'd probably recommend to have 1 requirements group for the base-caas integrated gate and let other projects and groups have their own requirements. That is, non base-caas projects should get the versions of their common requirements from g-r so that they won't conflict if they're installed alongside with any of the base-caas projects. But other than those base requirements, I'd let non base-caas projects have what they need (which is pretty much what heat's team has done with the contrib packages, AFAICT). I know this opens the doors for version conflicts between the requirements of non base-caas projects but I think this is a more welcoming (and non-blocking) way to do things until we've a better one. Hope the above makes some sense I blame the lack of coffee if it doesn't, Flavio We have the base infrastructure of that in devstack today with a SOFT requirements update - https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704 If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft in your devstack run, we will leave extra dependencies untouched. Probably a few more bits required to make it really easy to expose, but that direction is also feasable. The reason I brought up domains though is that some groups really want the facility to have common requirements lists across a domain. Like the OpenStack Docs team. They've currently inserted a ton of stuff in g-r that really shouldn't be there because they have a lot of git trees, and the synchronization is a nice feature. However, if there were domain specific lists, that would be fine. A collection of projects that want to coordinate could all agree on a domain specific set of lists, and off we go. Maybe that list
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On 01/14/2015 07:58 AM, Ihar Hrachyshka wrote: On 01/14/2015 01:44 PM, Daniel P. Berrange wrote: On Wed, Jan 14, 2015 at 07:39:59AM -0500, Sean Dague wrote: On 01/14/2015 04:08 AM, Dr. Jens Rosenboom wrote: Am 14/01/15 um 05:17 schrieb Adam Gandelman: So eventlet 0.16.x has started hitting slaves and breaking stable branches (its not like we weren't warned :\ ) https://bugs.launchpad.net/nova/+bug/1410626 Should hopefully be resolved by eventlet versions caps in icehouse + juno's requirements: https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z It was discussed already in the context of https://bugs.launchpad.net/nova/+bug/1407685 that capping eventlet would not be the proper solution, instead there is a fix already in master which has backports to icehouse + juno pending: https://review.openstack.org/#/c/145955/ https://review.openstack.org/#/c/146096/ Or is this new bug triggered by a different piece of code relating to the newly released eventlet 0.16.1? Capping in stable/* is fine. A real openstack installation will not randomly rev all the dependent libraries to a latest version. Assuming that they will do so is misguided at best. There was real concern in getting master to work correctly, which was done. But for stable, capping is the right answer. The patch that went into master is pretty trivial really. I don't see a reason to not just copy that into stable too. Gate issues are complicated due to the fact that currently we have multiple failures for nova: 1) eventlet patch missing/eventlet not capped; 2) boto patch missing/boto not capped. Currently if you want to pass gate, you have two options: a) squash boto and eventlet patches and merge them in; b) merge in an update to requirements.txt that will cap both eventlet and boto. The latter seems to be more straightforward. If you are interested in making sure stable branches work ok with new boto/eventlet releases, you will have time to resolve it while gate will be in good shape and not broken (including master). After both boto and eventlet patches are merged in all stable branches, we may reconsider uncapping them. And also matches the fact that we've agreed that stable requirements are going to be fully capped, the implementation is just lagging on that. -Sean -- Sean Dague http://dague.net __ 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] [Keystone][Horizon] User self registration and management
Hi Adrian You might be glad to know that we have already produced a blueprint and implementation for this, based on federated keystone and Horizon. You can read the specs here https://blueprints.launchpad.net/keystone/+spec/vo-management and see a demo here http://icehouse.sec.cs.kent.ac.uk/ (However you will not be able to perform federated login without a Facebook or Google account, and you will also need the name of the VO role that you are to join, plus a secret/PIN - Contact me if you want one) Briefly, the administrator (could be keystone or domain admin) sets up a VO role, sends the details to the users who are to become members of it, along with a secret, and the user then logs in via his IdP (you can use Facebook or Google), quoting the secret and VO role. He is then enrolled in Keystone, either automatically, or pending admin approval (as a config option). The user can resign from the VO role anytime he wishes. I have updated your etherpad giving my comments regards David On 14/01/2015 05:06, Adrian Turjak wrote: Hello openstack-dev, I'm wondering if there is any interest or need for an open-source user registration and management service for people using OpenStack. We're currently at a point where we need a way for users to sign up themselves, choose their own password, and request new users to be added to their project. There doesn't seem to be anything out there, and most vendors seem to have built their own systems to handle this or even their own dashboard systems that do. Horizon is built around the client tools, and your own personal token, so it can't handle creating new users. Plus Keystone doesn't really have any good way of handling temporary (unapproved) users and projects. The suggested approach seems to be to build a service to sit along Keystone, have it's own admin creds so it can create new users, and also store temp user data locally until the user is approved. Unless we can find a suitable solution for us quickly, we're likely to be developing such a service. It would ideally have a pluggable approval workflow, allowing new user requests, new project requests, creation of clients in external client database/ERP systems. Plus it would have a password reset-token system for having new users supply their password once they are approved, which would also allow existing users to request password resets. Part of our requirements are easy to integrate into Horizon, fitting neatly into the OpenStack ecosystem along other services, and being easy to update/alter once we have hierarchical multi-tenancy and if it makes some things easier. I've written up a proposal to help us define our requirements, and a copy of that is attached, and on etherpad: https://etherpad.openstack.org/p/User_Management_Service Plus I've attached a couple of diagrams, which are sadly not UML, but should give you some idea of two of the primary use cases. Is this useful to anyone? Is this entirely the wrong approach? If it is a useful service is there any interest in collaboration? Thanks for any feedback. Cheers, -Adrian Turjak __ 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] [Heat] Precursor to Phase 1 Convergence
On 09-Jan-15 19:19, Zane Bitter wrote: On 09/01/15 01:07, Angus Salkeld wrote: I am not in favor of the --continue as an API. I'd suggest responding to resource timeouts and if there is no response from the task, then re-start (continue) the task. Yeah, I am not in favour of a new API either. In fact, I believe we already have this functionality: if you do another update with the same template and parameters then it will break the lock and continue the update if the engine running the previous update has failed. And when we switch over to convergence it will still do the Right Thing without any extra implementation effort. There is one improvement we can make to the API though: in Juno, Ton added a PATCH method to stack update such that you can reuse the existing parameters without specifying them again. We should extend this to the template also, so you wouldn't have to supply any data to get Heat to start another update with the same template and parameters. I'm not sure if there is a blueprint for this already; co-ordinate with Ton if you are planning to work on it. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev IMHO, there are two different things here: 1. Failures external to Heat engine (or out-of-band failures). A convenient way to issue a stack-update on a stack that fails due to out-of-band failures is needed. When a stack fails due to service unavailability or infrastructure issues, operators/admins can fix those issues and then re-start the provisioning or tell users to restart. Currently, it is done by issuing a stack-update on the failed stack. It will be convenient to have an option to the stack-update command to retry the stack operation without having to specify the templates and parameters + environment again. User shouldn't need to supply any data again to start the update of failed stack. Folks working in Horizon would definitely need something like this. Horizon UI need not save a local copy of template and parameter + environment supplied by user, but rely on Heat because Heat already has the data. It would be convenient for Horizon to issue a --retry for stack-create or stack-update when the stack fails due to external problems that the operators/users fix. 2. Internal failures (or Heat engine failing). Continuing a stack operation even after a Heat engine fails due to internal error. I think Vishnu is talking about this part. When an engine fails, other engines should be able to take up the task of provisioning the stack without any user intervention. No new API or any option to stack-create or update is needed. Something like a periodic timer is needed to check if the engine provisioning a stack is up. If not, the lock is stolen and stack is restarted... may be by again issuing stack-update with same template and parameters. This is like an interim solution to continuous observer...the stack timer would periodically check for stacks that are stuck because the engine failed and issue another update or something equivalent to proceed with other Heat engines. Or as a first step, like Steve said, put the stack to FAILED state and let user initiate a stack-update (probably with the option specified 1). Please share your thoughts. - Anant __ 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] [horizon] static files handling, bower/
On 13/01/15 16:13, Drew Fisher wrote: On 1/13/15 7:59 AM, Jeremy Stanley wrote: On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote: [...] But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. [...] A requirement for testing _is_ a requirement for deployment. If it's not tested, it's broken. If you're deploying software on a platform where it can't be tested then you're simply _hoping_ that it's not broken, and that is almost certainly a false hope. Exactly. We have to test this code base extensively before we package it up for Solaris. Under no circumstances do we just blindly repackage the releases and push them out to customers. Node.js is a total incompatibility for Solaris. If upstream moves to using Bower we'll be forced to look for alternatives at managing the JavaScript libraries. I have some bad news for you. Horizon already uses node.js for running jshint on its JavaScript files on the gate. Simply because there is no other alternative. You are welcome to work on and propose a better solution. -- Radomir Dopieralski __ 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] grenade failures
On 01/14/2015 11:15 AM, Jakub Libosvar wrote: On 01/14/2015 10:58 AM, yatin kumbhare wrote: Many of them on gerrit page. Mine is also one of them. https://review.openstack.org/#/c/145290/ Regards, Yatin The cause is that nova-compute cannot start on stable/juno branch: http://logs.openstack.org/90/145290/2/check/check-grenade-dsvm-neutron/b328def/logs/old/screen-n-cpu.txt.gz I'm looking into this issue and will update once I have more info. The failure is probably because of new eventlet release that broke libvirt driver. Should be fixed by: https://review.openstack.org/145955 Kuba On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: Hi Sukhdev, thanks, Can you post links to the specific patches? Miguel Ángel Ajo On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote: Hi All, I noticed that several neutron patches are failing check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response, thought I post it here. -Sukhdev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe mailto: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://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 __ 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]Openstack installation issue.
Hi all,
For the past few days I have been trying to install Openstack through
Devsatck on Ubuntu 13.10 14.04, but while installing I was getting the
following errors:
1. *ERROR :* ln: failed to create symbolic link `/logs/screen/screen-
key.log': No such file or directory
2. *ERROR :* mkdir: cannot create directory '/logs': Permission denied
find: `/logs': No such file or directory
Traceback (most recent call last):
File /home/devstack/devstack/tools/outfilter.py, line 85, in
module
sys.exit(main())
File /home/devstack/devstack/tools/outfilter.py, line 53, in
main
outfile = open(opts.outfile, 'a', 0)
IOError: [Errno 2] No such file or directory:
'/logs/stack.sh.log.2015-01-14-144819'
To find the root cause of this problem, I played with the $DEST variable on
my local.conf file found the installation was running fine.
But later I found that the problem was not actually the DEST variable, but
it was something else.
It was actually the shell script that I had created and was using for
installing devstack was not able to write '$DEST' in the local.conf file.
Error Code in my script:
SCREEN_LOGDIR=$DEST/logs/screen
LOGFILE=$DEST/logs/stack.sh.log
Rectified Code of my script:
SCREEN_LOGDIR=*\$DEST*/logs/screen
LOGFILE=*\$DEST*/logs/stack.sh.log
Now after rectifying my script the Openstack installation is working fine.
Sorry for the confusion created earlier.
On Mon, Jan 12, 2015 at 6:23 PM, Sean Dague s...@dague.net wrote:
Is your root filesystem full? The log clearly shows the chown stack
/etc/keystone passing right before the copy is attempted.
-Sean
On 01/12/2015 06:59 AM, Abhishek Shrivastava wrote:
Same as before.
On Mon, Jan 12, 2015 at 5:04 PM, Samta Rangare samtarang...@gmail.com
mailto:samtarang...@gmail.com wrote:
Whats the log now?
On Mon, Jan 12, 2015 at 4:53 PM, Abhishek Shrivastava
abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote:
Hi Samta,
Thanks for the suggestion but still problem remains the same.
On Mon, Jan 12, 2015 at 4:29 PM, Samta Rangare
samtarang...@gmail.com mailto:samtarang...@gmail.com wrote:
Hey abhishek,
As a quick fix to this problem, edit this file
devstack/lib/keystone +170
in this function
function configure_keystone {
edit this line with adding sudo
sudo cp -p $KEYSTONE_DIR/etc/keystone.conf.sample
$KEYSTONE_CONF
Regards
Samta
On Mon, Jan 12, 2015 at 4:01 PM, Abhishek Shrivastava
abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com
wrote:
Hi all,
I am writing this again because I am getting the same
error from past week while I'm installing Openstack
through devstack on Ubuntu 13.10.
I am attaching the new log file, please go through it
and if anyone can provide me the solution please do
reply.
--
*Thanks Regards,
*
*Abhishek*
__
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
*Thanks Regards,
*
*Abhishek*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
