[openstack-dev] [Swift] Juno RC1 available
Hello everyone, Swift just published its first Juno release candidate. The list of fixed bugs and the RC1 tarball are available at: https://launchpad.net/swift/juno/2.2.0-rc1 Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as Swift 2.2.0 (final Juno version) on October 16. You are therefore strongly encouraged to test and validate this tarball ! Alternatively, you can directly test the proposed/juno branch at: https://github.com/openstack/swift/tree/proposed/juno If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/swift/+filebug and tag it *juno-rc-potential* to bring it to the release crew's attention. Note that the master branch of Swift is now open for Kilo development, and feature freeze restrictions no longer apply there. All projects have now published at least one release candidate. Regards, -- 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] ETSI NFV gap analysis [NFV]
Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a écrit : Team, Following my action item from last week IRC. It seems that the document is ready for submission by ETSI NFV team. It was written in a liaison form as this is how they are used to operate. They are wondering who should they send it to... IMHO it seems a good idea that the NFV sub group will receive it in behalf of the community. Thoughts? Itai I don't know the legal conditions of the publication of this document, but I would assume it would be worth of interest within the whole OpenStack community so anyone could see what's missing and contribute to it. At least pointing the document to the NFV wiki page sounds important, provided this communication can be done this way (ie. no opt-in list for people looking at the doc) -Sylvain Sent from my iPhone ___ 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] [Trove] Trove Blueprint Meeting on 6 October canceled
Hey folks: There's nothing to discuss on the BP Agenda for this week so I'd like to cancel the Trove blueprint meeting for this week. There are a few blueprints that are in-flight and need reviews / comments, so please take this time to review these blueprints and provide feedback: https://review.openstack.org/#/c/123571/ https://review.openstack.org/#/c/124717/ https://review.openstack.org/#/c/122736/ https://review.openstack.org/#/c/122767/ See you guys at the regular Trove meeting on Wednesday! Thanks, Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] structure of supported_instances field (architecture, hypervisor type, vm mode) ?
FYI I'm currently working on changing the get_available_resources() method to return a formal object, instead of its horrible undocumented dict(). With this, the current list of lists / JSON used for supported_instances will turn into a formal object with strict validation. Regards, Thanks Daniel, we had better coordinate on that then. I will try and catch you on IRC today. Paul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] CI report : 27/09/2014 - 03/10/2014
Hi All, There was 1 CI event last week, regression in ironic https://bugs.launchpad.net/tripleo/+bug/1375641 All ironic tripleo CI tests failed for about 12 hours For more info see https://etherpad.openstack.org/p/tripleo-ci-breakages thanks, Derek. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model
So a bit of background here. This began from thinking about functional dependencies, and pondering whether a map of the dependency graph of our projects could inform our gating structure, specifically to encourage (or dare I say, actually force) all of us (the project teams) to become more cognizant of the API contracts we are making with each other, and the pain it causes when we break those contracts. Let's not extend this exercise to a gigantic everything-needs-everything-to-do-everything picture, which is where it's heading now. Sure, telemetry is important for operators, and in no way am I saying anything else when I say: for Nova to fulfill its primary goal, telemetry is not necessary. It is optional. Desired, but optional. I don't follow the optional-but-not-necessary argument here, or where you're applying the cut-off for the graph not turning into a gigantic picture. There were a bunch of relationships in the original graph that are not strictly necessary for nova to fulfill it's primary goal, but are desired and existing functional dependencies in any case. For nova to do anything useful at all, it very simply needs an identity service (keystone), an image registry service (glance), and a network service (neutron (ignoring the fact that nova-network is still there because we actually want it to go away)). Without these, Nova is utterly useless. So, from a minimalist compute-centric perspective, THAT'S IT. Sure, I get that idea of isolating the minimal set of dependencies for the compute use-case. I was questioning the fact the dependency graph referenced on the thread earlier: http://i.imgur.com/y8zmNIM.png selectively included *some* dependencies that lay outside this narrow use-case for nova, but not others. So, are we trying to capture all dependencies here, or to apply some value-judgement and selectively capture just the good dependencies, for some definition of good? Nope. I am not making any value judgement whatsoever. I'm describing dependencies for minimally satisfying the intended purpose of a given project. For example, Nova's primary goal is not emit telemetry, it is scalable, on demand, self service access to compute resources [1] There are a lot of other super-awesome additional capabilities for which Nova depends on other services. And folks want to add more cool things on top of, next to, and underneath this ring compute. And make new non-compute-centric groups of projects. That's all wonderful. I happen to also fall in that camp - I think Ironic is a useful service, but I'm happy for it to not be in that inner ring of codependency. The nova.virt.ironic driver is optional from Nova's POV (Nova works fine without it), and Nova is optional from Ironic's POV (it's a bit awkward, but Ironic can deploy without Nova, though we're not testing it like that today). On the other hand, from a minimalist telemetry-centric perspective, what other projects do I need to run Ceilometer? Correct me if I'm wrong, but I think the answer is None. At the very least, ceilometer would need keystone to function. Or rather, which ever ones I want. If I'm running Nova and not running Swift, Ceilometer works with Nova. If I'm running Swift but not Nova, Ceilometer works with Swift. There's no functional dependency on either Nova or Swift here - it's just consumption of an API. None of which is bad - but this informs how we gate test these projects, and how we allocate certain resources (like debugging gate-breaking bugs) across projects. OK, so if project A doesn't *need* project B to function minimally, but will use if it's available, and it's likely to be so in most realistic deployments, then we still need to ensure somehow that changes in project B don't break project A. i.e. even if the dependency isn't a strict necessity, it may still very likely be an actual reality in practice. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On Sun, Oct 05 2014, Joshua Harlow wrote: IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. Best, -jay Amen to that, it is our responsibility as developers to do this, for the benefit of operators, developers, historians, ..., and users of openstack. And really it isn't that hard, you just have to devote some time to do it (take 1/2 of a day a week to devote to doing docs for your project). Eventually all those 1/2 of days add up to a decent set of usable docs for people using your project/library/other... If we had more people spending 1/2 or 1/4 a day a week on improving docstrings, improving api/sphinx docs, improving diagrams we would IMHO be in a much better position with respect to on-boarding new developers and making it so that existing developers can understand prior architectural decisions (which is important for a variety of reasons, including but not limited to 'knowing what the reason for this code was' which can be useful when/if refactoring, knowing what the reason for this code was when adding new tests...). IMHO we shouldn't be leaning on the docs team to do our docs, just like we shouldn't be leaning on the TC to say what is 'blessed' or what isn't; these roles should be advisory and I think they should be primarily spreading best practices, and leading by example (which I believe makes good leadership and a healthy community). I agree. I think we should have documentation be part of our policy to accept patches, just as we do with e.g. unit testing. Forcing people to write documentation along the patch will help writing better code, having a better understanding of what the patch does for reviewers, etc… And will obviously benefit to users and operators. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Adding pylint checking of new ceilometer patches
My points are next: 1. Pylint check will be very useful for project, and will help to avoid critical errors or mistakes in code. 2. At first step we won't implement pylint as gate job, but will add it at master to have a possibility to check code with pylint locally, if it is needed. 3. In future it could be added as a non-voting job. -- Igor On Sat, Oct 4, 2014 at 1:56 AM, Angus Lees g...@inodes.org wrote: You can turn off lots of the refactor recommendation checks. I've been running pylint across neutron and it's uncovered half a dozen legitimate bugs so far - and that's with many tests still disabled. I agree that the defaults are too noisy, but its about the only tool that does linting across files - pep8 for example only looks at the current file (and not even the parse tree). On 4 Oct 2014 03:22, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 1:09 PM, Neal, Phil phil.n...@hp.com wrote: From: Dina Belova [mailto:dbel...@mirantis.com] On Friday, October 03, 2014 2:53 AM Igor, Personally this idea looks really nice to me, as this will help to avoid strange code being merged and not found via reviewing process. Cheers, Dina On Fri, Oct 3, 2014 at 12:40 PM, Igor Degtiarov idegtia...@mirantis.com wrote: Hi folks! I try too guess do we need in ceilometer checking new patches for critical errors with pylint? As far as I know Nova and Sahara and others have such check. Actually it is not checking of all project but comparing of the number of errors without new patch and with it, and if diff is more then 0 then patch are not taken. Looking a bit deeper it seems that Nova struggled with false positives and resorted to https://review.openstack.org/#/c/28754/ , which layers some historical checking of git on top of pylint's tendency to check only the latest commit. I can't say I'm too deeply versed in the code, but it's enough to make me wonder if we want to go that direction and avoid the issues altogether? I haven’t looked at it in a while, but I’ve never been particularly excited by pylint. It’s extremely picky, encourages enforcing some questionable rules (arbitrary limits on variable name length?), and repots a lot of false positives. That combination tends to result in making writing software annoying without helping with quality in any real way. Doug I have taken as pattern Sahara's solution and proposed a patch for ceilometer: https://review.openstack.org/#/c/125906/ Cheers, Igor Degtiarov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 10/06/2014 11:24 AM, Julien Danjou wrote: On Sun, Oct 05 2014, Joshua Harlow wrote: IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. Best, -jay Amen to that, it is our responsibility as developers to do this, for the benefit of operators, developers, historians, ..., and users of openstack. And really it isn't that hard, you just have to devote some time to do it (take 1/2 of a day a week to devote to doing docs for your project). Eventually all those 1/2 of days add up to a decent set of usable docs for people using your project/library/other... If we had more people spending 1/2 or 1/4 a day a week on improving docstrings, improving api/sphinx docs, improving diagrams we would IMHO be in a much better position with respect to on-boarding new developers and making it so that existing developers can understand prior architectural decisions (which is important for a variety of reasons, including but not limited to 'knowing what the reason for this code was' which can be useful when/if refactoring, knowing what the reason for this code was when adding new tests...). IMHO we shouldn't be leaning on the docs team to do our docs, just like we shouldn't be leaning on the TC to say what is 'blessed' or what isn't; these roles should be advisory and I think they should be primarily spreading best practices, and leading by example (which I believe makes good leadership and a healthy community). I agree. I think we should have documentation be part of our policy to accept patches, just as we do with e.g. unit testing. Forcing people to write documentation along the patch will help writing better code, having a better understanding of what the patch does for reviewers, etc… And will obviously benefit to users and operators. This is a matter of making reviewers aware of this issue. As much as we want to make it official, there's probably not a good/easy way to enforce it besides asking reviewers to be nitpicky on these things. By requesting docs on reviews, we'll encourage people to write docs right away next time. Cheers, Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
-Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: Saturday, October 04, 2014 1:27 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][docs][tc] How to scale Documentation On 10/03/2014 07:50 PM, Anne Gentle wrote: Here's my current thinking and plan of attack on multiple fronts. Oh, that analogy is so militaristic, I'd revise more peacefully but ... time. :) 1. We need better page-based design and navigation for many of our docs. I'm working with the Foundation on a redesign. This may include simpler source files. 2. We still need book-like output. Examples of books include the Installation Guides, Operations Guide, the Security Guide, and probably the Architecture Design Guide. Every other bit of content can go into pages if we have decent design, information architecture, navigation, and versioning. Except maybe the API reference [0], that's a special beast. 3. We need better maintenance and care of app developer docs like the API Reference. This also includes simpler source files. Just curious, has anyone considered rejigging things so that each component has a single definition of its API that could then be used to mechanically generate both the API validation code as well as the API reference documentation? One idea related to the above, Nova will be able to provide API docs by auto-generating the docs from JSON-Home and JSON-Schema(API validation code). JSON-Home can provide API URLs, but it doesn't cover how to provide JSON-Schema now. If we make a consistent way for doing that in OpenStack components, we can get the docs on the same way/format. That was we told on the other thread[1]. Thanks Ken'ichi Ohmichi --- [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-October/047635.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
Jay Pipes wrote: On 10/03/2014 09:18 PM, Zane Bitter wrote: The prospect of a much larger tent with many more projects in OpenStack-proper shines a spotlight on the scalability of the Docs team, and in particular how they decide which projects are important to work on directly. I don't believe that a ticket to live under the OpenStack tent should come with the expectation that the Docs team is required to write documentation for the project. IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. I'd like to generalize that beyond Docs, because the same issue applies to all other horizontal teams. There are multiple ways an horizontal team can declare its commitment, and I agree we should never assume that a TC decision (new integrated project!) implies more work for the team (Docs now has to support this as well). That's the way it currently works, and yes, it doesn't scale. It didn't scale early with Docs, so they opted out of supporting all integrated projects early on. So in summary: - ticket to live under the OpenStack big tent should never come with expectation that any horizontal team will do the work for that project directly - horizontal teams may decide to directly do the work for any number of projects - corollary #1: horizontal teams may decide to commit to directly doing the work for a mostly-static ring0 (or not) - corollary #2: horizontal teams may decide to not directly do the work for any project - horizontal teams should build processes and tools to facilitate and guide the work of projects in the big tent in their area of expertise -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Tentative schedule for Kilo Design Summit in Paris
Hi everyone, I published a tentative schedule for the Kilo Design Summit in Paris: http://kilodesignsummit.sched.org/ The content is still very much a work in progress (as you can see by the topic tbd labels everywhere), but it shows when each project will be discussed, so hopefully you can start planning attendance more precisely. Also remember we'll have a number of pods available so that the discussion and collaboration can continue even when you don't have a session on the schedule. You should generally plan to attend all 4 days ! I tried to avoid PTLs conflicts with presentations they give on the OpenStack Summit side, and also made sure to reduce overlap between vertical programs and horizontal ones (for example, making sure Cinder folks can attend some QA or some Keystone sessions). It's a pretty delicate balance, so I don't expect to make major changes unless a critical conflict is reported and we can fix it with limited changes. Remember that you can help shape the agenda of each subtrack by joining the corresponding team meetings and participating in the brainstorming of topics using the public documents at: https://wiki.openstack.org/wiki/Summit/Planning More information on the Kilo summit will be posted at: https://wiki.openstack.org/wiki/Summit/Kilo Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Help needed to resolve ImportError: No module named urllib
Hello All, We are trying to integrate openstack with java. While doing so we are facing ImportError: No module named urllib When we import from python console it works fine. However when we are trying to import using jython 2.7 interpreter we get the below error. Caused by: Traceback (most recent call last): from oslo import messaging File /site-packages/oslo/messaging/__init__.py, line 18, in module from oslo.messaging.notify import * File /site-packages/oslo/messaging/notify/__init__.py, line 25, in module from oslo.messaging.notify.logger import * File /site-packages/oslo/messaging/notify/logger.py, line 21, in module from oslo.messaging import transport File /site-packages/oslo/messaging/transport.py, line 31, in module from six.moves.urllib import parse ImportError: No module named urllib We are using python package SIX of version 1.8. Please let me know your inputs on this. Thanks Regards Praveen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/10/14 18:12, Akihiro Motoki wrote: Thanks all for your input. This topic was also discussed in the I18N team meeting this week. All opinions I got so far are same and we seem to have a consensus. - not to have mo files (compile message catalogs) in our source git repository. - to provide a quick documentation on how to generate mo files and deploy them This consensus raises another question. At now Horizon is the only affected project. Is it better to apply this consensus to Juno Horizon release or to defer it to Kilo? One concern is that most distributions have already prepared packages for Kilo, so it might be better not to change now? I would like to know opinions from distributors like RDO, Debian, Ubuntu and so on. I was pointed (kudos to Alan Pevec) to the following update for RDO spec file [1] that makes it regenerate MO files from source for Juno. So for RDO, it's already handled the way we will probably go forward. [1]: http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/commit/?id=e756a1d0e401707d6d386516eef5c2af8ed5e138 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMn5lAAoJEC5aWaUY1u570KUIAJRuxXcARheAJQB8phFlarHn zzRNA7hA8WPBEVMRZCJjqqLKEeS/XaSN0Ue8XuR8bX4AOKA+Yh9S2X39kEWGquhI Xdb5OqkHXPrBRAAKIdg9sPIa5SfKF9m9vEWSH84nGDczhQTeV6XBJtrnBgL9USa7 bMmifiXg14lSNNgwwpiEkyoA1qmEsMki+yFPuvldWLvszWgl3xlTOZnY1L7auUgU DO9bWuvSa10O463+CH4SbhhwE/k8TS3B5A/Y7eKeFwLECAHQFumgFK3bQtFE7QfB Lv29eonr6NchEtGo+tu1W10ervDAoEVqMF6oLFtg+qF3hJwyumhH9pIV9PXVO5g= =fkXa -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Tentative schedule for Kilo Design Summit in Paris
On Mon, Oct 6, 2014 at 8:29 PM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I published a tentative schedule for the Kilo Design Summit in Paris: http://kilodesignsummit.sched.org/ The content is still very much a work in progress (as you can see by the topic tbd labels everywhere), but it shows when each project will be discussed, so hopefully you can start planning attendance more precisely. Also remember we'll have a number of pods available so that the discussion and collaboration can continue even when you don't have a session on the schedule. You should generally plan to attend all 4 days ! I tried to avoid PTLs conflicts with presentations they give on the OpenStack Summit side, and also made sure to reduce overlap between vertical programs and horizontal ones (for example, making sure Cinder folks can attend some QA or some Keystone sessions). It's a pretty delicate balance, so I don't expect to make major changes unless a critical conflict is reported and we can fix it with limited changes. Remember that you can help shape the agenda of each subtrack by joining the corresponding team meetings and participating in the brainstorming of topics using the public documents at: https://wiki.openstack.org/wiki/Summit/Planning Hi Thierry When does each project have to have the content nailed down? Thanks Angus More information on the Kilo summit will be posted at: https://wiki.openstack.org/wiki/Summit/Kilo Regards, -- 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] [all] Tentative schedule for Kilo Design Summit in Paris
Angus Salkeld wrote: When does each project have to have the content nailed down? At least one week before the Design Summit starts (so before October 28). I'll start to more aggressively nag the various Kilo PTLs once the release is out :) -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Tentative schedule for Kilo Design Summit in Paris
Le 06/10/2014 12:29, Thierry Carrez a écrit : Hi everyone, I published a tentative schedule for the Kilo Design Summit in Paris: http://kilodesignsummit.sched.org/ The content is still very much a work in progress (as you can see by the topic tbd labels everywhere), but it shows when each project will be discussed, so hopefully you can start planning attendance more precisely. Also remember we'll have a number of pods available so that the discussion and collaboration can continue even when you don't have a session on the schedule. You should generally plan to attend all 4 days ! I only see 3 slots for discussing about other projects. Do you know if it would be possible to get more as there are particular slots around 14:50, 15:40 and 17:20 which are quite empty ? -Sylvain I tried to avoid PTLs conflicts with presentations they give on the OpenStack Summit side, and also made sure to reduce overlap between vertical programs and horizontal ones (for example, making sure Cinder folks can attend some QA or some Keystone sessions). It's a pretty delicate balance, so I don't expect to make major changes unless a critical conflict is reported and we can fix it with limited changes. Remember that you can help shape the agenda of each subtrack by joining the corresponding team meetings and participating in the brainstorming of topics using the public documents at: https://wiki.openstack.org/wiki/Summit/Planning More information on the Kilo summit will be posted at: https://wiki.openstack.org/wiki/Summit/Kilo Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, tl;dr we should enforce utf8 on server and client sides of db connection, and this requires changes to docs and oslo.db. The latter may require raising effective libpq version dep to 9.1+. Recently I was working on making sure we always run using utf8 on both database server and client side, and that we do it with all the proper connection options set (f.e. mysqldb requires use_unicode=0 to avoid performance drop - a thing that is not set anywhere in gate as of now, and not documented). For server side, it's a matter of how we create databases, and in devstack, it's usually utf8 (though, for unclear reason, latin1 is still enforced for nova for initial creation due to Folsom (sic!) bug; I've reverted to utf8 with [1]). For client side, it's not that clear. Though devstack enforces utf8 in SQL connection strings, we don't ask to do so in official docs [2]. There is a bug [3] in LP that seems to be relevant. I think the proper way is to enforce utf8 everywhere. The first step would be to make sure we suggest adding charset=utf8 to SQL connection strings, and configure SQL servers to use utf8. That is something to be covered by docs team. But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. Though as you can see, the patch fails on py26 postgresql unit tests. This is because I set charset_encoding for PostgreSQL via libpq connection option that is available since PostgreSQL 9.1 only. The failure is because we run py26 test suite on CentOS 6.5 that still uses PostgreSQL 8.4.*, meaning the option is not available for us. Now, there are several other ways available for us to enforce encoding without using the option. First, we may set encoding thru PGCLIENTENCODING environment variable. Second, we may execute SET CLIENT_ENCODING TO utf8 after connecting to psql server. Now, the question is whether it's worth reimplementing the feature using some of the available hacks that will work with PSQL 9.1. We're about to drop Python 2.6 support in Kilo, and that probably means that CentOS 6.5 will be dropped from gate too. Do we have any other distribution of interest that uses both python 2.7 and psql 9.1, and is going to run Kilo pieces? On Red Hat side, we're not interested in running Juno on EL6 that uses old psql. As for EL7, it has a psql version that supports the connection option. On Ubuntu side, the only LTS release that is still supported and uses psql 9.1 is Lucid, but it's based on py26, so it should not be an issue. Any other consumers that could be affected by effectively raising minimum version bar for psql to 9.1 in Kilo? Though we've (almost) decided to drop py26 support in Kilo, we didn't have similar discussions for other components that we use. So I'd like to hear what's our take on that. Do we really drop *py26* support, or maybe what we really do is we drop *CentOS 6.5* support?.. On a more general note, do we track those kind of external dependencies anywhere? There are lots of them: neutron depends on specific versions of openvswitch; oslo.db depends on specific versions of underlying backend libraries, etc. Comments? [1]: https://review.openstack.org/126267 [2]: http://docs.openstack.org/icehouse/install-guide/install/yum/content/nova-controller.html [3]: https://bugs.launchpad.net/glance/+bug/1279000 [4]: https://review.openstack.org/111236 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMotwAAoJEC5aWaUY1u57IQQIAN2yHfxbj0DYDMHE40OGbEwU 8fis/KOAxSyUEhHbbECS8ODGjHNK9SeuddUplzL5sKVbYIMZgt3wKXGT/rT5ex0C iMmc7/mb6JGGTUYvR1sF2EXxioJ3kWJSt5oQqBhVT14y2g8rwqN6tQaTusfDVZWN yZ7KCmQDc+3HMyY3EmYCp6V1ndubLbx8Oh56/jtdSGdNtc7V4IwYIF3F4WQaKBcB 54tZkAO0wvlbbRrXqEiyf99/dVLDiMquM3LNKEbYg4zjDUEX74fGJ3mscQtWdDLv 0TcqOvQ2pwLvpksf30kvBBHGcNCF9x8Ov8H4vg5wRTD4bkpjEDwmXzQXTk7xfHM= =aYRM -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
Thanks Ihar, RDO already compiles message catalogs and nothing seems affected. I also got an input from Debian maintainer (zigo) that it is a good direction in Juno. I would like to remove MO files (compiled message catalogs) in Juno when importing translations this week. Distributions have their own packaging policy (directory hierarchy, build-depends and so on) so the detail step on how to compile message catalogs depends on distributions too. For operators who install Horizon from the source, I proposed the update of Horizon docs [1] and it can be added to the installation guide too. The way I wrote in the doc is not ideal, but I believe it is a convenient way. [1] https://review.openstack.org/#/c/126169/3/doc/source/topics/install.rst Thanks, Akihiro On Mon, Oct 6, 2014 at 8:35 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/10/14 18:12, Akihiro Motoki wrote: Thanks all for your input. This topic was also discussed in the I18N team meeting this week. All opinions I got so far are same and we seem to have a consensus. - not to have mo files (compile message catalogs) in our source git repository. - to provide a quick documentation on how to generate mo files and deploy them This consensus raises another question. At now Horizon is the only affected project. Is it better to apply this consensus to Juno Horizon release or to defer it to Kilo? One concern is that most distributions have already prepared packages for Kilo, so it might be better not to change now? I would like to know opinions from distributors like RDO, Debian, Ubuntu and so on. I was pointed (kudos to Alan Pevec) to the following update for RDO spec file [1] that makes it regenerate MO files from source for Juno. So for RDO, it's already handled the way we will probably go forward. [1]: http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/commit/?id=e756a1d0e401707d6d386516eef5c2af8ed5e138 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMn5lAAoJEC5aWaUY1u570KUIAJRuxXcARheAJQB8phFlarHn zzRNA7hA8WPBEVMRZCJjqqLKEeS/XaSN0Ue8XuR8bX4AOKA+Yh9S2X39kEWGquhI Xdb5OqkHXPrBRAAKIdg9sPIa5SfKF9m9vEWSH84nGDczhQTeV6XBJtrnBgL9USa7 bMmifiXg14lSNNgwwpiEkyoA1qmEsMki+yFPuvldWLvszWgl3xlTOZnY1L7auUgU DO9bWuvSa10O463+CH4SbhhwE/k8TS3B5A/Y7eKeFwLECAHQFumgFK3bQtFE7QfB Lv29eonr6NchEtGo+tu1W10ervDAoEVqMF6oLFtg+qF3hJwyumhH9pIV9PXVO5g= =fkXa -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Resource tracker
Hi, At the moment the resource tracker in Nova ignores that statistics that are returned by the hypervisor and it calculates the values on its own. Not only is this highly error prone but it is also very costly - all of the resources on the host are read from the database. Not only the fact that we are doing something very costly is troubling, the fact that we are over calculating resources used by the hypervisor is also an issue. In my opinion this leads us to not fully utilize hosts at our disposal. I have a number of concerns with this approach and would like to know why we are not using the actual resource reported by the hypervisor. The reason for asking this is that I have added a patch which uses the actual hypervisor resources returned and it lead to a discussion on the particular review (https://review.openstack.org/126237). Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
On 10/06/2014 08:30 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, tl;dr we should enforce utf8 on server and client sides of db connection, and this requires changes to docs and oslo.db. The latter may require raising effective libpq version dep to 9.1+. Recently I was working on making sure we always run using utf8 on both database server and client side, and that we do it with all the proper connection options set (f.e. mysqldb requires use_unicode=0 to avoid performance drop - a thing that is not set anywhere in gate as of now, and not documented). For server side, it's a matter of how we create databases, and in devstack, it's usually utf8 (though, for unclear reason, latin1 is still enforced for nova for initial creation due to Folsom (sic!) bug; I've reverted to utf8 with [1]). For client side, it's not that clear. Though devstack enforces utf8 in SQL connection strings, we don't ask to do so in official docs [2]. There is a bug [3] in LP that seems to be relevant. I think the proper way is to enforce utf8 everywhere. The first step would be to make sure we suggest adding charset=utf8 to SQL connection strings, and configure SQL servers to use utf8. That is something to be covered by docs team. But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. So, the subject of this email is a bit misleading :) You are suggesting a change to the UTF-8 charset enforcement here, and below you are suggesting removing libpq9.1 for related reasons. I suppose setting of utf8 on the client side, and supporting utf8 on the server side, but I do *not* recommend using a blanket policy of charset=utf8 on every text column on the database side. It really is wasteful for certain columns like uuids that are used in joins all over the schema... Best, -jay Though as you can see, the patch fails on py26 postgresql unit tests. This is because I set charset_encoding for PostgreSQL via libpq connection option that is available since PostgreSQL 9.1 only. The failure is because we run py26 test suite on CentOS 6.5 that still uses PostgreSQL 8.4.*, meaning the option is not available for us. Now, there are several other ways available for us to enforce encoding without using the option. First, we may set encoding thru PGCLIENTENCODING environment variable. Second, we may execute SET CLIENT_ENCODING TO utf8 after connecting to psql server. Now, the question is whether it's worth reimplementing the feature using some of the available hacks that will work with PSQL 9.1. We're about to drop Python 2.6 support in Kilo, and that probably means that CentOS 6.5 will be dropped from gate too. Do we have any other distribution of interest that uses both python 2.7 and psql 9.1, and is going to run Kilo pieces? On Red Hat side, we're not interested in running Juno on EL6 that uses old psql. As for EL7, it has a psql version that supports the connection option. On Ubuntu side, the only LTS release that is still supported and uses psql 9.1 is Lucid, but it's based on py26, so it should not be an issue. Any other consumers that could be affected by effectively raising minimum version bar for psql to 9.1 in Kilo? Though we've (almost) decided to drop py26 support in Kilo, we didn't have similar discussions for other components that we use. So I'd like to hear what's our take on that. Do we really drop *py26* support, or maybe what we really do is we drop *CentOS 6.5* support?.. On a more general note, do we track those kind of external dependencies anywhere? There are lots of them: neutron depends on specific versions of openvswitch; oslo.db depends on specific versions of underlying backend libraries, etc. Comments? [1]: https://review.openstack.org/126267 [2]: http://docs.openstack.org/icehouse/install-guide/install/yum/content/nova-controller.html [3]: https://bugs.launchpad.net/glance/+bug/1279000 [4]: https://review.openstack.org/111236 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMotwAAoJEC5aWaUY1u57IQQIAN2yHfxbj0DYDMHE40OGbEwU 8fis/KOAxSyUEhHbbECS8ODGjHNK9SeuddUplzL5sKVbYIMZgt3wKXGT/rT5ex0C iMmc7/mb6JGGTUYvR1sF2EXxioJ3kWJSt5oQqBhVT14y2g8rwqN6tQaTusfDVZWN yZ7KCmQDc+3HMyY3EmYCp6V1ndubLbx8Oh56/jtdSGdNtc7V4IwYIF3F4WQaKBcB 54tZkAO0wvlbbRrXqEiyf99/dVLDiMquM3LNKEbYg4zjDUEX74fGJ3mscQtWdDLv 0TcqOvQ2pwLvpksf30kvBBHGcNCF9x8Ov8H4vg5wRTD4bkpjEDwmXzQXTk7xfHM= =aYRM -END PGP SIGNATURE- ___ 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] Resource tracker
On Mon, Oct 06, 2014 at 01:03:01PM +, Gary Kotton wrote: Hi, At the moment the resource tracker in Nova ignores that statistics that are returned by the hypervisor and it calculates the values on its own. Not only is this highly error prone but it is also very costly - all of the resources on the host are read from the database. Not only the fact that we are doing something very costly is troubling, the fact that we are over calculating resources used by the hypervisor is also an issue. In my opinion this leads us to not fully utilize hosts at our disposal. I have a number of concerns with this approach and would like to know why we are not using the actual resource reported by the hypervisor. The reason for asking this is that I have added a patch which uses the actual hypervisor resources returned and it lead to a discussion on the particular review (https://review.openstack.org/126237). If i'm interpreting git history correctly, this behaviour was (re-)introduced in this commit: commit 8e851409f3a8a345ec954a880c81232fbf9e27b4 Author: Brian Elliott brian.elli...@rackspace.com Date: Fri Sep 14 15:17:07 2012 + Fix bugs in resource tracker and cleanup Fixes bugs in resource tracker: * Handle disk oversubscription * Handle suspended/powered off instances The usage model is changed to the old style that is based on actual instance usage on a compute host. (Not the current point in time of the hypervisor's reported host stats) There is now a 'limits' filter property that can be passed from the scheduler to the compute node to indicate that oversubscription of resources is desired: The 'limits' filter property is a dict with the following possible keys: * memory_mb - Specifies the memory ceiling for the compute node. * disk_gb - Specifies the disk space ceiling for the compute node. * vcpu - Specifies the max number of vcpus for the compute node. There is also some general cleanup and additional unit tests in an attempt to simplify down this function. bug 1048842 bug 1052157 Change-Id: I6ee851b8c03234a78a64d9f5c494dfc7059cdda4 Unfortunately that commit message isn't very informative as to why this change was made, and the bugs don't seem to have any real detail either. Perhaps Brian remembers himself ? Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] [Heat] [Mistral] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder
Renat, I've addressed a number of Mistral Workbook builder's issues, including: * separating workflow-based Tasks from action-based ones, including distinct set of fields for each one; * restricting the range of values that can be selected for 'required' field of Task inside reverse-type Workflow to already existing tasks of that Workflow; * removing 'Add' button that cluttered UI considerably - now Barricade entities are updated on field's 'change' event; * updating the Merlin/Mistral schema with the latest version of Mistral workbook schema * and some bugfixing... Regarding the field validation which is the last goal for Merlin/Mistral PoC I haven't implemented yet, your feedback would be very helpful, namely: * what validation constraints should be added? * which fields should be validated? Any other feedback (not only related to validation issues) is also greatly appreciated. Once we deal with validation and some UI awkwardness, I plan to begin with Horizon integration. P.S. As usual, you can find the latest version of Merlin/Mistral Workbook builder at https://github.com/stackforge/merlin On Tue, Sep 30, 2014 at 11:06 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Timur, For us, undoubtedly, it’s a great news. Visualization of any kind is really important for Mistral for a number of reasons. You can count on any help(including code contribution) from our side. Thanks Renat Akhmerov @ Mirantis Inc. On 26 Sep 2014, at 04:04, Steve Baker sba...@redhat.com wrote: On 26/09/14 05:36, Timur Sufiev wrote: Hello, folks! Following Drago Rosson's introduction of Barricade.js and our discussion in ML about possibility of using it in Merlin [1], I've decided to change the plans for PoC: now the goal for Merlin's PoC is to implement Mistral Workbook builder on top of Barricade.js. The reasons for that are: * To better understand Barricade.js potential as data abstraction layer in Merlin, I need to learn much more about its possibilities and limitations than simple examining/reviewing of its source code allows. The best way to do this is by building upon it. * It's becoming too crowded in the HOT builder's sandbox - doing the same work as Drago currently does [2] seems like a waste of resources to me (especially in case he'll opensource his HOT builder someday just as he did with Barricade.js). Drago, it would be to everyone's benefit if your HOT builder efforts were developed on a public git repository, no matter how functional it is currently. Is there any chance you can publish what you're working on to https://github.com/dragorosson or rackerlabs for a start? * Why Mistral and not Murano or Solum? Because Mistral's YAML templates have simpler structure than Murano's ones do and is better defined at that moment than the ones in Solum. There already some commits in https://github.com/stackforge/merlin and since client-side app doesn't talk to the Mistral's server yet, it is pretty easy to run it (just follow the instructions in README.md) and then see it in browser at http://localhost:8080. UI is yet not great, as the current focus is data abstraction layer exploration, i.e. how to exploit Barricade.js capabilities to reflect all relations between Mistral's entities. I hope to finish the minimal set of features in a few weeks - and will certainly announce it in the ML. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-September/044591.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044186.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report
Hello all, I'm researching if we can use Rally project for some Fuel testing. It's part of 100-nodes blueprint[1]. To write some Rally scenario I used our Fuelclient library. In it's current state it's really painful to use and it's not usable as production tool. Here is the list of the biggest issues: 1. If API returns code other than 20x it exits. Literally it calls sys.exit(). It should just rise Exception. 2. Using API Client as a Singleton. In theory we can have more than one connection, but all new objects will use default connection. 3. Can not use keystone token. It requires user and password. Server address and all credentials can be given via config file or environment variables. There is no way to set it during client initialization. All this issues show that library was designed only with CLI in mind. Especially issue nr 1. Now I know why ostf doesn't use fuelcient, why Rally wrote their own client. And I can bet that MOX team is also using their own version. I'm aware of Fuelclient refactoring blueprint[1] I reviewed it and gave +1 to most of the reviews. Unfortunately it focuses on CLI usage. Move to Cliff is very good idea, but for library it actually makes things worse [2] like moving data validation to CLI or initializing object using single dictionary instead of normal arguments. I think instead of focusing on CLI usage we should focus on a library part. To make it easier to use by other programs. After that we can focus on CLI. It's very important now when we are planning to support 100 nodes and more in future because more and more users will start use Fuel via API instead of UI. What do you think about this? Regards, [1] https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient [2] https://review.openstack.org/#/c/117294/ Regards, -- Łukasz Oleś ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 15:11, Jay Pipes wrote: On 10/06/2014 08:30 AM, Ihar Hrachyshka wrote: Hi all, tl;dr we should enforce utf8 on server and client sides of db connection, and this requires changes to docs and oslo.db. The latter may require raising effective libpq version dep to 9.1+. Recently I was working on making sure we always run using utf8 on both database server and client side, and that we do it with all the proper connection options set (f.e. mysqldb requires use_unicode=0 to avoid performance drop - a thing that is not set anywhere in gate as of now, and not documented). For server side, it's a matter of how we create databases, and in devstack, it's usually utf8 (though, for unclear reason, latin1 is still enforced for nova for initial creation due to Folsom (sic!) bug; I've reverted to utf8 with [1]). For client side, it's not that clear. Though devstack enforces utf8 in SQL connection strings, we don't ask to do so in official docs [2]. There is a bug [3] in LP that seems to be relevant. I think the proper way is to enforce utf8 everywhere. The first step would be to make sure we suggest adding charset=utf8 to SQL connection strings, and configure SQL servers to use utf8. That is something to be covered by docs team. But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. So, the subject of this email is a bit misleading :) You are suggesting a change to the UTF-8 charset enforcement here, and below you are suggesting removing libpq9.1 for related reasons. I suppose setting of utf8 on the client side, and supporting utf8 on the server side, but I do *not* recommend using a blanket policy of charset=utf8 on every text column on the database side. It really is wasteful for certain columns like uuids that are used in joins all over the schema... Maybe it is indeed wasteful, I don't have numbers; though the fact is we don't allow any migrations for databases with any non utf8 tables as of [1]. The code was copied in multiple projects (Nova, Glance among other things). Also, the same check is present in oslo.db that is used by most projects now. Also we have migration rules in multiple projects that end up with converting all tables to utf8. F.e. it's done in Nova [2]. So we already run against utf8 tables. Though we don't ever tell users to create their databases with utf8 as default charset, opening a can of worms. We also don't ever tell users to at least set use_unicode=0 when running against MySQLdb (which is the default and the only supported MySQL driver as of Juno) to avoid significant performance drop [3] (same is true for oursql driver, but that one is at least not recommended to users thru official docs). [1]: https://review.openstack.org/#/c/64764/ [2]: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1539 [3]: http://docs.sqlalchemy.org/en/rel_0_9/dialects/mysql.html#module-sqlalchemy.dialects.mysql.mysqldb Best, -jay Though as you can see, the patch fails on py26 postgresql unit tests. This is because I set charset_encoding for PostgreSQL via libpq connection option that is available since PostgreSQL 9.1 only. The failure is because we run py26 test suite on CentOS 6.5 that still uses PostgreSQL 8.4.*, meaning the option is not available for us. Now, there are several other ways available for us to enforce encoding without using the option. First, we may set encoding thru PGCLIENTENCODING environment variable. Second, we may execute SET CLIENT_ENCODING TO utf8 after connecting to psql server. Now, the question is whether it's worth reimplementing the feature using some of the available hacks that will work with PSQL 9.1. We're about to drop Python 2.6 support in Kilo, and that probably means that CentOS 6.5 will be dropped from gate too. Do we have any other distribution of interest that uses both python 2.7 and psql 9.1, and is going to run Kilo pieces? On Red Hat side, we're not interested in running Juno on EL6 that uses old psql. As for EL7, it has a psql version that supports the connection option. On Ubuntu side, the only LTS release that is still supported and uses psql 9.1 is Lucid, but it's based on py26, so it should not be an issue. Any other consumers that could be affected by effectively raising minimum version bar for psql to 9.1 in Kilo? Though we've (almost) decided to drop py26 support in Kilo, we didn't have similar discussions for other components that we use. So I'd like to hear what's our take on that. Do we really drop *py26* support, or maybe what we really do is we drop *CentOS 6.5* support?.. On a more general note, do we track those kind of external dependencies
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
Bonjour Gauvain, Un gros bravo pour cette documentation sur Heat qui est très complète. Est-ce que par hasard vous auriez déjà une version française ? ;) Best, F. -Message d'origine- De : Gauvain Pocentek [mailto:gauvain.pocen...@objectif-libre.com] Envoyé : lundi 6 octobre 2014 07:06 À : Tom Fifield Cc : OpenStack Development Mailing List (not for usage questions); openstack-d...@lists.openstack.org Objet : Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can! Le 2014-10-06 05:26, Tom Fifield a écrit : On 04/10/14 04:03, Nick Chase wrote: On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org mailto:stef...@openstack.org wrote: 1. Pick an existing topic or create a new topic. For new topics, we're primarily interested in deployment scenarios. 2. Develop content (text and/or diagrams) in a format that supports at least basic markup (e.g., titles, paragraphs, lists, etc.). 3. Provide a link to the content (e.g., gist on github.com http://github.com, wiki page, blog post, etc.) under the associated topic. Points 1-3 seem to be oriented at removing Launchpad from the equation. Is that all there is? I guess it makes sense to remove obstacles, although editing the wiki (since it requires a launchpad account anyway) may not be the best way to track progress and see assignments. No, really, the main change is in step 5. Launchpad isn't the problem, as far as we can tell; Docbook is. Hi Nick, As best I can tell - 'step 5' has been in place for at least the last few summits at least, so this is not a change :) We have had a policy where anyone can dump text in bug reports and we'll wrangle it. This has been popular, see eg Marco Cossoni's contributions, but in my opinion not widely enough communicated - so thanks for your efforts. We actually have another way to work with developers, although it's been only available for the new HOT guide. This guide is temporary, it will become a part of the user guide. The interesting point is that it's written in RST, and uses gerrit for reviews. So far we've had 2 core members of the heat team contributing content, and this content has been reviewed by other members of the team. The devs patches focused on content, not on the form of the content. I suggested to accept the patches rapidly - as long as they're technically correct - and to rework them later (what I've started to do a couple days ago). The fact that we're using gerrit and that the developers review each other work makes me more comfortable with the quality of the content. I'd really like to see this process extended to a larger part of the documentation, although this might not be needed everywhere. I had this workflow in mind: * a dev sends a review to a temporary repo * other devs can validate the information, and give their +1 when the patch is ready * a doc reviewer either requests more technical detail, or gives his +2/accept * the doc team reworks the patch and integrates it to the doc repository I really think that the process worked for the HOT guide, and I'm convinced that it could work for other parts of the doc (Cinder and Neutron drivers doc for instance). As a side note, we have a tool that converts RST to docbook. The hot guide is automatically built using this tool (http://docs.openstack.org/hot-guide/content/hot_guide_hot-guide.html). Gauvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state
Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +: Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700: If we really want to go with this type of aproach we could also just copy the existing /etc/passwd into the image thats being built. Then when users are added they should be added in after existing users. I do like this approach, and it isn't one I had considered. We will know what image we want to update from in nearly every situation. Also this supports another case, which is rolling back to the previous image, quite well. Really this is just an automated form of static UID assignment. Now that ive proposed this id like to make an argument against the copy /etc/passwd as our long term solution (sorry). I do think its a not bad immediate fix, but long term id prefer actual static UID assignment out of the solutions proposed so far. It seems like determining how to build a new image based on the state of a previous image is an exact anti-pattern that read only / ephemeral instances aim to solve - minimize entropy collected over time from doing updates. Were also adding a requirement that user databases are now precious data which cannot ever be lost for a given image type. Its worth noting that these are both issues that operators will encounter. Static UID/GID assignment requires more developer work but AFAICT it passes less potential issues off onto operators (which should be our goal). Cheers, Greg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [Rally] Using fuelclient as a library - battle report
Hi Lukasz, I have the same thoughts - we have to design a good Python library for dealing with Nailgun and this library has to be used by: * Fuel CLI * System Tests * Fuel Upgrade * OSTF * other scripts But it's a big deal and we definetely should have a separate blueprint for this task. Moreover, we have to carefully consider its architecture to be convenient not only for CLI usage. Thanks, Igor On Mon, Oct 6, 2014 at 4:49 PM, Lukasz Oles lo...@mirantis.com wrote: Hello all, I'm researching if we can use Rally project for some Fuel testing. It's part of 100-nodes blueprint[1]. To write some Rally scenario I used our Fuelclient library. In it's current state it's really painful to use and it's not usable as production tool. Here is the list of the biggest issues: 1. If API returns code other than 20x it exits. Literally it calls sys.exit(). It should just rise Exception. 2. Using API Client as a Singleton. In theory we can have more than one connection, but all new objects will use default connection. 3. Can not use keystone token. It requires user and password. Server address and all credentials can be given via config file or environment variables. There is no way to set it during client initialization. All this issues show that library was designed only with CLI in mind. Especially issue nr 1. Now I know why ostf doesn't use fuelcient, why Rally wrote their own client. And I can bet that MOX team is also using their own version. I'm aware of Fuelclient refactoring blueprint[1] I reviewed it and gave +1 to most of the reviews. Unfortunately it focuses on CLI usage. Move to Cliff is very good idea, but for library it actually makes things worse [2] like moving data validation to CLI or initializing object using single dictionary instead of normal arguments. I think instead of focusing on CLI usage we should focus on a library part. To make it easier to use by other programs. After that we can focus on CLI. It's very important now when we are planning to support 100 nodes and more in future because more and more users will start use Fuel via API instead of UI. What do you think about this? Regards, [1] https://blueprints.launchpad.net/fuel/+spec/refactoring-for-fuelclient [2] https://review.openstack.org/#/c/117294/ Regards, -- Łukasz Oleś ___ 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] Dependency freeze exception: Jinja2 needs to be = 2.6 for murano-dashboard
Hi, Trying to build murano-dashboard in Wheezy didn't work unless I wrote a backported package of the Sid version. So it's looking like murano-dashboard needs version 2.6 of Jinja2. See the murano-dashboard review: https://review.openstack.org/#/c/125565/ and the one for our global-requirements.txt: https://review.openstack.org/#/c/125651/ For Ubuntu, even Precise has 2.6. Jinja2=2.6 is *very* old already, so I don't think it's a problem in general. Does anyone has a concern? If you don't, please review the above patches. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Test verifying that models are in sync with migrations landed
Hi everyone! I want to bring to everyone's attention that now Neutron has test that checks that migrations create the same scheme that mentioned in models. Docs with explanation of its usage are shown here [1]. Now this is unittest, but it is expected to be moved to functional [2]. Anyway if you have migration in your change, you can expect jobs gate-neutron-python26, gate-neutron-python27 (now) and check-neutron-dsvm-functional (when [2] lands) to fail if you did something wrong in it. If you have some questions about usage I am available on irc (akamyshnikova) and via email. [1] - http://docs.openstack.org/developer/neutron/devref/db_layer.html [2] - https://review.openstack.org/126175 Regars, Ann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dependency freeze exception: Jinja2 needs to be = 2.6 for murano-dashboard
On 2014-10-06 22:15:26 +0800 (+0800), Thomas Goirand wrote: Trying to build murano-dashboard in Wheezy didn't work unless I wrote a backported package of the Sid version. So it's looking like murano-dashboard needs version 2.6 of Jinja2. [...] We've generally not seen StackForge project needs as a valid justification for changes to official OpenStack requirements. Perhaps this is an indication that murano-dashboard needs to join an official program? -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla] kolla, keystone, and endpoints (oh my!)
Hello all,
I wanted to expand on a discussion we had in #tripleo on Friday
regarding Kubernetes and the Keystone service catalog.
## The problem
The essential problem is that Kubernetes and Keystone both provide
service discovery mechanisms, and they are not aware of each other.
Kubernetes provides information about available services through
Docker environment variables, whereas Keystone maintains a list of API
endpoints in a database.
When you configure the keystone endpoints, it is tempting to simply
use the service environment variables provided by Kubernetes, but this
is problematic: the variables point at the host-local kube-proxy
instance. This is a problem right now because if that host were to
go down, that endpoint would no longer be available. That will be a
problem in the near future because the proxy address will soon be
pod-local, and thus inaccessible from other pods (even on the same
host).
One could instrument container start scripts to replace endpoints in
keystone when the container boots, but if a service has cached
information from the catalog it may not update in a timely fashion.
## The (?) solution
I spent some time this weekend experimenting with setting up a
pod-local proxy that takes all the service information provided by
Kubernetes and generates an haproxy configuration (and starts haproxy
with that configuration):
- https://github.com/larsks/kolla/tree/larsks/hautoproxy/docker/hautoproxy
This greatly simplifies the configuration of openstack service
containers: in all cases, the remote address of another service will
be at http://127.0.0.1/, so you can simply configure that address into
the keystone catalog.
It requires minimal configuration: you simply add the hautproxy
container to your pod.
This seems to do the right thing in all situations: if a pod is
rescheduled on another host, the haproxy configuration will pick up
the appropriate service environment variables for that host, and
services inside the pod will contain to use 127.0.0.1 as the remote
address.
If you use the .json files from
https://github.com/larsks/kolla/tree/larsks/hautoproxy, you can see
this in action. Specifically, if you start the services for mariadb,
keystone, and glance, and then start the corresponding ponds, you will
end up with functional keystone and glance services.
Here's a short script that will do just that:
#!/bin/sh
for x in glance/glance-registry-service.json \
glance/glance-api-service.json \
keystone/keystone-public-service.json \
keystone/keystone-admin-service.json \
mariadb/mariadb-service.json; do
kubecfg -c $x create services
done
for x in mariadb/mariadb.json \
keystone/keystone.json \
glance/glance.json; do
kubecfg -c $x create pods
done
With this configuration running, you can kill the keystone pod and allow
Kubernetes to reschedule it and glance will continue to operate correctly.
You cannot kill either the glance or mariadb pods because we do not
yet have a solution for persistent storage.
I will be cleaning up these changes and submitting them for review...but
probably not today due to an all-day meeting.
--
Lars Kellogg-Stedman l...@redhat.com | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpF2TOt3UsIt.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
Hi François, I guess this mail was directed to me personally but I'll answer here, this might be useful for the translation teams. There's no existing translation for the HOT guide yet, and I'm not sure that now is the best time to get started. The (temporary standalone) HOT guide will end up as a user guide section, in docbook (not RST). I'm currently rewriting some sections and more content will be added soon, so expect lots of modifications. As soon as it's ready to be officially published in the user guide, the translation tools will import the docbook strings in transifex (that's the plan at least). Gauvain Le 2014-10-06 16:05, François Bureau a écrit : Bonjour Gauvain, Un gros bravo pour cette documentation sur Heat qui est très complète. Est-ce que par hasard vous auriez déjà une version française ? ;) Best, F. -Message d'origine- De : Gauvain Pocentek [mailto:gauvain.pocen...@objectif-libre.com] Envoyé : lundi 6 octobre 2014 07:06 À : Tom Fifield Cc : OpenStack Development Mailing List (not for usage questions); openstack-d...@lists.openstack.org Objet : Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can! Le 2014-10-06 05:26, Tom Fifield a écrit : On 04/10/14 04:03, Nick Chase wrote: On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org mailto:stef...@openstack.org wrote: 1. Pick an existing topic or create a new topic. For new topics, we're primarily interested in deployment scenarios. 2. Develop content (text and/or diagrams) in a format that supports at least basic markup (e.g., titles, paragraphs, lists, etc.). 3. Provide a link to the content (e.g., gist on github.com http://github.com, wiki page, blog post, etc.) under the associated topic. Points 1-3 seem to be oriented at removing Launchpad from the equation. Is that all there is? I guess it makes sense to remove obstacles, although editing the wiki (since it requires a launchpad account anyway) may not be the best way to track progress and see assignments. No, really, the main change is in step 5. Launchpad isn't the problem, as far as we can tell; Docbook is. Hi Nick, As best I can tell - 'step 5' has been in place for at least the last few summits at least, so this is not a change :) We have had a policy where anyone can dump text in bug reports and we'll wrangle it. This has been popular, see eg Marco Cossoni's contributions, but in my opinion not widely enough communicated - so thanks for your efforts. We actually have another way to work with developers, although it's been only available for the new HOT guide. This guide is temporary, it will become a part of the user guide. The interesting point is that it's written in RST, and uses gerrit for reviews. So far we've had 2 core members of the heat team contributing content, and this content has been reviewed by other members of the team. The devs patches focused on content, not on the form of the content. I suggested to accept the patches rapidly - as long as they're technically correct - and to rework them later (what I've started to do a couple days ago). The fact that we're using gerrit and that the developers review each other work makes me more comfortable with the quality of the content. I'd really like to see this process extended to a larger part of the documentation, although this might not be needed everywhere. I had this workflow in mind: * a dev sends a review to a temporary repo * other devs can validate the information, and give their +1 when the patch is ready * a doc reviewer either requests more technical detail, or gives his +2/accept * the doc team reworks the patch and integrates it to the doc repository I really think that the process worked for the HOT guide, and I'm convinced that it could work for other parts of the doc (Cinder and Neutron drivers doc for instance). As a side note, we have a tool that converts RST to docbook. The hot guide is automatically built using this tool (http://docs.openstack.org/hot-guide/content/hot_guide_hot-guide.html). Gauvain ___ 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] Dependency freeze exception: django-nose needs to be = 1.2 for murano-dashboard
On 10/06/2014 10:21 PM, Jeremy Stanley wrote: On 2014-10-06 22:15:26 +0800 (+0800), Thomas Goirand wrote: Trying to build murano-dashboard in Wheezy didn't work unless I wrote a backported package of the Sid version. So it's looking like murano-dashboard needs version 2.6 of Jinja2. [...] We've generally not seen StackForge project needs as a valid justification for changes to official OpenStack requirements. Perhaps this is an indication that murano-dashboard needs to join an official program? Sorry, it's getting late, and I'm overworking ... The issue here, for murano-dashboard is with django-nose that needs to be = 1.2. Though there's also the need to use jinja = 2.6, but that's for another project, and I can't remember which one. When I do, I'll open a new thread. In both case, this was wired into my Debian packages, but IMO, our global-requirements.txt got to reflect the reality. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dependency freeze exception: jinja2 needs to be = 2.6 for designate (was: Dependency freeze exception: django-nose needs to be = 1.2 for murano-dashboard)
On 10/06/2014 11:00 PM, Thomas Goirand wrote: Though there's also the need to use jinja = 2.6, but that's for another project, and I can't remember which one. When I do, I'll open a new thread. Now I remember. Or rather, my IRC bouncer log did ... The issue with jinja2 needs to be = 2.6 is in Designate. Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 06/10/14 06:07, Thierry Carrez wrote: Jay Pipes wrote: On 10/03/2014 09:18 PM, Zane Bitter wrote: The prospect of a much larger tent with many more projects in OpenStack-proper shines a spotlight on the scalability of the Docs team, and in particular how they decide which projects are important to work on directly. I don't believe that a ticket to live under the OpenStack tent should come with the expectation that the Docs team is required to write documentation for the project. IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. I'd like to generalize that beyond Docs, because the same issue applies to all other horizontal teams. There are multiple ways an horizontal team can declare its commitment, and I agree we should never assume that a TC decision (new integrated project!) implies more work for the team (Docs now has to support this as well). That's the way it currently works, and yes, it doesn't scale. It didn't scale early with Docs, so they opted out of supporting all integrated projects early on. So in summary: - ticket to live under the OpenStack big tent should never come with expectation that any horizontal team will do the work for that project directly - horizontal teams may decide to directly do the work for any number of projects - corollary #1: horizontal teams may decide to commit to directly doing the work for a mostly-static ring0 (or not) - corollary #2: horizontal teams may decide to not directly do the work for any project - horizontal teams should build processes and tools to facilitate and guide the work of projects in the big tent in their area of expertise +1 So it seems like there is general agreement that we don't need/want the TC to tell horizontal teams what to work on, and that isn't one of the reasons for ring0/ring compute/Layer 1 to be a thing? cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ETSI NFV gap analysis [NFV]
I believe pointing it to the NFV Wiki would be good and that way it can be discussed during one of the weekly meetings run by Steven et.al and match the list to what is being requested to what is identified in the wiki list as a good starting point. /Alan -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: October-06-14 9:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] ETSI NFV gap analysis [NFV] Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a écrit : Team, Following my action item from last week IRC. It seems that the document is ready for submission by ETSI NFV team. It was written in a liaison form as this is how they are used to operate. They are wondering who should they send it to... IMHO it seems a good idea that the NFV sub group will receive it in behalf of the community. Thoughts? Itai I don't know the legal conditions of the publication of this document, but I would assume it would be worth of interest within the whole OpenStack community so anyone could see what's missing and contribute to it. At least pointing the document to the NFV wiki page sounds important, provided this communication can be done this way (ie. no opt-in list for people looking at the doc) -Sylvain Sent from my iPhone ___ 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] sign up for oslo liaisons for kilo cycle
The Oslo team is responsible for managing code shared between projects. There are a LOT more projects than Oslo team members, so we created the liaison program at the beginning of the Juno cycle, asking each team that uses Oslo libraries to provide one volunteer liaison. Our liaisons facilitate communication and work with us to make the application code changes needed as code moves out of the incubator and into libraries. With this extra help in place, we were able to successfully graduate 7 new libraries and begin having them adopted across OpenStack. With the change-over to the new release cycle, it’s time to ask for volunteers to sign up to be liaisons again. If you are interested in acting as a liaison for your project, please sign up on the wiki page [1]. It would be very helpful to have a full roster before the summit, so we can make sure liaisons are invited to participate in any relevant discussions there. Thanks, Doug [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][gate] configurable quota threshold warnings?
I'm floating this in case the idea has come up before. I've spent most of my day so far digging through logs and code for gate race bug 1353962 [1] where an admin tenant is going over-quota when trying to allocate fixed IPs for a test instance (the test setup creates 2 instances and more test instances are created in some of the test cases). I'm going to push up some patches to nova to make the logs more useful when we hit this, i.e. log the quota limit and current usage for the given resource (fixed_ips in this case). But the idea that keeps coming up when I'm digging into stuff like this is it'd be nice to know when we're nearing over-quota so we can walk that back and figure out what was going on prior to us falling over the cliff. This isn't a novel idea, but I haven't heard it discussed before. What I'm thinking is basically add a config option for setting a threshold value which would dump warnings when you're over that threshold. This could be configured per resource, e.g. I only care about fixed_ips, instances, etc. It could be configured per tenant (maybe we only care about this for the admin tenant?). My use case would be specifically related to the bug in question, so I want to set the threshold at let's say 80%. With a default fixed_ips quota of 10, when I've gotten over 8 reserved for the admin tenant, I start logging warnings that I'm nearing over-quota. When we go over-quota on a request, we could then see what operations/requests were going on before this that tipped us over. Thoughts? [1] https://bugs.launchpad.net/nova/+bug/1353962 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral] Team meeting minutes 10/06/2014
Thanks everyone for participating the meeting today! In case you’d like to see what we discussed, here’s Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-10-06-16.00.html http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-10-06-16.00.html Meeting full log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-10-06-16.00.log.html The next meeting is scheduled for Oct 13. -- Best Regards, Nikolay @Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Candidate proposals for TC (Technical Committee) positions are now open
On Oct 3, 2014, at 11:38 AM, Tristan Cacqueray tristan.cacque...@enovance.com wrote: Candidate proposals for the Technical Committee positions (6 positions) are now open and will remain open until 05:59 UTC October 10, 2014. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. [0] (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen) [1] Propose your candidacy by sending an email to the openstack-dev at lists.openstack.org mailing-list, with the subject: TC candidacy. Please start your own thread so we have one thread per candidate. Since there will be many people voting for folks with whom they might not have worked, including a platform or statement to help voters make an informed choice is recommended, though not required. NEW: In order to help the electorate learn more about the candidates we have posted a template of questions to which all candidates are requested to respond. [2] Anita and I will confirm candidates with an email to the candidate thread as well as create a link to the confirmed candidate's proposal email on the wikipage for this election. [1] The election will be held from October 10 through to 13:00 UTC October 17, 2014. The electorate are the Foundation individual members that are also committers for one of the official programs projects [3] over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC), as well as the extra-ATCs who are acknowledged by the TC. [4] Please see the wikipage for additional details about this election. [1] If you have any questions please be sure to either voice them on the mailing list or email Anita or myself [5] or contact Anita or myself on IRC. Thank you, and I look forward to reading your candidate proposals, Tristan [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee [1] https://wiki.openstack.org/wiki/TC_Elections_October_2014 [2] https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions [3] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections Note the tag for this repo, sept-2014-elections. [4] http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections [5] Anita: anteaya at anteaya dot info Tristan: tristan dot cacqueray at enovance dot com Could you elaborate a bit on the question How would you characterize the various facets of contributor motivation?” Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Candidate proposals for TC (Technical Committee) positions are now open
On 10/03/2014 12:16 PM, Flavio Percoco wrote: On 10/03/2014 05:38 PM, Tristan Cacqueray wrote: Candidate proposals for the Technical Committee positions (6 positions) are now open and will remain open until 05:59 UTC October 10, 2014. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. [0] (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen) [1] Propose your candidacy by sending an email to the openstack-dev at lists.openstack.org mailing-list, with the subject: TC candidacy. Please start your own thread so we have one thread per candidate. Since there will be many people voting for folks with whom they might not have worked, including a platform or statement to help voters make an informed choice is recommended, though not required. NEW: In order to help the electorate learn more about the candidates we have posted a template of questions to which all candidates are requested to respond. [2] Anita and I will confirm candidates with an email to the candidate thread as well as create a link to the confirmed candidate's proposal email on the wikipage for this election. [1] The election will be held from October 10 through to 13:00 UTC October 17, 2014. The electorate are the Foundation individual members that are also committers for one of the official programs projects [3] over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC), as well as the extra-ATCs who are acknowledged by the TC. [4] Please see the wikipage for additional details about this election. [1] If you have any questions please be sure to either voice them on the mailing list or email Anita or myself [5] or contact Anita or myself on IRC. Thank you, and I look forward to reading your candidate proposals, Tristan [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee [1] https://wiki.openstack.org/wiki/TC_Elections_October_2014 [2] https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions [3] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections Note the tag for this repo, sept-2014-elections. [4] http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections [5] Anita: anteaya at anteaya dot info Tristan: tristan dot cacqueray at enovance dot com Greetings, I'd like to take this chance to gently ask, but it's obviously not a requirement, to all candidates to share what their opinion with regards to the new governance discussion is in their candidacy. As a voter, I'm interested to know how the new candidates see our governance model in the next 6 months and what changes, related to the big tent discussion, they consider most important. Thanks, Flavio Hi Flavio: I had purposely not mentioned the organizational changes in the templated questions (which are brand new this time, so these are the guinea pig candidates). One of the things people are looking for is leaders. At campaign time folks with strong stances prevail. However it is the ability to listen and consider the opinions of others, especially when disagreement arises, that makes our TC as strong as it has been and hopefully will be in future. Everyone is enjoying the drama of the changes and yes they are dramatic, but equally if not more important is the work that will have to take place using listening and consideration skills in order to turn decisions into outcomes. Listening is an incredibly important leadership skill but doesn't get much air time during campaigns. If you look at really effective leaders though they are listeners, every one. Listeners also rarely state that is what they are doing, since they are busy listening. Any candidate is welcome to say anything they wish in their candidate statement. I appreciate that you are interested in their opinions about the new governance model, Flavio, and I appreciate you speaking up about it. But regardless of what decisions are made, what structure is decided upon and what that structure and its parts are called, we need people with the ability to listen, consider, and work very hard to put any of these decisions in place in order for them to succeed. We have a problem of incredible growth in OpenStack. Our growth is a manifestation of all we are doing correctly. I hope that the questions asked in the templates bring out the qualities I know each candidate is capable of, that ensure we have a group of leaders with the skills necessary to make agreements and produce results, regardless of the shape and colour of those agreements and results. Thank you, Anita. ___ OpenStack-dev mailing list
Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state
Excerpts from Gregory Haynes's message of 2014-10-06 07:06:02 -0700: Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +: Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700: If we really want to go with this type of aproach we could also just copy the existing /etc/passwd into the image thats being built. Then when users are added they should be added in after existing users. I do like this approach, and it isn't one I had considered. We will know what image we want to update from in nearly every situation. Also this supports another case, which is rolling back to the previous image, quite well. Really this is just an automated form of static UID assignment. Now that ive proposed this id like to make an argument against the copy /etc/passwd as our long term solution (sorry). I do think its a not bad immediate fix, but long term id prefer actual static UID assignment out of the solutions proposed so far. We have to be _extremely_ careful in how we manage this. I actually think it has potential to really blow up in our faces. We need to give people a way to move forward without us merging a patch, and at the same time we need to make sure we provide a consistent set of UIDs for anything people may want to deploy with diskimage-builder. It seems like determining how to build a new image based on the state of a previous image is an exact anti-pattern that read only / ephemeral instances aim to solve - minimize entropy collected over time from doing updates. Were also adding a requirement that user databases are now precious data which cannot ever be lost for a given image type. Its worth noting that these are both issues that operators will encounter. I disagree with some of these points. Expecting Linux filesystems to be consumable from any machine without a source of consistent UIDs/GIDs is the anti-pattern. Using /etc/passwd and /etc/group from the previous image is just one such source, and it is one source that anybody who has a previous image will always have. If you've deployed using TripleO's tools already, you will not have the same UIDs that our centralized UID registry would have. We could also just deploy FreeIPA on all controllers, delay UID allocations, and put everything in LDAP. Having our own special project for static UIDs feels like a third possible implementation, not one I'm ready to say is the way. I'm leaning more toward keeping a copy of the UID/GID/symbolic-name database anywhere that has state, and use a guard against making use of a system database which conflicts with existing mappings on the state drive. Then we can use either a static UID project, or previous images, as the source of UIDs/GIDs for new images, to avoid hitting the guard. Static UID/GID assignment requires more developer work but AFAICT it passes less potential issues off onto operators (which should be our goal). +1 for making this as painless as possible on operators. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
I personally believe that delegating the task of documentation to individual projects would be a huge mistake for one big reason: documentation exists to understand how everything works within the context of the solution as a whole. Very hard to do that consistently across all projects with the docs team entrenched in developing individual products. Plus, enterprise adoption of the open cloud *requires* documentation that isn't an after thought. Writing code and trying to set aside some time to document is the sheer definition of turning documentation an afterthought - and no superior product has ever come from that sort of model. *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Mon, Oct 6, 2014 at 8:40 AM, Zane Bitter zbit...@redhat.com wrote: On 06/10/14 06:07, Thierry Carrez wrote: Jay Pipes wrote: On 10/03/2014 09:18 PM, Zane Bitter wrote: The prospect of a much larger tent with many more projects in OpenStack-proper shines a spotlight on the scalability of the Docs team, and in particular how they decide which projects are important to work on directly. I don't believe that a ticket to live under the OpenStack tent should come with the expectation that the Docs team is required to write documentation for the project. IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. I'd like to generalize that beyond Docs, because the same issue applies to all other horizontal teams. There are multiple ways an horizontal team can declare its commitment, and I agree we should never assume that a TC decision (new integrated project!) implies more work for the team (Docs now has to support this as well). That's the way it currently works, and yes, it doesn't scale. It didn't scale early with Docs, so they opted out of supporting all integrated projects early on. So in summary: - ticket to live under the OpenStack big tent should never come with expectation that any horizontal team will do the work for that project directly - horizontal teams may decide to directly do the work for any number of projects - corollary #1: horizontal teams may decide to commit to directly doing the work for a mostly-static ring0 (or not) - corollary #2: horizontal teams may decide to not directly do the work for any project - horizontal teams should build processes and tools to facilitate and guide the work of projects in the big tent in their area of expertise +1 So it seems like there is general agreement that we don't need/want the TC to tell horizontal teams what to work on, and that isn't one of the reasons for ring0/ring compute/Layer 1 to be a thing? cheers, Zane. ___ 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] Candidate proposals for TC (Technical Committee) positions are now open
On 10/06/2014 12:35 PM, Doug Hellmann wrote: On Oct 3, 2014, at 11:38 AM, Tristan Cacqueray tristan.cacque...@enovance.com wrote: Candidate proposals for the Technical Committee positions (6 positions) are now open and will remain open until 05:59 UTC October 10, 2014. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. [0] (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen) [1] Propose your candidacy by sending an email to the openstack-dev at lists.openstack.org mailing-list, with the subject: TC candidacy. Please start your own thread so we have one thread per candidate. Since there will be many people voting for folks with whom they might not have worked, including a platform or statement to help voters make an informed choice is recommended, though not required. NEW: In order to help the electorate learn more about the candidates we have posted a template of questions to which all candidates are requested to respond. [2] Anita and I will confirm candidates with an email to the candidate thread as well as create a link to the confirmed candidate's proposal email on the wikipage for this election. [1] The election will be held from October 10 through to 13:00 UTC October 17, 2014. The electorate are the Foundation individual members that are also committers for one of the official programs projects [3] over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC), as well as the extra-ATCs who are acknowledged by the TC. [4] Please see the wikipage for additional details about this election. [1] If you have any questions please be sure to either voice them on the mailing list or email Anita or myself [5] or contact Anita or myself on IRC. Thank you, and I look forward to reading your candidate proposals, Tristan [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee [1] https://wiki.openstack.org/wiki/TC_Elections_October_2014 [2] https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions [3] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections Note the tag for this repo, sept-2014-elections. [4] http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections [5] Anita: anteaya at anteaya dot info Tristan: tristan dot cacqueray at enovance dot com Could you elaborate a bit on the question How would you characterize the various facets of contributor motivation?” Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Doug: Sure. The reasons for a contributor's actions affect their actions. I'm interested in hearing what you perceive to be the outcomes of various contributor actions. For instance, in the third party space, contributors consistently do certain things which affect the whole community and they are regularly oblivious to it. It is a very specific and predictable pattern. The source of the pattern of behaviour stems from their reasons for contributing, every single one has the same response when asked about why they are doing what they are doing. I'm interested in hearing what a given candidate's experience is with the patterns of behaviour of various contributors. My hope is that perhaps after the election, if any patterns seem to be OpenStack wide they can be discussed, from the point of view of motivation. I hope that sheds more light on the nature of the question without projecting too much of my own experience here. Do ask again if I missed the mark. Thanks Doug, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 10/06/2014 12:44 PM, Adam Lawson wrote: I personally believe that delegating the task of documentation to individual projects would be a huge mistake for one big reason: documentation exists to understand how everything works within the context of the solution as a whole. Very hard to do that consistently across all projects with the docs team entrenched in developing individual products. Plus, enterprise adoption of the open cloud /requires/ documentation that isn't an after thought. Writing code and trying to set aside some time to document is the sheer definition of turning documentation an afterthought - and no superior product has ever come from that sort of model. I hear your concerns about the possibility of getting documentation that is either inconsistent (with respect to the other OpenStack projects) or not written for the right audience if we only have developer contributors writing documentation. You have an excellent and prescient point. However, with my proposal, I was only saying that being under the OpenStack tent should not come with an automatic gift of resources from the excellent OpenStack Docs horizontal team. This process cannot scale. Instead, I believe it should be incumbent on the joining project to provide resources to work *with* the horizontal Docs team to provide foundational documentation for end users and operators. The Docs team can and should be advisors to the project contributors in how to write effective documentation targeted at non-developer contributors. In addition, please see my proposal that projects applying to be in the OpenStack tent would have a requirement to name both a Docs liaison as well as a Release Management liaison. [1] Best, -jay [1] http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstacl] [Glance] Container format
Hi all, is there a reason that specifying a 'bare' container format option is required from the operator given it isn't used by any Openstack services? [1] [1] http://docs.openstack.org/trunk/install-guide/install/apt/content/glance-verify.html (step4) *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
On Oct 6, 2014, at 9:56 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: But we can do better. We should also enforce utf8 on client side, so that there is no way to run with a different encoding, and so that we may get rid of additional options in sql connection strings. I've sent a patch for oslo.db [4] to do just that. i would recommend that we definitely do *not* set explicit client encodings on all columns, and go with the most minimal approach for whatever the target database is.For example, with Postgresql 8.4, utf-8 is not an issue so long as client_encoding is set within postgresql.conf.I’ve had this kind of discussion many times in the past with folks who are trying to “protect” some subset of users that don’t have this setting in their conf file, either because they installed from an OSX package or some other weird reason, and generally I’m not buying it.There’s no need to build tremendous verbosity and fine-grained specificity throughout a system in order to appease very narrow edge cases like this. It’s not just about potential performance problems, it’s also just a schema and code management issue, in that it is complexity that IMHO is just not needed. For this reason I’m pretty ambivalent overall about any kind of utf-8 hardcoding within the application connection logic. IMHO this should be handled at the configurational layer as much as possible. Though as long as it’s just an application time setting, and not something hardwired throughout the schema (implying we now have to *rely* upon UTF-8 encoding explicitly for all columns everywhere…and then what happens if we are on some target database that doesn’t quite do things the same way, e.g. DB2, oracle, others?), it’s not *too* big of a deal for me if it solves some problems right now. short answer, there should be no need to drop PG8.X support for this reason. If the client encoding setting is something we want hardcoded in the app layer and it fails for those versions (which I’m not familiar with? what is the thing that is not actually supported prior to libpq 9.1 ? psycopg2’s set_client_encoding, really? this doesn’t sound familiar two me), we can detect that and forego the setting - sqlalchemy dialect has server_version_info for this reason. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Suggestions for students final year project
My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Suggestions for students final year project
On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Patricia: This is going to be a tough one for anyone to reply to since noone knows who you are, your interests or what you've done. My best suggestion is to hop onto irc's freenode server and join #openstack-dev as well as any other channel on this list that catches your eye: https://wiki.openstack.org/wiki/IRC The first thing you will have to do is learn our workflow, which is really specific and is the same across all projects: http://docs.openstack.org/infra/manual/developers.html You can also look at attending some meetings: https://wiki.openstack.org/wiki/Meetings and find something that you like. Logs for meetings and channels are here: http://eavesdrop.openstack.org/ I hope you can find something that interests you. Thanks Patricia, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Broken coverage jobs
When you propose a job to OpenStack, you're all familiar with the usual
check and gate job. There're also so-called post jobs. These are jobs
that are run after a job has been merged. One group of these post jobs
are publishing documents to docs.openstack.org, others run coverage
tests to record the coverage of the testsuite for a project.
Unfortunately, there's no easy way for failures in post jobs to inform
the project about failures (see also [1]).
I've been looking at failures of post jobs and noticed that many of the
coverage jobs are completely broken.
With broken I mean: The infra scripts call tox -e cover and I found
these problems:
* no tox environment called cover
* coverage package not in requirements
* Scripts called by cover are not available
I've changed now the default python-jobs template for all jobs to not
include the coverage job anymore and added to those projects using
python-jobs the coverage job manually if they have a working setup
[2]. I now double checked all projects that had a coverage job (some
have them even without using python-jobs) and proposed a patch to remove
the coverage job [3].
So, if you want to have coverage on a project, do the following:
* check that tox -e cover works locally and if not fix the failures
* sent a patch to project-config adding the coverage job to your project.
To check what post jobs run, install git os-job [4][5] and run it like:
$ cd python-cinderclient
$ git os-job
which opened for me a webbrowser window with the following URL:
http://logs.openstack.org/89/892b739f4a50f34bc669b1be30503e823310f7f1/
and clicking through it, you find the coverage html page at:
http://logs.openstack.org/89/892b739f4a50f34bc669b1be30503e823310f7f1/post/python-cinderclient-coverage/3f2a9e9/cover/
Btw. some coverage jobs are running fine but still fail, for example
since no data is collected or due to other failures.
So, for those projects without coverage job: Once you fixed tox -e
cover, feel free to send a patch for project-config to enable it. I'll
happily review ;)
Andreas
P.S. Since I just cleaned this up: If you need help to enable the job,
feel free to email me and I'll take care of it.
References
[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047560.html
[2] https://review.openstack.org/#/c/125395/
[3] https://review.openstack.org/#/c/126155/
[4] https://github.com/dhellmann/git-os-job
[5]
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015422.html
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Suggestions for students final year project
On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Patricia, I am Keystone core developer. I have several ideas. It really depends on your skills and interests. Are you a security person? If not, are you a web development type person? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
I like your suggestion about the Docs team being advisors. I would submit however (my opinion here) that whether or not there are enough resources on the Doc'n team to handle Openstack's current list of integrated programs, offloading the work to individual projects exchanges one challenge (scalability) with another problem (quality). Using that approach, doc bugs will get triaged with the other project bugs and potentially distracts developers from doing what they do best - writing and fixing code. And what happens when you only have time to fix a feature or work on documentation? Focus on features and performance/stability are going to win. Every time. And they should because that what the program teams should be focused on. That means we start down the road heavy on code because developers can't do everything, making them light on documentation forcing a catch-up process to ensure which requires a special team to preserve momentum, bringing us back to where we are now. I've been there before. And I'm sure others have as well. I've always been a big proponent of exploiting strengths vs building on weaknesses and I'm going to step out on a limb here and speak to strengths which may get me into hot water with some so I want to apologize in advance. ; ) If a team of developers is tasked to produce all of the documentation for enterprise consumers, I hate to say it like this but you'll end up with highly-targeted documentation that makes sense to a developer and possibly low-level engineers. That level of detail is probably best served in README, wikis and mailing lists. It isn't effective as a user's manual. Even with coaching, we'd be coaching folks to do things they aren't good at. Same goes for a solution architect writing documentation the other way around - you end up with documentation that speaks so broad, it fails to make the impact that a targeted/focused approach is needed by the engineering consumers. While documentation produced by each individual project makes a special kind of impact, it must be one spoke - not the entire wheel. I love the idea of advisors and they should provide the first draft but I also believe a dedicated team is needed to ensure quality doesn't suffer. *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Mon, Oct 6, 2014 at 9:59 AM, Jay Pipes jaypi...@gmail.com wrote: On 10/06/2014 12:44 PM, Adam Lawson wrote: I personally believe that delegating the task of documentation to individual projects would be a huge mistake for one big reason: documentation exists to understand how everything works within the context of the solution as a whole. Very hard to do that consistently across all projects with the docs team entrenched in developing individual products. Plus, enterprise adoption of the open cloud /requires/ documentation that isn't an after thought. Writing code and trying to set aside some time to document is the sheer definition of turning documentation an afterthought - and no superior product has ever come from that sort of model. I hear your concerns about the possibility of getting documentation that is either inconsistent (with respect to the other OpenStack projects) or not written for the right audience if we only have developer contributors writing documentation. You have an excellent and prescient point. However, with my proposal, I was only saying that being under the OpenStack tent should not come with an automatic gift of resources from the excellent OpenStack Docs horizontal team. This process cannot scale. Instead, I believe it should be incumbent on the joining project to provide resources to work *with* the horizontal Docs team to provide foundational documentation for end users and operators. The Docs team can and should be advisors to the project contributors in how to write effective documentation targeted at non-developer contributors. In addition, please see my proposal that projects applying to be in the OpenStack tent would have a requirement to name both a Docs liaison as well as a Release Management liaison. [1] Best, -jay [1] http://www.joinfu.com/2014/09/answering-the-existential- question-in-openstack/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management
Hello All, I wanted to start a discussion on floating IP management and ultimately decide how the LBaaS group wants to handle the association. There is a need to utilize floating IPs(FLIP) and its API calls to associate a FLIP to the neutron port that we currently spin up. See DOCS here: http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_create.html Currently, LBaaS will make internal service calls (clean interface :/) to create and attach a Neutron port. The VIP from this port is added to the Loadbalancer object of the Load balancer configuration and returned to the user. This creates a bit of a problem if we want to associate a FLIP with the port and display the FLIP to the user instead of the ports VIP because the port is currently created and attached in the plugin and there is no code anywhere to handle the FLIP association. To keep this short and to the point: We need to discuss where and how we want to handle this association. I have a few questions to start it off. Do we want to add logic in the plugin to call the FLIP association API? If we have logic in the plugin should we have configuration that identifies weather to use/return the FLIP instead the port VIP? Would we rather have logic for FLIP association in the drivers? If logic is in the drivers would we still return the port VIP to the user then later overwrite it with the FLIP? Or would we have configuration to not return the port VIP initially, but an additional query would show the associated FLIP. Is there an internal service call for this, and if so would we use it instead of API calls? Theres plenty of other thoughts and questions to be asked and discussed in regards to FLIP handling, hopefully this will get us going. I'm certain I may not be completely understanding this and is the hopes of this email to clarify any uncertainties. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq 9.1
On Mon, Oct 06, 2014, Ihar Hrachyshka ihrac...@redhat.com wrote: Maybe it is indeed wasteful, I don't have numbers; though the fact is we don't allow any migrations for databases with any non utf8 tables as of [1]. The code was copied in multiple projects (Nova, Glance among other things). Also, the same check is present in oslo.db that is used by most projects now. Also we have migration rules in multiple projects that end up with converting all tables to utf8. F.e. it's done in Nova [2]. So we already run against utf8 tables. Though we don't ever tell users to create their databases with utf8 as default charset, opening a can of worms. We also don't ever tell users to at least set use_unicode=0 when running against MySQLdb (which is the default and the only supported MySQL driver as of Juno) to avoid significant performance drop [3] (same is true for oursql driver, but that one is at least not recommended to users thru official docs). This is a situation where Openstack is frustratingly inconsistent. While we don't provide any guidance about the default charset, Nova now creates all tables with the utf8 charset and provided a migration[1] to fix deployments done before this change. The same cannot be said for Glance. It inherited the utf8 check, but never provided a migration to fix deployments done before this change. It still creates tables with no default charset leading to a situation where you can deploy Glance with default values but then end up not being able to run any future migrations. Glance did have a flag to disable that check, but it was recently removed[2] with no automated migrations to resolve earlier deployments (like many of ours). This frustratingly got approved and merged after my -1 and with no explanation why they were doing this to operators. It felt like I was getting the gerrit equivalent of a middle finger. All of that said, I'm 100% for making all of the projects more consistent and use utf8 (where it makes sense). [1]: https://review.openstack.org/#/c/3946/ [2]: https://review.openstack.org/#/c/120002/ JE ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!
On 10/06/2014 04:56 PM, Gauvain Pocentek wrote:
Hi François,
I guess this mail was directed to me personally but I'll answer here,
this might be useful for the translation teams.
There's no existing translation for the HOT guide yet, and I'm not sure
that now is the best time to get started. The (temporary standalone) HOT
guide will end up as a user guide section, in docbook (not RST). I'm
currently rewriting some sections and more content will be added soon,
so expect lots of modifications. As soon as it's ready to be officially
published in the user guide, the translation tools will import the
docbook strings in transifex (that's the plan at least).
Translations have been setup for the guide - like for all other
OpenStack manuals as our toolchains needs it.
Still, let's wait with translations,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 10/06/2014 01:39 PM, Adam Lawson wrote: I like your suggestion about the Docs team being advisors. I would submit however (my opinion here) that whether or not there are enough resources on the Doc'n team to handle Openstack's current list of integrated programs, offloading the work to individual projects exchanges one challenge (scalability) with another problem (quality). Using that approach, doc bugs will get triaged with the other project bugs and potentially distracts developers from doing what they do best - writing and fixing code. And what happens when you only have time to fix a feature or work on documentation? Focus on features and performance/stability are going to win. Every time. And they should because that what the program teams should be focused on. That means we start down the road heavy on code because developers can't do everything, making them light on documentation forcing a catch-up process to ensure which requires a special team to preserve momentum, bringing us back to where we are now. I've been there before. And I'm sure others have as well. I've always been a big proponent of exploiting strengths vs building on weaknesses and I'm going to step out on a limb here and speak to strengths which may get me into hot water with some so I want to apologize in advance. ; ) If a team of developers is tasked to produce all of the documentation for enterprise consumers, I hate to say it like this but you'll end up with highly-targeted documentation that makes sense to a developer and possibly low-level engineers. That level of detail is probably best served in README, wikis and mailing lists. It isn't effective as a user's manual. Even with coaching, we'd be coaching folks to do things they aren't good at. Same goes for a solution architect writing documentation the other way around - you end up with documentation that speaks so broad, it fails to make the impact that a targeted/focused approach is needed by the engineering consumers. While documentation produced by each individual project makes a special kind of impact, it must be one spoke - not the entire wheel. I love the idea of advisors and they should provide the first draft but I also believe a dedicated team is needed to ensure quality doesn't suffer. I guess I wasn't clear in my suggestion. I am proposing that the joining project be responsible for bringing resources to the table -- and not developer resources, but tech writer resources. I think developers can and should work with the Docs team, but I also think that projects should hire or source tech writers themselves to handle the end user and operator documentation. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 10/06/2014 11:39 AM, Adam Lawson wrote: I like your suggestion about the Docs team being advisors. I would submit however (my opinion here) that whether or not there are enough resources on the Doc'n team to handle Openstack's current list of integrated programs, offloading the work to individual projects exchanges one challenge (scalability) with another problem (quality). Using that approach, doc bugs will get triaged with the other project bugs and potentially distracts developers from doing what they do best - writing and fixing code. I think the point is that the individual projects can't have just developers...they also need to have people responsible for release management, integration testing, infrastructure, documentation, etc. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account
Thanks for the feedback and awesome query! To move things forward are there any other steps? Anyone else I should ping to take a look at it? -Patrick On Thu, Oct 2, 2014 at 10:36 AM, Asselin, Ramy ramy.asse...@hp.com wrote: Looks good to me using this query: http://paste.openstack.org/show/117844/ Generated via: https://review.openstack.org/#/c/125716/ Ramy -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Thursday, October 02, 2014 10:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account Looks good to me (cinder core) On 29 September 2014 19:59, Patrick East patrick.e...@purestorage.com wrote: Hi All, I am writing to request voting permissions as per the instructions for third party CI systems[1]. The account email is cinder...@purestorage.com. The system has been operational and stable for a little while now building/commenting on openstack/cinder gerrit. You can view its comment history on reviews here: https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z Please take a look and let me know if there are any issues. I will be the primary point of contact, but the alias openstack-...@purestorage.com is the best way for a quick response from our team. For immediate issues I can be reached in IRC as patrickeast I look forward to your feedback! [1] http://ci.openstack.org/third_party.html#permissions-on-your-third-par ty-system -Patrick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Patrick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account
On 10/06/2014 01:58 PM, Patrick East wrote: Thanks for the feedback and awesome query! To move things forward are there any other steps? Anyone else I should ping to take a look at it? -Patrick I would suggest you attend the Cinder meeting on Wednesday, add an item to the agenda, if folks are in favour, have the Cinder ptl post to this thread after the meeting and tell infra/me the outcome. If Cinder tells infra to give you voting permissions, I can make the change. Thanks, Anita. On Thu, Oct 2, 2014 at 10:36 AM, Asselin, Ramy ramy.asse...@hp.com wrote: Looks good to me using this query: http://paste.openstack.org/show/117844/ Generated via: https://review.openstack.org/#/c/125716/ Ramy -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Thursday, October 02, 2014 10:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account Looks good to me (cinder core) On 29 September 2014 19:59, Patrick East patrick.e...@purestorage.com wrote: Hi All, I am writing to request voting permissions as per the instructions for third party CI systems[1]. The account email is cinder...@purestorage.com. The system has been operational and stable for a little while now building/commenting on openstack/cinder gerrit. You can view its comment history on reviews here: https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z Please take a look and let me know if there are any issues. I will be the primary point of contact, but the alias openstack-...@purestorage.com is the best way for a quick response from our team. For immediate issues I can be reached in IRC as patrickeast I look forward to your feedback! [1] http://ci.openstack.org/third_party.html#permissions-on-your-third-par ty-system -Patrick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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] [Infra][Cinder] Request for voting permission with Pure Storage CI account
Sounds good, will do. Thanks! -Patrick On Mon, Oct 6, 2014 at 11:03 AM, Anita Kuno ante...@anteaya.info wrote: On 10/06/2014 01:58 PM, Patrick East wrote: Thanks for the feedback and awesome query! To move things forward are there any other steps? Anyone else I should ping to take a look at it? -Patrick I would suggest you attend the Cinder meeting on Wednesday, add an item to the agenda, if folks are in favour, have the Cinder ptl post to this thread after the meeting and tell infra/me the outcome. If Cinder tells infra to give you voting permissions, I can make the change. Thanks, Anita. On Thu, Oct 2, 2014 at 10:36 AM, Asselin, Ramy ramy.asse...@hp.com wrote: Looks good to me using this query: http://paste.openstack.org/show/117844/ Generated via: https://review.openstack.org/#/c/125716/ Ramy -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Thursday, October 02, 2014 10:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra][Cinder] Request for voting permission with Pure Storage CI account Looks good to me (cinder core) On 29 September 2014 19:59, Patrick East patrick.e...@purestorage.com wrote: Hi All, I am writing to request voting permissions as per the instructions for third party CI systems[1]. The account email is cinder...@purestorage.com. The system has been operational and stable for a little while now building/commenting on openstack/cinder gerrit. You can view its comment history on reviews here: https://review.openstack.org/#/q/cinder.ci%2540purestorage.com,n,z Please take a look and let me know if there are any issues. I will be the primary point of contact, but the alias openstack-...@purestorage.com is the best way for a quick response from our team. For immediate issues I can be reached in IRC as patrickeast I look forward to your feedback! [1] http://ci.openstack.org/third_party.html#permissions-on-your-third-par ty-system -Patrick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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 -- -Patrick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Group-based Policy] Database migration chain
I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron then GBP would use: connection = mysql://user:pass@locationX:3306/neutron_gbp That's correct, that would be the likely approach if we go with the different schema route. if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in. from SQLAlchemy’s perspective, it’s just a name with a dot. It’s the database itself that has to support the foreign key at the scope you are shooting for. I'm experimenting this approach with our code and it seems to be the case. ' I feel that having the constraint of pointing the same database connection with a different schema is pretty acceptable given how tight is GBP to Neutron. On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau ges...@cisco.com wrote: Clint Byrum cl...@fewbar.com wrote: Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700: On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote: Does sqlalchemy have good support for cross-database foreign keys? I was under the impression that they cannot be implemented with the normal syntax and semantics of an intra-database foreign-key constraint. cross “database” is not typically portable, but cross “schema” is. different database vendors have different notions of “databases” or “schemas”. if you can get the “other database” to be accessible from the target database via “otherdatabase.sometable”, then you’re in. from SQLAlchemy’s perspective, it’s just a name with a dot. It’s the database itself that has to support the foreign key at the scope you are shooting for. All true, however, there are zero guarantees that databases will be hosted on the same server, and typically permissions are setup to prevent cross-schema joins. I believe Group-based Policy (which this thread is about) will use the Neutron database configuration for its dependent database. If Neutron is configured for: connection = mysql://user:pass@locationX:3306/neutron then GBP would use: connection = mysql://user:pass@locationX:3306/neutron_gbp Typically we use the public API's when we want to access data in a different application. The database is a private implementation detail of each application. Currently GPB is very tightly coupled to Neutron. ___ 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] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
Some of you may already be aware of Sage Weil’s challenge to the open source storage community to raise the level of female participation in open source by contributing to the Ada Initiative [1]. I would also like to share about the Ada Initiative, and how they are helping open source communities like OpenStack. I’m also going to increase Sage’s original matching to $10,000 and extend a personal challenge [2] to the OpenStack community. If you already know about the Ada Initiative, you can donate now: https://supportada.org?campaign=openstack The current status of the campaign can be found here: https://adainitiative.org/counters/2014counter-openstack.svg The Ada Initiative has helped over two million women get and stay involved with open source communities. The organization helps communities understand a culture that needs to exist in order to successfully achieve diversity. While women make up about 30% of the software developer community, they only account for less than 10% of the open source community. On a personal level this is something that I have been actively committed to doing and I have had the wonderful opportunity to volunteer as a mentor at a couple of groups that are bringing diversity to the tech community. The PyLadies San Francisco group is providing exciting workshops [3] that will give a foundation to women to expand on. The Women Who Code group is preparing women for internship opportunities through the Gnome Outreach Program for Women in open source projects like OpenStack [4]. It's these experiences that led me to explore how the OpenStack community promotes diversity. Today the OpenStack community has been including a Code of Conduct [5] in an attempt to provide a safe, no harassment environment at our summits. We have events [6] that bring women together to talk about their achievements, to get others excited on what can be contributed to the community. Our participation in the Gnome Outreach Program for Women continues to grow with mentors eager to bring out the talent of our selected interns [7]. Things are getting better but we have a long way to go. The Atlanta design summit had attendance of 9% women, up from 7% at the previous Hong Kong summit. But this number is still unacceptable, and as others have echoed in the community, we must work to make it better. This is a change I want the OpenStack community to be part of. I would like to kick start things with the community with a challenge for us to raise $10,000 before Wednesday, Oct 8th, to which Sage and I will match that dollar for dollar! https://supportada.org?campaign=openstack Thanks, Mike Perez [1] - http://ceph.com/community/support-ada-initiative-challenge-open-storage-community [2] - https://www.dreamhost.com/dreamscape/2014/10/06/support-the-ada-initiative-a-challenge-to-the-openstack-community/ [3] - http://www.meetup.com/PyLadiesSF/events/201387112/ [4] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [5] - https://www.openstack.org/summit/openstack-paris-summit-2014/code-of-conduct/ [6] - https://www.youtube.com/watch?v=jkzyNbvl_5g [7] - https://wiki.openstack.org/wiki/OutreachProgramForWomen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Candidate proposals for TC (Technical Committee) positions are now open
On 10/06/2014 12:38 PM, Anita Kuno wrote: On 10/03/2014 12:16 PM, Flavio Percoco wrote: On 10/03/2014 05:38 PM, Tristan Cacqueray wrote: Candidate proposals for the Technical Committee positions (6 positions) are now open and will remain open until 05:59 UTC October 10, 2014. Candidates for the Technical Committee Positions: Any Foundation individual member can propose their candidacy for an available, directly-elected TC seat. [0] (except the seven TC members who were elected for a one-year seat last April: Thierry Carrez, Jay Pipes, Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda van der Veen) [1] Propose your candidacy by sending an email to the openstack-dev at lists.openstack.org mailing-list, with the subject: TC candidacy. Please start your own thread so we have one thread per candidate. Since there will be many people voting for folks with whom they might not have worked, including a platform or statement to help voters make an informed choice is recommended, though not required. NEW: In order to help the electorate learn more about the candidates we have posted a template of questions to which all candidates are requested to respond. [2] Anita and I will confirm candidates with an email to the candidate thread as well as create a link to the confirmed candidate's proposal email on the wikipage for this election. [1] The election will be held from October 10 through to 13:00 UTC October 17, 2014. The electorate are the Foundation individual members that are also committers for one of the official programs projects [3] over the Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26, 2014 05:59 UTC), as well as the extra-ATCs who are acknowledged by the TC. [4] Please see the wikipage for additional details about this election. [1] If you have any questions please be sure to either voice them on the mailing list or email Anita or myself [5] or contact Anita or myself on IRC. Thank you, and I look forward to reading your candidate proposals, Tristan [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee [1] https://wiki.openstack.org/wiki/TC_Elections_October_2014 [2] https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions [3] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections Note the tag for this repo, sept-2014-elections. [4] http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections [5] Anita: anteaya at anteaya dot info Tristan: tristan dot cacqueray at enovance dot com Greetings, I'd like to take this chance to gently ask, but it's obviously not a requirement, to all candidates to share what their opinion with regards to the new governance discussion is in their candidacy. As a voter, I'm interested to know how the new candidates see our governance model in the next 6 months and what changes, related to the big tent discussion, they consider most important. Thanks, Flavio Hi Flavio: I had purposely not mentioned the organizational changes in the templated questions (which are brand new this time, so these are the guinea pig candidates). One of the things people are looking for is leaders. At campaign time folks with strong stances prevail. However it is the ability to listen and consider the opinions of others, especially when disagreement arises, that makes our TC as strong as it has been and hopefully will be in future. Everyone is enjoying the drama of the changes and yes they are dramatic, but equally if not more important is the work that will have to take place using listening and consideration skills in order to turn decisions into outcomes. Listening is an incredibly important leadership skill but doesn't get much air time during campaigns. If you look at really effective leaders though they are listeners, every one. Listeners also rarely state that is what they are doing, since they are busy listening. Any candidate is welcome to say anything they wish in their candidate statement. I appreciate that you are interested in their opinions about the new governance model, Flavio, and I appreciate you speaking up about it. But regardless of what decisions are made, what structure is decided upon and what that structure and its parts are called, we need people with the ability to listen, consider, and work very hard to put any of these decisions in place in order for them to succeed. We have a problem of incredible growth in OpenStack. Our growth is a manifestation of all we are doing correctly. I hope that the questions asked in the templates bring out the qualities I know each candidate is capable of, that ensure we have a group of leaders with the skills necessary to make agreements and produce results, regardless of the shape and colour of those agreements and results. Thank you, Anita. I will also
Re: [openstack-dev] [Openstacl] [Glance] Container format
Adam, container-format is an essential property within Glance. Specifying 'bare' is not mandatory however, whatever applicable container-format for your deployment is necessary. Thanks, -Nikhil From: Adam Lawson [alaw...@aqorn.com] Sent: Monday, October 06, 2014 1:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Openstacl] [Glance] Container format Hi all, is there a reason that specifying a 'bare' container format option is required from the operator given it isn't used by any Openstack services? [1] [1] http://docs.openstack.org/trunk/install-guide/install/apt/content/glance-verify.html (step4) Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [http://www.aqorn.com/images/logo.png] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator
Thanks all for a good discussion. I would like to call for an agreement on this subject in Wednesday's (Oct 8th) Heat IRC meeting. It has been added in the agenda. Thanks! Regards, Sahdev Zala IBM SWG Standards Strategy Durham, NC (919)486-2915 T/L: 526-2915 From: Steven Hardy sha...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 09/23/2014 05:46 AM Subject:Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator On Fri, Sep 19, 2014 at 06:54:27PM -0400, Zane Bitter wrote: On 09/09/14 05:52, Steven Hardy wrote: Hi Sahdev, On Tue, Sep 02, 2014 at 11:52:30AM -0400, Sahdev P Zala wrote: Hello guys, As you know, the heat-translator project was started early this year with an aim to create a tool to translate non-Heat templates to HOT. It is a StackForge project licensed under Apache 2. We have made good progress with its development and a demo was given at the OpenStack 2014 Atlanta summit during a half-a-day session that was dedicated to heat-translator project and related TOSCA discussion. Currently the development and testing is done with the TOSCA template format but the tool is designed to be generic enough to work with templates other than TOSCA. There are five developers actively contributing to the development. In addition, all current Heat core members are already core members of the heat-translator project. Recently, I attended Heat Mid Cycle Meet Up for Juno in Raleigh and updated the attendees on heat-translator project and ongoing progress. I also requested everyone for a formal adoption of the project in the python-heatclient and the consensus was that it is the right thing to do. Also when the project was started, the initial plan was to make it available in python-heatclient. Hereby, the heat-translator team would like to make a request to have the heat-translator project to be adopted by the python-heatclient/Heat program. Obviously I wasn't at the meetup, so I may be missing some context here, but can you answer some questions please? - Is the scope for heat-translator only tosca simple-profile, or also the original more heavyweight tosca too? - If it's only tosca simple-profile, has any thought been given to moving towards implementing support via a template parser plugin, rather than baking the translation into the client? One idea we discussed at the meetup was to use the template-building code that we now have in Heat for building the HOT output from the translator - e.g. the translator would produce ResourceDefinition objects and add them to a HOTemplate object. That would actually get us a long way toward an implementation of a template format plugin (which basically just has to spit out ResourceDefinition objects). So maybe that approach would allow us to start in python-heatclient and easily move it later into being a full-fledged template format plugin in Heat itself. While I see this effort as valuable, integrating the translator into the client seems the worst of all worlds to me: - Any users/services not intefacing to heat via python-heatclient can't use it Yep, this is a big downside (although presumably we'd want to build in a way to just spit out the generated template that can be used by other clients). On the other hand, there is a big downside to having it (only) in Heat also - you're dependent on the operator deciding to provide it. - You prempt the decision about integration with any higher level services, e.g Mistral, Murano, Solum, if you bake in the translator at the heat level. Not sure I understand this one. I meant if non-simple TOSCA was in scope, would it make sense to bake the translation in at the heat level, when there are aspects of the DSL which we will never support (but some higher layer might). Given Sahdev's response saying simple-profile is all that is currently in scope, it's probably a non-issue, I just wanted to clarify if heat was the right place for this translation. Steve ___ 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] [oslo] summit planning during this week's meeting
In the past, summit planning has been left up to the PTL, but this time all of the projects are trying a more collaborative process. We’ve talked about it briefly in previous meetings, and set up an etherpad to record ideas [1]. I would like to use our meeting this week to work through some of the suggestions and see how best to fill our scheduled slots. If you have something you would like the Oslo team to consider discussing at the summit, please add it to the etherpad. If you have an interest in any of the items on the list, please join us for our meeting this Friday at 16:00 UTC [2]. Thanks, Doug [1] https://etherpad.openstack.org/p/kilo-oslo-summit-topics [2] http://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Suggestions for students final year project
Hi Adam, Thanks for taking the time to reply. I'm more of a web development type than security. I have some maths background so perhaps something with data analysis. To date I have done mostly Java, some JavaScript, Html, and MySQL. I am interested in learning Python. I co-developed a web app to check and commit time-sheets to a database during my work experience this summer; I did the database and the checking of the sheets. I, have also, created an Android app to monitor the fuel consumption in multiple vehicles, using the Android SQLite Database for storage. On 6 October 2014 18:37, Adam Young ayo...@redhat.com wrote: On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Patricia, I am Keystone core developer. I have several ideas. It really depends on your skills and interests. Are you a security person? If not, are you a web development type person? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On Mon, Oct 6, 2014 at 12:52 PM, Jay Pipes jaypi...@gmail.com wrote: On 10/06/2014 01:39 PM, Adam Lawson wrote: I like your suggestion about the Docs team being advisors. I would submit however (my opinion here) that whether or not there are enough resources on the Doc'n team to handle Openstack's current list of integrated programs, offloading the work to individual projects exchanges one challenge (scalability) with another problem (quality). Using that approach, doc bugs will get triaged with the other project bugs and potentially distracts developers from doing what they do best - writing and fixing code. And what happens when you only have time to fix a feature or work on documentation? Focus on features and performance/stability are going to win. Every time. And they should because that what the program teams should be focused on. That means we start down the road heavy on code because developers can't do everything, making them light on documentation forcing a catch-up process to ensure which requires a special team to preserve momentum, bringing us back to where we are now. I've been there before. And I'm sure others have as well. I've always been a big proponent of exploiting strengths vs building on weaknesses and I'm going to step out on a limb here and speak to strengths which may get me into hot water with some so I want to apologize in advance. ; ) If a team of developers is tasked to produce all of the documentation for enterprise consumers, I hate to say it like this but you'll end up with highly-targeted documentation that makes sense to a developer and possibly low-level engineers. That level of detail is probably best served in README, wikis and mailing lists. It isn't effective as a user's manual. Even with coaching, we'd be coaching folks to do things they aren't good at. Same goes for a solution architect writing documentation the other way around - you end up with documentation that speaks so broad, it fails to make the impact that a targeted/focused approach is needed by the engineering consumers. While documentation produced by each individual project makes a special kind of impact, it must be one spoke - not the entire wheel. I love the idea of advisors and they should provide the first draft but I also believe a dedicated team is needed to ensure quality doesn't suffer. I guess I wasn't clear in my suggestion. I am proposing that the joining project be responsible for bringing resources to the table -- and not developer resources, but tech writer resources. I think developers can and should work with the Docs team, but I also think that projects should hire or source tech writers themselves to handle the end user and operator documentation. This is happening with some projects and I always encourage companies hiring for OpenStack devs should also hire writers to keep up with those devs. Sometimes the tech writer is assigned only to the API docs not the operator docs. Or all sorts of other combinations. But yes, the idea is that the enterprise doc teams should also dedicate some of their work to upstream patching. And yes, I agree with the sentiment that it's pretty useless to document any project standalone for anyone except contributor devs. Users, operators, should write for users and operators upstream. Contrib devs write for devs in the commuity/upstream. Also hire tech writers who are good at advocating for particular groups and have them write for upstream as well. Lana Brindley and I are talking about that at the Summit Monday at 17:10 http://sched.co/1qeSZbp Nick Chase and I are working on a report about the balance between meeting the needs of community doc contributors and finding resources for enterprise-level deliverables. It's complicated, isn't it? It's a balancing act. Great discussion. Anne Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Granularity of policies
I encountered an interesting situation with Glance policies. Basically we have a situation where users in certain roles are not allowed to make certain calls at all. In this specific case, we don't want users in those roles listing or viewing members. When listing members, these users receive a 403 (Forbidden) but when showing an individual member the users receive 404 (Not Found). So the problem is that there are a couple of situations here and we don't (can't?) distinguish the exact intent: 1) A user IS allowed to make the call but isn't allowed to see a particular member - in that case 404 makes sense because a 403 could imply the user actually is there, you just can't look see them directly. 2) A user IS NOT allowed to make the call at all. In this case a 403 makes more sense because the user is forbidden at the call level. At this point I'm mainly trying to spark some conversation on this. This feels a bit inconsistent if users get 403 for a whole set of calls they are barred from but 404 for others which are sub calls of the others (e.g. listing members vs. showing a specific one.) But I don't have a specific proposals at this time - first I'm trying to find out if others feel this is a problem which should be addressed. If so I'm willing to work on a blueprint and implementation. - Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Skipping IPv6 unit tests in proprietary plugins
Hi, I am seeing some patches in review that are adding skips to unit tests in the Open Contrail plugin. If we can, please imitate the work that Kevin Benton did in the One Convergence plugin and have your plugin skip tests that have v6 in the name, if your plugin does not support IPv6. I have added similar logic to the OpenContrail plugin's tests. https://review.openstack.org/#/c/126407/1 -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][gate] configurable quota threshold warnings?
Logging like that is useful for admins, but I wonder if we should talk about notifications as well. That would allow people to build systems which warned the user as well that they are nearing quota. Michael On Tue, Oct 7, 2014 at 2:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: I'm floating this in case the idea has come up before. I've spent most of my day so far digging through logs and code for gate race bug 1353962 [1] where an admin tenant is going over-quota when trying to allocate fixed IPs for a test instance (the test setup creates 2 instances and more test instances are created in some of the test cases). I'm going to push up some patches to nova to make the logs more useful when we hit this, i.e. log the quota limit and current usage for the given resource (fixed_ips in this case). But the idea that keeps coming up when I'm digging into stuff like this is it'd be nice to know when we're nearing over-quota so we can walk that back and figure out what was going on prior to us falling over the cliff. This isn't a novel idea, but I haven't heard it discussed before. What I'm thinking is basically add a config option for setting a threshold value which would dump warnings when you're over that threshold. This could be configured per resource, e.g. I only care about fixed_ips, instances, etc. It could be configured per tenant (maybe we only care about this for the admin tenant?). My use case would be specifically related to the bug in question, so I want to set the threshold at let's say 80%. With a default fixed_ips quota of 10, when I've gotten over 8 reserved for the admin tenant, I start logging warnings that I'm nearing over-quota. When we go over-quota on a request, we could then see what operations/requests were going on before this that tipped us over. Thoughts? [1] https://bugs.launchpad.net/nova/+bug/1353962 -- Thanks, Matt Riedemann ___ 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] Suggestions for students final year project
Patricia, Perhaps someone from the Sahara team has a need for help to resolve a problem. If patching or implementing a new feature isn't your idea of a final project, maybe create a big data job that analyses real-time Twitter trends on a virtualized Hadoop cluster. Or maybe a comparison running that same job between multiple virtual clusters with Hortonworks versus Cloudera versus Vanilla Apache Hadoop and compare which one performs better and why. Just some suggestions. ; ) Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Mon, Oct 6, 2014 at 12:25 PM, Patricia Ellis patricia.el...@mycit.ie wrote: Hi Adam, Thanks for taking the time to reply. I'm more of a web development type than security. I have some maths background so perhaps something with data analysis. To date I have done mostly Java, some JavaScript, Html, and MySQL. I am interested in learning Python. I co-developed a web app to check and commit time-sheets to a database during my work experience this summer; I did the database and the checking of the sheets. I, have also, created an Android app to monitor the fuel consumption in multiple vehicles, using the Android SQLite Database for storage. On 6 October 2014 18:37, Adam Young ayo...@redhat.com wrote: On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Patricia, I am Keystone core developer. I have several ideas. It really depends on your skills and interests. Are you a security person? If not, are you a web development type person? ___ 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] Suggestions for students final year project
On 10/06/2014 03:25 PM, Patricia Ellis wrote: Hi Adam, Thanks for taking the time to reply. I'm more of a web development type than security. I have some maths background so perhaps something with data analysis. To date I have done mostly Java, some JavaScript, Html, and MySQL. I am interested in learning Python. I co-developed a web app to check and commit time-sheets to a database during my work experience this summer; I did the database and the checking of the sheets. I, have also, created an Android app to monitor the fuel consumption in multiple vehicles, using the Android SQLite Database for storage. I am looking to get someone to work on a Javascript based web client to replace Horizon. There has been some work along these lines already. Beyond that, most of the projects I have are Python based Keystone features. You can see the kinds of things I am considering here: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+owner:%22ayoung+%253Cayoung%2540redhat.com%253E%22,n,z On 6 October 2014 18:37, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ 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 Patricia, I am Keystone core developer. I have several ideas. It really depends on your skills and interests. Are you a security person? If not, are you a web development type person? ___ 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] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team. Pavlo has been a consistently active member of the Heat community - he's a regular participant in IRC and at meetings, has been making plenty of good commits[1] and maintains a very respectable review rate[2] with helpful comments. I think he's built up enough experience with the code base to be ready for core. Heat-cores, please vote by replying to this thread. As a reminder of your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as a veto. cheers, Zane. [1] https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
You're all awesome, as the goal has already been met! The matching challenge has just been raised to $16,384! https://supportada.org?campaign=openstack Status: https://adainitiative.org/counters/2014counter-openstack.svg -- Mike Perez On Oct 6, 2014, at 11:33, Mike Perez thin...@gmail.com wrote: Some of you may already be aware of Sage Weil’s challenge to the open source storage community to raise the level of female participation in open source by contributing to the Ada Initiative [1]. I would also like to share about the Ada Initiative, and how they are helping open source communities like OpenStack. I’m also going to increase Sage’s original matching to $10,000 and extend a personal challenge [2] to the OpenStack community. If you already know about the Ada Initiative, you can donate now: https://supportada.org?campaign=openstack The current status of the campaign can be found here: https://adainitiative.org/counters/2014counter-openstack.svg The Ada Initiative has helped over two million women get and stay involved with open source communities. The organization helps communities understand a culture that needs to exist in order to successfully achieve diversity. While women make up about 30% of the software developer community, they only account for less than 10% of the open source community. On a personal level this is something that I have been actively committed to doing and I have had the wonderful opportunity to volunteer as a mentor at a couple of groups that are bringing diversity to the tech community. The PyLadies San Francisco group is providing exciting workshops [3] that will give a foundation to women to expand on. The Women Who Code group is preparing women for internship opportunities through the Gnome Outreach Program for Women in open source projects like OpenStack [4]. It's these experiences that led me to explore how the OpenStack community promotes diversity. Today the OpenStack community has been including a Code of Conduct [5] in an attempt to provide a safe, no harassment environment at our summits. We have events [6] that bring women together to talk about their achievements, to get others excited on what can be contributed to the community. Our participation in the Gnome Outreach Program for Women continues to grow with mentors eager to bring out the talent of our selected interns [7]. Things are getting better but we have a long way to go. The Atlanta design summit had attendance of 9% women, up from 7% at the previous Hong Kong summit. But this number is still unacceptable, and as others have echoed in the community, we must work to make it better. This is a change I want the OpenStack community to be part of. I would like to kick start things with the community with a challenge for us to raise $10,000 before Wednesday, Oct 8th, to which Sage and I will match that dollar for dollar! https://supportada.org?campaign=openstack Thanks, Mike Perez [1] - http://ceph.com/community/support-ada-initiative-challenge-open-storage-community [2] - https://www.dreamhost.com/dreamscape/2014/10/06/support-the-ada-initiative-a-challenge-to-the-openstack-community/ [3] - http://www.meetup.com/PyLadiesSF/events/201387112/ [4] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [5] - https://www.openstack.org/summit/openstack-paris-summit-2014/code-of-conduct/ [6] - https://www.youtube.com/watch?v=jkzyNbvl_5g [7] - https://wiki.openstack.org/wiki/OutreachProgramForWomen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
Thanks for your leadership! On Oct 6, 2014, at 3:44 PM, Mike Perez thin...@gmail.com wrote: You're all awesome, as the goal has already been met! The matching challenge has just been raised to $16,384! https://supportada.org?campaign=openstack Status: https://adainitiative.org/counters/2014counter-openstack.svg -- Mike Perez On Oct 6, 2014, at 11:33, Mike Perez thin...@gmail.com wrote: Some of you may already be aware of Sage Weil’s challenge to the open source storage community to raise the level of female participation in open source by contributing to the Ada Initiative [1]. I would also like to share about the Ada Initiative, and how they are helping open source communities like OpenStack. I’m also going to increase Sage’s original matching to $10,000 and extend a personal challenge [2] to the OpenStack community. If you already know about the Ada Initiative, you can donate now: https://supportada.org?campaign=openstack The current status of the campaign can be found here: https://adainitiative.org/counters/2014counter-openstack.svg The Ada Initiative has helped over two million women get and stay involved with open source communities. The organization helps communities understand a culture that needs to exist in order to successfully achieve diversity. While women make up about 30% of the software developer community, they only account for less than 10% of the open source community. On a personal level this is something that I have been actively committed to doing and I have had the wonderful opportunity to volunteer as a mentor at a couple of groups that are bringing diversity to the tech community. The PyLadies San Francisco group is providing exciting workshops [3] that will give a foundation to women to expand on. The Women Who Code group is preparing women for internship opportunities through the Gnome Outreach Program for Women in open source projects like OpenStack [4]. It's these experiences that led me to explore how the OpenStack community promotes diversity. Today the OpenStack community has been including a Code of Conduct [5] in an attempt to provide a safe, no harassment environment at our summits. We have events [6] that bring women together to talk about their achievements, to get others excited on what can be contributed to the community. Our participation in the Gnome Outreach Program for Women continues to grow with mentors eager to bring out the talent of our selected interns [7]. Things are getting better but we have a long way to go. The Atlanta design summit had attendance of 9% women, up from 7% at the previous Hong Kong summit. But this number is still unacceptable, and as others have echoed in the community, we must work to make it better. This is a change I want the OpenStack community to be part of. I would like to kick start things with the community with a challenge for us to raise $10,000 before Wednesday, Oct 8th, to which Sage and I will match that dollar for dollar! https://supportada.org?campaign=openstack Thanks, Mike Perez [1] - http://ceph.com/community/support-ada-initiative-challenge-open-storage-community [2] - https://www.dreamhost.com/dreamscape/2014/10/06/support-the-ada-initiative-a-challenge-to-the-openstack-community/ [3] - http://www.meetup.com/PyLadiesSF/events/201387112/ [4] - http://www.meetup.com/Women-Who-Code-SF/events/195850392/ [5] - https://www.openstack.org/summit/openstack-paris-summit-2014/code-of-conduct/ [6] - https://www.youtube.com/watch?v=jkzyNbvl_5g [7] - https://wiki.openstack.org/wiki/OutreachProgramForWomen ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TaskFlow][Oslo] TaskFlow 0.5.0 Released!
Howdy all, Just wanted to send a mini-announcement about the new taskflow 0.5.0 release on behalf of the oslo and taskflow teams, The details about what is new and what is changed and all that goodness can be found @ https://etherpad.openstack.org/p/TaskFlow-0.5 This release mainly fixes some small bugs issues found with 0.4.0 and also uses the new oslo.utils, oslotest packages... (details in above etherpad). Updated developer docs can be found @ http://docs.openstack.org/developer/taskflow as usual. Bugs of course can be reported @ http://bugs.launchpad.net/taskflow/0.5/+filebug (hopefully no bugs!). As always find the team in #openstack-state-management or #openstack-oslo and come with questions, comments or other thoughts :-) Onward and upward to the next release! - Josh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Suggestions for students final year project
On 10/06/2014 04:11 PM, Adam Young wrote: On 10/06/2014 03:25 PM, Patricia Ellis wrote: Hi Adam, Thanks for taking the time to reply. I'm more of a web development type than security. I have some maths background so perhaps something with data analysis. To date I have done mostly Java, some JavaScript, Html, and MySQL. I am interested in learning Python. I co-developed a web app to check and commit time-sheets to a database during my work experience this summer; I did the database and the checking of the sheets. I, have also, created an Android app to monitor the fuel consumption in multiple vehicles, using the Android SQLite Database for storage. I am looking to get someone to work on a Javascript based web client to replace Horizon. Can I just say that I think using new people looking to have work experience with OpenStack to further pet projects, without telling them it is a pet project and not considered a project which others may consider OpenStack to be not the best approach for encouraging new people. Not knocking your project, Adam, since I know nothing about it, and this isn't the first time I have seen this happen. But I do believe that folks asking to help out with something are looking to gain transferable skills so that they have something to offer a potential employeer who is looking for work experience with OpenStack. That would be what I would be looking for anyway. New people have no idea what are considered transferable skills within OpenStack unless we tell them. Thanks, Anita. There has been some work along these lines already. Beyond that, most of the projects I have are Python based Keystone features. You can see the kinds of things I am considering here: https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+owner:%22ayoung+%253Cayoung%2540redhat.com%253E%22,n,z On 6 October 2014 18:37, Adam Young ayo...@redhat.com mailto:ayo...@redhat.com wrote: On 10/06/2014 01:14 PM, Patricia Ellis wrote: My name is Patricia Ellis, I am a fourth year software development student at Cork Institute of Technology. I am looking for ideas for my final year project. I have six weeks to get my proposal together and then 13 weeks to implement it. I am hoping you might have a suitable project on your wish list, one which is of the ”low hanging fruit” variety as my time frame is tight. ___ 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 Patricia, I am Keystone core developer. I have several ideas. It really depends on your skills and interests. Are you a security person? If not, are you a web development type person? ___ 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] [nova] Resource tracker
On Mon, Oct 6, 2014 at 6:03 AM, Gary Kotton gkot...@vmware.com wrote: Hi, At the moment the resource tracker in Nova ignores that statistics that are returned by the hypervisor and it calculates the values on its own. Not only is this highly error prone but it is also very costly – all of the resources on the host are read from the database. Not only the fact that we are doing something very costly is troubling, the fact that we are over calculating resources used by the hypervisor is also an issue. In my opinion this leads us to not fully utilize hosts at our disposal. I have a number of concerns with this approach and would like to know why we are not using the actual resource reported by the hypervisor. The reason for asking this is that I have added a patch which uses the actual hypervisor resources returned and it lead to a discussion on the particular review (https://review.openstack.org/126237). So it sounds like you have mentioned two concerns here: 1. The current method to calculate hypervisor usage is expensive in terms of database access. 2. Nova ignores that statistics that are returned by the hypervisor and uses its own calculations. To #1, maybe we can doing something better, optimize the query, cache the result etc. As for #2 nova intentionally doesn't use the hypervisor statistics for a few reasons: * Make scheduling more deterministic, make it easier to reproduce issues etc. * Things like memory ballooning and thin provisioning in general, mean that the hypervisor is not reporting how much of the resources can be allocated but rather how much are currently in use (This behavior can vary from hypervisor to hypervisor today AFAIK -- which makes things confusing). So if I don't want to over subscribe RAM, and the hypervisor is using memory ballooning, the hypervisor statistics are mostly useless. I am sure there are more complex schemes that we can come up with that allow us to factor in the properties of thin provisioning, but is the extra complexity worth it? That being said I am fine with discussing in a spec the idea of adding an option to use the hypervisor reported statistics, as long as it is off by default. Thanks Gary ___ 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] Taskflow for Juno RC1 effectively require Kombu 3.x
This is fixed (or should be): https://pypi.python.org/pypi/taskflow/0.5.0 - Josh On Oct 1, 2014, at 3:55 AM, Thomas Goirand z...@debian.org wrote: Hi, When building the latest release (eg: Juno RC1) of Taskflow 0.4, needed by Cinder, I've notice failures due to the impossibility to do: from kombu import message More in details, the failure is: == FAIL: unittest.loader.ModuleImportFailure.taskflow.tests.unit.worker_based.test_dispatcher unittest.loader.ModuleImportFailure.taskflow.tests.unit.worker_based.test_dispatcher -- _StringException: Traceback (most recent call last): ImportError: Failed to import test module: taskflow.tests.unit.worker_based.test_dispatcher Traceback (most recent call last): File /usr/lib/python2.7/unittest/loader.py, line 252, in _find_tests module = self._get_module_from_name(name) File /usr/lib/python2.7/unittest/loader.py, line 230, in _get_module_from_name __import__(name) File taskflow/tests/unit/worker_based/test_dispatcher.py, line 17, in module from kombu import message ImportError: cannot import name message The thing is, there's no message.py in the latest Kombu 2.x, this appears in version 3.0. Though in our global-requirements.txt, we only have kombu=2.5.0, which IMO is just completely wrong, considering what Taskflow does in . Changing the requirement to be kombu=3.0 means that we also need to import new dependencies, as kombu 3.x needs python-beanstalkc. So here, we have 2 choices: 1/ Fix Taskflow so that it really supports Kombu 2.5, as per our decided Juno requirements. 2/ Accept beanstalkc and kombu=3.0, modify our global-requirements.txt and add these 2. Since Ubuntu is already in a deep freeze, probably 2/ isn't a very good solution. Also, python-beanstalkc fails to build in Wheezy (when doing its doc tests). I didn't investigate a lot why (yet), but that's annoying. On my test system (eg: a cowbuilder chroot), I have just added a Debian patch to completely remove taskflow/tests/unit/worker_based/test_dispatcher.py from taskflow, and everything works again (eg: no unit test errors). This is maybe a bit more drastic than what we could do, probably... :) Joshua, I've CC-ed you because git blame told me that you were the person writing these tests. Could you patch it quickly (eg: before the final release of Juno) so that it works with the older Kombu? Thoughts anyone? Cheers, Thomas Goirand (zigo) ___ 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][nova] git fetch fails with permission denied (publickey)
I have followed the instructions on https://wiki.openstack.org/wiki/Gerrit_Workflow and am trying to fetch the nova repository, but it fails with Permission denied (publickey). I believe this has something to do with my specific account on review.openstack.org, but not sure what. git remote add origin ssh://jmul...@review.openstack.org:29418/openstack/nova.git git fetch origin Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I have double checked that my user name is correct on review.openstack.org and in my global git config where I am trying to do the fetch. I have checked my settings on review.openstack.org and verified that I have the correct public key saved. I have tried configuring keys 3 times now, and none of them worked. They are stored in the normal paths of ~/.ssh/id_rsa and ~/.shh/id_rsa.pub. I see the same error with git clone and 'ssh -vv -p 29418 jmul...@review.openstack.org'. The output from ssh looks like it is looking in the right places for the key, I'm just not getting back the message that the server has accepted the key. ... debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/jmulsow/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey ... debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). Has anyone seen this before, or have any ideas? Thank you, Jennifer Mulsow Cloud Systems Software Development IBM Systems Technology Group___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Support the Ada Initiative: A Challenge to the OpenStack Communtiy
On Oct 6, 2014, at 15:15, Anne Gentle a...@openstack.org wrote: You got it Mike! Donating now! This is awe-inspiring. Male allies are what we need, and you are delivering. +1, and thank you Mike for sharing information about the Ada Initiative with us. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-dev][nova] git fetch fails with permission denied (publickey)
On 2014-10-06 17:45:21 -0500 (-0500), Jennifer Mulsow wrote: [...] git remote add origin ssh://jmul...@review.openstack.org:29418/openstack/nova.git [...] I have double checked that my user name is correct on review.openstack.org and in my global git config where I am trying to do the fetch. [...] The logs for the Gerrit API indicate it could not find any user with jmulsow as the username, and digging in its MySQL database I have confirmed that is the case. I see a Jennifer Mulsow who created a Gerrit account in April of 2013 who last updated contact information a few weeks ago, but that account has no username configured at all. When you are signed into Gerrit's WebUI and visit https://review.openstack.org/#/settings/ is there anything at all listed to the right of Username? If so, that's what you should use instead of jmulsow. If there's nothing there at all, then click into the blank space and (carefully since it can't be changed later) enter whatever you want it to be. -- Jeremy Stanley signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Granularity of policies
On Oct 6, 2014, at 12:35 PM, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: I encountered an interesting situation with Glance policies. Basically we have a situation where users in certain roles are not allowed to make certain calls at all. In this specific case, we don't want users in those roles listing or viewing members. When listing members, these users receive a 403 (Forbidden) but when showing an individual member the users receive 404 (Not Found). So the problem is that there are a couple of situations here and we don't (can't?) distinguish the exact intent: 1) A user IS allowed to make the call but isn't allowed to see a particular member - in that case 404 makes sense because a 403 could imply the user actually is there, you just can't look see them directly. 2) A user IS NOT allowed to make the call at all. In this case a 403 makes more sense because the user is forbidden at the call level. At this point I'm mainly trying to spark some conversation on this. This feels a bit inconsistent if users get 403 for a whole set of calls they are barred from but 404 for others which are sub calls of the others (e.g. listing members vs. showing a specific one.) But I don't have a specific proposals at this time - first I'm trying to find out if others feel this is a problem which should be addressed. If so I'm willing to work on a blueprint and implementation Generally you use a 404 to make sure no information is exposed about whether the user actually exists, but in the case of 2) I agree that a 403 is appropriate. It may be that 404 was used there because the same code path is taken in both cases. Vish signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Meeting Tuesday October 7th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday October 7th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) 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] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
On Tue, Oct 7, 2014 at 6:41 AM, Zane Bitter zbit...@redhat.com wrote: I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team. Pavlo has been a consistently active member of the Heat community - he's a regular participant in IRC and at meetings, has been making plenty of good commits[1] and maintains a very respectable review rate[2] with helpful comments. I think he's built up enough experience with the code base to be ready for core. Heat-cores, please vote by replying to this thread. As a reminder of your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as a veto. +1 cheers, Zane. [1] https://review.openstack.org/#/q/owner:%22Pavlo+ Shchelokovskyy%22+status:merged+project:openstack/heat,n,z [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_ Removing_Members ___ 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] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
+1 On 07/10/14 09:41, Zane Bitter wrote: I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team. Pavlo has been a consistently active member of the Heat community - he's a regular participant in IRC and at meetings, has been making plenty of good commits[1] and maintains a very respectable review rate[2] with helpful comments. I think he's built up enough experience with the code base to be ready for core. Heat-cores, please vote by replying to this thread. As a reminder of your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as a veto. cheers, Zane. [1] https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members ___ 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][nova] git fetch fails with permission denied (publickey)
Jennifer Mulsow/Austin/IBM@IBMUS wrote on 10/06/2014 06:45:21 PM: I have followed the instructions on https://wiki.openstack.org/wiki/ Gerrit_Workflow and am trying to fetch the nova repository, but it fails with Permission denied (publickey). I believe this has something to do with my specific account on review.openstack.org, but not sure what. git remote add origin ssh://jmul...@review.openstack.org:29418/ openstack/nova.git git fetch origin Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Maybe I am blind tonight, but I do not see where the Gerrit_Workflow wiki page is telling you to `git fetch origin`. When starting from scratch (which I suppose you are), you want a command like this: git clone git://git.openstack.org/openstack/nova.git Your SSH test looks valid to me, I do not see why it should fail. Regards, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] What I already have for openstack/kubernetes/docker
On 10/02/2014 06:25 PM, Angus Lees wrote: Sorry I couldn't make the IRC meeting. sdake quite rightly suggested I send this to the broader list for dissection. I spent yesterday templatising my k8s configs so I could publish them without revealing all my passwords ;) https://github.com/anguslees/kube-openstack Please take a look and let me know if any of this is useful. I think the good bits are: - A simpler method of handling k8s pod routes by just using etcd and two shell loops to setup a poor-mans dynamic routing protocol. For all its simplicity, this should scale to hundreds of nodes just fine, and a sharding hierarchy would be easy enough to add at that point (see the networking portions in heat-kube-coreos-rax.yaml) - Dockerfiles for nova + keystone, and a start on glance. The structure should be similar for all the other control jobs that don't need to mess with hardware directly. In particular, I'm experimenting with what it would be like if environment variables were supported directly in oslo.config files, and so far it looks good. I chose to build these from git master. I'm not sure if that's a good idea or not, but it's what I need to use this for dev work. A possible improvement would be to base these on something like dockerfile/python-runtime. - k8s config for keystone + nova + a start on glance. Again, these should be a good model for other control jobs. - I use heat to setup the initial deployment environment and generate all the passwords, and then stamp the generated values into kubernetes template files. This assumes an already active undercloud, but it also removes easily isolated tasks like set up a mysql server and provide its address here from our list of problems to tackle. I'm trying to run servers independently wherever possible, rather than bundling them into the same pod or container. This gives maximum freedom with very little overhead (thanks to docker). This also means my containers are basically dumb software distribution, without a complicated start.sh. I don't have anything that configures keystone users or catalog yet - I was going to do that in a single pass that just added all the service ports some time after keystone was configured but not as part of each individual service. Angus, The routing idea sounds interesting, but I'd like someone who actually is a network expert (which I'm not) provide an analysis of the concept. I have had a look at your repo and I don't immediately see how to integrate our two repos together. That said, I'd really like you to join the Kolla community and help crank out a working solution. We hang out in #tripleo on freenode and would love to chat more. If you want coreos support, I think that is do-able with some renames in our repository. Right now we are focused on Fedora + RDO support rather then CoreOS + master support. Regards, -steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Compute][Nova] Kilo specs are open for business
I am pleased to announce that the specs process for nova in kilo is now open. There are some tweaks to the previous process, so please read this entire email before uploading your spec! Blueprints approved in Juno === For specs approved in Juno, there is a fast track approval process for Kilo. The steps to get your spec re-approved are: - Copy your spec from the specs/juno/approved directory to the specs/kilo/approved directory. Note that if we declared your spec to be a partial implementation in Juno, it might be in the implemented directory. This was rare however. - Update the spec to match the new template - Commit, with the Previously-approved: juno commit message tag - Upload using git review as normal Reviewers will still do a full review of the spec, we are not offering a rubber stamp of previously approved specs. However, we are requiring only one +2 to merge these previously approved specs, so the process should be a lot faster. A note for core reviewers here -- please include a short note on why you're doing a single +2 approval on the spec so future generations remember why. Trivial blueprints == We are not requiring specs for trivial blueprints in Kilo. Instead, create a blueprint in Launchpad athttps://blueprints.launchpad.net/nova/+addspec and target the specification to Kilo. New, targetted, unapproved specs will be reviewed in weekly nova meetings. If it is agreed they are indeed trivial in the meeting, they will be approved. Other proposals === For other proposals, the process is the same as Juno... Propose a spec review against the specs/kilo/approved directory and we'll review it from there. Cheers, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [doc][swift] improvement for selinux related procedure
Hi, I think that the document OPENSTACK INSTALLATION GUIDE FOR RED HAT ENTERPRISE LINUX, ... has been written based on selinux because the openstack-selinux package is installed along with the in following procedure. http://docs.openstack.org/icehouse/install-guide/install/yum/content/basics-packages.html + OpenStack packages And the following document there is the mount procedure for /srv/node/sdb1 without specifying the context information(context=system_u:object_r:swift_data_t:s0). http://docs.openstack.org/icehouse/install-guide/install/yum/content/installing-and-configuring-storage-nodes.html I think it is better to add the context information on the document. What do you think? If you need a bug report for this, please let me know. Best Regards, Hisashi Osanai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [gantt] Scheduler group meeting - Agenda 10/7
1) Forklift status 2) Kilo Summit sessions 3) Kilo BPs 4) Opens -- 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
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
On Oct 3, 2014, at 2:44 PM, Monty Taylor mord...@inaugust.com wrote: On 09/30/2014 12:07 PM, Tim Bell wrote: -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: 30 September 2014 15:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading On 30 September 2014 14:04, joehuang joehu...@huawei.com wrote: Hello, Dear TC and all, Large cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons: 1) Multiple data centers distributed geographically; 2) Multi-vendor business policy; 3) Server nodes scale up modularized from 00's up to million; 4) Fault and maintenance isolation between zones (only REST interface); At the same time, they also want to integrate these OpenStack instances into one cloud. Instead of proprietary orchestration layer, they want to use standard OpenStack framework for Northbound API compatibility with HEAT/Horizon or other 3rd ecosystem apps. We call this pattern as OpenStack Cascading, with proposal described by [1][2]. PoC live demo video can be found[3][4]. Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the OpenStack cascading. Kindly ask for cross program design summit session to discuss OpenStack cascading and the contribution to Kilo. Kindly invite those who are interested in the OpenStack cascading to work together and contribute it to OpenStack. (I applied for “other projects” track [5], but it would be better to have a discussion as a formal cross program session, because many core programs are involved ) [1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution [2] PoC source code: https://github.com/stackforge/tricircle [3] Live demo video at YouTube: https://www.youtube.com/watch?v=OSU6PYRz5qY [4] Live demo video at Youku (low quality, for those who can't access YouTube)：http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html [5] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395 .html There are etherpads for suggesting cross project sessions here: https://wiki.openstack.org/wiki/Summit/Planning https://etherpad.openstack.org/p/kilo-crossproject-summit-topics I am interested at comparing this to Nova's cells concept: http://docs.openstack.org/trunk/config-reference/content/section_compute- cells.html Cells basically scales out a single datacenter region by aggregating multiple child Nova installations with an API cell. Each child cell can be tested in isolation, via its own API, before joining it up to an API cell, that adds it into the region. Each cell logically has its own database and message queue, which helps get more independent failure domains. You can use cell level scheduling to restrict people or types of instances to particular subsets of the cloud, if required. It doesn't attempt to aggregate between regions, they are kept independent. Except, the usual assumption that you have a common identity between all regions. It also keeps a single Cinder, Glance, Neutron deployment per region. It would be great to get some help hardening, testing, and building out more of the cells vision. I suspect we may form a new Nova subteam to trying and drive this work forward in kilo, if we can build up enough people wanting to work on improving cells. At CERN, we've deployed cells at scale but are finding a number of architectural issues that need resolution in the short term to attain feature parity. A vision of we all run cells but some of us have only one is not there yet. Typical examples are flavors, security groups and server groups, all of which are not yet implemented to the necessary levels for cell parent/child. We would be very keen on agreeing the strategy in Paris so that we can ensure the gap is closed, test it in the gate and that future features cannot 'wishlist' cell support. I agree with this. I know that there are folks who don't like cells - but I think that ship has sailed. It's there - which means we need to make it first class. Just out of curiosity, would you prioritize cells over split out unified quotas, or a split out scheduler, or split out virt drivers, or a split out ..., or upgrades that work reliably or db quota consistency ([2]) or the other X things that need to be done to keep the 'openstack' ship afloat (neutron integration/migrations... the list can go on and on)? To me that's the part that has always bugged me about cells, it seems like we have bigger 'fish to fry' to get the whole system working in a good manner instead of adding yet another fish in to the already overwhelmed fishery (this is an analogy, not reality, ha). It somehow didn't/doesn't feel right that we have so many other pieces of the puzzle that need
[openstack-dev] [swiftclient]Implement swift service-list in python-swiftclient
Hi, In Horizon dashboard, under Admin- System Info we have service lists for Compute and Block Storage. I have filed a blueprint to populate the Swift services there. But while going through the implementation details of Compute Services and Block Storage Services i got to know that the details there is populated through api calls to python-novaclient and python-cinderclient respectively which in turn uses nova service-list and cinder service-list to return the details. Whereas no such method is implemented in python-swiftclient to get the list of services. So my question is, Do we have plans to include swift service-list in swiftclient ? If yes then I would be filing a blueprint in python-swiftclient to implement the same coz I require it to populate under the Admin - System Info - Object Storage Services. As a side note I can also see it has also not been implemented in some other services like glance and heat. Is it a design decision or the feature has not been simply impemented. Thanks and Regards Ashish Chandra ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
