[openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually *(not sure if this section needs to be commented)* http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Add a pollster plugin
Thanks a lot, Doug. It does work after configuring pipeline.yaml. Regards, Gary On Aug 12, 2014, at 4:11 AM, Duan, Li-Gong (Gary at HPServers-Core-OE-PSChttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev) li-gong.duan at hp.comhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev wrote: Hi Folks, Is there any best practices or good way to debug whether new pollster plugin work fine for ceilometer? I'd like to add a new pollster plugin into Ceilometer by - adding a new item under enterypoint/ceilometer.poll.central in setup.cfg file - adding the implementation code inheriting plugin.CentralPollster. But when I sudo python setup.py install and restart ceilometer-related services in devstack, NO new metering is displayed upon ceilometer meter-list and I expect that there should be a new metering showing the item defined in setup.cfg. Is there any other source/config files I need to modify or add? You need to define a pipeline [1] to include the data from your new pollster and schedule it to be run. Doug [1] http://docs.openstack.org/developer/ceilometer/configuration.html#pipelines Thanks in advance, Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Mistral milestone 0.1 blueprint review
Thanks, Dmitri, I left my comments in the document you shared. Please take a loot at them. We also need to define a reasonable date for 0.1 release which is now set to Sept 11 according to my very raw estimates. We may want to move it a little bit. Renat Akhmerov @ Mirantis Inc. On 14 Aug 2014, at 08:30, Dmitri Zimine dzim...@stackstorm.com wrote: Renat, team: The current plan of record on 0.1 here, https://launchpad.net/mistral/+milestone/0.1 Some suggested adjustments: https://docs.google.com/a/stackstorm.com/document/d/1Ukd6SDk9tMpn8kpti-kXaOzVhl8Jm1YWTh3Kw1A6lgQ/edit# Pls use the doc to comment/disccuss and let’s decide by next mistral iRC meeting on Mon. Regards, Dmitri. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Nova API meeting
Hi, Just a reminder that the weekly Nova API meeting is being held tomorrow Friday UTC . We encourage cloud operators and those who use the REST API such as SDK developers and others who and are interested in the future of the API to participate. In other timezones the meeting is at: EST 20:00 (Thu) Japan 09:00 (Fri) China 08:00 (Fri) ACDT 9:30 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. Walt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree
Hi Aaron: There is a certain fear of another cascading chain of emails so with hesitation i send this email out. :-) 1) I could not agree with u more on the issue with the logs and the pain with debugging issues here. Yes for sure bugs do keep popping up but often times, (speaking for fwaas) - given the L3 agent interactions - there are a multitude of reasons for a failure. An L3Agent crash or a router issue - also manifests itself as an fwaas issue - i think ur first paste is along those lines (perhaps i could be wrong without much context here). The L3Agent - service coexistence is far from ideal - but this experience has lead to two proposals - a vendor proposal [1] that actually tries to address such agent limitations and collaboration on another community proposal[2] to enable the L3 Agent to be more suited to hosting services. Hopefully [2] will get picked up in K and should help provide the necessary infrastructure to clean up the reference implementation. 2) Regarding ur point on the FWaaS API - the intent of the feature by design was to keep the service abstraction separate from how it is inserted in the network - to keep this vendor/technology neutral. The first priority, post Havana was to address service insertion to get away from the all routers model [3] but did not get the blessings needed. Now with a redrafted proposal for Juno[4] again an effort is being made to address this now for the second time in the 2 releases post H. In general, I would make a request that before we decide to go ahead and start moving things out into an incubator area - more discussion is needed. We don’t want to land up in a situation in K-3 where we find out that this model does not quite work for whatever reason. Also i wonder about the hoops to get out from incubation. As vendors who try to align with the community and upstream our work - we don’t want to land up waiting more cycles - there is quite a bit of frustration that is felt here too. Lets also think about the impacts on feature velocity, somehow that keeps popping into my head every time i buy a book from a certain online retailer. :-) [1] https://review.openstack.org/#/c/90729/ [2] https://review.openstack.org/#/c/91532/ [3] https://review.openstack.org/#/c/62599/ [4] https://review.openstack.org/#/c/93128/ Thanks Sridar From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 13, 2014 at 3:56 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree Hi, I've been thinking a good bit on this on the right way to move forward with this and in general the right way new services should be added. Yesterday I was working on a bug that was causing some problems in the openstack infra. We tracked down the issue then I uploaded a patch for it. A little while later after jenkins voted back a -1 so I started looking through the logs to see what the source of the failure was (which was actually unrelated to my patch). The random failure in the fwaas/vpn/l3-agent code which all outputs to the same log file that contains many traces for every run even successful ones. In one skim of this log file I was able to spot 4 [1]bugs which shows these new experimental services that we've added to neutron have underlying problems (even though they've been in the tree for 2 releases+ now). This puts a huge strain on the whole openstack development community as they are always recheck no bug'ing due to neutron failures. If you look at the fwaas work that was done. This merged over two releases ago and still does not have a complete API as there is no concept of where enforcement should be done. Today, enforcement is done across all of a tenant's routers making it more or less useless imho and we're just carrying it along in the tree (and it's causing us problems)! I think Mark's idea of neutron-incubator[2] is a great step forward to improving neutron. We can easily move these things out of the neutron source tree and we can plug these things in here: https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L52 https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L72 (GASP: We have seen shipped our own API's here to customers before we were able to upstream them). This allows us to decouple these experimental things from the neutron core and allows us to release these components on their own making things more modular/maintainable and stable (I think these things might even be better long term living out of the tree). Most importantly though it doesn't put a burden on everyone else. Best, Aaron [1] http://paste.openstack.org/show/94664/ http://paste.openstack.org/show/94670/
[openstack-dev] [heat] heat docker multi host scheduling support
Hi all, I am trying to use heat to create docker containers. I have configured heat-docker plugin. I am also able to create stack using heat successfully. To start container on different host we need to provide 'docker_endpoint' in template. For this we have to provide host address where container will run in template. Is there any way to schedule docker container on available hosts using heat-docker plugin without giving 'docker_endpoint' in template file. Is heat-docker plugin supports managing docker hosts cluster with scheduling logic. Please let me know your suggestions on the same. Thanks, Abhijeet __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?
On 08/13/2014 06:05 PM, Sylvain Bauza wrote: Le 13/08/2014 12:21, Sylvain Bauza a écrit : Le 12/08/2014 22:06, Sylvain Bauza a écrit : Le 12/08/2014 18:54, Nikola Đipanov a écrit : On 08/12/2014 04:49 PM, Sylvain Bauza wrote: (sorry for reposting, missed 2 links...) Hi Nikola, Le 12/08/2014 12:21, Nikola Đipanov a écrit : Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - I'll add it to compute nodes table thinking it's a fundamental enough property of a compute host that it deserves to be there, although I was considering Extensible Resource Tracker at one point (ERT from now on - see [2]) but looking at the code - it did not seem to provide anything I desperately needed, so I went with keeping it simple. So fast-forward a few days, and I caught myself solving a problem that I kept thinking ERT should have solved - but apparently hasn't, and I think it is fundamentally a broken design without it - so I'd really like to see it re-visited. The problem can be described by the following lemma (if you take 'lemma' to mean 'a sentence I came up with just now' :)): Due to the way scheduling works in Nova (roughly: pick a host based on stale(ish) data, rely on claims to trigger a re-schedule), _same exact_ information that scheduling service used when making a placement decision, needs to be available to the compute service when testing the placement. This is not the case right now, and the ERT does not propose any way to solve it - (see how I hacked around needing to be able to get extra_specs when making claims in [3], without hammering the DB). The result will be that any resource that we add and needs user supplied info for scheduling an instance against it, will need a buggy re-implementation of gathering all the bits from the request that scheduler sees, to be able to work properly. Well, ERT does provide a plugin mechanism for testing resources at the claim level. This is the plugin responsibility to implement a test() method [2.1] which will be called when test_claim() [2.2] So, provided this method is implemented, a local host check can be done based on the host's view of resources. Yes - the problem is there is no clear API to get all the needed bits to do so - especially the user supplied one from image and flavors. On top of that, in current implementation we only pass a hand-wavy 'usage' blob in. This makes anyone wanting to use this in conjunction with some of the user supplied bits roll their own 'extract_data_from_instance_metadata_flavor_image' or similar which is horrible and also likely bad for performance. I see your concern where there is no interface for user-facing resources like flavor or image metadata. I also think indeed that the big 'usage' blob is not a good choice for long-term vision. That said, I don't think as we say in French to throw the bath water... ie. the problem is with the RT, not the ERT (apart the mention of third-party API that you noted - I'll go to it later below) This is obviously a bigger concern when we want to allow users to pass data (through image or flavor) that can affect scheduling, but still a huge concern IMHO. And here is where I agree with you : at the moment, ResourceTracker (and consequently Extensible RT) only provides the view of the resources the host is knowing (see my point above) and possibly some other resources are missing. So, whatever your choice of going with or without ERT, your patch [3] still deserves it if we want not to lookup DB each time a claim goes. As I see that there are already BPs proposing to use this IMHO broken ERT ([4] for example), which will surely add to the proliferation of code that hacks around these design shortcomings in what is already a messy, but also crucial (for perf as well as features) bit of Nova code. Two distinct implementations of that spec (ie. instances and flavors) have been proposed [2.3] [2.4] so reviews are welcome. If you see the test() method, it's no-op thing for both plugins. I'm open to comments because I have the stated problem : how can we define a limit on just a counter of instances and flavors ? Will look at these - but none of them seem to hit the issue I am complaining about, and that is that it will need to consider other request data for claims, not only data available for on instances. Also - the fact that you don't implement test() in flavor ones tells me that the implementation is indeed racy (but it is racy atm as well) and two requests can indeed race for the same host, and since no claims are done, both can succeed. This is I believe (at least in case of single flavor hosts) unlikely to happen in practice, but you get the idea. Agreed, these 2 patches probably require another iteration, in particular how we make sure that it
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On Wed, 13 Aug 2014 18:52:05 -0400 Jay Pipes jaypi...@gmail.com wrote: On 08/13/2014 06:35 PM, Russell Bryant wrote: On 08/13/2014 06:23 PM, Mark McLoughlin wrote: On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote: cor...@inaugust.com (James E. Blair) writes: Sean Dague s...@dague.net writes: This has all gone far enough that someone actually wrote a Grease Monkey script to purge all the 3rd Party CI content out of Jenkins UI. People are writing mail filters to dump all the notifications. Dan Berange filters all them out of his gerrit query tools. I should also mention that there is a pending change to do something similar via site-local Javascript in our Gerrit: https://review.openstack.org/#/c/95743/ I don't think it's an ideal long-term solution, but if it works, we may have some immediate relief without all having to install greasemonkey scripts. You may have noticed that this has merged, along with a further change that shows the latest results in a table format. (You may need to force-reload in your browser to see the change.) Beautiful! Thank you so much to everyone involved. +1! Love this. Indeed. Amazeballs. Agreed! This is a really nice improvement Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree
FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it can only handle NS traffic, leaving W-E untouched. If we implement the WE firewall in DVR, the iptable might be applied at a per port basis, so there are some overlapping with SG (Can we image a packet run into iptable hook twice between VM and the wire, for both ingress and egress directions?). Maybe the overall service plugins (including service extension in ML2) needs some cleaning up, It seems that Neutron is just built from separate single blocks. [1] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/neutron-dvr-fwaas.rst From: Sridar Kandaswamy (skandasw) [skand...@cisco.com] Sent: Thursday, August 14, 2014 3:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree Hi Aaron: There is a certain fear of another cascading chain of emails so with hesitation i send this email out. :-) 1) I could not agree with u more on the issue with the logs and the pain with debugging issues here. Yes for sure bugs do keep popping up but often times, (speaking for fwaas) - given the L3 agent interactions - there are a multitude of reasons for a failure. An L3Agent crash or a router issue - also manifests itself as an fwaas issue - i think ur first paste is along those lines (perhaps i could be wrong without much context here). The L3Agent - service coexistence is far from ideal - but this experience has lead to two proposals - a vendor proposal [1] that actually tries to address such agent limitations and collaboration on another community proposal[2] to enable the L3 Agent to be more suited to hosting services. Hopefully [2] will get picked up in K and should help provide the necessary infrastructure to clean up the reference implementation. 2) Regarding ur point on the FWaaS API - the intent of the feature by design was to keep the service abstraction separate from how it is inserted in the network - to keep this vendor/technology neutral. The first priority, post Havana was to address service insertion to get away from the all routers model [3] but did not get the blessings needed. Now with a redrafted proposal for Juno[4] again an effort is being made to address this now for the second time in the 2 releases post H. In general, I would make a request that before we decide to go ahead and start moving things out into an incubator area - more discussion is needed. We don’t want to land up in a situation in K-3 where we find out that this model does not quite work for whatever reason. Also i wonder about the hoops to get out from incubation. As vendors who try to align with the community and upstream our work - we don’t want to land up waiting more cycles - there is quite a bit of frustration that is felt here too. Lets also think about the impacts on feature velocity, somehow that keeps popping into my head every time i buy a book from a certain online retailer. :-) [1] https://review.openstack.org/#/c/90729/ [2] https://review.openstack.org/#/c/91532/ [3] https://review.openstack.org/#/c/62599/ [4] https://review.openstack.org/#/c/93128/ Thanks Sridar From: Aaron Rosen aaronoro...@gmail.commailto:aaronoro...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 13, 2014 at 3:56 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree Hi, I've been thinking a good bit on this on the right way to move forward with this and in general the right way new services should be added. Yesterday I was working on a bug that was causing some problems in the openstack infra. We tracked down the issue then I uploaded a patch for it. A little while later after jenkins voted back a -1 so I started looking through the logs to see what the source of the failure was (which was actually unrelated to my patch). The random failure in the fwaas/vpn/l3-agent code which all outputs to the same log file that contains many traces for every run even successful ones. In one skim of this log file I was able to spot 4 [1]bugs which shows these new experimental services that we've added to neutron have underlying problems (even though they've been in the tree for 2 releases+ now). This puts a huge strain on the whole openstack development community as they are always recheck no bug'ing due to neutron failures. If you look at the fwaas work that was done. This merged over two releases ago and still does not have a complete API as there is no concept of where enforcement should be done. Today, enforcement is done across all of a tenant's routers making it more or less useless imho and we're just carrying it along in the tree
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][rally] nova-network, unable to associate floating ip
Hello,
Recently we use rally to test our cloud. We run boot-run-commnd-delete
task. The configuration is this:
{
VMTasks.boot_runcommand_delete: [
{
args: {
flavor: {
name: m1.small
},
image: {
name: ubuntu-12-04-raw-rally-test
},
script: /home/rally/doc/samples/ec_script/ubuntu_ls_test.sh,
interpreter: bash,
username: root,
floating_network: LTQ,
use_floatingip: true,
availability_zone: dell420
},
runner: {
type: constant,
times: 1000,
concurrency: 40,
timeout: 6000
},
context: {
users: {
tenants: 1,
users_per_tenant: 1
},
quotas: {
nova: {
instances: -1,
cores: -1,
ram: -1,
fixed_ips: -1,
floating_ips: -1,
}
},
}
}
]
}
There are almose 39 Exceptions for unable to associate floating ips.
The output of rally is
Traceback (most recent call last):\n File
\/opt/rally/local/lib/python2.7/site-packages/rally/benchmark/runners/base.py\,
line 62, in _run_scenario_once\nmethod_name)(**kwargs) or {}\n File
\/opt/rally/local/lib/python2.7/site-packages/rally/benchmark/scenarios/vm/vmtasks.py\,
line 80, in boot_runcommand_delete\nself._associate_floating_ip(server,
floating_ip)\n File
\/opt/rally/local/lib/python2.7/site-packages/rally/benchmark/scenarios/utils.py\,
line 139, in func_atomic_actions\nf = func(self, *args, **kwargs)\n File
\/opt/rally/local/lib/python2.7/site-packages/rally/benchmark/scenarios/nova/utils.py\,
line 402, in _associate_floating_ip\nserver.add_floating_ip(address,
fixed_address=fixed_address)\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/v1_1/servers.py\,
line 123, in add_floating_ip\nself.manager.add_floating_ip(self, address,
fixed_address)\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/v1_1/servers.py\,
line 631, in add_floating_ip\nself._action('addFloatingIp', server,
{'address': address})\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/v1_1/servers.py\,
line 1190, in _action\nreturn self.api.client.post(url, body=body)\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/client.py\, line
485, in post\nreturn self._cs_request(url, 'POST', **kwargs)\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/client.py\, line
459, in _cs_request\n**kwargs)\n File
\/opt/rally/local/lib/python2.7/site-packages/novaclient/client.py\, line
441, in _time_request\nresp, body = self.request(url, method, **kwargs)\n
File \/opt/rally/local/lib/python2.7/site-packages/novaclient/client.py\,
line 435, in request\nraise exceptions.from_response(resp, body, url,
method)\nBadRequest: Error. Unable to associate floating ip (HTTP 400)
(Request-ID: req-7b85f1cb-664d-4c98-b140-66f8b8d2ebe4)\n
I do not why associatiting floating ip is failed. I see in /var/log/sys.log
found this:
Aug 14 16:13:26 compute-node10 dnsmasq[21117]: failed to load names from
/var/lib/nova/networks/nova-br100.hosts: No such file or directory
Aug 14 16:13:26 compute-node10 dnsmasq-dhcp[21117]: read
/var/lib/nova/networks/nova-br100.conf
Aug 14 16:13:26 compute-node10 ceph-mon: 2014-08-14 16:13:26.952565
7f7b2d65a700 1 mon.compute-node10@5(peon).paxos(paxos active c
4947462..4947989) is_readable now=2014-08-14 16:13:26.952569
lease_expire=2014-08-14 16:13:31.935450 has v0 lc 4947989
Aug 14 16:13:27 compute-node10 ceph-mon: 2014-08-14 16:13:27.425576
7f7b2d65a700 1 mon.compute-node10@5(peon).paxos(paxos active c
4947462..4947990) is_readable now=2014-08-14 16:13:27.425578
lease_expire=2014-08-14 16:13:32.408369 has v0 lc 4947990
Aug 14 16:13:28 compute-node10 ceph-mon: 2014-08-14 16:13:28.368894
7f7b2d65a700 1 mon.compute-node10@5(peon).paxos(paxos active c
4947462..4947991) is_readable now=2014-08-14 16:13:28.368895
lease_expire=2014-08-14 16:13:33.350551 has v0 lc 4947991
Aug 14 16:13:28 compute-node10 ceph-mon: 2014-08-14 16:13:28.504170
7f7b2d65a700 1 mon.compute-node10@5(peon).paxos(paxos active c
4947462..4947992) is_readable now=2014-08-14 16:13:28.504171
lease_expire=2014-08-14 16:13:33.486123 has v0 lc 4947992
Aug 14 16:13:29 compute-node10 ceph-mon: 2014-08-14 16:13:29.593776
7f7b2d65a700 1 mon.compute-node10@5(peon).paxos(paxos active c
4947462..4947993) is_readable now=2014-08-14 16:13:29.593777
lease_expire=2014-08-14 16:13:34.575913 has v0 lc 4947993
Although sys.log says that no address available,
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I explain in the rest of my email below I'm not advocating getting rid of mid-cycle events entirely. I'm suggesting that we can attain a reasonable % of the benefits of f2f meetings by doing more formal virtual meetups and so be
Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit
On Wed, Aug 13, 2014 at 12:05:27PM -0700, James E. Blair wrote: cor...@inaugust.com (James E. Blair) writes: Sean Dague s...@dague.net writes: This has all gone far enough that someone actually wrote a Grease Monkey script to purge all the 3rd Party CI content out of Jenkins UI. People are writing mail filters to dump all the notifications. Dan Berange filters all them out of his gerrit query tools. I should also mention that there is a pending change to do something similar via site-local Javascript in our Gerrit: https://review.openstack.org/#/c/95743/ I don't think it's an ideal long-term solution, but if it works, we may have some immediate relief without all having to install greasemonkey scripts. You may have noticed that this has merged, along with a further change that shows the latest results in a table format. (You may need to force-reload in your browser to see the change.) Thanks again to Radoslav Gerganov for writing the original change. These are both a great step forward in usability of the Gerrit web UI. Thanks for the effort everyone put into these changes. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Retrospective veto revert policy
On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote: Hey (Terrible name for a policy, I know) From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're expecting the procedure to be: https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy If it sounds reasonably sane, I can propose its addition to the Development policies doc. (In the spirit of we really need to step back and laugh at ourselves sometimes ... ) Two years ago, we were worried about patches getting merged in less than 2 hours and had a discussion about imposing a minimum review time. How times have changed! Is it even possible to land a patch in less than two hours now? :) Looking back over the thread, this part stopped me in my tracks: https://lists.launchpad.net/openstack/msg08625.html On Tue, Mar 13, 2012, Mark McLoughlin markmc@xx wrote: Sometimes there can be a few folks working through an issue together and the patch gets pushed and approved so quickly that no-one else gets a chance to review. Everyone has an opportunity to review even after a patch gets merged. JE It's not quite perfect, but if you squint you could conclude that Johannes and I have both completely reversed our opinions in the intervening two years :) The lesson I take from that is to not get too caught up in the current moment. We're growing and evolving rapidly. If we assume everyone is acting in good faith, and allow each other to debate earnestly without feelings getting hurt ... we should be able to work through anything. Now, back on topic - digging through that thread, it doesn't seem we settled on the idea of we can just revert it later if someone has an objection in this thread. Does anyone recall when that idea first came up? Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Retrospective veto revert policy
On Thu, Aug 14, 2014 at 10:06:13AM +0100, Mark McLoughlin wrote: On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote: Hey (Terrible name for a policy, I know) From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're expecting the procedure to be: https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy If it sounds reasonably sane, I can propose its addition to the Development policies doc. (In the spirit of we really need to step back and laugh at ourselves sometimes ... ) Two years ago, we were worried about patches getting merged in less than 2 hours and had a discussion about imposing a minimum review time. How times have changed! Is it even possible to land a patch in less than two hours now? :) Looking back over the thread, this part stopped me in my tracks: https://lists.launchpad.net/openstack/msg08625.html On Tue, Mar 13, 2012, Mark McLoughlin markmc@xx wrote: Sometimes there can be a few folks working through an issue together and the patch gets pushed and approved so quickly that no-one else gets a chance to review. Everyone has an opportunity to review even after a patch gets merged. JE It's not quite perfect, but if you squint you could conclude that Johannes and I have both completely reversed our opinions in the intervening two years :) The lesson I take from that is to not get too caught up in the current moment. We're growing and evolving rapidly. If we assume everyone is acting in good faith, and allow each other to debate earnestly without feelings getting hurt ... we should be able to work through anything. Now, back on topic - digging through that thread, it doesn't seem we settled on the idea of we can just revert it later if someone has an objection in this thread. Does anyone recall when that idea first came up? Probably lost in time - I've seen it said several times on Nova IRC channel over the year(s) when we made a strategic decision to merge something quickly. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Is network ordering of vNICs guaranteed?
Most guests generate this on first boot. I haven't looked into how newer versions of ubuntu handle this though I noticed in 14.04 this file doesn't exist anymore but I figure it's doing it somewhere else. Aaron On Wed, Aug 13, 2014 at 9:03 PM, Jian Wen wenjia...@gmail.com wrote: Ordering of vNICs is not 100% guaranteed for the cloud images which are not shipped with /etc/udev/rules.d/70-persistent-net.rules. e.g. attaching a port and deattaching another port, then reboot the instance. 2014-08-12 15:52 GMT+08:00 Aaron Rosen aaronoro...@gmail.com: This bug was true in grizzly and older (and was reintroduced in icehouse for a few days but was fixed before the nova icehouse shipped). Aaron On Mon, Aug 11, 2014 at 7:10 AM, CARVER, PAUL pc2...@att.com wrote: Armando M. [mailto:arma...@gmail.com] wrote: On 9 August 2014 10:16, Jay Pipes jaypi...@gmail.com wrote: Paul, does this friend of a friend have a reproduceable test script for this? We would also need to know the OpenStack release where this issue manifest itself. A number of bugs have been raised in the past around this type of issue, and the last fix I recall is this one: https://bugs.launchpad.net/nova/+bug/1300325 It's possible that this might have regressed, though. The reason I called it friend of a friend is because I think the info has filtered through a series of people and is not firsthand observation. I'll ask them to track back to who actually observed the behavior, how long ago, and with what version. It could be a regression, or it could just be old info that people have continued to assume is true without realizing it was considered a bug all along and has been fixed. Thanks! The moment I first heard it my first reaction was that it was almost certainly a bug and had probably already been fixed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best, Jian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] [Cinder] 3'rd party CI systems
Well, I could make it test every patchset, but then I have to look into how to limit at one build per time + queue the other builds. (didn't try that yet) Anyways, I just got my new CI machine so I'll be able to finalize the CI system relatively soon. 2014-08-14 1:01 GMT+02:00 Jeremy Stanley fu...@yuggoth.org: On 2014-08-13 16:30:23 + (+), Asselin, Ramy wrote: I remember infra team objected to the nightly builds. They wanted reports on every patch set in order to report to gerrit. [...] I can't imagine, nor do I recall, objecting to such an idea. The question is merely where you expect to publish the results, and how you deal with the fact that you're testing changes which have already merged rather than getting in front of the reviewers on proposed changes. I don't personally have any specific desire for third-party CI systems to report on changes in Gerrit, but individual projects supporting your drivers/features/whatever might. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- David Pineau, Developer RD at Scality ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. +1. It's better to move all MD for none built-in backend out of tree, maintaining these drivers shouldn't be the responsibility of community. Not only MD, but also plugin, agent should all obey this rule [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Which changes need accompanying bugs?
On 08/14/2014 11:37 AM, Ihar Hrachyshka wrote:
On 14/08/14 02:43, Angus Lees wrote:
On Wed, 13 Aug 2014 11:11:51 AM Kevin Benton wrote:
Is the pylint static analysis that caught that error prone to
false positives? If not, I agree that it would be really nice if
that were made part of the tox check so these don't have to be
fixed after the fact.
At the moment pylint on neutron is *very* noisy, and I've been
looking through the reported issues by hand to get a feel for
what's involved. Enabling pylint is a separate discussion that I'd
like to have - in some other thread.
Just start with non-voting check. Once all the issues are fixed, we
can enable it as voting.
Or blacklist all failures, make it voting - and then fix one issue after
the other - and with each patch, remove the blacklisted number.
That way no regressions come in...
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Congress] Help in understanding API Flow
Hi,
Can some one help me understand how an API is exposed to the clients from
Congress server ?
I see that a cage service ('api-policy') is created in congress_server.py.
I believe this is implemented in policy_model. I tried to send a
json_request from my client on the server.
I tried sending list_members, get_items, PUT and POST as methods
and all these give me NotImplemented error response.
Any help in this direction ?
I also want to add new APIs and hence understanding the API flow is crucial.
Thanks,
Madhu Mohan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)
Hi James, I have added the Nuage CI system to the list; I also took the liberty to reorder alphabetically the list Franck Franck On Wed, Aug 13, 2014 at 11:23 AM, James E. Blair cor...@inaugust.com wrote: Hi, We've updated the registration requirements for third-party CI systems here: http://ci.openstack.org/third_party.html We now have 86 third-party CI systems registered and have undertaken an effort to make things more user-friendly for the developers who interact with them. There are two important changes to be aware of: 1) We now generally name third-party systems in a descriptive manner including the company and product they are testing. We have renamed currently-operating CI systems to match these standards to the best of our abilities. Some of them ended up with particularly bad names (like Unknown Function...). If your system is one of these, please join us in #openstack-infra on Freenode to establish a more descriptive name. 2) We have established a standard wiki page template to supply a description of the system, what is tested, and contact information for each system. See https://wiki.openstack.org/wiki/ThirdPartySystems for an index of such pages and instructions for creating them. Each third-party CI system will have its own page in the wiki and it must include a link to that page in every comment that it leaves in Gerrit. If you operate a third-party CI system, please ensure that you register a wiki page and update your system to link to it in every new Gerrit comment by the end of August. Beginning in September, we will disable systems that have not been updated. Thanks, Jim ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] gate-ceilometer-python33 failed because of wrong setup.py in happybase
Hisashi Osanai, np :) You're welcome :) On Thu, Aug 14, 2014 at 5:13 AM, Osanai, Hisashi osanai.hisa...@jp.fujitsu.com wrote: On Wed, Aug 13, 2014 at 2:35 PM, Julien Danjou wrote: Means the py33 needs to execute on stable/icehouse. Here I misunderstand something... Not it does not, that line in tox.ini is not use by the gate. this is a problem in the infrastructure config. Means execfile function calls on python33 in happybase is a problem. If my understanding is correct, I agree with you and I think this is the direct cause of this problem. Your idea to solve this is creating a patch for the direct cause, right? My idea to solve this is to create a patch on http://git.openstack.org/cgit/openstack-infra/config/ to exclude py33 on the stable/icehouse branch of Ceilometer in the gate. Sorry to use your time for explanation above again and thanks for it. I'm happy to have clear understanding your thought. On Wednesday, August 13, 2014 7:54 PM, Dina Belova wrote: Here it is: https://review.openstack.org/#/c/113842/ Thank you for providing the fix. I surprised the speed for it. it's really fast... Thanks again! Hisashi Osanai -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
I think there will soon be a discussion regarding what the appropriate location for plugin and drivers should be. My personal feeling is that Neutron has simply reached the tipping point where the high number of drivers and plugins is causing unnecessary load for the core team and frustration for the community. There I would totally support Luke's initiative about maintaining an out-of-tree ML2 driver. On the other hand, a plugin/driver diaspora might also have negative consequences such as frequent breakages such as those Bob was mentioning or confusion for users which might need to end up fetching drivers from disparate sources. As mentioned during the last Neutron IRC meeting this is another process aspect which will be discussed soon, with the aim of defining a plan for: - drastically reduce the number of plugins and drivers which must be maintained in the main source tree - enhance control of plugin/driver maintainers over their own code - preserve the ability of doing CI checks on gerrit as we do today - raise the CI bar (maybe finally set the smoketest as a minimum requirement?) Regards, Salvatore On 14 August 2014 11:47, loy wolfe loywo...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. +1. It's better to move all MD for none built-in backend out of tree, maintaining these drivers shouldn't be the responsibility of community. Not only MD, but also plugin, agent should all obey this rule [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Retrospective veto revert policy
On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote: Hey (Terrible name for a policy, I know) From the version_cap saga here: https://review.openstack.org/110754 I think we need a better understanding of how to approach situations like this. Here's my attempt at documenting what I think we're expecting the procedure to be: https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy If it sounds reasonably sane, I can propose its addition to the Development policies doc. Proposed here: https://review.openstack.org/114188 Thanks, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)
Hi Franck - Thanks for the update. I too have that re-order in mind. :) Here after CI owners may add their CI names in appropriate alphabetical order. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: Franck Yelles [mailto:franck...@gmail.com] Sent: Thursday, August 14, 2014 3:33 PM To: James E. Blair Cc: OpenStack Development Mailing List (not for usage questions); openstack-in...@lists.openstack.org Subject: Re: [OpenStack-Infra] [infra] Third Party CI naming and contact (action required) Hi James, I have added the Nuage CI system to the list; I also took the liberty to reorder alphabetically the list Franck Franck On Wed, Aug 13, 2014 at 11:23 AM, James E. Blair cor...@inaugust.com wrote: Hi, We've updated the registration requirements for third-party CI systems here: http://ci.openstack.org/third_party.html We now have 86 third-party CI systems registered and have undertaken an effort to make things more user-friendly for the developers who interact with them. There are two important changes to be aware of: 1) We now generally name third-party systems in a descriptive manner including the company and product they are testing. We have renamed currently-operating CI systems to match these standards to the best of our abilities. Some of them ended up with particularly bad names (like Unknown Function...). If your system is one of these, please join us in #openstack-infra on Freenode to establish a more descriptive name. 2) We have established a standard wiki page template to supply a description of the system, what is tested, and contact information for each system. See https://wiki.openstack.org/wiki/ThirdPartySystems for an index of such pages and instructions for creating them. Each third-party CI system will have its own page in the wiki and it must include a link to that page in every comment that it leaves in Gerrit. If you operate a third-party CI system, please ensure that you register a wiki page and update your system to link to it in every new Gerrit comment by the end of August. Beginning in September, we will disable systems that have not been updated. Thanks, Jim ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Annoucing CloudKitty : an OpenSource Rating-as-a-Service project for OpenStack
Glad to see there is another group interested in rating/billing. I'm thinking if I should announce our rating service to join the fun :-) You know, I'm kidding. The more groups join the rating service discussion, the better. But IMHO, we just need one rating service for OpenStack. So let's collaborate to work out a good rating service to benefit OpenStack and consumer. But before more duplicate work, it would be great if we can start some discussion. Cheers. On 14/08/14 01:40, Christophe Sauthier wrote: We are very pleased at Objectif Libre to intoduce CloudKitty, an effort to provide a fully OpenSource Rating-as-a-Service comptinent in OpenStack.. Following a first POC presented during the last summit in Atlanta to some Ceilometer devs (thanks again Julien Danjou for your great support !), we continued our effort to create a real service for rating. Today we are happy to share it with you all. So what do we propose in CloudKitty? - a service for collecting metrics (using Ceilometer API) - a modular rating architecture to enable/disable modules and create your own rules on-the-fly, allowing you to use the rating patterns you like - an API to interact with the whole environment from core components to every rating module - a Horizon integration to allow configuration of the rating modules and display of pricing information in real time during instance creation - a CLI client to access this information and easily configure everything Technically we are using all the elements that are used in the various OpenStack projects like olso, stevedore, pecan... CloudKitty is highly modular and allows integration / developement of third party collection and rating modules and output formats. A roadmap is available on the project wiki page (the link is at the end of this email), but we are clearly hoping to have some feedback and ideas on how to improve the project and reach a tighter integration with OpenStack. The project source code is available at http://github.com/stackforge/cloudkitty More stuff will be available on stackforge as soon as the reviews get validated like python-cloudkittyclient and cloudkitty-dashboard, so stay tuned. The project's wiki page (https://wiki.openstack.org/wiki/CloudKitty) provides more information, and you can reach us via irc on freenode: #cloudkitty. Developper's documentation is on its way to readthedocs too. We plan to present CloudKitty in detail during the Paris Summit, but we would love to hear from you sooner... Cheers, Christophe and Objectif Libre Christophe Sauthier Mail : christophe.sauth...@objectif-libre.com CEO Fondateur Mob : +33 (0) 6 16 98 63 96 Objectif LibreURL : www.objectif-libre.com Infrastructure et Formations LinuxTwitter : @objectiflibre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [vmware] Canonical list of os types
I've just spent the best part of a day tracking down why instance creation was failing on a particular setup. The error message from CreateVM_Task was: 'A specified parameter was not correct'. After discounting a great many possibilities, I finally discovered that the problem was guestId, which was being set to 'CirrosGuest'. Unusually, the vSphere API docs don't contain a list of valid values for that field. Given the unhelpfulness of the error message, it might be worthwhile validating that field (which we get from glance) and displaying an appropriate warning. Does anybody have a canonical list of valid values? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
With further debugging, i find that none of the configuration options present in /etc/cinder/cinder.conf are getting applied. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 11:40 AM, Amit Das amit@cloudbyte.com wrote: Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually *(not sure if this section needs to be commented)* http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [vmware] Canonical list of os types
- Original Message - From: Matthew Booth mbo...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org I've just spent the best part of a day tracking down why instance creation was failing on a particular setup. The error message from CreateVM_Task was: 'A specified parameter was not correct'. After discounting a great many possibilities, I finally discovered that the problem was guestId, which was being set to 'CirrosGuest'. Unusually, the vSphere API docs don't contain a list of valid values for that field. Given the unhelpfulness of the error message, it might be worthwhile validating that field (which we get from glance) and displaying an appropriate warning. Does anybody have a canonical list of valid values? Thanks, Matt I found a page [1] linked from the Grizzly edition of the compute guide [2] which has since been superseded. The content that would appear to have replaced it in more recent versions of the documentation suite [3] does not appear to contain such a link though. If a link to a more formal list is available it would be great to get this in the documentation. Thanks, Steve [1] http://www.thinkvirt.com/?q=node/181 [2] http://docs.openstack.org/grizzly/openstack-compute/admin/content/image-metadata.html [3] http://docs.openstack.org/icehouse/config-reference/content/vmware.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 FYI: I've uploaded a review for openstack/requirements to add the upstream module into the list of potential dependencies [1]. Once it's merged, I'm going to introduce this new requirement for Neutron. [1]: https://review.openstack.org/114213 /Ihar On 12/08/14 16:27, Ihar Hrachyshka wrote: Hey all, as per [1], Cisco Nexus ML2 plugin requires a patched version of ncclient from github. I wonder: - whether this information is still current; - why don't we depend on ncclient thru our requirements.txt file. [1]: https://wiki.openstack.org/wiki/Neutron/ML2/MechCiscoNexus Cheers, /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT7KO6AAoJEC5aWaUY1u57ft0IAJzPC2o8fz9mwlC47tXGeHpJ uP5HFIMaJaPXIwDnuz2uz8dJQZzBvTo6WrN+SRPb6PL3aGbIW4y2BA4n6NM276Xx PwL8cnBdjQ9INwxn3g9jBceynbm2Yxx3I//2AIT1iu1Io/qjHppkUePxgH33PVMn jw/n00mnCVJgxpHNXuFoe7Mn8UsduhB7xNCnW90t4rc9cfClGhW1T6/Pw2PWc07p 3Kw4OmmTS7q6r89iAmkBgbgdI2WBjdR902gwGxnuwmf7TJLo5Nd+jnvbe4bJ7V1d DHzcFPNffKS2Fjbbxay0GjN+7/dAKHVRqkGQZvGzzEL8ZvqZGzyFojZ9BlnrM4Q= =BZEc -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 07:27 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 01:09 PM, Dan Smith wrote: Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. I am a bit confused by this stance to be honest. You yourself said when you were Icehouse PTL that you wanted cores to come to the summit. What changed? Yes, I would love for core team members to come to the design summit that's twice a year. I still don't *expect* it for them to remain a member of the team, and I certainly don't expect it 4 times a year. It's a matter of frequency and requirement. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 11:31 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I'm not sure that's much different in reality. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. Yes, IRC is one option which we already use on a regular basis. We can also switch to voice communication for higher bandwidth when needed. We even have a conferencing server set up in OpenStack's infrastructure: https://wiki.openstack.org/wiki/Infrastructure/Conferencing In theory it even supports basic video conferencing, though I haven't tested it on this server yet. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 07:27 PM, Michael Still wrote: The etherpad for the meetup has extensive notes. Any summary I write will basically be those notes in prose. What are you looking for in a summary that isn't in the etherpad? There also wasn't a summary of the Icehouse midcycle produced that I can find. Whilst I am happy to do one for Juno, its a requirement that I hadn't planned for, and is therefore taking me some time to retrofit. I think we should chalk the request for summaries up experience and talk through how to better provide such things at future meetups. The summary from the Icehouse meetup is here: http://lists.openstack.org/pipermail/openstack-dev/2014-February/027370.html -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Docker] Run OpenStack Service in Docker Container
I see a few mentions of OpenStack services themselves being containerized in Docker. Is this a serious trend in the community? http://allthingsopen.com/2014/02/12/why-containers-for-openstack-services/ -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Annoucing CloudKitty : an OpenSource Rating-as-a-Service project for OpenStack
Sounds very interesting. We're currently collecting detailed (and verified) usage information in StackTach and are keen to see what CloudKitty is able to offer. My one wish is that you keep the components as small pip redistributables with low coupling to promote reuse with other projects. Many tiny repos and clear API's (internal and external) are good for adoption and contribution. All the best! -Sandy From: Christophe Sauthier [christophe.sauth...@objectif-libre.com] Sent: Wednesday, August 13, 2014 10:40 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Annoucing CloudKitty : an OpenSource Rating-as-a-Service project for OpenStack We are very pleased at Objectif Libre to intoduce CloudKitty, an effort to provide a fully OpenSource Rating-as-a-Service component in OpenStack.. Following a first POC presented during the last summit in Atlanta to some Ceilometer devs (thanks again Julien Danjou for your great support !), we continued our effort to create a real service for rating. Today we are happy to share it with you all. So what do we propose in CloudKitty? - a service for collecting metrics (using Ceilometer API) - a modular rating architecture to enable/disable modules and create your own rules on-the-fly, allowing you to use the rating patterns you like - an API to interact with the whole environment from core components to every rating module - a Horizon integration to allow configuration of the rating modules and display of pricing information in real time during instance creation - a CLI client to access this information and easily configure everything Technically we are using all the elements that are used in the various OpenStack projects like olso, stevedore, pecan... CloudKitty is highly modular and allows integration / developement of third party collection and rating modules and output formats. A roadmap is available on the project wiki page (the link is at the end of this email), but we are clearly hoping to have some feedback and ideas on how to improve the project and reach a tighter integration with OpenStack. The project source code is available at http://github.com/stackforge/cloudkitty More stuff will be available on stackforge as soon as the reviews get validated like python-cloudkittyclient and cloudkitty-dashboard, so stay tuned. The project's wiki page (https://wiki.openstack.org/wiki/CloudKitty) provides more information, and you can reach us via irc on freenode: #cloudkitty. Developper's documentation is on its way to readthedocs too. We plan to present CloudKitty in detail during the Paris Summit, but we would love to hear from you sooner... Cheers, Christophe and Objectif Libre Christophe Sauthier Mail : christophe.sauth...@objectif-libre.com CEO Fondateur Mob : +33 (0) 6 16 98 63 96 Objectif LibreURL : www.objectif-libre.com Infrastructure et Formations LinuxTwitter : @objectiflibre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
I also feel like the drivers/plugins are currently BEYOND a tipping point, and are in fact dragging down velocity of the core project in many ways. I'm working on a proposal for Kilo where we move all drivers/plugins out of the main Neutron tree and into a separate git repository under the networking program. We have way too many drivers, requiring way too man review cycles, for this to be a sustainable model going forward. Since the main reason plugin/driver authors want their code upstream is to be a part of the simultaneous release, and thus be packaged by distributions, having a separate repository for these will satisfy this requirement. I'm still working through the details around reviews of this repository, etc. Also, I feel as if the level of passion on the mailing list has died down a bit, so I thought I'd send something out to try and liven things up a bit. It's been somewhat non-emotional here for a day or so. :) Thanks, Kyle On Thu, Aug 14, 2014 at 5:09 AM, Salvatore Orlando sorla...@nicira.com wrote: I think there will soon be a discussion regarding what the appropriate location for plugin and drivers should be. My personal feeling is that Neutron has simply reached the tipping point where the high number of drivers and plugins is causing unnecessary load for the core team and frustration for the community. There I would totally support Luke's initiative about maintaining an out-of-tree ML2 driver. On the other hand, a plugin/driver diaspora might also have negative consequences such as frequent breakages such as those Bob was mentioning or confusion for users which might need to end up fetching drivers from disparate sources. As mentioned during the last Neutron IRC meeting this is another process aspect which will be discussed soon, with the aim of defining a plan for: - drastically reduce the number of plugins and drivers which must be maintained in the main source tree - enhance control of plugin/driver maintainers over their own code - preserve the ability of doing CI checks on gerrit as we do today - raise the CI bar (maybe finally set the smoketest as a minimum requirement?) Regards, Salvatore On 14 August 2014 11:47, loy wolfe loywo...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. +1. It's better to move all MD for none built-in backend out of tree, maintaining these drivers shouldn't be the responsibility of community. Not only MD, but also plugin, agent should all obey this rule [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 08:31:48AM -0400, Russell Bryant wrote: On 08/13/2014 11:31 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I'm not sure that's much different in reality. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. Yes, IRC is one option which we already use on a regular basis. We can also switch to voice communication for higher bandwidth when needed. We even have a conferencing server set up in OpenStack's infrastructure: https://wiki.openstack.org/wiki/Infrastructure/Conferencing In theory it even supports basic video conferencing, though I haven't tested it on this server yet. Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. It could be useful in cases where one (or a handful) of people want to present an idea / topic visually with slides / screencasts / etc and then let the broader interactive discussion take place on IRC / mailing list afterwards. I could see this being something that might let people present proposals for new Nova features without having to wait (+try for a limited) design summit slot in the 6 month cycle. One of the issues I feel with the design summit is that it was the first time hearing about many of the ideas, so there was not enough time to disgest the proposal and so some of the thorny things to discuss only come to mind afterwards. If we had to a approach for promoting features knowledge in this way the design summit could have more time to focus on areas of debate where the f2f prescence is most valuable. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
On Aug 14, 2014 2:04 AM, Eoghan Glynn egl...@redhat.com wrote: Letting the industry field-test a project and feed their experience back into the community is a slow process, but that is the best measure of a project's success. I seem to recall this being an implicit expectation a few years ago, but haven't seen it discussed in a while. I think I recall us discussing a must have feedback that it's successfully deployed requirement in the last cycle, but we recognized that deployers often wait until a project is integrated. In the early discussions about incubation, we respected the need to officially recognize a project as part of OpenStack just to create the uptick in adoption necessary to mature projects. Similarly, integration is a recognition of the maturity of a project, but I think we have graduated several projects long before they actually reached that level of maturity. Actually running a project at scale for a period of time is the only way to know it is mature enough to run it in production at scale. I'm just going to toss this out there. What if we set the graduation bar to is in production in at least two sizeable clouds (note that I'm not saying public clouds). Trove is the only project that has, to my knowledge, met that bar prior to graduation, and it's the only project that graduated since Havana that I can, off hand, point at as clearly successful. Heat and Ceilometer both graduated prior to being in production; a few cycles later, they're still having adoption problems and looking at large architectural changes. I think the added cost to OpenStack when we integrate immature or unstable projects is significant enough at this point to justify a more defensive posture. FWIW, Ironic currently doesn't meet that bar either - it's in production in only one public cloud. I'm not aware of large private installations yet, though I suspect there are some large private deployments being spun up right now, planning to hit production with the Juno release. We have some hard data from the user survey presented at the Juno summit, with respectively 26 53 production deployments of Heat and Ceilometer reported. There's no cross-referencing of deployment size with services in production in those data presented, though it may be possible to mine that out of the raw survey responses. Indeed, and while that would be useful information, I was referring to the deployment of those services at scale prior to graduation, not post graduation. Best, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][DevStack] How to increase developer usage of Neutron
I'll bet I am not the only developer who is not highly competent with bridges and tunnels, Open VSwitch, Neutron configuration, and how DevStack transmutes all those. My bet is that you would have more developers using Neutron if there were an easy-to-find and easy-to-follow recipe to use, to create a developer install of OpenStack with Neutron. One that's a pretty basic and easy case. Let's say a developer gets a recent image of Ubuntu 14.04 from Canonical, and creates an instance in some undercloud, and that instance has just one NIC, at 10.9.8.7/16. If there were a recipe for such a developer to follow from that point on, it would be great. Regards, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
You either need to comment out the enabled_backends line, or you'll want to put something similar to this in your cinder.conf file: [DEFAULT] ... enabled_backends = cloudbyte ... [cloudbyte] volume_driver = volume_driver = cinder.volume.drivers.cloudbyte.cloudbyte.ElasticenterISCSIDriver SAN_IP=20.10.22.245 CB_APIKEY=masQwghrmPOVIqbjyyWKQdg4z4bP2sNZ13fRQyUMwm453PUiYB-xyRSMBDoZeMj6R 0-XU9DCscxMbe3AhleDyQ CB_ACCOUNT_NAME=acc1 TSM_NAME=openstacktsm If you have enabled_backends set then it will only use those driver specs and ignore all driver related details in the DEFAULT section. You also probably want to comment (or remove) the default_volume_type line, unless you plan to create that volume type after the services come up. Andrew Kerr OpenStack QA Cloud Solutions Group NetApp From: Amit Das amit@cloudbyte.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, August 14, 2014 at 5:37 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default With further debugging, i find that none of the configuration options present in /etc/cinder/cinder.conf are getting applied. Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 11:40 AM, Amit Das amit@cloudbyte.com wrote: Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually (not sure if this section needs to be commented) http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][DevStack] How to increase developer usage of Neutron
Mike Spreitzer [mailto:mspre...@us.ibm.com] wrote: I'll bet I am not the only developer who is not highly competent with bridges and tunnels, Open VSwitch, Neutron configuration, and how DevStack transmutes all those. My bet is that you would have more developers using Neutron if there were an easy-to-find and easy-to-follow recipe to use, to create a developer install of OpenStack with Neutron. One that's a pretty basic and easy case. Let's say a developer gets a recent image of Ubuntu 14.04 from Canonical, and creates an instance in some undercloud, and that instance has just one NIC, at 10.9.8.7/16. If there were a recipe for such a developer to follow from that point on, it would be great. https://wiki.openstack.org/wiki/NeutronDevstack worked for me. However, I'm pretty sure it's only a single node all in one setup. At least, I created only one VM to run it on and I don't think DevStack has created multiple nested VMs inside of the one I create to run DevStack. I haven't gotten around to figuring out how to setup a full multi-node DevStack setup with separate compute nodes and network nodes and GRE/VXLAN tunnels. There are multi-node instructions on that wiki page but I haven't tried following them. If someone has a Vagrant file that creates a full multi- node Neutron devstack complete with GRE/VXLAN tunnels it would be great if they could add it to that wiki page. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] requirements.txt: explicit vs. implicit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, some plugins depend on modules that are not mentioned in requirements.txt. Among them, Cisco Nexus (ncclient), Brocade (ncclient), Embrane (heleosapi)... Some other plugins put their dependencies in requirements.txt though (like Arista depending on jsonrpclib). There are pros and cons in both cases. The obvious issue with not putting those requirements in the file is that packagers are left uninformed about those implicit requirements existing, meaning plugins are shipped to users with broken dependencies. It also means we ship code that depends on unknown modules grabbed from random places in the internet instead of relying on what's available on pypi, which is a bit scary. With my packager hat on, I would like to suggest to make those dependencies explicit by filling in requirements.txt. This will make packaging a bit easier. Of course, runtime dependencies being set correctly do not mean plugins are working and tested, but at least we give them chance to be tested and used. But, maybe there are valid concerns against doing so. In that case, I would be glad to know how packagers are expected to track those implicit dependencies. I would like to ask community to decide what's the right way to handle those cases. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJT7Lu2AAoJEC5aWaUY1u57tDkIAOrx1TWVjke8xxsJtz+tizmg rDgoQyugU8bmaWUFzKi3yVLDFmkOH5iX9RFqj6pgXngydd+cO0Z8CB825uT7kimi tTwTk2o1Ty4lIG38nwi/U8pn+nmzVApjOqtJmBmtZKBtoY7hRUs+QVTz5V5M1AmA MQm0eYZXMQ531k4UTdaFxtZ2xPvnCEsFTWi0vosZLPvccVw33vUnQ0SnewQAgb4w NZ7m302454S2INegqVYlZqQMQXxy6v/BAigyoLXBj8Pl3FsrNU0j3SMtzqSm71ty GCz0qdWckUdgsDFnLyyNXjUV/G9xZ03pYZ5ID2WiVQl5MYbmkAHlJJkjCYIrv3c= =tLTZ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] heat docker multi host scheduling support
On 14/08/14 03:21, Malawade, Abhijeet wrote: Hi all, I am trying to use heat to create docker containers. I have configured heat-docker plugin. I am also able to create stack using heat successfully. To start container on different host we need to provide 'docker_endpoint' in template. For this we have to provide host address where container will run in template. Is there any way to schedule docker container on available hosts using heat-docker plugin without giving 'docker_endpoint' in template file. Yes, there is a Nova driver on Stackforge that uses Docker as a back-end. Hopefully one day this will turn into a Nova-like container service, but for now the way to use Docker as a scheduler is through Nova with this driver. Is heat-docker plugin supports managing docker hosts cluster with scheduling logic. No. Please let me know your suggestions on the same. Thanks, Abhijeet ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
Thanks a lot. This worked out like a charm. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 7:02 PM, Kerr, Andrew andrew.k...@netapp.com wrote: You either need to comment out the enabled_backends line, or you'll want to put something similar to this in your cinder.conf file: [DEFAULT] ... enabled_backends = cloudbyte ... [cloudbyte] volume_driver = volume_driver = cinder.volume.drivers.cloudbyte.cloudbyte.ElasticenterISCSIDriver SAN_IP=20.10.22.245 CB_APIKEY=masQwghrmPOVIqbjyyWKQdg4z4bP2sNZ13fRQyUMwm453PUiYB-xyRSMBDoZeMj6R 0-XU9DCscxMbe3AhleDyQ CB_ACCOUNT_NAME=acc1 TSM_NAME=openstacktsm If you have enabled_backends set then it will only use those driver specs and ignore all driver related details in the DEFAULT section. You also probably want to comment (or remove) the default_volume_type line, unless you plan to create that volume type after the services come up. Andrew Kerr OpenStack QA Cloud Solutions Group NetApp From: Amit Das amit@cloudbyte.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, August 14, 2014 at 5:37 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default With further debugging, i find that none of the configuration options present in /etc/cinder/cinder.conf are getting applied. Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 11:40 AM, Amit Das amit@cloudbyte.com wrote: Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually (not sure if this section needs to be commented) http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
+1 On 14 August 2014 00:55, Boring, Walter walter.bor...@hp.com wrote: Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. Walt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 8/14/2014 3:47 AM, Daniel P. Berrange wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. Just speaking from experience, I attended the Icehouse meetup before my first summit (Juno in ATL) and the design summit sessions for Juno were a big disappointment after the meetup sessions, basically because of the time constraints. The meetups are nice since there
Re: [openstack-dev] use of compute node as a storage
You run cinder-volume on compute node which you want to convert to storage. Configure LVM driver of compute node as storage backend for cinder-volume. On Fri, Aug 8, 2014 at 1:54 PM, shailendra acharya acharyashailend...@gmail.com wrote: i made 4 vm 1 controller, 1 network and 2 compute and i want 1 compute to run as a storage so plz help how can i do such ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? http://www.google.com/+/learnmore/hangouts/onair.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? http://www.google.com/+/learnmore/hangouts/onair.html We've done Google Hangout OnAir for the docs team with varied success due to the oddities with calendaring and having to know everyone's preferred Google identity. It's nice for high-fidelity conversations without requiring travel. It also lets people tune in then or watch a recording later. Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] team meeting Aug 14 1800 UTC
Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20140814T18 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [third-party] What tests are required to be run
Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? This is a terrible idea, as it perpetuates the core vs. non-core argument. We need equal participation for cores and non-cores alike. http://www.google.com/+/learnmore/hangouts/onair.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
+1, Xing is very active in the community, provides valuable reviews and currently developing cinder core features. ~Kurt -Original Message- From: Boring, Walter Sent: Wednesday, August 13, 2014 11:56 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. Walt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Russell Bryant [mailto:rbry...@redhat.com] wrote: An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? In principle, yes, but that loses the immersive telepresence aspect which is the next best thing to an in-person meetup (which is where this thread started.) ATT Employees live and breathe on ATT Connect which is our teleconferencing (not telepresence) service. It supports webcam video as well as desktop sharing, but I'm on the verge of making a sales pitch here which was NOT my intent. I'm on ATT Connect meetings 5+ times a day but I'm biased so I won't offer any opinion on how it compares to WebEx, GotoMeeting, and other services. None of them are really equivalent to the purpose built telepresence rooms. My point was that there may well be a telepresence room within reasonable driving distance for a large number of OpenStack contributors if we were able to get a number of the large OpenStack participant companies to open their doors to an occasional meet-up. Instead of asking participants around the globe to converge on a single physical location for a meet-up, perhaps they could converge on the closest of 20 different locations that are linked via telepresence. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:31 AM, CARVER, PAUL pc2...@att.com wrote: Russell Bryant [mailto:rbry...@redhat.com] wrote: An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? In principle, yes, but that loses the immersive telepresence aspect which is the next best thing to an in-person meetup (which is where this thread started.) ATT Employees live and breathe on ATT Connect which is our teleconferencing (not telepresence) service. It supports webcam video as well as desktop sharing, but I'm on the verge of making a sales pitch here which was NOT my intent. I'm on ATT Connect meetings 5+ times a day but I'm biased so I won't offer any opinion on how it compares to WebEx, GotoMeeting, and other services. None of them are really equivalent to the purpose built telepresence rooms. My point was that there may well be a telepresence room within reasonable driving distance for a large number of OpenStack contributors if we were able to get a number of the large OpenStack participant companies to open their doors to an occasional meet-up. Instead of asking participants around the globe to converge on a single physical location for a meet-up, perhaps they could converge on the closest of 20 different locations that are linked via telepresence. If we could make this work, I'd be up for it. It's a great balance to the travel and face-to-face argument here. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 11:40 AM, David Kranz wrote: On 08/14/2014 10:54 AM, Matt Riedemann wrote: On 8/14/2014 3:47 AM, Daniel P. Berrange wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. Just speaking from experience, I attended the Icehouse meetup before my first summit (Juno in ATL) and the
Re: [openstack-dev] [all] The future of the integrated release
On Aug 13, 2014, at 5:07 AM, Daniel P. Berrange berra...@redhat.com wrote: On Wed, Aug 13, 2014 at 12:55:48PM +0100, Steven Hardy wrote: On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote: On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote: By ignoring stable branches, leaving it upto a small team to handle, I think we giving the wrong message about what our priorities as a team team are. I can't help thinking this filters through to impact the way people think about their work on master. Who is ignoring stable branches? This sounds like a project specific failing to me, as all experienced core reviewers should consider offering their services to help with stable-maint activity. I don't personally see any reason why the *entire* project core team has to do this, but a subset of them should feel compelled to participate in the stable-maint process, if they have sufficient time, interest and historical context, it's not some other team IMO. I think that stable branch review should be a key responsibility for anyone on the core team, not solely those few who volunteer for stable team. As the number of projects in openstack grows I think the idea of having a single stable team with rights to approve across any project is ultimately flawed because it doesn't scale efficiently and they don't have the same level of domain knowledge as the respective project teams. This side-thread is a bit off topic for the main discussion, but as a stable-maint with not a lot of time, I would love more help from the core teams here. That said, help is not just about aproving reviews. There are three main steps in the process: 1. Bugs get marked for backport I try to stay on top of this in nova by following the feed of merged patches and marking them icehouse-backport-potential[1] when they seem like they are appropriate but I’m sure I miss some. 2. Patches get backprorted This is sometimes a very time-consuming process, especially late in the cycle or for patches that are being backported 2 releases. 3. Patches get reviewed and merged The criteria for a stable backport are pretty straightforward and I think any core reviewer is capable of understanding and aply that criteria While we have fallen behind in number 3. at times, we are much more often WAY behind on 2. I also suspect that a whole bunch of patches get missed in some of the other projects where someone isn’t specifically trying to mark them all as they come in. Vish [1] https://bugs.launchpad.net/nova/+bugs?field.tag=icehouse-backport-potential signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
On 06:55 Thu 14 Aug , Boring, Walter wrote: Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. +1 If you take a look at the last 3 months [1][2] she has been very active and providing great feedback in reviews. She has also been setting great expectations for other drivers with the recent third-party CI work. Thanks Xing! [1] - http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt [2] - http://stackalytics.com/?user_id=xing-yang -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] requirements.txt: explicit vs. implicit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/14/2014 08:37 AM, Ihar Hrachyshka wrote: Hi all, some plugins depend on modules that are not mentioned in requirements.txt. Among them, Cisco Nexus (ncclient), Brocade (ncclient), Embrane (heleosapi)... Some other plugins put their dependencies in requirements.txt though (like Arista depending on jsonrpclib). There are pros and cons in both cases. The obvious issue with not putting those requirements in the file is that packagers are left uninformed about those implicit requirements existing, meaning plugins are shipped to users with broken dependencies. It also means we ship code that depends on unknown modules grabbed from random places in the internet instead of relying on what's available on pypi, which is a bit scary. With my packager hat on, I would like to suggest to make those dependencies explicit by filling in requirements.txt. This will make packaging a bit easier. Of course, runtime dependencies being set correctly do not mean plugins are working and tested, but at least we give them chance to be tested and used. But, maybe there are valid concerns against doing so. In that case, I would be glad to know how packagers are expected to track those implicit dependencies. I would like to ask community to decide what's the right way to handle those cases. So I raised a similar issue about six months ago and completely failed to follow up on the direction everyone seemed to be onboard with: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026976.html I did add support to pbr for using nested requirements files, and I had posted a PoC for oslo.messaging to allow requirements files for different backends, but some of our CI jobs don't know how to handle that and I never got around to addressing the limitation. - From the packaging perspective, I think you could do a requirements file that basically rolls up requirements.d/*.txt minus test.txt and get all the runtime dependencies that the project knows about, assuming we finished the implementation for this and started using it in projects. I don't really anticipate having time to pursue this in the near future, so if you wanted to pick up the ball and run with it that would be great! :-) - -Ben Cheers, /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT7OS8AAoJEDehGd0Fy7uqtqsH/0kcIB+Q9iA5vR5evC+PDsFb ek+cwvldbgpv0JwFwhgsLtsbRbI9xv1wDpu8L5i30yKzgcPQX5cqYe2WZeG5eCBJ HUHb3t86rCanBU+kp7hpjHSoQbdwhY9gtu1LwiVha/2IeOHchZBzJccxEcACsv0q Es8YkQy3qp9EfegumaL4OHvYFfB/j4NbewxZjAb3mkcpObb6NBM1v+qeubjTEg5I nY8lJMLBXJOLNrR5cg8G7sObh3Cow51GtjwFaiFuZi/9o6whQFXipKnwXkaSRR5U I3YV18sy3NLtoStZdr4/Oa9kUICw1MdDZAckoc5nP+AQeZCBFaPaCPpkLzIcMT8= =CdPl -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Way to get wrapped method's name/class using Pecan secure decorators?
Sure, Doug. We want the ability to selectively apply policies to certain
Ceilometer
API methods based on user/tenant roles.
For example, we want to restrict the ability to execute Alarm deletes to
admins and user/tenants who have a special role, say domainadmin.
The policy file might look like this:
{
context_is_admin: [[role:admin]],
admin_and_matching_project_domain_id: [[role:domainadmin]],
admin_or_cloud_admin: [[rule:context_is_admin],
[rule:admin_and_matching_project_domain_id]],
telemetry:delete_alarms: [[rule:admin_or_cloud_admin]]
}
The current acl.py and _query_to_kwargs access control setup either sets
project_id scope to None (do everything) or to the project_id in the request
header 'X-Project-Id'. This allows for admin or project scope, but nothing
in
between.
We tried hooks. Unfortunately we can't seem to turn the API controllers
into
HookControllers just by adding HookController to the Controller class
definition. It causes infinite recursion on API startup. For example, this
doesn't work because ceilometer-api will not start with it:
class MetersController(rest.RestController, HookController):
If there was a way to use hooks with the v2. API controllers that might work
really well.
So we are left using the @secure decorator and deriving the method name from
the request environ PATH_INFO and REQUEST_METHOD values. This is how we
determine the wrapped method within the class (REQUEST_METHOD + PATH_INFO =
telemetry:delete_alarms with some munging). We need the method name in
order to
selectively apply acces control to certain methods.
Deriving the method this way isn't ideal but it's the only thing we've
gotten working
between hooks, @secure, and regular decorators.
I submitted a WIP BP here: https://review.openstack.org/#/c/112137/3. It is
slightly out of date but should give you a beter idea of our goals.
Thanks
Eric,
If you can give us some more information about your end goal, independent
of the implementation, maybe we can propose an alternate technique to
achieve the same thing.
Doug
On Aug 12, 2014, at 6:21 PM, Ryan Petrello ryan.petre...@dreamhost.com
wrote:
Yep, you're right, this doesn't seem to work. The issue is that
security is enforced at routing time (while the controller is still
actually being discovered). In order to do this sort of thing with
the `check_permissions`, we'd probably need to add a feature to pecan.
On 08/12/14 06:38 PM, Pendergrass, Eric wrote:
Sure, here's the decorated method from v2.py:
class MetersController(rest.RestController):
Works on meters.
@pecan.expose()
def _lookup(self, meter_name, *remainder):
return MeterController(meter_name), remainder
@wsme_pecan.wsexpose([Meter], [Query])
@secure(RBACController.check_permissions)
def get_all(self, q=None):
and here's the decorator called by the secure tag:
class RBACController(object):
global _ENFORCER
if not _ENFORCER:
_ENFORCER = policy.Enforcer()
@classmethod
def check_permissions(cls):
# do some stuff
In check_permissions I'd like to know the class and method with the
@secure tag that caused check_permissions to be invoked. In this case, that
would be MetersController.get_all.
Thanks
Can you share some code? What do you mean by, is there a way for the
decorator code to know it was called by MetersController.get_all
On 08/12/14 04:46 PM, Pendergrass, Eric wrote:
Thanks Ryan, but for some reason the controller attribute is None:
(Pdb) from pecan.core import state
(Pdb) state.__dict__
{'hooks': [ceilometer.api.hooks.ConfigHook object at 0x31894d0,
ceilometer.api.hooks.DBHook object at 0x3189650,
ceilometer.api.hooks.PipelineHook object at 0x39871d0,
ceilometer.api.hooks.TranslationHook object at 0x3aa5510], 'app':
pecan.core.Pecan object at 0x2e76390, 'request': Request at
0x3ed7390 GET http://localhost:8777/v2/meters, 'controller': None,
'response': Response at 0x3ed74d0 200 OK}
-Original Message-
From: Ryan Petrello [mailto:ryan.petre...@dreamhost.com]
Sent: Tuesday, August 12, 2014 10:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] Way to get wrapped
method's name/class using Pecan secure decorators?
This should give you what you need:
from pecan.core import state
state.controller
On 08/12/14 04:08 PM, Pendergrass, Eric wrote:
Hi, I'm trying to use the built in secure decorator in Pecan for
access control, and I'ld like to get the name of the method that is wrapped
from within the decorator.
For instance, if I'm wrapping MetersController.get_all with an
@secure decorator, is there a way for the decorator code to know it was
called by MetersController.get_all?
I don't see any global objects that provide this information. I
can get the
[openstack-dev] Using gerrymander, a client API and command line tool for gerrit
Over the past couple of months I've worked on creating a python library and command line tool for dealing with gerrit. I've blogged about this a number of times on http://planet.openstack.org, but I figure there are quite a few people who won't be reading the blogs there or easily miss some posts hence this mail to alert people to its existance. Gerrymander was born out of my frustration with the inefficiency of handling reviews through the gerrit web UI. In particular (until today - yay !) the review comments were splattered with noise from CI bots, and it was hard to generate some kinds of reports for lists of reviews you might want. The gerrit upgrade has improved the latter to with better query language support, but it is still somewhat limited in the way it can present the results and I prefer the CLI reports over web UI anyway. You might be familiar with tools like gerrit_view, reviewtodo and reviewstats written by Josh Harlow and / or Russell Bryant in the past. As a starting point, gerrymander aimed to offer all the functionality present in those tools. More importantly though was the idea to write it as a set of a python classes rather than just put everything in a command line tool. This makes it easy for people to customize extend its functionality to pull our new interesting types of data. Personally, using gerrymander to query gerrit for reviews and being able to quickly get a list of comments filtered for bots has had a big positive impact on my efficiency as a core reviewer. I've been able to review more code in less time and focus my attention better. So if you are the kind of person who is more comfortable with having command line tools instead of pointy-clicky web UIs, I'd encourage you to try it out for yourself. Hopefully it will be of as much use to other reviewers as it has been for me. You can get it from pypi (pip install gerrymander) and for a quick start guide, check out the README file https://github.com/berrange/gerrymander/blob/master/README Or my blog posts https://www.berrange.com/tags/gerrymander/ It is intended to work with any Gerrit instance, not just openstack, so you'll need a config file that tailors it for openstack world, like our team membership, bot accounts, etc. I've got a demo config file here that should point you in the right direction at least: https://wiki.openstack.org/wiki/GerrymanderConfig Feel free to update that wiki to add more project teams I've not covered already, since there's many openstack projects I've not familiar enough with. NB, I've tested it to work on Linux systems. It would probably work on OS-X since that resembles UNIX well enough, but Windows people might be out of luck since it relies on forking stuff like ssh and less with pipes connecting them up. In terms of how I personally use it (assuming the above config file)... At least once a day I look at all open changes in Nova which touch any libvirt source files $ gerrymander -g nova --branch master libvirt and will go through and review anything that I've not seen before. In addition I'll process any open changes where I have commented on a previous version of a patch, but not commented in the current version which is a report generated by a special command: $ gerrymander -g nova todo-mine If I have more time I'll look at any patches which have been submitted where *no one* has done any review, touching anything in nova source tree $ gerrymander -g nova todo-noones or any patches where I've not reviewed the current version $ gerrymander -g nova todo-others That's pretty much all I need on a day-to-day basis to identify stuff needing my review attention. For actual review I'll use the gerrit web UI, or git fetch the patch locally depending on complexity of the change in question. Also if I want to see comments fully expanded, without bots, for a specific change number 104264 I would do $ gerrymander comments 104264 One day I'd love to be able to write some reports which pull priority data on blueprints from nova-specs or launchpad, and correlate with reviews so important changes needing attention can be highlighted... Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.
Hi, Does anyone know how to configure cinder ci tests to not have these errors? 12:32:11 *** Not Whitelisted *** 2014-08-14 12:23:56.179 18021 ERROR cinder.volume.volume_types [req-c9ec92ab-132b-4167-a467-15bd213659e8 bd1f54a867ce47acb4097cd94149efa0 d15dcf4cb3c7495389799ec849e9036d - - -] Default volume type is not found, please check default_volume_type config: Volume type with name dot could not be found. 17:43:28 *** Not Whitelisted *** 2014-08-11 17:31:20.343 2097 ERROR cinder.volume.volume_types [req-01e539ad-5357-4a0f-8d58-464b970114f9 f72cd499be584d9d9585bc26ca71c603 d845ad2d7e6a47dfb84bdf0754f60384 - - -] Default volume type is not found, please check default_volume_type config: Volume type with name cat_1 could not be found. http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/console.html http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/console.html Thanks, Ramy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is there a way to let nova schedule plugin fetch glance image metadata
Indeed, no REST API yet, but that's one of the things we will be considering for Gantt. I wonder if this is yet another argument for Gantt and, if you can wait until the Kilo cycle, maybe we can provide an appropriate service for Heat. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Wednesday, August 13, 2014 10:12 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Is there a way to let nova schedule plugin fetch glance image metadata On 08/13/2014 11:06 PM, zhiwei wrote: Hi Jay. The case is: When heat create a stack, it will first call our scheduler(will pass image_id), our scheduler will get image metadata by image_id. Our scheduler will build a placement policy through image metadata, then start booting VM. How exactly is Heat calling your scheduler? The Nova scheduler does not have a public REST API, so I'm unsure how you are calling it. More details needed, thanks! :) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)
Hi, Midokura CI should be up to date now too. We have a problem with zuul-merger when the host id of review.openstack.org changes. In this case, the new rsa key has to be added manually otherwise the build will fail with a: Merge Failed. This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset So if the review.openstack.org host changes soon it will start failing again. That said, taking into account that August is the usual vacation month in Europe and probably in some other parts as well, end of August sounds like a tight deadline. Also, I have been attending to third-party meetings regularly but the last one (I have checked the logs) and I feel like an announcement for these new requirements should have been done there. Have a great summer! Lucas On Wed, Aug 13, 2014 at 8:23 PM, James E. Blair cor...@inaugust.com wrote: Hi, We've updated the registration requirements for third-party CI systems here: http://ci.openstack.org/third_party.html We now have 86 third-party CI systems registered and have undertaken an effort to make things more user-friendly for the developers who interact with them. There are two important changes to be aware of: 1) We now generally name third-party systems in a descriptive manner including the company and product they are testing. We have renamed currently-operating CI systems to match these standards to the best of our abilities. Some of them ended up with particularly bad names (like Unknown Function...). If your system is one of these, please join us in #openstack-infra on Freenode to establish a more descriptive name. 2) We have established a standard wiki page template to supply a description of the system, what is tested, and contact information for each system. See https://wiki.openstack.org/wiki/ThirdPartySystems for an index of such pages and instructions for creating them. Each third-party CI system will have its own page in the wiki and it must include a link to that page in every comment that it leaves in Gerrit. If you operate a third-party CI system, please ensure that you register a wiki page and update your system to link to it in every new Gerrit comment by the end of August. Beginning in September, we will disable systems that have not been updated. Thanks, Jim ___ OpenStack-Infra mailing list openstack-in...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination
On Thu, Aug 14, 2014 at 10:29 AM, Mike Perez thin...@gmail.com wrote: On 06:55 Thu 14 Aug , Boring, Walter wrote: Hey guys, I wanted to pose a nomination for Cinder core. Xing Yang. She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself. She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time. I think she would be a good addition to the core team. +1 If you take a look at the last 3 months [1][2] she has been very active and providing great feedback in reviews. She has also been setting great expectations for other drivers with the recent third-party CI work. Thanks Xing! [1] - http://russellbryant.net/openstack-stats/cinder-reviewers-90.txt [2] - http://stackalytics.com/?user_id=xing-yang -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 for sure!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I explain in the rest of my email below I'm not advocating getting
Re: [openstack-dev] [Neutron][DevStack] How to increase developer usage of Neutron
CARVER, PAUL pc2...@att.com wrote on 08/14/2014 09:35:17 AM: Mike Spreitzer [mailto:mspre...@us.ibm.com] wrote: I'll bet I am not the only developer who is not highly competent with bridges and tunnels, Open VSwitch, Neutron configuration, and how DevStack transmutes all those. My bet is that you would have more developers using Neutron if there were an easy-to-find and easy-to-follow recipe to use, to create a developer install of OpenStack with Neutron. One that's a pretty basic and easy case. Let's say a developer gets a recent image of Ubuntu 14.04 from Canonical, and creates an instance in some undercloud, and that instance has just one NIC, at 10.9.8.7/16. If there were a recipe for such a developer to follow from that point on, it would be great. https://wiki.openstack.org/wiki/NeutronDevstack worked for me. However, I'm pretty sure it's only a single node all in one setup. At least, I created only one VM to run it on and I don't think DevStack has created multiple nested VMs inside of the one I create to run DevStack. I haven't gotten around to figuring out how to setup a full multi-node DevStack setup with separate compute nodes and network nodes and GRE/VXLAN tunnels. There are multi-node instructions on that wiki page but I haven't tried following them. If someone has a Vagrant file that creates a full multi- node Neutron devstack complete with GRE/VXLAN tunnels it would be great if they could add it to that wiki page. A working concrete recipe for a single-node install would be great. https://wiki.openstack.org/wiki/NeutronDevstack is far from a concrete recipe, leaving many blanks to be filled in by the reader. My problem is that as a non-expert in the relevant networking arcana, Neutron implementation, and DevStack configuration options, it is not entirely obvious how to fill in the blanks. For starters, http://docs.openstack.org/admin-guide-cloud/content/network-connectivity.html speaks of four networks and, appropriately for a general page like that, does not relate them to NICs. But at the start of the day, I need to know how many NICs to put on my host VM (the one in which I will run DevStack to install OpenStack), how to configure them in the host VM's operating system, and how to tell DevStack whatever details it needs and cannot figure out on its own (I am not even clear on what that set is). I need to know how to derive the fixed and floating IP address ranges from the networking context of my host VM. A recipe that requires more than one NIC on my host VM can be problematic in some situations, which is why I suggested starting with a recipe for a host with a single NIC. I am not using Xen in my undercloud. I suspect many developers are not using Xen. I did not even know it was possible to install OpenStack inside a Xen VM; does that still work? I was hoping for a working concrete recipe that does not depend on the undercloud, rather something that works in a vanilla context that can easily be established with whatever undercloud a given developer is using. Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Is there a way to let nova schedule plugin fetch glance image metadata
Mmm... I can understand that you perhaps need an external scheduler for
your own purposes, but I think you can't expect your plugin merged upstream
for two reasons :
- during Icehouse, there was an effort for not having the scheduler
proxying to the compute nodes
- Call for scheduler needs to go thru Nova-api and no endpoints are there
got just scheduling
That said, once Gantt will be lifted, discussing about possible endpoints
sounds reasonable to me.
-Sylvain
Le 14 août 2014 05:07, zhiwei zhiw...@gmail.com a écrit :
Hi Jay.
The case is: When heat create a stack, it will first call our
scheduler(will pass image_id), our scheduler will get image metadata by
image_id.
Our scheduler will build a placement policy through image metadata, then
start booting VM.
Thanks.
On Thu, Aug 14, 2014 at 10:28 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/13/2014 10:22 PM, zhiwei wrote:
Thanks Jay.
The scheduler plugin is not a scheduler filter.
We implemented a scheduler instead of using nova native scheduler.
OK. Any reason why you did this? Without any details on what your
scheduler does, it's tough to give advice on how to solve your problems.
One of our scheduler component need to fetch image metadata by image_id(
at this time, there is not instance ).
Why? Again, the request_spec contains all the information you need about
the image...
Best,
-jay
On Thu, Aug 14, 2014 at 9:29 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:
On 08/13/2014 08:31 PM, zhiwei wrote:
Hi all,
We wrote a nova schedule plugin that need to fetch image
metadata by
image_id, but encountered one thing, we did not have the glance
context.
Our solution is to configure OpenStack admin user and password
to
nova.conf, as you know this is not good.
So, I want to ask if there are any other ways to do this?
You should not have to do a separate fetch of image metadata in a
scheduler filter (which is what I believe you meant by plugin
above?).
The filter object's host_passes() method has a filter_properties
parameter that contains the request_spec, that in turn contains the
image, which in turn contains the image metadata. You can access
it like so:
def host_passes(self, host_state, filter_properties):
request_spec = filter_properties['request___spec']
image_info = request_spec['image']
# Certain image attributes are accessed via top-level keys,
like
# size, disk_format, container_format and checksum
image_size = image_info['size']
# Other attributes can be accessed in the properties
collection
# of key/value pairs
image_props = image.get('properties', {})
for key, value in image_props.items():
# do something...
Best,
-jay
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)
On 2014-08-14 20:50:21 +0200 (+0200), Lucas Eznarriaga wrote: [...] We have a problem with zuul-merger when the host id of review.openstack.org changes. In this case, the new rsa key has to be added manually [...] If so, you were broken a while... the last (and effectively only in recent history) time we replaced the Gerrit SSH API RSA host key on review.openstack.org was in April as a safety precaution in the wake of the Heartbleed Bug announcement. We definitely haven't touched it in the four months since then. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?
Hi mikal, Le 14 août 2014 01:49, Michael Still mi...@stillhq.com a écrit : So, there's been a lot of email in the last few days and I feel I am not keeping up. Sylvain, can you summarise for me what the plan is here? Can we roll forward or do we need to revert? Well, as we agreed with Nikola, the problem is not with ERT but RT, as the request data needs to be passed when claiming a resource. I'm proposing to keep ERT and only consider plugins that are not needing request_spec when claiming, but here there is no agreement yet. Unfortunately, I'm on PTO till Tuesday, and Paul Murray this week as well. So I propose to delay the discussion by these days as that's not impacted by FPF. In the meantime, I created a patch for discussing a workaround [1] for Juno until we correctly figure out how to fix that issue, as it deserves a spec. Time is running out for Juno. Indeed, I'm mostly concerned by the example exception spec that Nikola mentioned [2] (isolate-scheduler-db) as it still needs a second +2 while FPF is in 1 week... I'm planning to deliver an alternative implementation without ERT wrt this discussion. -Sylvain [1] https://review.openstack.org/#/c/113936/ [2] https://review.openstack.org/#/c/89893 Thanks, Michael On Thu, Aug 14, 2014 at 3:40 AM, Sylvain Bauza sba...@redhat.com wrote: Le 13/08/2014 18:40, Brian Elliott a écrit : On Aug 12, 2014, at 5:21 AM, Nikola Đipanov ndipa...@redhat.com wrote: Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - I'll add it to compute nodes table thinking it's a fundamental enough property of a compute host that it deserves to be there, although I was considering Extensible Resource Tracker at one point (ERT from now on - see [2]) but looking at the code - it did not seem to provide anything I desperately needed, so I went with keeping it simple. So fast-forward a few days, and I caught myself solving a problem that I kept thinking ERT should have solved - but apparently hasn't, and I think it is fundamentally a broken design without it - so I'd really like to see it re-visited. The problem can be described by the following lemma (if you take 'lemma' to mean 'a sentence I came up with just now' :)): Due to the way scheduling works in Nova (roughly: pick a host based on stale(ish) data, rely on claims to trigger a re-schedule), _same exact_ information that scheduling service used when making a placement decision, needs to be available to the compute service when testing the placement. “ Correct This is not the case right now, and the ERT does not propose any way to solve it - (see how I hacked around needing to be able to get extra_specs when making claims in [3], without hammering the DB). The result will be that any resource that we add and needs user supplied info for scheduling an instance against it, will need a buggy re-implementation of gathering all the bits from the request that scheduler sees, to be able to work properly. Agreed, ERT does not attempt to solve this problem of ensuring RT has an identical set of information for testing claims. I don’t think it was intended to. ERT does solve the issue of bloat in the RT with adding just-one-more-thing to test usage-wise. It gives a nice hook for inserting your claim logic for your specific use case. I think Nikola and I agreed on the fact that ERT is not responsible for this design. That said I can talk on behalf of Nikola... This is obviously a bigger concern when we want to allow users to pass data (through image or flavor) that can affect scheduling, but still a huge concern IMHO. I think passing additional data through to compute just wasn’t a problem that ERT aimed to solve. (Paul Murray?) That being said, coordinating the passing of any extra data required to test a claim that is *not* sourced from the host itself would be a very nice addition. You are working around it with some caching in your flavor db lookup use case, although one could of course cook up a cleaner patch to pass such data through on the “build this” request to the compute. Indeed, and that's why I think the problem can be resolved thanks to 2 different things : 1. Filters need to look at what ERT is giving them, that's what isolate-scheduler-db is trying to do (see my patches [2.3 and 2.4] on the previous emails 2. Some extra user request needs to be checked in the test() method of ERT plugins (where claims are done), so I provided a WIP patch for discussing it : https://review.openstack.org/#/c/113936/ As I see that there are already BPs proposing to use this IMHO broken ERT ([4] for example), which will surely add to the proliferation of code that hacks around these design shortcomings in what is already a
Re: [openstack-dev] [nova] Review priorities as we approach juno-3
== Move Virt Drivers to use Objects (Juno Work) == I couldn't actually find any code out for review for this one apart from https://review.openstack.org/#/c/94477/, is there more out there? This was an umbrella one to cover a bunch of virt driver objects work done early in the cycle. Much of that is done, I haven't gone looking for anything to see if there are any obvious things to include under this anymore, but I'll try to do that. == Add a virt driver for Ironic == This one is in progress, but we need to keep going at it or we wont get it merged in time. * https://review.openstack.org/#/c/111223/ was approved, but a rebased ate it. Should be quick to re-approve. * https://review.openstack.org/#/c/111423/ * https://review.openstack.org/#/c/111425/ * ...there are more reviews in this series, but I'd be super happy to see even a few reviewed I've been reviewing this pretty heavy and I think that it's just taking a while to make changes given the roundabout way they're getting done first in Ironic. I'm pretty confident that this one will be okay. == VMware: spawn refactor == * https://review.openstack.org/#/c/104145/ * https://review.openstack.org/#/c/104147/ (Dan Smith's -2 on this one seems procedural to me) Yep, we're just trying to get MineSweeper votes on them before letting them in. We already had one refactor go in without a minesweeper run that ... broke minesweeper :) --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party] What tests are required to be run
Hi- I'm hitting bugs for (basic/advanced)_server_ops testing. https://bugs.launchpad.net/nova/+bug/1232303 Kindly help me with a fix to this. Thanking you. -- Trinath Somanchi - B39208 trinath.soman...@freescale.com | extn: 4048 -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Thursday, August 14, 2014 9:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] [third-party] What tests are required to be run Folks, I'm not sure if all CI accounts are running sufficient tests. Per the requirements wiki page here [1], everyone needs to be running more than just Tempest API tests, which I still see most neutron third-party CI setups doing. I'd like to ask everyone who operates a third-party CI account for Neutron to please look at the link below and make sure you are running appropriate tests. If you have questions, the weekly third-party meeting [2] is a great place to ask questions. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com wrote: On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote: At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up with a pile of mud that no one is happy with. That we're being so abstract about all of this is frustrating. I get that no-one wants to start a flamewar, but can someone be concrete about what they feel we should say 'no' to but are likely to say 'yes' to? I'll bite, but please note this is a strawman. No: * Accepting any more projects into incubation until we are comfortable with the state of things again * Marconi * Ceilometer Well -1 to that, obviously, from me. Ceilometer is on track to fully execute on the gap analysis coverage plan agreed with the TC at the outset of this cycle, and has an active plan in progress to address architectural debt. Yes, there seems to be an attitude among several people in the community that the Ceilometer team denies that there are issues and refuses to work on them. Neither of those things is the case from our perspective. Totally agree. Can you be more specific about the shortcomings you see in the project that aren’t being addressed? Once again, this is just a strawman. I'm just not sure OpenStack has 'blessed' the best solution out there. https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready - Successfully passed the challenge of being adopted by 3 related projects which have agreed to join or use ceilometer: - Synaps - Healthnmon - StackTach https://wiki.openstack.org/w/index.php?title=StackTachaction=editredlink=1 Stacktach seems to still be under active development ( http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by rackspace in production and from everything I hear is more mature then ceilometer. Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything. * Sahara * Trove * Tripleo You write as if cross-project efforts are both of fixed size and amenable to centralized command control. Neither of which is actually the case, IMO. Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. What “cross-project efforts” are we talking about? The liaison program in Oslo has been a qualified success so far. Would it make sense to extend that to other programs and say that each project needs at least one designated QA, Infra, Doc, etc. contact? Doug Yes: * All integrated projects that are not listed above And what of the other pending graduation request? Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Review priorities as we approach juno-3
On Fri, Aug 15, 2014 at 6:37 AM, Dan Smith d...@danplanet.com wrote: == Move Virt Drivers to use Objects (Juno Work) == I couldn't actually find any code out for review for this one apart from https://review.openstack.org/#/c/94477/, is there more out there? This was an umbrella one to cover a bunch of virt driver objects work done early in the cycle. Much of that is done, I haven't gone looking for anything to see if there are any obvious things to include under this anymore, but I'll try to do that. Thanks, I'd appreciate that. If its all done, we should mark it implemented. == Add a virt driver for Ironic == This one is in progress, but we need to keep going at it or we wont get it merged in time. * https://review.openstack.org/#/c/111223/ was approved, but a rebased ate it. Should be quick to re-approve. * https://review.openstack.org/#/c/111423/ * https://review.openstack.org/#/c/111425/ * ...there are more reviews in this series, but I'd be super happy to see even a few reviewed I've been reviewing this pretty heavy and I think that it's just taking a while to make changes given the roundabout way they're getting done first in Ironic. I'm pretty confident that this one will be okay. Yep, I appreciate your focus on this one -- as I am sure the ironic people do too. If another core was available to pair up with you on these we might be able to get them to land faster. I was doing that for a while, but I haven't had time in the last week or so. == VMware: spawn refactor == * https://review.openstack.org/#/c/104145/ * https://review.openstack.org/#/c/104147/ (Dan Smith's -2 on this one seems procedural to me) Yep, we're just trying to get MineSweeper votes on them before letting them in. We already had one refactor go in without a minesweeper run that ... broke minesweeper :) Is there a way for the minesweeper people to manually kick off runs against specific reviews? Doing that might unblock this faster than rechecking and hoping. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Le 14 août 2014 21:56, Joe Gordon joe.gord...@gmail.com a écrit : On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I
Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.
Cinder.conf needs to have a default_volume_type entry set under the [Default] group and a volume type that is valid, for example, default_volume_type=bronze. This allows for a volume to be created when a volume type is not selected, the default 'None' type. This feature has been available for some time in cinder but recently enabled in devstack. ~Kurt -Original Message- From: Asselin, Ramy Sent: Thursday, August 14, 2014 10:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Hi, Does anyone know how to configure cinder ci tests to not have these errors? 12:32:11 *** Not Whitelisted *** 2014-08-14 12:23:56.179 18021 ERROR cinder.volume.volume_types [req-c9ec92ab-132b-4167-a467-15bd213659e8 bd1f54a867ce47acb4097cd94149efa0 d15dcf4cb3c7495389799ec849e9036d - - -] Default volume type is not found, please check default_volume_type config: Volume type with name dot could not be found. 17:43:28 *** Not Whitelisted *** 2014-08-11 17:31:20.343 2097 ERROR cinder.volume.volume_types [req-01e539ad-5357-4a0f-8d58-464b970114f9 f72cd499be584d9d9585bc26ca71c603 d845ad2d7e6a47dfb84bdf0754f60384 - - -] Default volume type is not found, please check default_volume_type config: Volume type with name cat_1 could not be found. http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/console.html http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/console.html Thanks, Ramy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Which changes need accompanying bugs?
On Aug 13, 2014, at 11:11 AM, Kevin Benton blak...@gmail.com wrote: Is the pylint static analysis that caught that error prone to false positives? If not, I agree that it would be really nice if that were made part of the tox check so these don't have to be fixed after the fact. To me that particular patch seems like one that should be accompanied with a unit test because it's a failure case with cleanup code that isn't being touched by the unit tests. +1 As a general rule I would like to see test addition included with any fix targeting a bug that was merged due to a lack of coverage. m. On Aug 13, 2014 8:34 AM, Armando M. arma...@gmail.com wrote: I am gonna add more color to this story by posting my replies on review [1]: Hi Angus, You touched on a number of points. Let me try to give you an answer to all of them. (I'll create a bug report too. I still haven't worked out which class of changes need an accompanying bug report and which don't.) The long story can be read below: https://wiki.openstack.org/wiki/BugFilingRecommendations https://wiki.openstack.org/wiki/GitCommitMessages IMO, there's a grey area for some of the issues you found, but when I am faced with a bug, I tend to answer myself? Would a bug report be useful to someone else? The author of the code? A consumer of the code? Not everyone follow the core review system all the time, whereas Launchpad is pretty much the tool everyone uses to stay abreast with the OpenStack release cycle. Obviously if you're fixing a grammar nit, or filing a cosmetic change that has no functional impact then I warrant the lack of a test, but in this case you're fixing a genuine error: let's say we want to backport this to icehouse, how else would we make the release manager of that? He/she is looking at Launchpad. I can add a unittest for this particular code path, but it would only check this particular short segment of code, would need to be maintained as the code changes, and wouldn't catch another occurrence somewhere else. This seems an unsatisfying return on the additional work :( You're looking at this from the wrong perspective. This is not about ensuring that other code paths are valid, but that this code path stays valid over time, ensuring that the code path is exercised and that no other regression of any kind creep in. The reason why this error was introduced in the first place is because the code wasn't tested when it should have. If you don't get that this mechanical effort of fixing errors by static analysis is kind of ineffective, which leads me to the last point I actually found this via static analysis using pylint - and my question is: should I create some sort of pylint unittest that tries to catch this class of problem across the entire codebase? [...] I value what you're doing, however I would see even more value if we prevented these types of errors from occurring in the first place via automation. You run pylint today, but what about tomorrow, or a week from now? Are you gonna be filing pylint fixes for ever? We might be better off automating the check and catch these types of errors before they land in the tree. This means that the work you are doing it two-pronged: a) automate the detection of some failures by hooking this into tox.ini via HACKING/pep8 or equivalent mechanism and b) file all the fixes that require these validation tests to pass; c) everyone is happy, or at least they should be. I'd welcome to explore a better strategy to ensure a better quality of the code base, without some degree of automation, nothing will stop these conversation from happening again. Cheers, Armando [1] https://review.openstack.org/#/c/113777/ On 13 August 2014 03:02, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13/08/14 09:28, Angus Lees wrote: I'm doing various small cleanup changes as I explore the neutron codebase. Some of these cleanups are to fix actual bugs discovered in the code. Almost all of them are tiny and obviously correct. A recurring reviewer comment is that the change should have had an accompanying bug report and that they would rather that change was not submitted without one (or at least, they've -1'ed my change). I often didn't discover these issues by encountering an actual production issue so I'm unsure what to include in the bug report other than basically a copy of the change description. I also haven't worked out the pattern yet of which changes should have a bug and which don't need one. There's a section describing blueprints in NeutronDevelopment but nothing on bugs. It would be great if someone who understands the nuances here could add some words on when to file bugs: Which type of changes should have accompanying bug reports? What is the purpose of that bug, and what should it contain? It was discussed before at:
Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.
Both configurations have that set as you described. [1][2] Who actually creates that volume type? Is that supposed to be added manually to local.sh, or is this a bug in devstack? [1] http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/logs/etc/cinder/cinder.conf.txt.gz [DEFAULT] default_volume_type = cat_1 [2] http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/logs/etc/cinder/cinder.conf.txt.gz [DEFAULT] default_volume_type = dot -Original Message- From: Martin, Kurt Frederick (ESSN Storage MSDU) Sent: Thursday, August 14, 2014 2:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Cinder.conf needs to have a default_volume_type entry set under the [Default] group and a volume type that is valid, for example, default_volume_type=bronze. This allows for a volume to be created when a volume type is not selected, the default 'None' type. This feature has been available for some time in cinder but recently enabled in devstack. ~Kurt -Original Message- From: Asselin, Ramy Sent: Thursday, August 14, 2014 10:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Hi, Does anyone know how to configure cinder ci tests to not have these errors? 12:32:11 *** Not Whitelisted *** 2014-08-14 12:23:56.179 18021 ERROR cinder.volume.volume_types [req-c9ec92ab-132b-4167-a467-15bd213659e8 bd1f54a867ce47acb4097cd94149efa0 d15dcf4cb3c7495389799ec849e9036d - - -] Default volume type is not found, please check default_volume_type config: Volume type with name dot could not be found. 17:43:28 *** Not Whitelisted *** 2014-08-11 17:31:20.343 2097 ERROR cinder.volume.volume_types [req-01e539ad-5357-4a0f-8d58-464b970114f9 f72cd499be584d9d9585bc26ca71c603 d845ad2d7e6a47dfb84bdf0754f60384 - - -] Default volume type is not found, please check default_volume_type config: Volume type with name cat_1 could not be found. http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/console.html http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/console.html Thanks, Ramy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] [Containers] Containers Service for OpenStack
OpenStack Devs, In accordance with guidance from the Nova team at the Midcycle meeting, I have drafted the following proposal for a new OpenStack service to fit into the Compute program: https://blueprints.launchpad.net/nova/+spec/containers-service https://review.openstack.org/114044 Please take a look, and let me know your feedback so we can refine and resource this plan. Please let me know if you have an interest in working on this. Thanks, Adrian Otto ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found.
They need to be manually added. -Original Message- From: Asselin, Ramy Sent: Thursday, August 14, 2014 2:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Both configurations have that set as you described. [1][2] Who actually creates that volume type? Is that supposed to be added manually to local.sh, or is this a bug in devstack? [1] http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/logs/etc/cinder/cinder.conf.txt.gz [DEFAULT] default_volume_type = cat_1 [2] http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/logs/etc/cinder/cinder.conf.txt.gz [DEFAULT] default_volume_type = dot -Original Message- From: Martin, Kurt Frederick (ESSN Storage MSDU) Sent: Thursday, August 14, 2014 2:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Cinder.conf needs to have a default_volume_type entry set under the [Default] group and a volume type that is valid, for example, default_volume_type=bronze. This allows for a volume to be created when a volume type is not selected, the default 'None' type. This feature has been available for some time in cinder but recently enabled in devstack. ~Kurt -Original Message- From: Asselin, Ramy Sent: Thursday, August 14, 2014 10:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Cinder] 3'rd party CI systems: Not Whitelisted Volume type with name * could not be found. Hi, Does anyone know how to configure cinder ci tests to not have these errors? 12:32:11 *** Not Whitelisted *** 2014-08-14 12:23:56.179 18021 ERROR cinder.volume.volume_types [req-c9ec92ab-132b-4167-a467-15bd213659e8 bd1f54a867ce47acb4097cd94149efa0 d15dcf4cb3c7495389799ec849e9036d - - -] Default volume type is not found, please check default_volume_type config: Volume type with name dot could not be found. 17:43:28 *** Not Whitelisted *** 2014-08-11 17:31:20.343 2097 ERROR cinder.volume.volume_types [req-01e539ad-5357-4a0f-8d58-464b970114f9 f72cd499be584d9d9585bc26ca71c603 d845ad2d7e6a47dfb84bdf0754f60384 - - -] Default volume type is not found, please check default_volume_type config: Volume type with name cat_1 could not be found. http://15.126.198.151/60/111460/18/check/dsvm-tempest-hp-lefthand/3ee1598/console.html http://publiclogs.emc.com/vnx_ostack/EMC_VNX_FC/212/console.html Thanks, Ramy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Review priorities as we approach juno-3
Le 14 août 2014 22:02, Michael Still mi...@stillhq.com a écrit : Hi. We're rapidly approaching j-3, so I want to remind people of the current reviews that are high priority. The definition of high priority I am using here is blueprints that are marked high priority in launchpad that have outstanding code for review -- I am sure there are other reviews that are important as well, but I want us to try to land more blueprints than we have so far. These are listed in the order they appear in launchpad. == Compute Manager uses Objects (Juno Work) == https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/compute-manager-objects-juno,n,z This is ongoing work, but if you're after some quick code review points they're very easy to review and help push the project forward in an important manner. == Move Virt Drivers to use Objects (Juno Work) == I couldn't actually find any code out for review for this one apart from https://review.openstack.org/#/c/94477/, is there more out there? == Add a virt driver for Ironic == This one is in progress, but we need to keep going at it or we wont get it merged in time. * https://review.openstack.org/#/c/111223/ was approved, but a rebased ate it. Should be quick to re-approve. * https://review.openstack.org/#/c/111423/ * https://review.openstack.org/#/c/111425/ * ...there are more reviews in this series, but I'd be super happy to see even a few reviewed == Create Scheduler Python Library == * https://review.openstack.org/#/c/82778/ * https://review.openstack.org/#/c/104556/ (There are a few abandoned patches in this series, I think those two are the active ones but please correct me if I am wrong). Nope that's OK, those are the only one implementing the spec. We had a +2 on 82778 but it needed a rebase, FYI. == VMware: spawn refactor == * https://review.openstack.org/#/c/104145/ * https://review.openstack.org/#/c/104147/ (Dan Smith's -2 on this one seems procedural to me) * https://review.openstack.org/#/c/105738/ * ...another chain with many more patches to review Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
On Aug 14, 2014, at 4:41 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann d...@doughellmann.com wrote: On Aug 13, 2014, at 3:05 PM, Eoghan Glynn egl...@redhat.com wrote: At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up with a pile of mud that no one is happy with. That we're being so abstract about all of this is frustrating. I get that no-one wants to start a flamewar, but can someone be concrete about what they feel we should say 'no' to but are likely to say 'yes' to? I'll bite, but please note this is a strawman. No: * Accepting any more projects into incubation until we are comfortable with the state of things again * Marconi * Ceilometer Well -1 to that, obviously, from me. Ceilometer is on track to fully execute on the gap analysis coverage plan agreed with the TC at the outset of this cycle, and has an active plan in progress to address architectural debt. Yes, there seems to be an attitude among several people in the community that the Ceilometer team denies that there are issues and refuses to work on them. Neither of those things is the case from our perspective. Totally agree. Can you be more specific about the shortcomings you see in the project that aren’t being addressed? Once again, this is just a straw man. You’re not the first person to propose ceilometer as a project to kick out of the release, though, and so I would like to be talking about specific reasons rather than vague frustrations. I'm just not sure OpenStack has 'blessed' the best solution out there. https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready Successfully passed the challenge of being adopted by 3 related projects which have agreed to join or use ceilometer: Synaps Healthnmon StackTach Stacktach seems to still be under active development (http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by rackspace in production and from everything I hear is more mature then ceilometer. Stacktach is older than ceilometer, but does not do all of the things ceilometer does now and aims to do in the future. It has been a while since I last looked at it, so the situation may have changed, but some of the reasons stacktach would not be a full replacement for ceilometer include: it only works with AMQP; it collects notification events, but doesn’t offer any metering ability per se (no tracking of values like CPU or bandwidth utilization); it only collects notifications from some projects, and doesn’t have a way to collect data from swift, which doesn’t emit notifications; and it does not integrate with Heat to trigger autoscaling alarms. We did work with a few of the Stacktach developers on bringing event collection into ceilometer, and that work is allowing us to modify the way we store the meter data that causes a lot of the performance issues we’ve seen. That work is going on now and will be continued into Kilo, when we expect to be adding drivers for time-series databases more appropriate for that type of data. We’ve just finished the TC meeting where some of these issues were discussed, but I want to reiterate my stance here more publicly. As a community, we need to be able to talk about the technical shortcomings of projects. We need to be able to say, for example, “ceilometer, your runtime performance isn’t good enough, you need to work on that rather than adding features.” But we must also be willing give the team in question the benefit of the doubt that they will work on the problem before we bring out the pitchforks of de-integration, because there are serious community implications around that level of rejection. Doug Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything. * Sahara * Trove * Tripleo You write as if cross-project efforts are both of fixed size and amenable to centralized command control. Neither of which is actually the case, IMO. Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. What “cross-project efforts” are we talking about? The liaison program in Oslo has been a qualified success so far. Would it make sense to extend that to other programs and say that each project needs at least one
Re: [openstack-dev] [nova] Review priorities as we approach juno-3
I have also been reminded that http://54.201.139.117/nova-bugs.html tracks bugs with outstanding code reviews (click on ready for review). There are 179 at the moment, so it sure would be cool to land some bug fixes. Thanks, Michael On Fri, Aug 15, 2014 at 5:57 AM, Michael Still mi...@stillhq.com wrote: Hi. We're rapidly approaching j-3, so I want to remind people of the current reviews that are high priority. The definition of high priority I am using here is blueprints that are marked high priority in launchpad that have outstanding code for review -- I am sure there are other reviews that are important as well, but I want us to try to land more blueprints than we have so far. These are listed in the order they appear in launchpad. == Compute Manager uses Objects (Juno Work) == https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/compute-manager-objects-juno,n,z This is ongoing work, but if you're after some quick code review points they're very easy to review and help push the project forward in an important manner. == Move Virt Drivers to use Objects (Juno Work) == I couldn't actually find any code out for review for this one apart from https://review.openstack.org/#/c/94477/, is there more out there? == Add a virt driver for Ironic == This one is in progress, but we need to keep going at it or we wont get it merged in time. * https://review.openstack.org/#/c/111223/ was approved, but a rebased ate it. Should be quick to re-approve. * https://review.openstack.org/#/c/111423/ * https://review.openstack.org/#/c/111425/ * ...there are more reviews in this series, but I'd be super happy to see even a few reviewed == Create Scheduler Python Library == * https://review.openstack.org/#/c/82778/ * https://review.openstack.org/#/c/104556/ (There are a few abandoned patches in this series, I think those two are the active ones but please correct me if I am wrong). == VMware: spawn refactor == * https://review.openstack.org/#/c/104145/ * https://review.openstack.org/#/c/104147/ (Dan Smith's -2 on this one seems procedural to me) * https://review.openstack.org/#/c/105738/ * ...another chain with many more patches to review Thanks, Michael -- Rackspace Australia -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Which program for Rally
Matt, One thing did just occur to me while writing this though it's probably worth investigating splitting out the stress test framework as an external tool/project after we start work on the tempest library. [3] I fully agree with the fact that stress testing doesn't belong to Tempest. This current thread is all about this aspect and all my arguments, related to splitting Rally and merging it to tempest are related to this. Could you please elaborate, why instead of ready solution Rally that has community and is aligned with OpenStack and OpenStack processes you are going to create from scratch similar solution? I really don't see any reasons why we need to duplicate existing and working solution and can't just work together on Rally? Best regards, Boris Pavlovic On Fri, Aug 15, 2014 at 1:15 AM, Matthew Treinish mtrein...@kortar.org wrote: On Wed, Aug 13, 2014 at 03:48:59PM -0600, Duncan Thomas wrote: On 13 August 2014 13:57, Matthew Treinish mtrein...@kortar.org wrote: On Tue, Aug 12, 2014 at 01:45:17AM +0400, Boris Pavlovic wrote: Keystone, Glance, Cinder, Neutron and Heat are running rally performance jobs, that can be used for performance testing, benchmarking, regression testing (already now). These jobs supports in-tree plugins for all components (scenarios, load generators, benchmark context) and they can use Rally fully without interaction with Rally team at all. More about these jobs: https://docs.google.com/a/mirantis.com/document/d/1s93IBuyx24dM3SmPcboBp7N47RQedT8u4AJPgOHp9-A/ So I really don't see anything like this in tempest (even in observed future) So this is actually the communication problem I mentioned before. Singling out individual projects and getting them to add a rally job is not cross project communication. (this is part of what I meant by push using Rally) There was no larger discussion on the ML or a topic in the project meeting about adding these jobs. There was no discussion about the value vs risk of adding new jobs to the gate. Also, this is why less than half of the integrated projects have these jobs. Having asymmetry like this between gating workloads on projects helps no one. So the advantage of the approach, rather than having a massive cross-product discussion, is that interested projects (I've been very interested for a cinder core PoV) act as a test bed for other projects. 'Cross project' discussions rather come to other teams, they rely on people to find them, where as Boris came to us, said I've got this thing you might like, try it out, tell me what you want. He took feedback, iterated fast and investigated bugs. It has been a genuine pleasure to work with him, and I feel we made progress faster than we would have done if it was trying to please everybody. I'm not arguing whether Boris was great to work with or not. Or whether there isn't value in talking directly to the dev team when setting up a new job. That is definitely the fastest path to getting a new job up and running. But, for something like adding a new class of dsvm job which runs on every patch, that affects everyone, not just the project where the jobs are being added. A larger discussion is really necessary to weigh whether such a job should be added. It really only needs to happen once, just before the first one is added on an integrated project. That being said the reason I think osprofiler has been more accepted and it's adoption into oslo is not nearly as contentious is because it's an independent library that has value outside of itself. You don't need to pull in a monolithic stack to use it. Which is a design point more conducive with the rest of OpenStack. Sorry, are you suggesting tempest isn't a giant monolithic thing? Because I was able to comprehend the rally code very quickly, that isn't even slightly true of tempest. Having one simple tool that does one thing well is exactly what rally has tried to do - tempest seems to want to be five different things at once (CI, instalation tests, trademark, preformance, stress testing, ...) This is actually a common misconception about the purpose and role of Tempest. Tempest is strictly concerned with being the integration test suite for OpenStack, which just includes the actual tests and some methods of running the tests. This is attempted to be done in a manner which is independent of the environment in which tempest is run or run against. (for example, devstack vs a public cloud) Yes tempest is a large project and has a lot of tests which just adds to it's complexity, but it's scope is quite targeted. It's just that it grows at the same rate OpenStack scope grows because tempest has coverage for all the projects. Methods of running the tests does include the stress tests framework, but that is mostly just a method of leveraging the large quantity of tests we currently
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 02:48 PM, Dugger, Donald D wrote: My experience with mics, no matter how good, In conference rooms is not good. You are always working hard to hear the soft spoken person who is drowned by the background noise. It’s always a strain and I don’t want to even think about doing it for a full 8 hrs. It’s better than nothing so I agree, we need to provide some sort of remote conferencing at meetups but nothing compares with actually being there. I’m not a core so I’m speaking from the outside but I think requiring attendance at the summits (absence requires a note from your parent Jwhile strongly encouraging attendance at mid-cycle meetups seems reasonable. I think expecting summit attendance, rather than requiring, is a better way to say it, but otherwise I agree that this seems reasonable. PS: In re companies spending millions on OpenStack so travel to f2f events should be a drop in the bucket. It doesn’t always work that way with the finance department, money comes out of different buckets and the travel bucket `always` dries up first. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 *From:*Joe Gordon [mailto:joe.gord...@gmail.com] *Sent:* Wednesday, August 13, 2014 10:48 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [nova][core] Expectations of core reviewers On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com mailto:mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. What about making it easier for remote people to participate at the mid-cycle meetups? Set up some microphones and a Google hangout? At least that way attending the mid-cycle is not all or nothing. We did something like this last cycle (IIRC we didn't have enough mics) and it worked pretty well. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] The future of the integrated release
Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. OK, so what exactly do you suspect wouldn't be enough, for what exactly? Is it the likely number of such new resources, or the level of domain- expertise that they can be realistically be expected bring to the table, or the period of time to on-board them, or something else? And which cross-project concern do you think is most strained by the current set of projects in the integrated release? Is it: * QA * infra * release management * oslo * documentation * stable-maint or something else? Each of those teams has quite different prerequisite skill-sets, and the on-ramp for someone jumping in seeking to make a positive impact will vary from team to team. Different approaches have been tried on different teams, ranging from dedicated project-liaisons (Oslo) to shared cores (Sahara/Infra) to newly assigned dedicated resources (QA/Infra). Which of these models might work in your opinion? Which are doomed to failure, and why? So can you be more specific here on why you think adding more cross- project resources won't be enough to address an identified shortage of cross-project resources, while de-integrating projects would be? And, please, can we put the proverbial strawman back in its box on this thread? It's all well and good as a polemic device, but doesn't really move the discussion forward in a constructive way, IMO. Thanks, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Congress] Help in understanding API Flow
Hi Madhu,
If you are trying to expose data from a new service, you need to add a new
data-source driver (examples from nova and neutron are in the tree.) Once a
data-source driver is registered, data from the data source will be exposed
through the API automatically, and you will also be able to write policy based
on the data. (Note that using the current code in master your data source will
not be activated until it is referenced by a policy - a commit is in flight to
change that, however.)
If, instead, you are trying to expose non datasource data in the API, it would
involve implementing the DataModel interface (see api/webservice.py) and
binding it to a URI and handler in congress_server.py. If this is what you
want to do, please provide more details on what you are exposing and I can walk
you through it.
- Peter
From: Madhu Mohan mmo...@mvista.commailto:mmo...@mvista.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, August 14, 2014 at 2:54 AM
To: openstack-dev
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Congress] Help in understanding API Flow
Hi,
Can some one help me understand how an API is exposed to the clients from
Congress server ?
I see that a cage service ('api-policy') is created in congress_server.py.
I believe this is implemented in policy_model. I tried to send a json_request
from my client on the server.
I tried sending list_members, get_items, PUT and POST as methods and
all these give me NotImplemented error response.
Any help in this direction ?
I also want to add new APIs and hence understanding the API flow is crucial.
Thanks,
Madhu Mohan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree
Hi Sridar, Yes I know this is only for phase 1, while I'm also thinking about how it should be in next phase. At least, zone concept should be introduced, we may use it to replace SG, to eliminate potential conflicts of defining ACL in two different places. From: Sridar Kandaswamy (skandasw) [skand...@cisco.com] Sent: Thursday, August 14, 2014 10:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree Hi Wuhongning: Yes u are correct – this is phase 1 to at least get basic perimeter firewall support working with DVR before looking for an optimal way to address E – W traffic. Thanks Sridar From: Wuhongning wuhongn...@huawei.commailto:wuhongn...@huawei.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, August 14, 2014 at 1:05 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it can only handle NS traffic, leaving W-E untouched. If we implement the WE firewall in DVR, the iptable might be applied at a per port basis, so there are some overlapping with SG (Can we image a packet run into iptable hook twice between VM and the wire, for both ingress and egress directions?). Maybe the overall service plugins (including service extension in ML2) needs some cleaning up, It seems that Neutron is just built from separate single blocks. [1] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/neutron-dvr-fwaas.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Sahara] Swift authentication and backwards compatibility
hello Sahara folks, I am working to get the revamped spec[1] finalized and I'd like to know the group's thoughts on the idea of backward compatibility. It is possible to implement the new authentication method and remain backward compatible, but we will need to keep the username and password inputs in the Swift data forms. Having the backward compatibility would also give Sahara a way to react in situations where the proxy domain is not available or the administrator doesn't wish to use it. I'm not sure this is the behavior we want, but I don't know if it is proper for Sahara to exit if no proxy domain can be found. If we choose not to remain backward compatible then we are requiring Sahara operators to create the new proxy domain needed, and they must update all virtual machine images. Thoughts? regards, mike [1]: https://review.openstack.org/#/c/113591/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Python 3 support in os-*-config
Hai, I've been poking at Python 3 support in os-*-config recently, and here's what is going on with it: * os-apply-config This one looks to be the hardest one to port. Multiple test failures, hard coded use of '#!/usr/bin/env python' which is unhappy in a only Python 3 environment, map() changes, byte changes ... * os-cloud-config I have a patch to fix current Python 3 issues up (https://review.openstack.org/111606), and then my plan is to add Python 3 jobs to check *and* gate, so in-flight patches may need to watch out for that soon. * os-collect-config This needs six sprinkled throughout it due to URL parsing, and I need to work out what to do WRT absolute importing due to: File ./os_collect_config/collect.py, line 25, in module from openstack.common import log ImportError: No module named 'openstack' * os-net-config I know this isn't really a thing yet, but I also have yet to look into it's Python 3 support. * os-refresh-config This has Python 3 jobs running in check and gate. Does anyone have a small fix to test them out, the last code change that landed in os-refresh-config was mid July. Thanks, -- Steve I hate temporal mechanics! - Chief Miles O'Brien, Deep Space Nine ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
On Thu, Aug 14, 2014 at 9:07 PM, Kyle Mestery mest...@mestery.com wrote: I also feel like the drivers/plugins are currently BEYOND a tipping point, and are in fact dragging down velocity of the core project in many ways. I'm working on a proposal for Kilo where we move all drivers/plugins out of the main Neutron tree and into a separate git not all drivers/plugins, but most which are not built-in. For example, ML2 with ovs/linux/sriov MD and l2pop MD should be kept in tree as the default built-in backend, but all vendor specific MD and shim REST proxy like all kinds of SDN controller MD should be removed out. repository under the networking program. We have way too many drivers, requiring way too man review cycles, for this to be a sustainable model going forward. Since the main reason plugin/driver authors want their code upstream is to be a part of the simultaneous release, and thus be packaged by distributions, having a separate repository for these will satisfy this requirement. I'm still working through the details around reviews of this repository, etc. Also, I feel as if the level of passion on the mailing list has died down a bit, so I thought I'd send something out to try and liven things up a bit. It's been somewhat non-emotional here for a day or so. :) Thanks, Kyle On Thu, Aug 14, 2014 at 5:09 AM, Salvatore Orlando sorla...@nicira.com wrote: I think there will soon be a discussion regarding what the appropriate location for plugin and drivers should be. My personal feeling is that Neutron has simply reached the tipping point where the high number of drivers and plugins is causing unnecessary load for the core team and frustration for the community. There I would totally support Luke's initiative about maintaining an out-of-tree ML2 driver. On the other hand, a plugin/driver diaspora might also have negative consequences such as frequent breakages such as those Bob was mentioning or confusion for users which might need to end up fetching drivers from disparate sources. As mentioned during the last Neutron IRC meeting this is another process aspect which will be discussed soon, with the aim of defining a plan for: - drastically reduce the number of plugins and drivers which must be maintained in the main source tree - enhance control of plugin/driver maintainers over their own code - preserve the ability of doing CI checks on gerrit as we do today - raise the CI bar (maybe finally set the smoketest as a minimum requirement?) Regards, Salvatore On 14 August 2014 11:47, loy wolfe loywo...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. +1. It's better to move all MD for none built-in backend out of tree, maintaining these drivers shouldn't be the responsibility of community. Not only MD, but also plugin, agent should all obey this rule [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [neutron][ml2] Mech driver as out-of-tree add-on
I also feel like the drivers/plugins are currently BEYOND a tipping point, and are in fact dragging down velocity of the core project in many ways. Can you elaborate on the ways that they are slowing down the velocity? I know they take up reviewer time, but are there other ways that you think they slow down the project? On Thu, Aug 14, 2014 at 6:07 AM, Kyle Mestery mest...@mestery.com wrote: I also feel like the drivers/plugins are currently BEYOND a tipping point, and are in fact dragging down velocity of the core project in many ways. I'm working on a proposal for Kilo where we move all drivers/plugins out of the main Neutron tree and into a separate git repository under the networking program. We have way too many drivers, requiring way too man review cycles, for this to be a sustainable model going forward. Since the main reason plugin/driver authors want their code upstream is to be a part of the simultaneous release, and thus be packaged by distributions, having a separate repository for these will satisfy this requirement. I'm still working through the details around reviews of this repository, etc. Also, I feel as if the level of passion on the mailing list has died down a bit, so I thought I'd send something out to try and liven things up a bit. It's been somewhat non-emotional here for a day or so. :) Thanks, Kyle On Thu, Aug 14, 2014 at 5:09 AM, Salvatore Orlando sorla...@nicira.com wrote: I think there will soon be a discussion regarding what the appropriate location for plugin and drivers should be. My personal feeling is that Neutron has simply reached the tipping point where the high number of drivers and plugins is causing unnecessary load for the core team and frustration for the community. There I would totally support Luke's initiative about maintaining an out-of-tree ML2 driver. On the other hand, a plugin/driver diaspora might also have negative consequences such as frequent breakages such as those Bob was mentioning or confusion for users which might need to end up fetching drivers from disparate sources. As mentioned during the last Neutron IRC meeting this is another process aspect which will be discussed soon, with the aim of defining a plan for: - drastically reduce the number of plugins and drivers which must be maintained in the main source tree - enhance control of plugin/driver maintainers over their own code - preserve the ability of doing CI checks on gerrit as we do today - raise the CI bar (maybe finally set the smoketest as a minimum requirement?) Regards, Salvatore On 14 August 2014 11:47, loy wolfe loywo...@gmail.com wrote: On Thu, Aug 14, 2014 at 4:22 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, I would like to add that it would be harder for the community to help maintaining drivers. such a work [1] wouldn't have occured with an out of tree ODL driver. +1. It's better to move all MD for none built-in backend out of tree, maintaining these drivers shouldn't be the responsibility of community. Not only MD, but also plugin, agent should all obey this rule [1] https://review.openstack.org/#/c/96459/ On Wed, Aug 13, 2014 at 1:09 PM, Robert Kukura kuk...@noironetworks.com wrote: One thing to keep in mind is that the ML2 driver API does sometimes change, requiring updates to drivers. Drivers that are in-tree get updated along with the driver API change. Drivers that are out-of-tree must be updated by the owner. -Bob On 8/13/14, 6:59 AM, ZZelle wrote: Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
[openstack-dev] [OpenStack-Dev] [Cinder] Summer 2014 meetup summary
Hey Everyone, I wanted to send out a quick message regarding the Cinder Mid-Cycle (kinda) Meetup we just finished up at the Fort Collins HP Site. First off, I want to thank everyone who attended for a great and very productive three days!! Not only did we have a strong physical turn-out (16 participants) but we also had a good number of folks attend via Google HangOuts. We covered a lot of topics and details as a group. Agenda items ranged from collective review of new Cinder features for Juno (Pool-Scheduler, Consistency-Groups and Replication) to sharing approaches to third-party CI deployment and lessons learned. We also spent a good deal of time discussing future plans and ideas for Cinder. We had a great mix of folks, including long time core members, new contributors and everything inbetween. This even included representatives from the Infra Team as well as a guest appearance from the Horizon team. It was a great format and everybody really pulled together in an inclusive format to help accomplish quite a bit and set the tone for work to do in the upcoming Kilo release. Anyway, IMO it was a great effort and I really appreciate all those who participated. If you'd like more detail on the things that we discussed you can check out the etherpad which includes some of the nitty gritty details. Of course any questions or details for those that weren't present, drop in to the Cinder channel with any questions or ideas that you might have. Thanks, John https://etherpad.openstack.org/p/cinder-meetup-summer-2014 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] Object Model and DB Structure
So I've been assuming that the Octavia object model would be an exact copy of the neutron lbaas one with additional information for Octavia. However, after thinking about it I'm not sure this is the right way to go because the object model in neutron lbaas may change in the future, and Octavia can't just change it's object model when neutron lbaas/openstack lbaas changes it's object model. So if there are any lessons learned we would like to apply to Octavia's object model now is the time. Entity name changes are also on the table if people don't really like some of the names. Even adding new entities or removing entities if there are good reasons isn't out of the question. Anyway here are a few of my suggestions. Please add on to this if you want. Also, just flat out tell me I'm wrong on some of htese suggestions if you feel as such. A few improvements I'd suggest (using the current entity names): -A real root object that is the only top level object (loadbalancer). --This would be 1:M relationship with Listeners, but Listeners would only be children of loadbalancers. --Pools, Members, and Health Monitors would follow the same workflow. --Basically no shareable entities. -Provisioning status only on the root object (loadbalancer). --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a DEFEERRED status! YAY!) --Also maybe a DELETED status. -Operating status on other entities --ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members --Listeners have been mentioned but I'd like to hear more details on that. -Adding status_description field in, or something similar. Would only eixst on loadbalancer entity if loadbalancer is the only top level object. Thanks, Brandon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
