[openstack-dev] [Neutron] Allow multiple subnets on gateway port for router
Hi, With regards to https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port, can you please clarify this statement: We will disallow more that two subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets. The use case for dual-stack with one IPv4 and one IPv6 address associated to the same port is clear, but what is the reason to disallow more than two IPv4/IPv6 subnets to a port? Thanks and happy holidays! Nir ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Turbo-hipster
Hi, It seems that she/he is behaving oddly again. I have posted a patch that does not have any database changes and it has give me a –1…. Happy new year Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove] Proposal to add Auston McReynolds to trove-core
+1 On Dec 30, 2013, at 1:13 PM, Vipul Sabhaya vip...@gmail.com wrote: +1 Sent from my iPhone On Dec 30, 2013, at 10:50 AM, Craig Vyvial cp16...@gmail.com wrote: +1 On Mon, Dec 30, 2013 at 12:00 PM, Greg Hill greg.h...@rackspace.com wrote: +1 On Dec 27, 2013, at 4:48 PM, Michael Basnight mbasni...@gmail.com wrote: Howdy, Im proposing Auston McReynolds (amcrn) to trove-core. Auston has been working with trove for a while now. He is a great reviewer. He is incredibly thorough, and has caught more than one critical error with reviews and helps connect large features that may overlap (config edits + multi datastores comes to mind). The code he submits is top notch, and we frequently ask for his opinion on architecture / feature / design. https://review.openstack.org/#/dashboard/8214 https://review.openstack.org/#/q/owner:8214,n,z https://review.openstack.org/#/q/reviewer:8214,n,z Please respond with +1/-1, or any further comments. ___ 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] [trove][mistral] scheduled tasks
Agreed taskflow doesn't currently provide scheduling as it was thought that reliable execution that can be restarted and resumed is the foundation that someone using taskflow can easily provide scheduling ontop of... Better IMHO to have a project doing this foundation well (since openstack would benefit from this) than try to pack so many features in that it does none of them well (this kind of kitchen sink approach seems to happen more often than not, sadly). But in reality it's all about compromises and finding the solution that makes sense and works, and happy new year!! :P Sent from my really tiny device... On Dec 30, 2013, at 9:03 PM, Renat Akhmerov rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote: Greg, Georgy is right. We’re now actively working on PoC and we’ve already implemented the functionality we initially planned, including cron-based scheduling. You can take a look at our repo and evaluate what we’ve done, we’d be very glad to hear some feedback from anyone potentially interested in Mistral. We were supposed to deliver PoC in the end of December, however, we decided not to rush and include several really cool things that we came up with while working on PoC, they should demonstrate the whole idea of Mistral much better and expose functionality for more potential use cases. A couple of days ago I sent out the information about additional changes in DSL that we want to implement (etherpad: https://etherpad.openstack.org/p/mistral-poc), so if you’d like please join the discussion and let us know how we can evolve the project to better fit your needs. In fact, even though we call it PoC it’s already in a good shape and pretty soon (~1.5 month) is going to be mature enough to use it as a dependency for other projects. As far as security, we thought about this and and we have a vision of how it could be implemented. Generally, later on we’re planning to implement sort of Role Based Access Control (RBAC) to, first of all, isolate user workbooks (definition of tasks, actions, events) from each other and deal with access patterns to OpenStack services. We would encourage you to file a BP with a description of what would be needed by Trove in that regard. I looked at https://wiki.openstack.org/wiki/Trove/scheduled-tasks and at the first glance Mistral looks a good fit here, especially if you’re interested in a standalone REST service with its capabilities like execution monitoring, history, language independence and HA (i.e. you schedule backups via Mistral and Trove itself shouldn’t care about availability of any functionality related to scheduling). TaskFlow may also be helpful in case your scheduled jobs are representable as flows using one of TaskFlow patterns. However, in my understanding you’ll have to implement scheduling yourself since TaskFlow does not support it now, at least I didn’t find anything like that (Joshua can provide more details on that). Thanks. Renat Akhmerov @Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router
Hi Nir Good question. There's absolutely no reason not to allow more than 2 subnets, or even 2 of the same IP versions on the gateway port. In fact, in our POC we allowed this (or, more specifically, we did not disallow it). However, for the gateway port to the provider's next-hop router, we did not have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron today, only a single subnet is allowed per interface (either v4 or v6). So all we are doing is opening up the gateway port to support what it does today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the gateway port (and same network/vlan). Our principle use case is to enable IPv6 in an existing IPv4 environment. Do you have a specific use case requiring 2 or more of the same IP-versioned subnets on a gateway port? Thanks Randy On Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel nyech...@redhat.com wrote: Hi, With regards to https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port,can you please clarify this statement: We will disallow more that two subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets. The use case for dual-stack with one IPv4 and one IPv6 address associated to the same port is clear, but what is the reason to disallow more than two IPv4/IPv6 subnets to a port? Thanks and happy holidays! Nir ___ 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] [OpenStack-Dev] IDE extensions in .gitignore
Hey Everyone, I wanted to see where we stand on IDE extensions in .gitignore files. We seem to have some back and forth, one cycle there's a bug and a patch to add things like eclipse, idea etc and the next there's a bug and a patch to remove them. I'd like to have some sort of consensus on what we want here. I personally don't have a preference, I would just like to have consistency and quit thrashing back and forth. Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 2013-12-31 09:45:38 -0700 (-0700), John Griffith wrote: [...] Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? Personal opinion, the per-project .gitignore should be reserved exclusively for autogenerated artifacts tools and scripts embedded in the source (AUTHORS, dist, cover) or ephemeral files created by tools which are part of the documented and recommended workflow (.tox, .testrepository). The place for ignoring files created by your preferred tools (editors, IDEs) is within your own ~/.gitconfig instead... you can even set core.excludesfile to something like ~/.gitignore if you want to inherit common exclusions from a separate file. As for a global .gitignore synchronized across all projects, I think this is not likely to work well. Consider, as an example, that some projects may want ChangeLog autogenerated by PBR from the Git commit log while others prefer to hand-curate their ChangeLog file instead. The first project will want ChangeLog listed in .gitignore while the second will want it to actually get checked into the repo. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 8:45 AM, John Griffith john.griff...@solidfire.comwrote: Hey Everyone, I wanted to see where we stand on IDE extensions in .gitignore files. We seem to have some back and forth, one cycle there's a bug and a patch to add things like eclipse, idea etc and the next there's a bug and a patch to remove them. I'd like to have some sort of consensus on what we want here. I personally don't have a preference, I would just like to have consistency and quit thrashing back and forth. Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. John ___ 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] IDE extensions in .gitignore
I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. I hereby +1 this I think we should just remove all editors specifics in .gitignore and leave it to the user to set this up which would be useful for him as well on other projects (i.e: not openstack) that doesn't have such .gitignore . Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 10:07 AM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, Dec 31, 2013 at 8:45 AM, John Griffith john.griff...@solidfire.com wrote: Hey Everyone, I wanted to see where we stand on IDE extensions in .gitignore files. We seem to have some back and forth, one cycle there's a bug and a patch to add things like eclipse, idea etc and the next there's a bug and a patch to remove them. I'd like to have some sort of consensus on what we want here. I personally don't have a preference, I would just like to have consistency and quit thrashing back and forth. Anyway, I'd like to see all of the projects agree on this... or even consider moving to a global .gitignore. Thoughts?? I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Yep Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. Exactly John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][mistral] scheduled tasks
I guess this isn't a new discussion. I did some more digging and apparently this is what came out of the last discussion: https://wiki.openstack.org/wiki/EventScheduler That definitely seems like it would be something simple we could use, since it only provides scheduling and that's all we need, but it doesn't appear that it's had any traction since that time. I guess that got absorbed along with Convection into Mistral (is that right?). I tend to agree with the sentiment that the scheduling component should live outside the workflow service, especially for use cases like this where we just need scheduling and not the workflow portions as we're just scheduling things that are already achievable via single API calls (to my knowledge). It seems like we basically have 4 options at this point: 1. Wait for/help finish the scheduling component of mistral and use that 2. Build Qonos workers to do the trove needful and integrate with that 3. Build this proposed EventScheduler thing and have trove use that 4. Build something simple internal to trove for now and revisit when things have matured more Despite my initial enthusiasm about Qonos after it was mentioned earlier today, the more I look into it, the more it seems like the wrong fit. It could definitely do it, but the way it's structured, it appears that we'd have to add code to qonos/worker for each action we wanted to schedule, which just seems like a pain for what amounts to make this API call to trove. My gut says working on EventScheduler is probably the best/most ideal option, but time constraints and what-not make build it into trove the most likely course of action for now. Greg On Dec 31, 2013, at 10:06 AM, Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote: Agreed taskflow doesn't currently provide scheduling as it was thought that reliable execution that can be restarted and resumed is the foundation that someone using taskflow can easily provide scheduling ontop of... Better IMHO to have a project doing this foundation well (since openstack would benefit from this) than try to pack so many features in that it does none of them well (this kind of kitchen sink approach seems to happen more often than not, sadly). But in reality it's all about compromises and finding the solution that makes sense and works, and happy new year!! :P Sent from my really tiny device... On Dec 30, 2013, at 9:03 PM, Renat Akhmerov rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote: Greg, Georgy is right. We’re now actively working on PoC and we’ve already implemented the functionality we initially planned, including cron-based scheduling. You can take a look at our repo and evaluate what we’ve done, we’d be very glad to hear some feedback from anyone potentially interested in Mistral. We were supposed to deliver PoC in the end of December, however, we decided not to rush and include several really cool things that we came up with while working on PoC, they should demonstrate the whole idea of Mistral much better and expose functionality for more potential use cases. A couple of days ago I sent out the information about additional changes in DSL that we want to implement (etherpad: https://etherpad.openstack.org/p/mistral-poc), so if you’d like please join the discussion and let us know how we can evolve the project to better fit your needs. In fact, even though we call it PoC it’s already in a good shape and pretty soon (~1.5 month) is going to be mature enough to use it as a dependency for other projects. As far as security, we thought about this and and we have a vision of how it could be implemented. Generally, later on we’re planning to implement sort of Role Based Access Control (RBAC) to, first of all, isolate user workbooks (definition of tasks, actions, events) from each other and deal with access patterns to OpenStack services. We would encourage you to file a BP with a description of what would be needed by Trove in that regard. I looked at https://wiki.openstack.org/wiki/Trove/scheduled-tasks and at the first glance Mistral looks a good fit here, especially if you’re interested in a standalone REST service with its capabilities like execution monitoring, history, language independence and HA (i.e. you schedule backups via Mistral and Trove itself shouldn’t care about availability of any functionality related to scheduling). TaskFlow may also be helpful in case your scheduled jobs are representable as flows using one of TaskFlow patterns. However, in my understanding you’ll have to implement scheduling yourself since TaskFlow does not support it now, at least I didn’t find anything like that (Joshua can provide more details on that). Thanks. Renat Akhmerov @Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [nova] Turbo-hipster
Hi. So while turbo hipster is new, I've been reading every failure message it produces to make sure its not too badly wrong. There were four failures posted last night while I slept: https://review.openstack.org/#/c/64521 This one is a TH bug. We shouldn't be testing stable branches. bug/1265238 has been filed to track this. https://review.openstack.org/#/c/61753 This is your review. The failed run's log is https://ssl.rcbops.com/turbo_hipster/logviewer/?q=/turbo_hipster/results/61/61753/8/check/gate-real-db-upgrade_nova_percona_user_001/1326092/user_001.log and you can see from the failure message that migrations 152 and 206 took too long. Migration 152 took 326 seconds, where our historical data of 2,846 test migrations says it should take 222 seconds. Migration 206 took 81 seconds, where we think it should take 56 seconds based on 2,940 test runs. Whilst I can't explain why those migrations took too long this time around, they are certainly exactly the sort of thing TH is meant to catch. If you think your patch isn't responsible (perhaps the machine is just being slow or something), you can always retest by leaving a review comment of recheck migrations. I have done this for you on this patch. https://review.openstack.org/#/c/61717 This review also had similar unexplained slowness, but has already been rechecked by someone else and now passes. I note that the slowness in both cases was from the same TH worker node, and I will keep an eye on that node today. https://review.openstack.org/#/c/56420 This review also had slowness in migration 206, but has been rechecked by the developer and now passes. It wasn't on the percona-001 worker that the other two were on, so perhaps this indicates that we need to relax the timing requirements for migration 206. Hope this helps, Michael On Wed, Jan 1, 2014 at 12:34 AM, Gary Kotton gkot...@vmware.com wrote: Hi, It seems that she/he is behaving oddly again. I have posted a patch that does not have any database changes and it has give me a –1…. Happy new year Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore
On 1 January 2014 06:07, Joe Gordon joe.gord...@gmail.com wrote: I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. This is a strawman argument: noone (that I know of) has proposed adding all editors to all repositories. There are in reality a few very common editors and having their extensions present in per repository .gitignores does absolutely *no harm*. There is no reason not to have sane and sensible defaults in our repositories. If we are wasting time adding and removing patterns, then I think that counts as a harm, so it is a sensible discussion to have to come to a project standard, but the standard should be inclusive and useful, not just useful for power users that have everything setup 'just so'. Many contributors are using git for the first time when they contribute to OpenStack, and getting git setup correctly is itself daunting [for new users]. So I'm very much +1 on having tolerance for the top 5-10 editor patterns in our .gitignores, -1 on *ever* having a bug open to change this in any repository, and getting on with our actual task here of writing fantastic code. If folk *really* don't want editor files in .gitignore (and given the complete lack of harm I would -really- like a explanation for this mindset) then we could solve the problem more permanently: we know what files need to be added - *.rst, *.py, *.ini, [!.]* and a few others. Everything else is junk and shouldn't be added. By whitelisting patterns we will support all editors except those whose working file names match names we'd genuinely want to add. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [style] () vs \ continuations
A little late, but here is the patch to put this into hacking. https://review.openstack.org/#/c/64584/ And here is it running against nova: http://logs.openstack.org/84/64584/1/check/gate-hacking-integration-nova/b31c47e/console.html On Mon, Nov 18, 2013 at 5:23 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: On Nov 14, 2013, at 10:00 AM, Monty Taylor mord...@inaugust.com wrote: On 11/13/2013 08:08 PM, Robert Collins wrote: On 14 November 2013 13:59, Sean Dague s...@dague.net wrote: This is an area where we actually have consensus in our docs (have had for a while), the reviewer was being consistent with them, and it feels like you are reopening that for personal preference. Sorry that it feels that way. My personal code also uses () overwhelmingly - so this isn't a personal agenda issue. I brought it up because the person that wrote the code had chosen to use \, and as far as I knew we didn't have a hard decision either way - and the style guide we have talks preference not requirement, but the review didn't distinguish between whether it's a suggestion or a requirement. I'm seeking clarity so I can review more effectively and so that our code doesn't end up consistent but hard to read. I'd say we've got an expression of clarity here - which means potentially a patch to the hacking guide to clarify the language on what our choice is, as well as the addition of a hacking check to enforce it would be in bounds. +1 to sticking something in hacking. FWIW I would probably do the following to avoid the debate altogether: result = self._path_file_exists(ds_browser, folder_path, file_name) folder_exists, file_exists, file_size_in_kb, disk_extents = result Vish Honestly I find \ at the end of a line ugly as sin, and completely jarring to read. I actually do like the second one better. I don't care enough to change a policy on it, but we do already have a policy, so it seems pretty pedantic, and not useful. Ok, thats interesting. Readability matters, and if most folk find that even this case - which is pretty much the one case where I would argue for \ - is still easier to read with (), then thats cool. Bringing up for debate the style guide every time it disagrees with your personal preference isn't a very effective use of people's time. Especially on settled matters. Totally not what I'm doing. I've been told that much of our style guide was copied lock stock and barrel from some Google Python style guide, so I can't tell what is consensus and what is 'what someone copied down one day'. Particularly when there is no rationale included against the point - its a black box and entirely opaque. -Rob ___ 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-Dev] IDE extensions in .gitignore
On Tue, Dec 31, 2013 at 3:33 PM, Robert Collins robe...@robertcollins.net wrote: On 1 January 2014 06:07, Joe Gordon joe.gord...@gmail.com wrote: I am not sure if this is the global .gitignore you are thinking of but this is the one I am in favor of: https://help.github.com/articles/ignoring-files#global-gitignore Maintaining .gitignore in 30+ repositories for a potentially infinite number of editors is very hard, and thankfully we have an easier way to do it. This is a strawman argument: noone (that I know of) has proposed adding all editors to all repositories. There are in reality a few very common editors and having their extensions present in per repository .gitignores does absolutely *no harm*. There is no reason not to have sane and sensible defaults in our repositories. If we are wasting time adding and removing patterns, then I think that counts as a harm, so it is a sensible discussion to have to come to a project standard, but the standard should be inclusive and useful, not just useful for power users that have everything setup 'just so'. Many contributors are using git for the first time when they contribute to OpenStack, and getting git setup correctly is itself daunting [for new users]. So I'm very much +1 on having tolerance for the top 5-10 editor patterns in our .gitignores, -1 on *ever* having a bug open to change this in any repository, and getting on with our actual task here of writing fantastic code. If folk *really* don't want editor files in .gitignore (and given the complete lack of harm I would -really- like a explanation for this mindset) then we could solve the problem more permanently: we know what files need to be added - *.rst, *.py, *.ini, [!.]* and a few others. Everything else is junk and shouldn't be added. By whitelisting patterns w e will support all editors except those whose working file names match names we'd genuinely want to add. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev If we are wasting time adding and removing patterns, then I think that counts as a harm, so it is a sensible discussion to have to come to a project standard, but the standard should be inclusive and useful, not just useful for power users that have everything setup 'just so'. Many contributors are using git for the first time when they contribute to OpenStack, and getting git setup correctly is itself daunting [for new users]. My point exactly is that this is creating churn and there is some back and forth (see links to LP items below). Like I said, I don't have an objection, I just want to be consistent and move on. This has come up in commits in past releases as well. As I said, I see little harm in having them present, however I see significant harm in racking up commits to take them in and out as well as the ugliness in having inconsistent policies in different projects. https://bugs.launchpad.net/ceilometer/+bug/1256043 https://bugs.launchpad.net/trove/+bug/1257279 https://bugs.launchpad.net/python-cinderclient/+bug/1255876 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tripleo] reviewer review Jan
I'm going to skip this this month: with most folk having ~2 weeks of leave there's only an effective 2 weeks of delta - both in practice for new reviewers, and in changes to track for existing -core since the last review - it seems a little pointless. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Docker and TripleO
So, we've spoken about using containers on baremetal - e.g. the lxc provider - in the past, and with the [righteously deserved] noise Docker is receiving, I think we need to have a short expectation-setting discussion. Previously we've said that deploying machines to deploy containers to deploy OpenStack was overly meta - I stand by it being strictly unnecessary, but since Docker seems to have gotten a really good sweet spot together, I think we're going to want to revisit those discussions. However, I think we should do so no sooner than 6 months, and probably more like a year out. I say 6-12 months because: - Docker currently describes itself as 'not for production use' - It's really an optimisation from our perspective - We need to ship a production ready version of TripleO ASAP, and I think retooling would delay us more than it would benefit us. - There are going to be some nasty bootstrapping issues - we have to deploy the bare metal substrate and update it in all cases anyway - And I think pushing ahead with (any) container without those resolved is unwise - because our goal as always has to be to push the necessary support into the rest of OpenStack, *not* as a TripleO unique facility. This all ties into other threads that have been raised about future architectures we could use: I think we want to evolve to have better flexability and performance, but lets get a v1 minimal but functional - HA, scalable, usable - version in place before we advance. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Novnc switch to sockjs-client instead of websockify
Hi, I was wondering if it would be possible for NoVNC to switch from websockify to sockjs-client, which is available here: https://github.com/sockjs/sockjs-client This has the advantage of not using flash at all (pure javascript), and continuing to work on all browsers, with a much cleaner licensing. Thoughts welcome! Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
