Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On Mon, 06 Oct 2014 11:24:30 +0200 Julien Danjou jul...@danjou.info wrote: On Sun, Oct 05 2014, Joshua Harlow wrote: 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… Agreed. And a lot of the confusion we get between what is documented to happen and what is implemented in the code is due to different people writing the documentation versus writing the code. And there has been insufficient information (other than the code) left for people to write accurate documentation. For API docs I wonder if we should bringing more of that into the project tree so we can enforce updating of documentation when the code gets updated. Chris ___ 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 Regards, Sergey. On 7 October 2014 00:41, 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. 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] [All] [I18N] compiling translation message catalogs
On 06/10/14 13:35, Ihar Hrachyshka wrote: 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 obviously, I'm for (a). When distros need to patch translation messages for whatever reason, they need to regenerate mo files anyways. In most distributions, use of pre-compiled binaries is forbidden by policy. When seeing it very strict, that might apply to message object files as well. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] kolla, keystone, and endpoints (oh my!)
On Mon, 6 Oct 2014 10:33:21 AM Lars Kellogg-Stedman wrote: 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. What you haven't stated here is whether the catalog endpoints should be reachable outside the kubernetes minions or not. Perhaps we could even use this mysterious(*) keystone publicURL/internalURL division to publish different external and kubernetes-only versions, since we can presumably always do more efficient communication pod-pod. (*) Is the publicURL/internalURL/adminURL split documented anywhere? Does anything other than keystone-manage use anything other than publicURL? 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): This sounds good. Some alternatives off the top of my head, just to feed the discussion: 1. Fixed hostname Add something like this to the start.sh wrapper script: echo $SERVICE_HOST proxy /etc/hosts and then use http://proxy:$port/... etc as the endpoint in keystone catalog. 2. Fixed IP addresses Create a regular OpenStack loadbalancer and configure this (possibly publicly available) IP in keystone catalog. I _think_ this could even be a loadbalancer controlled by the neutron we just set up, assuming the the loadbalancer HA works without help and the nova- neutron bootstrap layer was setup using regular k8s service env vars and not the loadbalancer IPs. Variant a) Create an external proxy kubernetes job that adds itself to a regular OpenStack loadbalancer and forwards traffic to the local kubernetes proxy (and thence to the real backend). We can just walk the standard kubernetes environment variables to find configured k8s services. Variant b) Have an out-of-band job that periodically finds the current location of suitable endpoints using a list pods with label matching and then (re)configures a loadbalancer with the hostports of whatever it finds. Avoids the double proxy inherent in (a) (and (c) aiui), at the cost of more frequent loadbalancer config churn. Variant c) Teach kubernetes how to configure OpenStack loadbalancers directly by adding a kubernetes/pkg/cloudprovider/openstack. Then we add CreateExternalLoadBalancer: true to the appropriate service definitions and kubernetes basically does variant (a) itself. Fwiw, I think we should do (2.c) anyway, just to keep up with the other providers that already exist in kubernetes. I haven't written any go in a year or so, but I might even do this myself. In case it needs to be said, I think we should watch discussions like https://github.com/GoogleCloudPlatform/kubernetes/issues/1161 and try to follow the standard kubernetes approaches as they emerge. - Gus - 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
Re: [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. +1. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Moving docs from wiki to mistral/doc
Folks, I have moved the DSL and API docs to the project (up on review). Now it contains enough examples to get going, also see doc/README.md for some useful hints. Renat, Nikolay, if you find any omissions please add; and once we are happy let’s remove the DSL and API wiki to avoid confusion. Wiki can refer to the readthedocs page (generated with every build). DZ ___ 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 08:58 PM, Anita Kuno wrote: 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
Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
On Mon, Oct 06, 2014 at 04:41:33PM -0400, 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. +1 ___ 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
Sylvain Bauza wrote: 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 ? There are actually Other projects sessions on those slots (the placeholders cover multiple 40-min slots), as can be seen at: http://kilodesignsummit.sched.org/grid/ So we currently have 6 other projects slots, but I hope we can secure a few more. 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] Candidate proposals for TC (Technical Committee) positions are now open
On Tue, Oct 7, 2014 at 6:16 PM, Flavio Percoco fla...@redhat.com wrote: On 10/06/2014 08:58 PM, Anita Kuno wrote: 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
[openstack-dev] [horizon] Packaging Sinon.JS as xstatic
Hello all! Recently I've stumbled upon wonderful Sinon.JS library [1] for stubs and mocks in JS unit tests and found that it can be used for simplifying unit test I've made in [2] and speeding it up. Just before wrapping it as xstatic package I'd like to clarify 2 questions regarding Sinon.JS: * Are Horizon folks fine with adding this dependency? Right now it will be used just for one test, but it would be useful for anybody who wants to mock AJAX requests in tests or emulate timeout events being fired up (again, see very brief and concise examples at [1]). * Is it okay to include QUnit and Jasmine adapters for Sinon.JS in the same xstatic package? Well, personally I'd vote for including QUnit adapter [3] since it has very little code and allows for seamless integration of Sinon.JS with QUnit testing framework. If someone is interested in using Jasmine matchers for Sinon [4], please let me know. [1] http://sinonjs.org/ [2] https://review.openstack.org/#/c/113855/2/horizon/static/horizon/tests/tables.js [3] http://sinonjs.org/qunit/ [4] https://github.com/froots/jasmine-sinon -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] End of DepFreeze, openstack/requirements open for kilo
Hi everyone, All integrated projects have their proposed/juno branch now, so we cut the proposed/juno branch for openstack/requirements yesterday, which results in the end of the DepFreeze period. openstack/requirements is now open for Kilo additions. Cheers, -- 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] [TripleO] a need to assert user ownership in preserved state
Hi On 6 Oct 2014, at 17:41, Clint Byrum cl...@fewbar.com wrote: We have to be _extremely_ careful in how we manage this. I actually think it has potential to really blow up in our faces. Yes, anything we do here has the potential to be extremely ruinous for operators, but the reality is that any existing TripleO deployment is at pretty severe risk of blowing up because of UIDs/GIDs changing when they update. 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. IMO the only desirable option *has* to be that we statically define UIDs and GIDs in the elements, because: 1: Requires no data fragments to be kept safe and fed to subsequent build processes 2: Doesn't do anything dynamic on first boot that could take hours/days 3: Can be thoroughly audited at build time to ensure correctness As you rightly point out though, any existing deployments will definitely be disrupted by this, but as I said above, all we'd be doing there is moving the needle from possible/probable to definite. Since the only leftovers we have from their previous image builds, are the images themselves, we could add the ability for a DIB run to extract IDs from a previous image, but this couldn't be required as a default build option, so we'd still risk existing deployments if they don't notice this feature. We could create a script that would spider an existing cloud and extract its ID mappings, to produce a fragment to feed into future builds, but again we're relying on operators to know that they need to do this. Instead, I agree with Greg's view that this is our fault and we should fix it. We didn't think of this sooner, and as a result, our users are at risk. If we don't entirely fix this ourselves, we will be both expecting them to become aware of this issue and expecting them to do additional work to mitigate it. To that end, I think we should audit all of our elements for use of /mnt/state/ and use the specific knowledge we have of the software they relate to, to build one-time ID migration scripts, which would: 1: Execute before any related services start 2: Compare the now-static ID mappings against known files in /mnt/state 3: chown/chgrp any files/directories that need migrating 4: store a flag file in /mnt/state indicating that this process doesn't need to run again It does mean they have a potentially painfully long update process once, but the result will be a completely stable, static arrangement that will not require them to preserve precious build fragments for the rest of time. Nor does it require some odd run-time remapping, or any additional mechanisms to centralise user management (e.g. LDAP. Please, no LDAP!) I think that tying ourselves and our operators into knots because we're afraid of the hit of one-time data migration, is crazy. AFAICS, the only risk left at that point, is elements that other people are maintaining. If we consider that to be a sufficient risk, we can still build the mechanism for injecting ID values from a previous build (essentially just seeding the static values that we'd be setting anyway) and apologise to the users who need that, or who don't discover its existence and break their clouds. Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sign up for oslo liaisons for kilo cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM= =+HC1 -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] sign up for oslo liaisons for kilo cycle
I am totally not against it. I agree with you that probably the restriction on core-only might be lifted, but that decision lies with the oslo team. Salvatore On 7 October 2014 13:55, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM= =+HC1 -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] sign up for oslo liaisons for kilo cycle
Ihar, Welcome! and thanks for considering signing up to be liaison :) As oslo core, i'd support the relaxation. I think the thinking behind the wording was it would help if folks were core -- dims On Tue, Oct 7, 2014 at 7:55 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. Cheers, /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM= =+HC1 -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] local.conf ini file setting issues
Hi Ian, I agree with your plan. I¹ve +1ed the first two patches. I responded to your comments on [3]. Basically I think that iniadd_literal is necessary. In addition, [3] will also keep the original order of items. With all of the three patches, I think the end result would be that it¹s almost exact copy from local.conf to the destination config file. ‹Robert On 10/6/14, 9:38 PM, Ian Wienand iwien...@redhat.com wrote: Hi, Rather than adding more MAGIC_VARIABLE=foo variables to devstack that really only add lines to config files, I've been asking people to add them to local.conf and provide additional corresponding documentation if required. However increased use has exposed some issues, now covered by several reviews. There seem to be three issues: 1. preservation of quotes 2. splitting of arguments with an '=' in them 3. multi-line support We have several reviews not dependent on each other but which will all conflict. If we agree, I think we should 1. merge [1] to handle quotes 2. merge [2] to handle '='s 3. extract just multi-line support from [3] All include test-cases, which should increase confidence -- I did consider re-implementing a python tool to handle this; there were some things that made me think twice. Firstly ini settings in local.conf are expected to expand shell-vars (path to neutron plugin configs, etc) so you end up shelling out anyway. Secondly ConfigParser doesn't like [[foo]] as a section name (drops the trailing ], maybe a bug) so you have to start playing games there. Using a non-standard library (oslo.config) would be a big change to devstack's current usage of dependencies. -i [1] https://review.openstack.org/124227 [2] https://review.openstack.org/124467/ [3] https://review.openstack.org/124502 ___ 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 19:10, Mike Bayer wrote: 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. - From server side, indeed, proper configuration described in documentation may be enough. Though atm we don't document PostgreSQL settings anywhere. [As for MySQL, both server and client encodings are indeed advised to be set to utf8.] That said, I wonder how we're going to manage cases when those *global* settings for the whole server should be really limited to specific databases. Isn't it better to enforce utf8 on service side, since we already know that we always run against utf8 database? 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. Please let me clarify... Do you say that setting client encoding on oslo.db side is actually ok? I haven't suggested to enforce utf8 per column/table, though I guess we're already there. 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. Forgoing, again, means some users running with utf8 client encoding, others without it. I strive towards consistency here, that's why I try to find a way to set the setting for all clients we support (and the question is *which* of those clients we really support). The thing that is not supported in psql 9.1 is a connection option added to libpq as of: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192 As I said before, we have other ways to set client encoding for psql clients that use libpq 9.1, and the thing I try to determine is whether we consider supporting those versions of libpq. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUM9yfAAoJEC5aWaUY1u571T0IALBgfRSL0PY1q9PC/vpiee2B d++dVM+CU/SRhXh7zlY703K/sdRVvsPGlUNkzPjT0TGa81LbXPKtwVqPIQeUpI5i a+X9HKHksaeidgLyuOPbSic+hFSoQESoYBswLfb0+vhT9JEn2XwzEyJo83c4MDH3 grgi5Crk+xx2uAa3mnEKCkeCOiq6t6V+7s7DKM8qdAEZOvKWlY3JK5W+AF6Smjlj XJkywLXkDy+t+jMMIo2XqlR7xIVoy4wSTZRgbqrHpBqxqhL3/wzk31JnQgant8A+ 2HF8p+Goy0CxoLOYb0LCE4JiHh6aoHXCcUOXW9BmcVBxfRg7el3OcKWJb9g2Q+M= =78+Z -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] Candidate proposals for TC (Technical Committee) positions are now open
On 10/07/2014 05:12 AM, Angus Salkeld wrote: On Tue, Oct 7, 2014 at 6:16 PM, Flavio Percoco fla...@redhat.com wrote: On 10/06/2014 08:58 PM, Anita Kuno wrote: 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
Re: [openstack-dev] sign up for oslo liaisons for kilo cycle
On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. We need someone who can push patches into the project and understands the code well enough to be able to do that without delay. Usually that means a core reviewer. If the Neutron team commits to working closely with you on patches to avoid delays, that would achieve the same ends. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sign up for oslo liaisons for kilo cycle
On 10/07/2014 02:50 PM, Doug Hellmann wrote: On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. We need someone who can push patches into the project and understands the code well enough to be able to do that without delay. Usually that means a core reviewer. If the Neutron team commits to working closely with you on patches to avoid delays, that would achieve the same ends. Agreed with Doug. It's not really a strong requirement. The request of the liaison to be a core reviewer is more a suggestion for the projects themselves in order to make the interaction between both teams easier. That said, we could probably re-word that somehow to reflect the above. 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] sign up for oslo liaisons for kilo cycle
On Tue, Oct 7, 2014 at 7:50 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. We need someone who can push patches into the project and understands the code well enough to be able to do that without delay. Usually that means a core reviewer. If the Neutron team commits to working closely with you on patches to avoid delays, that would achieve the same ends. I am 100% onboard with Ihar being the Neutron team's Osli liaison. Thanks for signing up Ihar, and thanks for working with us here Doug! Kyle Doug ___ 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] TC candidacy
I'm Anne Gentle (hi, Anne!) and I'm writing to announce my candidacy for the technical committee. I've served on the technical committee for two years and have been working on OpenStack since September 2010. I'm currently the Documentation PTL. I'd be honored to continue to represent the cross-project needs as well as the needs of the users, operators, and admins who keep an OpenStack cloud running every day. I've responded to the questions below so you can get to know me a little better. You can also see my review comments on the governance repo https://review.openstack.org/#/q/reviewer:self+project:openstack/governance,n,z Please feel free to ask me questions and challenge my assumptions. I believe good leaders can take on the tough work and we all know there is plenty of hard work to go around. Thanks, Anne Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? The technical community consists of a huge blend of people now, thank goodness, because the mission is a grand sweeping one for private and public clouds. Plus it has the word ubiquitous in it which makes it even more wide-reaching. We're making clouds for the planet and I feel we're tackling, blocking, clearing, and fighting hard to meet the Mission. We're struggling with the simple to implement but we have come a very long way. Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? I feel the TC is supportive of the technical contributors to all the projects that make up OpenStack. We're constantly seeking ways to improve and challenge programs. We began to hold programs accountable for their integration. We pushed the limits of the definition of OpenStack by defining all code that a project maintains as part of OpenStack (defined sections). Yes, it was a defense on the side of our Active Technical Contributor community base, but it was a statement about our ideals - Openness, Transparency, Commonality, Integration, Quality. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? Contributors are motivated in different ways, but we're all humans and behave like humans do. In Peter Kollock's study of online communities, he found these motivating factors for participating: reciprocity, reputation, sense of belonging, efficacy, and need. All of these make sense to me when put in the docs context, why would anyone contribute to upstream documentation? and I can also draw maps and correlations to the overall reasons why contributors work on upstream. We need to be aware of what happens when the need stems from corporate motivation, but I know that OpenStack is a great community to work within and that I can do my part to demonstrate which motivations I want to encourage in our community. Topic: Rate of Growth There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate? Hopefully by now you've seen me represent the cross-project ramifications of this growth rate over the years I've served on the TC. The docs program has had to adjust the expectations and educate incoming programs about how OpenStack documentation is not just project-by-project but an umbrella effort. People come to docs.openstack.org for OpenStack docs, not just nova or glance docs. I hope I have shown bravery in the face of the rate of growth and also pragmatism. Topic: New Contributor Experience How would you characterize the experience new contributors have currently? As an admin for the GNOME Outreach Program for Women for the last two years, I have helped with on-boarding new interns who have to have a patch in order to complete their application. Really, though, the previous interns do a lion's share of the work in on-boarding newcomers to our community. I think this is because their eyes are freshest to the difficulties you'll encounter while figuring out our unique processes. I'm also amazed at how a wonderful small community has grown up out of helping others learn, and that's been the best part about seeing new contributors coming in. We've done a lot to make installing git review easier and specifically setting up the gerrit remote. So the very first on-boarding experiences can get better. Now, the experience of those of us a few years in isn't great either as reviews are harder and harder to get through and our gate is stuffed full with patches wanting in. I think we can work on both experiences at the same time to make it better for all contributors. Topic: Communication How would you describe our current state of communication in the OpenStack community? Communication with such a wide, growing population can be difficult but I think we have the channels available with opt-in policies that make sense for our community. The TC listens on many channels, I know I'm subscribed to all the mailing lists without filters
Re: [openstack-dev] [nova] Resource tracker
On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote: 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 is just an example of problems with the way Nova virt drivers /currently/ report usage to the schedular. It is easily within the realm of possibility for the virt drivers to be changed so that they report stats which take into account things like ballooning and thin provisioning so that we don't oversubscribe. Ignoring the hypervisor stats entirely and re-doing the calculations in the resource tracker code is just a crude workaround really. It is just swapping one set of problems for a new set of problems. 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. I'm against the idea of adding config options to switch between multiple codepaths because it is just punting the problem to the admins who are in an even worse position to decide what is best. It is saying would you rather your cloud have bug A or have bug B. We should be fixing the data the hypervisors report so that the resource tracker doesn't have to ignore them, and give the admins something which just works and avoid having to choose between 2 differently broken options. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading
Hello, Joshua, Thank you for your concerns on OpenStack cascading. I am afraid that I am not proper person to give comment on cells, but I would like to speak a little about cascading for you mentioned with its own set of consistency warts I'm sure . 1. For small scale or a cloud within one data centers, one OpenStack instance (including cells) without cascading feature can work just like it work today. OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... like other vendor specific agent/driver( for example, vcenter driver, hyper-v driver, linux-agent.. ovs-agent ), and does not change the current architecture for Nova/Cinder/Neutron..., and does not affect the aleady developed features and deployment capability. The cloud operators can skip the existence of OpenStack cascading if they don't want to use it, just like they don't want to use some kinds of hypervisor / sdn controller 2. Could you provide concrete inconsistency issues you are worried about in OpenStack cascading? Although we did not implement inconsistency check in the PoC source code completely, but because logical VM/Volume/Port/Network... objects are stored in the cascading OpenStack, and the physical objects are stored in the cascaded OpenStack, uuid mapping between logical object and physical object had been built, it's possible and easy to solve the inconsistency issues. Even for flavor, host aggregate, we have method to solve the inconsistency issue. Best Regards Chaoyi Huang ( joehuang ) From: Joshua Harlow [harlo...@outlook.com] Sent: 07 October 2014 12:21 To: OpenStack Development Mailing List (not for usage questions) Subject: 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
[openstack-dev] [neutron] Priorities for Kilo and the Summit
In today's Neutron meeting, we'll spend a portion of the time starting to go over the Summit ideas we have proposed on our etherpad here [1]. The list is incredibly long, so I expect the process we use to select our topics for Paris to include a lot of paring down. I'd also like to emphasize that for Kilo, I expect the focus to be on paying down technical debt. In particular, the core team will need to help focus on finally getting some of the refactoring around things like Pecan, tasks, etc. done. We'll also need to work closely with the nova team on the neutron/nova integration points, as well as continue to refine the short, medium and long-term migration story for nova-network to neutron. In addition, I expect a focus to come in from the NFV sub-team in OpenStack as well. We'll discuss in more detail, but I wanted to give the broader community an idea of where Neutron's focus will be for the next 6 months. Thanks, Kyle [1] https://etherpad.openstack.org/p/kilo-neutron-summit-topics ___ 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
My data consistency concerts would be around: 1) Defining global state. You can of course hand wave away a lot of your issues by saying they are all local to the sub-unit, but then what benefit are you providing .v. just providing a list of endpoints and teaching the clients to talk to multiple endpoints, which is far easier to make reliable than a new service generally is. State that 'ought' to be global: quota, usage, floating ips, cinder backups, and probably a bunch more 2) Data locality expectations. You have to be careful about what expectations .v. realty you're providing here. If the user experience is substantially different using your proxy .v. direct API, then I don't think you are providing a useful service - again, just teach the clients to be multi-cloud aware. This includes what can be connected to what (cinder volumes, snaps, backups, networks, etc), replication behaviours and speeds (swift) and probably a bunch more that I haven't thought of yet. On 7 October 2014 14:24, joehuang joehu...@huawei.com wrote: Hello, Joshua, Thank you for your concerns on OpenStack cascading. I am afraid that I am not proper person to give comment on cells, but I would like to speak a little about cascading for you mentioned with its own set of consistency warts I'm sure . 1. For small scale or a cloud within one data centers, one OpenStack instance (including cells) without cascading feature can work just like it work today. OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... like other vendor specific agent/driver( for example, vcenter driver, hyper-v driver, linux-agent.. ovs-agent ), and does not change the current architecture for Nova/Cinder/Neutron..., and does not affect the aleady developed features and deployment capability. The cloud operators can skip the existence of OpenStack cascading if they don't want to use it, just like they don't want to use some kinds of hypervisor / sdn controller 2. Could you provide concrete inconsistency issues you are worried about in OpenStack cascading? Although we did not implement inconsistency check in the PoC source code completely, but because logical VM/Volume/Port/Network... objects are stored in the cascading OpenStack, and the physical objects are stored in the cascaded OpenStack, uuid mapping between logical object and physical object had been built, it's possible and easy to solve the inconsistency issues. Even for flavor, host aggregate, we have method to solve the inconsistency issue. Best Regards Chaoyi Huang ( joehuang ) From: Joshua Harlow [harlo...@outlook.com] Sent: 07 October 2014 12:21 To: OpenStack Development Mailing List (not for usage questions) Subject: 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]
Re: [openstack-dev] TC candidacy
confirmed On 07/10/14 09:19 AM, Anne Gentle wrote: I'm Anne Gentle (hi, Anne!) and I'm writing to announce my candidacy for the technical committee. I've served on the technical committee for two years and have been working on OpenStack since September 2010. I'm currently the Documentation PTL. I'd be honored to continue to represent the cross-project needs as well as the needs of the users, operators, and admins who keep an OpenStack cloud running every day. I've responded to the questions below so you can get to know me a little better. You can also see my review comments on the governance repo https://review.openstack.org/#/q/reviewer:self+project:openstack/governance,n,z Please feel free to ask me questions and challenge my assumptions. I believe good leaders can take on the tough work and we all know there is plenty of hard work to go around. Thanks, Anne Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? The technical community consists of a huge blend of people now, thank goodness, because the mission is a grand sweeping one for private and public clouds. Plus it has the word ubiquitous in it which makes it even more wide-reaching. We're making clouds for the planet and I feel we're tackling, blocking, clearing, and fighting hard to meet the Mission. We're struggling with the simple to implement but we have come a very long way. Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? I feel the TC is supportive of the technical contributors to all the projects that make up OpenStack. We're constantly seeking ways to improve and challenge programs. We began to hold programs accountable for their integration. We pushed the limits of the definition of OpenStack by defining all code that a project maintains as part of OpenStack (defined sections). Yes, it was a defense on the side of our Active Technical Contributor community base, but it was a statement about our ideals - Openness, Transparency, Commonality, Integration, Quality. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? Contributors are motivated in different ways, but we're all humans and behave like humans do. In Peter Kollock's study of online communities, he found these motivating factors for participating: reciprocity, reputation, sense of belonging, efficacy, and need. All of these make sense to me when put in the docs context, why would anyone contribute to upstream documentation? and I can also draw maps and correlations to the overall reasons why contributors work on upstream. We need to be aware of what happens when the need stems from corporate motivation, but I know that OpenStack is a great community to work within and that I can do my part to demonstrate which motivations I want to encourage in our community. Topic: Rate of Growth There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate? Hopefully by now you've seen me represent the cross-project ramifications of this growth rate over the years I've served on the TC. The docs program has had to adjust the expectations and educate incoming programs about how OpenStack documentation is not just project-by-project but an umbrella effort. People come to docs.openstack.org for OpenStack docs, not just nova or glance docs. I hope I have shown bravery in the face of the rate of growth and also pragmatism. Topic: New Contributor Experience How would you characterize the experience new contributors have currently? As an admin for the GNOME Outreach Program for Women for the last two years, I have helped with on-boarding new interns who have to have a patch in order to complete their application. Really, though, the previous interns do a lion's share of the work in on-boarding newcomers to our community. I think this is because their eyes are freshest to the difficulties you'll encounter while figuring out our unique processes. I'm also amazed at how a wonderful small community has grown up out of helping others learn, and that's been the best part about seeing new contributors coming in. We've done a lot to make installing git review easier and specifically setting up the gerrit remote. So the very first on-boarding experiences can get better. Now, the experience of those of us a few years in isn't great either as reviews are harder and harder to get through and our gate is stuffed full with patches wanting in. I think we can work on both experiences at the same time to make it better for all contributors. Topic: Communication How would you describe our current state of communication in the OpenStack community? Communication with such a wide, growing population can be difficult but I think we have the channels available with opt-in
[openstack-dev] [Fuel] Cluster reconfiguration scenarios
Hi folks, I want to discuss cluster reconfiguration scenarios, i am aware of 2 such bugs: - ceph-mon not installed on controllers if cluster initially was deployed without ceph-osd - config with rabbitmq hosts not updated on non-controlles nodes after additional controllers is added to cluster [1] In both cases we need to track node state and change it accordingly to some event (additonal ceph-osd, additional controller added to cluster, etc..). I think that it is generic scenario and our api should support such modifications. To track state of node we need to introduce new state - something in lines of requires_update. And extend deployment selection logic to include nodes with this state, if deploy action will be invoked. What do you think about such feature? I would be grateful for any other cases. [1] https://bugs.launchpad.net/fuel/+bug/1368445 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Cinder/Neutron plugins on UI
Hi, We had a meeting today about plugins on UI, as result of the meeting we have two approaches and this approaches affect not only UX but plugins itself. *1st - disable/enable plugin on settings tab* 1. user installs the plugin 2. creates a cluster 3. configures and enables/disables plugins on settings tab For user it will look like Ceph plugin checkboxes on settings tab, if he enables checkbox, then we pass the parameter to orchestrator as `true`. Cons: - plugin developer should define a checkbox in each plugin (for plugin disabling/enabling) - on the backend we have to enable all of the plugins for environment, because user can define any name for his checkbox and we won't be able to find it and make appropriate mapping plugin - env - since all of the plugins are always enabled we have to run tasks for all of the plugins, and each plugin should parse astute.yaml in order to figure out if it's required to run task current script Pros: - it won't require additional setting or step for wizard - user will be able to disable plugin after environment creation *2nd - enable plugins in wizard* 1. user installs the plugin 2. now he can choose specific plugins for his environment in wizard 3. after cluster is created, he can configure additional parameters on settings tab, if plugin provides any Cons: - user won't be able to disable plugin after cluster is created - additional step or configuration subcategory in wizard Pros: On backend we always know which plugin is disabled and which is enabled. - it means we don't provide settings for plugins which are disabled - we don't run tasks on slaves if it's not required Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] sign up for oslo liaisons for kilo cycle
Last cycle the Ironic liaison wasn't a core reviewer and things worked. So I agree with the idea of relaxing the recommendation. Ghe Rivero (Ironic liaison) On 07/10/14 14:50, Doug Hellmann wrote: On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Signed PGP part On 06/10/14 17:56, Doug Hellmann wrote: 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 Quoting the page: The liaison should be a core reviewer for the project. Is it a reasonable limitation? I suspect that being an Oslo liaison usually does not really require the core status. Any team member with visible level of participation in the project and decent communication skills should be able to do the job. Why I ask: I would probably consider signing up for the liaison program from Neutron side if 1) the program rules would not be that tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be against it. We need someone who can push patches into the project and understands the code well enough to be able to do that without delay. Usually that means a core reviewer. If the Neutron team commits to working closely with you on patches to avoid delays, that would achieve the same ends. Doug ___ 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] [Keystone] Question regarding Service Catalog and Identity entries...
I am trying to use the Python Keystone client to integration authentication functionality into a project I am contributing to (https://github.com/rackerlabs/deuce-client). However, I ran into a situation where if I do the following: c = keystoneclient.v2_0.client.Client(username='username', password='password', auth_url=https://keystone-compatible-service.example.com/v2.0/;) Failed to retrieve management_url from token I traced it through the Python Keystoneclient code and it fails due to not finding the identity service entry in the Service Catalog. The authentication otherwise happens in that it has already received a successful response and a full Service Catalog, aside from the missing identity service. This happens with both version 0.10 and 0.11 python keystone clients; I did not try older clients. Talking with the service provider, their version does not include itself in the Service Catalog, and they learned the Keystone itself inserts itself into the Service Catalog. I can certainly understand why it having the identity service entry be part of the Service Catalog, but for them it is (at least for now) not desirable to do so. Questions: - Is it now a standard that Keystone inserts itself into the Service Catalog? - Or is the Python Keystone Client broken because it is forcing it to be so? Thanks, Benjamen R. Meyer ___ 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)
Thank you, Jeremy. That solved it. Jennifer Mulsow Cloud Systems Software Development IBM Systems Technology Group From: Jeremy Stanley fu...@yuggoth.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 10/06/2014 06:05 PM Subject: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 [attachment signature.asc deleted by Jennifer Mulsow/Austin/IBM] ___ 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 Mon, Oct 06 2014, 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
[openstack-dev] [neutron] Creation of neutron-drivers team
As discussed in today's meeting [1], I've created a neutron-drivers team [2], which was modeled on the same way as the existing nova-drivers team. This team will be responsible for approving specs for Kilo. Please see the wiki page for the long story, but the short story is that as focused team driving spec approval and a consistent architectural approach for Neutron in Kilo will be good for the long-term health of the project. As with all things process related, we'll try this out in Kilo and adjust accordingly at the end. I wanted to keep the broader community aware of this new team. Thanks! Kyle [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-07-14.01.html [2] https://wiki.openstack.org/wiki/Neutron-drivers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Treating notifications as a contract
On Wed, 3 Sep 2014, Sandy Walsh wrote: Good goals. When Producer and Consumer know what to expect, things are good ... I know to find the Instance ID here. When the consumer wants to deal with a notification as a generic object, things get tricky (find the instance ID in the payload, What is the image type?, Is this an error notification?) Basically, how do we define the principle artifacts for each service and grant the consumer easy/consistent access to them? (like the 7-W's above) I'd really like to find a way to solve that problem. Is that a good summary? What did I leave out or get wrong? Great start! Let's keep it simple and do-able. Has there been any further thinking on these topics? Summit is soon and kilo specs are starting so I imagine more people than just me are hoping to get rolling on plans. If there is going to be a discussion at summit I hope people will be good about keeping some artifacts for those of us watching from afar. It seems to me that if the notifications ecosystem becomes sufficiently robust and resilient we ought to be able to achieve some interesting scale and distributed-ness opporunities throughout OpenStack, not just in telemetry/metering/eventing (choose your term of art). -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI
Hi Dmitry, In 1st case - in tasks we will introduce simple conditions (in description or in python code of the plugin): You will be able to do it in the same way in case of 2nd solution. I mean there is no constraints on conditions defining. Also, we should not forget about CLI In case of cli we can provide special parameter and user will be able to create env with specific plugins. Thanks, On Tue, Oct 7, 2014 at 6:51 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi, I would use 1st option. Consider plugins which is mutually exclusive, and you need to disable default tasks if plugin is selected. As example: - neutron backend plugins neutron_backend: choices: - ovs - contrail value: ovs Right now we are using ovs as neutron_backend, but what we will need to do if plugin will provide completely different backend, as contrail? In 1st case - in tasks we will introduce simple conditions (in description or in python code of the plugin): condition: 'ovs == cluster.attributes.neutron_backend' - for default workflow condition: 'contrail == cluster.attributes.neutron_backend' - contrail plugin workflow And if we need to exclude some task from workflow - simply select another value from drop down list. I believe same applies for glance/cinder backends (lvm/ceph, swift/ceph). Atleast we are managing them this way right now. Also, we should not forget about CLI. I can easily imagine how operator downloads cluster config (big cluster attributes file) and modifies it accordingly to turn on specific plugins. How we will manage plugins from cli if plugins will be managed from wizard? On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L e...@mirantis.com wrote: Hi, We had a meeting today about plugins on UI, as result of the meeting we have two approaches and this approaches affect not only UX but plugins itself. *1st - disable/enable plugin on settings tab* 1. user installs the plugin 2. creates a cluster 3. configures and enables/disables plugins on settings tab For user it will look like Ceph plugin checkboxes on settings tab, if he enables checkbox, then we pass the parameter to orchestrator as `true`. Cons: - plugin developer should define a checkbox in each plugin (for plugin disabling/enabling) - on the backend we have to enable all of the plugins for environment, because user can define any name for his checkbox and we won't be able to find it and make appropriate mapping plugin - env - since all of the plugins are always enabled we have to run tasks for all of the plugins, and each plugin should parse astute.yaml in order to figure out if it's required to run task current script Pros: - it won't require additional setting or step for wizard - user will be able to disable plugin after environment creation *2nd - enable plugins in wizard* 1. user installs the plugin 2. now he can choose specific plugins for his environment in wizard 3. after cluster is created, he can configure additional parameters on settings tab, if plugin provides any Cons: - user won't be able to disable plugin after cluster is created - additional step or configuration subcategory in wizard Pros: On backend we always know which plugin is disabled and which is enabled. - it means we don't provide settings for plugins which are disabled - we don't run tasks on slaves if it's not required Thanks, ___ 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] [Fuel] Cluster reconfiguration scenarios
Hi, I'm not sure if we should add the new state in this case, it looks like you can get this information dynamically, you already have the state of env which tells you that there are new ceph nodes, and there are no ready ceph nodes in the cluster hence you should install ceph-mon on the controllers. The same for rabbitmq, if there is new controller, run rabbit reconfiguration on non-controllers nodes. Thanks, On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi folks, I want to discuss cluster reconfiguration scenarios, i am aware of 2 such bugs: - ceph-mon not installed on controllers if cluster initially was deployed without ceph-osd - config with rabbitmq hosts not updated on non-controlles nodes after additional controllers is added to cluster [1] In both cases we need to track node state and change it accordingly to some event (additonal ceph-osd, additional controller added to cluster, etc..). I think that it is generic scenario and our api should support such modifications. To track state of node we need to introduce new state - something in lines of requires_update. And extend deployment selection logic to include nodes with this state, if deploy action will be invoked. What do you think about such feature? I would be grateful for any other cases. [1] https://bugs.launchpad.net/fuel/+bug/1368445 ___ 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 10/06/2014 04:41 PM, 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. Obviously past 5 +1 votes here, but showing full support doesn't hurt. 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] TC candidacy
Hi everybody! I'd like to announce my candidacy for re-election to the TC. tl;dr - Vote for me or vote for someone else you prefer I've been around the project for quite a while, having been on the phone calls where we were discussing the name OpenStack - although I'll admit I had absolutely zero decision making power there. The first decision in the project I took any active part in shaping was the decision to keep the code names nova and swift and not to rename each project openstack-compute and openstack-object-storage. My main technical focus within OpenStack is in Infra, where I am a former PTL and current core. I tend to focus energy on cross-project concerns over individual project concerns. I believe that a strong OpenStack comes from a high degree of coordination and standardization - but I think it's important to keep standardization in perspective as a tool to help us make a better product and not an goal in and of itself. As an Infra team member, I am a fairly large end-user of OpenStack. Infra runs across two public clouds and a private cloud run by the TripleO team. Although I sometimes express it in a non-productive and rage-filled way, I regularly experience first hand what our end users experience ... which is both awesome and not-awesome ... and I've been spending more and more of my effort on improving that experience. As may be clear from my big-tent blog post, I believe it's highly important to be inclusive in who we are, while at the same time collectively taking a higher amount of accountability for the quality of what we produce. Finally, there is a natural tug between exciting new features to make people's lives better and the quality of the existing features we have. We've been growing at a rather unprecedented pace over the last four years, so at the moment I think we need a double-down on quality and stability with less of a focus on adding features. As with everything else though, this is a balancing act and the relative importance changes continually. Balancing the competing needs such as the ones above is what I believe the main job of the TC is. We have process, we have policy, we have governance structure - but ultimately humans need to talk and make decisions, even if the decision is to do nothing. I think as the TC we need to own that responsibility and not shrink from it when it's hard or potentially unpopular. == The questions == Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? In case you haven't read it recently: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. If there is anyone out there who feels we've nailed simple to implement I'd love to meet them. I think we've been focusing on all of the other parts - I'd like to see more attention placed on simple to implement Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? In case you haven't read it recently: The Technical Committee (TC) is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project. I think over the last year since we became all-elected, the TC has been doing a better and better job. Historically the TC has been a bit reluctant to own the words technical leadership Over the past cycle or two, the TC has consistently been stepping more up to the plate on this topic, and I think that trend needs to continue. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? I'm pretty sure the majority of our contributors are doing so as part of their jobs. I think this makes our dynamic a bit different than a traditional Open Source project. That said - I think we see a very strong set of people who are passionate about what we're doing evidenced by the number of people who have worked for multiple companies while working on OpenStack. I can't speak to everyone's motivation - but I can tell you what mine is. Cloud is taking over as the way we think about how IT works. It's not an if, it's a when. But even with that, Cloud is an idea more than a destination. When we started, there was one legitimate definition for Cloud and it was Amazon. Amazon is a closed-source company run by a ruthless dictator. I do not want to live in a world where I need his permission to use a computer. Over the last four years, we've made significant inroads in redefining what Cloud can be. Containers and bare-metal are now legitimate building blocks and I think it's becomming understood that
Re: [openstack-dev] [qa] In-tree functional test vision
On Mon, 25 Aug 2014, Joe Gordon wrote: On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent chd...@redhat.com wrote: For constraints: Will tempest be available as a stable library? Is using tempest (or other same library across all projects) a good or bad thing? Seems there's some disagreement on both of these. Yes, there is a separate thread on spinning out a tempest-lib (not sure on what final name will be yet) that functional tests can use. Although I think there is a lot to be done before needing the tempest-lib. What's the status of tempest-lib? Looking at the repo it appears that other things may be taking priority at the moment. As I said in notifications thread: With summit approaching and kilo open for business, now seems to be talking about what kinds of structure we want to apply to in-tree functional testing. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ 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 10/07/2014 06:41 AM, Duncan Thomas wrote: My data consistency concerts would be around: 1) Defining global state. You can of course hand wave away a lot of your issues by saying they are all local to the sub-unit, but then what benefit are you providing .v. just providing a list of endpoints and teaching the clients to talk to multiple endpoints, which is far easier to make reliable than a new service generally is. State that 'ought' to be global: quota, usage, floating ips, cinder backups, and probably a bunch more BTW - since infra regularly talks to multiple clouds, I've been working on splitting supporting code for that into a couple of libraries. Next pass is to go add support for it to the clients, and it's not really a lot of work ... so let's assume that the vs. here is going to be accomplished soonish for the purposes of assessing the above question. Second BTW - you're certainly right about the first two in the global list - we keep track of quota and usage ourselves inside of nodepool. Actually - since nodepool already does a bunch of these things - maybe we should just slap a REST api on it... 2) Data locality expectations. You have to be careful about what expectations .v. realty you're providing here. If the user experience is substantially different using your proxy .v. direct API, then I don't think you are providing a useful service - again, just teach the clients to be multi-cloud aware. This includes what can be connected to what (cinder volumes, snaps, backups, networks, etc), replication behaviours and speeds (swift) and probably a bunch more that I haven't thought of yet. On 7 October 2014 14:24, joehuang joehu...@huawei.com wrote: Hello, Joshua, Thank you for your concerns on OpenStack cascading. I am afraid that I am not proper person to give comment on cells, but I would like to speak a little about cascading for you mentioned with its own set of consistency warts I'm sure . 1. For small scale or a cloud within one data centers, one OpenStack instance (including cells) without cascading feature can work just like it work today. OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... like other vendor specific agent/driver( for example, vcenter driver, hyper-v driver, linux-agent.. ovs-agent ), and does not change the current architecture for Nova/Cinder/Neutron..., and does not affect the aleady developed features and deployment capability. The cloud operators can skip the existence of OpenStack cascading if they don't want to use it, just like they don't want to use some kinds of hypervisor / sdn controller 2. Could you provide concrete inconsistency issues you are worried about in OpenStack cascading? Although we did not implement inconsistency check in the PoC source code completely, but because logical VM/Volume/Port/Network... objects are stored in the cascading OpenStack, and the physical objects are stored in the cascaded OpenStack, uuid mapping between logical object and physical object had been built, it's possible and easy to solve the inconsistency issues. Even for flavor, host aggregate, we have method to solve the inconsistency issue. Best Regards Chaoyi Huang ( joehuang ) From: Joshua Harlow [harlo...@outlook.com] Sent: 07 October 2014 12:21 To: OpenStack Development Mailing List (not for usage questions) Subject: 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
Re: [openstack-dev] [Fuel] Cluster reconfiguration scenarios
We are definitely able to parse all this information at the time of deployment and generate deployment info accordingly, but my idea was that additional status will provide more visibility for operator. It just wont be obivious - you added controllers/ceph-osd and suddenly your computes/controllers are in deployment mode. On Tue, Oct 7, 2014 at 6:17 PM, Evgeniy L e...@mirantis.com wrote: Hi, I'm not sure if we should add the new state in this case, it looks like you can get this information dynamically, you already have the state of env which tells you that there are new ceph nodes, and there are no ready ceph nodes in the cluster hence you should install ceph-mon on the controllers. The same for rabbitmq, if there is new controller, run rabbit reconfiguration on non-controllers nodes. Thanks, On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi folks, I want to discuss cluster reconfiguration scenarios, i am aware of 2 such bugs: - ceph-mon not installed on controllers if cluster initially was deployed without ceph-osd - config with rabbitmq hosts not updated on non-controlles nodes after additional controllers is added to cluster [1] In both cases we need to track node state and change it accordingly to some event (additonal ceph-osd, additional controller added to cluster, etc..). I think that it is generic scenario and our api should support such modifications. To track state of node we need to introduce new state - something in lines of requires_update. And extend deployment selection logic to include nodes with this state, if deploy action will be invoked. What do you think about such feature? I would be grateful for any other cases. [1] https://bugs.launchpad.net/fuel/+bug/1368445 ___ 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] TC candidacy
confirmed On 07/10/14 11:25 AM, Monty Taylor wrote: Hi everybody! I'd like to announce my candidacy for re-election to the TC. tl;dr - Vote for me or vote for someone else you prefer I've been around the project for quite a while, having been on the phone calls where we were discussing the name OpenStack - although I'll admit I had absolutely zero decision making power there. The first decision in the project I took any active part in shaping was the decision to keep the code names nova and swift and not to rename each project openstack-compute and openstack-object-storage. My main technical focus within OpenStack is in Infra, where I am a former PTL and current core. I tend to focus energy on cross-project concerns over individual project concerns. I believe that a strong OpenStack comes from a high degree of coordination and standardization - but I think it's important to keep standardization in perspective as a tool to help us make a better product and not an goal in and of itself. As an Infra team member, I am a fairly large end-user of OpenStack. Infra runs across two public clouds and a private cloud run by the TripleO team. Although I sometimes express it in a non-productive and rage-filled way, I regularly experience first hand what our end users experience ... which is both awesome and not-awesome ... and I've been spending more and more of my effort on improving that experience. As may be clear from my big-tent blog post, I believe it's highly important to be inclusive in who we are, while at the same time collectively taking a higher amount of accountability for the quality of what we produce. Finally, there is a natural tug between exciting new features to make people's lives better and the quality of the existing features we have. We've been growing at a rather unprecedented pace over the last four years, so at the moment I think we need a double-down on quality and stability with less of a focus on adding features. As with everything else though, this is a balancing act and the relative importance changes continually. Balancing the competing needs such as the ones above is what I believe the main job of the TC is. We have process, we have policy, we have governance structure - but ultimately humans need to talk and make decisions, even if the decision is to do nothing. I think as the TC we need to own that responsibility and not shrink from it when it's hard or potentially unpopular. == The questions == Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? In case you haven't read it recently: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. If there is anyone out there who feels we've nailed simple to implement I'd love to meet them. I think we've been focusing on all of the other parts - I'd like to see more attention placed on simple to implement Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? In case you haven't read it recently: The Technical Committee (TC) is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project. I think over the last year since we became all-elected, the TC has been doing a better and better job. Historically the TC has been a bit reluctant to own the words technical leadership Over the past cycle or two, the TC has consistently been stepping more up to the plate on this topic, and I think that trend needs to continue. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? I'm pretty sure the majority of our contributors are doing so as part of their jobs. I think this makes our dynamic a bit different than a traditional Open Source project. That said - I think we see a very strong set of people who are passionate about what we're doing evidenced by the number of people who have worked for multiple companies while working on OpenStack. I can't speak to everyone's motivation - but I can tell you what mine is. Cloud is taking over as the way we think about how IT works. It's not an if, it's a when. But even with that, Cloud is an idea more than a destination. When we started, there was one legitimate definition for Cloud and it was Amazon. Amazon is a closed-source company run by a ruthless dictator. I do not want to live in a world where I need his permission to use a computer. Over the last four years, we've made
[openstack-dev] Horizon and Keystone: API Versions and Discovery
Horizon has a config options which says which version of the Keystone API it should work against: V2 or V3. I am not certain that there is still any reason for Horizon to go against V2. However, If we defer the decision to Keystone, we come up against the problem of discovery. On the surface it is easy, as the Keystone client supports version discovery. The problem is that discovery must be run for each new client creation, and Horizon uses a new client per request. That would mean that every request to Horizon that talks to Keystone would generate at least one additional request. Is this significant? It gets a little worse when you start thinking about all of the other services out there. If each new request that has to talk to multiple services needs to run discovery, you can image that soon the majority of network chatter would be discovery based. It seems to me that Horizon should somehow cache this data, and share it among clients. Note that I am not talking about user specific data like the endpoints from the service catalog for a specific project. But the overall service catalog, as well as the supported versions of the API, should be cacheable. We can use the standard HTTP cache management API on the Keystone side to specify how long Horizon can trust the data to be current. I think this actually goes for the rest of the endpoints as well: we want to get to a much smaller service catalog, and we can do that by making the catalog holds on IDs. The constraints spec for endpoint binding will be endpoint only anyway, and so having the rest of the endpoint data cached will be valuable there as well. ___ 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 7 October 2014 16:30, Monty Taylor mord...@inaugust.com wrote: Second BTW - you're certainly right about the first two in the global list - we keep track of quota and usage ourselves inside of nodepool. Actually - since nodepool already does a bunch of these things - maybe we should just slap a REST api on it... Whether or not it does much for this use-case, Nodepool-aaS would definitely be useful I think, particularly if it was properly multi-tenant. It isn't /hard/ to set up, but it's effort and yet another cog to understand and debug. ___ 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 7, 2014, at 8:29 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: That said, I wonder how we're going to manage cases when those *global* settings for the whole server should be really limited to specific databases. Isn't it better to enforce utf8 on service side, since we already know that we always run against utf8 database? I think whenever we do a “CREATE DATABASE”, we should make sure the desired encodings are set up at that level. I’ve seen lots of migration scripts that are listing through tables and setting each table individually to utf-8, and that’s less than ideal, though I suppose that’s more of a retroactive fix. Please let me clarify... Do you say that setting client encoding on oslo.db side is actually ok? I haven't suggested to enforce utf8 per column/table, though I guess we're already there. The way we are setting client encoding now should be fine, if you could clarify what about that isn’t working for PG 8.4 that would be helpful.IMHO especially on Postgresql we should be able to get away with not having it. MySQLdb is not as nicely implemented as far as encoding (including the use_unicode speed issues) so it may be more necessary there. But yes what I really *dont* want is the encoding set up on every column definition, e.g. “VARCHAR(20) CHARACTER SET ‘utf-8’”, that’s been suggested before and that would be terrible. I don’t think Postgresql has quite the same thing available (only collation per column). Forgoing, again, means some users running with utf8 client encoding, others without it. I strive towards consistency here, that's why I try to find a way to set the setting for all clients we support (and the question is *which* of those clients we really support). The thing that is not supported in psql 9.1 is a connection option added to libpq as of: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192 OK but that is just the connection parameter, when you pass client_encoding to SQLAlchemy’s psycopg2 dialect, the encoding is set using psycopg2’s set_client_encoding() method: http://initd.org/psycopg/docs/connection.html#connection.set_client_encoding. This ultimately emits “SET client_encoding TO ‘utf8’” on the connection: conn_set_client_encoding - https://github.com/psycopg/psycopg2/blob/master/psycopg/connection_int.c#L1188 pq_set_guc_locked - https://github.com/psycopg/psycopg2/blob/master/psycopg/pqpath.c#L709 “SET client_encoding TO value” is supported in all Postgresql versions, here’s 8.0: http://www.postgresql.org/docs/8.0/static/multibyte.html So there’s no issue with Postgresql 8.2 here as far as client encoding, the libpq feature isn’t used for that. Also, it defaults to the encoding that is set for the database (e.g. server side), so if we make sure CREATE DATABASE is emitted with the encoding, then we wouldn’t even need to set it (and perhaps we shouldn’t if the database is set to a different encoding). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets
A number of bugs[1][2][3] have been filed which are related to updating the IPv6 attributes after a subnet has been created. In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and questions have been raised, which were discussed in today's IPv6 IRC meeting[6]. Summary: In Juno we are not ready for allowing the IPv6 attributes on a subnet to be updated after the subnet is created, because: - The implementation for supporting updates is incomplete. - Perceived lack of usefulness, no good use cases known yet. - Allowing updates causes more complexity in the code. - Have not tested that radvd, dhcp, etc. behave OK after update. Therefore we are proposing to change 'allow_put' to False for the two IPv6 attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes from being updated via the PUT:subnets API. We would be interested to hear of any disagreements or questions. [1] https://launchpad.net/bugs/1362966 [2] https://launchpad.net/bugs/1363064 [3] https://launchpad.net/bugs/1373417 [4] https://review.openstack.org/125328 [5] https://review.openstack.org/117799 [6] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC candidacy
Greetings OpenStackers, I would like to announce my candidacy for the OpenStack Technical Committee. I have worked closely with the TC since around the time that Heat was incubated, two years ago. I have been a regular participant in TC meetings throughout the Juno cycle as the Heat PTL, so I am familiar with the current structures and procedures, their back-story, and the issues that are before the committee. I think I can best contribute by digging deep into issues, rooting out the points of contention or misunderstanding and building consensus from there. If you follow openstack-dev closely you'll probably have seen me doing that quite a bit already. I don't claim to have all the answers, but I'm pretty good at asking questions. The OpenStack project has been incredibly successful in building a strong community where people want to collaborate on solving problems for our common users.[1] We are at a point where we need to readjust the structure of the project to better respond to the next phase of that success. This is not the first time we have reached such a point; nor will it be the last. There is no final form of the OpenStack project; we must approach it as we would any engineering problem (_not_, I hasten to add, a technical problem): by considering our goals and opportunities, making incremental changes, evaluating their effects (both intended and unintended), and repeating. I believe we need to work to reduce entropy in the OpenStack system - encouraging shared components and implementations over repeatedly reinventing the wheel - without crushing innovation. Those two goals are in tension (note that the wheel has been repeatedly reinvented throughout history, often to great effect), but they are the ones I will be trying to balance. And we must, of course, do this while giving operators and end-users confidence in their investments in the OpenStack ecosystem. I think making it easier for projects to join the OpenStack community would be a good thing, provided that still entails a commitment to doing things the OpenStack way backed up by meaningful oversight by the TC. I'm comfortable for now with leaving a high bar for graduation in place, though it needs to move around less. While I am in favour of more projects in principle, I'll be scrutinising specific projects carefully to make sure that they've either been able to apply the feedback part of the engineering process I described above with real users, or alternatively have solved the simplest possible version of their design problem with a view to maximising their flexibility to respond when they do get that feedback.[2] What we're really missing are stepping stones from the lower incubation bar to the high graduation bar. We need to do more to help projects understand how they can fit in to the bigger picture and what they need to do to get there. That will require greater involvement from the TC, but it appears we have already reached the point where the TC itself does not scale. That was evident from the Zaqar's second graduation review. One year after its incubation, the TC was still debating whether an SQS-like cloud messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint: none of them[4]), and in the end deferred for another six months to figure it out. It's clear that TC members don't have the time to dig deeply into all the issues that cross their desks. I already proposed a structure whereby subcommittees in each general subject area, comprising a representative from each of the relevant projects plus one TC member, would do the investigation and mentoring of new projects and report the results to the TC.[5] In this model the TC would be responsible for setting an overall vision for the project and ensuring that it is applied consistently. I would welcome other proposals that could help to expand and deepen support for new projects in a way that can scale through our next stage of growth. (I am also a strong supporter of having formal liaison programs to boost the impact of horizontal, cross-project functions without stretching them to breaking point.[1]) As we're figuring out structural changes I think we need to be careful to decouple short-term technical issues, like how to scale the gate to a larger number of projects that don't all have mutual dependencies, from longer-term structural issues. We also need to be very aware of how changes we make might be perceived by external parties not sharing the same context, including the Foundation Board and especially the DefCore subcommittee. Finally, we need to remember that our users see the cloud from many different perspectives and that no single perspective can capture what is important to our community.[5] Answers to the TC Election questions are below. I'm happy to answer any other questions folks have too, in an open forum of course. cheers, Zane. [1]
Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
On Tuesday, October 7, 2014, Adam Young ayo...@redhat.com wrote: Horizon has a config options which says which version of the Keystone API it should work against: V2 or V3. I am not certain that there is still any reason for Horizon to go against V2. However, If we defer the decision to Keystone, we come up against the problem of discovery. On the surface it is easy, as the Keystone client supports version discovery. The problem is that discovery must be run for each new client creation, and Horizon uses a new client per request. That would mean that every request to Horizon that talks to Keystone would generate at least one additional request. The response is cacheable. Is this significant? It gets a little worse when you start thinking about all of the other services out there. If each new request that has to talk to multiple services needs to run discovery, you can image that soon the majority of network chatter would be discovery based. It seems to me that Horizon should somehow cache this data, and share it among clients. Note that I am not talking about user specific data like the endpoints from the service catalog for a specific project. But the overall service catalog, as well as the supported versions of the API, should be cacheable. We can use the standard HTTP cache management API on the Keystone side to specify how long Horizon can trust the data to be current. I think this actually goes for the rest of the endpoints as well: we want to get to a much smaller service catalog, and we can do that by making the catalog holds on IDs. The constraints spec for endpoint binding will be endpoint only anyway, and so having the rest of the endpoint data cached will be valuable there as well. ___ 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] [I18N] compiling translation message catalogs
I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE packaging: the Horizon team would love to have your opinion on this (it came up during our weekly meeting). The current consensus is leaning toward removing the mo files for Juno RC2 (in a couple of days) rather than wait until Kilo, as this has been a pain point for (some/all?) distros for a while. Thank you, Julie On 01/10/14 17:04, Akihiro Motoki wrote: Hi, To display localized strings, we need to compile translated message catalogs (PO files) into compiled one (MO files). I would like to discuss and get a consensus who and when generate compiled message catalogs. Inputs from packagers are really appreciated. [The current status] * Horizon contains compile message catalogs in the git repo. (It is just a history and there seems no strong reason to have compiled one in the repo. There is a bug report on it.) * Other all projects do not contain compiled message catalogs and have only PO files. [Possible choices] I think there are several options. (there may be other options) (a) OpenStack does not distribute compiled message catalogs, and only provides a command (setup.py integration) to compile message catalogs. Deployers or distributors need to compile message catalogs. (b) Similar to (a), but compile message catalogs as a part of pip install. (c) OpenStack distributes compiled message catalogs as a part of the release. (c1) the git repo maintains compiled message catalogs. (c2) only tarball contains compiled message catalogs Note that the current Horizon is (c1) and others are (a). [Pros/Cons] (a) It is a simplest way as OpenStack upstream. Packagers need to compile message catalogs and customize there scripts. Deployers who install openstack from the source need to compile them too. (b) It might be a simple approach from users perspective. However to compile message catalogs during installation, we need to install required modules (like babel or django) before running installation (or require them as the first citizen in setup.py require). I don't think it is much simpler compared to option (a). (c1) Compiled message catalogs are a kind of binary files and they can be generated from PO files. There is no need to manage two same data. (c2) OpenStack is downloaded in several ways (release tarballs is not the only option), so I don't see much merits that the only tarball contains compiled message catalogs. A merit is that compiled message catalogs are available and there is no additional step users need to do. My preference is (a), but would like to know broader opinions especially from packagers. Thanks, Akihiro ___ 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] TC candidacy
confirmed On 07/10/14 12:47 PM, Zane Bitter wrote: Greetings OpenStackers, I would like to announce my candidacy for the OpenStack Technical Committee. I have worked closely with the TC since around the time that Heat was incubated, two years ago. I have been a regular participant in TC meetings throughout the Juno cycle as the Heat PTL, so I am familiar with the current structures and procedures, their back-story, and the issues that are before the committee. I think I can best contribute by digging deep into issues, rooting out the points of contention or misunderstanding and building consensus from there. If you follow openstack-dev closely you'll probably have seen me doing that quite a bit already. I don't claim to have all the answers, but I'm pretty good at asking questions. The OpenStack project has been incredibly successful in building a strong community where people want to collaborate on solving problems for our common users.[1] We are at a point where we need to readjust the structure of the project to better respond to the next phase of that success. This is not the first time we have reached such a point; nor will it be the last. There is no final form of the OpenStack project; we must approach it as we would any engineering problem (_not_, I hasten to add, a technical problem): by considering our goals and opportunities, making incremental changes, evaluating their effects (both intended and unintended), and repeating. I believe we need to work to reduce entropy in the OpenStack system - encouraging shared components and implementations over repeatedly reinventing the wheel - without crushing innovation. Those two goals are in tension (note that the wheel has been repeatedly reinvented throughout history, often to great effect), but they are the ones I will be trying to balance. And we must, of course, do this while giving operators and end-users confidence in their investments in the OpenStack ecosystem. I think making it easier for projects to join the OpenStack community would be a good thing, provided that still entails a commitment to doing things the OpenStack way backed up by meaningful oversight by the TC. I'm comfortable for now with leaving a high bar for graduation in place, though it needs to move around less. While I am in favour of more projects in principle, I'll be scrutinising specific projects carefully to make sure that they've either been able to apply the feedback part of the engineering process I described above with real users, or alternatively have solved the simplest possible version of their design problem with a view to maximising their flexibility to respond when they do get that feedback.[2] What we're really missing are stepping stones from the lower incubation bar to the high graduation bar. We need to do more to help projects understand how they can fit in to the bigger picture and what they need to do to get there. That will require greater involvement from the TC, but it appears we have already reached the point where the TC itself does not scale. That was evident from the Zaqar's second graduation review. One year after its incubation, the TC was still debating whether an SQS-like cloud messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint: none of them[4]), and in the end deferred for another six months to figure it out. It's clear that TC members don't have the time to dig deeply into all the issues that cross their desks. I already proposed a structure whereby subcommittees in each general subject area, comprising a representative from each of the relevant projects plus one TC member, would do the investigation and mentoring of new projects and report the results to the TC.[5] In this model the TC would be responsible for setting an overall vision for the project and ensuring that it is applied consistently. I would welcome other proposals that could help to expand and deepen support for new projects in a way that can scale through our next stage of growth. (I am also a strong supporter of having formal liaison programs to boost the impact of horizontal, cross-project functions without stretching them to breaking point.[1]) As we're figuring out structural changes I think we need to be careful to decouple short-term technical issues, like how to scale the gate to a larger number of projects that don't all have mutual dependencies, from longer-term structural issues. We also need to be very aware of how changes we make might be perceived by external parties not sharing the same context, including the Foundation Board and especially the DefCore subcommittee. Finally, we need to remember that our users see the cloud from many different perspectives and that no single perspective can capture what is important to our community.[5] Answers to the TC Election questions are below. I'm happy to answer any other questions folks have too, in an open forum
Re: [openstack-dev] Suggestions for students final year project
On 10/06/2014 05:28 PM, Anita Kuno wrote: 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. Good points: 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. I can verify how hard to cut off a chunk for a new developer: I had an intern I was working with this summer. Most of the time was spent on learning the development process. It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. That limits the number of projects available. Typically, and internship or a senior project like this is the correct place for a proof of concept or side project. The project can be done with a focus more on functionality and less on stability. We should come up with a published list of intern and senior projects proposals 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 ___ 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 Chris Jones's message of 2014-10-07 04:35:33 -0700: Hi On 6 Oct 2014, at 17:41, Clint Byrum cl...@fewbar.com wrote: We have to be _extremely_ careful in how we manage this. I actually think it has potential to really blow up in our faces. Yes, anything we do here has the potential to be extremely ruinous for operators, but the reality is that any existing TripleO deployment is at pretty severe risk of blowing up because of UIDs/GIDs changing when they update. 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. IMO the only desirable option *has* to be that we statically define UIDs and GIDs in the elements, because: 1: Requires no data fragments to be kept safe and fed to subsequent build processes 2: Doesn't do anything dynamic on first boot that could take hours/days 3: Can be thoroughly audited at build time to ensure correctness As you rightly point out though, any existing deployments will definitely be disrupted by this, but as I said above, all we'd be doing there is moving the needle from possible/probable to definite. Since the only leftovers we have from their previous image builds, are the images themselves, we could add the ability for a DIB run to extract IDs from a previous image, but this couldn't be required as a default build option, so we'd still risk existing deployments if they don't notice this feature. We could create a script that would spider an existing cloud and extract its ID mappings, to produce a fragment to feed into future builds, but again we're relying on operators to know that they need to do this. Wel... they'd know they need to do _something_ because their UIDs and GIDs are all horked up (technical term). Instead, I agree with Greg's view that this is our fault and we should fix it. We didn't think of this sooner, and as a result, our users are at risk. If we don't entirely fix this ourselves, we will be both expecting them to become aware of this issue and expecting them to do additional work to mitigate it. To that end, I think we should audit all of our elements for use of /mnt/state/ and use the specific knowledge we have of the software they relate to, to build one-time ID migration scripts, which would: 1: Execute before any related services start 2: Compare the now-static ID mappings against known files in /mnt/state 3: chown/chgrp any files/directories that need migrating 4: store a flag file in /mnt/state indicating that this process doesn't need to run again It does mean they have a potentially painfully long update process once, but the result will be a completely stable, static arrangement that will not require them to preserve precious build fragments for the rest of time. Nor does it require some odd run-time remapping, or any additional mechanisms to centralise user management (e.g. LDAP. Please, no LDAP!) I think that tying ourselves and our operators into knots because we're afraid of the hit of one-time data migration, is crazy. AFAICS, the only risk left at that point, is elements that other people are maintaining. If we consider that to be a sufficient risk, we can still build the mechanism for injecting ID values from a previous build (essentially just seeding the static values that we'd be setting anyway) and apologise to the users who need that, or who don't discover its existence and break their clouds. I'm not afraid of running migrations once. I want to make sure we never _plan_ to run migrations as part of regular operation. I agree with most of what you've written, but first I'd start with this: * Create an element which exports /etc/passwd and /etc/group from build process. * Create an element which imports /etc/passwd and /etc/group from local disk into image. This will have an element-provides of uid-gid-map * Create a separate element called 'static-users' which also provides uid-gid-map. Contains a map of uids and gids, and creates users early on with static UIDs/GIDs only. Disables usual commands used to add users and groups (error message should explain well enough that user can add their own element that provides uid-gid-map or switch to importing/exporting). * Make use-ephemeral depend on uid-gid-map. * Make tripleo-ci build with static-users, and recommend it in TripleO documentation. Once that is done, we will be producing builds with static users. If you want to create a user for base TripleO, you'll need to do it by hand in the static-users element. If you are downstream and want to do things differently that should be easy, just provide your own uid-gid-map element. As for migrations, that is fairly simple and can be done generically, I've already written a script that does it fairly reliably. The only worry is of course
Re: [openstack-dev] [nova] Resource tracker
On Oct 7, 2014, at 6:21 AM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote: 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 is just an example of problems with the way Nova virt drivers /currently/ report usage to the schedular. It is easily within the realm of possibility for the virt drivers to be changed so that they report stats which take into account things like ballooning and thin provisioning so that we don't oversubscribe. Ignoring the hypervisor stats entirely and re-doing the calculations in the resource tracker code is just a crude workaround really. It is just swapping one set of problems for a new set of problems. +1 lets make the hypervisors report detailed enough information that we can do it without having to recalculate. Vish 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. I'm against the idea of adding config options to switch between multiple codepaths because it is just punting the problem to the admins who are in an even worse position to decide what is best. It is saying would you rather your cloud have bug A or have bug B. We should be fixing the data the hypervisors report so that the resource tracker doesn't have to ignore them, and give the admins something which just works and avoid having to choose between 2 differently broken options. 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 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] Suggestions for students final year project
On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: 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. Good points: 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. Thanks for understanding, Adam. I can verify how hard to cut off a chunk for a new developer: I had an intern I was working with this summer. Most of the time was spent on learning the development process. Exactly! I think this is a very salient point which is missed both by people in Patricia's situation as well as the ones who send them here. It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Typically, and internship or a senior project like this is the correct place for a proof of concept or side project. Well I guess I would like to change things a bit and interact more closely with institutions so they are encouraging students to mix it up with the rest of us (reviewing for marks, that appeals to me) rather than working on their own on the side. They get what the prof wanted but they don't get as much as they could get for their time in terms of what would be useful after they get that rolled up piece of paper secured with a ribbon. Also there are hiring managers afoot in them thar hills masquerading as devs, who knows what might happen if you actually work with them for 3 - 6 weeks what fate might bestow on you. The project can be done with a focus more on functionality and less on stability. We should come up with a published list of intern and senior projects proposals I agree that is would be helpful, not only to students, but also to OpenStack to have a published list of endpoints (whatever they may be) that allows newcomers to be productive while getting what they need to show off to evaluators while also growing skills that will be useful to them long term. Having them learn how to do work that benefits Openstack (how about reviews?) wouldn't hurt us either. Thanks Adam, Anita. 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:
Re: [openstack-dev] Suggestions for students final year project
On Oct 7, 2014, at 10:38 AM, Adam Young ayo...@redhat.com wrote: We should come up with a published list of intern and senior projects proposals I know there is a low-hanging-fruit tag in the bug tracker, and this summer when we had two interns on our team working on Openstack we had them both “onboard” to the development process by having them find and resolve low-hanging-fruit tagged bugs in IPA and Ironic. I’d strongly suggest this list start with us being more vigilant about tagging bugs as low-hanging-fruit and then having those act as a gateway into the community. At Open Source Bridge this year, in a session about getting newcomers interested in open source, easy/l-h-f bugs were indicated as a strongly preferred way to get someone involved. Even to the level of suggesting a more senior developer could make the bug report better, with more breadcrumbs for a new person, to make it even easier to get started. Just a thought :). Thanks, Jay Faulkner 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] [nova] Resource tracker
On Tue, Oct 7, 2014 at 10:56 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Oct 7, 2014, at 6:21 AM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote: 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 is just an example of problems with the way Nova virt drivers /currently/ report usage to the schedular. It is easily within the realm of possibility for the virt drivers to be changed so that they report stats which take into account things like ballooning and thin provisioning so that we don't oversubscribe. Ignoring the hypervisor stats entirely and re-doing the calculations in the resource tracker code is just a crude workaround really. It is just swapping one set of problems for a new set of problems. I agree, lets make reported hypervisor stats actually useful for scheduling. This would mean we can have fewer config options (currently the operator has to set aside resources for the underlying OS via a config option). +1 lets make the hypervisors report detailed enough information that we can do it without having to recalculate. Do we have any idea of how expensive recalculating this information is? Vish 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. I'm against the idea of adding config options to switch between multiple codepaths because it is just punting the problem to the admins who are in an even worse position to decide what is best. It is saying would you rather your cloud have bug A or have bug B. We should be fixing the data the hypervisors report so that the resource tracker doesn't have to ignore them, and give the admins something which just works and avoid having to choose between 2 differently broken options. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev 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 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote: On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: On 10/06/2014 04:11 PM, Adam Young wrote: 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. I think writing a client / gui for openstack is one of the best single projects you can do to get a good overview of the whole stack. 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. snip It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. If you're doing a final year project and your highest goal isn't 'to get a good mark', then you're doing yourself a serious disservice. You can have all sorts of secondary goals, but by the point in your academic career where you're doing your final year project, your main goal is to prove you're learnt and can apply all of the skills that your course has covered. This actually involves a very different process to getting something done in the 'real world'. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Extremely difficult to get a decent academic project and therefore a good mark out of an existing project that has had any substantial amount of work done on it. Not impossible, but flicking through a pile of old final year projects that got good marks shows that stand-alone start-to-finish projects tend to get better marks. (I've looked into this quite a bit) -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC candidacy
I am Dean Troyer here to nominate myself as a candidate for the upcoming Technical Committee election. I have been involved with OpenStack for a long time, working on the implementation at NASA of what became Nova. Since then I have been heavily involved in a number of projects: I was an early contributor to DevStack and served as its PTL during its short tenure as a stand-alone program, and started Grenade to use DevStack as the basis for upgrade testing. I also started the OpenStackClient project to address the disparity in user interface experience in our CLI tools and have been working down the client stack to improve the application developer experience using the client libraries. I currently work for Nebula Inc. from my home in the hotbed of overachiever baseball, Kansas City MO. Recently some ideas I wrote down regarding the technical relationship of OpenStack projects escaped into the wild and became part of the current re-thinking of what OpenStack should look like. I think these ideas are a result from a practical approach to building useful systems and identifying the natural characteristics of both the projects and the people driving them. Technical relationships might not define organizational relationships, but they often look similar in the end. The major changes being discussed are required as a result of the tremendous growth of OpenStack and the changes in incentives for contribution. This growth also feeds a desire to be all things to all participants that simply is not possible at this scale. We can not rewind the clock to the simpler times of 5 projects, but we can recover some of the characteristics of those days by growing through division into a larger number of smaller tents. I'll be happy to answer specific questions beyond the ones below… Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? I think the rapid growth in the number of incubated/integrated projects has diluted the TC focus and attention and it has become clear that ignoring the natural strata of OpenStack projects is not working. Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? I think this and the previous question are intertwined at this point and it is time to do a sanity check on where we are and where we want to go. This conversation has started and there is no clear answer yet. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? I think at a high level this is one of the motivations to re-evaluate our existing structure. We are a corporate-driven project and in spite of individual efforts to remain independent the corporate influence is being felt in ways that the individuals may have not anticipated, ie, being 'Integrated' is the most valuable attribute for a project, and is the indicator for investment for many corporate managers. At an individual level I see people who want to make a better cloud and make the tools and components to get us there. We have some procedural things to smooth out (CLA, etc) and some significant scaling issues to address (review backlogs) in order to retain and utilize the energy being brought to OpenStack by new contributors. Topic: Rate of Growth There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate? As I wrote above, we have lost focus as we have attempted to widen the scope of integrated projects. Rather than do a smaller number of things very well the pressure is to do a lot of things. Topic: New Contributor Experience How would you characterize the experience new contributors have currently? The mechanics of contributing (CLA, accounts, etc) could be much better. I am not convinced that the CLA is providing value. The percentage of initial contributions that I see that are more than trivial spelling fixes or similar is low, as they need to focus on the process rather than the content just to get going. Topic: Communication How would you describe our current state of communication in the OpenStack community? There are enough different communication channels available that it is hard for anyone to monitor them all and still have time to write. I do think in general we have done a good job of herding conversations toward the mailing lists and logged IRC channels. Twitter and personal blogs are other common avenues and may or may not be easy to discover if one doesn't already know about them. Topic: Relationship with the Foundation Board The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions? I have mostly seen the interaction around the DefCore work and have found it interesting that neither side seems to want to say “This Is OpenStack” for fear of stepping on toes. dt -- Dean Troyer dtro...@gmail.com
Re: [openstack-dev] TC candidacy
confirmed On 07/10/14 02:26 PM, Dean Troyer wrote: I am Dean Troyer here to nominate myself as a candidate for the upcoming Technical Committee election. I have been involved with OpenStack for a long time, working on the implementation at NASA of what became Nova. Since then I have been heavily involved in a number of projects: I was an early contributor to DevStack and served as its PTL during its short tenure as a stand-alone program, and started Grenade to use DevStack as the basis for upgrade testing. I also started the OpenStackClient project to address the disparity in user interface experience in our CLI tools and have been working down the client stack to improve the application developer experience using the client libraries. I currently work for Nebula Inc. from my home in the hotbed of overachiever baseball, Kansas City MO. Recently some ideas I wrote down regarding the technical relationship of OpenStack projects escaped into the wild and became part of the current re-thinking of what OpenStack should look like. I think these ideas are a result from a practical approach to building useful systems and identifying the natural characteristics of both the projects and the people driving them. Technical relationships might not define organizational relationships, but they often look similar in the end. The major changes being discussed are required as a result of the tremendous growth of OpenStack and the changes in incentives for contribution. This growth also feeds a desire to be all things to all participants that simply is not possible at this scale. We can not rewind the clock to the simpler times of 5 projects, but we can recover some of the characteristics of those days by growing through division into a larger number of smaller tents. I'll be happy to answer specific questions beyond the ones below… Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? I think the rapid growth in the number of incubated/integrated projects has diluted the TC focus and attention and it has become clear that ignoring the natural strata of OpenStack projects is not working. Topic: Technical Committee Mission How do you feel the technical committee is doing in meeting the technical committee mission? I think this and the previous question are intertwined at this point and it is time to do a sanity check on where we are and where we want to go. This conversation has started and there is no clear answer yet. Topic: Contributor Motivation How would you characterize the various facets of contributor motivation? I think at a high level this is one of the motivations to re-evaluate our existing structure. We are a corporate-driven project and in spite of individual efforts to remain independent the corporate influence is being felt in ways that the individuals may have not anticipated, ie, being 'Integrated' is the most valuable attribute for a project, and is the indicator for investment for many corporate managers. At an individual level I see people who want to make a better cloud and make the tools and components to get us there. We have some procedural things to smooth out (CLA, etc) and some significant scaling issues to address (review backlogs) in order to retain and utilize the energy being brought to OpenStack by new contributors. Topic: Rate of Growth There is no argument the OpenStack technical community has a substantial rate of growth. What are some of the consequences of this rate? As I wrote above, we have lost focus as we have attempted to widen the scope of integrated projects. Rather than do a smaller number of things very well the pressure is to do a lot of things. Topic: New Contributor Experience How would you characterize the experience new contributors have currently? The mechanics of contributing (CLA, accounts, etc) could be much better. I am not convinced that the CLA is providing value. The percentage of initial contributions that I see that are more than trivial spelling fixes or similar is low, as they need to focus on the process rather than the content just to get going. Topic: Communication How would you describe our current state of communication in the OpenStack community? There are enough different communication channels available that it is hard for anyone to monitor them all and still have time to write. I do think in general we have done a good job of herding conversations toward the mailing lists and logged IRC channels. Twitter and personal blogs are other common avenues and may or may not be easy to discover if one doesn't already know about them. Topic: Relationship with the Foundation Board The technical committee interacts with the foundation board on several different fronts. How would you describe these interactions? I have mostly seen the interaction around the DefCore work and have found it interesting that
Re: [openstack-dev] Suggestions for students final year project
Is the OP looking to help patch bugs with an individual program or to use Openstack to deploy an interesting use case? The latter is how I interpreted the question. *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 Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote: On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: On 10/06/2014 04:11 PM, Adam Young wrote: 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. I think writing a client / gui for openstack is one of the best single projects you can do to get a good overview of the whole stack. 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. snip It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. If you're doing a final year project and your highest goal isn't 'to get a good mark', then you're doing yourself a serious disservice. You can have all sorts of secondary goals, but by the point in your academic career where you're doing your final year project, your main goal is to prove you're learnt and can apply all of the skills that your course has covered. This actually involves a very different process to getting something done in the 'real world'. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Extremely difficult to get a decent academic project and therefore a good mark out of an existing project that has had any substantial amount of work done on it. Not impossible, but flicking through a pile of old final year projects that got good marks shows that stand-alone start-to-finish projects tend to get better marks. (I've looked into this quite a bit) -- 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] [oslo] Meeting time
Hi all, Last Friday we decided to find a better time for the weekly team meeting. Keeping in mind that DST ends soon (October the 26th in Europe, November the 2nd in the US), I think, we can choose from: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 (assuming the information about meeting rooms availability provided here [0] is correct) Basically, anything earlier than 1600 UTC will be too early for those who live in CA after November the 2nd. And 1700+ UTC is beer o'clock here in Europe :) Alternatively, we could ask Infra to add the meeting bot directly to #openstack-oslo channel and have the weekly meeting there on any day we like around 1600 UTC (#openstack-oslo is not really crowded, so it shouldn't be a problem to use it for a meeting once a week). Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?
Hi, There are mainly two things you need to know when proposing a new Neutron Plugin (or even any Openstack feature): - The process [0]; - The tools [1]. Although the above documents cover those two points pretty well, I can give you a high level overview of what the process looks like. I'll not cover the how to implement a plugin part since it looks like you are already past that :) In order to add a new plugin/feature to the neutron repo, you first need to propose it through our *specification process*. The first step is to file a blueprint on launchpad [2] (register a blueprint), in which you very briefly explain what you are trying to attempt. You can find many examples on how to write a blueprint in [2], but it'll more or less look like this: *name: ferryboat-l2-plugin**title: L2 Neutron Plugin for supporting Ferryboat framework* *Summary:* *This proposal tracks the implementation of a new Neutron core plugin which allows the user **to implement L2 networks on the Ferryboat technology. In its first release, the plugin will support:* *- Port, Subnet, Network APIs;* *- Router APIs;**- Floating IPs;* *Security group support is planned for further iterations.* Once you have filed the blueprint, you can publish your spec[3](look at Spec + Blueprints lifecycle section) in the spec repo[4]. To do that, follow the Gerrit Workflow ([1] for details). In a nutshell, you need to: - Clone the spec repository locally, - Write a specification following the template, it should be targeted to Kilo (specs/kilo) - Run git review so that it can be reviewed by the core dev team. Once you do that, you spec will be published for review in the Openstack's review board [5], where it'll have to wait for some core reviewer's attention in order to get approved. Now to the actual patch: When the specification gets approved (or even in parallel actually), you can publish you Ferryboat plugin code for review just like you did for the spec. GerritWorkflow[1] will provide you a very clear understanding on how to configure/use git in order to be able to do that. So, again, you'll have to clone the Neutron's repository, add your code in a local branch properly named, and then run git review so that it gets published in the review board. In order to get approved and finally merged in the main Neutron repo, your plugin needs to pass at least the following criteria: - Pass all the unit tests; - Its own unit tests have to be implemented! With as much code coverage as possible; - The Spec discussed above have to be approved and properly targeted; - A *Third party CI system [5] *needs to be in place and positively voting your patch; - At least 2 core developers need to approve the patch based on its compliance in terms of functionalities and code quality. For those who implement a Neutron plugin for the first time, the Third Party Ci system is usually the moment in which things get very hard! The documentation pointed in [5][6], plus participating the weakly CI meetings, should be enough for you to understand what needs to be done. Very rapidly, Neutron needs to make sure that your plugin actually works, and you want to make sure that no changes are trying to break your plugin! To reach the goal, you'll need to setup a continuous integration system at home which votes a rightful amount of patches in review in order to validate that your implementation is not broken. Without a CI in place you plugin won't be approved, and removed if already in tree. The above should cover roughly 60% of the whole process, there are other small details like the commit format, unit testing, and other things that would be useless to overload here. More than that, I suggest you to go on the IRC channels and look for help there. My IRC alias is ivar-lazzaro, feel free to contact me :) Last but not least, the first push in Openstack (especially if it's something so big as a vendor plugin) is always tough! You'll go through a TON of review rounds and nasty issues. But don't be discouraged! It gets way better once you grasp the whole process :) Cheers, Ivar. [0] https://wiki.openstack.org/wiki/NeutronDevelopment [1] https://wiki.openstack.org/wiki/Gerrit_Workflow [2] https://launchpad.net/neutron [3] https://wiki.openstack.org/wiki/Neutron/BlueprintTemplate [4] https://github.com/openstack/neutron-specs [5] https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z [4] https://github.com/openstack/neutron https://github.com/openstack/neutron-specs [5] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting [6] http://ci.openstack.org/third_party.html [7] https://wiki.openstack.org/wiki/IRC On Sun, Oct 5, 2014 at 9:51 PM, thanh le giang legiangth...@gmail.com wrote: Hi all I want to add a plugin to the Public Neutron Repository. Although I have read the gerrit workflow and Neutron Development page ( https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly how we can add our plugin to
Re: [openstack-dev] [oslo] Meeting time
On Oct 7, 2014, at 3:01 PM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi all, Last Friday we decided to find a better time for the weekly team meeting. Keeping in mind that DST ends soon (October the 26th in Europe, November the 2nd in the US), I think, we can choose from: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 (assuming the information about meeting rooms availability provided here [0] is correct) Thanks for putting this list together, Roman. Basically, anything earlier than 1600 UTC will be too early for those who live in CA after November the 2nd. And 1700+ UTC is beer o'clock here in Europe :) Right, I think we were trying to move it off of Friday evening especially. :-) Alternatively, we could ask Infra to add the meeting bot directly to #openstack-oslo channel and have the weekly meeting there on any day we like around 1600 UTC (#openstack-oslo is not really crowded, so it shouldn't be a problem to use it for a meeting once a week). I remember talking about that at some point, but I don’t remember why we decided against it. Since we have several options for earlier in the week using the existing meeting rooms I think it’s safe to pick one of those. I have a slight preference for the Monday time slot, but all of them work for me. Does anyone else have a preference or a hard conflict with any of these times? Doug Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 06:51, thanh le giang wrote: Hi all I want to add a plugin to the Public Neutron Repository. Although I have read the gerrit workflow and Neutron Development page (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly how we can add our plugin to neutron repository. Could you please share me the process? Note that there are discussions to move all (or most) plugins outside the neutron tree (can't find the link atm, but it's mentioned in [1]). So in the end, your plugin may end up in a separate repository. [1]: https://etherpad.openstack.org/p/kilo-neutron-summit-topics /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEaBAEBCgAGBQJUNDzwAAoJEC5aWaUY1u57O08H8Pwm93FbLr7SR9LUiVg114eJ 9jKsuhOBartQMidKHXMfCTxC6lYtqFkaZdjnHuZ6ADFAQsDEzucHxHiJZx0SmiIs uD0NJeqLrS3UR0RJZMya5InfF1wso7B3CAXuGejAuQB0D08K7qR3nSRNGqcUn3k5 RVn6JNJk5DicuXrtrOOzvlUuPNeHx9b1/YfKhiC2J1Bl1WttOXzedZMXcRhlTBGN wtWfyl4OzKLHPTvumUkT6NMoHyg0zHs/FBM7caOOzo3xsA+pq89E6q+mY5un6zUy KKQI36zhIBvVUE0eIqekm9zqV+2AJxQnb+H6U4vRrAFMxjArvjUpgnLDN70T =ow33 -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] [TripleO] a need to assert user ownership in preserved state
On 8 October 2014 06:49, Clint Byrum cl...@fewbar.com wrote: Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700: AFAICS, the only risk left at that point, is elements that other people are maintaining. If we consider that to be a sufficient risk, we can still build the mechanism for injecting ID values from a previous build (essentially just seeding the static values that we'd be setting anyway) and apologise to the users who need that, or who don't discover its existence and break their clouds. I'm not afraid of running migrations once. I want to make sure we never _plan_ to run migrations as part of regular operation. If I can make a suggestion... Set a marker in the image indicating whether it has fixed uuids or not. Calculate that by comparing the contents of the computed passwd and groups db's to the static reference we've put together. Secondly, at the end of migrations.d write a marker file in /mnt/state that indicates we're fully synced. This flag should contain a uuid of the image and whether or not that image had fixed ids - or something like that. Then, the chown migration should activate if either a) the image doesn't have fully fixed uuids, or b) the marker file is missing, or c) the marker file has a different uuid and indicates the prior image didn't have fixed ids. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state
Hi On 7 Oct 2014, at 18:49, Clint Byrum cl...@fewbar.com wrote: * Create an element which imports /etc/passwd and /etc/group from local disk into image. This will have an element-provides of uid-gid-map I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds. I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each. The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen). * Create a separate element called 'static-users' which also provides uid-gid-map. Contains a map of uids and gids, and creates users early on I don't like the idea of keeping the map in a single element, for several reasons: 1: Harder to maintain across multiple element repos (e.g. we have two repos, do we have a static-users equivalent in each?) 2: Harder for downstreams to fork if they want to add an element we don't carry 3: Harder for devs to commit to, especially if it means they need to simultaneously land something in di-b and t-i-e. with static UIDs/GIDs only. Disables usual commands used to add users and groups (error message should explain well enough that user can add their Are you suggesting disabling those during build time only, or runtime too? I strongly dislike the latter and I'm not thrilled about the former. I'd rather we leave them as-is and audit the passwd/group files at the end of the build, vs what we were expecting from the elements. (we should also be aware that by enforcing this, we'll be increasing the number of elements we need to supply, because any dependencies that get pulled in during the build, which create users/groups, will now error/fail the build) As for migrations, that is fairly simple and can be done generically, I've already written a script that does it fairly reliably. The only Curious to see how that works - how can it know that /mnt/state/some/random/dir currently listed as ceilometer was actually owned by swift on the previous boot? Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Meeting time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/14 21:01, Roman Podoliaka wrote: Hi all, Last Friday we decided to find a better time for the weekly team meeting. Keeping in mind that DST ends soon (October the 26th in Europe, November the 2nd in the US), I think, we can choose from: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 Friday is beer day (especially here in Czech Republic!); Thursdays are harsh in terms of meetings in my calendar (though 1600 is bearable). I vote for Mondays. (assuming the information about meeting rooms availability provided here [0] is correct) Basically, anything earlier than 1600 UTC will be too early for those who live in CA after November the 2nd. And 1700+ UTC is beer o'clock here in Europe :) Alternatively, we could ask Infra to add the meeting bot directly to #openstack-oslo channel and have the weekly meeting there on any day we like around 1600 UTC (#openstack-oslo is not really crowded, so it shouldn't be a problem to use it for a meeting once a week). Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUND18AAoJEC5aWaUY1u57zFYIAI7xbaKnrfly6IUlJxG8Of8d n21PY05Jr/3vqq+sb+7E+a7Ty0xN1Rk2ehgUZsAMeQl59uH6JAqMoLavZjdfMkUO jxziRcR/si8wJ0LL1cXW0v5FDTYfYHoGkeJcmF1kbbOIVeezvhC2Ow7MkldIWZJk UmvUqGHshawERb0Hf1LIYnyU03mkg+F/lcdoT0xnLmI5UKEGVE9KjLsG8/mJ5aW0 uOiN0rgOR1+0sP6TWJArDD303feTcr+/ibeAgCmCEuLi0u/h54RnXRTdRScwPMdG ZMeDc/BcB3TY1wCnmMxvxLDDcIiZ6YIlpLPmmdDPXlxQf1OCgPJ24pBTSu9Hrww= =Ofcz -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] [Neutron][LBaaS][Octavia] Floating IP management
I'll add some more info to this as well: Neutron LBaaS creates the neutron port for the VIP in the plugin layer before drivers ever have any control. In the case of an async driver, it will then call the driver's create method, and then return to the user the vip info. This means the user will know the VIP before the driver even finishes creating the load balancer. So if Octavia is just going to create a floating IP and then associate that floating IP to the neutron port, there is the problem of the user not ever seeing the correct VIP (which would be the floating iP). So really, we need to have a very detailed discussion on what the options are for us to get this to work for those of us intending to use floating ips as VIPs while also working for those only requiring a neutron port. I'm pretty sure this will require changing the way V2 behaves, but there's more discussion points needed on that. Luckily, V2 is in a feature branch and not merged into Neutron master, so we can change it pretty easily. Phil and I will bring this up in the meeting tomorrow, which may lead to a meeting topic in the neutron lbaas meeting. Thanks, Brandon On Mon, 2014-10-06 at 17:40 +, Phillip Toohill wrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What's Up Doc? Oct 7 2014
Hi everyone, Be sure to read the discussions on openstack-dev about scaling documentation efforts across projects. Lots of great discussion on this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-October/047802.html We've got a new gerrit dashboard for doc reviews that shows works in progress as well as doc patches that have merged in the last week. Try it for yourself with http://is.gd/M4wghC This past week saw a lot of driver doc patches proposed and landing for storage and Hyper-V updates. We're happy to review those but I think we're carefully considering more pointers to outside documentation for driver configuration so that driver maintainers don't have to duplicate maintenance of docs. I'd love discussion on this point -- at the Ops meetup for example, they suggested just pointing to the external sites for those docs. Makes sense to me, but I want discussion. In addition, the install guide work is ongoing. You can see the test matrix here: https://wiki.openstack.org/wiki/JunoDocTesting and note that testing is not yet started on release candidates. Feel free to test and fill in the matrix as you go. For the OpenStack dashboard (horizon) on Ubuntu, we're awaiting updates for a python-xstatic package dependency. Also the networking guide has a small subteam working on it. The TOC for the networking guide is available at: https://wiki.openstack.org/wiki/NetworkingGuide/TOC So far we have three blog entries and some test results back from Phil Hopkins. We need more content for this guide so please do send it in with any format you have. The Foundation has offered web designers to revise our (aging) docs.openstack.org site design and I met with them and Tom Fifield last week to go over the requirements and scope of the project. Looking forward to a refresh for sure. For API documentation, I'm still working through a large change to remove the docs.openstack.org/api documents and point to the reference page at http://developer.openstack.org/api-ref.html. In this change I need to propose patches for these projects specs repo: nova (compute-api) v2, v2.1 swift (object-api) v1 glance (image-api) v1, v1.1, v2 keystone (identity-api) v2.0, v3 neutron (netconn-api) v1.0, v2.0 cinder (volume-api) v1.0, v2.0 Then I can delete the repos in the parentheses above. Some projects don't have this type of document in a separate service-api repo that I know of, which is just fine: trove ceilometer heat sahara ironic zaqar (marconi) barbican designate manila I hope this cleanup can move us forward in API documentation questions of what docs, where to source and publish, and for whom do we write them. My current thinking is that there should be specs written for and by contributor devs, and also reference docs written for app devs by contributor devs and api writers. This week I'm at the Grace Hopper conference with 7,999 other women in technology. Matt Kassawara has agreed to run the docs team meeting in #openstack-meeting tomorrow at 14:00 UTC (09:00 Central). Agenda is here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting Thanks, Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] How to write extension
Hello, Can You send me some examples or link to tutorial how to write extension to neutron. I'm using ML2 plugin in neutron and I want to add some new functionality and API methods to this neutron. So imho I should do it via extension but how exactly write it that it will work in existing ML2 plugin? --- Best regards Sławek Kapłoński sla...@kaplonski.pl signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Meeting time
On Oct 7, 2014, at 3:15 PM, Doug Hellmann d...@doughellmann.com wrote: I remember talking about that at some point, but I don’t remember why we decided against it. Since we have several options for earlier in the week using the existing meeting rooms I think it’s safe to pick one of those. I have a slight preference for the Monday time slot, but all of them work for me. Does anyone else have a preference or a hard conflict with any of these times? I’m fine with whatever. Doug Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?
If you are thinking about adding a new neutron core plugin, please consider whether you could accomplish what you need with an ML2 MechanismDriver instead. Its a lot less code to write, review, and maintain. -Bob On 10/6/14 12:51 AM, thanh le giang wrote: Hi all I want to add a plugin to the Public Neutron Repository. Although I have read the gerrit workflow and Neutron Development page (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly how we can add our plugin to neutron repository. Could you please share me the process? Thanks and best regards, -- L.G.Thanh Email:legiangt...@gmail.com mailto:legiangth...@gmail.com lgth...@fit.hcmus.edu.vn mailto:lgth...@fit.hcmus.edu.vn ___ 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 Chris Jones's message of 2014-10-07 12:23:20 -0700: Hi On 7 Oct 2014, at 18:49, Clint Byrum cl...@fewbar.com wrote: * Create an element which imports /etc/passwd and /etc/group from local disk into image. This will have an element-provides of uid-gid-map I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds. Disagree on the grounds that the point of this is to deal with people who already have images and want to update them. We're not trying to enable people to deploy radically different OS's or anything like that. I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each. The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen). That is a lot of complexity for the case that we don't want people to use (constantly carrying /etc/passwd and /etc/group forward). * Create a separate element called 'static-users' which also provides uid-gid-map. Contains a map of uids and gids, and creates users early on I don't like the idea of keeping the map in a single element, for several reasons: 1: Harder to maintain across multiple element repos (e.g. we have two repos, do we have a static-users equivalent in each?) 2: Harder for downstreams to fork if they want to add an element we don't carry 3: Harder for devs to commit to, especially if it means they need to simultaneously land something in di-b and t-i-e. I think that makes sense. The per-element expressions will still need to be coalesced into one place to check for conflicts. I suppose if we use add only tools that will work. with static UIDs/GIDs only. Disables usual commands used to add users and groups (error message should explain well enough that user can add their Are you suggesting disabling those during build time only, or runtime too? I strongly dislike the latter and I'm not thrilled about the former. I'd rather we leave them as-is and audit the passwd/group files at the end of the build, vs what we were expecting from the elements. (we should also be aware that by enforcing this, we'll be increasing the number of elements we need to supply, because any dependencies that get pulled in during the build, which create users/groups, will now error/fail the build) So I think we still do care about these. MySQL puts its files on /mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files on /mnt/state. If an element installs a package that needs a user, we have to treat that as our responsibility to handle, because we want to preserve /mnt/state. As for migrations, that is fairly simple and can be done generically, I've already written a script that does it fairly reliably. The only Curious to see how that works - how can it know that /mnt/state/some/random/dir currently listed as ceilometer was actually owned by swift on the previous boot? It also has to have access to the previous image's /etc/passwd and /etc/group. In the context I wrote it in, updating via ansible, I can cheat and copy that into /mnt/state before rebuilding the box. But we can do that in our elements too. :) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?
On Tue, Oct 7, 2014 at 2:20 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/10/14 06:51, thanh le giang wrote: Hi all I want to add a plugin to the Public Neutron Repository. Although I have read the gerrit workflow and Neutron Development page (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly how we can add our plugin to neutron repository. Could you please share me the process? Note that there are discussions to move all (or most) plugins outside the neutron tree (can't find the link atm, but it's mentioned in [1]). So in the end, your plugin may end up in a separate repository. [1]: https://etherpad.openstack.org/p/kilo-neutron-summit-topics Yes, this is very likely to happen in Kilo and it's one of the refactoring related items the team will focus on in Kilo. I hope next week to have this more documented on an etherpad for folks to consume prior to the Summit. Thanks, Kyle /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEaBAEBCgAGBQJUNDzwAAoJEC5aWaUY1u57O08H8Pwm93FbLr7SR9LUiVg114eJ 9jKsuhOBartQMidKHXMfCTxC6lYtqFkaZdjnHuZ6ADFAQsDEzucHxHiJZx0SmiIs uD0NJeqLrS3UR0RJZMya5InfF1wso7B3CAXuGejAuQB0D08K7qR3nSRNGqcUn3k5 RVn6JNJk5DicuXrtrOOzvlUuPNeHx9b1/YfKhiC2J1Bl1WttOXzedZMXcRhlTBGN wtWfyl4OzKLHPTvumUkT6NMoHyg0zHs/FBM7caOOzo3xsA+pq89E6q+mY5un6zUy KKQI36zhIBvVUE0eIqekm9zqV+2AJxQnb+H6U4vRrAFMxjArvjUpgnLDN70T =ow33 -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] [neutron] Creation of neutron-drivers team
Can you add a section to the wiki to document how a core can become a member of the drivers team? On Tue, Oct 7, 2014 at 7:55 AM, Kyle Mestery mest...@mestery.com wrote: As discussed in today's meeting [1], I've created a neutron-drivers team [2], which was modeled on the same way as the existing nova-drivers team. This team will be responsible for approving specs for Kilo. Please see the wiki page for the long story, but the short story is that as focused team driving spec approval and a consistent architectural approach for Neutron in Kilo will be good for the long-term health of the project. As with all things process related, we'll try this out in Kilo and adjust accordingly at the end. I wanted to keep the broader community aware of this new team. Thanks! Kyle [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-07-14.01.html [2] https://wiki.openstack.org/wiki/Neutron-drivers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra] Meeting Tuesday October 7th at 19:00 UTC
On Mon, Oct 6, 2014 at 4:06 PM, Elizabeth K. Joseph l...@princessleia.com wrote: The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday October 7th, at 19:00 UTC in #openstack-meeting Meeting minutes and log are now available: Minutes: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.txt Log: http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.log.html -- 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] [qa] In-tree functional test vision
On Tue, Oct 07, 2014 at 04:28:23PM +0100, Chris Dent wrote: On Mon, 25 Aug 2014, Joe Gordon wrote: On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent chd...@redhat.com wrote: For constraints: Will tempest be available as a stable library? Is using tempest (or other same library across all projects) a good or bad thing? Seems there's some disagreement on both of these. Yes, there is a separate thread on spinning out a tempest-lib (not sure on what final name will be yet) that functional tests can use. Although I think there is a lot to be done before needing the tempest-lib. What's the status of tempest-lib? Looking at the repo it appears that other things may be taking priority at the moment. Things were blocked briefly by global requirements freeze. I'll hopefully be cutting the first release this week, just waiting on one patch to go through. We already have most of the pieces in place already to start using it on ci jobs so it should just be a matter of getting: https://review.openstack.org/#/c/122478/ landed before you can import it anywhere. That being said it's still a lower priority dev item compared to some other tasks, mostly because we don't have too many interfaces in tempest which are considered stable enough to migrate yet. The long term scope of the library hasn't been clearly defined yest, so not entirely clear what things are worth migrating into the library at this point. Next up I expect to migrate the auth layer and the base rest client. This will allow projects to build service specific clients out of tree, which I've seen commonly done for projects prior to incubation. This won't include the service clients in tempest though, because we expect to make some changes to that interface soon. That being said I'm not sure how long the additional library migrations will take. As I said in notifications thread: With summit approaching and kilo open for business, now seems to be talking about what kinds of structure we want to apply to in-tree functional testing. There is nothing stopping you from doing this. Tempest-lib is not a requirement for doing this at all, and should really only be useful for some specific types of testing. It shouldn't be required for functional testing in general. Also, at this point tempest-lib only contains the CLI testing framework which is hardly useful for spinning up project specific functional testing. -Matt Treinish pgpHt8yHxOH3G.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC candidacy
Hello, everyone! I would like to run for re-election on the Technical Committee. I have been an elected member of the TC since it was created in the Fall of 2012 [1]. I have been contributing to OpenStack since late 2011 (commits [2] reviews [3]). My most substantial contributions have been to Nova, where I also served as the PTL for the Havana and Icehouse releases. For further details on my background, see openhub [4] or linkedin [5]. I have been a proactive member of the TC. I take my broad experience with the project and work to turn it into change that puts us in a better position for the future. Some specific examples of actions I’ve taken may help demonstrate this. Over the last cycle it became clear that the TC could do a better job at communicating what we’re up to to the broader community. I helped launch an ongoing effort to blog about TC activities. I wrote the first [9] and third [10] posts of this series. We now intend to rotate the authorship of these posts through a group of willing TC members. I’ve become deeply familiar with the history of Neutron vs. nova-network through my work with the Nova project. During my second term as the Nova PTL, we unfortunately reached a point where we had to unfreeze development on nova-network [11]. I wanted to find ways to help improve the current situation and help prevent it from happening again. I identified policy that could be added (must have explicit deprecation and migration plan in place before graduation) [12] for the future. To help with the current situation, I proposed that we kick off a round of project reviews where we review all existing projects against our incubation and graduation requirements [13]. This process resulted in a gap analysis and plans for filling those gaps for Neutron [14], Trove, Ceilometer, Horizon, Glance, and Heat. We are now much closer to being able to deprecate nova-network than we were 6 months ago thanks to some very hard work by the Neutron team. I think these reviews were very productive and I hope to help continue this process with the TC going forward. The TC has the critical role to evolve and scale our structure and processes to ensure the ongoing health of our development community. We’ve worked through important changes in every cycle so far. From recent discussions it is quite clear that it is time for another round of big changes to how we organize our teams and projects. The TC itself has even become a bottleneck in some cases. I see resolving these issues as a top priority for the TC over the next release cycle. There are far too many things wrapped up in the incubation and integration statuses. They communicate different things to different audiences. This overload has led to a lot of conflict. It’s a high priority for me to ensure that with whatever changes we make, we value an inclusive community that lets projects doing good work be a part of OpenStack. We need to rework the organization such that what we’re communicating is the most useful information for each audience. At the same time, we need allow this growth in such a way that it doesn’t provide unbearable strain on horizontal project resources like documentation, infrastructure, or release management. The incubated and integrated statuses are not doing the job, but I’m confident that we can work through our next evolution, and I would like to be a part of ensuring that happens. Thank you all for your consideration. It’s an honor and a pleasure to work with you. If there’s anything you would like to discuss, please feel free to reach out to me. Below you will find my answers to the provided questions [6]. *** Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? To recap, the mission statement is “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.” “ubiquitous” - I think the part we’re doing great here. OpenStack is growing like crazy and is being used all over the place. The list of supporting companies [7] is impressive. The number and diversity of our contributors is even more impressive. With that said, we shouldn’t get comfortable. There is a lot more to go. “public and private clouds” - I think we do a nice job working to support both of these use cases. “regardless of size”, “massively scalable” - This one probably depends on who you ask. :-) Our scalability depends on the project. In some areas we’re doing great. In all areas, we have more improvements to make. I think our biggest failure here has been how well we communicate what to expect to the rest of the community. Some people expect that they can take every component of the integrated release to large public cloud scale. That isn’t true and we’ve done a poor job of setting expectations here. This is something I’d like to improve on. “simple
Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?
2014-10-02 14:19 GMT+02:00 Duncan Thomas duncan.tho...@gmail.com: Hi, What is actually needed is those who rely on the stable branch(es) existence need to step forward and dedicate resources to it. Putting the work on people not interested is just the same as killing them off, except slower, messier and creating more anger and otehr community fallout along the way. I'm paid by one of those distros that are interested in stable branch maintenance but have no idea what needs to be done other than saying I'm interested in helping out. I've been proposing patches to backport every once in a while already and being frustrated that it takes weeks if not months for someone to review them and potentially merge. What are the queries that people are supposed to look at ? How can I help in pushing patches or look for gating failures *specific* to stable/ branches? Thanks, Dirk ___ 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
Hi On 7 Oct 2014, at 20:47, Clint Byrum cl...@fewbar.com wrote: I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds. Disagree on the grounds that the point of this is to deal with people who already have images and want to update them. We're not trying to enable people to deploy radically different OS's or anything like that. My point is that we don't know what else is changing under the hood. Switching OS is a bit extreme, but we don't know that they're not going to pull in an OS upgrade at the same time and have everything change substantially, or even just introduce one additional dependency which we would destroy the uid/gid for. I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each. The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen). That is a lot of complexity for the case that we don't want people to use (constantly carrying /etc/passwd and /etc/group forward). As tchaypo pointed out on IRC, if we do this static route, we are laying down a great big concrete slab of opinion in our images. I'm all for opinionated software, but we need to give people an out, which means we probably want to have a way for the suggested default UID/GIDs to be overridden, i.e. roughly what I described. We can just use that override to inject the pre-existing passwd/group values, if we so desire. I think that makes sense. The per-element expressions will still need to be coalesced into one place to check for conflicts. I suppose if we Definitely. If we use normal system tools to create the users/groups, the build will fail if there are conflicts. So I think we still do care about these. MySQL puts its files on /mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files on /mnt/state. If an element installs a package that needs a user, we have to treat that as our responsibility to handle, because we want to preserve /mnt/state. Agreed. I just wanted to put a note on the table that we will have to care about these things :) It also has to have access to the previous image's /etc/passwd and /etc/group. In the context I wrote it in, updating via ansible, I can *nods* Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Sahara] Juno RC2 available
Hello everyone, Due to various regressions and documentation issues in the published Sahara RC1, we generated a new Juno release candidate for Sahara: https://launchpad.net/sahara/juno/juno-rc2 Unless new release-critical issues are found that warrant a release candidate respin, this RC2 will be formally released as Sahara 2014.2 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/sahara/tree/proposed/juno If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/sahara/+filebug and tag it *juno-rc-potential* to bring it to the release crew's attention. 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] TC candidacy
I am announcing my candidacy for a position on the OpenStack Technical Committee. I am currently employed by HP to work upstream on OpenStack. I started contributing in 2012, not long after joining DreamHost. I am one of the founding members of the Ceilometer project, and a core reviewer for the requirements and unified command line interface projects. I am also part of the team working on the Python 3 transition, and have contributed to several of the infrastructure projects. Kilo will be my third term serving as PTL for the Oslo project, and I have served on the Technical Committee for the last year. In addition to my technical contributions, I helped to found and still help to organize the OpenStack meetup group in Atlanta, Georgia. I've included the answers to the formally posed election questions below, but please follow up here with any other questions you might have for me. The OpenStack community is the most exciting and welcoming group I have interacted with in more than 20 years of contributing to open source projects. I'm looking forward to continuing to being a part of the community and serving the project. Thank you, Doug Review history: https://review.openstack.org/#/q/reviewer:2472,n,z Commit history: https://review.openstack.org/#/q/owner:2472,n,z Stackalytics: http://stackalytics.com/?user_id=doug-hellmann Foundation: http://www.openstack.org/community/members/profile/359 OpenHUB: https://www.openhub.net/accounts/doughellmann Freenode: dhellmann Website: http://doughellmann.com * Topic: OpenStack Mission * * How do you feel the technical community is doing in meeting the * OpenStack Mission? I am amazed by what our community produces. We have some truly exceptional development teams building great software. We regularly add new components to the system, and our feature set is as diverse as the community. Our work is not perfect, but as we continue to refine it based on experience and input from users, we are continually improving the way we work and what we produce. However, there are recurring themes in the user feedback after every release: We need to make OpenStack easier to operate, easier to use, and easier to debug. We are starting to build cross-project teams to work more directly on some of these areas, and it's important that we give priority to that work and consider usability and scalability as features. * Topic: Technical Committee Mission * * How do you feel the technical committee is doing in meeting the * technical committee mission? We're fulfilling most of the mission, but we can do better. The Zaqar graduation discussion is a good example of an area where we need to rethink how we bring new project teams into OpenStack. There are several similar suggestions to drop our current incubation and integration process completely, and that is one option. Another is to set up the resources we would need to do an objective technical evaluation for projects. I favor a combination of those two ideas, evaluating projects on several criteria from the users' perspective, but deciding the official status of a team based on community considerations. We have also recognized that we need some way to handle cross-project initiatives such as improving our logging to make debugging easier, but we do not yet have a formal structure in place to accomplish those goals. The way we set up working groups for those sorts of jobs is going to depend on the outcome of the bigger governance discussion, but I think they should be organized by the TC. * Topic: Contributor Motivation * * How would you characterize the various facets of contributor * motivation? I don't know if we have numbers, but my impression is that most of our contributions come from people employed at least in part to work on OpenStack. Their commitment to the project as a whole, outside of their area of specialty, varies for a lot of reasons. We want everyone to have a strong commitment to the whole project, but that's not always realistic, because it's not always up to the individual to decide how much time or effort they can put into working on OpenStack, or into a given area. That's perfectly normal and OK. We can, and do, welcome contributions from all sorts of people for all sorts of reasons. * Topic: Rate of Growth * * There is no argument the OpenStack technical community has a * substantial rate of growth. What are some of the consequences of * this rate? Growing so quickly is forcing us to think about how we organize our selves and make changes explicitly, and more rapidly, rather than allowing for a slower evolution. We've had a lot of blog posts and mailing list threads talking about ways to handle the growth through governance model changes to the project. These are important decisions for us to make as a community, and we need to weigh both sides of each issue carefully. For example, we want to be more inclusive and bring more project teams into OpenStack, but doing that further strains our
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
Hi Julie, I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE packaging: the Horizon team would love to have your opinion on this (it came up during our weekly meeting). I was somehow not CC'ed although I'm the SUSE packager for OpenStack. In my opinion a) is the option we prefer, we're actually removing and ignoring the .mo files from git and (re-) build them as part of packaging. Using the git-maintained build results would be a distribution packaging policy violation for us. Whether it needs to be done before Juno or after: I personally don't care either way, there are much more serious issues in Juno than this.. Greetings, Dirk ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/10/14 22:25, Dirk Müller wrote: 2014-10-02 14:19 GMT+02:00 Duncan Thomas duncan.tho...@gmail.com: Hi, What is actually needed is those who rely on the stable branch(es) existence need to step forward and dedicate resources to it. Putting the work on people not interested is just the same as killing them off, except slower, messier and creating more anger and otehr community fallout along the way. I'm paid by one of those distros that are interested in stable branch maintenance but have no idea what needs to be done other than saying I'm interested in helping out. I've been proposing patches to backport every once in a while already and being frustrated that it takes weeks if not months for someone to review them and potentially merge. What are the queries that people are supposed to look at ? How can I help in pushing patches or look for gating failures *specific* to stable/ branches? First, check out [1]. Also please subscribe to openstack-stable-maint@ mailing list [2]. You can start helping the team by applying the rules from [1] to existing backport reviews. Once team members see your work for a while, you will be able to join the team and get +2 vote for stable branches. Welcome! [1]: https://wiki.openstack.org/wiki/StableBranch [2]: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUNE5dAAoJEC5aWaUY1u57cpoH/2Y8qTTRg1IBWBB7O+VnezWc LEHEi1ydXwpu75kPMI5YWlPx4YWSFKRD6DOd30bUgSsoW7rI/d1LtelfvE3ubdS3 8D6qt1Rvlw15xpX8GbVaABlezxeQufufCMp0wioV0OkrlryyF0dvE1iopwnIjnAi hD8rfbAO8LUW8ra0hkteRFac3oPVzGBGhWu67ijxvec3Oh7p7gV4AlMj2tm2n5JE fhzxPLnPTqVa8zqJYdZBIr7nHfZtvx9bxGMPAqJP40e15x/toaVJquBEM43HaVs+ 2YX5sGWrxmZaP6w8TJRcbBqny0hfK8n3IWgY6d8NVa4FqgwibdHY22hi7jnMuoU= =hLF9 -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] TC candidacy
confirmed On 07/10/14 04:21 PM, Russell Bryant wrote: Hello, everyone! I would like to run for re-election on the Technical Committee. I have been an elected member of the TC since it was created in the Fall of 2012 [1]. I have been contributing to OpenStack since late 2011 (commits [2] reviews [3]). My most substantial contributions have been to Nova, where I also served as the PTL for the Havana and Icehouse releases. For further details on my background, see openhub [4] or linkedin [5]. I have been a proactive member of the TC. I take my broad experience with the project and work to turn it into change that puts us in a better position for the future. Some specific examples of actions I’ve taken may help demonstrate this. Over the last cycle it became clear that the TC could do a better job at communicating what we’re up to to the broader community. I helped launch an ongoing effort to blog about TC activities. I wrote the first [9] and third [10] posts of this series. We now intend to rotate the authorship of these posts through a group of willing TC members. I’ve become deeply familiar with the history of Neutron vs. nova-network through my work with the Nova project. During my second term as the Nova PTL, we unfortunately reached a point where we had to unfreeze development on nova-network [11]. I wanted to find ways to help improve the current situation and help prevent it from happening again. I identified policy that could be added (must have explicit deprecation and migration plan in place before graduation) [12] for the future. To help with the current situation, I proposed that we kick off a round of project reviews where we review all existing projects against our incubation and graduation requirements [13]. This process resulted in a gap analysis and plans for filling those gaps for Neutron [14], Trove, Ceilometer, Horizon, Glance, and Heat. We are now much closer to being able to deprecate nova-network than we were 6 months ago thanks to some very hard work by the Neutron team. I think these reviews were very productive and I hope to help continue this process with the TC going forward. The TC has the critical role to evolve and scale our structure and processes to ensure the ongoing health of our development community. We’ve worked through important changes in every cycle so far. From recent discussions it is quite clear that it is time for another round of big changes to how we organize our teams and projects. The TC itself has even become a bottleneck in some cases. I see resolving these issues as a top priority for the TC over the next release cycle. There are far too many things wrapped up in the incubation and integration statuses. They communicate different things to different audiences. This overload has led to a lot of conflict. It’s a high priority for me to ensure that with whatever changes we make, we value an inclusive community that lets projects doing good work be a part of OpenStack. We need to rework the organization such that what we’re communicating is the most useful information for each audience. At the same time, we need allow this growth in such a way that it doesn’t provide unbearable strain on horizontal project resources like documentation, infrastructure, or release management. The incubated and integrated statuses are not doing the job, but I’m confident that we can work through our next evolution, and I would like to be a part of ensuring that happens. Thank you all for your consideration. It’s an honor and a pleasure to work with you. If there’s anything you would like to discuss, please feel free to reach out to me. Below you will find my answers to the provided questions [6]. *** Topic: OpenStack Mission How do you feel the technical community is doing in meeting the OpenStack Mission? To recap, the mission statement is “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.” “ubiquitous” - I think the part we’re doing great here. OpenStack is growing like crazy and is being used all over the place. The list of supporting companies [7] is impressive. The number and diversity of our contributors is even more impressive. With that said, we shouldn’t get comfortable. There is a lot more to go. “public and private clouds” - I think we do a nice job working to support both of these use cases. “regardless of size”, “massively scalable” - This one probably depends on who you ask. :-) Our scalability depends on the project. In some areas we’re doing great. In all areas, we have more improvements to make. I think our biggest failure here has been how well we communicate what to expect to the rest of the community. Some people expect that they can take every component of the integrated release to large
Re: [openstack-dev] TC candidacy
confirmed On 07/10/14 04:30 PM, Doug Hellmann wrote: I am announcing my candidacy for a position on the OpenStack Technical Committee. I am currently employed by HP to work upstream on OpenStack. I started contributing in 2012, not long after joining DreamHost. I am one of the founding members of the Ceilometer project, and a core reviewer for the requirements and unified command line interface projects. I am also part of the team working on the Python 3 transition, and have contributed to several of the infrastructure projects. Kilo will be my third term serving as PTL for the Oslo project, and I have served on the Technical Committee for the last year. In addition to my technical contributions, I helped to found and still help to organize the OpenStack meetup group in Atlanta, Georgia. I've included the answers to the formally posed election questions below, but please follow up here with any other questions you might have for me. The OpenStack community is the most exciting and welcoming group I have interacted with in more than 20 years of contributing to open source projects. I'm looking forward to continuing to being a part of the community and serving the project. Thank you, Doug Review history: https://review.openstack.org/#/q/reviewer:2472,n,z Commit history: https://review.openstack.org/#/q/owner:2472,n,z Stackalytics: http://stackalytics.com/?user_id=doug-hellmann Foundation: http://www.openstack.org/community/members/profile/359 OpenHUB: https://www.openhub.net/accounts/doughellmann Freenode: dhellmann Website: http://doughellmann.com * Topic: OpenStack Mission * * How do you feel the technical community is doing in meeting the * OpenStack Mission? I am amazed by what our community produces. We have some truly exceptional development teams building great software. We regularly add new components to the system, and our feature set is as diverse as the community. Our work is not perfect, but as we continue to refine it based on experience and input from users, we are continually improving the way we work and what we produce. However, there are recurring themes in the user feedback after every release: We need to make OpenStack easier to operate, easier to use, and easier to debug. We are starting to build cross-project teams to work more directly on some of these areas, and it's important that we give priority to that work and consider usability and scalability as features. * Topic: Technical Committee Mission * * How do you feel the technical committee is doing in meeting the * technical committee mission? We're fulfilling most of the mission, but we can do better. The Zaqar graduation discussion is a good example of an area where we need to rethink how we bring new project teams into OpenStack. There are several similar suggestions to drop our current incubation and integration process completely, and that is one option. Another is to set up the resources we would need to do an objective technical evaluation for projects. I favor a combination of those two ideas, evaluating projects on several criteria from the users' perspective, but deciding the official status of a team based on community considerations. We have also recognized that we need some way to handle cross-project initiatives such as improving our logging to make debugging easier, but we do not yet have a formal structure in place to accomplish those goals. The way we set up working groups for those sorts of jobs is going to depend on the outcome of the bigger governance discussion, but I think they should be organized by the TC. * Topic: Contributor Motivation * * How would you characterize the various facets of contributor * motivation? I don't know if we have numbers, but my impression is that most of our contributions come from people employed at least in part to work on OpenStack. Their commitment to the project as a whole, outside of their area of specialty, varies for a lot of reasons. We want everyone to have a strong commitment to the whole project, but that's not always realistic, because it's not always up to the individual to decide how much time or effort they can put into working on OpenStack, or into a given area. That's perfectly normal and OK. We can, and do, welcome contributions from all sorts of people for all sorts of reasons. * Topic: Rate of Growth * * There is no argument the OpenStack technical community has a * substantial rate of growth. What are some of the consequences of * this rate? Growing so quickly is forcing us to think about how we organize our selves and make changes explicitly, and more rapidly, rather than allowing for a slower evolution. We've had a lot of blog posts and mailing list threads talking about ways to handle the growth through governance model changes to the project. These are important decisions for us to make as a community, and we need to weigh both
Re: [openstack-dev] Suggestions for students final year project
Regarding to the Sahara, we could discuss it in the ML separately or you could join the #openstack-sahara channel at freenode. There is a big area of doing things inside and on top of Sahara. thanks. On Tue, Oct 7, 2014 at 11:41 AM, Adam Lawson alaw...@aqorn.com wrote: Is the OP looking to help patch bugs with an individual program or to use Openstack to deploy an interesting use case? The latter is how I interpreted the question. *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 Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote: On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: On 10/06/2014 04:11 PM, Adam Young wrote: 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. I think writing a client / gui for openstack is one of the best single projects you can do to get a good overview of the whole stack. 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. snip It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. If you're doing a final year project and your highest goal isn't 'to get a good mark', then you're doing yourself a serious disservice. You can have all sorts of secondary goals, but by the point in your academic career where you're doing your final year project, your main goal is to prove you're learnt and can apply all of the skills that your course has covered. This actually involves a very different process to getting something done in the 'real world'. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Extremely difficult to get a decent academic project and therefore a good mark out of an existing project that has had any substantial amount of work done on it. Not impossible, but flicking through a pile of old final year projects that got good marks shows that stand-alone start-to-finish projects tend to get better marks. (I've looked into this quite a bit) -- 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 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ETSI NFV gap analysis [NFV]
- Original Message - From: Alan Kavanagh alan.kavan...@ericsson.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org 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 Hi all, I've uploaded the document here: https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf Many items are tracked (and in fact linked inline in the document itself) in the list that we have already compiled on the wiki, but there are certainly gaps over and above those as you work your way down the list. Thanks, Steve -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 -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Treating notifications as a contract
From: Chris Dent [chd...@redhat.com] Tuesday, October 07, 2014 12:07 PM On Wed, 3 Sep 2014, Sandy Walsh wrote: Good goals. When Producer and Consumer know what to expect, things are good ... I know to find the Instance ID here. When the consumer wants to deal with a notification as a generic object, things get tricky (find the instance ID in the payload, What is the image type?, Is this an error notification?) Basically, how do we define the principle artifacts for each service and grant the consumer easy/consistent access to them? (like the 7-W's above) I'd really like to find a way to solve that problem. Is that a good summary? What did I leave out or get wrong? Great start! Let's keep it simple and do-able. Has there been any further thinking on these topics? Summit is soon and kilo specs are starting so I imagine more people than just me are hoping to get rolling on plans. If there is going to be a discussion at summit I hope people will be good about keeping some artifacts for those of us watching from afar. It seems to me that if the notifications ecosystem becomes sufficiently robust and resilient we ought to be able to achieve some interesting scale and distributed-ness opporunities throughout OpenStack, not just in telemetry/metering/eventing (choose your term of art). Haven't had any time to get anything written down (pressing deadlines with StackTach.v3) but open to suggestions. Perhaps we should just add something to the olso.messaging etherpad to find time at the summit to talk about it? -S ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Meeting time
Any of the proposed times work for me. -Ben On 10/07/2014 02:01 PM, Roman Podoliaka wrote: Hi all, Last Friday we decided to find a better time for the weekly team meeting. Keeping in mind that DST ends soon (October the 26th in Europe, November the 2nd in the US), I think, we can choose from: - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3 - Thursdays at 1600 UTC [2]: #openstack-meeting-3 - Thursdays at 1700 UTC [3]: #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3 (assuming the information about meeting rooms availability provided here [0] is correct) Basically, anything earlier than 1600 UTC will be too early for those who live in CA after November the 2nd. And 1700+ UTC is beer o'clock here in Europe :) Alternatively, we could ask Infra to add the meeting bot directly to #openstack-oslo channel and have the weekly meeting there on any day we like around 1600 UTC (#openstack-oslo is not really crowded, so it shouldn't be a problem to use it for a meeting once a week). Please let me know what you think. Thanks, Roman [0] https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics [1] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=3hour=16min=0sec=0p1=367p2=195p3=179p4=224 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=16min=0sec=0p1=367p2=195p3=179p4=224 [3] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=6hour=17min=0sec=0p1=367p2=195p3=179p4=224 [4] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=7hour=16min=0sec=0p1=367p2=195p3=179p4=224 ___ 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
Thank you all for your attention, In answer to Anita, in a way my goal is to get a good mark as I have been getting good marks so far. I had a project proposal of my own, a web app for a friend of mine but my supervisor didn't think it good enough to get me a good mark and she suggested I approach you. Final year projects don't seem to be about showing off what we have learned over the last 3/4 years rather to show off what we haven't learned at college. I started off my degree from a very low foundation of knowledge about programming and found I really liked the coding side of things so I switched to a software development degree in second year. It is very difficult to get the balance right when you realize how little you know about the subject, the more I learn the bigger the field seems to be getting. I will spend some time investigating the links you sent me. On 7 October 2014 19:41, Adam Lawson alaw...@aqorn.com wrote: Is the OP looking to help patch bugs with an individual program or to use Openstack to deploy an interesting use case? The latter is how I interpreted the question. *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 Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote: On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: On 10/06/2014 04:11 PM, Adam Young wrote: 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. I think writing a client / gui for openstack is one of the best single projects you can do to get a good overview of the whole stack. 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. snip It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. If you're doing a final year project and your highest goal isn't 'to get a good mark', then you're doing yourself a serious disservice. You can have all sorts of secondary goals, but by the point in your academic career where you're doing your final year project, your main goal is to prove you're learnt and can apply all of the skills that your course has covered. This actually involves a very different process to getting something done in the 'real world'. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Extremely difficult to get a decent academic project and therefore a good mark out of an existing project that has had any substantial amount of work done on it. Not impossible, but flicking through a pile of old final year projects that got good marks shows that stand-alone start-to-finish projects tend to get better marks. (I've looked into this quite a bit) -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state
Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700: Hi On 7 Oct 2014, at 20:47, Clint Byrum cl...@fewbar.com wrote: I don't think it should import those files wholesale, IMO that's making way too many assumptions about the similarity of the two builds. Disagree on the grounds that the point of this is to deal with people who already have images and want to update them. We're not trying to enable people to deploy radically different OS's or anything like that. My point is that we don't know what else is changing under the hood. Switching OS is a bit extreme, but we don't know that they're not going to pull in an OS upgrade at the same time and have everything change substantially, or even just introduce one additional dependency which we would destroy the uid/gid for. Ok, any time we can fail at build time is good, so merging is important. I agree now. I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each. The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen). That is a lot of complexity for the case that we don't want people to use (constantly carrying /etc/passwd and /etc/group forward). As tchaypo pointed out on IRC, if we do this static route, we are laying down a great big concrete slab of opinion in our images. I'm all for opinionated software, but we need to give people an out, which means we probably want to have a way for the suggested default UID/GIDs to be overridden, i.e. roughly what I described. We can just use that override to inject the pre-existing passwd/group values, if we so desire. Mmk. I think having an override is important, but I feel that we can do it in a more straight forward manner. I may not have thought it all the way through. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Treating notifications as a contract
From: Sandy Walsh [sandy.wa...@rackspace.com] Tuesday, October 07, 2014 6:07 PM Haven't had any time to get anything written down (pressing deadlines with StackTach.v3) but open to suggestions. Perhaps we should just add something to the olso.messaging etherpad to find time at the summit to talk about it? -S Actually, that's not really true. The Monasca team has been playing with schema definitions for their wire format (a variation on the kind of notification we ultimately want). And http://apiary.io/ is introducing support for structure schemas soon. Perhaps we can start with some schema proposals there? JSON-Schema based? For green-field installations, CADF is a possibility, but for already established services we will to document what's in place first. At some point we'll need a cross-project effort to identify all the important characteristics of the various services. Also, we've been finding no end of problems with the wild-west payload section. For example, look at all the different places we have to look to find the instance UUID from Nova. https://github.com/SandyWalsh/stacktach-sandbox/blob/verifier/winchester/event_definitions.yaml#L12-L17 Likewise for project_id, flavor_id, deleted_at, etc. Definitely need a solution to this. ___ 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/07/2014 05:21 PM, Patricia Ellis wrote: Thank you all for your attention, In answer to Anita, in a way my goal is to get a good mark as I have been getting good marks so far. Great. Thanks for getting back to us. Out of the replies thus far Duncan seems to have the most experience (that has been mentioned) in getting a good mark. He tends to hang out in the #openstack-cinder channel and, lucky you, is in your timezone. I would suggest having a follow up conversation with him to maximize your effectiveness at getting a good mark. I'm still interested in having that conversation with you, Adam, since I think you have some thoughts I would like to support. Thanks Patricia, Anita. I had a project proposal of my own, a web app for a friend of mine but my supervisor didn't think it good enough to get me a good mark and she suggested I approach you. Final year projects don't seem to be about showing off what we have learned over the last 3/4 years rather to show off what we haven't learned at college. I started off my degree from a very low foundation of knowledge about programming and found I really liked the coding side of things so I switched to a software development degree in second year. It is very difficult to get the balance right when you realize how little you know about the subject, the more I learn the bigger the field seems to be getting. I will spend some time investigating the links you sent me. On 7 October 2014 19:41, Adam Lawson alaw...@aqorn.com wrote: Is the OP looking to help patch bugs with an individual program or to use Openstack to deploy an interesting use case? The latter is how I interpreted the question. *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 Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.com wrote: On 7 October 2014 19:01, Anita Kuno ante...@anteaya.info wrote: On 10/07/2014 01:38 PM, Adam Young wrote: On 10/06/2014 05:28 PM, Anita Kuno wrote: On 10/06/2014 04:11 PM, Adam Young wrote: 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. I think writing a client / gui for openstack is one of the best single projects you can do to get a good overview of the whole stack. 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. No offense taken. I think you are looking out for the interest of the poster and people wityh similar interests. snip It would not be appropriate for someone in Patricia's position to try and come in and get a bug fix through. Now on this point, I'm going to disagree, simply because I don't have enough information on what Patricia's position actually is. I can guess but until I hear from Patricia herself, I'm just guessing and I would much rather know. It was my desire to know more about Patricia's position that motivated my suggestion she join irc and perhaps ask a few questions, allowing others to ask questions of her. When interacting with other folks who enter under similar circumstances, my first question invariably is What is your goal?. I truly hope Patricia has something better than to get a good mark because folks with that goal rarely interest me, but who knows. I haven't had the chance to ask. If you're doing a final year project and your highest goal isn't 'to get a good mark', then you're doing yourself a serious disservice. You can have all sorts of secondary goals, but by the point in your academic career where you're doing your final year project, your main goal is to prove you're learnt and can apply all of the skills that your course has covered. This actually involves a very different process to getting something done in the 'real world'. That limits the number of projects available. Now here is where I would like to interact with program administrators at institutions such as Patricia's to ask them why a project? We have over 300 including stackforge, why task a student with starting their own, why not encourage them to learn our development process which then can enable them to work on any of the 300 in various stages of development. Extremely difficult to get a decent academic project and therefore a good mark out of an existing
[openstack-dev] cross-project liaison list
At the project meeting today we decided that since we have several programs following the liaison system we should have a single page listing all liaisons, instead of separate project-specific pages. I have created https://wiki.openstack.org/wiki/CrossProjectLiaisons as that page, and moved the Oslo and QA lists there. If your project has a similar list, please consider adding it to the page. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [oslo] Acceptable methods for establishing per-test-suite behaviors
Hi folks - So just to update on the status here, for the transactional testing and all that, I’ve had a blueprint in the queue for quite awhile: https://review.openstack.org/#/c/117335/ and for a long time have had a working (with one caveat) version of the whole thing that uses testresources: https://review.openstack.org/120870 , which is also dependent on https://review.openstack.org/110170 as a first step. to recap, the purpose here is to provide a system that 1. creates and drops anonymous databases in an efficient way, where they are held open for the span of many (all?) tests on a per-process basis, 2. provides utilities to create schemas within these databases if needed, which if used are also held open for the span of many tests 3. allows individual tests to run within transactions where the state of the transaction is unconditionally rolled back at the end of each test, but the schema remains 4. unifies and simplifies the system by which we connect to lots of different kinds of databases within tests 5. makes the whole system of running against multiple backends easier to expand upon for new backends. This system works great, with the catch that as the original email describes here, to get something to happen “at the end of *all* tests”, e.g. drop those databases, is very challenging.The testresources way is to bundle all tests into a single suite called OptimisingTestSuite, which then provides its own run() method.OptimisingTestSuite can be rolled out on a per-module, or per-package, basis. What we’re shooting for here is to roll it out on a “per all tests completely” basis, by putting it in the top level __init__.py file where the tests start. Unfortunately there are some issues where depending on how tests are run, this top level file might not be loaded as a package, and then the load_tests() hook which this relies upon does not get invoked. Robert Collins created http://bugs.python.org/issue22457 to check with the Python devs on how this issue can be resolved, and if/when someone ever replies to it, he will commit similar workarounds to testtools directly. There is also some potential overlap with the fact that oslo.db itself runs tests without using the -d flag and instead points right at “tests/“, which would imply that we might need to move “tests/“ in oslo.db itself into more of a package like “oslodb/tests”, but I am not sure. In any case, any other project can still put the special load_tests() hook into their top level __init__.py or even within individual modules. So from my POV these patches are held up just so that load_tests() can work in all cases no matter where we put it, but in reality I think it’s fine that it would be placed in more database-test-specific locations. I’d really like to get these patches in so please feel free to review the spec as well as the patches. - mike On Aug 22, 2014, at 3:35 PM, Mike Bayer mba...@redhat.com wrote: Hi all - I’ve spent many weeks on a series of patches for which the primary goal is to provide very efficient patterns for tests that use databases and schemas within those databases, including compatibility with parallel tests, transactional testing, and scenario-driven testing (e.g. a test that runs multiple times against different databases). To that end, the current two patches that achieve this behavior in a rudimental fashion are part of oslo.db and are at: https://review.openstack.org/#/c/110486/ and https://review.openstack.org/#/c/113153/.They have been in the queue for about four weeks now. The general theory of operation is that within a particular Python process, a fixed database identifier is established (currently via an environment variable). As tests request the services of databases, such as a Postgresql database or a MySQL database, the system will provision a database within that backend of that fixed identifier and return it. The test can then request that it make use of a particular “schema” - for example, Nova’s tests may request that they are using the “nova schema”, which means that the schema for Nova’s model will be created within this database, and will them remain permanently across the span of many tests which use this same schema. Only when a test requests that it wants a different schema, or no schema, will the tables be dropped.To ensure the schema is “clean” for every test, the provisioning system ensures that each test runs within a transaction, which at test end is rolled back.In order to accommodate tests that themselves need to roll back, the test additionally runs within the context of a SAVEPOINT. This system is entirely working, and for those that are wondering, yes it works with SQLite as well (see https://review.openstack.org/#/c/113152/). And as implied earlier, to ensure the operations upon this schema don’t conflict with parallel test runs, the
Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
Congrats Pavlo, I have added you to core. -Angus On Wed, Oct 8, 2014 at 1:18 AM, Jeff Peeler jpee...@redhat.com wrote: +1 On 10/06/2014 04:41 PM, 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. Obviously past 5 +1 votes here, but showing full support doesn't hurt. 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] [Group-based Policy] Database migration chain
I posted a patch that implements the Different DB Different Chain approach [0]. That does not mean that this approach is the chosen one! It's just to have a grasp of what the change looks like. The Same DB different chain solution is much simpler to implement (basically you just specify a different version table in the alembic environment) so I haven't posted anything for that. One thing I'm particularly interested about is to hear packagers opinions about which approach would be the preferred one: Same DB or Different? Also, on the line of Bob's comment in my patch, is there any kind of compatibility or performance issue anyone is aware of about in using cross schema FKs? Thanks, Ivar. [0] https://review.openstack.org/#/c/126383/ On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote: 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
