Re: [openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit
Yes, let's discuss this in the meeting on Thursday. Carl On Oct 29, 2014 5:27 AM, Jaume Devesa devv...@gmail.com wrote: Hello, it seems like the BGP dynamic routing it is in a good shape to be included in Neutron during Kilo[1]. There is quite interest in offer BGP-VPN too. Mathieu Rohon's spec[2] goes in this direction. Of course it makes sense that his development leverages the BGP one. I would like to have a BoF session and invite anyone interested on these blueprints to join us or even add a new related one. I've created an etherpad[3] to share ideas and agree with session schedule. I propose Wednesday afternoon. If Carl Baldwin is agree, we can talk about it also during the open discussion of today's L3 subteam meeting. [1]: https://review.openstack.org/#/c/125401/ [ 2]: https://review.openstack.org/#/c/125401/ [3]: https://etherpad.openstack.org/p/bgp-vpn-dynamic-routing Cheers, -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Well, that we don't know, because the ballots are anonymized. So we can only make a stab at detecting partisan voting patterns, in the form a strict preference for candidates from one company over all others, but we've no way of knowing whether voters from those same companies actually cast the ballots in question. ... i.e. from these data, the conclusion that the preferred pairs of candidates were just more popular across-the-board would be equally valid. Conversely, we've no way of knowing if the voters employed by those under-represented companies you mention had a higher or lower turnout than the average. If there is a concern about balanced representation, then the biggest single change we could make to address this, IMO, would be to contest all TC seats at all elections. Staggered terms optimize for continuity, but by amplifying the majority voice (if such a thing exists in our case), they tend to pessimize for balanced representation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [All] [Openstack-docs] High Availability Guide Update - RFI
Hello All. We kicked off our first meeting yesterday the review of the HA guide.[1] We need to get the *current* HA model for each of the core components. It would be great if either the PTL of each project - (or someone else that has a definitive answer) could add their feedback to this query so we could start the ball rolling and collect the information. ** Just to clarify - this would be only for the OpenStack components and depending software (i.e. Databases and message queues etc..) not the underlying instances ** The requested information is: - Project Name - Active/Active or Active/Passive or both or other? - Suggested method of implementation - Additional info that you feel is relevant to add. [1] https://etherpad.openstack.org/p/openstack-haguide-update Thanks -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 10/30/2014 04:45 AM, Clint Byrum wrote: Excerpts from Jeremy Stanley's message of 2014-10-29 18:37:42 -0700: On 2014-10-29 18:27:48 -0700 (-0700), Clint Byrum wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
Code review is a vital part of the Openstack CI workflow, and as such the git repos managed by Openstack CI Gerrit are the authorative sources. It looks to me you don't want to have Gerrit to be the authorative git server to avoid doing code reviews in experiments or to share code among developers, but going down that route will put you in a situation hard to maintain, as Dolph alredy mentioned. I recommend you follow the same layout as upstream (Gerrit being the authorative git server with other git servers mirroring it) and you install something like GitLab to have your developers make experiments and long lived branches that they do not want to go thru code review for sharing. Regards 2014-10-29 22:43 GMT+01:00 Stefano Maffulli stef...@openstack.org: On 10/29/2014 07:02 AM, Ondrej Wisniewski wrote: If I understand correctly, we cannot use the OpenStack community Git servers as our central Git repository since developers cannot push to them. And we don't want to go through Gerrit and the code review procedure just to share a bit of code with somebody else in the team. Thus the need for a local mirror. I have been having similar questions as Dolph. Are you going to Paris by chance? It'd be great to have a chat in person and understand exactly your needs. Additionally also a local Gerrit server was set up to allow for internal code review within the team before submitting anything to the community server review.openstack.org http://review.openstack.org (which will be done eventually). As Dolph mentioned, you may be able to use review.openstack.org for that, keeping the patches as Work In Progress (workflow-1): your developers can all participate in the reviews and mark the change as 'Ready for review' when ready. This will allow you to stay close to trunk and avoid complex setup on your side. It also allows your developers to participate more in the 'openstack way' of doing things, maybe even do some code reviews for other patches while they're on review.openstack.org, it's less likely that your team will show up with a large patch after a long internal conversation. This is also helpful in case our Internet connection goes down, as we will still be able to follow the complete workflow inside the LAN. Fair enough: how often does your Internet connection drop? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. But that's just as likely to be a distortion caused by the free summit pass policy, so I'm not sure we could draw any solid conclusions on that basis. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
On Tue, Oct 28, 2014 at 21:50:09, Carl Baldwin wrote: Many API users won't care about the L2 details. This could be a compelling alternative for them. However, some do. The L2 details seem to matter an awful lot to many NFV use cases. It might be that this alternative is just not compelling for those. Not to say it isn't compelling overall though. Agreed. This is a point worth emphasising: routed networking is not a panacea for everyone's networking woes. We've got a lot of NFV people and products at my employer, and while we're engaged in work to come up with L3 approaches to solve their use-cases, we'd like to draw a balance between adding complexity to the network layer to support legacy L2-based requirements and providing better native L3 solutions that NFV applications can use instead. One of the key challenges with NFV is that it shouldn't just be a blind porting of existing codebases - you need to make sure you're producing something which takes advantage of the new environment. Cory ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
Hi Stefano and Dolph, since me and my team joined the OpenStack developer community just recently, I really appreciate your comments and suggestions. After all, we are here to learn. The current workflow we've set up might be a consequence of a different development model we were used to. Anyway we have no intention to isolate our development from the community and our contributions will surely be shared. Therefore we will review our way of working and make adjustments to follow more closely the community workflow. Ondrej ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] changing host name and /etc/hosts in container
Hello hackers, We are experimenting Sahara with Docker container (nova-docker) and ran into an issue that Sahara needs to change the host name and /etc/hosts which is not allowed in container. I am wondering if there is any easy way to work around this by hacking into Sahara? thanks, Zhidong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 10/30/2014 09:32 AM, Eoghan Glynn wrote:
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two elections prior to this one filtered out.
Well, the base electorate for the TC are active contributors with
patches landed to official projects within the past year, so these
are devs getting their code merged but not interested in voting.
This is somewhat different from (though potentially related to) the
dead weight foundation membership on the rolls for board
elections.
Also, foundation members who have not voted in two board elections
are being removed from the membership now, from what I understand
(we just needed to get to the point where we had two years worth of
board elections in the first place).
Thanks, I lost my mind here and confused the board with the TC.
So then my next question is, of those who did not vote, how many are
from under-represented companies? A higher percentage there might point
to disenfranchisement.
Different but related question (might be hard to calculate though):
If we remove people who have only ever landed one patch from the
electorate, what do the turnout numbers look like? 2? 5?
Do we have the ability to dig in slightly and find a natural definition
or characterization amongst our currently voting electorate that might
help us understand who the people are who do vote and what it is about
those people who might be or feel different or more enfranchised? I've
personally been thinking that the one-patch rule is, while tractable,
potentially strange for turnout - especially when one-patch also gets
you a free summit pass... but I have no data to say what actually
defined active in active technical contributor.
Again, the ballots are anonymized so we've no way of doing that analysis.
The best we could IIUC would be to analyze the electoral roll, bucketizing
by number of patches landed, to see if there's a significant long-tail of
potential voters with very few patches.
Just looking at stackalytices numbers for Juno: Out of 1556 committers,
1071 have committed more than one patch and 485 only a single patch.
That's a third!
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
How many of those cashed in their free pass?
On 30 October 2014 21:54, Andreas Jaeger a...@suse.com wrote:
On 10/30/2014 09:32 AM, Eoghan Glynn wrote:
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with voters who
missed the last two elections prior to this one filtered out.
Well, the base electorate for the TC are active contributors with
patches landed to official projects within the past year, so these
are devs getting their code merged but not interested in voting.
This is somewhat different from (though potentially related to) the
dead weight foundation membership on the rolls for board
elections.
Also, foundation members who have not voted in two board elections
are being removed from the membership now, from what I understand
(we just needed to get to the point where we had two years worth of
board elections in the first place).
Thanks, I lost my mind here and confused the board with the TC.
So then my next question is, of those who did not vote, how many are
from under-represented companies? A higher percentage there might point
to disenfranchisement.
Different but related question (might be hard to calculate though):
If we remove people who have only ever landed one patch from the
electorate, what do the turnout numbers look like? 2? 5?
Do we have the ability to dig in slightly and find a natural definition
or characterization amongst our currently voting electorate that might
help us understand who the people are who do vote and what it is about
those people who might be or feel different or more enfranchised? I've
personally been thinking that the one-patch rule is, while tractable,
potentially strange for turnout - especially when one-patch also gets
you a free summit pass... but I have no data to say what actually
defined active in active technical contributor.
Again, the ballots are anonymized so we've no way of doing that analysis.
The best we could IIUC would be to analyze the electoral roll, bucketizing
by number of patches landed, to see if there's a significant long-tail of
potential voters with very few patches.
Just looking at stackalytices numbers for Juno: Out of 1556 committers,
1071 have committed more than one patch and 485 only a single patch.
That's a third!
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On Thu, Oct 30, 2014 at 5:48 PM, Eoghan Glynn egl...@redhat.com wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Well, that we don't know, because the ballots are anonymized. So we can only make a stab at detecting partisan voting patterns, in the form a strict preference for candidates from one company over all others, but we've no way of knowing whether voters from those same companies actually cast the ballots in question. I'd love to see a rule that says you can't vote for people from your own company. That would turn things around :-) -A ... i.e. from these data, the conclusion that the preferred pairs of candidates were just more popular across-the-board would be equally valid. Conversely, we've no way of knowing if the voters employed by those under-represented companies you mention had a higher or lower turnout than the average. If there is a concern about balanced representation, then the biggest single change we could make to address this, IMO, would be to contest all TC seats at all elections. Staggered terms optimize for continuity, but by amplifying the majority voice (if such a thing exists in our case), they tend to pessimize for balanced representation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
Thanks Ricardo for your suggestion about GitLab. I am looking into this. Ondrej /On 10/30/2014 09:20 AM, Ricardo Carrillo Cruz wrote:// / Code review is a vital part of the Openstack CI workflow, and as such the git repos managed by Openstack CI Gerrit are the authorative sources. It looks to me you don't want to have Gerrit to be the authorative git server to avoid doing code reviews in experiments or to share code among developers, but going down that route will put you in a situation hard to maintain, as Dolph alredy mentioned. I recommend you follow the same layout as upstream (Gerrit being the authorative git server with other git servers mirroring it) and you install something like GitLab to have your developers make experiments and long lived branches that they do not want to go thru code review for sharing. Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hi, Can the VM migration happens across POD (Zone) ? If so then how reachability of VM is addressed dynamically without any packet loss ? Thanks Regards, keshava -Original Message- From: Wuhongning [mailto:wuhongn...@huawei.com] Sent: Thursday, October 30, 2014 7:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 30/10/2014 11:22, Angus Salkeld wrote: On Thu, Oct 30, 2014 at 5:48 PM, Eoghan Glynn egl...@redhat.com mailto:egl...@redhat.com wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Well, that we don't know, because the ballots are anonymized. So we can only make a stab at detecting partisan voting patterns, in the form a strict preference for candidates from one company over all others, but we've no way of knowing whether voters from those same companies actually cast the ballots in question. I'd love to see a rule that says you can't vote for people from your own company. That would turn things around :-) -A I think that hell would freeze over before that happens... Maish ... i.e. from these data, the conclusion that the preferred pairs of candidates were just more popular across-the-board would be equally valid. Conversely, we've no way of knowing if the voters employed by those under-represented companies you mention had a higher or lower turnout than the average. If there is a concern about balanced representation, then the biggest single change we could make to address this, IMO, would be to contest all TC seats at all elections. Staggered terms optimize for continuity, but by amplifying the majority voice (if such a thing exists in our case), they tend to pessimize for balanced representation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% So the proportion of single-patch committers is creeping up slowly, but not at a rate that would account for the decline in voter turnout. And since we've no way of knowing if voting patterns among the single-patch committers differs in any way from the norm, these data don't tell us much. If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% Correction, I skipped a cycle in that table: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.0% Grizzly | 630| 179 (28.4%) | 29.2% Folsom | 401| 120 (29.9%) | 27.9% Doesn't alter the trend though, still quite flat with some jitter and a small uptick. Cheers, Eoghan So the proportion of single-patch committers is creeping up slowly, but not at a rate that would account for the decline in voter turnout. And since we've no way of knowing if voting patterns among the single-patch committers differs in any way from the norm, these data don't tell us much. If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] How to connect to a serial port of an instance via websocket?
On Wed Oct 29 09:42:52 UTC 2014, Sahid Orentino Ferdjaoui wrote: The aim of the feature is exposing an interactive web-based serial consoles through a websocket proxy. The API returns an URL with a valid token that should be used with a websocket client to read/write on the stream. Considering the service nova-serialproxy is running and well configured you can use this simple test purpose client to connect yourself on the URL returned by the API: https://gist.github.com/sahid/894c31f306bebacb2207 The general idea behind this service is for example to help debugging VMs when something was wrong with the network configuration. Hi Sahid, thanks for your great example! When I execute it I get the error socket.error: [Errno 111] Connection refused How do I debug this? Did I miss a configuration? ./lazyclient.py ws://127.0.0.1:6083/?token=39262891-2588-4872-994b-3be9b7333fd7 Traceback (most recent call last): File ./lazyclient.py, line 27, in module ws.connect() File /usr/local/lib/python2.7/dist-packages/ws4py/client/__init__.py, line 209, in connect self.sock.connect(self.bind_addr) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 111] Connection refused ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP
I'm seeing the same error when trying to setup a whole new network
through Horizon with external gateway and an ipv4 and ipv6 subnet. Eg,
without floating ip.
l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Looking inside port[] lists the following items:
2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[name] =
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:profile] = {}
2014-10-30 10:26:05.854 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vnic_type] = normal
2014-10-30 10:26:05.856 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[fixed_ips] = [{u'subnet_id':
u'faaf9c91-19ce-4c14-8f86-c81949cdbac5', u'ip_address':
u'192.168.64.30'}, {u'subnet_id':
u'381d0c54-1a4e-4a27-9858-a81202e81487', u'ip_address':
u'2001:470::64::'}]
2014-10-30 10:26:05.857 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[id] = b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.858 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[security_groups] = []
2014-10-30 10:26:05.860 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_id] = d3bbec5a-2075-4229-ba88-698f27cd0943
_set_subnet_info() is set to log an ERROR when it encounters multiple
addresses and then happily continues doing something:
prefixlen = netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
port['ip_cidr'] = %s/%s % (ips[0]['ip_address'], prefixlen)
Operations with just 1 (ipv6) ip go without any issues, the adress is
added to a namespace and pongs just fine. Adding 2 subnets to this
external net and creating a gateway to it on the l3 router causes a problem.
Do we need to wait for K before we can fully go dual-stack?
- Harm
op 29-10-14 15:29, Jerry Xinyu Zhao schreef:
Hi
I want to use both ipv4 and ipv6 for floating ip at the same time.
However, I have the following issue when setting router gateway or
associate floating ip to an instance.
Is it supported in the first place? What should I do to make it work?
Thanks!
neutron router-list
+--++---+-+---+
| id | name |
external_gateway_info
|
distributed | ha|
+--++---+-+---+
| b243c786-4648-4d69-b749-ee5fad02069b | default-router |
{network_id: 02eca54a-420d-4d52-b045-1207e17994e5, enable_snat:
true, external_fixed_ips: [{subnet_id:
a188333f-77c3-40d9-9048-e733c4da30b1, ip_address: 162.3.123.51},
{subnet_id: 14d9dd91-b315-43bc-818d-ab21f62c1ebb, ip_address:
2001:470:1f0f:cb4::7}]} | False | False |
Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP
Unfortunately, it seems to be the case. Just saw there is a summit talk
about it called IPv6 Feature in Openstack Juno. Dual stack floating ip
support is planned in K.
However, I couldn't even get single IPv6 floating IP to work. Even though I
configured only IPv6 subnet for the external network, I got those errors
from neutron-l3-agent when associating the floating IP to instance.
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Command: ['sudo', '/usr/bin/neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec',
'qrouter-b243c786-4648-4d69-b749-ee5fad02069b', 'iptables-restore', '-c']
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Exit
code: 2
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Stdout: ''
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Stderr: iptables-restore v1.4.21: host/network `2001:470:1f0f:cb4::7' not
found\nError occurred at line: 39\nTry `iptables-restore -h' or
'iptables-restore --help' for more information.\n
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 10:55:32.407 30286 ERROR neutron.agent.linux.iptables_manager
[-] IPTablesManager.apply failed to apply the following set of iptables
rules:
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
1. # Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2. *raw
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
3. :PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
4. :OUTPUT ACCEPT [219:20352]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
5. :neutron-l3-agent-OUTPUT - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
6. :neutron-l3-agent-PREROUTING - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
7. [148546:23091816] -A PREROUTING -j neutron-l3-agent-PREROUTING
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
8. [219:20352] -A OUTPUT -j neutron-l3-agent-OUTPUT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
9. COMMIT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
10. # Completed on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
11. # Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
12. *mangle
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
13. :PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
14. :INPUT ACCEPT [55837:18978656]
On Thu, Oct 30, 2014 at 6:32 PM, Harm Weites h...@weites.com wrote:
I'm seeing the same error when trying to setup a whole new network
through Horizon with external gateway and an ipv4 and ipv6 subnet. Eg,
without floating ip.
l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Looking inside port[] lists the following items:
2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[name] =
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:profile] = {}
2014-10-30 10:26:05.854 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vnic_type] = normal
2014-10-30 10:26:05.856 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[fixed_ips] = [{u'subnet_id': u'faaf9c91-19ce-4c14-8f86-c81949cdbac5',
u'ip_address': u'192.168.64.30'}, {u'subnet_id':
u'381d0c54-1a4e-4a27-9858-a81202e81487',
Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion
As I found out there already is a change made by Xurong Yang that assigns conntrack zones to ports https://review.openstack.org/#/c/118274/6 If merged, it will make connection tracking easier and will allow to add functionality for closing connections after updating or deleting security group rules. I will try to add this functionality basing on the existing patch and see if it works. I believe that the change requires attention and discussion as there are some concerns regarding it. Perhaps somebody could take a look it? On Fri, Oct 24, 2014 at 9:28 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando sorla...@nicira.com wrote: Assigning a distinct ct zone to each port sounds more scalable. This should keep the number of zones per host Agree that zones could be a good solution to this problem. +1 to zone / port for scalability. Though it will take a bit more code and complexity to kill the right connections than it would with zone / rule. Once we identify the ports, and therefore the ct zones, then we'd still need to find the connections matching the rules which were removed. This does not sound like being too difficult, but it can result in searches over long lists - think about an instance hosting a DB or web server. Are you thinking of listing all connections and then iterating over the list with some code to match it to a security group rule being removed/updated? Or, map the security group rule to conntrack filter arguments to send to a call to conntrack -D? This could be problematic. What if security group rules were redundant and an update or removal of a rule should not really affect any existing connections? If all connections were compared instead against the set of *remaining* security group rules then this wouldn't be a problem. This sounds non-trivial to me. I'm probably thinking too hard about this. ;) The above two considerations made me suggest the idea of associating ct zones with rules, but it is probably true that this can cause us to go beyond the 2^16 limit. I agree we'd hit this limit. Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
Hi, w.r.t. ' VM packet forwarding' at L3 level by enabling routing I have below points. With below reference diagram , when the routing is enabled to detect the destination VM's compute node .. 1. How many route prefix will be injected in each of the compute node ? 2. For each of the VM address, there will be corresponding IP address in the 'L3 Forwarding Tbl' ? When we have large number of VM's of the order 50,000/ 1 Million VM's in the cloud each compute node needs to maintain 1 Million Route Entries ? 3. Even with route aggregations, it is not guaranteed to be very efficient because a. Tenants can span across computes. b. VM migration can happen which may break the aggregation and allow the growth of routing table. 4. Across Switch if we try to run BGP and try to aggregate, we will be introducing the Hierarchical Network. If any change in topology what will be convergence time and will there any looping issues ? Cost of the L3 switch will go up as the capacity of that switch to support 10,000 + routes. 5. With this we want to break the classical L2 broadcast in the last mile Cloud ? I was under the impression that the cloud network we want to keep simple L2 broadcast domain, without adding any complexity like MPLS label, Routing, Aggregation . 6. The whole purpose of brining VxLAN in datacenter cloud is to keep the L2 and even able to extend the L2 to different Datacenter. 7. I also saw some ietf draft w.r.t implementation architecture of OpenStack !!!. Let me know the opinion w.r.t. this ? [cid:image003.png@01CFF45F.51F2F0A0] Thanks regards, Keshava -Original Message- From: Fred Baker (fred) [mailto:f...@cisco.com] Sent: Wednesday, October 29, 2014 5:51 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking On Oct 28, 2014, at 4:59 PM, Angus Lees g...@inodes.orgmailto:g...@inodes.org wrote: On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote: Agreed. The way I'm thinking about this is that tenants shouldn't care what the underlying implementation is - L2 or L3. As long as the connectivity requirements are met using the model/API, end users should be fine. The data center network design should be an administrators decision based on the implementation mechanism that has been configured for OpenStack. I don't know anything about Project Calico, but I have been involved with running a large cloud network previously that made heavy use of L3 overlays. Just because these points weren't raised earlier in this thread: In my experience, a move to L3 involves losing: - broadcast/multicast. It's possible to do L3 multicast/IGMP/etc, but that's a whole can of worms - so perhaps best to just say up front that this is a non-broadcast network. - support for other IP protocols. - various L2 games like virtual MAC addresses, etc that NFV/etc people like. I'm a little confused. IP supports multicast. It requires a routing protocol, and you have to join the multicast group, but it's not out of the picture. What other IP protocols do you have in mind? Are you thinking about IPX/CLNP/etc? Or are you thinking about new network layers? I'm afraid the L2 games leave me a little cold. We have been there, such as with DECNET IV. I'd need to understand what you were trying to achieve before I would consider that a loss. We gain: - the ability to have proper hierarchical addressing underneath (which is a big one for scaling a single network). This itself is a tradeoff however - an efficient/strict hierarchical addressing scheme means VMs can't choose their own IP addresses, and VM migration is messy/limited/impossible. It does require some variation on a host route, and it leads us to ask about renumbering. The hard part of VM migration is at the application layer, not the network, and is therefore pretty much the same. - hardware support for dynamic L3 routing is generally universal, through a small set of mostly-standard protocols (BGP, ISIS, etc). - can play various L3 games like BGP/anycast, which is super useful for geographically diverse services. It's certainly a useful tradeoff for many use cases. Users lose some generality in return for more powerful cooperation with the provider around particular features, so I sort of think of it like a step halfway up the IaaS- PaaS stack - except for networking. - Gus Thanks Rohit From: Kevin Benton blak...@gmail.commailto:blak...@gmail.commailto:blak...@gmail.com%3cmailto:blak...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.opensta ck.org Date: Tuesday, October 28, 2014 1:01 PM To: OpenStack Development Mailing List (not for usage
Re: [openstack-dev] TC election by the numbers
Eoghan Glynn wrote: I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Haven't been able to run my analysis yet. I should be able to a few weeks after summit :) In complement to the partisan analysis you ran, one interesting analysis is to see how much the results would be different if we enable the proportional vote option in CIVS (which is designed to deter block voting). I'll do that one. The turnout rate continues to decline, in this case from 29.7% to 26.7%. Here's how the participation rates have shaped up since the first TC2.0 election: Election | Electorate | Voted | Turnout | Change 10/2013 | 1106 | 342 | 30.9% | -8.0% 04/2014 | 1510 | 448 | 29.7% | -4.1% 10/2014 | 1892 | 506 | 26.7% | -9.9% Overall percentage of the electorate voting is declining, but absolute numbers of voters has increased. And in fact, the electorate has grown more than the turnout has declined. True that, but AFAIK the generally accepted metric on participation rates in elections is turnout as opposed to absolute voter numbers. It's the generally-accepted metric in classic elections, which have a slow-growing electorate. I agree that a decline in global participation is not a good trend, but in our case I think it's more an artifact of our long tail of small contributors than true decline in interest in existing voters. What is *is* showing is that we grow the number of people who care about OpenStack governance at a smaller rate (+12%) than we grow raw contributors (+25%). -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FreeBSD host support
Monty Taylor wrote: On 10/27/2014 06:39 AM, Michael Still wrote: On Tuesday, October 21, 2014, Roman Bogorodskiy rbogorods...@mirantis.com wrote: On Mon, Oct 20, 2014 at 10:19 PM, Joe Gordon joe.gord...@gmail.com javascript:; wrote: On Sat, Oct 18, 2014 at 10:04 AM, Roman Bogorodskiy rbogorods...@mirantis.com javascript:; wrote: [snip] High level overview of what needs to be done: - Nova * linux_net needs to be re-factored to allow to plug in FreeBSD support (that's what the spec linked above is about) * nova.virt.disk.mount needs to be extended to support FreeBSD's mdconfig(8) in a similar way to Linux's losetup [snip] What about neutron? We are in the process of trying to deprecate nova-network, so any new thing needs to support neutron. AFAIK, there's no defined migration plan yet, unless I missed that. Anyway, I don't see any blockers regarding an implementation of a driver similar to linuxbridge that'd work on FreeBSD. Also, Semihalf guys are working on OpenContail/FreeBSD and Neutron/OpenContrial support, so that's an option as well. I have no problem with supporting FreeBSD as a hypervisor operating system, especially if there is a solid team on the FreeBSD side that will commit to maintaining the changes required and adding the necessary CI (especially ensuring that when it breaks it gets fixed). I believe that the CI related things that would be needed would be: - solid devstack support - someone willing to step up and make sure that nodepool can provide freebsd images like ianw recently did with centos Semihalf guys implemented FreeBSD support devstack as well (Michał CCed): https://github.com/Semihalf/openstack-devstack I don't know if they did an attempt to push these changes back. Creating FreeBSD images is not hard and I could do that. Anyway, there are some points regarding the CI that are not quite clear to me. - Should it be a 3rd party CI or integrated to the main CI? - At what point we want to start tempest/devstack testing over FreeBSD? I think it'll take quite some time to make these pass (maybe several release cycles). However, I see Neutron support as a firm requirement. We've spent a large amount of time getting closer and closer to deprecating nova-network. Despite opening it up for limited development again, I don't think we should be making the transition plan harder by introducing new features that don't work with Neutron. I agree with Mikal on this. Good. It doesn't look like a problem to me to bring the support into Neutron over nova-network. After a brief view the level of effort for the Neutron implementation is not much higher comparing to nova-network. Roman Bogorodskiy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
Monty Taylor wrote: Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. As a sidenote, we are a bit limited by the Foundation bylaws in tweaking what rules gives you the right to vote in the TC election. The members of the Technical Committee shall be elected by a vote of the Active Technical Contributors (“ATC”) using a fair voting method determined by the Technical Committee An Individual Member is an ATC who has had a software contribution approved for inclusion in any of the modules of the Core OpenStack Project during one of the two prior release cycles of the Core OpenStack Project (“Approved Contribution’). Such Individual Member shall remain an ATC for three hundred and sixty five days after the date of acceptance of such Approved Contribution. (from http://www.openstack.org/legal/technical-committee-member-policy/) We further define the ATC in the TC charter, so I guess we could redefine that a software contribution means at least 2 patches. It's harder to play with the 2-cycle timeframe without requiring a bylaws change, though. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hello, Keshava Live migration is allowed inside one pod ( one cascaded OpenStack instance ), not support cross pods live migration yet. But cold migration could be done between pods, even cross data centers. Live migration cross pods will be studied in the future. Best Regards Chaoyi Huang ( joehuang ) From: A, Keshava [keshav...@hp.com] Sent: 30 October 2014 17:45 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Can the VM migration happens across POD (Zone) ? If so then how reachability of VM is addressed dynamically without any packet loss ? Thanks Regards, keshava -Original Message- From: Wuhongning [mailto:wuhongn...@huawei.com] Sent: Thursday, October 30, 2014 7:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
Thank you very much, voted. - Original Message - On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery mest...@mestery.com wrote: As discussed during the neutron-drivers meeting this week [1], we've going to use one of the Neutron 40 minute design summit slots for lightning talks. The basic idea is we will have 6 lightning talks, each 5 minutes long. We will force a 5 minute hard limit here. We'll do the lightning talk round first thing Thursday morning. To submit a lightning talk, please add it to the etherpad linked here [2]. I'll be collecting ideas until after the Neutron meeting on Monday, 10-27-2014. At that point, I'll take all the ideas and add them into a Survey Monkey form and we'll vote for which talks people want to see. The top 6 talks will get a lightning talk slot. I'm hoping the lightning talks allow people to discuss some ideas which didn't get summit time, and allow for even new contributors to discuss their ideas face to face with folks. As discussed in the weekly Neutron meeting, I've setup a Survey Monkey to determine which 6 talks will get a slot for the Neutron Lightning Talk track at the Design Summit. Please go here [1] and vote. I'll collect results until Thursday around 2300UTC or so, and then close the poll and the top 6 choices will get a 5 minute lightning talk. Thanks! Kyle [1] https://www.surveymonkey.com/s/RLTPBY6 Thanks! Kyle [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2014/neutron_drivers.2014-10-22-15.02.log.html [2] https://etherpad.openstack.org/p/neutron-kilo-lightning-talks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively simple task. I also feel that using tempest-lib like this shouldn't be a hard requirement. Ideally the client definitions shouldn't have to live externally, or if they did they would be the official clients, but I am suggesting this as a first step to start a migration out of tempest. I don't want anyone to feel that they need block their functional testing efforts until tempest-lib becomes more useable. The larger value from functional testing is actually in enabling testing more tightly coupled to the projects (e.g. whitebox testing). I feel that any work necessary to enable functional testing should be prioritized. Thanks Matt for getting the ball rolling on this conversation in advance of summit. Probably stating the obvious here, but I feel we should make a concious effort to keep the approaches to in-tree functional testing as consistent as possible across projects. Towards that end, it would be good for folks with an interest in this area to attend each other's sessions where possible: Cross-project: Tue, 12:05 [1] Heat: Wed, 13:50 [2] Nova: Wed, 16:30 [3] Ceilometer:Wed, 17:20 [4] QA:Wed, 17:20 [5] Unfortunately there's a clash there between the QA tempest-lib session and the ceilo session. I'm not sure how reasonable it would be to make a last-minute schedule change to avoid that clash. Cheers, Eoghan [1] http://kilodesignsummit.sched.org/event/575938e4837e8293615845582d7e3e7f [2] http://kilodesignsummit.sched.org/event/eb261fb08b18ec1eaa2c67492e7fc385 [3] http://kilodesignsummit.sched.org/event/271a9075c1ced6c1269100ff4b8efc37 [4] http://kilodesignsummit.sched.org/event/daf63526a1883e84cec107c70cc6cad3 [5]
[openstack-dev] Writing a cinder volume driver
Hi All, I need to write a volume driver so that I can integrate our storage product into openstack. I have following questions about the sane, 1. How should I go about it? 2. I donnot know python. Is the python only way to write a driver? 3. I have setup openstack by following steps mentioned at http://docs.openstack.org/icehouse/install-guide/install/apt/content/. To test the drive do I also need to have a development environment ( http://docs.openstack.org/developer/cinder/devref/development.environment.html )? Thanks, Darshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] What's the hypervisor support matrix feature Service Control?
The hypervisor support matrix [1] lists a lot feaures. Some of them are explained and declared mandatory/optional in [2]. After reading these wiki pages, grepping the tempest and unit tests and searching in the mailing lists via markmail [3] I still cannot figure out what the feature service control is. What is this? How does a hypervisor verify that it supports this? [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix [2] https://wiki.openstack.org/wiki/HypervisorSupportMatrix/Requirements [3] http://openstack.markmail.org/ Regards, Markus Zoeller IRC: markus_z ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/29/2014 12:30 PM, Matthew Treinish wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I think a lot of the negative API testing is also a great thing to be done back at the project level. All of that testing should be able to work without a full OpenStack, as it should be caught and managed by the API service and never get any further than that. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I think we can see where this takes us. I'm still skeptical of cross project loading of tests because it's often quite fragile. However, if you look at what refstack did they had a giant evaluation of all of tempest and pruned a bunch of stuff out. I would imagine maybe there is a conversation there about tests that refstack feels are important to stay in Tempest for their validation reasons. I think having a few paths that are tested both in Tempest and in project functional tests is not a bad thing. But I think that's an end of cycle at best discussion. Also, there probably need to be a few discussions anyway of refstack/tempest/defcore. The fact that Keystone was dropped from defcore because there were no non admin Keystone tests explicitly in Tempest (even though we make over 5000 keystone non admin API calls over a tempest run) was very odd. That is something that could have been fixed in a day. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively simple task. I also feel that using tempest-lib like this shouldn't be a hard requirement. Ideally the client definitions shouldn't have to live externally, or if they did they would be the official clients, but I am suggesting this as a first step to start a migration out of tempest. I don't want anyone to feel that they need block their functional testing efforts until tempest-lib becomes more useable. The larger value from functional testing is actually in enabling testing more tightly coupled to the projects (e.g.
Re: [openstack-dev] Writing a cinder volume driver
Hi Darshan, Having just finished writing a volume driver i can say you need a lot of patience. First, to quickly answer your questions: 1. Read ALL the drivers in the official repo: ( https://github.com/openstack/cinder/tree/master/cinder/volume/drivers) and how they relate to the cinder-api ( https://github.com/openstack/cinder/tree/master/cinder/api); then look into (https://wiki.openstack.org/wiki/Cinder), especially the part about plugins and configuring devstack to user your driver and backend); 2. As far as i could tell, python is the only way. 3. You should try devstack (it's easier to setup, quicker, and always gives you latest code so you can develop against the latest version). After that, the rest is just bureaucracy :) (become a contributor, sign up for some services, get your code reviewed on gerrit, etc). Hope this helps, Eduard On Thu, Oct 30, 2014 at 1:37 PM, Darshan Ghumare darshan.ghum...@gmail.com wrote: Hi All, I need to write a volume driver so that I can integrate our storage product into openstack. I have following questions about the sane, 1. How should I go about it? 2. I donnot know python. Is the python only way to write a driver? 3. I have setup openstack by following steps mentioned at http://docs.openstack.org/icehouse/install-guide/install/apt/content/. To test the drive do I also need to have a development environment ( http://docs.openstack.org/developer/cinder/devref/development.environment.html )? Thanks, Darshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
Lot's of interesting talks. Thank you Kyle. Voted and looking forward. Fawad Khaliq On Thu, Oct 30, 2014 at 12:30 PM, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Thank you very much, voted. - Original Message - On Thu, Oct 23, 2014 at 3:22 PM, Kyle Mestery mest...@mestery.com wrote: As discussed during the neutron-drivers meeting this week [1], we've going to use one of the Neutron 40 minute design summit slots for lightning talks. The basic idea is we will have 6 lightning talks, each 5 minutes long. We will force a 5 minute hard limit here. We'll do the lightning talk round first thing Thursday morning. To submit a lightning talk, please add it to the etherpad linked here [2]. I'll be collecting ideas until after the Neutron meeting on Monday, 10-27-2014. At that point, I'll take all the ideas and add them into a Survey Monkey form and we'll vote for which talks people want to see. The top 6 talks will get a lightning talk slot. I'm hoping the lightning talks allow people to discuss some ideas which didn't get summit time, and allow for even new contributors to discuss their ideas face to face with folks. As discussed in the weekly Neutron meeting, I've setup a Survey Monkey to determine which 6 talks will get a slot for the Neutron Lightning Talk track at the Design Summit. Please go here [1] and vote. I'll collect results until Thursday around 2300UTC or so, and then close the poll and the top 6 choices will get a 5 minute lightning talk. Thanks! Kyle [1] https://www.surveymonkey.com/s/RLTPBY6 Thanks! Kyle [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2014/neutron_drivers.2014-10-22-15.02.log.html [2] https://etherpad.openstack.org/p/neutron-kilo-lightning-talks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
hi, Network reachability is not an issue for live migration, it is the same as cold. The challenge is near realtime order control of interaction between parent proxies, child virt drivers, agents, and libvirt lib. Wu Sent from my iPad On 2014-10-30, at 下午7:28, joehuang joehu...@huawei.com wrote: Hello, Keshava Live migration is allowed inside one pod ( one cascaded OpenStack instance ), not support cross pods live migration yet. But cold migration could be done between pods, even cross data centers. Live migration cross pods will be studied in the future. Best Regards Chaoyi Huang ( joehuang ) From: A, Keshava [keshav...@hp.com] Sent: 30 October 2014 17:45 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Can the VM migration happens across POD (Zone) ? If so then how reachability of VM is addressed dynamically without any packet loss ? Thanks Regards, keshava -Original Message- From: Wuhongning [mailto:wuhongn...@huawei.com] Sent: Thursday, October 30, 2014 7:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Sent from my iPad On 2014-10-30, at 下午8:05, Hly henry4...@gmail.com wrote: hi, Network reachability is not an issue for live migration, it is the same as cold. The challenge is near realtime order control of interaction between parent proxies, child virt drivers, agents, and libvirt lib. Wu Also it destroy the principle of only REST between POD, so we may study it in some special POC cases Sent from my iPad On 2014-10-30, at 下午7:28, joehuang joehu...@huawei.com wrote: Hello, Keshava Live migration is allowed inside one pod ( one cascaded OpenStack instance ), not support cross pods live migration yet. But cold migration could be done between pods, even cross data centers. Live migration cross pods will be studied in the future. Best Regards Chaoyi Huang ( joehuang ) From: A, Keshava [keshav...@hp.com] Sent: 30 October 2014 17:45 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Can the VM migration happens across POD (Zone) ? If so then how reachability of VM is addressed dynamically without any packet loss ? Thanks Regards, keshava -Original Message- From: Wuhongning [mailto:wuhongn...@huawei.com] Sent: Thursday, October 30, 2014 7:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] TC election by the numbers
On 10/30/2014 06:09 AM, Eoghan Glynn wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% So the proportion of single-patch committers is creeping up slowly, but not at a rate that would account for the decline in voter turnout. And since we've no way of knowing if voting patterns among the single-patch committers differs in any way from the norm, these data don't tell us much. If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. I am curious why you believe the staggering is dramatically changing the outcome of the elections. Because this is a condorcet system, and not a weighted one vote one, in a staggered election that would just mean that: Thierry, Vish, Jim, Mark, Jay, Michael, and Deva would be in the pool as well. Who I'd honestly expect to be ranked really highly (based on past election results, and based on their impact across a lot of projects). If there is some reference you have about why a race for 6 or 7 seats with 6 or 7 incumbents is considered less open than a race for 13 seats with 13 incumbents, would be great to see. Because to me, neither the math nor the psychology seem to support that. Note in both elections since we started open elections all incumbents that chose to run were re-elected. Which is approximately the same results we've seen in PTL elections (with only 1 exception that I know of). So that seems consistent with the rest of the community tone. We can argue separately whether we should be actively creating more turn over across the board, maybe we should be. But the TC doesn't seem massively out of line with the rest of the elections we do in the project. -Sean Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature
[openstack-dev] [Horizon] Separate horizon and openstack_dashboard
Hi, tl;dr: how to progreed in separating horizon and openstack_dashboard About a year ago now we agreed, it makes sense to separate horizon and openstack_dashboard. Thanks to Radomirs work in unbundling JavaScript libraries, we're finally there. It was decided to rename horizon to horizon_lib[1], and to rename openstack_dashboard to horizon. Now following[2]: The split: == code freeze -- no patches merged, except for the ones mentioned here, - rename horizon to horizon_lib, fix all corresponding imports, - rename openstack_dashboard to horizon, fix all corresponding imports, - clone the horizon repository using git-filter to skip the dashboard files, create an external repository on github for that, - add new project to openstack-infra/config called horizon_lib, with the new repo as the upstream, setup CI for the new project, - verify that the new repository works correctly, - remove the horizon_lib files from the old repository in one big commit, end of code freeze I tried that in [3], [4]. I renamed openstack_dashboard to openstack_horizon, rather than horizon to be sure, I really catched all imports etc., and to make sure, it's clear, what component is meant. During this process, the name horizon is a bit ambiguous. It was a somehow larger rework, just search and replace didn't do the job here, and I'm quite confident to have left one or the other thing untouched. There were quite a few additional code changes necessary, mostly due flake8 tests (renamed names are longer, breaking line length, horizon_lib and horizon are now separate, imports must be separated) So, how do we proceed from here? - how do we block the gate - how to create a new repo - how to set up ci for the new project? - how to integrate new horizon_lib and horizon (or openstack-horizon) to devstack Matthias [1] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037996.html [2] https://etherpad.openstack.org/p/horizon-split-plan [3] https://github.com/mrunge/openstack_horizon [4] https://github.com/mrunge/horizon_lib ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Hi Mike, I saw your comment on my review, but i need some more info regarding Your driver passes the cert test and the results are posted. I assume you mean running cinder_driver_cert.sh - this is already passing - but how do i get the results posted, and where? I've been looking through some documentation and couldn't find a definitive answer. Thanks Eduard On Thu, Oct 30, 2014 at 9:03 AM, Mike Perez thin...@gmail.com wrote: On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail
Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP
ipv6 floating Ip is currently not supported.
Check out this review and the associated bug:
https://review.openstack.org/#/c/131145/
—Robert
On 10/30/14, 6:47 AM, Jerry Xinyu Zhao
xyzje...@gmail.commailto:xyzje...@gmail.com wrote:
Unfortunately, it seems to be the case. Just saw there is a summit talk about
it called IPv6 Feature in Openstack Juno. Dual stack floating ip support is
planned in K.
However, I couldn't even get single IPv6 floating IP to work. Even though I
configured only IPv6 subnet for the external network, I got those errors from
neutron-l3-agent when associating the floating IP to instance.
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Command:
['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip',
'netns', 'exec', 'qrouter-b243c786-4648-4d69-b749-ee5fad02069b',
'iptables-restore', '-c']
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Exit code:
2
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Stdout: ''
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Stderr:
iptables-restore v1.4.21: host/network `2001:470:1f0f:cb4::7' not found\nError
occurred at line: 39\nTry `iptables-restore -h' or 'iptables-restore --help'
for more information.\n
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 2014-10-29
10:55:32.407 30286 ERROR neutron.agent.linux.iptables_manager [-]
IPTablesManager.apply failed to apply the following set of iptables rules:
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 1. #
Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 2.
*raw
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 3.
:PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 4.
:OUTPUT ACCEPT [219:20352]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 5.
:neutron-l3-agent-OUTPUT - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 6.
:neutron-l3-agent-PREROUTING - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 7.
[148546:23091816] -A PREROUTING -j neutron-l3-agent-PREROUTING
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 8.
[219:20352] -A OUTPUT -j neutron-l3-agent-OUTPUT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 9.
COMMIT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 10. #
Completed on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 11. #
Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 12.
*mangle
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 13.
:PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: 14.
:INPUT ACCEPT [55837:18978656]
On Thu, Oct 30, 2014 at 6:32 PM, Harm Weites
h...@weites.commailto:h...@weites.com wrote:
I'm seeing the same error when trying to setup a whole new network through
Horizon with external gateway and an ipv4 and ipv6 subnet. Eg, without floating
ip.
l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Looking inside port[] lists the following items:
2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK: port[name]
=
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:profile] = {}
2014-10-30
[openstack-dev] [Tripleo] os-cloud-config
Dear all, Seems like os-cloud-config is to initialise uncercloud or overcloud after heat orchestration. But I can not find how it is used in either tuskar, or tuskar-UI. So can anyone explain a little bit how it is used in TripleO projects? Thanks. Best RegardsLeslie Wang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 From: Nikhil Manchanda [nik...@manchanda.me] Sent: Thursday, October 30, 2014 3:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Hey Eduard, We posted our driver cert result by creating a new bugzilla ticket tagging that as driver-cert. https://bugs.launchpad.net/cinder/+bug/1380126 Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Oct 30, 2014 at 5:55 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Mike, I saw your comment on my review, but i need some more info regarding Your driver passes the cert test and the results are posted. I assume you mean running cinder_driver_cert.sh - this is already passing - but how do i get the results posted, and where? I've been looking through some documentation and couldn't find a definitive answer. Thanks Eduard On Thu, Oct 30, 2014 at 9:03 AM, Mike Perez thin...@gmail.com wrote: On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 On Thu, Oct 30, 2014 at 3:02 PM, Tim Simpson tim.simp...@rackspace.com wrote: +1 From: Nikhil Manchanda [nik...@manchanda.me] Sent: Thursday, October 30, 2014 3:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP
Thanks for the pointer.
On Thu, Oct 30, 2014 at 8:44 PM, Robert Li (baoli) ba...@cisco.com wrote:
ipv6 floating Ip is currently not supported.
Check out this review and the associated bug:
https://review.openstack.org/#/c/131145/
—Robert
On 10/30/14, 6:47 AM, Jerry Xinyu Zhao xyzje...@gmail.com wrote:
Unfortunately, it seems to be the case. Just saw there is a summit talk
about it called IPv6 Feature in Openstack Juno. Dual stack floating ip
support is planned in K.
However, I couldn't even get single IPv6 floating IP to work. Even though
I configured only IPv6 subnet for the external network, I got those errors
from neutron-l3-agent when associating the floating IP to instance.
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Command: ['sudo', '/usr/bin/neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec',
'qrouter-b243c786-4648-4d69-b749-ee5fad02069b', 'iptables-restore', '-c']
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent: Exit
code: 2
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Stdout: ''
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
Stderr: iptables-restore v1.4.21: host/network `2001:470:1f0f:cb4::7' not
found\nError occurred at line: 39\nTry `iptables-restore -h' or
'iptables-restore --help' for more information.\n
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2014-10-29 10:55:32.407 30286 ERROR neutron.agent.linux.iptables_manager
[-] IPTablesManager.apply failed to apply the following set of iptables
rules:
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
1. # Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
2. *raw
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
3. :PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
4. :OUTPUT ACCEPT [219:20352]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
5. :neutron-l3-agent-OUTPUT - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
6. :neutron-l3-agent-PREROUTING - [0:0]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
7. [148546:23091816] -A PREROUTING -j neutron-l3-agent-PREROUTING
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
8. [219:20352] -A OUTPUT -j neutron-l3-agent-OUTPUT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
9. COMMIT
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
10. # Completed on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
11. # Generated by iptables-save v1.4.21 on Wed Oct 29 10:55:32 2014
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
12. *mangle
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
13. :PREROUTING ACCEPT [148546:23091816]
Oct 29 10:55:32 overcloud-controller0-ghqtsmsgjgck neutron-l3-agent:
14. :INPUT ACCEPT [55837:18978656]
On Thu, Oct 30, 2014 at 6:32 PM, Harm Weites h...@weites.com wrote:
I'm seeing the same error when trying to setup a whole new network
through Horizon with external gateway and an ipv4 and ipv6 subnet. Eg,
without floating ip.
l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Looking inside port[] lists the following items:
2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[name] =
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 07:49 AM, Sean Dague wrote: On 10/29/2014 12:30 PM, Matthew Treinish wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I think a lot of the negative API testing is also a great thing to be done back at the project level. All of that testing should be able to work without a full OpenStack, as it should be caught and managed by the API service and never get any further than that. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I think we can see where this takes us. I'm still skeptical of cross project loading of tests because it's often quite fragile. However, if you look at what refstack did they had a giant evaluation of all of tempest and pruned a bunch of stuff out. I would imagine maybe there is a conversation there about tests that refstack feels are important to stay in Tempest for their validation reasons. I think having a few paths that are tested both in Tempest and in project functional tests is not a bad thing. Refstack is not the only thing that cares about validation of real clouds. As we move forward with this, it would be good to separate the issues of in which repo does a functional test live and can a functional test be run against a real cloud. IMO, over use of mocking (broadly defined) in functional tests should be avoided unless it is configurable to also work in an unmocked fashion. Whether the way to combine all of the functional tests is by cross project loading of tests or by some other means is more of an implementation detail. But I think that's an end of cycle at best discussion. Also, there probably need to be a few discussions anyway of refstack/tempest/defcore. The fact that Keystone was dropped from defcore because there were no non admin Keystone tests explicitly in Tempest (even though we make over 5000 keystone non admin API calls over a tempest run) was very odd. That is something that could have been fixed in a day. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively
Re: [openstack-dev] Writing a cinder volume driver
All excellent advice from Eduard. To confirm: - You will definitely need to write your driver in python. - Devstack is the recommended environment for development - Please look at the third party CI requirements for cinder drivers - these are an ongoing commitment The IRC channel #openstack-cinder on irc.freenode.net is the easiest way to chat to cinder developers realtime, please feel free to join us there. Welcome to the cinder community. -- Duncan Thomas On 30 October 2014 11:50, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Darshan, Having just finished writing a volume driver i can say you need a lot of patience. First, to quickly answer your questions: 1. Read ALL the drivers in the official repo: (https://github.com/openstack/cinder/tree/master/cinder/volume/drivers) and how they relate to the cinder-api (https://github.com/openstack/cinder/tree/master/cinder/api); then look into (https://wiki.openstack.org/wiki/Cinder), especially the part about plugins and configuring devstack to user your driver and backend); 2. As far as i could tell, python is the only way. 3. You should try devstack (it's easier to setup, quicker, and always gives you latest code so you can develop against the latest version). After that, the rest is just bureaucracy :) (become a contributor, sign up for some services, get your code reviewed on gerrit, etc). Hope this helps, Eduard On Thu, Oct 30, 2014 at 1:37 PM, Darshan Ghumare darshan.ghum...@gmail.com wrote: Hi All, I need to write a volume driver so that I can integrate our storage product into openstack. I have following questions about the sane, 1. How should I go about it? 2. I donnot know python. Is the python only way to write a driver? 3. I have setup openstack by following steps mentioned at http://docs.openstack.org/icehouse/install-guide/install/apt/content/. To test the drive do I also need to have a development environment (http://docs.openstack.org/developer/cinder/devref/development.environment.html)? Thanks, Darshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Eduard Biceri Matei, Senior Software Developer www.cloudfounders.com | eduard.ma...@cloudfounders.com CloudFounders, The Private Cloud Software Company Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me] Sent: October-30-14 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How to connect to a serial port of an instance via websocket?
The cause of this is that the serialproxy was not started. So nobody was listening to the port 6083. Validate with: $ netstat -nat | grep :608 tcp 0 0 0.0.0.0:6080 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6081 0.0.0.0:*LISTEN tcp 0 0 192.168.122.41:60858 192.168.122.41:5672 ESTABLISHED tcp 0 0 192.168.122.41:60859 192.168.122.41:5672 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60858 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60859 ESTABLISHED After finding [1] all I had to do was to start this proxy manually with: $ nova-serialproxy INFO nova.console.websocketproxy [-] WebSocket server settings: INFO nova.console.websocketproxy [-] - Listen on 0.0.0.0:6083 INFO nova.console.websocketproxy [-] - Flash security policy server INFO nova.console.websocketproxy [-] - No SSL/TLS support (no cert file) INFO nova.console.websocketproxy [-] - proxying from 0.0.0.0:6083 to None:None After executing this command, the `netstat` command from above shows a listener for port 6083: $ netstat -nat | grep :608 tcp 0 0 0.0.0.0:6080 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6081 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6083 0.0.0.0:*LISTEN tcp 0 0 192.168.122.41:60858 192.168.122.41:5672 ESTABLISHED tcp 0 0 192.168.122.41:60859 192.168.122.41:5672 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60858 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60859 ESTABLISHED By using Sahids websocketclient and the URI I got from the command `nova get-serial-console instance1` the connection gets established and one will see the login screen (e.g. from cirros). I was expecting the nova-serialproxy to start automatically when the section [serial_console] has the entry `enabled=True`. Is this a bug or do I have a wrong assumption here? Thanks again Sahid for your help! Thanks to Solly too, for offering JS help! [1] OpenStack Nova Developer Docs; Websocket serial Proxy for OpenStack Nova serial ports. ; http://docs.openstack.org/developer/nova/man/nova-serialproxy.html Markus Zoeller/Germany/IBM wrote on 10/30/2014 11:29:22 AM: From: Markus Zoeller/Germany/IBM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/30/2014 11:29 AM Subject: [nova] How to connect to a serial port of an instance via websocket? On Wed Oct 29 09:42:52 UTC 2014, Sahid Orentino Ferdjaoui wrote: The aim of the feature is exposing an interactive web-based serial consoles through a websocket proxy. The API returns an URL with a valid token that should be used with a websocket client to read/write on the stream. Considering the service nova-serialproxy is running and well configured you can use this simple test purpose client to connect yourself on the URL returned by the API: https://gist.github.com/sahid/894c31f306bebacb2207 The general idea behind this service is for example to help debugging VMs when something was wrong with the network configuration. Hi Sahid, thanks for your great example! When I execute it I get the error socket.error: [Errno 111] Connection refused How do I debug this? Did I miss a configuration? ./lazyclient.py ws://127.0.0.1:6083/?token=39262891-2588-4872-994b-3be9b7333fd7 Traceback (most recent call last): File ./lazyclient.py, line 27, in module ws.connect() File /usr/local/lib/python2.7/dist-packages/ws4py/client/ __init__.py, line 209, in connect self.sock.connect(self.bind_addr) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 111] Connection refused ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me] Sent: October-30-14 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 09:33 AM, David Kranz wrote: On 10/30/2014 07:49 AM, Sean Dague wrote: On 10/29/2014 12:30 PM, Matthew Treinish wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I think a lot of the negative API testing is also a great thing to be done back at the project level. All of that testing should be able to work without a full OpenStack, as it should be caught and managed by the API service and never get any further than that. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I think we can see where this takes us. I'm still skeptical of cross project loading of tests because it's often quite fragile. However, if you look at what refstack did they had a giant evaluation of all of tempest and pruned a bunch of stuff out. I would imagine maybe there is a conversation there about tests that refstack feels are important to stay in Tempest for their validation reasons. I think having a few paths that are tested both in Tempest and in project functional tests is not a bad thing. Refstack is not the only thing that cares about validation of real clouds. As we move forward with this, it would be good to separate the issues of in which repo does a functional test live and can a functional test be run against a real cloud. IMO, over use of mocking (broadly defined) in functional tests should be avoided unless it is configurable to also work in an unmocked fashion. Whether the way to combine all of the functional tests is by cross project loading of tests or by some other means is more of an implementation detail. Part of the perspective I'm bringing in is actually knowing what to do when your tests fail. Using Tempest against real clouds is great, people should keep doing that. But if you are rolling out a real cloud yourself, in the future you should be running the functional tests in staging to ensure you are functioning. Those will also provide you, hopefully, with a better path to understand what's wrong. This will mean that as an arbitrary 3rd party accessing a public cloud, you don't have a test suite that pushes every button of the cloud. But I think that's an acceptable trade off. Because pushing on odd edge cases might produce a fail, but if there is no
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 On October 30, 2014 at 4:47:06 AM, Nikhil Manchanda (nik...@manchanda.memailto:nik...@manchanda.me) wrote: Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. I am curious why you believe the staggering is dramatically changing the outcome of the elections. Well, I don't. In fact I've already stated the opposite in a prior discussion on TC election turnout[1]. So I don't think un-staggering the terms would dramatically alter the outcome, but I do think it would have a better chance of increasing the voter turnout, than say standardized questionnaires. The last few seats would be perceived as being in play to a greater extent IMO, hence increasing both voter interest, and possibly promoting slightly more balance in the representation. On the balance aspect, which does concern the outcome, the logic goes along the lines that the impact of the majority opinion is amplified by being applied *independently* to each staggered cohort ... e.g. the same voter can rate both Monty and Thierry, say, as their #1 preference. In the real world, I believe research suggests a weak correlation between simultaneous terms and representation of minorities in local government; some references can be found in [2] if interested, as per usual with academic research, paywalls abound :(. The applicability of such research to our scenario is, of course, questionable. This is one further quirk (bug?) in the design of TC2.0, that may tend to muddy the waters: the results of original TC2.0 election were used to determine the term cohorts, as opposed to a random selection. So the most popular candidates from that race who're still in the running end in competition with each other every second election, whereas the less popular remaining candidates contest the alternate elections. Switching to simultaneous terms would also remove that quirk (or fix that bug, depending on your PoV). Cheers, Eoghan [1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035832.html [2] http://books.google.ie/books?id=xSibrZC0XSQC Because this is a condorcet system, and not a weighted one vote one, in a staggered election that would just mean that: Thierry, Vish, Jim, Mark, Jay, Michael, and Deva would be in the pool as well. Who I'd honestly expect to be ranked really highly (based on past election results, and based on their impact across a lot of projects). If there is some reference you have about why a race for 6 or 7 seats with 6 or 7 incumbents is considered less open than a race for 13 seats with 13 incumbents, would be great to see. Because to me, neither the math nor the psychology seem to support that. Note in both elections since we started open elections all incumbents that chose to run were re-elected. Which is approximately the same results we've seen in PTL elections (with only 1 exception that I know of). So that seems consistent with the rest of the community tone. We can argue separately whether we should be actively creating more turn over across the board, maybe we should be. But the TC doesn't seem massively out of line with the rest of the elections we do in the project. -Sean Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 09:52 AM, Sean Dague wrote: On 10/30/2014 09:33 AM, David Kranz wrote: On 10/30/2014 07:49 AM, Sean Dague wrote: On 10/29/2014 12:30 PM, Matthew Treinish wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I think a lot of the negative API testing is also a great thing to be done back at the project level. All of that testing should be able to work without a full OpenStack, as it should be caught and managed by the API service and never get any further than that. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I think we can see where this takes us. I'm still skeptical of cross project loading of tests because it's often quite fragile. However, if you look at what refstack did they had a giant evaluation of all of tempest and pruned a bunch of stuff out. I would imagine maybe there is a conversation there about tests that refstack feels are important to stay in Tempest for their validation reasons. I think having a few paths that are tested both in Tempest and in project functional tests is not a bad thing. Refstack is not the only thing that cares about validation of real clouds. As we move forward with this, it would be good to separate the issues of in which repo does a functional test live and can a functional test be run against a real cloud. IMO, over use of mocking (broadly defined) in functional tests should be avoided unless it is configurable to also work in an unmocked fashion. Whether the way to combine all of the functional tests is by cross project loading of tests or by some other means is more of an implementation detail. Part of the perspective I'm bringing in is actually knowing what to do when your tests fail. Using Tempest against real clouds is great, people should keep doing that. But if you are rolling out a real cloud yourself, in the future you should be running the functional tests in staging to ensure you are functioning. Those will also provide you, hopefully, with a better path to understand what's wrong. Sean, sorry if I was unclear. By real clouds, I just meant the tests should be able to use OpenStack apis with no mocking. -David This will mean that as an arbitrary 3rd party accessing a public cloud, you don't have a test suite that pushes every button of the cloud. But I
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Thanks Amit, I'll do this as well. Eduard On Thu, Oct 30, 2014 at 3:09 PM, Amit Das amit@cloudbyte.com wrote: Hey Eduard, We posted our driver cert result by creating a new bugzilla ticket tagging that as driver-cert. https://bugs.launchpad.net/cinder/+bug/1380126 Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Oct 30, 2014 at 5:55 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Mike, I saw your comment on my review, but i need some more info regarding Your driver passes the cert test and the results are posted. I assume you mean running cinder_driver_cert.sh - this is already passing - but how do i get the results posted, and where? I've been looking through some documentation and couldn't find a definitive answer. Thanks Eduard On Thu, Oct 30, 2014 at 9:03 AM, Mike Perez thin...@gmail.com wrote: On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are
Re: [openstack-dev] TC election by the numbers
On Thu, Oct 30, 2014 at 08:11:59AM -0400, Sean Dague wrote: On 10/30/2014 06:09 AM, Eoghan Glynn wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% So the proportion of single-patch committers is creeping up slowly, but not at a rate that would account for the decline in voter turnout. And since we've no way of knowing if voting patterns among the single-patch committers differs in any way from the norm, these data don't tell us much. If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. I am curious why you believe the staggering is dramatically changing the outcome of the elections. Because this is a condorcet system, and not a weighted one vote one, in a staggered election that would just mean that: Thierry, Vish, Jim, Mark, Jay, Michael, and Deva would be in the pool as well. Who I'd honestly expect to be ranked really highly (based on past election results, and based on their impact across a lot of projects). If there is some reference you have about why a race for 6 or 7 seats with 6 or 7 incumbents is considered less open than a race for 13 seats with 13 incumbents, would be great to see. Because to me, neither the math nor the psychology seem to support that. Note in both elections since we started open elections all incumbents that chose to run were re-elected. Which is approximately the same results we've seen in PTL elections (with only 1 exception that I know of). So that seems consistent with the rest of the community tone. We can argue separately whether we should be actively creating more turn over across the board, maybe we should be. Well, FWIW, I think we should be, and I'd posit that the lack of turnover probably is one of the reasons for voter apathy. I'd hypothesise that smaller and/or newer projects probably do contain voters who feel disenfranchised, based on the historically
Re: [openstack-dev] [sahara] changing host name and /etc/hosts in container
Zhidong, Thanks for your question. I personally don't have an answer, but I think we definitely should bring up the possibility of dockerization for Sahara at the design summit next week. It may be something we want to formalize for Kilo. Will you be at the summit? Just to be clear, are you running Sahara itself in a container, or launching node instances in containers? I'll take a look and see if I can find anything useful about the ip assignment/hostname sequence for node instances during launch. Best, Trevor On Thu, 2014-10-30 at 16:46 +0800, Zhidong Yu wrote: Hello hackers, We are experimenting Sahara with Docker container (nova-docker) and ran into an issue that Sahara needs to change the host name and /etc/hosts which is not allowed in container. I am wondering if there is any easy way to work around this by hacking into Sahara? thanks, Zhidong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How to connect to a serial port of an instance via websocket?
The serial proxy will not automatically start. It's intended to be started as a service, just the like API, VNC proxy, or SPICE proxy. Best Regards, Solly Ross - Original Message - From: Markus Zoeller mzoel...@de.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, October 30, 2014 9:45:08 AM Subject: Re: [openstack-dev] [nova] How to connect to a serial port of an instance via websocket? The cause of this is that the serialproxy was not started. So nobody was listening to the port 6083. Validate with: $ netstat -nat | grep :608 tcp 0 0 0.0.0.0:6080 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6081 0.0.0.0:*LISTEN tcp 0 0 192.168.122.41:60858 192.168.122.41:5672 ESTABLISHED tcp 0 0 192.168.122.41:60859 192.168.122.41:5672 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60858 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60859 ESTABLISHED After finding [1] all I had to do was to start this proxy manually with: $ nova-serialproxy INFO nova.console.websocketproxy [-] WebSocket server settings: INFO nova.console.websocketproxy [-] - Listen on 0.0.0.0:6083 INFO nova.console.websocketproxy [-] - Flash security policy server INFO nova.console.websocketproxy [-] - No SSL/TLS support (no cert file) INFO nova.console.websocketproxy [-] - proxying from 0.0.0.0:6083 to None:None After executing this command, the `netstat` command from above shows a listener for port 6083: $ netstat -nat | grep :608 tcp 0 0 0.0.0.0:6080 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6081 0.0.0.0:*LISTEN tcp 0 0 0.0.0.0:6083 0.0.0.0:*LISTEN tcp 0 0 192.168.122.41:60858 192.168.122.41:5672 ESTABLISHED tcp 0 0 192.168.122.41:60859 192.168.122.41:5672 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60858 ESTABLISHED tcp6 0 0 192.168.122.41:5672 192.168.122.41:60859 ESTABLISHED By using Sahids websocketclient and the URI I got from the command `nova get-serial-console instance1` the connection gets established and one will see the login screen (e.g. from cirros). I was expecting the nova-serialproxy to start automatically when the section [serial_console] has the entry `enabled=True`. Is this a bug or do I have a wrong assumption here? Thanks again Sahid for your help! Thanks to Solly too, for offering JS help! [1] OpenStack Nova Developer Docs; Websocket serial Proxy for OpenStack Nova serial ports. ; http://docs.openstack.org/developer/nova/man/nova-serialproxy.html Markus Zoeller/Germany/IBM wrote on 10/30/2014 11:29:22 AM: From: Markus Zoeller/Germany/IBM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/30/2014 11:29 AM Subject: [nova] How to connect to a serial port of an instance via websocket? On Wed Oct 29 09:42:52 UTC 2014, Sahid Orentino Ferdjaoui wrote: The aim of the feature is exposing an interactive web-based serial consoles through a websocket proxy. The API returns an URL with a valid token that should be used with a websocket client to read/write on the stream. Considering the service nova-serialproxy is running and well configured you can use this simple test purpose client to connect yourself on the URL returned by the API: https://gist.github.com/sahid/894c31f306bebacb2207 The general idea behind this service is for example to help debugging VMs when something was wrong with the network configuration. Hi Sahid, thanks for your great example! When I execute it I get the error socket.error: [Errno 111] Connection refused How do I debug this? Did I miss a configuration? ./lazyclient.py ws://127.0.0.1:6083/?token=39262891-2588-4872-994b-3be9b7333fd7 Traceback (most recent call last): File ./lazyclient.py, line 27, in module ws.connect() File /usr/local/lib/python2.7/dist-packages/ws4py/client/ __init__.py, line 209, in connect self.sock.connect(self.bind_addr) File /usr/lib/python2.7/socket.py, line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 111] Connection refused ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 10:02 AM, David Kranz wrote: On 10/30/2014 09:52 AM, Sean Dague wrote: On 10/30/2014 09:33 AM, David Kranz wrote: On 10/30/2014 07:49 AM, Sean Dague wrote: On 10/29/2014 12:30 PM, Matthew Treinish wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. I think a lot of the negative API testing is also a great thing to be done back at the project level. All of that testing should be able to work without a full OpenStack, as it should be caught and managed by the API service and never get any further than that. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I think we can see where this takes us. I'm still skeptical of cross project loading of tests because it's often quite fragile. However, if you look at what refstack did they had a giant evaluation of all of tempest and pruned a bunch of stuff out. I would imagine maybe there is a conversation there about tests that refstack feels are important to stay in Tempest for their validation reasons. I think having a few paths that are tested both in Tempest and in project functional tests is not a bad thing. Refstack is not the only thing that cares about validation of real clouds. As we move forward with this, it would be good to separate the issues of in which repo does a functional test live and can a functional test be run against a real cloud. IMO, over use of mocking (broadly defined) in functional tests should be avoided unless it is configurable to also work in an unmocked fashion. Whether the way to combine all of the functional tests is by cross project loading of tests or by some other means is more of an implementation detail. Part of the perspective I'm bringing in is actually knowing what to do when your tests fail. Using Tempest against real clouds is great, people should keep doing that. But if you are rolling out a real cloud yourself, in the future you should be running the functional tests in staging to ensure you are functioning. Those will also provide you, hopefully, with a better path to understand what's wrong. Sean, sorry if I was unclear. By real clouds, I just meant the tests should be able to use OpenStack apis with no mocking. Ok, so part of this remains to be
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On Thu, Oct 30, 2014 at 6:30 AM, Eoghan Glynn egl...@redhat.com wrote: Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think they'll eventually come together. Currently in tempest we have a large number of tests (mostly api-focused) which are probably a better fit for a project's functional test suite. The best example I can think of is the nova flavors tests. Validation of flavor manipulation doesn't need to run in the integrated test suite on every commit to every project because it only requires Nova. A simple win for initiating in-tree functional testing would be to move these kinds of tests into the projects and run the tests from the project repos instead of from tempest. This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. As tests are moved tempest can start to become the integration test suite it was meant to be. It would retain only tests that involve multiple projects and stop being the OpenStack black box testing suite. I think that this is the right direction for tempest moving forward, especially as we move to having project-specific functional testing. Doing this migration is dependent on some refactors in tempest and moving the required bits to tempest-lib so they can be easily consumed by the other projects. This will be discussed at summit, is being planned for implementation this cycle, and is similar to what is currently in progress for the cli tests. The only reason this testing existed in tempest in the first place was as mechanism to block and then add friction against breaking api changes. Tempest's api testing has been been pretty successful at achieving these goals. We'll want to ensure that migrated tests retain these characteristics. If we are using clients from tempest-lib we should get this automatically since to break the api you'd have to change the api client. Another option proposed was to introduce a hacking rule that would block changes to api tests at the same time other code was being changed. There is also a concern for external consumers of tempest if we move the tests out of the tempest tree (I'm thinking refstack). I think the solution is to maintain a load_tests discovery method inside of tempest or elsewhere that will run the appropriate tests from the other repos for something like refstack. Assuming that things are built in a compatible way using the same framework then running the tests from separate repos should be a simple matter of pointing the test runner in the right direction. I also want to comment on the role of functional testing. What I've proposed here is only one piece of what project specific functional testing should be and just what I feel is a good/easy start. I don't feel that this should be the only testing done in the projects. I'm suggesting this as a first step because the tests already exist and it should be a relatively simple task. I also feel that using tempest-lib like this shouldn't be a hard requirement. Ideally the client definitions shouldn't have to live externally, or if they did they would be the official clients, but I am suggesting this as a first step to start a migration out of tempest. I don't want anyone to feel that they need block their functional testing efforts until tempest-lib becomes more useable. The larger value from functional testing is actually in enabling testing more tightly coupled to the projects (e.g. whitebox testing). I feel that any work necessary to enable functional testing should be prioritized. Thanks Matt for getting the ball rolling on this conversation in advance of summit. Probably stating the obvious here, but I feel we should make a concious effort to keep the approaches to in-tree functional testing as consistent as possible across projects. Towards that end, it would be good for folks with an interest in this area to attend each other's sessions where possible: +1 Cross-project: Tue, 12:05 [1] Heat: Wed, 13:50 [2] Nova: Wed, 16:30 [3] Ceilometer:Wed, 17:20 [4] QA:Wed, 17:20 [5] I think Keystone was planning on dedicating some time to this on Friday, so our dev/hackathon day. I'm interested in the process that will be in place for tracking status of the functional test migration if there will be one. Unfortunately there's a clash there between the QA tempest-lib session and the ceilo session. I'm not sure how reasonable it would be to make a last-minute schedule
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 | -Original Message- | From: Nikhil Manchanda [mailto:nik...@manchanda.me] | Sent: Thursday, October 30, 2014 4:47 AM | To: OpenStack Development Mailing List (not for usage questions) | Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core | | Hello folks: | | I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. | | Iccha has been working with Trove for a while now. She has been a very | active reviewer, and has provided insightful comments on numerous reviews. | She has submitted quality code for multiple bug-fixes in Trove, and most | recently drove the per datastore volume support BP in Juno. She was also a | crucial part of the team that implemented replication in Juno, and helped | close out multiple replication related issues during Juno-3. | | https://review.openstack.org/#/q/reviewer:iccha,n,z | https://review.openstack.org/#/q/owner:iccha,n,z | | Please respond with +1/-1, or any further comments. | | Thanks, | Nikhil | | ___ | OpenStack-dev mailing list | OpenStack-dev@lists.openstack.org | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] OpenStack Bootstrapping Hour - next talk and summit
We'll be skipping a few weeks on the OpenStack Bootstrapping Hour (https://wiki.openstack.org/wiki/BootstrappingHour) due to Summit and travel by people on both ends. The next one will be on Nov 21st talking about how to debug gate failures. I'd encourage anyone that's got feedback for OpenStack Bootstrapping Hour so far to please find me, Jay, or Dan at summit to chat about it. During the Booth / Pub crawl on Monday I'll be at the Expert Bar in the HP booth from 17:50 - 18:45pm, so if no other time, that's where you can be guaranteed that I'll be stationary, in a known place, and love to talk with people about anything OpenStack related, which OpenStack Bootstrapping Hour definitely fits into. Hope to see many of your in Paris! -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 From: Peter Stachowski pe...@tesora.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/30/2014 08:45 AM Subject:Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core +1 -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me] Sent: October-30-14 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
Matthew wrote: This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. [much snipping] Sean wrote: Ok, so part of this remains to be seen about what the biggest bang for the buck is. The class of bugs I feel like we need to nail in Nova right now are going to require tests that bring up pieces of the wsgi stack, but are probably not runable on a real deploy. Again, this is about debugability. So this notion of the biggest bang for our buck is an aspect of the drive for in-tree functional tests, that's not entirely clear to me as yet. i.e. whether individual projects should be prioritizing within this effort: (a) the creation of net-new coverage for scenarios (especially known or suspected bugs) that were not previously tested, in a non-unit sense (b) the relocation of existing integration test coverage from Tempest to the project trees, in order to make the management of Tempest more tractable It feels like there may be a tension between (a) and (b) in terms of the pay-off for this effort. I'd interested in hearing other opinions on this, on what aspect projects are expecting (and expected) to concentrate on initially. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 On Thu, Oct 30, 2014 at 9:42 AM, Mariam John mari...@us.ibm.com wrote: +1 [image: Inactive hide details for Peter Stachowski ---10/30/2014 08:45:43 AM---+1 -Original Message-]Peter Stachowski ---10/30/2014 08:45:43 AM---+1 -Original Message- From: Peter Stachowski pe...@tesora.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/30/2014 08:45 AM Subject: Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core -- +1 -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me nik...@manchanda.me] Sent: October-30-14 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 -Original Message- From: Nikhil Manchanda [mailto:nik...@manchanda.me] Sent: October-30-14 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5315 / Virus Database: 4189/8475 - Release Date: 10/29/14 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 10:47 AM, Eoghan Glynn wrote: Matthew wrote: This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. [much snipping] Sean wrote: Ok, so part of this remains to be seen about what the biggest bang for the buck is. The class of bugs I feel like we need to nail in Nova right now are going to require tests that bring up pieces of the wsgi stack, but are probably not runable on a real deploy. Again, this is about debugability. So this notion of the biggest bang for our buck is an aspect of the drive for in-tree functional tests, that's not entirely clear to me as yet. i.e. whether individual projects should be prioritizing within this effort: (a) the creation of net-new coverage for scenarios (especially known or suspected bugs) that were not previously tested, in a non-unit sense (b) the relocation of existing integration test coverage from Tempest to the project trees, in order to make the management of Tempest more tractable It feels like there may be a tension between (a) and (b) in terms of the pay-off for this effort. I'd interested in hearing other opinions on this, on what aspect projects are expecting (and expected) to concentrate on initially. For what it's worth I have a bunch of early targets listed for Nova for our summit session - https://etherpad.openstack.org/p/kilo-nova-functional-testing My focus in kilo is going to be first about A), as that provides value out of the gate (pun intended). Then peel off some stuff from B as makes sense. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 From: Nikhil Manchanda nik...@manchanda.me Sent: Thursday, October 30, 2014 4:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Friday Meetup pod reservation etherpad
I've setup an etherpad [1] where people can feel free to grab a 45 minute slot for Friday at the Summit. Please follow the instructions on the format for making your reservation. I expect the time limits to be self enforcing, so please be conscious of the next group of people who want time to discuss their ideas. Thanks! Kyle [1] https://etherpad.openstack.org/p/neutron-kilo-meetup-slots ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
+1 On Oct 30, 2014, at 1:47 AM, Nikhil Manchanda nik...@manchanda.me wrote: Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit
I have reserved the 2:35 slot for Friday. https://etherpad.openstack.org/p/neutron-kilo-meetup-slots -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
Hi Cory, Here NFV-Apps will use the infrastructure' L3 Route table' to make any decision ? From OpenStack perspective NFV-App(VM) is not like any other Tennant-VM as for as delivering the packet is concerned ? Is there any thinking of NFV-App ( Service router VM) to insert any routing information in OpenStack infrastructure ? Thanks Regards, keshava -Original Message- From: Cory Benfield [mailto:cory.benfi...@metaswitch.com] Sent: Thursday, October 30, 2014 2:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking On Tue, Oct 28, 2014 at 21:50:09, Carl Baldwin wrote: Many API users won't care about the L2 details. This could be a compelling alternative for them. However, some do. The L2 details seem to matter an awful lot to many NFV use cases. It might be that this alternative is just not compelling for those. Not to say it isn't compelling overall though. Agreed. This is a point worth emphasising: routed networking is not a panacea for everyone's networking woes. We've got a lot of NFV people and products at my employer, and while we're engaged in work to come up with L3 approaches to solve their use-cases, we'd like to draw a balance between adding complexity to the network layer to support legacy L2-based requirements and providing better native L3 solutions that NFV applications can use instead. One of the key challenges with NFV is that it shouldn't just be a blind porting of existing codebases - you need to make sure you're producing something which takes advantage of the new environment. Cory ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][all] Synchronizing local Git and Gerrit repositories
On Thursday, October 30, 2014, Ondrej Wisniewski ondrej.wisniew...@dektech.com.au wrote: Hi Stefano and Dolph, since me and my team joined the OpenStack developer community just recently, I really appreciate your comments and suggestions. After all, we are here to learn. The current workflow we've set up might be a consequence of a different development model we were used to. Anyway we have no intention to isolate our development from the community and our contributions will surely be shared. Therefore we will review our way of working and make adjustments to follow more closely the community workflow. Great to hear! Do get in touch (either in Paris or on the list, or in IRC, etc) if you need help to get moving. Ondrej ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html [1] https://etherpad.openstack.org/p/6cWQG9oNsr -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] team meeting Oct 30 1800 UTC
Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20141030T18 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Fuel plugins feedback
Hi Dmitry, Thank you for being beta tester and for your feedback :) On Wed, Oct 29, 2014 at 11:05 AM, Dmitry Ukov du...@mirantis.com wrote: All, Recently I have tried plugins feature which was implemented for 6.x release. And that was really pleasant experience. Plugins work almost out-of-the box. I was able to implement Cinder with NetApp backend installation and configuration as a separate Fuel plugin. Current simple implementation (with pre- and post-deployment customizations) covers around 30% of our use cases. Obviously this will cover all cases that require OpenStack configuration file changes (e.g. custom Cinder backend, LDAP integration e.t.c). Next things that will cover significant amount of our use cases is ability to add custom roles and modify node provisioning parameters. I'm looking forward to trying those features out. I'd like to thank Fuel team for implementation such desirable feature. Plugins will definitely help to increase flexibility of MOS. Great job! -- Kind regards Dmitry Ukov IT Engineer Mirantis, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/30/2014 04:53 PM, Joe Gordon wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. I'm happy to lead this, to co-lead with Dean or to just watch Dean lead it - although I can promise in any format to start off the time period with some very colorful ranting. I think I'm less necessary in the tech debt session, as other than yes, please get rid of it I probably don't have too much more input that will be helpful. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [MagnetoDB] IRC weekly meeting minutes 30-10-2014
Hello team, Thank you for coming to meeting today, you can find meeting minutes and logs below [1][2][3] Please pay attention, that next week meeting is canceled due to summit. [1] http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.html [2] http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.txt [3] http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html Thank you, Ilya Sviridov isviridov @ FreeNode Meeting started by isviridov at 14:00:52 UTC (full logs http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html ). Meeting summary 1. *action items* (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-21, 14:03:42) 1. https://review.openstack.org/#/c/126335/ (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-29, 14:05:49) 2. *Kilo roadmap https://etherpad.openstack.org/p/kilo-crossproject-summit-topics https://etherpad.openstack.org/p/kilo-crossproject-summit-topics isviridov* (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-46, 14:12:29) 1. https://etherpad.openstack.org/p/magnetodb-kilo-roadmap (ikhudoshyn http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-48, 14:13:11) 2. https://etherpad.openstack.org/p/magnetodb-kilo-roadmap (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-49, 14:13:15) 3. *ACTION*: dukhlov data encryption support blueprint (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-87, 14:31:06) 4. *ACTION*: ikhudoshyn file a bug about dynamodb version support documentation (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-100, 14:35:25) 5. *ACTION*: isviridov ikhudoshyn clarify roadmap item (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-145, 14:51:48) 3. *Design session topics https://etherpad.openstack.org/p/magnetodb-kilo-design-summit https://etherpad.openstack.org/p/magnetodb-kilo-design-summit isviridov* (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-146, 14:51:51) 4. *Next meeting isviridov* (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-149, 14:53:18) 1. the next week meeting is canceled due to summit (isviridov http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html#l-150, 14:53:44) Meeting ended at 15:01:15 UTC (full logs http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html ). Action items 1. dukhlov data encryption support blueprint 2. ikhudoshyn file a bug about dynamodb version support documentation 3. isviridov ikhudoshyn clarify roadmap item Action items, by person 1. dukhlov 1. dukhlov data encryption support blueprint 2. ikhudoshyn 1. ikhudoshyn file a bug about dynamodb version support documentation 2. isviridov ikhudoshyn clarify roadmap item 3. isviridov 1. isviridov ikhudoshyn clarify roadmap item ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On Thu, Oct 30, 2014 at 10:53 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. There are many discussion sessions related to SDKs, they just aren't all in the cross-project slots. Plus these don't require an ATC badge (something users may not have). Application Ecosystem Working Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group Monday 2:30 (Degas) Thursday 1:40 (Hyatt) I think we can talk about the real SDK at one of these. There's also: Getting Started with the OpenStack Python SDK Monday 4:20 (Room 242AB) Anne The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html [1] https://etherpad.openstack.org/p/6cWQG9oNsr -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On Thu, Oct 30, 2014 at 9:20 AM, Anne Gentle a...@openstack.org wrote: On Thu, Oct 30, 2014 at 10:53 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. There are many discussion sessions related to SDKs, they just aren't all in the cross-project slots. Plus these don't require an ATC badge (something users may not have). If we want to make sure the end user has a more uniform experience, having the individual python-*client discussions isn't sufficient. Also, the issue is not lack of user feedback, the issue here is more of a lack of people implementing the feedback. Application Ecosystem Working Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group Monday 2:30 (Degas) Thursday 1:40 (Hyatt) These sessions have pretty broad scopes, and I don't think a discussion on SDKs here is enough, since the issue isn't a lack of feedback. I think we can talk about the real SDK at one of these. There's also: Getting Started with the OpenStack Python SDK Monday 4:20 (Room 242AB) This isn't a a design summit session, so it doesn't really make sense to do future design work here. Anne The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html [1] https://etherpad.openstack.org/p/6cWQG9oNsr -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo] os-cloud-config
Hello, we call it from UI after the deployment https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overview/forms.py#L222 . There should be conversation on the summit whether to do the call from somewhere else (tuskar, template..). Kind Regards, Ladislav On 10/30/2014 01:47 PM, LeslieWang wrote: Dear all, Seems like os-cloud-config is to initialise uncercloud or overcloud after heat orchestration. But I can not find how it is used in either tuskar, or tuskar-UI. So can anyone explain a little bit how it is used in TripleO projects? Thanks. Best Regards Leslie Wang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
OK, You may need to think of brining BGP routing between POD to support Live migration. Thanks Regards, keshava -Original Message- From: joehuang [mailto:joehu...@huawei.com] Sent: Thursday, October 30, 2014 4:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hello, Keshava Live migration is allowed inside one pod ( one cascaded OpenStack instance ), not support cross pods live migration yet. But cold migration could be done between pods, even cross data centers. Live migration cross pods will be studied in the future. Best Regards Chaoyi Huang ( joehuang ) From: A, Keshava [keshav...@hp.com] Sent: 30 October 2014 17:45 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi, Can the VM migration happens across POD (Zone) ? If so then how reachability of VM is addressed dynamically without any packet loss ? Thanks Regards, keshava -Original Message- From: Wuhongning [mailto:wuhongn...@huawei.com] Sent: Thursday, October 30, 2014 7:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one Datacenter, Just like below: (A, B, C) ... (D, E) ... (F) ... (G) Each character represent a POD or child openstack, while parenthesis represent a Datacenter. Each POD has a corresponding virtual host node in the parent openstack, so when scheduler of any projects (nova/neutron/cinder...) locate a host node, the resource POD is determined, also with its geo-located Datacenter by side effect. Cascading don't schedule by Datacenter directly, DC is just an attribute of POD (for example we can configure host aggregate to identify a DC with multiple PODs). The upper scale of POD is fixed, maybe several hundreds, so a super large DC with tens of thousands servers could be built by modularized PODs, avoiding the difficult of tuning and maintaining such a huge monolithic openstack. Next do you mean networking reachability? Sorry for the limitation of mail post I can just give some very simple idea: in parent openstack the L2pop and DVR is used, so L2/L3 agent-proxy in each virtual host node can get all the vm reachability information of other POD, then they are set to local POD by Neutron REST API. However, cascading depends on some feature not exists yet in current Neutron, like L2GW, pluggable external network, WE Fwaas in DVR, centralized FIP in DVR... so we have to do some little patch in the front. In the future if these features is merged, these patch code can be removed. Indeed Neutron is the most challenge part of cascading, without considering those proxies in the parent openstack virtual host node, Neutron patchs account for 85% or more LOC in the whole project. Regards, Wu From: keshava [keshav...@hp.com] Sent: Wednesday, October 29, 2014 2:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading This is very interesting problem to solve. I am curious to know how the reachability is provided across different Datacenter. How to know which VM is part of which Datacenter? VM may be in different Zone but under same DC or in different DC itself. How this problem is solved? thanks regards, keshava -- View this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html Sent from the Developer mailing list archive at Nabble.com. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-tc] Topics for the Board/TC joint meeting in Paris
This is already on the agenda proposed by the board (as well as a quick presentation on the need for structural reform in the ways we handle projects in OpenStack). Would it be possible for the slidedeck and a quick summary of that presentation to be posted to the os-dev list after the Board/TC joint meeting on Sunday? (Given that discussion will be highly relevant to the cross-project sessions on Growth Challenges running on the Tuesday) Thanks, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries
On 10/23/2014 04:18 PM, Doug Hellmann wrote: On Oct 23, 2014, at 2:56 AM, Flavio Percoco fla...@redhat.com wrote: On 10/22/2014 08:15 PM, Doug Hellmann wrote: The application projects are dropping python 2.6 support during Kilo, and I’ve had several people ask recently about what this means for Oslo. Because we create libraries that will be used by stable versions of projects that still need to run on 2.6, we are going to need to maintain support for 2.6 in Oslo until Juno is no longer supported, at least for some of our projects. After Juno’s support period ends we can look again at dropping 2.6 support in all of the projects. I think these rules cover all of the cases we have: 1. Any Oslo library in use by an API client that is used by a supported stable branch (Icehouse and Juno) needs to keep 2.6 support. 2. If a client library needs a library we graduate from this point forward, we will need to ensure that library supports 2.6. 3. Any Oslo library used directly by a supported stable branch of an application needs to keep 2.6 support. 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one of the previous rules applies. 5. The stable/icehouse and stable/juno branches of the incubator need to retain 2.6 support for as long as those versions are supported. 6. The master branch of the incubator needs to retain 2.6 support until we graduate all of the modules that will go into libraries used by clients. A few examples: - oslo.utils was graduated during Juno and is used by some of the client libraries, so it needs to maintain python 2.6 support. - oslo.config was graduated several releases ago and is used directly by the stable branches of the server projects, so it needs to maintain python 2.6 support. - oslo.log is being graduated in Kilo and is not yet in use by any projects, so it does not need python 2.6 support. - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but both are used by client projects, so they need to keep python 2.6 support. At that point we can evaluate the code that remains in the incubator and see if we’re ready to turn of 2.6 support there. Let me know if you have questions about any specific cases not listed in the examples. The rules look ok to me but I'm a bit worried that we might miss something in the process due to all these rules being in place. Would it be simpler to just say we'll keep py2.6 support in oslo for Kilo and drop it in Igloo (or L?) ? I think we have to actually wait for M, don’t we (K L represents 1 year where J is supported, M is the first release where J is not supported and 2.6 can be fully dropped). But to your point of keeping it simple and saying we support 2.6 in all of Oslo until no stable branches use it, that could work. I think in practice we’re not in any hurry to drop the 2.6 tests from existing Oslo libs, and we just won’t add them to new ones, which gives us basically the same result. A bit late to this discussion, but if we don't add py26 jobs to new libraries, we need to be very careful that they never get pulled in as a transitive dep to an existing lib that does need py26 support. Since I think some of the current libs are still using incubator modules, it's possible this could happen as we transition to newly released libs. So if we're going for safe and simple, we should probably also keep py26 jobs for everything until EOL for Juno. Doug Once Igloo development begins, Kilo will be stable (without py2.6 support except for Oslo) and Juno will be in security maintenance (with py2.6 support). I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo until we move the rest of the projects just to keep the process simpler. Probably longer but hopefully simpler. I'm sure I'm missing something so please, correct me here. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Proposal to add Iccha Sethi to trove-core
Thanks everyone for the show of support. Iccha: welcome to trove-core! On Thu, Oct 30, 2014 at 8:41 AM, Vipul Sabhaya vip...@gmail.com wrote: +1 On Oct 30, 2014, at 1:47 AM, Nikhil Manchanda nik...@manchanda.me wrote: Hello folks: I'm proposing to add Iccha Sethi (iccha on IRC) to trove-core. Iccha has been working with Trove for a while now. She has been a very active reviewer, and has provided insightful comments on numerous reviews. She has submitted quality code for multiple bug-fixes in Trove, and most recently drove the per datastore volume support BP in Juno. She was also a crucial part of the team that implemented replication in Juno, and helped close out multiple replication related issues during Juno-3. https://review.openstack.org/#/q/reviewer:iccha,n,z https://review.openstack.org/#/q/owner:iccha,n,z Please respond with +1/-1, or any further comments. Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.concurrency 0.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FYI we'll need the following review for oslo-incubator to merge before projects are able to consume the new library: https://review.openstack.org/#/c/122796/3 On 24/10/14 19:12, Doug Hellmann wrote: The Oslo team is pleased to announce the release of oslo.conccurrency 0.1.0, the first development release of the new library containing lockutils and processutils. Documentation for the library is available at http://docs.openstack.org/developer/oslo.concurrency/ Please report issues via launchpad: https://launchpad.net/oslo.concurrency Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUUnaGAAoJEC5aWaUY1u57hq8H/jrFMmM6a8N1aLwOIGwTlNv+ QVQZb9kC2ZzCp712U//2v8eXhxEGLIaNmnHexqyLKQuuzlpkhr+URVDjYp54AsPj RdgrYoHWm1XwCUoGjSIr2bvmaf4Lb4IVR+OVjw/ZzdWY1MoPYh+RhWNQKAFyHxD9 PY2P1M211aANP4wLaDEQfuRGVnAArep4lzDZqv9AVd7R2TTLBPO1N7WjwmVtI5Xa 8JaRq5tDQLbDX+6Q54taIBUBIcOzeGlYT/q/7Txiu+ZCNBzAqtSkc5zfBitECZ4a jB9zMLNFYxDh6wBJgloX4SsrSfsJJtMkeD5QV7z+EvO1wwdvfOF9gSYhotUt4wE= =NKei -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 30/10/14 06:22, Eoghan Glynn wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% Correction, I skipped a cycle in that table: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.0% Grizzly | 630| 179 (28.4%) | 29.2% Folsom | 401| 120 (29.9%) | 27.9% Doesn't alter the trend though, still quite flat with some jitter and a small uptick. The low (and dropping) level of turnout is worrying, particularly in light of that analysis showing the proportion of drive-by contributors is relatively static, but it is always going to be hard to discern the motives of people who didn't vote from the single bit of data we have on them. There is, however, another metric that we can pull from the actual voting data: the number of candidates actually ranked by each voter: Candidates rankedFrequency 08 2% 1 17 3% 2 24 5% 3 20 4% 4 31 6% 5 36 7% 6 68 13% 7 39 8% 8 17 3% 99 2% 10 21 4% 11- - 12 216 43% (Note that it isn't possible to rank exactly n-1 candidates.) So even amongst the group of people who were engaged enough to vote, fewer than half ranked all of the candidates. A couple of hypotheses spring to mind: 1) People don't understand the voting system. Under Condorcet, there is no such thing as tactical voting by an individual. So to the extent that these figures might reflect deliberate 'tactical' voting, it means people don't understand Condorcet. The size of the spike at 6 (the number of positions available - the same spike appeared at 7 in the previous election) strongly suggests that lack of understanding of the voting system is at least part of the story. The good news is that this problem is eminently addressable. 2) People aren't familiar with the candidates This is the one that worries me - it looks a lot like most voters are choosing not to rank many of the candidates because they don't feel they know enough about them to have an opinion. It seems to me that
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On Thu, Oct 30, 2014 at 11:48 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 9:20 AM, Anne Gentle a...@openstack.org wrote: On Thu, Oct 30, 2014 at 10:53 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. There are many discussion sessions related to SDKs, they just aren't all in the cross-project slots. Plus these don't require an ATC badge (something users may not have). If we want to make sure the end user has a more uniform experience, having the individual python-*client discussions isn't sufficient. Also, the issue is not lack of user feedback, the issue here is more of a lack of people implementing the feedback. Agreed, so a cross-project session may help with that. Still, non-ATCs may want to pick up this work and just don't know how. I'd like to see ATC at the Ecosystem sessions to help with that direction of contribution. I know we need this session, just trying to find a place. Application Ecosystem Working Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group Monday 2:30 (Degas) Thursday 1:40 (Hyatt) These sessions have pretty broad scopes, and I don't think a discussion on SDKs here is enough, since the issue isn't a lack of feedback. Okay, fair enough. I think we can talk about the real SDK at one of these. There's also: Getting Started with the OpenStack Python SDK Monday 4:20 (Room 242AB) This isn't a a design summit session, so it doesn't really make sense to do future design work here. Agreed, was just making sure people on this list are aware. Anne Anne The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html [1] https://etherpad.openstack.org/p/6cWQG9oNsr -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
Hi all, I've add a new item (No. 34 in the bottom) for Disaster Reover topics On Thu, Oct 30, 2014 at 5:48 PM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 9:20 AM, Anne Gentle a...@openstack.org wrote: On Thu, Oct 30, 2014 at 10:53 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. There are many discussion sessions related to SDKs, they just aren't all in the cross-project slots. Plus these don't require an ATC badge (something users may not have). If we want to make sure the end user has a more uniform experience, having the individual python-*client discussions isn't sufficient. Also, the issue is not lack of user feedback, the issue here is more of a lack of people implementing the feedback. Application Ecosystem Working Group https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group Monday 2:30 (Degas) Thursday 1:40 (Hyatt) These sessions have pretty broad scopes, and I don't think a discussion on SDKs here is enough, since the issue isn't a lack of feedback. I think we can talk about the real SDK at one of these. There's also: Getting Started with the OpenStack Python SDK Monday 4:20 (Room 242AB) This isn't a a design summit session, so it doesn't really make sense to do future design work here. Anne The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html [1] https://etherpad.openstack.org/p/6cWQG9oNsr -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Zhipeng Huang 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate
- Original Message - From: Wuhongning wuhongn...@huawei.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org +1, the hint should be persistent as other server instance metadata. I don't think there is much disagreement that it makes sense to do this, but more how/where to do so. You can refer to the comments in the review Jay linekd for more background: https://review.openstack.org/#/c/88983/17/specs/juno/persist-scheduler-hints.rst From: Alex Xu [sou...@gmail.com] Sent: Wednesday, October 29, 2014 9:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate 2014-10-29 13:42 GMT+08:00 Chen CH Ji jiche...@cn.ibm.commailto:jiche...@cn.ibm.com: Yes, I remember that spec might talk about local storage (in local db?) and it can be the root cause And I think we need persistent storage otherwise the scheduler hints can't survive in some conditions such as system reboot or upgrade ? Yeah, that's problem. And I have talk with Jay Lau, look like there already got agreement on persistent it. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.commailto:jiche...@cn.ibm.com Phone: +86-10-82454158tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [Inactive hide details for Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: ]Alex Xu ---10/29/2014 01:34:13 PM---On 2014年10月29日 12:37, Chen CH Ji wrote: From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: 10/29/2014 01:34 PM Subject: Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate On 2014年10月29日 12:37, Chen CH Ji wrote: I think we already support to specify the host when doing evacuate and migration ? Yes, we support to specify the host, but schedule-hints is different thing. if we need use hints that passed from creating instance, that means we need to persistent schedule hints I remember we used to have a spec for store it locally ... I also remember we have one spec for persistent before, but I don't know why it didn't continue. And I think maybe we needn't persistent schedule-hints, just add pass new schedule-hints when migration the instance. Nova just need provide the mechanism. Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.commailto:jiche...@cn.ibm.com Phone: +86-10-82454158tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC [Inactive hide details for Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass]Alex Xu ---10/29/2014 12:19:35 PM---Hi, Currently migration/rebuild/evacuate didn't support pass From: Alex Xu x...@linux.vnet.ibm.commailto:x...@linux.vnet.ibm.com To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: 10/29/2014 12:19 PM Subject: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate Hi, Currently migration/rebuild/evacuate didn't support pass scheduler-hints, that means any migration can't use schedule-hints that passed when creating instance. Can we add scheduler-hints support when migration/rebuild/evacuate? That also can enable user move in/out instance to/from an server group. Thanks Alex ___ 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-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] add a common cache mechanism for block device storage
On 08:57 Wed 29 Oct , yoo bright wrote: Dear all, We proposed a new blueprint (at https://review.openstack.org/128814) for adding a common cache mechanism for block device storage. All requirements, suggestions and comments are welcome. Thank you! Thanks for submitting this Yoo. This is already posted in the review, but I think we would want to see a way for alternatives to be plugged in. I also think if you want this working on the compute nodes, you'll need to work with the Nova folks as well. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] Finalizing cross-project design summit track
On 10/30/2014 12:12 PM, Monty Taylor wrote: On 10/30/2014 04:53 PM, Joe Gordon wrote: On Thu, Oct 30, 2014 at 4:01 AM, Thierry Carrez thie...@openstack.org wrote: Jay Pipes wrote: On 10/29/2014 09:07 PM, Russell Bryant wrote: On 10/29/2014 06:46 PM, Rochelle Grober wrote: Any chance we could use the opening to move either the Refstack session or the logging session from their current joint (and conflicting) time (15:40)? QA really would be appreciated at both. And I'd really like to be at both. I'd say the Refstack one would go better in the debug slot, as the API stuff is sort of related to the logging. Switching with one of the 14:50 sessions might also work. Just hoping. I really want great participation at all of these sessions. The gate debugging session is most likely going to be dropped at this point. I don't see a big problem with moving the refstack one to that slot (the first time). Anyone else have a strong opinion on this? Sounds good to me. Sounds good. With the gate debugging session being dropped due to being the wrong format to be productive, we now need a new session. After looking over the etherpad of proposed cross project sessions I think there is one glaring omission: the SDK. In the Kilo Cycle Goals Exercise thread [0] having a real SDK was one of the top answers. Many folks had great responses that clearly explained the issues end users are having [1]. As for who could lead a session like this I have two ideas: Monty Taylor, who had one of the most colorful explanations to why this is so critical, or Dean Troyer, one of the few people actually working on this right now. I think it would be embarrassing if we had no cross project session on SDKs, since there appears to be a consensus that the making life easier for the end user is a high priority. The current catch is, the free slot is now at 15:40, so it would compete with 'How to Tackle Technical Debt in Kilo,' a session which I expect to be very popular with the same people who would be interested in attending a SDK session. I'm happy to lead this, to co-lead with Dean or to just watch Dean lead it - although I can promise in any format to start off the time period with some very colorful ranting. I think I'm less necessary in the tech debt session, as other than yes, please get rid of it I probably don't have too much more input that will be helpful. OK, awesome! I'll put you down for now. I could use a proposed session description to put on sched.org. Otherwise, I'll just make something up. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions
On 10/30/2014 11:12 AM, Sean Dague wrote: On 10/30/2014 10:47 AM, Eoghan Glynn wrote: Matthew wrote: This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. [much snipping] Sean wrote: Ok, so part of this remains to be seen about what the biggest bang for the buck is. The class of bugs I feel like we need to nail in Nova right now are going to require tests that bring up pieces of the wsgi stack, but are probably not runable on a real deploy. Again, this is about debugability. So this notion of the biggest bang for our buck is an aspect of the drive for in-tree functional tests, that's not entirely clear to me as yet. i.e. whether individual projects should be prioritizing within this effort: (a) the creation of net-new coverage for scenarios (especially known or suspected bugs) that were not previously tested, in a non-unit sense (b) the relocation of existing integration test coverage from Tempest to the project trees, in order to make the management of Tempest more tractable It feels like there may be a tension between (a) and (b) in terms of the pay-off for this effort. I'd interested in hearing other opinions on this, on what aspect projects are expecting (and expected) to concentrate on initially. For what it's worth I have a bunch of early targets listed for Nova for our summit session - https://etherpad.openstack.org/p/kilo-nova-functional-testing My focus in kilo is going to be first about A), as that provides value out of the gate (pun intended). Then peel off some stuff from B as makes sense. -Sean That seems sensible from the nova point of view and overall health, and not all projects have to pursue the same priorities at the same time. But a big part of the benefit of (b) is the impact it has on all the other projects in that other projects will stop getting as many gate failures, and that benefit could be achieved right now by simply changing the set of tempest tests that run against each project. -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On Oct 30, 2014, at 10:41 AM, Zane Bitter zbit...@redhat.com wrote: On 30/10/14 06:22, Eoghan Glynn wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Different but related question (might be hard to calculate though): If we remove people who have only ever landed one patch from the electorate, what do the turnout numbers look like? 2? 5? Do we have the ability to dig in slightly and find a natural definition or characterization amongst our currently voting electorate that might help us understand who the people are who do vote and what it is about those people who might be or feel different or more enfranchised? I've personally been thinking that the one-patch rule is, while tractable, potentially strange for turnout - especially when one-patch also gets you a free summit pass... but I have no data to say what actually defined active in active technical contributor. Again, the ballots are anonymized so we've no way of doing that analysis. The best we could IIUC would be to analyze the electoral roll, bucketizing by number of patches landed, to see if there's a significant long-tail of potential voters with very few patches. Just looking at stackalytices numbers for Juno: Out of 1556 committers, 1071 have committed more than one patch and 485 only a single patch. That's a third! Here's the trend over the past four cycles, with a moving average in the last column, as the eligible voters are derived from the preceding two cycles: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.8% Folsom | 401| 120 (29.9%) | 27.9% Correction, I skipped a cycle in that table: Release | Committers | Single-patch | 2-cycle MA Juno| 1556 | 485 (31.2%) | 29.8% Icehouse| 1273 | 362 (28.4%) | 28.0% Havana | 1005 | 278 (27.6%) | 28.0% Grizzly | 630| 179 (28.4%) | 29.2% Folsom | 401| 120 (29.9%) | 27.9% Doesn't alter the trend though, still quite flat with some jitter and a small uptick. The low (and dropping) level of turnout is worrying, particularly in light of that analysis showing the proportion of drive-by contributors is relatively static, but it is always going to be hard to discern the motives of people who didn't vote from the single bit of data we have on them. There is, however, another metric that we can pull from the actual voting data: the number of candidates actually ranked by each voter: Candidates rankedFrequency 08 2% 1 17 3% 2 24 5% 3 20 4% 4 31 6% 5 36 7% 6 68 13% 7 39 8% 8 17 3% 99 2% 10 21 4% 11- - 12 216 43% (Note that it isn't possible to rank exactly n-1 candidates.) So even amongst the group of people who were engaged enough to vote, fewer than half ranked all of the candidates. A couple of hypotheses spring to mind: 1) People don't understand the voting system. Under Condorcet, there is no such thing as tactical voting by an individual. So to the extent that these figures might reflect deliberate 'tactical' voting, it means people don't understand Condorcet. The size of the spike at 6 (the number of positions available - the same spike appeared at 7 in the previous election) strongly suggests that lack of understanding of the voting system is at least part of the story. The good news is that this problem is eminently addressable. 2) People aren't familiar with the candidates This is the one that worries me - it looks a lot like most
Re: [openstack-dev] [sahara] team meeting Oct 30 1800 UTC
Minutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-10-30-18.00.html Logs: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-10-30-18.00.log.html On Thu, Oct 30, 2014 at 7:01 PM, Sergey Lukjanov slukja...@mirantis.com wrote: Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20141030T18 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
The low (and dropping) level of turnout is worrying, particularly in light of that analysis showing the proportion of drive-by contributors is relatively static, but it is always going to be hard to discern the motives of people who didn't vote from the single bit of data we have on them. There is, however, another metric that we can pull from the actual voting data: the number of candidates actually ranked by each voter: Candidates rankedFrequency 08 2% 1 17 3% 2 24 5% 3 20 4% 4 31 6% 5 36 7% 6 68 13% 7 39 8% 8 17 3% 99 2% 10 21 4% 11- - 12 216 43% (Note that it isn't possible to rank exactly n-1 candidates.) So even amongst the group of people who were engaged enough to vote, fewer than half ranked all of the candidates. A couple of hypotheses spring to mind: 1) People don't understand the voting system. Under Condorcet, there is no such thing as tactical voting by an individual. So to the extent that these figures might reflect deliberate 'tactical' voting, it means people don't understand Condorcet. The size of the spike at 6 (the number of positions available - the same spike appeared at 7 in the previous election) strongly suggests that lack of understanding of the voting system is at least part of the story. The good news is that this problem is eminently addressable. Addressable by educating the voters on the subtleties of Condorcet, or by switching to another model such as the single-transferable vote? I can see the attractions of Condorcet, in particular it tends to favor consensus over factional candidates. Which could be seen as A Good Thing. But in our case, seems to me, we're doubling down on consensus. By combining Condorcet with staggered terms and no term limits, seems we're favoring both consensus in general and the tendency to return the *same* consensus candidates. (No criticism of the individual candidates intended, just the sameness) STV on the other hand combined with simultaneous terms, is actually used in the real world[1] and has the advantage of ensuring factions get some proportional representation and hence don't feel excluded or disenfranchised. Just a thought ... given that we're in the mood, as a community, to consider radical structural reforms. Cheers, Eoghan [1] so at least would be familiar to the large block of Irish and Australian voters ... though some centenarian citizens of Marquette, Michigan, may be a tad more comfortable with Condorcet ;) 2) People aren't familiar with the candidates This is the one that worries me - it looks a lot like most voters are choosing not to rank many of the candidates because they don't feel they know enough about them to have an opinion. It seems to me that the TC has failed to engage the community enough on the issues of the day to move beyond elections as a simple name-recognition contest. (Kind of like how I imagine it is when you have to vote for your local dog-catcher here in the US. I have to imagine because they don't let me vote.) It gets worse, because the less the TC tries to engage the community on the issues and the less it attempts to actually lead (as opposed to just considering checklists and voting to ask for more time to consider checklists), the more entrenched the current revolving-door membership becomes. So every election serves to reinforce the TC members' perception that everything is going great, and also to reinforce the perception of those whose views are not represented that the TC is an echo chamber from which their views are more or less structurally excluded. That's a much harder problem to address. cheers, Zane. Cheers, Eoghan So the proportion of single-patch committers is creeping up slowly, but not at a rate that would account for the decline in voter turnout. And since we've no way of knowing if voting patterns among the single-patch committers differs in any way from the norm, these data don't tell us much. If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters, than contests that feel like a foregone conclusion. That would suggest un-staggering the terms as a first step. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] New specs on routed networking
These are all important discussion topics, but we are getting pulled into implementation-specific details again. Routing aggregation and network topology is completely up to the backend implementation. We should keep this thread focused on the user-facing abstractions and the changes required to Nova and Neutron to enable them. Then when it is time to implement the reference implementation in Neutron, we can have this discussion on optimal placement of BGP nodes, etc. On Thu, Oct 30, 2014 at 4:04 AM, A, Keshava keshav...@hp.com wrote: Hi, w.r.t. ‘ VM packet forwarding’ at L3 level by enabling routing I have below points. With below reference diagram , when the routing is enabled to detect the destination VM’s compute node .. 1. How many route prefix will be injected in each of the compute node ? 2. For each of the VM address, there will be corresponding IP address in the ‘L3 Forwarding Tbl’ ? When we have large number of VM’s of the order 50,000/ 1 Million VM’s in the cloud each compute node needs to maintain 1 Million Route Entries ? 3. Even with route aggregations, it is not guaranteed to be very efficient because a. Tenants can span across computes. b. VM migration can happen which may break the aggregation and allow the growth of routing table. 4. Across Switch if we try to run BGP and try to aggregate, we will be introducing the Hierarchical Network. If any change in topology what will be convergence time and will there any looping issues ? Cost of the L3 switch will go up as the capacity of that switch to support 10,000 + routes. 5. With this we want to break the classical L2 broadcast in the last mile Cloud ? I was under the impression that the cloud network we want to keep simple L2 broadcast domain, without adding any complexity like MPLS label, Routing, Aggregation . 6. The whole purpose of brining VxLAN in datacenter cloud is to keep the L2 and even able to extend the L2 to different Datacenter. 7. I also saw some ietf draft w.r.t implementation architecture of OpenStack !!!. Let me know the opinion w.r.t. this ? Thanks regards, Keshava -Original Message- From: Fred Baker (fred) [mailto:f...@cisco.com] Sent: Wednesday, October 29, 2014 5:51 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][nova] New specs on routed networking On Oct 28, 2014, at 4:59 PM, Angus Lees g...@inodes.org wrote: On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote: Agreed. The way I'm thinking about this is that tenants shouldn't care what the underlying implementation is - L2 or L3. As long as the connectivity requirements are met using the model/API, end users should be fine. The data center network design should be an administrators decision based on the implementation mechanism that has been configured for OpenStack. I don't know anything about Project Calico, but I have been involved with running a large cloud network previously that made heavy use of L3 overlays. Just because these points weren't raised earlier in this thread: In my experience, a move to L3 involves losing: - broadcast/multicast. It's possible to do L3 multicast/IGMP/etc, but that's a whole can of worms - so perhaps best to just say up front that this is a non-broadcast network. - support for other IP protocols. - various L2 games like virtual MAC addresses, etc that NFV/etc people like. I’m a little confused. IP supports multicast. It requires a routing protocol, and you have to “join” the multicast group, but it’s not out of the picture. What other “IP” protocols do you have in mind? Are you thinking about IPX/CLNP/etc? Or are you thinking about new network layers? I’m afraid the L2 games leave me a little cold. We have been there, such as with DECNET IV. I’d need to understand what you were trying to achieve before I would consider that a loss. We gain: - the ability to have proper hierarchical addressing underneath (which is a big one for scaling a single network). This itself is a tradeoff however - an efficient/strict hierarchical addressing scheme means VMs can't choose their own IP addresses, and VM migration is messy/limited/impossible. It does require some variation on a host route, and it leads us to ask about renumbering. The hard part of VM migration is at the application layer, not the network, and is therefore pretty much the same. - hardware support for dynamic L3 routing is generally universal, through a small set of mostly-standard protocols (BGP, ISIS, etc). - can play various L3 games like BGP/anycast, which is super useful for geographically diverse services. It's certainly a useful tradeoff for many use cases. Users lose some generality in return for more powerful
