Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure
On Thu, Jun 20, 2013 at 7:31 AM, Dan Smith d...@danplanet.com wrote: Or, you can run dash.py, which will show you a personalized view of zuul: https://github.com/kk7ds/openstack-gerrit-dashboard Running it with a refresh of thirty seconds or so will give you status of your patches as they make their way through the queues, as well as early failure warning (in the form of a red line): This is really nice! Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag
Hi, I guess, the splitting point is defined by the hypervisor, so I guess that's a +1 for the config option. Does any other hypervisor have such a limit? If so, it would make sense to set it to the minimum of all those limits. Mate On Thu, Jun 20, 2013 at 06:02:44PM +0100, John Garbutt wrote: Hi, I have had some discussions about if I should add a config flag in this change: https://review.openstack.org/#/c/32760/ I am looking to support adding a large amount of ephemeral disk space to a VM, but the VHD format has a limit of around 2TB per disk. To work around this in XenServer, I plan to add several smaller disks to make up the full ephemeral disk space. To me it seems worth adding a configuration flag (in this case), because there is no easy way to guess the correct value, and there doesn't seem to be a great value to hardcode it to. Having said that, I suspect the default value will be all most people need, whether or not they have very large ephemeral disk space in their flavors. I am curious about what people think (in general, and in this case) about the tradeoff between: hardcode, magic heuristic calculation, add config John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Celery
On Fri, Jun 21, 2013 at 05:33:05PM +, Jessica Lucci wrote: Hello all, Included here is a link to a Celery wiki, explaining what the Celery project is and how it works. Currently, celery is being used in a distributed pattern for the WIP task flow project. As such, links to both the distributed project, and its' parent task flow project have been included for your viewing pleasure. Please feel free to ask any questions/address any concerns regarding either celery or the task flow project as a whole. (: Celery: https://wiki.openstack.org/wiki/Celery Distributed: https://wiki.openstack.org/wiki/DistributedTaskManagement TaskFlow: https://wiki.openstack.org/wiki/TaskFlow There was some discussion of Celery in #heat last week, and one question I have is re supported brokers, and qpid in particular. It appears from these pages that celery does not work with qpid, and is not a supported broker, can you confirm that is the case? http://docs.celeryproject.org/en/latest/getting-started/brokers/index.html https://github.com/celery/kombu/issues/54 Related question - if the TaskFlow effort is aiming to become a library in oslo, or an openstack project in its own right, are there plans to implement an oslo RPC transport driver for celery? Thanks! Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] A DB question for UniqueName/Event/Trait
Hi I am looking at ceilometer DB code. I find there are 3 tables (UniqueName, Event, Trait), and in Trait, the two columns name_id and event_id refer to table UniqueName and table Event. My question is why we need UniqueName and Event, because in both tables there are no many other columns, so why not fill unique_name into Trait directly. Thanks in advance. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack Programs
Hi everyone, Official OpenStack projects are those under the oversight of the Technical Committee, and contributing to one grants you ATC status (which in turn you use to elect the Technical Committee members). The list of official projects used to be simple (Swift+Nova) but nowadays it is rather convoluted, with categories like integrated, incubated, library, gating and supporting, as described in [1]. That complexity derived from the need to special-case some projects because their PTL would automatically get a TC seat. Now that we simplified the TC membership, we can also simplify official projects nomenclature by blessing the goals rather than the specific repositories. [1] https://wiki.openstack.org/wiki/Projects This is why Monty had the idea of programs which would be blessed by the TC (and then any code under an official program becomes official). Rather than trying to come up with categories that would cover all the stuff that the Infrastructure team is working on (gating, supporting, libraries...), just say that Infrastructure is a program and let them add any repo that they need. The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. That sounds like a pretty nice idea, so could we consider everything falls under the realm of a program ? Like having an integrated release program that would contain all integrated projects ? I think we need to keep special-casing a concept of projects, separated from programs, since those are accepted one by one by the TC and go through an incubation period. Those projects would contain at least one repo that wants to be part of the integrated, common OpenStack release, plus anything the same team works on (like the corresponding python client project). To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) New programs would draft a clear mission statement and apply to the TC for consideration. Programs should also expect to have a specific topic at the Design Summit (most of them already have), and should probably designate a lead/ambassador as a clear go-to person. A few questions I had left: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo, and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... * Where would devstack fall ? QA program ? Infrastructure program ? * Where would openstack/requirements fall ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] A DB question for UniqueName/Event/Trait
On 06/24/2013 04:49 AM, Wang, Shane wrote: Hi I am looking at ceilometer DB code. I find there are 3 tables (UniqueName, Event, Trait), and in Trait, the two columns name_id and event_id refer to table UniqueName and table Event. My question is why we need UniqueName and Event, because in both tables there are no many other columns, so why not fill unique_name into Trait directly. Thanks in advance. Hi Shane, The purpose of the separate UniqueName table, IIRC, is to reduce the footprint of the main Event and Trait tables. A smaller integer foreign key can be used instead of a larger string key. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Networking] Allocation of IPs
Here's the blueprint… https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation On Jun 21, 2013, at 5:34 PM, Edgar Magana emag...@plumgrid.com wrote: Mark, Can you point me to the BP for this feature? I want to keep an eye on it. Thanks, Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Friday, June 21, 2013 12:41 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There will be a deployment option where you can configure the default IP allocator. Additionally, the allocator will be configurable at subnet creation time. mark On Jun 20, 2013, at 4:51 PM, Edgar Magana emag...@plumgrid.com wrote: Could it be possible to add a flag to disable the allocation for the IP? If the no allocation flag is enabled, all ports will have an empty value for IPs. It will increase the config parameters in quantum, should we try it? Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 20, 2013 1:13 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There's work under way to make IP allocation pluggable. One of the options will include not having an allocator for a subnet. mark On Jun 20, 2013, at 2:36 PM, Edgar Magana emag...@plumgrid.com wrote: Developers, So far in Networking (formerly Quantum) IPs are pre-allocated when a new port is created by the following def: _allocate_ips_for_port(self, context, network, port): If we are using a real DHCP (not the dnsmasq process) that does not accept static IP allocation because it only allocates IPs based on its own algorithm, how can we tell Networking to not allocate an IP at all? I don’t think that is possible based on the code but I would like to know if somebody has gone through the same problem and have a workaround solution. Cheers, Edgar ___ 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.orghttp://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] [Infra] Meeting Tuesday June 25th at 19:00 UTC
The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday June 25th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cells design issue
On 06/21/2013 12:16 PM, Armando Migliaccio wrote: In my view a cell should only know about the queue it's connected to, and let the 'global' message queue to do its job of dispatching the messages to the right recipient: that would solve the problem altogether. Were federated http://www.rabbitmq.com/federation.html queues and topic routing http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/ not considered fit for the purpose? I guess the drawback with this is that it is tight to Rabbit. FWIW, qpid does this, too. It wouldn't be a rabbit specific approach. I also agree that this seems like a more natural approach and is worth exploring if someone wants to dig into it some more. -- 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] Adding a xenapi_max_ephemeral_disk_size_gb flag
On 06/21/2013 05:55 AM, John Garbutt wrote: Its just that the limit you want to set varies depending on the flavor. So flavor = 10TB, limit = 2000GB, the final disk is a bit of an odd size, maybe 1024GB would be a better split. Although you make a good point, maybe we should set the splitting point in extra specs in the flavor, rather than a config value. Sounds like it, if it's flavor specific anyway. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Thanks for kicking off this discussion! I think the idea of programs has fantastic promise. On Mon, Jun 24, 2013 at 2:50 AM, Thierry Carrez thie...@openstack.orgwrote: Hi everyone, Official OpenStack projects are those under the oversight of the Technical Committee, and contributing to one grants you ATC status (which in turn you use to elect the Technical Committee members). The list of official projects used to be simple (Swift+Nova) but nowadays it is rather convoluted, with categories like integrated, incubated, library, gating and supporting, as described in [1]. That complexity derived from the need to special-case some projects because their PTL would automatically get a TC seat. Now that we simplified the TC membership, we can also simplify official projects nomenclature by blessing the goals rather than the specific repositories. [1] https://wiki.openstack.org/wiki/Projects This is why Monty had the idea of programs which would be blessed by the TC (and then any code under an official program becomes official). Rather than trying to come up with categories that would cover all the stuff that the Infrastructure team is working on (gating, supporting, libraries...), just say that Infrastructure is a program and let them add any repo that they need. The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. That sounds like a pretty nice idea, so could we consider everything falls under the realm of a program ? Like having an integrated release program that would contain all integrated projects ? I think we need to keep special-casing a concept of projects, separated from programs, since those are accepted one by one by the TC and go through an incubation period. Those projects would contain at least one repo that wants to be part of the integrated, common OpenStack release, plus anything the same team works on (like the corresponding python client project). To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) New programs would draft a clear mission statement and apply to the TC for consideration. Programs should also expect to have a specific topic at the Design Summit (most of them already have), and should probably designate a lead/ambassador as a clear go-to person. A few questions I had left: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo Can you clarify this concern? Overall, folks would still be ATCs of the projects that they were committing on in the name of the given program, so their OpenStack ATC status would be successfully tracked regardless. Is the problem organizing leadership votes *within* the program? If so, could we settle on horizontal votes being extended to all OpenStack ATCs? or is that just too wide open? , and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... Can you give an example of the kind of vagueness you're worried about? Perhaps it is just a failure of my imagination, but I can't seem to conceive of a way a program mission statement would be distinctly more vague than a project mission statement. * Where would devstack fall ? QA program ? Infrastructure program ? * Where would openstack/requirements fall ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag
So in the current review, I have just gone for switching between 2000GB and 1024 GB. I figure we can try this simpler approach, and worry about generalizing it if people need it later. John On 24 June 2013 16:13, Russell Bryant rbry...@redhat.com wrote: On 06/21/2013 05:55 AM, John Garbutt wrote: Its just that the limit you want to set varies depending on the flavor. So flavor = 10TB, limit = 2000GB, the final disk is a bit of an odd size, maybe 1024GB would be a better split. Although you make a good point, maybe we should set the splitting point in extra specs in the flavor, rather than a config value. Sounds like it, if it's flavor specific anyway. -- Russell Bryant ___ 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] [Horizon[ Update on the realtime-communication blueprint
All, Presenting a new version of the proof of concept for the realtime-communication Horizon blueprint[0]. Here's the code: https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/realtime-communication,n,z Following the previous discussion, this iteration listens to the OpenStack notifications and passes them using websocket (or one of the fallbacks) to the connected browsers. That means adding oslo-incubator as a dependency (the RPC bits of it at least). The code grew a bit more complex, because as far as I can see, the RPC helpers in oslo-incubator are deeply intertwined with eventlet, but there is no suitable web realtime library built on top of eventlet*. The available solutions are built on top of gevent or tornado, both of which come with their own event loops. In order to both receive notifications and push them to the browsers, we need two separate threads, one for each event loop. We're only talking about a 150 lines of code and I don't expect it to grow much beyond that, so I'm not really worried about that now. But if there are better solutions, please share them. The original PoC was built on top of gevent and gevent-socketio, neither of which is likely to be Python3-compatible any time soon. Since that's a requirement for new dependencies, I've switched to Tornado[1] and SockJS-tornado[2] that are both compatible with Python 3. I didn't add the dependencies to openstack/requirements[3] yet but if you are fine with this stack, I shall do so and we can start thinking about merging this. To try it out, please run the server: ./horizon-realtime.py --config-file etc/horizon/horizon-realtime.conf navigate to `http://localhost:8080/project/instances` (you can verify the WebSocket connection in the JavaScript console) and then launch an instance out of band (e.g. via the nova command line). The webpage should update automatically when you add, suspend, resume or delete the instance. T. [0]: https://blueprints.launchpad.net/horizon/+spec/realtime-communication [1]: http://www.tornadoweb.org/en/stable/ [2]: https://github.com/mrjoes/sockjs-tornado [3]: https://github.com/openstack/requirements * eventlet ships with a WebSocket implementation, but it lacks the fallback transports, etc. that socket.io and SockJS provide. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Removing python-sendfile related code from BaseClient
I'm adding some unit tests for glance/common/client.py as part of bug/1115551, and noticed the image_iterator() function (https://github.com/openstack/glance/blob/master/glance/common/client.py#L568) returns two non-existent types, SendFileIterator and ImageBodyIterator. It seems there's no code path that goes down this route; would I be correct in assuming this is left over from the legacy glanceclient? I think there's two possible actions - one would be to remove this and related code that calls it from do_request. The other would be to restore these iterator classes back, so this functionality would still be supported if desired. Thoughts? Thanks, -Paul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
On 06/24/2013 05:50 AM, Thierry Carrez wrote: Hi everyone, Official OpenStack projects are those under the oversight of the Technical Committee, and contributing to one grants you ATC status (which in turn you use to elect the Technical Committee members). The list of official projects used to be simple (Swift+Nova) but nowadays it is rather convoluted, with categories like integrated, incubated, library, gating and supporting, as described in [1]. That complexity derived from the need to special-case some projects because their PTL would automatically get a TC seat. Now that we simplified the TC membership, we can also simplify official projects nomenclature by blessing the goals rather than the specific repositories. [1] https://wiki.openstack.org/wiki/Projects This is why Monty had the idea of programs which would be blessed by the TC (and then any code under an official program becomes official). Rather than trying to come up with categories that would cover all the stuff that the Infrastructure team is working on (gating, supporting, libraries...), just say that Infrastructure is a program and let them add any repo that they need. The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. That sounds like a pretty nice idea, so could we consider everything falls under the realm of a program ? Like having an integrated release program that would contain all integrated projects ? I think we need to keep special-casing a concept of projects, separated from programs, since those are accepted one by one by the TC and go through an incubation period. Those projects would contain at least one repo that wants to be part of the integrated, common OpenStack release, plus anything the same team works on (like the corresponding python client project). To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) New programs would draft a clear mission statement and apply to the TC for consideration. Programs should also expect to have a specific topic at the Design Summit (most of them already have), and should probably designate a lead/ambassador as a clear go-to person. Thank you for describing the idea very well! I specifically like the idea of a program proposal drafting a mission statement and having a PTL. (infra and oslo both do PTLs, so I think it's a fair thing to except other programs to as well) A few questions I had left: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo, and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... I'd actually like to revisit this question as a separate thing. Honestly, I want to see bug work and review work as part of the ATC calculation. Seriously - both are hard and thankless. I think those are really the only two places where work on the above stuff can 'fall through the cracks' by potentially not having a 'patch'. * Where would devstack fall ? QA program ? Infrastructure program ? I think it's honestly a joint-venture between QA and Infra (especially if you consider developer tooling to fall into the infra umbrella - which is where it traditionally has fallen) But I'd say it's more primarily Infra and we use it for QA, rather than the other way around (as someone said the other day - it's devstack, not teststack or tempeststack) * Where would openstack/requirements fall ? I think openstack/requirements sits under oslo - although right now it's a joint-venture between oslo and infra. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] AMQP Version upgrade plans?
OpenStack currently uses AMQP 0.8. Are there any plans to upgrade? Thank you, Sunjeet ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] AMQP Version upgrade plans?
On 06/24/2013 02:01 PM, Sunjeet Singh wrote: OpenStack currently uses AMQP 0.8. Are there any plans to upgrade? OpenStack is not specifically tied to an AMQP version. It's more about what clients we have support for, what versions they speak, and then what message brokers support that. Right now we have support for using the kombu (for RabbitMQ) and qpid (for Qpid) clients. I actually have a big interest in adding support for AMQP 1.0. One of the *really* interesting things with AMQP 1.0 that is relevant for OpenStack is that it is not tied to using a message broker. You can use it in both a peer-to-peer and a brokered way. This is interesting, because depending on the messaging pattern we're using, we may want one vs the other in different parts of OpenStack. As for the specifics to doing this, the only AMQP 1.0 client I know of is Proton. It does have Python bindings. http://qpid.apache.org/proton/ As for the server side, ActiveMQ recently added AMQP 1.0 support using this same library (proton). http://activemq.apache.org/ -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] resize confirm broken on XenServer
Just started seeing these in SmokeStack: https://bugs.launchpad.net/nova/+bug/1194264 I pushed a revert which should fix the issue: https://review.openstack.org/#/c/34256/ Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] bug 1189711 Should RPC consume_in_thread() be more fault tolerant?
The code review for this change is I0d6ec8a5: Make AMQP based RPC consumer threads more robust: https://review.openstack.org/#/c/32235/ There is a need for more reviewers, since there are some questions surrounding the implementation and whether mox is being used appropriately for the unit test cases. Thanks, Ray ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Termination of the title line of commit messages
Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) I missed this point: Also not that space is limited to 50 characters by choice, not necessity (the very same external reference about git commit messages pointed out that 50 is not a hard limit). It is a hard limit for us... because we chose to make it so. It's another pretty common git usage convention - I think the idea is to make output like 'git log --oneline' fit on 80 char terminals. The numbers don't add up, though, so maybe it's another thing from the git-via-email world. Also, the idea is probably to take into account that the first line can be quoted by e.g. 'Merge foo' or 'Revert foo' in the first line of other commit messages. Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On 06/24/2013 05:56 PM, Mark McLoughlin wrote: On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) I missed this point: Also not that space is limited to 50 characters by choice, not necessity (the very same external reference about git commit messages pointed out that 50 is not a hard limit). It is a hard limit for us... because we chose to make it so. It's another pretty common git usage convention - I think the idea is to make output like 'git log --oneline' fit on 80 char terminals. The numbers don't add up, though, so maybe it's another thing from the git-via-email world. Also, the idea is probably to take into account that the first line can be quoted by e.g. 'Merge foo' or 'Revert foo' in the first line of other commit messages. Long commit messages also look like poop in gerrit, and I don't think anyone cares enough about bucking this style thing to go write Java to fix it. 50 chars is common enough that vim syntax highlighting groks it. I see no reason to choose a different thing. Why 50? NO CLUE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On 06/24/2013 06:15 PM, Monty Taylor wrote: On 06/24/2013 05:56 PM, Mark McLoughlin wrote: On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) I missed this point: Also not that space is limited to 50 characters by choice, not necessity (the very same external reference about git commit messages pointed out that 50 is not a hard limit). It is a hard limit for us... because we chose to make it so. It's another pretty common git usage convention - I think the idea is to make output like 'git log --oneline' fit on 80 char terminals. The numbers don't add up, though, so maybe it's another thing from the git-via-email world. Also, the idea is probably to take into account that the first line can be quoted by e.g. 'Merge foo' or 'Revert foo' in the first line of other commit messages. Long commit messages also look like poop in gerrit, and I don't think anyone cares enough about bucking this style thing to go write Java to fix it. 50 chars is common enough that vim syntax highlighting groks it. I see no reason to choose a different thing. Why 50? NO CLUE As long as it gets auto enforced in hacking, I'll adapt to whatever. I admit I've been bleeding my first line to 72 characters recently as I wasn't sure we were still enforcing at 50. But I'm adaptable to 50. Makes you get to the point with that first line. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New BP - ServiceId binding with role definition
All, Added etherpad link, please share your comments or suggestion https://etherpad.openstack.org/serviceid-binding-with-role-definition Arvind From: Tiwari, Arvind Sent: Wednesday, June 19, 2013 4:42 PM To: OpenStack Development Mailing List Subject: New BP - ServiceId binding with role definition All, I have added a new BP, which advocates service id binding with role definition https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition Please look at it and share your comments. Arvind ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On Mon, Jun 24, 2013 at 3:19 PM, Sean Dague s...@dague.net wrote: On 06/24/2013 06:15 PM, Monty Taylor wrote: On 06/24/2013 05:56 PM, Mark McLoughlin wrote: On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/**33262https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/**33789https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/**wiki/GitCommitMessages#** Summary_of_GIT_commit_message_**structurehttps://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/**19/a-note-about-git-commit-** messages.htmlhttp://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.htmldoesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) I missed this point: Also not that space is limited to 50 characters by choice, not necessity (the very same external reference about git commit messages pointed out that 50 is not a hard limit). It is a hard limit for us... because we chose to make it so. It's another pretty common git usage convention - I think the idea is to make output like 'git log --oneline' fit on 80 char terminals. The numbers don't add up, though, so maybe it's another thing from the git-via-email world. Also, the idea is probably to take into account that the first line can be quoted by e.g. 'Merge foo' or 'Revert foo' in the first line of other commit messages. Long commit messages also look like poop in gerrit, and I don't think anyone cares enough about bucking this style thing to go write Java to fix it. 50 chars is common enough that vim syntax highlighting groks it. I see no reason to choose a different thing. Why 50? NO CLUE As long as it gets auto enforced in hacking, I'll adapt to whatever. I admit I've been bleeding my first line to 72
Re: [openstack-dev] Termination of the title line of commit messages
On 06/24/2013 06:19 PM, Sean Dague wrote: On 06/24/2013 06:15 PM, Monty Taylor wrote: On 06/24/2013 05:56 PM, Mark McLoughlin wrote: On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: Hey, Pulling this out of gerrit for discussion. Background is one of my patches to diskimage-builder was -1ed because I terminated the title line of the commit message with a period: https://review.openstack.org/33262 This is actually the exact opposite to what I consider normal practice for git commit messages as I explained in the review and the tripleo wiki page, so I proposed a hacking change here: https://review.openstack.org/33789 The rationale for *not* having a period is: * With the 50 char limit, space is at a premium on the first line * The first line is often used as the Subject: in [PATCH] emails - subject lines in emails generally don't end in a period * Examples in: https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure don't end in period (Note - the should not end with a period was only added by me recently) * Another common reference on git commit messages http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn't either * In git's own git repo, 1.43% of commit messages in the last year ended in a period * I'm not aware of any other OpenStack project which enforces this. Looking at the history of various projects for the past year (and excluding merge commits which don't end with a period), the use of period termination runs at between 10 and 30%. Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. Now, for Robert's comments in the review: It would have been nice for this to be discussed rather than dropping into the communal standards without warning; I tried my best do explain why period termination is broken in the diskimage-builder review and wiki page, so it's not like I was trying to avoid a discussion. In any case, if I, jogo and sdague got this wrong somehow, the mistake is only a git-revert away from being corrected. the prior documentation *did not* require a period, Yes, but the examples didn't use a period which obviously means a policy to *require* a period is a bit bizarre. I'm pretty confident that danpb didn't mention this when he wrote the page because he either felt it was obvious or not worth mentioning. I've cc-ed him to be sure. and the reference that was sourced that doesn't use them is one in the git-via-email world which is not how OpenStack does *any* of it's git communications, so the 'gets used like subject line of emails' point is entirely irrelevant. git was born came from a git-via-email world and its usage conventions reflect that. I raised the subject line point to try and explain how git conventions may have arisen. In TripleO we have been using a period because the first line of the commit message acts like the first line of a docstring: it is a pithy description of the object it describes. Docstrings are also space limited, and yet PEP8 happily requires good sentence structure and grammar there. It's not a docstring, though. It's a git commit message. tl;dr - this is an unpythonic change, and the lack of discussion is quite annoying. Well, the former point is irrelevant and hopefully this email corrects the latter point :) I missed this point: Also not that space is limited to 50 characters by choice, not necessity (the very same external reference about git commit messages pointed out that 50 is not a hard limit). It is a hard limit for us... because we chose to make it so. It's another pretty common git usage convention - I think the idea is to make output like 'git log --oneline' fit on 80 char terminals. The numbers don't add up, though, so maybe it's another thing from the git-via-email world. Also, the idea is probably to take into account that the first line can be quoted by e.g. 'Merge foo' or 'Revert foo' in the first line of other commit messages. Long commit messages also look like poop in gerrit, and I don't think anyone cares enough about bucking this style thing to go write Java to fix it. 50 chars is common enough that vim syntax highlighting groks it. I see no reason to choose a different thing. Why 50? NO CLUE As long as it gets auto enforced in hacking, I'll adapt to whatever. I admit I've been bleeding my first line to 72 characters recently as I wasn't sure we were still enforcing at 50. But I'm adaptable to 50. Makes you get to the point with that first line. I actually had a gerrit patch a while ago that would allow you to set a project to reject uploads with too-long subject lines.
Re: [openstack-dev] Termination of the title line of commit messages
On Jun 24, 2013, at 2:50 PM, Mark McLoughlin wrote: Unlike other nitpicking I tend to do with commit messages, I previously never thought this was worth even mentioning to committers but if some reviewers were going to start -1ing people for the *correct* style then I figured it was best to clear it up. I too have never thought it worth mentioning, similar to capitalizing the first word of the first line of the commit message or not. I thought any way works, as long as the first line is brief so it shows up nicely browsing on github. Personally, I treat the first line like you mention the subject line of an email, which I never capitalize or use a period at the end. Melanie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] defaults: making OpenStack work out of the box.
On 05/29/2013 08:48 AM, Doug Hellmann wrote: On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: On the other hand, we're finding a large chunk of the work we're doing is changing defaults. If we were changing them down from 'this works for prod clouds' to 'this works for a test cloud' - that would be fine. But we're changing them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger quotas for end users. Another large chunk of the bring up is determining private network details w/in Quantum - something that isn't (typically) exposed to either the real world *or* other machines w/in the datacentre. So I find myself asking two questions: a) why aren't the defaults suitable for production? Where they are not suitable, it's just friction waiting to trip new deployers up. b) perhaps we can document - or even automate - some defaults for things like Quantum topology, which will work ok everywhere, and which we can tell folk who are just getting going 'follow this, it will work well enough for you to get experience with the rest of the system'.. Default values always target a specific use case, as for some parameters there is just no default value that works for most cases. The trick is to define a target use case for your defaults, and not have half the default values care for a all-in-one while the others care for a thousand nodes deployment. You'll always create friction for some categories of users, but at least it should be a consistent friction :) Alternatively you can ship multiple sets of defaults (I remember MySQL doing this for some time) if it's difficult to get documentation to cover the various use cases. These went stale very quickly... It's easy for developers to override the defaults to work for all-in-one deployments via devstack. We should try to make the baked-in defaults more useful for non-development use cases. Perhaps the defaults should work for a moderate size with a few compute nodes (someone should suggest a specific number), which would make them useful for proof-of-concept setups. We can also ship separate example files for large deployments, as you suggest. I'm going to suggest a moderate size default suggestion. What if our defaults are sensible for a single rack of gear? It seems to be a common enough unit of measure - and having a rack-sized set of defaults on a couple of machines probably won't kill much. OTOH - if you're doing a data center, there is NO WAY you're going to not configure something. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] defaults: making OpenStack work out of the box.
On Mon, Jun 24, 2013 at 6:46 PM, Monty Taylor mord...@inaugust.com wrote: On 05/29/2013 08:48 AM, Doug Hellmann wrote: On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: On the other hand, we're finding a large chunk of the work we're doing is changing defaults. If we were changing them down from 'this works for prod clouds' to 'this works for a test cloud' - that would be fine. But we're changing them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger quotas for end users. Another large chunk of the bring up is determining private network details w/in Quantum - something that isn't (typically) exposed to either the real world *or* other machines w/in the datacentre. So I find myself asking two questions: a) why aren't the defaults suitable for production? Where they are not suitable, it's just friction waiting to trip new deployers up. b) perhaps we can document - or even automate - some defaults for things like Quantum topology, which will work ok everywhere, and which we can tell folk who are just getting going 'follow this, it will work well enough for you to get experience with the rest of the system'.. Default values always target a specific use case, as for some parameters there is just no default value that works for most cases. The trick is to define a target use case for your defaults, and not have half the default values care for a all-in-one while the others care for a thousand nodes deployment. You'll always create friction for some categories of users, but at least it should be a consistent friction :) Alternatively you can ship multiple sets of defaults (I remember MySQL doing this for some time) if it's difficult to get documentation to cover the various use cases. These went stale very quickly... It's easy for developers to override the defaults to work for all-in-one deployments via devstack. We should try to make the baked-in defaults more useful for non-development use cases. Perhaps the defaults should work for a moderate size with a few compute nodes (someone should suggest a specific number), which would make them useful for proof-of-concept setups. We can also ship separate example files for large deployments, as you suggest. I'm going to suggest a moderate size default suggestion. What if our defaults are sensible for a single rack of gear? It seems to be a common enough unit of measure - and having a rack-sized set of defaults on a couple of machines probably won't kill much. OTOH - if you're doing a data center, there is NO WAY you're going to not configure something. +1 -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On Mon, Jun 24, 2013 at 5:36 PM, Christopher Yeoh cbky...@gmail.com wrote: On Tue, Jun 25, 2013 at 7:56 AM, Joe Gordon joe.gord...@gmail.com wrote: As long as it gets auto enforced in hacking, I'll adapt to whatever. I admit I've been bleeding my first line to 72 characters recently as I wasn't sure we were still enforcing at 50. But I'm adaptable to 50. Makes you get to the point with that first line. FWIW we say 50 and enforce 72 ( https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L778 ). I'd prefer 72 than 50. I thought it was enforced at 50 and so there's been few changes I've submitted recently where I've resorted to dropping vowels to make it fit. My preference also would be there to be no period at the end Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Shorter the better IMO, I'd prefer we leave it alone but I've got enough to work on that I'll just go with the flow if everyone decides to change it. I'd prefer to have more concise summaries when browsing changes. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Nova scheduler sub-group meeting agenda 6/25
1) Follow ups on the scheduler BPs 2) Opens? Not really much on the agenda for this week, we'll probably have a short meeting (I'm still studying the scheduler's use of fan-out messages and the DB, I'll want to go over that in more detail once I complete my study). PS: The list of scheduler BPs is: 1) Extending data in host state 2) Utilization based scheduling 3) Whole host allocation capability 4) Coexistence of different schedulers 5) Rack aware scheduling 6) List scheduler hints via API 7) Host directory service 8) The future of the scheduler 9) Network bandwisth aware scheduling (and wider aspects) 10) ensembles/vclusters -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Sample config file location inconsistency
Hi team I'm currently trying to move the generate_sample.sh script in nova to oslo. Before pushing the patch to gerrit, I wanted to give the output directory a default value if it was not stated so I was wondering where projects put their sample config file at and did this: find . -name *.conf* ! -path *.tox* ! -path *.venv* | grep etc results: ./ceilometer/etc/ceilometer/ceilometer.conf.sample ./cinder/etc/cinder/cinder.conf.sample ./nova/etc/nova/nova.conf.sample ./swift/etc/swift.conf-sample ./tempest/etc/tempest.conf.sample ./glance/etc/glance-cache.conf ./quantum/etc/quantum.conf ./keystone/etc/keystone.conf.sample You can see that ceilometer, cinder, and nova put their sample config files on ./etc/$PROJECTNAME while the others put it on ./etc So would this inconsistency be a problem? IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue. Thoughts? -- *Intel SSG/STOD/DCST/CIT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Termination of the title line of commit messages
On 25 June 2013 15:34, Joe Gordon joe.gord...@gmail.com wrote: This is exactly why we want a consensus, so we can automatically enforce it without using any human resources (at least during the review process). If we say we don't care, someone will come along and care. If we enforce one option, if someone disagrees the gate will tell them they are wrong. Not caring is a valid consensus; if the wiki page had said we explicitly don't care, I would have raised enforcing proper sentence structure in the first line here. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ 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 API Web Framework Change
On Mon, Jun 24, 2013 at 11:53 PM, John Griffith john.griff...@solidfire.com wrote: All, I wanted to loop the larger community in on some discussions that have been taking place on #openstack-cinder. During the Summit we talked about switching to Pecan for our API/Web framework. Since then we've registered a BP [1] and some pretty good progress has been made. Since starting this effort however we've been debating the best way to implement this change: 1. Replace existing WSGI framework in the existing API versions In my opinion there's a bit of risk here with changing the entire framework tha the API is built on, and even though I'm confident this can be done I'm not sure of the return on the investment and really I don't see anything that compelling when you consider all of the changes in not only the API code but in the unit tests that would be affected. 2. Bump to a new API version and isolate the changes to that new version This is my preference and IMO the right way to go, however there's no driving need for another API version bump in Cinder currently. I personally don't like the idea of bumping the API version for every release, even if we're keeping things stable and maintaining backward compatibility without issues. For me there isn't an overly compelling reason to justify this change for the H release. My plan is to go with option #2, and to push this change out until the I release. I'd like to know if anybody has strong feelings or justifications that we should consider on this before moving forward. Thanks, John I've been involved with the discussions with John and was originally the person that proposed the pecan switch back at the Havana summit for Cinder in my session: https://etherpad.openstack.org/havana-cinder-api2-a-new-hope I've been writing compatibility for both v1 and v2 in pecan/wsme and while I would absolutely love to see the wsgi implementation code go and xml serializing/deserializing code go, as John mentioned, I don't think it's worth it right now. It just took me writing around 5K lines of code to realize it. Sort of reiterating John's points, there's a few reasons why I think we should wait for v3: 1) We'd likely drop v1 support in that release, so we don't have to worry about it anymore. 2) Make reviewing a lot easier since it's not one big commit that changes all controllers and tests. Instead have v3 be introduced using pecan with a commit for each controller and tests. Eventually allow v3 to be served by cinder-api in the ending commit. 3) v2 controller code and tests don't have to be updated to use pecan. v2 will continue to use paste and v3 will use pecan. This is the same approach that Ceilometer has done from Flask to Pecan and it's working out great. With all that said, I don't want a version bump either for just a framework switch, as we just did v2 last release. v3 will be needed soon and once that happens, I'll already be ready with core API controllers I already switched over to Pecan. -Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Networking] Question on portbinding
Hello All, While going through the portbinding extension I noticed that a patch has been proposed for calls from nova to checks and updates the port binding attributes for a plugin which supports this extension. https://review.openstack.org/#/c/29767/ While going through the code, I don't see the same changes for dhcp and l3 agents. These agents while creating ports don't provide portbinding attributes. Am I missing something ? Thanks Chandan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
