Re: [openstack-dev] [Openstack-operators] [tc] Who is allowed to vote for TC candidates
On Fri, May 1, 2015 at 2:50 PM, Adam Lawson alaw...@aqorn.com wrote: I purposely didn't email the general mailing list since I didn't want to cross-post, hard to have these discussions across verticals and choosing one list = hearing one community - those subscribed to the developer mailing list. So I'm not assuming anything, it seems some are suggesting that Operators get into code review to quantify their role as an engaged Operator. Is that a correct statement? Just want to make sure I'm hearing correctly. I try to avoid absolutes but personally speaking for the record, I don't believe the answer lies with asking Operators to become code reviewers on top of everthing else they're doing in order for them to have a voice in the TC elections. If code reviews are being suggested (again, assuming the assumption is correct for the sake of making my point), technical contribution extends far beyond uploading and reviewing code. This alternate means to gain ATC status seems like a potential candidate for those who want to review code but not for those who are day-to-day operators engaging with the community. Specification review is a far cry from code review. Specification review is really about direction / impact. Operator imput on specifications can be extremely valuable (e.g. This doesn't meet any of our needs, but it's close. Here are some suggestions to make it meet more needs/closer to real-world). It is one of the ways operators can be involved and get ATC status. It may not be the only way that operators should be involved. --Morgan Is there any meetings planned in Vancouver where users/operators are meeting where we can add an agenda items to gather input? Given this conversation involves the Operator community as well, I went ahead and CC'd them to hopefully capture their specific thoughts/ideas on the subject. Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. --Morgan -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?
Thanks Adam! That makes sense to me!Wanjing Xu From: adam.harw...@rackspace.com To: openstack-dev@lists.openstack.org Date: Fri, 1 May 2015 16:33:09 + Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? The subnet_id on the pool specifies what networks to plug when everything is first configured.Iif you add a member to the pool that is outside this subnet, there may not be a route to it, since it is probably on a different network that is not correctly plugged on the LB host. (I hope this is correct, it is from memory from a bit ago.) --Adam https://keybase.io/rm_you From: Wanjing Xu wanjing...@hotmail.com Reply-To: OpenStack Development Mailing List not for usage questions openstack-dev@lists.openstack.org Date: Thursday, April 30, 2015 at 5:15 PM To: OpenStack Development Mailing List not for usage questions openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? Thanks Bharath for replying. But when I add members , I can successfully specify a member ip address from a different pool than the subnet when creating pool, hence the confusion. And theoretically, why would members for a pool have to belong to the same subnet? Date: Tue, 28 Apr 2015 17:50:16 -0700 From: bharath.stac...@gmail.com To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? Hi Wanjing, As it's Juno, I assume you are using LBaaSv1. If that's the case, as Brandon pointed, there's no subnet-id switch in the neutron lb-member-create command. Having said that you still use the subnet-id in both the following commands: neutron lb-pool-create neutron lb-vip-create You should note that the subnet id in each of the above commands serve different purpose. In the case of lb-pool-create, the subnet-id is provided to make sure that only members belonging to the specified subnet-id could be added to the pool. However, the subnet id in the lb-vip-create command specifies the network range from which an ip is chosen to be assigned as a vip. Thus, you could use different subnets for both the above commands and as long as you have route between those two, the load balancing works. Thanks, Bharath. On Tue, Apr 28, 2015 at 9:19 AM, Brandon Logan brandon.lo...@rackspace.com wrote: So someone pointed out that you were using lbaas for Juno, which would mean you aren't using LBaaS V2. So you're using V1. V1 member's do not take subnet_id as an attribute. Let me know how you are making your requests. Thanks, Brandon From: Brandon Logan brandon.lo...@rackspace.com Sent: Monday, April 27, 2015 8:40 PM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? I'm assuming you are using LBaaS V2. With that assumption, I'm not sure how you are having to select subnet on the pool. It's not supposed to be a field at all on the pool object. subnet_id is required on the member object right now, but that's something I and others think should just be optional, and if not specified then it's assumed that member can be reached with whatever has already been setup. Another option is pool could get a subnet_id field in the future and all members that are created without subnet_id are assumed to be on the pool's subnet_id, but I'm getting ahead of myself and this has no bearing on your current issue. Could you tell me how you are making your requests? CLI? REST directly? From: Wanjing Xu wanjing...@hotmail.com Sent: Monday, April 27, 2015 12:57 PM To: OpenStack Development Mailing List not for usage questions Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field that I need to fill in when creating a pool, and later on when I add members, I can use a different subnet(or simply just enter the ip of the member), when adding vip, I can still select a third subnet. So what is the usage of the first subnet that I used to create pool? There is no port created for this pool subnet. I can see that a port is created for the vip subnet that the loadbalancer instance is binding to. Regards! Wanjing Xu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
[openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate
Hi all, At around the time Barbican was applying for incubation there was a discussion about supported WSGI frameworks. From memory the decision at the time was that Pecan was to be the only supported framework and that for incubation Barbican had to convert to Pecan (from Falcon). Keystone is looking to ditch our crusty old, home-grown wsgi layer for an external framework and both Pecan and Falcon are in global requirements. In the experimenting I've done Pecan provides a lot of stuff we don't need and some that just gets in the way. To call out a few: * the rendering engine really doesn't make sense for us, for APIs, and where we are often returning different data (not just different views or data) based on Content-Type. * The security enforcement within Pecan does not really mesh with how we enforce policy, nor does the way we build controller objects per resource. It seems we will have to build this for ourselves on top of pecan and there are just various other niggles. THIS IS NOT SUPPOSED TO START A DEBATE ON THE VIRTUES OF EACH FRAMEWORK. Everything I've found can be dealt with and pecan will be a vast improvement over what we use now. I have also not written a POC with Falcon to know that it will suit any better. My question is: Does the ruling that Pecan is the only WSGI framework for OpenStack stand? I don't want to have 100s of frameworks in the global requirements, but given falcon is already there iff a POC determines that Falcon is a better fit for keystone can we use it? Thanks, Jamie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core
+1 From: Alex Xu sou...@gmail.commailto:sou...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 6:30 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core I'm not core, but I want to +1 :) 2015-04-30 19:30 GMT+08:00 John Garbutt j...@johngarbutt.commailto:j...@johngarbutt.com: Hi, I propose we add Melanie to nova-core. She has been consistently doing great quality code reviews[1], alongside a wide array of other really valuable contributions to the Nova project. Please respond with comments, +1s, or objections within one week. Many thanks, John [1] https://review.openstack.org/#/dashboard/4690 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Karma Tests in Horizon
Paging David Lyle! We're trying to nail down exactly what work needs to be done on the Karma patch to get your approval and avoid further frustrating patch churn. Could you take a moment to respond to Matt's question, and/or discuss here what you're looking for? We tried pinging you on IRC, but it appears you missed the notification in backscroll. For reference, here's the patch under consideration: https://review.openstack.org/#/c/168152/ Michael Krotscheck __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-01 14:50:33 -0700: I purposely didn't email the general mailing list since I didn't want to cross-post, hard to have these discussions across verticals and choosing one list = hearing one community - those subscribed to the developer mailing list. I didn't notice that you had cross-posted this time, so my reply only went to the operators list: http://lists.openstack.org/pipermail/openstack-operators/2015-May/006860.html Let's pick a list before continuing the discussion. Maybe it's sufficient to link to this discussion on the operator's list, since most of the discussion is already in the archives here? Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Status of Beaker jobs
Hi, TL;DR: Please review: https://review.openstack.org/#/q/status:open++topic:bug-1444736,n,z I would like to share some progress/feedback about integrating Beaker in our modules. First, everything is updated in the Google Doc [1] My main blockers were related to packaging in UCA, I had sometimes to do ugly Puppet patches (as dependencies) to fix some bugs. Packaging is missing === Some projects don't have packages (Gnocchi Tuskar), so I can't tests it in OpenStack CI for now. Bugs in packaging === Ensure python-mysqldb is installed before MySQL db_sync (ceilometer) https://review.openstack.org/#/c/177593/ Allow to deploy Sahara on Ubuntu https://review.openstack.org/#/c/179136/ FWaaS: update packaging for Debian Ubuntu https://review.openstack.org/#/c/179210/ chmod /etc/neutron to 755 instead of 750 https://review.openstack.org/#/c/179235/ Fix Sahara installation for Ubuntu (workaround) https://bugs.launchpad.net/puppet-sahara/+bug/1450659 https://bugs.launchpad.net/cloud-archive/+bug/1450945 https://review.openstack.org/#/c/179276/ Ensure /var/log/ironic ownership https://review.openstack.org/#/c/179531/ https://bugs.launchpad.net/cloud-archive/+bug/1450942 python-openstackclient For Keystone v3 API, we *need* 1.0.3 at least if we want to have our new providers working[2], it should be in UCA soon. Fedora will have the right package too. I'm helping Rich to test the feature with https://review.openstack.org/#/c/178828/ (Beaker will be very useful to actually test the whole thing with patch dependencies). TripleO === I did not start beaker tests for now, because I first want to see unit testing. (If someone is volunteer? or I'll make it next week). Have a great week-end, [1] https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0 [2] https://review.openstack.org/#/q/status:open+project:stackforge/puppet-keystone+branch:master+topic:bp/api-v3-support,n,z -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] service chaining feature development
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Status of Beaker jobs
On 05/01/2015 05:35 PM, Emilien Macchi wrote: Hi, TL;DR: Please review: https://review.openstack.org/#/q/status:open++topic:bug-1444736,n,z I would like to share some progress/feedback about integrating Beaker in our modules. First, everything is updated in the Google Doc [1] My main blockers were related to packaging in UCA, I had sometimes to do ugly Puppet patches (as dependencies) to fix some bugs. Packaging is missing === Some projects don't have packages (Gnocchi Tuskar), so I can't tests it in OpenStack CI for now. Bugs in packaging === Ensure python-mysqldb is installed before MySQL db_sync (ceilometer) https://review.openstack.org/#/c/177593/ Allow to deploy Sahara on Ubuntu https://review.openstack.org/#/c/179136/ FWaaS: update packaging for Debian Ubuntu https://review.openstack.org/#/c/179210/ chmod /etc/neutron to 755 instead of 750 https://review.openstack.org/#/c/179235/ Fix Sahara installation for Ubuntu (workaround) https://bugs.launchpad.net/puppet-sahara/+bug/1450659 https://bugs.launchpad.net/cloud-archive/+bug/1450945 https://review.openstack.org/#/c/179276/ Ensure /var/log/ironic ownership https://review.openstack.org/#/c/179531/ https://bugs.launchpad.net/cloud-archive/+bug/1450942 python-openstackclient For Keystone v3 API, we *need* 1.0.3 at least if we want to have our new providers working[2], it should be in UCA soon. Fedora will have the right package too. Looks like RDO kilo now has python-openstackclient 1.0.3. I've been using that since last night and it has been working fine. I'm helping Rich to test the feature with https://review.openstack.org/#/c/178828/ (Beaker will be very useful to actually test the whole thing with patch dependencies). Thanks Emilien! TripleO === I did not start beaker tests for now, because I first want to see unit testing. (If someone is volunteer? or I'll make it next week). Have a great week-end, [1] https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0 [2] https://review.openstack.org/#/q/status:open+project:stackforge/puppet-keystone+branch:master+topic:bp/api-v3-support,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Clarification required
Hello,
I am playing around with Neutron LBaaS API calls as per Neutron/LBaaS/API
2.0 docs. I have noticed below behavior against working devstack. I would
like to clarify on it:
1. I create a loadbalancer using RESTAPI with the attributes -
'vip_subnet_id' and 'admin_state_up' as 'False'. It is getting created
successfully
when I do a GET on loadbalancer, I could see the relevant their information.
2. I create a listener with the loadbalancer_id from step 1 and
'admin_state_up' as 'False' and able to create listener.
when I do a GET on loadbalancer again, I could see listener details
associated with the loadbalancer as expected
Now the question comes in:-
3. I create a pool with listener _id and 'admin_state_up' as 'False' and
able to create pool accordingly
But, when I do a GET on loadbalancer, I could not see pool details under
listener associated with the loadbalancer.
Just curious, why I could not see like this when I do a GET on loadbalancer:
{
loadbalancer {
listener {
pools
}
}
}
4. I could see all the details including pool correctly when I do GET on
loadbalancers/lb_id/statuses
Thanks,
Madhusudhan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Deadline for submitting Nova Design Summit Session Proposals
On 01/05/15 11:44, John Garbutt wrote: Hi, In case you were unable to make yesterday's Nova meeting... I was there, but still a bit shy and retiring... :-) If you have a suggestion for a Nova design summit session, please ensure you add it to before the next Nova meeting (7th May): https://etherpad.openstack.org/p/liberty-nova-summit-ideas I've just added something, about getting Nova out of the networking business by providing a basic set of VIF types and a mechanism like vif-plugin-script. It's my first time editing an etherpad, and also my first suggestion for an OpenStack summit - so I may have done it all wrong, but would appreciate any feedback on how to correct that if so. Please be gentle! Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova-docker] Status update
Anyone still interested in this work? :) * there's a stable/kilo branch now (see http://git.openstack.org/cgit/stackforge/nova-docker/). * CI jobs are running fine against both nova trunk and nova's stable/kilo branch. * there's an updated nova-spec to get code back into nova tree (see https://review.openstack.org/#/c/128753/) Thanks, dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [octavia] Joining Neutron under the big tent
Good stuff. Thanks everyone for your hard work on getting Octavia to this point! Cheers, --Jorge From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 10:20 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent +1 from me From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Sent: Friday, May 1, 2015 8:53 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, I am proposing that Octavia is joining the Networking program as a project under the Services area. Octavia is the open scalable reference implementation for Neutron LBaaS V2 and has always seen itself as part of the networking program. We have adopted most governance rules from the Networking program, sharing the same build structure, and are organized like an OpenDStack project. This sounds fine to me German. To proceed here, propose something similar to what Russell has proposed for OVN here [1], and ping me on IRC with the review so I can ack it. The TC can then approve it at a future meeting. Thanks! Kyle [1] https://review.openstack.org/#/c/175954/ Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [octavia] Joining Neutron under the big tent
On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German german.eichber...@hp.com wrote: Hi, I am proposing that Octavia is joining the Networking program as a project under the Services area. Octavia is the open scalable reference implementation for Neutron LBaaS V2 and has always seen itself as part of the networking program. We have adopted most governance rules from the Networking program, sharing the same build structure, and are organized like an OpenDStack project. This sounds fine to me German. To proceed here, propose something similar to what Russell has proposed for OVN here [1], and ping me on IRC with the review so I can ack it. The TC can then approve it at a future meeting. Thanks! Kyle [1] https://review.openstack.org/#/c/175954/ Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Change for automatic translation import
Our PO files contain information about location (filename and line
numbers) as well as untranslated strings. Dolph suggested to me recently
to import into projects only the *translated* strings and I did some
investigation and implementation after discussion with the translation
team [1] - with the goal to decrease the size of these changes.
We will continue to push the full location information to transifex (our
translation tool) and leave it in the POT files that are stored in each
repository.
During the import from transifex into the OpenStack git repositories,
our scripts remove the location information from the PO files as well as
any untranslated strings thus reducing the files to import
significantly. This also reduces the change of an import significantly
since a line number change will not cause many location information to
be updated.
The gettext tools we use can cope fine with this smaller PO file since
it contains everything that is needed - just nothing more ;)
This has been tested successfully on the Documentation repositories and
now [2] has merged for the python projects that are translated. A
separate patch for horizon is under review [3].
The next import for translation will be larger than normal - it removes
lots of untranslated lines and the location information. Further patches
will then be smaller. So, don't be surprised by the next import [4]
(tomorrow),
Andreas
[1]
http://lists.openstack.org/pipermail/openstack-i18n/2015-April/001061.html
[2] https://review.openstack.org/176947
[3] https://review.openstack.org/176943
[4]
https://review.openstack.org/#/q/status:open++branch:master+topic:transifex/translations,n,z
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [octavia] Joining Neutron under the big tent
?+1 from me From: Kyle Mestery mest...@mestery.com Sent: Friday, May 1, 2015 8:53 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, I am proposing that Octavia is joining the Networking program as a project under the Services area. Octavia is the open scalable reference implementation for Neutron LBaaS V2 and has always seen itself as part of the networking program. We have adopted most governance rules from the Networking program, sharing the same build structure, and are organized like an OpenDStack project. This sounds fine to me German. To proceed here, propose something similar to what Russell has proposed for OVN here [1], and ping me on IRC with the review so I can ack it. The TC can then approve it at a future meeting. Thanks! Kyle [1] https://review.openstack.org/#/c/175954/ Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
Thanks for your reply, Kevin, and sorry for the delay in following up. On 21/04/15 09:40, Kevin Benton wrote: Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? No, not as I've described it below, and as we've implemented Calico so far. Calico's first target is a shared address space without overlapping IPs, so that we can handle everything within the default namespace. But we do also anticipate a future Calico release to support private address spaces with overlapping IPs, while still routing all VM data rather than bridging. That will need the private address TAP interfaces to go into a separate namespace (per address space), and have their data routed there; and we'd run a Dnsmasq in that namespace to provide that space's IP addresses. Within each namespace - whether the default one or private ones - we'd still use the other changes I've described below for how the DHCP agent creates the ns-XXX interface and launches Dnsmasq. Does that make sense? Do you think that this kind of approach could be in scope under the Neutron umbrella, as an alternative to bridging the TAP interfaces? Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] trimming down Tempest smoke tag
On 1 May 2015 at 05:39, Sean Dague s...@dague.net wrote: On 04/30/2015 12:53 PM, Matt Riedemann wrote: snip Yeah why would you not include admin tests? Like listing services and hosts in nova? It is extremely easy to say why not include *, it's valid function and we're going to end up with an hour long smoke test. At some point, you have to cut. Nova... can you boot a server, cool. Can it get on the network? Glance, can I feed you an image and it looks like it works. Great. Keystone, you do something with users right, can I add one? There are so many features in OpenStack that we need to be aggressive on keeping this paired down. My thought is Smoke is not intended to be validation your cloud is working. It's validation that the cloud isn't a giant pile of fail. It might be a medium pile of fail, but some basic ops are working, so that's cool. +1 That said, I think having *a* admin call is worthwhile in smoke, because that (privileges working) is a good representative example of the broad ways in which things could be systemically broken. But it needed be explicit: If admin calls are implicit in setting up user tests, that would be more than sufficient IMO. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [octavia] Joining Neutron under the big tent
+1 Governance patch filed: https://review.openstack.org/179417 Thanks, doug On May 1, 2015, at 9:58 AM, Jorge Miramontes jorge.miramon...@rackspace.com wrote: Good stuff. Thanks everyone for your hard work on getting Octavia to this point! Cheers, --Jorge From: Brandon Logan brandon.lo...@rackspace.com mailto:brandon.lo...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 10:20 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent +1 from me From: Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com Sent: Friday, May 1, 2015 8:53 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German german.eichber...@hp.com mailto:german.eichber...@hp.com wrote: Hi, I am proposing that Octavia is joining the Networking program as a project under the Services area. Octavia is the open scalable reference implementation for Neutron LBaaS V2 and has always seen itself as part of the networking program. We have adopted most governance rules from the Networking program, sharing the same build structure, and are organized like an OpenDStack project. This sounds fine to me German. To proceed here, propose something similar to what Russell has proposed for OVN here [1], and ping me on IRC with the review so I can ack it. The TC can then approve it at a future meeting. Thanks! Kyle [1] https://review.openstack.org/#/c/175954/ https://review.openstack.org/#/c/175954/ Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
Excerpts from Adam Lawson's message of 2015-05-01 09:06:20 -0700: So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. *Requiring* reviews would be onerous, but we definitely *encourage* them. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. I think folks who are truly engaged with the existing contributor team will be recognized, and if they feel they are engaged but are not being recognized they should talk to the PTL of the project to understand why. It's likely that not all PTLs are thinking about adding ATCs to their project, and some may just need to be nudged. On the other hand, if you want to have a real, immediate, impact on the future direction of OpenStack start with the folks making the plans for upcoming work by reviewing their proposals. One benefit of the specs review process is that it is open for everyone to participate, and we especially want to hear from operators. I have several times pointed my local meetup group or some individual operators to specifications where I thought their input would be valuable. I don't know how much feedback we're seeing overall from anyone not already designated a contributor (if someone familiar enough with the tools to generate those stats could do it I think it would be useful information). Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] service chaining feature development
Hi Cathy, Thanks for the information. Waiting for the invite. Thanks Swami From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] Sent: Thursday, April 30, 2015 6:17 PM To: adolfo.duar...@hp.com; Vikram Choudhary; Isaku Yamahata; Yamahata, Isaku; Vasudevan, Swaminathan (PNB Roseville); Anand, Ritesh; vishswanan...@hotmail.com; Gal Sagie; Subrahmanyam Ongole; Manish Godara; ybaben...@gmail.com; vishwana...@hotmail.com; Palanisamy, Ila (HP Networking); Li, Lynn; Vasudevan, Swaminathan (PNB Roseville); adrian.ho...@intel.com; Carlos; jdand...@research.att.com; Dirk; ronen.a...@intel.com; sram...@brocade.com; A, Keshava; Wu, Hong-Guang (ES-Best-Shore-Services-China-BJ); yuriy.babe...@telekom.de; ralf.trezec...@telekom.de; ybaben...@gmail.com; Jay-s-b; mathieu.rohon@orange.coSum; Migliaccio, Armando; mest...@mestery.com; openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] service chaining feature development Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] service chaining feature development
Hello everyone, Some of you have reached out to me asking questions about when we will start meeting discussion on the service chaining feature BPs in OpenStack. I have set up agoto meeting for an audio meeting discussion so that we can sync up thought and bring everyone on the same page in a more efficient way. The meeting will be 10am~11am May 5th pacific time. Anyone who has interest in this feature development is welcome to join the meeting and contribute together to the service chain feature in OpenStack. Hope the time is good for most people. OpenStack BP discussion for service chaining Please join the meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/199553557, meeting password: 199-553-557 You can also dial in using your phone. United States +1 (224) 501-3212 Access Code: 199-553-557 - Following are the links to the Neutron related service chain specs and the bug IDs. Feel free to sign up and add you comments/input to the BPs. https://review.openstack.org/#/c/177946 https://bugs.launchpad.net/neutron/+bug/1450617 https://bugs.launchpad.net/neutron/+bug/1450625 Just FYI. There is an approved service chain project in OPNFV. Here is the link to the project page. It will be good to sync up the service chain work between the two communities. https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. Does the current system allow this kind of co-authoring/operator review sort of thing? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow harlo...@outlook.com wrote: Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors
Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200: pbr 0.11 is finally released (now that Kilo is out :). This brings in more support to ensure that our version numbers are monotonically increasing. Mostly this should be unintrusive (but please do read the docs - http://docs.openstack.org/developer/pbr/#version). The key things you need to know are: - setup.cfg's with a version line in it are 'preversioned' - preversioning requires an *immediate* commit to a branch right after a final release is done, to update the setup.cfg - without this, no future changes can be landed. Details below. - most projects - particularly non-server projects - should be able to remove remove the version entry from setup.cfg and let pbr manage everything. This is 'postversioning', and pbr will calculate the next appropriate version number based on the git history. Details: say your project is tempest, and you have 'version = 4' in setup.cfg. This tells pbr that you want your next final release to be 4.0.0[the .0.0 is implied]. Then you tag a release: 'git tag -s 4' (or 4.0.0 - same difference to pbr). This tells pbr that you *have released* 4.0.0. Then you do a new commit to the tree. What version should pbr choose? By having a version= line in setup.cfg, you've turned off pbr's automatic selection of a good version, but it will cross-check to prevent your versions rolling backwards - and since 4 has been released there are *no* versions that are lower than the release, for it to choose from. So - the next commit needs to be the one where you choose a new version (be that 4.0.1 or 5 or whatever) as a target. Alternatively, you can choose to let pbr's version calculation logic automatically determine the version - just remove the version = line from setup.cfg entirely, and pbr will generate numbers for you, with you choosing the actual one when you make a new tag. We're dealing with the most visible projects that have bad metadata now in -infra, but projects using pbr elsewhere will probably be puzzled - thus this email :) It would be good to make sure this is in the pbr documentation, too. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [octavia] Joining Neutron under the big tent
+1 --Adam https://keybase.io/rm_you From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 11:19 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent +1 Governance patch filed: https://review.openstack.org/179417 Thanks, doug On May 1, 2015, at 9:58 AM, Jorge Miramontes jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote: Good stuff. Thanks everyone for your hard work on getting Octavia to this point! Cheers, --Jorge From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 10:20 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent +1 from me From: Kyle Mestery mest...@mestery.commailto:mest...@mestery.com Sent: Friday, May 1, 2015 8:53 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [octavia] Joining Neutron under the big tent On Thu, Apr 30, 2015 at 5:17 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, I am proposing that Octavia is joining the Networking program as a project under the Services area. Octavia is the open scalable reference implementation for Neutron LBaaS V2 and has always seen itself as part of the networking program. We have adopted most governance rules from the Networking program, sharing the same build structure, and are organized like an OpenDStack project. This sounds fine to me German. To proceed here, propose something similar to what Russell has proposed for OVN here [1], and ping me on IRC with the review so I can ack it. The TC can then approve it at a future meeting. Thanks! Kyle [1] https://review.openstack.org/#/c/175954/ Thanks, German __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
Same is true of network shares. If its already listed in fstab, it will just work. But an admin's got to manually add it there. My point is automation is not supported in cinder either? Thanks, Kevin From: Ben Swartzlander [b...@swartzlander.org] Sent: Friday, May 01, 2015 8:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf On 05/01/2015 09:32 AM, Fox, Kevin M wrote: Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... That not really true. If the volume is already formatted with a filesystem, and the filesystem is listed in the fstab, linux will mount it automatically. Same with Windows. Even unlabelled volumes could be automatically formatted and mounted with some script inside the guest that was watching for the right events. With shares, even the basic notification is not there, nor is there a standard way for a guest to determine what mounts are available out there (the equivalent of the existence of the /dev/* files). We'd like to solve these 2 basic problems in a way that's standard across all Manila instances. Of course what consumes that information and what happens afterwards would ideally be up the the tenant, and we would like to provide a set of samples for popular use cases. -Ben Thanks, Kevin From: Deepak Shetty Sent: Thursday, April 30, 2015 9:54:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf Hi, Have we considered cloud-init and qemu guest agent, I remember there was some discussion around this in the prev summit, but i couldn't find any etherpad/notes on that. I had one more question in this regards. Is it possible to do some kind of VM hotplug add operation as part of manila access allow which will cause the VM to see a new drive with a pre-specified label and a client inside the VM will mount it as part of the udev/uevent ? On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.commailto:clinton.kni...@netapp.com wrote: Thanks, Luis, I agree with your assessment that one good way to solve this issue is a publisher-subscriber model. The publisher would be Manila, using zeroconf or AMQP or Zaqar (the one I¹m investigating now). The subscriber would be a lightweight agent running on the client that listens for share availability events and handles the mounts. One open question is whether Manila needs to store a record of client mounts, without which it could not influence the mount paths on each client. Clinton On 4/27/15, 1:49 PM, Luis Pabon lpa...@redhat.commailto:lpa...@redhat.com wrote: Hi Clinton, I think there are two main parts that are needed to automatically mount Manila shares. One is the share discovery model, and the other is enabling the virtual machine to mount the share. I think the only benefit to using zeroconf would be as a standard way to broadcast availability of a network share regardless of protocol. Manila could broadcast the availability of a share by using a name like _manila_nfs, _manila_cifs, _manila_gluster, etc. Although, even with zeroconf, the virtual machine still requires an agent to be able to attach the share for use. I think the real benefit of using zeroconf is its simplicity. There could still be other methods we can investigate. For example (don't kill me for this ;-)), have a Manila YP NIS service for NFS shares? - Luis - Original Message - From: Clinton Knight clinton.kni...@netapp.commailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Sent: Wednesday, April 22, 2015 3:29:50 PM Subject: [openstack-dev] [Manila] Mount automation using Zeroconf Hello, Manila-philes. Back in Paris we started talking about Manila mount automation, whereby file shares could be automatically mounted on clients, and this will likely be a topic in Vancouver. So in order to have an informed discussion at the summit, I'd like to explore a few things beforehand. Besides brute force approaches like SSH or PsExec, one of the community suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds attractive on the surface, but it seems to have a number of limitations: * No standard way to specify local mount point * Additional setup required to work beyond the 'local' domain * Custom software needed on clients to mount advertised shares * Same issues with network connectivity as any other mount automation solution Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila mount automation? Thanks, Clinton Knight Manila core team [1]
Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool?
The subnet_id on the pool specifies what networks to plug when everything is first configured.Iif you add a member to the pool that is outside this subnet, there may not be a route to it, since it is probably on a different network that is not correctly plugged on the LB host. (I hope this is correct, it is from memory from a bit ago.) --Adam https://keybase.io/rm_you From: Wanjing Xu wanjing...@hotmail.commailto:wanjing...@hotmail.com Reply-To: OpenStack Development Mailing List not for usage questions openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, April 30, 2015 at 5:15 PM To: OpenStack Development Mailing List not for usage questions openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? Thanks Bharath for replying. But when I add members , I can successfully specify a member ip address from a different pool than the subnet when creating pool, hence the confusion. And theoretically, why would members for a pool have to belong to the same subnet? Date: Tue, 28 Apr 2015 17:50:16 -0700 From: bharath.stac...@gmail.commailto:bharath.stac...@gmail.com To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? Hi Wanjing, As it's Juno, I assume you are using LBaaSv1. If that's the case, as Brandon pointed, there's no subnet-id switch in the neutron lb-member-create command. Having said that you still use the subnet-id in both the following commands: neutron lb-pool-create neutron lb-vip-create You should note that the subnet id in each of the above commands serve different purpose. In the case of lb-pool-create, the subnet-id is provided to make sure that only members belonging to the specified subnet-id could be added to the pool. However, the subnet id in the lb-vip-create command specifies the network range from which an ip is chosen to be assigned as a vip. Thus, you could use different subnets for both the above commands and as long as you have route between those two, the load balancing works. Thanks, Bharath. On Tue, Apr 28, 2015 at 9:19 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: So someone pointed out that you were using lbaas for Juno, which would mean you aren't using LBaaS V2. So you're using V1. V1 member's do not take subnet_id as an attribute. Let me know how you are making your requests. Thanks, Brandon From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Sent: Monday, April 27, 2015 8:40 PM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? I'm assuming you are using LBaaS V2. With that assumption, I'm not sure how you are having to select subnet on the pool. It's not supposed to be a field at all on the pool object. subnet_id is required on the member object right now, but that's something I and others think should just be optional, and if not specified then it's assumed that member can be reached with whatever has already been setup. Another option is pool could get a subnet_id field in the future and all members that are created without subnet_id are assumed to be on the pool's subnet_id, but I'm getting ahead of myself and this has no bearing on your current issue. Could you tell me how you are making your requests? CLI? REST directly? From: Wanjing Xu wanjing...@hotmail.commailto:wanjing...@hotmail.com Sent: Monday, April 27, 2015 12:57 PM To: OpenStack Development Mailing List not for usage questions Subject: [openstack-dev] [Neutron][LBaaS] Why do we need to select subnet when creating a pool? So when I use Haproxy for LBaaS for Juno, there is a subnet mandatary field that I need to fill in when creating a pool, and later on when I add members, I can use a different subnet(or simply just enter the ip of the member), when adding vip, I can still select a third subnet. So what is the usage of the first subnet that I used to create pool? There is no port created for this pool subnet. I can see that a port is created for the vip subnet that the loadbalancer instance is binding to. Regards! Wanjing Xu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions)
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. --Morgan -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [docs] Scheduler filters documentation
On Wed, Apr 29, 2015 at 8:00 PM, Jay Pipes jaypi...@gmail.com wrote: On 04/29/2015 03:41 PM, Ed Leafe wrote: On Apr 29, 2015, at 2:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: I'd prefer to see the scheduler filter docs be maintained in the nova devref where they are close to the source, versioned, and reviewed by the nova team when there are scheduler filter changes or new filters added. For now, I think this is best. When and if the scheduler is a separate entity, it will need its own docs; nova will still need to document *its* filters, but not *how to* filter. So, the config-ref docs are auto-generated continually via automation scripts from the help text of options. And, IMO, this is A Good Thing. In this case, the end user of this information is the cloud admin -- the person who creates flavors and tags compute nodes with capability extra specs. The target audience for this information is not really the Nova developer. Now, if there are sections of the devref that need to inform the *developer* about some weird intricacies of the scheduler filters (and frankly, this is kind of one of them), then I think it's OK to have slightly duplicate information. It depends on the target audience. In this particular case, I think it's fine to duplicate a little. Right, to me this is the right approach, thanks Jay. I say this because here are the stats for each page, showing where your audience is. 10,473 page views in six months:[1] http://docs.openstack.org/juno/config-reference/content/section_compute- scheduler.html#aggregate-instanceextraspecsfilter 5,143 page views in same six months: [2] http://docs.openstack.org/developer/nova /devref/filter_scheduler.html#filtering Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
On 05/01/2015 09:32 AM, Fox, Kevin M wrote: Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... That not really true. If the volume is already formatted with a filesystem, and the filesystem is listed in the fstab, linux will mount it automatically. Same with Windows. Even unlabelled volumes could be automatically formatted and mounted with some script inside the guest that was watching for the right events. With shares, even the basic notification is not there, nor is there a standard way for a guest to determine what mounts are available out there (the equivalent of the existence of the /dev/* files). We'd like to solve these 2 basic problems in a way that's standard across all Manila instances. Of course what consumes that information and what happens afterwards would ideally be up the the tenant, and we would like to provide a set of samples for popular use cases. -Ben Thanks, Kevin * * *From:* Deepak Shetty *Sent:* Thursday, April 30, 2015 9:54:31 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Manila] Mount automation using Zeroconf Hi, Have we considered cloud-init and qemu guest agent, I remember there was some discussion around this in the prev summit, but i couldn't find any etherpad/notes on that. I had one more question in this regards. Is it possible to do some kind of VM hotplug add operation as part of manila access allow which will cause the VM to see a new drive with a pre-specified label and a client inside the VM will mount it as part of the udev/uevent ? On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.com mailto:clinton.kni...@netapp.com wrote: Thanks, Luis, I agree with your assessment that one good way to solve this issue is a publisher-subscriber model. The publisher would be Manila, using zeroconf or AMQP or Zaqar (the one I¹m investigating now). The subscriber would be a lightweight agent running on the client that listens for share availability events and handles the mounts. One open question is whether Manila needs to store a record of client mounts, without which it could not influence the mount paths on each client. Clinton On 4/27/15, 1:49 PM, Luis Pabon lpa...@redhat.com mailto:lpa...@redhat.com wrote: Hi Clinton, I think there are two main parts that are needed to automatically mount Manila shares. One is the share discovery model, and the other is enabling the virtual machine to mount the share. I think the only benefit to using zeroconf would be as a standard way to broadcast availability of a network share regardless of protocol. Manila could broadcast the availability of a share by using a name like _manila_nfs, _manila_cifs, _manila_gluster, etc. Although, even with zeroconf, the virtual machine still requires an agent to be able to attach the share for use. I think the real benefit of using zeroconf is its simplicity. There could still be other methods we can investigate. For example (don't kill me for this ;-)), have a Manila YP NIS service for NFS shares? - Luis - Original Message - From: Clinton Knight clinton.kni...@netapp.com mailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Wednesday, April 22, 2015 3:29:50 PM Subject: [openstack-dev] [Manila] Mount automation using Zeroconf Hello, Manila-philes. Back in Paris we started talking about Manila mount automation, whereby file shares could be automatically mounted on clients, and this will likely be a topic in Vancouver. So in order to have an informed discussion at the summit, I'd like to explore a few things beforehand. Besides brute force approaches like SSH or PsExec, one of the community suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds attractive on the surface, but it seems to have a number of limitations: * No standard way to specify local mount point * Additional setup required to work beyond the 'local' domain * Custom software needed on clients to mount advertised shares * Same issues with network connectivity as any other mount automation solution Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila mount automation? Thanks, Clinton Knight Manila core team [1] http://en.wikipedia.org/wiki/Zero-configuration_networking
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I’m trying to capture the various comments from this discussion as time permits in the ether pad for the user committee design session at https://etherpad.openstack.org/p/YVR-ops-user-committee but feel free to add further items you’d like to discuss. The user committee or operators mailing list is, IMHO, a better place for these discussions since they are generally paid to run their clouds. Tim (trying to keep up while running a 140K core cloud and doing lots outreach ) From: Adam Lawson alaw...@aqorn.commailto:alaw...@aqorn.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, May 1, 2015 at 6:06 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates So this is an interesting idea. Would we require operators co-author/review all patches that land? if not (and that actually strikes me as making uploading patches more difficult unnecessarily), My question is how Operators can easily get involved with that process. If Operators want to get recognized for contributing and participate with TC elections, an easy way to start an engagement with some means of tracking would be immensely helpful I think. Does the current system allow this kind of co-authoring/operator review sort of thing? Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] On Fri, May 1, 2015 at 8:44 AM, Joshua Harlow harlo...@outlook.commailto:harlo...@outlook.com wrote: Davanum Srinivas wrote: One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? +1 Kris is a great example, and I can think of other operators that should be some sort of ATC (but may not contribute code to get this). IMHO any operator running openstack (let's say at least at 50+ compute nodes) and operating it should get full access to the summit, because their words of advice/experience are just as useful as technical contributors... thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawsonalaw...@aqorn.commailto:alaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffullistef...@openstack.orgmailto:stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
[openstack-dev] [keystone] Liberty MidCycle Meetup
Hi everyone! I'm happy to announce that (due to overwhelming demand from the development team) Keystone will be holding a MidCycle meetup for Liberty. In an effort to get ahead of the curve and ensure everyone has time to put in for travel arrangements, I am sending out the preliminary details today. Expect that more details will come as we get to the summit and beyond (such as hotels, topics, etc). Keystone Liberty MidCycle Meetup Location: Boston University (Main Campus) Boston, MA Dates: July 15, 16, and 17th I want to thank the Massachusetts Open Cloud [1] for offering to host us at BU! It will be a great meetup in a great city. I'll send out more details as they become available. Cheers, Morgan [1] http://www.bu.edu/hic/research/massachusetts-open-cloud/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors
On 2 May 2015 at 04:17, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200: pbr 0.11 is finally released (now that Kilo is out :). This brings in more support to ensure that our version numbers are monotonically increasing. Mostly this should be unintrusive (but please do read the docs - http://docs.openstack.org/developer/pbr/#version). ... It would be good to make sure this is in the pbr documentation, too. It is, at the link I gave. If its not clear enough, please do help me understand how, since having clear docs is kindof important :) I'd also like to do a little postmortem - here's the fallout I've heard of from pbr's 0.11 release (which is 1yr of inventory, so kindof a big deal). Two number of projects had backslid since the audit I did last year on their setup.cfg's: tempest and rally. These have all been trivially fixed by removal. tempest's caused issues in many different projects test runs though, which let to some confused reports - generally any patch hitting that issue should be fine on a recheck. http://logs.openstack.org/85/179285/1/check/check-tempest-dsvm-full/1c5fec4/logs/devstacklog.txt.gz#_2015-04-30_23_47_08_277 and the following error show this. Nova had a unit test that mocked out only part of the API it was using, and when the internals of pbr changed, the mocking stopped being effective. It was using VersionInfo.version_string, but mocking VersionInfo.version. https://review.openstack.org/179307 and the associated backports fix this. I think we should move the vendor functionality into pbr itself (you'd give pbr a callback to get the vendor info) rather than having multiple copies of it one per server, all potentially different. Lastly, and still unresolved, heat's contrib plugin versions (introduced in March) are deliberately different to the git history, and thats a use case that pbr hasn't ever supported (multiple version timelines in one git tree). https://review.openstack.org/#/c/162311/ introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733 is the bug for this. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Congrats (I think) to the new TC
On 04/30/15 16:40, Jay Pipes wrote: On 04/30/2015 09:26 AM, David Medberry wrote: Hey guys, Congrats to the new TC leaders. http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688 Please reach out to me (and openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org) if you ever need operator input (that you aren't already getting.) And many thanks for volunteering so much of your time this go round I *most* certainly will be reaching out to you, David. First up on the operator-related docket for me will be tags that represent production-level maturity. I have always maintained the the TC should help create the tag definition with the help of the operator community and rely on the operator community to determine which projects can get the tag applied to them. I hope you will be an instrument in achieving that collaboration. All the best, -jay A huge congratulations from me as well. I would also like to offer my help from an operator perspective and perhaps I can also help with the tasks that were discussed regarding finding a way to get the information out there to those who are not 'OpenStack savvy' or 'strong with the OpenStack force' . I have learned a lot from this election, the process, the candidates, the active members of the community, and also from the results. I definitely think we are on the right path. Rome was not built in a day, peace in the middle east will not come for another 1000 years and changes take time. -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][api] API working group liaisons and responsibilities
On Apr 30, 2015, at 9:54 AM, Jay Pipes jaypi...@gmail.com wrote: Hi Stackers, OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova team's liaisons to the API working group. Big thank you to Matthew and Alex for volunteering for this important role. I've created a wiki page [1] that details the responsibilities of these liaisons. If these duties work out for Nova, we'll recommend other projects pick them up. Here are the responsibilities that the Nova/API working group liaisons have: 1. Monitor the active patch queue in nova (and nova-specs) and look out for any patch that adds or changes the REST API 2. For each patch collected in #1, determine if the constructs used in the patch (or proposed spec) match the guidance currently laid out in the API working group repo's guidance documents. 3. If the patch does NOT match the guidance from the API working group, do a code review on the patch pointing to the guidance from the API working group, and ask the author to align with that guidance. Include in your research patches to the API working group that may actually be in review and not merged. (An example of this recently occurred with Sergey Nikitin's re-proposed instance tagging spec: https://review.openstack.org/#/c/177112/. See Ryan Brown's reference to an in-progress API working group guidance on tagging) 4. If there is NO guidance in the API working group repo for a particular proposed API change or addition, the liaison should **either** create a proposed patch to the API working group with guidance that clarifies the missing functionality that is introduced in the new Nova patch or spec patch, and bring the proposed guidance to the attention of the API working group. **or** the liaison should working with a member of the API working group to draft such a guideline. The liaison should mark the corresponding Nova patch with a -1 Code Review vote with a link to the proposed guideline, noting that the patch should be put on hold (Work In Progress) until the guideline is merged. Best, -jay [1] https://wiki.openstack.org/wiki/Nova/APIWGLiaisons This is great. I’ve added a link to that page from the Cross-Project Liaisons page [2]. I also added Matthew and Alex as liaisons there. giiard and alex_xu: feel free to join us in #openstack-api on freenode too! Everett [2] https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][api] 3 API Guidelines up for final review
All 3 API guidelines have merged. Thanks everyone! Everett On Apr 22, 2015, at 2:08 PM, Everett Toews everett.to...@rackspace.com wrote: Hi All, We have 3 API Guidelines that are ready for a final review. 1. Metadata guidelines document https://review.openstack.org/#/c/141229/ 2. Tagging guidelines https://review.openstack.org/#/c/155620/ 3. Guidelines on using date and time format https://review.openstack.org/#/c/159892/ If the API Working Group hasn’t received any further feedback, we’ll merge them on April 29. Thanks, Everett __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I purposely didn't email the general mailing list since I didn't want to cross-post, hard to have these discussions across verticals and choosing one list = hearing one community - those subscribed to the developer mailing list. So I'm not assuming anything, it seems some are suggesting that Operators get into code review to quantify their role as an engaged Operator. Is that a correct statement? Just want to make sure I'm hearing correctly. I try to avoid absolutes but personally speaking for the record, I don't believe the answer lies with asking Operators to become code reviewers on top of everthing else they're doing in order for them to have a voice in the TC elections. If code reviews are being suggested (again, assuming the assumption is correct for the sake of making my point), technical contribution extends far beyond uploading and reviewing code. This alternate means to gain ATC status seems like a potential candidate for those who want to review code but not for those who are day-to-day operators engaging with the community. Is there any meetings planned in Vancouver where users/operators are meeting where we can add an agenda items to gather input? Given this conversation involves the Operator community as well, I went ahead and CC'd them to hopefully capture their specific thoughts/ideas on the subject. Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Friday, May 1, 2015, Russell Bryant rbry...@redhat.com wrote: On 05/01/2015 02:22 PM, Tim Bell wrote: The spec review process has made it much easier for operators to see what is being proposed and give input. Recognition is a different topic. It also comes into who would be the operator/user electorate ? ATC is simple to define where the equivalent operator/user definition is less clear. I think spec review participation is a great example of where it would make sense to grant extra ATC status. If someone provides valuable spec input, but hasn't made any commits that get ATC status, I'd vote to approve their ATC status if proposed. This is exactly the case for David Chadwick (U of Kent) if anyone is looking for prior examples of someone who has contributed to the spec process but has not landed code and has received ATC for the contributions. This is a great way to confer ATC for spec participation. --Morgan -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Deadline for submitting Nova Design Summit Session Proposals
Hi, In case you were unable to make yesterday's Nova meeting... If you have a suggestion for a Nova design summit session, please ensure you add it to before the next Nova meeting (7th May): https://etherpad.openstack.org/p/liberty-nova-summit-ideas Shortly after that Nova meeting, the (mostly) final schedule will be uploaded here: http://libertydesignsummit.sched.org/type/design+summit/Nova Priority will be given to issues where need to build a consensus on the way forward with the whole community. We had a nova-drivers meeting to agree on a provisional list of sessions, based on suggested sessions at the time. You can see that list at the very end of the summit ideas etherpad. If you have a feature you want feedback on, please submit a nova-spec, in the usual way. We have scheduled some 'unconference' time to discuss stuck nova-spec reviews. We will fill up those slots during the week of the summit. In addition to the scheduled fishbowl sessions, and unconference slots, just like in Paris, all day Friday will be a nova contributor meetup. We are collecting topics for the meetup on this etherpad: https://etherpad.openstack.org/p/liberty-nova-summit-meetup Notice I have scheduled the first 40 mins after lunch on Friday for individual sub team discussions, designed to replace the fishbowl virt driver sessions we have done previously. We can decide how that will work, and if its needed, on Friday morning. Any questions, or ideas, please let me know, and I will do my best to help. Thanks, johnthetubaguy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
On 05/01/2015 12:54 AM, Deepak Shetty wrote: Hi, Have we considered cloud-init and qemu guest agent, I remember there was some discussion around this in the prev summit, but i couldn't find any etherpad/notes on that. I had one more question in this regards. Is it possible to do some kind of VM hotplug add operation as part of manila access allow which will cause the VM to see a new drive with a pre-specified label and a client inside the VM will mount it as part of the udev/uevent ? The only way to get hotplug working for shares (that I know of) would be to use virtfs. In that case the hypervisor would mount the share and present it to the guest through a p9fs/virtio tunnel. This would be pretty cool but also has a bunch of disadvantages: * Doesn't work w/ Windows guests * Doesn't work with hypervisors other than qemu/xen * p9fs semantics are different than native nfs/cifs to the client * Some apps are coded to use NFS directly (not through the OS's built in nfs client) * Many apps are tested/qualified with NFS/CIFS but not virtfs * Locking and FS metadata work significantly differently * VirtFS appears to be abandonware If anyone knows of a way other than VirtFS to get cool hotplug semantics, I'd love to know. Also, if any of my above assertions are false, I'd also love to know about that too. -Ben Swartzlander On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.com mailto:clinton.kni...@netapp.com wrote: Thanks, Luis, I agree with your assessment that one good way to solve this issue is a publisher-subscriber model. The publisher would be Manila, using zeroconf or AMQP or Zaqar (the one I¹m investigating now). The subscriber would be a lightweight agent running on the client that listens for share availability events and handles the mounts. One open question is whether Manila needs to store a record of client mounts, without which it could not influence the mount paths on each client. Clinton On 4/27/15, 1:49 PM, Luis Pabon lpa...@redhat.com mailto:lpa...@redhat.com wrote: Hi Clinton, I think there are two main parts that are needed to automatically mount Manila shares. One is the share discovery model, and the other is enabling the virtual machine to mount the share. I think the only benefit to using zeroconf would be as a standard way to broadcast availability of a network share regardless of protocol. Manila could broadcast the availability of a share by using a name like _manila_nfs, _manila_cifs, _manila_gluster, etc. Although, even with zeroconf, the virtual machine still requires an agent to be able to attach the share for use. I think the real benefit of using zeroconf is its simplicity. There could still be other methods we can investigate. For example (don't kill me for this ;-)), have a Manila YP NIS service for NFS shares? - Luis - Original Message - From: Clinton Knight clinton.kni...@netapp.com mailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Sent: Wednesday, April 22, 2015 3:29:50 PM Subject: [openstack-dev] [Manila] Mount automation using Zeroconf Hello, Manila-philes. Back in Paris we started talking about Manila mount automation, whereby file shares could be automatically mounted on clients, and this will likely be a topic in Vancouver. So in order to have an informed discussion at the summit, I'd like to explore a few things beforehand. Besides brute force approaches like SSH or PsExec, one of the community suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds attractive on the surface, but it seems to have a number of limitations: * No standard way to specify local mount point * Additional setup required to work beyond the 'local' domain * Custom software needed on clients to mount advertised shares * Same issues with network connectivity as any other mount automation solution Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila mount automation? Thanks, Clinton Knight Manila core team [1] http://en.wikipedia.org/wiki/Zero-configuration_networking __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack
[openstack-dev] [nova] Blueprints and Specs for Liberty Deadline
Hi, Just a quick reminder that blueprints and nova-specs need to be approved for liberty, even if they have already been approved for a previous release. I added deadline in the subject mostly just to get your attention. We haven't agreed a deadline for spec and blueprint submissions yet, but expect it to be near liberty-1: https://wiki.openstack.org/wiki/Liberty_Release_Schedule As with kilo, not all blueprints will need a spec, for details please see: http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html If you think your blueprint doesn't need a spec, but you want to get it approve for liberty, please add a link to your blueprint to the agenda for the next nova-meeting: https://wiki.openstack.org/wiki/Meetings/Nova If you want to get your nova-spec reviewed for liberty, please submit that ASAP. Ideally before the summit, so any problems that come up during the review can be discussed at the summit. We already have lots of approved blueprints that are up for review: https://blueprints.launchpad.net/nova/liberty Please note we are not attempting to predict what features will land in each milestone during liberty. For more details please see: https://wiki.openstack.org/wiki/Release_Cycle_Management/Liberty_Tracking Any questions around process, please just ask, and I can help you move forward. Asking sooner helps us fix the problem sooner. Thanks, johnthetubaguy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core
+1 :) 2015-04-30 20:30 GMT+09:00 John Garbutt j...@johngarbutt.com: Hi, I propose we add Melanie to nova-core. She has been consistently doing great quality code reviews[1], alongside a wide array of other really valuable contributions to the Nova project. Please respond with comments, +1s, or objections within one week. Many thanks, John [1] https://review.openstack.org/#/dashboard/4690 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] Proposal for Madhuri Kumari to join Core Team
Hi All, Thank you for adding me to this team. It will be my pleasure to work with you all together. Till now, everyone has helped me in many or some way. Thank you for all the support and this honor. Looking forward for contributing more. Thanks Regards Madhuri Kumari On Fri, May 1, 2015 at 10:25 AM, Adrian Otto adrian.o...@rackspace.com wrote: Team, Madnuri has been added to the magnum-core group [1]. Thanks everyone for your votes. Regards, Adrian [1] https://review.openstack.org/#/admin/groups/473,members On Apr 30, 2015, at 8:48 PM, Hongbin Lu hongbin...@gmail.com wrote: +1! On Apr 28, 2015, at 11:14 PM, Steven Dake (stdake) std...@cisco.com wrote: Hi folks, I would like to nominate Madhuri Kumari to the core team for Magnum. Please remember a +1 vote indicates your acceptance. A –1 vote acts as a complete veto. Why Madhuri for core? 1. She participates on IRC heavily 2. She has been heavily involved in a really difficult project to remove Kubernetes kubectl and replace it with a native python language binding which is really close to be done (TM) 3. She provides helpful reviews and her reviews are of good quality Some of Madhuri’s stats, where she performs in the pack with the rest of the core team: reviews: http://stackalytics.com/?release=kilomodule=magnum-group commits: http://stackalytics.com/?release=kilomodule=magnum-groupmetric=commits Please feel free to vote if your a Magnum core contributor. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila] Mount automation using Zeroconf
Hmm The cinder volumes dont automount either. /dev/vdx shows up, but you have to format/mount it yourself. Maybe both teams could share a common solution? Im guessing it will have to be an agent... Thanks, Kevin From: Deepak Shetty Sent: Thursday, April 30, 2015 9:54:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Manila] Mount automation using Zeroconf Hi, Have we considered cloud-init and qemu guest agent, I remember there was some discussion around this in the prev summit, but i couldn't find any etherpad/notes on that. I had one more question in this regards. Is it possible to do some kind of VM hotplug add operation as part of manila access allow which will cause the VM to see a new drive with a pre-specified label and a client inside the VM will mount it as part of the udev/uevent ? On Tue, Apr 28, 2015 at 11:50 PM, Knight, Clinton clinton.kni...@netapp.commailto:clinton.kni...@netapp.com wrote: Thanks, Luis, I agree with your assessment that one good way to solve this issue is a publisher-subscriber model. The publisher would be Manila, using zeroconf or AMQP or Zaqar (the one I¹m investigating now). The subscriber would be a lightweight agent running on the client that listens for share availability events and handles the mounts. One open question is whether Manila needs to store a record of client mounts, without which it could not influence the mount paths on each client. Clinton On 4/27/15, 1:49 PM, Luis Pabon lpa...@redhat.commailto:lpa...@redhat.com wrote: Hi Clinton, I think there are two main parts that are needed to automatically mount Manila shares. One is the share discovery model, and the other is enabling the virtual machine to mount the share. I think the only benefit to using zeroconf would be as a standard way to broadcast availability of a network share regardless of protocol. Manila could broadcast the availability of a share by using a name like _manila_nfs, _manila_cifs, _manila_gluster, etc. Although, even with zeroconf, the virtual machine still requires an agent to be able to attach the share for use. I think the real benefit of using zeroconf is its simplicity. There could still be other methods we can investigate. For example (don't kill me for this ;-)), have a Manila YP NIS service for NFS shares? - Luis - Original Message - From: Clinton Knight clinton.kni...@netapp.commailto:clinton.kni...@netapp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Sent: Wednesday, April 22, 2015 3:29:50 PM Subject: [openstack-dev] [Manila] Mount automation using Zeroconf Hello, Manila-philes. Back in Paris we started talking about Manila mount automation, whereby file shares could be automatically mounted on clients, and this will likely be a topic in Vancouver. So in order to have an informed discussion at the summit, I'd like to explore a few things beforehand. Besides brute force approaches like SSH or PsExec, one of the community suggestions was to use Zeroconf (aka Bonjour)[1]. Zeroconf sounds attractive on the surface, but it seems to have a number of limitations: * No standard way to specify local mount point * Additional setup required to work beyond the 'local' domain * Custom software needed on clients to mount advertised shares * Same issues with network connectivity as any other mount automation solution Does anyone have a clearer idea how Zeroconf might satisfy the need for Manila mount automation? Thanks, Clinton Knight Manila core team [1] http://en.wikipedia.org/wiki/Zero-configuration_networking __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
