Re: [openstack-dev] [all][docs][tc] How to scale Documentation

2014-10-07 Thread Christopher Yeoh
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

2014-10-07 Thread Sergey Kraynev
+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

2014-10-07 Thread Matthias Runge
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!)

2014-10-07 Thread Angus Lees
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

2014-10-07 Thread Thomas Herve

 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

2014-10-07 Thread Dmitri Zimine
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

2014-10-07 Thread Flavio Percoco
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

2014-10-07 Thread Steven Hardy
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

2014-10-07 Thread Thierry Carrez
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

2014-10-07 Thread Angus Salkeld
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

2014-10-07 Thread Timur Sufiev
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

2014-10-07 Thread Thierry Carrez
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

2014-10-07 Thread Chris Jones
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

2014-10-07 Thread Ihar Hrachyshka
-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

2014-10-07 Thread Salvatore Orlando
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

2014-10-07 Thread Davanum Srinivas
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

2014-10-07 Thread Robert Li (baoli)
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

2014-10-07 Thread Ihar Hrachyshka
-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

2014-10-07 Thread Anita Kuno
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

2014-10-07 Thread Doug Hellmann

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

2014-10-07 Thread Flavio Percoco
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

2014-10-07 Thread Kyle Mestery
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

2014-10-07 Thread Anne Gentle
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

2014-10-07 Thread Daniel P. Berrange
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

2014-10-07 Thread joehuang
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

2014-10-07 Thread Kyle Mestery
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

2014-10-07 Thread Duncan Thomas
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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Dmitriy Shulyak
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

2014-10-07 Thread Evgeniy L
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

2014-10-07 Thread Ghe Rivero
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...

2014-10-07 Thread Ben Meyer
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)

2014-10-07 Thread Jennifer Mulsow

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

2014-10-07 Thread Jason Dunsmore
+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

2014-10-07 Thread Kyle Mestery
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

2014-10-07 Thread Chris Dent

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

2014-10-07 Thread Evgeniy L
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

2014-10-07 Thread Evgeniy L
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

2014-10-07 Thread Jeff Peeler

+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

2014-10-07 Thread Monty Taylor
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

2014-10-07 Thread Chris Dent

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

2014-10-07 Thread Monty Taylor
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

2014-10-07 Thread Dmitriy Shulyak
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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Adam Young
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

2014-10-07 Thread Duncan Thomas
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

2014-10-07 Thread Mike Bayer

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

2014-10-07 Thread Henry Gessau
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

2014-10-07 Thread Zane Bitter

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

2014-10-07 Thread Dolph Mathews
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

2014-10-07 Thread Julie Pichon
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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Adam Young

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

2014-10-07 Thread Clint Byrum
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

2014-10-07 Thread Vishvananda Ishaya

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

2014-10-07 Thread Anita Kuno
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

2014-10-07 Thread Jay Faulkner
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

2014-10-07 Thread Joe Gordon
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

2014-10-07 Thread Duncan Thomas
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

2014-10-07 Thread Dean Troyer
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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Adam Lawson
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

2014-10-07 Thread Roman Podoliaka
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?

2014-10-07 Thread Ivar Lazzaro
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

2014-10-07 Thread Doug Hellmann

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?

2014-10-07 Thread Ihar Hrachyshka
-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

2014-10-07 Thread Robert Collins
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

2014-10-07 Thread Chris Jones
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

2014-10-07 Thread Ihar Hrachyshka
-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

2014-10-07 Thread Brandon Logan
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

2014-10-07 Thread Anne Gentle
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

2014-10-07 Thread Sławek Kapłoński
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

2014-10-07 Thread Mike Bayer

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?

2014-10-07 Thread Robert Kukura
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

2014-10-07 Thread Clint Byrum
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] Creation of neutron-drivers team

2014-10-07 Thread Joe Gordon
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.


We have had a subset of nova-core manage the blueprints for a while now
with good results.  I look forward to hearing how this works out for
Neutron in Kilo.




 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

___
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?

2014-10-07 Thread Kyle Mestery
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

2014-10-07 Thread Kevin Benton
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

2014-10-07 Thread Elizabeth K. Joseph
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

2014-10-07 Thread Matthew Treinish
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

2014-10-07 Thread Russell Bryant
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-07 Thread Dirk Müller
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

2014-10-07 Thread Chris Jones
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

2014-10-07 Thread Thierry Carrez
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

2014-10-07 Thread Doug Hellmann
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

2014-10-07 Thread Dirk Müller
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?

2014-10-07 Thread Ihar Hrachyshka
-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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Tristan Cacqueray
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

2014-10-07 Thread Sergey Lukjanov
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]

2014-10-07 Thread Steve Gordon
- 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

2014-10-07 Thread Sandy Walsh

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

2014-10-07 Thread Ben Nemec
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

2014-10-07 Thread Patricia Ellis
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

2014-10-07 Thread Clint Byrum
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

2014-10-07 Thread Sandy Walsh

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

2014-10-07 Thread Anita Kuno
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

2014-10-07 Thread Doug Hellmann
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

2014-10-07 Thread Mike Bayer
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

2014-10-07 Thread Angus Salkeld
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


  1   2   >