Re: [openstack-dev] [RFC] Straw man to start the incubation / graduation requirements discussion

[Monty Taylor]

On 11/13/2013 10:49 AM, Doug Hellmann wrote:
> 
> 
> 
> On Wed, Nov 13, 2013 at 7:49 AM, Thierry Carrez  > wrote:
> 
> Sean Dague wrote:
>> [...] Proposed Incubation requirements
>>  Once something becomes an
>> integrated project, it's important that they are able to run in the
>> gate.
> 
>> Both devstack and devstack-gate now support hooks, so with a couple
>> of days of work any project in stackforge could build a gate job
>> which sets up a devstack of their configuration, including their
>> code, running some project specific test they feel is appropriate
>> to ensure they could run in the gate environment.
> 
>> This would ensure an incubated project works with OpenStack global
>> requirements, or if it requires something new, that's known very
>> clearly before incubation.
> 
> That makes sense, my only concern with it is, how much support from
> QA/Infra would actually be needed *before* incubation can even be
> requested. One of the ideas behind the incubation status is to allow
> incubated projects to tap into common resources (QA, infra, release
> management...) as they cover the necessary ground before being fully
> integrated. Your proposal sounds like they would also need some
> support even before being incubated.


>> This was my main concern for making this an incubation requirement, too.
>> It's not that I think the new project will have a lot of trouble with
>> it, but any questions they do have will need to be answered by a team
>> that is already operating pretty close to capacity. If you think the
>> teams in question can take on the extra potential load, then I like the
>> idea.

I actually don't think this is additional load. Stackforge projects can
and do do this today already. They ask questions already. We ignore them
until we have bandwidth already. I think all we're saying is that we
expect that projects who want to become incubated be in the set of
projects who are already being proactive, learning how to write patches
to infra/config and being involved.

> Also does it place a requirement that all projects wanting to request
> incubation to be placed in stackforge ? That sounds like a harsh
> requirement if we were to reject them.

I'm not sure I think it's a harsh requirement. We've got enough internal
mass at this point that if stackforge is an impediment to you, you're
probably barking up the wrong tree.

> (sidenote: I'm planning to suggest we create an "emerging technology"
> label for projects that are (1) in stackforge, (2) applied for
> incubation but got rejected purely for community maturity reasons.
> Projects under this label would potentially get some limited space at
> summits to gain more visibility. Designate belongs to that category,
> but without a clear label it seems to fall in the vast bucket of
> openstack-related projects and not gaining more traction. Not sure we
> can leverage it to solve the issue here though).
> 
>> Proposed Graduation requirements 
>> All integrated projects should be in the integrated gate, as this
>> is the only way we provably know that they can all work together,
>> at the same level of requirements, in a consistent way.
> 
>> During incubation landing appropriate tests in Tempest is fair
>> game. So the expectation would be that once a project is incubated
>> they would be able to land tests in tempest. Before integrated
>> we'd need to ensure the project had tests which could take part in
>> the integrated gate, so as soon as a project is voted integrated,
>> it has some working integrated gate tests. (Note: there is actually
>> a symmetric complexity here, to be worked out later).
> 
> +1 -- I think we already made that decision for any future graduation..
> 
>> Proposed Stable Release requirements
>>  We have this automatic
>> transition that happens when a project that's integrated for a
>> release, actually releases as part of that. I.e. Trove and
>> Icehouse. There is no additional TC decision about whether or not
>> Trove is part of the stable release, once integrated, it just is.
>> Nothing that it does over that cycle will kick it out of the stable
>> release. This is one of the reasons it needs to be in the
>> integrated gate **before** graduation.
> 
>> Additionally, upgrade path is critically important to our users,
>> and the number one piece of feedback we received from the User
>> Survey. It was also important enough to our developers that it was
>> scattered all over the Icehouse Design Summit. All integrated
>> projects should be included in upgrade testing the moment they are
>> in a stable release. (ex: when Icehouse is released, Trove should
>> be in master grenade, and upgrade testing from Icehouse -> master
>> for the J cycle from day one).
> 
> I agree with you, but I don't see how we can enforce this one. Like
> you say, integrated projects get commonly released and get a 

Re: [openstack-dev] [qa] Proposals for Tempest core

[Matthew Treinish]

I think responding to this is worth breaking my vacation email embargo. 
Although I seem to remember a certain PTL whose vacation we waited for the last 
time we did core proposals... 

Sean Dague  wrote:
>It's post summit time, so time to evaluate our current core group for
>Tempest. There are a few community members that I'd like to nominate
>for
>Tempest core, as I've found their review feedback over the last few
>months to be invaluable. Tempest core folks, please +1 or -1 as you
>feel
>appropriate:
>
>Masayuki Igawa
>
>His review history is here -
>https://review.openstack.org/#/q/reviewer:masayuki.igawa%2540gmail.com+project:openstack/tempest,n,z
>

+1

>Ken'ichi Ohmichi
>
>His review history is here -
>https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com+project:openstack/tempest,n,z
>

+1

>They have both been actively engaged in the Tempest community, and have
>been actively contributing to both Tempest and OpenStack integrated
>projects, working hard to both enhance test coverage, and fix the
>issues
>found in the projects themselves. This has been hugely beneficial to
>OpenStack as a whole.
>
>At the same time, it's also time, I think, to remove Jay Pipes from
>tempest-core. Jay's not had much time for reviews of late, and it's
>important that the core review team is a working title about actively
>reviewing code.

+1, but sad to see you go Jay. Thanks for all the past effort. 

>
>With this change Tempest core would end up no longer being majority
>north american, or even majority english as first language (that kind
>of
>excites me). Adjusting to both there will be another mailing list
>thread
>about changing our weekly meeting time to make it more friendly to our
>APAC contributors.
>
>   -Sean


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association

[Steven Weston]

Hi Salvatore!

My responses (to your responses) are in-line. I think we could also use 
some feedback from the rest of the community on this, as well ... would 
it be a good idea to discuss the implementation further at the next IRC 
meeting?


Good Stuff!!

Steven

On 11/15/2013 7:39 AM, Salvatore Orlando wrote:




On 14 November 2013 23:03, Steven Weston > wrote:


Hi Salvatore,

My Launchpad ID is steven-weston.  I do not know who those other
Steven Westons are ... if someone has created clones of me, I am
going to be upset! Anyway, Here are my thoughts on the
implementation approach.

I have now assigned the blueprint to you.

Great, thank you!


Is there any reason why the two alternatives you listed should be
considered mutually exclusive?

In line of principle they're not. But if we provide the facility in 
Neutron, doing the orchestration from nova for the association would 
be, in my opinion, just redundant.

Unless I am not understanding what you suggest.


I agree, implementing the functionality in nova and neutron would be 
redundant, although I was suggesting that the nova api be modified to 
allow for the auto association request on vm creation, which would then 
be passed to neutron for the port creation.  Currently it looks to only 
be available as a configuration option in nova.


So far I understand the goal is to pass a 'autoassociate_fip' flag (or 
something similar) to POST /v2/port
the operation will create two resource: a floating IP and a port, with 
only the port being returned (hence the side-effect).




This sounds good, unless we want to modify the api behavior to return a 
list of floating ips, as you already suggested below.  Or would it be 
better to return a mapping of fixed ips to floating ips, since that 
would technically be more accurate?


I think that in consideration of loosely coupled design, it would
be best to make the attribute addition to the port in neutron and
create the ability for nova to orchestrate the call as well.  I do
not see a way to prevent modification of the REST API, and in the
interest of fulfilling your concern of atomicity, the fact that an
auto association was requested will need to be stored somewhere,
in addition to the state of the request as well.

Storing the autoassociation could be achieved with a flag on the 
floating IP data model. But would that also imply that the association 
for an auto-associate floatingIP cannot be altered?

I think that depends on how we want it to work ... see my comments below.


Plus, tracking the attribute in neutron would allow the ability of
other events to fire that would need to be performed in response
to an auto associate request, such as split zone dns updates (for
example).  The primary use case for this would be for request by
nova, although I can think of other services which could use it as
well -- load balancers, firewalls, vpn's, and any component that
would require connectivity to another network.  I think the
default behavior of the auto association request would be to
create ip addresses on the associated networks of the attached
routers, unless a specific network is given.


Perhaps I need more info on this specific point; I think the current 
floating_port_id - port_id might work to this aim; perhaps the reverse 
mapping would be needed to, and we might work to add id - but I don't 
see why we would need a 'auto_associate' flag. This is not a 
criticism. It's just me being dumb perhaps!


This one is my fault, I should have been more clear as to what I was 
thinking ... the purpose of the flag would be to provide some sort of 
state that a floating ip was allocated as the result of an 
auto-association .. not necessarily for consumption by neutron, but for 
other "services" that might want to use the information.  I do see a 
reason to store it for  Neutron's usage as well, but I guess that would 
depend on whether the behavior of an auto associated floating ip address 
would be different than a normal, independently associated floating ip 
address.  Which brings up a few good implementation questions.  1.  
Should the mapping between the floating and fixed be immutable?  2.  
When the port is deleted, should the floating ip address be removed as 
well?  3.  What about in the reverse situation,  should deletion of the 
floating ip address be denied until the port no longer exists?  
Depending on what your answers are to these questions, then IMHO I would 
suggest possibly adding an "is_auto_associated" flag to the floating ip 
data model, as you alluded to above.


I apologize if these situations are already addressed in Neutron ... if 
they are, I couldn't find them ... I believe they are currently handled 
by nova.  If I am incorrect on this, please point me in the right direction!


To conclude I think it might be actually not bad at all to allow for 
specifyi

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Russell Bryant]

On 11/16/2013 11:18 AM, Álvaro López García wrote:
> On Fri 15 Nov 2013 (07:28), Dan Smith wrote:
>> Hi all,
> 
> Hi Dan.
> 
>> As you know, Nova adopted a plan to require CI testing for all our
>> in-tree hypervisors by the Icehouse release. At the summit last week, we
>> determined the actual plan for deprecating non-compliant drivers. I put
>> together a page detailing the specific requirements we're putting in
>> place as well as a plan and timeline for how the deprecation process
>> will proceed:
>>
>> https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
>>
>> I also listed the various drivers and whether we've heard any concrete
>> plans from them. Driver owners should feel free to add details to that
>> and correct any of the statements if incorrect.
> 
> I've posted an email one month ago about this and the support of Xen
> via libvirt [1]. We are happy users of this ad we would love to see
> it being promoted form the use-at-your-own-risk group C to group B.
> Should we add it to the list of drivers in the group C, and add another
> column to the table so that we can start filling it with the
> supported/working features? Should I fill a blueprint for this?
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/016661.html

I don't think we need a blueprint.

Yes, I would list it under group C and add a column for it.

Is there any chance you would be interested in working on setting up CI
for it?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Anita Kuno]

On 11/16/2013 01:14 PM, Anita Kuno wrote:

On 11/16/2013 12:37 PM, Sean Dague wrote:

On 11/15/2013 10:36 AM, Russell Bryant wrote:

On 11/13/2013 11:10 AM, Anita Kuno wrote:

Neutron Tempest code sprint

In the second week of January in Montreal, Quebec, Canadathere will be a
Neutron Tempest code sprint to improve the status of Neutron tests in
Tempest and to add new tests.

First off, I think anything regarding putting more effort into this is
great.  However, I *beg* the Neutron team not to wait until this week to
make significant progress.

To be clear, IMO, this is already painfully late.  It's one of the
largest items blocking deprecation of nova-network and moving forward
with Neutron.  This spring is just a couple weeks before icehouse-2.
Come i2, mid-cycle, we're going to have make a call on whether or not
nova-network deprecation seems likely.  If not, we really can't wait
around and I will probably propose un-freezing nova-network.

100% agreed. Realistically this has to be a capping session, not when
the real work starts. If the agent rewrite isn't done, and the parallel
gate basically working before then, it won't work.

Honestly, I think we're going to need to checkpoint before Christmas to
figure out if the preconditions are met, because if they aren't, then
it's not clear the 3 days of code sprint are really going to generate
the results we need.

I'm encouraged by the level of activity in the neutron channel, so I
think right now planning for success is good. But again, we need some
aggressive check points, and people need to realize this is not the
beginning of this work, it is the closing session.

-Sean
Great. What kind of check points in a mutual location would we like to 
see?


Etherpad?

Meeting logs?

Other suggestions?

Thanks Sean,
Anita.

Actually I am going to answer my own question with a proposal.

I would like to see a special sub-committee of the TC convened comprised 
of (5?) TC members and/or appointees for the express purpose of being 
available to help meet this goal, be available in the -neutron irc 
channel for questions and support and also to guide the process so the 
goal is achieved.


Thoughts?

Anita.



___
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] Split of the openstack-dev list

[Miguel Angel]

2013/11/16 Sean Dague 

> On 11/14/2013 02:25 PM, Mark Washenberger wrote:> It seems excessive, I
> agree. But if your meeting time bounces on a
> > biweekly schedule to accommodate multiple timezones, I think its quite
> > necessary.
>
> And the fact that people forget the times are in UTC
>
> Honestly I'd be +1 for an openstack-meeting list where people posted
> announces and minutes (should they wish). There are a subset of us that
> would find that useful, and it would move the traffic off of -dev.
>
>
I totally agree with having an openstack-meeting list to keep us posted with
minutes and meetings.

+1

---
irc: ajo / mangelajo
Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Anita Kuno]

Silly me and Saturday emails. I mistakenly sent out the emails to the 
individual participants from my gmail account not this one. Sorry about 
that.


Thanks,
Anita.

On 11/16/2013 10:12 AM, Anita Kuno wrote:
I have just sent out emails asking for specific details for food and 
so on to the 31 emails provided to me, thank you all for indicating 
your intent.


If you would like to attend the code sprint and did not receive an 
email from this email address anteaya at anteaya dot info (check your 
spam folder, please) please email me and ensure I add you to the list.


I look forward to hearing from you all as soon as possible so I can 
submit my budget for the event.


My thanks,
Anita.

On 11/13/2013 01:48 PM, Anita Kuno wrote:
So if you are requesting a letter of invitation to enter Canada, here 
is what I have to do to provide it:

http://www.cic.gc.ca/english/visit/letter.asp

It appears that letters of invitation are only required sometimes:
"Sometimes, when you apply for a visa to visit Canada, we ask you to 
give us a letter of invitation from someone in Canada."
so I will encourage you to contact your closest Canadian embassy or 
consulate outside of Canada to assess if you need one. Hopefully if 
you are planning on staying less that 1 week, you won't need one. But 
contact the embassy and be sure.


Thanks,
Anita.

On 11/13/2013 01:25 PM, Edgar Magana wrote:

Will do ASAP.

Thanks,

Edgar

On 11/13/13 10:20 AM, "Anita Kuno"  wrote:


Hi Edgar:

I hadn't thought of that, I guess I am going to have to do that.

For others, check if you need a visa to enter Canada:
http://www.cic.gc.ca/ENGLISH/visit/visas.asp
Please notify me ASAP if you do, even if you aren't sure you can 
attend

so I can get the paperwork you need.

Edgar, can you email me your address to my personal email anteaya at
anteaya dot info so I can work on this for you.

Thanks,
Anita.

On 11/13/2013 01:12 PM, Edgar Magana wrote:

Anita,

Could you prepare the invitation letters for the ones that will 
require

a
visa?, which is my case.

Thanks,

Edgar

On 11/13/13 8:10 AM, "Anita Kuno"  wrote:


Neutron Tempest code sprint

In the second week of January in Montreal, Quebec, Canadathere 
will be

a
Neutron Tempest code sprint to improve the status of Neutron 
tests in

Tempest and to add new tests.
It will be a 3 day event. Right now there are 14 peoplewho came 
forward
when it was announced on the Friday at the summit. We need to 
know how

many additional people are interested in attending.

This is an impromptu event based on my assessment of the need for 
this

to happen, so don't feel left out if you didn't know about it in
advance.

We picked Montreal for two main reasons:
1. All 4 people whose attendance is critical (markmclain, 
salv-orlando,

sdague and mtrenish) can get there. It was New York or Montreal.
2. I can't think in New York, love it, can't compose a thought, so
Montreal it is.

It turns out this location choice has some resultant effects:
1. People who wouldn't have time to get a visa to attend an event in
the
States have an easier time entering Canada.
  US requires visa applications filed 2 months in advance of 
travel

and we are inside that timeframe.
2. Montreal is cheaper than NYC.
3. Being Canadian it is going to be easier for me to produce this 
event

in Canada since I am in Canada.
4. It will be cold. We had few choices on the timing and this event
can't wait on good weather.

There is no location that will make everyone happy, so people 
will be
disappointed by this choice and I accept that. It is my hope that 
this

event is a success and we can create a schedule of some sort so that
people who have a high possibility of attending can vote on the
location. So that is the future vision.

I have a tenative hold on a venue and am working on getting a 
rate on a

block of rooms at a hotel.

I am preparing a budget to submit to the Foundation in the hopes 
they

will sponsor the event. Since this was planned with no warning, the
Foundation has no budget for it. Mark is supportive of the event
happening and if I can come up with some reasonable numbers, I hope
that
the money can come from the Foundation.

The event will be vendor neutral. We will talk to each other 
based on
who we are and our interests, not based on who signs our 
paycheque. If

folks arrive with logoed shirts (I don't know which logos are work
logos
and which aren't, so I will request no logos please) I will issue 
you a
white T-shirt to wear. We need to work collaboratively to 
effectlvely

make progress during the code sprint.

Someone at the summit choose not to wear footwear at the event. 
If you

want to come to the code sprint please plan on wearing appropriate
footwear in the public areas at the code sprint. For two reasons:
1. It will be cold.
2. The event is meant to facilitate mutual respect between us to
increase communication, both at the event and afterwards. I feel
wearing
appropriate footwear supports this goal.

Please 

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Anita Kuno]

On 11/16/2013 12:37 PM, Sean Dague wrote:

On 11/15/2013 10:36 AM, Russell Bryant wrote:

On 11/13/2013 11:10 AM, Anita Kuno wrote:

Neutron Tempest code sprint

In the second week of January in Montreal, Quebec, Canadathere will be a
Neutron Tempest code sprint to improve the status of Neutron tests in
Tempest and to add new tests.

First off, I think anything regarding putting more effort into this is
great.  However, I *beg* the Neutron team not to wait until this week to
make significant progress.

To be clear, IMO, this is already painfully late.  It's one of the
largest items blocking deprecation of nova-network and moving forward
with Neutron.  This spring is just a couple weeks before icehouse-2.
Come i2, mid-cycle, we're going to have make a call on whether or not
nova-network deprecation seems likely.  If not, we really can't wait
around and I will probably propose un-freezing nova-network.

100% agreed. Realistically this has to be a capping session, not when
the real work starts. If the agent rewrite isn't done, and the parallel
gate basically working before then, it won't work.

Honestly, I think we're going to need to checkpoint before Christmas to
figure out if the preconditions are met, because if they aren't, then
it's not clear the 3 days of code sprint are really going to generate
the results we need.

I'm encouraged by the level of activity in the neutron channel, so I
think right now planning for success is good. But again, we need some
aggressive check points, and people need to realize this is not the
beginning of this work, it is the closing session.

-Sean

Great. What kind of check points in a mutual location would we like to see?

Etherpad?

Meeting logs?

Other suggestions?

Thanks Sean,
Anita.




___
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] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Anita Kuno]

On 11/16/2013 12:42 PM, Sean Dague wrote:

On 11/15/2013 01:13 PM, Mark McLoughlin wrote:

On Fri, 2013-11-15 at 12:47 -0500, Anita Kuno wrote:

On 11/15/2013 12:34 PM, Russell Bryant wrote:

On 11/15/2013 12:16 PM, Kyle Mestery (kmestery) wrote:

On Nov 15, 2013, at 11:04 AM, Dan Smith  wrote:

Thanks for weighing in, I do hope to keep the conversation going.

Add my name to the list of people that won't be considering the trip as
a result.


Are people really saying that if they show up for this Tempest sprint
with a logo shirt they would actually take it off and wear a white shirt
provided by someone, or that this will prevent them from going at all?
I can't even believe we're having this conversation on the list, frankly.

I'm saying that I find it so ridiculous, that I wouldn't consider going
at all.

I find the suggestion that I would be given a different shit to wear so
offensive, that I have to waste time having this conversation to condemn
it publicly.  I have a lot of pride in OpenStack, and don't want anyone
to think that everyone finds this sort of requirement acceptable in our
community.

I respect this about you, Russell and it is one of the many reasons I am
so glad to work with you.

Had this level of pride in OpenStack been prevalent during the Neutron
design summit sessions, it wouldn't even have occured to me to mention it.

I hope to attract people with this level of pride in OpenStack to the
code sprint and my thought was that eliminating logos would support that
goal.

What would you suggest to attract and foster this level of pride in
OpenStack in the code sprint attendees?

I will also note, that while you clearly stated the Neutron is being
considered for deprecation - t-shirts prevail as an issue on this
thread. I consider that rather interesting to observe.

I think you're expressing a similar sentiment to e.g. "there should be
more Neutron developers who work on core Neutron rather than just their
drivers". I'm cool with that, and totally agree.

Choosing to pick on people's choice of clothing is just a bizarre way of
expressing that concern, though.

Bear in mind how often I talk about this being a community of
individuals, we should all wear our "project hats", that our affiliation
should be secondary to our commitment to our project, ...

Dictating what people can wear to an OpenStack event is not my idea of
what OpenStack is all about. It's not my idea of the "mutual respect"
you talk about.

100% agree with Mark. I think the spirit of working together on the
whole can be set as a tone without rules and policies around people's
clothing. This is about inclusiveness.

I'd like the clothing restriction bits retracted from this as well,
because I don't think it's really relevant to the discussion, the
sprint, or how we function as a community.

-Sean
It happened yesterday: 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019403.html


I'm really heartened by the content in the discussion so far. Thanks to 
all who are adding value.


Anita.




___
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] Split of the openstack-dev list

[Sean Dague]

On 11/14/2013 02:25 PM, Mark Washenberger wrote:
> 
> 
> 
> On Thu, Nov 14, 2013 at 5:19 AM, Thierry Carrez  > wrote:
> 
> Thierry Carrez wrote:
> > [...]
> > That will not solve all issues. We should also collectively make sure
> > that *usage questions are re-routed* to the openstack general
> > mailing-list, where they belong. Too many people still answer
> off-topic
> > questions here on openstack-dev, which encourages people to be
> off-topic
> > in the future (traffic on the openstack general ML has been mostly
> > stable, with only 868 posts in October). With those actions, I
> hope that
> > traffic on openstack-dev would drop back to the 1000-1500 range, which
> > would be more manageable for everyone.
> 
> Other suggestion: we could stop posting meeting reminders to -dev (I
> know, I'm guilty of it) and only post something if the meeting time
> changes, or if the weekly meeting is canceled for whatever reason.
> 
> 
> It seems excessive, I agree. But if your meeting time bounces on a
> biweekly schedule to accommodate multiple timezones, I think its quite
> necessary.

And the fact that people forget the times are in UTC

Honestly I'd be +1 for an openstack-meeting list where people posted
announces and minutes (should they wish). There are a subset of us that
would find that useful, and it would move the traffic off of -dev.

Honestly, I don't the QA meeting post to the main list because of
volume, but if we had a separate place for that, it would be cool.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack + OpenContrail

[Dean Troyer]

On Sat, Nov 16, 2013 at 11:15 AM, Harshad Nakil
wrote:

> Sean,
> We have diff in three repositories.
> Nova, Neutron and devstack. Each review is requiring other to happen first.
> Do you have recommendation how do we deal with these dependencies?
>

First off, if you rebase on to a current DevStack you will find a new
plugin mechanism specifically designed to address this sort of problem.
 You've already worked out the plugin bits for Neutron, the parts for
stack.sh are similar, located in extras.d.
http://devstack.org/plugins.htmldescribes how it works.

Also, DevStack does not install support services that are not packaged in
the underlying distro.  Look at Docker's split between the support
service(s) that start before stack.sh runs and the parts that specifically
configure Nova.

The patches to Neutron and Nova should be handled by setting the *_BRANCH
and *_REPO variables to point to your repo and branch.  DevStack will check
them out for you when it installs the project source.

You should be able to re-arrange things to support this architecture.
 Also, expect to break the remaining DevStack changes into digestible bits.
 As it stands, your branch is unmergable, even if it was based on a
semi-current commit.

FWIW, the opencontrail.org website appears to be off the air making it
harder to understand what it is you are trying to integrate here.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Sean Dague]

On 11/15/2013 01:13 PM, Mark McLoughlin wrote:
> On Fri, 2013-11-15 at 12:47 -0500, Anita Kuno wrote:
>> On 11/15/2013 12:34 PM, Russell Bryant wrote:
>>> On 11/15/2013 12:16 PM, Kyle Mestery (kmestery) wrote:
 On Nov 15, 2013, at 11:04 AM, Dan Smith  wrote:
>> Thanks for weighing in, I do hope to keep the conversation going.
> Add my name to the list of people that won't be considering the trip as
> a result.
>
 Are people really saying that if they show up for this Tempest sprint
 with a logo shirt they would actually take it off and wear a white shirt
 provided by someone, or that this will prevent them from going at all?
 I can't even believe we're having this conversation on the list, frankly.
>>> I'm saying that I find it so ridiculous, that I wouldn't consider going
>>> at all.
>>>
>>> I find the suggestion that I would be given a different shit to wear so
>>> offensive, that I have to waste time having this conversation to condemn
>>> it publicly.  I have a lot of pride in OpenStack, and don't want anyone
>>> to think that everyone finds this sort of requirement acceptable in our
>>> community.
>> I respect this about you, Russell and it is one of the many reasons I am 
>> so glad to work with you.
>>
>> Had this level of pride in OpenStack been prevalent during the Neutron 
>> design summit sessions, it wouldn't even have occured to me to mention it.
>>
>> I hope to attract people with this level of pride in OpenStack to the 
>> code sprint and my thought was that eliminating logos would support that 
>> goal.
>>
>> What would you suggest to attract and foster this level of pride in 
>> OpenStack in the code sprint attendees?
>>
>> I will also note, that while you clearly stated the Neutron is being 
>> considered for deprecation - t-shirts prevail as an issue on this 
>> thread. I consider that rather interesting to observe.
> 
> I think you're expressing a similar sentiment to e.g. "there should be
> more Neutron developers who work on core Neutron rather than just their
> drivers". I'm cool with that, and totally agree.
> 
> Choosing to pick on people's choice of clothing is just a bizarre way of
> expressing that concern, though.
> 
> Bear in mind how often I talk about this being a community of
> individuals, we should all wear our "project hats", that our affiliation
> should be secondary to our commitment to our project, ...
> 
> Dictating what people can wear to an OpenStack event is not my idea of
> what OpenStack is all about. It's not my idea of the "mutual respect"
> you talk about.

100% agree with Mark. I think the spirit of working together on the
whole can be set as a tone without rules and policies around people's
clothing. This is about inclusiveness.

I'd like the clothing restriction bits retracted from this as well,
because I don't think it's really relevant to the discussion, the
sprint, or how we function as a community.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Sean Dague]

On 11/15/2013 10:36 AM, Russell Bryant wrote:
> On 11/13/2013 11:10 AM, Anita Kuno wrote:
>> Neutron Tempest code sprint
>>
>> In the second week of January in Montreal, Quebec, Canadathere will be a
>> Neutron Tempest code sprint to improve the status of Neutron tests in
>> Tempest and to add new tests.
> 
> First off, I think anything regarding putting more effort into this is
> great.  However, I *beg* the Neutron team not to wait until this week to
> make significant progress.
> 
> To be clear, IMO, this is already painfully late.  It's one of the
> largest items blocking deprecation of nova-network and moving forward
> with Neutron.  This spring is just a couple weeks before icehouse-2.
> Come i2, mid-cycle, we're going to have make a call on whether or not
> nova-network deprecation seems likely.  If not, we really can't wait
> around and I will probably propose un-freezing nova-network.

100% agreed. Realistically this has to be a capping session, not when
the real work starts. If the agent rewrite isn't done, and the parallel
gate basically working before then, it won't work.

Honestly, I think we're going to need to checkpoint before Christmas to
figure out if the preconditions are met, because if they aren't, then
it's not clear the 3 days of code sprint are really going to generate
the results we need.

I'm encouraged by the level of activity in the neutron channel, so I
think right now planning for success is good. But again, we need some
aggressive check points, and people need to realize this is not the
beginning of this work, it is the closing session.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [RFC] Straw man to start the incubation / graduation requirements discussion

[Sean Dague]

On 11/15/2013 12:57 PM, Mark McLoughlin wrote:
> On Wed, 2013-11-13 at 06:57 -0500, Sean Dague wrote:
>> (Apologies, this started on the TC list, and really should have started
>> on -dev, correctly posting here now for open discussion)
>>
>> There were a few chats at summit about this, mostly on the infra /
>> devstack / qa side of the house. Consider the following a straw man to
>> explain the current state of the world, and what I'd like to see change here
>> I call out projects by name here, not to
>> make fun of them, but that I think concrete examples bring the point
>> home much more than abstract arguments (at least for me).
>>
>> This is looking at raising the bar quite a bit along the way. However,
>> as someone that spends a lot of time trying to keep the whole ball of
>> wax holding together, and is spending a lot of time retroactively trying
>> to get projects into our integrated gate (and huge pain to everyone, as
>> their gate commits get bounced by racey projects), I think we really
>> need to up this bar if we want a 20 integrated project version of
>> OpenStack to hold together.
> 
> Thanks for doing this. The requirements look good to me.
> 
> I think it's about time we gathered all requirements together and
> properly documented them so people realize there's a much bigger
> picture. I've started pulling together some stuff here:
> 
>   https://etherpad.openstack.org/p/incubation-and-integration-requirements
> 
> but clearly there's a lot of work to do.
> 
> One thing I really, really want is for the rules to be accompanied with
> a good explanation of what the rules are there to achieve. We cannot let
> ourselves turn into a community that over-zealously applies rules to the
> extent that the rules do more damage than good.
> 
> There's always got to be a judgement call involved. I'm happy that
> Ceilometer graduated, even though it doesn't have gating tests. I think
> it has been a positive addition and I'd rather have it without the
> gating tests than not at all.
> 
> The guidelines like this will greatly encourage projects to up their
> game and hopefully we'll rarely be faced with a generally awesome
> project wanting to graduate but it not having integration tests.
> However, if that did happen, we need it to at least be possible for us
> to have a rational, big-picture conversation about whether some
> rule-bending is the best thing overall for the project.

Absolutely, I'm completely happy to call these guidelines, this wasn't
meant as a written in stone, but as best practices. Rationale is of
utmost importance, it informs the future community why we chose to do a
thing, which also makes it clear when that guideline is no longer
relevant because something else changed.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] future fate of nova-network?

[Sean Dague]

That is clearly a step in the right direction, and I have to commend the
neutron team for really kicking things into high gear in going after
some of these issues.

That said, we still have a long way to go. I think a very frank
evaluation at icehouse-2 is going to be required to figure out whether
nova-network either is indeed deprecated, or we remove the deprecation
language from it and let more feature development happen back on the
nova side.

On 11/15/2013 02:36 PM, Davanum Srinivas wrote:
> fyi. gate-tempest-devstack-vm-neutron-large-ops is now a bit more
> stable (compare [1] and [2]) with the Nova change [3]. Joe earlier
> posted a call to arms [4] yesterday.
> 
> [1] 
> http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkZpbmlzaGVkOiBGQUlMVVJFXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLXRlbXBlc3QtZGV2c3RhY2stdm0tbmV1dHJvbi1sYXJnZS1vcHNcIiAiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzODQ1NDM3NDgzODcsIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0=
> [2] 
> http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkZpbmlzaGVkOiBTVUNDRVNTXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLXRlbXBlc3QtZGV2c3RhY2stdm0tbmV1dHJvbi1sYXJnZS1vcHNcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4NDU0MzgxOTg1MCwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==
> [3] https://review.openstack.org/#/c/56075/
> [4] http://markmail.org/message/lelobpwkle34sh4a
> 
> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant  wrote:
>> On 11/15/2013 01:26 PM, Lorin Hochstein wrote:
>>> Was the fate of nova-network discussed at the icehouse summit?
>>
>> Yes. [1][2]
>>
>>> In particular, has there been a decision made about whether it will
>>> definitely be deprecated in some (as yet unspecified) future release, or
>>> whether it will continue to be supported for the foreseeable future?
>>
>> We want to deprecate it.  There are some things blocking moving forward
>> with this.  In short:
>>
>> 1) Feature parity (primarily something that satisfies performance and HA
>> requirements addressed by nova-network in multi-host mode)
>>
>> 2) Testing and quality parity.  The status of Neutron testing in the
>> gate is far inferior to the testing done against nova-network.
>>
>> I'm personally more worried about #2 than #1 at this point.
>>
>> A major issue is that very few people actually stepped up and agreed to
>> help with #2 at the summit [2].  Only one person signed up to work on
>> tempest issues.  Nobody signed up to help with grenade.  If this doesn't
>> happen, nova-network can't be deprecated, IMO.
>>
>> If significant progress isn't made ASAP this cycle, and ideally by
>> mid-cycle so we can change directions if necessary, then we'll have to
>> discuss what next step to take.  That may include un-freezing
>> nova-network so that various people holding on to enhancements to
>> nova-network can start submitting them back.  It's a last resort, but I
>> consider it on the table.
>>
>> [1] https://etherpad.openstack.org/p/icehouse-neutron-nova-parity
>> [2] https://etherpad.openstack.org/p/icehouse-summit-qa-neutron
>>
>> --
>> Russell Bryant
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack + OpenContrail

[Harshad Nakil]

Sean,
We have diff in three repositories.
Nova, Neutron and devstack. Each review is requiring other to happen first.
Do you have recommendation how do we deal with these dependencies?

Regards
-Harshad


> On Nov 16, 2013, at 9:11 AM, Sean Dague  wrote:
>
> For something to go in devstack, it has to be included in the base server 
> project. So first step is to work on getting your code upstream into the 
> relevant upstream.
>
> We don't preintegrate into devstack, because it's job is not to be a general 
> installer, it's to be an opinionated development setup tool for the existing 
> integrated projects, making it easier for people to develop and work with the 
> whole stack.
>
>-Sean
>
>> On 11/15/2013 07:35 PM, Deepinder Singh Setia wrote:
>> I would like to add that the work in forked devstack is ongoing and not
>> complete. I am trying to understand what would it take to push these
>> changes upstream such as coding requirements, testing, code
>> organization, documentation  etc.
>>
>> Thanks
>> Deepinder
>>
>> From: Deepinder Setia mailto:dse...@juniper.net>>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Date: Friday, November 15, 2013 4:25 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Subject: [openstack-dev] Openstack + OpenContrail
>>
>> I forked devstack a few weeks ago to integrate with OpenContrail at
>> https://github.com/dsetia/devstack.  This installs and launches
>> OpenContrail in addition to openstack components.  OpenContrail provides
>> network virtualization components -  SDN controller, Virtual Router and
>> analytics  - via neutron and nova plugins along with other modules built
>> and launched when stack.sh is run. Please see
>>
>>  * https://github.com/dsetia/devstack/blob/master/contrail/README -
>>  * 
>> http://pedrormarques.wordpress.com/2013/11/14/using-devstack-plus-opencontrail/
>>
>>  * http://opencontrail.org/
>>
>> Bulk of the work is done by new file lib/neutron_thirdparty/contrail
>> such as cloning open contrail repo, building and launching contrail
>> modules. I also have directory called contrail under devstack which
>> includes:
>>
>> 1. sample localrc files for setting up single or multi node openstack +
>>open contrail system
>> 2. Support files and scripts needed by  lib/neutron_thirdparty/contrail
>>functions
>> 3. Neutron and Nova patches needed by OpenStack. These plugins have
>>been submitted for review. Once approved, I will get rid of code to
>>patch them
>>
>> I would like to understand the procedure, requirements and logistics  to
>> push these changes upstream to devstack repository.
>>
>> Thanks
>> Deepinder
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack + OpenContrail

[Sean Dague]

For something to go in devstack, it has to be included in the base 
server project. So first step is to work on getting your code upstream 
into the relevant upstream.


We don't preintegrate into devstack, because it's job is not to be a 
general installer, it's to be an opinionated development setup tool for 
the existing integrated projects, making it easier for people to develop 
and work with the whole stack.


-Sean

On 11/15/2013 07:35 PM, Deepinder Singh Setia wrote:

I would like to add that the work in forked devstack is ongoing and not
complete. I am trying to understand what would it take to push these
changes upstream such as coding requirements, testing, code
organization, documentation  etc.

Thanks
Deepinder

From: Deepinder Setia mailto:dse...@juniper.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, November 15, 2013 4:25 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] Openstack + OpenContrail

I forked devstack a few weeks ago to integrate with OpenContrail at
https://github.com/dsetia/devstack.  This installs and launches
OpenContrail in addition to openstack components.  OpenContrail provides
network virtualization components -  SDN controller, Virtual Router and
analytics  - via neutron and nova plugins along with other modules built
and launched when stack.sh is run. Please see

  * https://github.com/dsetia/devstack/blob/master/contrail/README -
  * 
http://pedrormarques.wordpress.com/2013/11/14/using-devstack-plus-opencontrail/

  * http://opencontrail.org/

Bulk of the work is done by new file lib/neutron_thirdparty/contrail
such as cloning open contrail repo, building and launching contrail
modules. I also have directory called contrail under devstack which
includes:

 1. sample localrc files for setting up single or multi node openstack +
open contrail system
 2. Support files and scripts needed by  lib/neutron_thirdparty/contrail
functions
 3. Neutron and Nova patches needed by OpenStack. These plugins have
been submitted for review. Once approved, I will get rid of code to
patch them

I would like to understand the procedure, requirements and logistics  to
push these changes upstream to devstack repository.

Thanks
Deepinder



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Hypervisor CI requirement and deprecation plan

[Álvaro López García]

On Fri 15 Nov 2013 (07:28), Dan Smith wrote:
> Hi all,

Hi Dan.

> As you know, Nova adopted a plan to require CI testing for all our
> in-tree hypervisors by the Icehouse release. At the summit last week, we
> determined the actual plan for deprecating non-compliant drivers. I put
> together a page detailing the specific requirements we're putting in
> place as well as a plan and timeline for how the deprecation process
> will proceed:
> 
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
> 
> I also listed the various drivers and whether we've heard any concrete
> plans from them. Driver owners should feel free to add details to that
> and correct any of the statements if incorrect.

I've posted an email one month ago about this and the support of Xen
via libvirt [1]. We are happy users of this ad we would love to see
it being promoted form the use-at-your-own-risk group C to group B.
Should we add it to the list of drivers in the group C, and add another
column to the table so that we can start filling it with the
supported/working features? Should I fill a blueprint for this?

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-October/016661.html

> Thanks!
> 
> --Dan
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Álvaro López García  al...@ifca.unican.es
Instituto de Física de Cantabria http://alvarolopez.github.io
Ed. Juan Jordá, Campus UC  tel: (+34) 942 200 969
Avda. de los Castros s/n
39005 Santander (SPAIN)
_
http://xkcd.com/571/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Split of the openstack-dev list (summary so far)

[Nick Chase]

I am one of those horizontal people (working on docs and basically one of
the people responsible at my organization for keeping a handle on what's
going on) and I'm totally against a split.

Of COURSE we need to maintain the integrated/incubated/proposed spectrum.
Saying that we need to keep all traffic on one list isn't suggesting we do
away with that. But it IS a spectrum, and we should maintain that.
Splitting the list is definitely splitting the community and I agree that
it's a poison pill.

Integrating new projects into the community is just as important as
integrating them into the codebase.  Without one the other won't happen
nearly as effectively, and we do lose one of the strengths of the community
as a whole.

Part of this is psychology. Many of us are familiar with broken windows
theory[1] in terms of code.  For those of you who aren't, the idea is based
on an experiment where they left an expensive car in a crime-ridden
neighborhood and nothing happened to it -- until they broke a window.  In
coding it means you're less likely to kludge a patch to pristine code, but
once you do you are more likely to do it again.

Projects work hard to do things "the OpenStack way" because they feel from
the start that they are already part of OpenStack, even if they aren't
integrated.

It also leads to another side effect, which I'll leave to you to decide
whether it's good or bad.  We do have a culture of "there can be only
one".  Once a project is proposed in a space, that's it (mostly).  We
typically don't have multiple projects in that space.  That's bad because
it reduces innovation through competition, but it's good because we get
focused development from the finite number of developers we have available.
As I said, YMMV.

Look, Monty is right: a good threaded client solves a multitude of
problems.  Definitely try that for a week before you set your mind on a
decision.

TL; DR Splitting the list is splitting the community, and that will lead to
a decline in overall quality.

[1] http://en.wikipedia.org/wiki/Broken_windows_theory
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Anita Kuno]

I have just sent out emails asking for specific details for food and so 
on to the 31 emails provided to me, thank you all for indicating your 
intent.


If you would like to attend the code sprint and did not receive an email 
from this email address anteaya at anteaya dot info (check your spam 
folder, please) please email me and ensure I add you to the list.


I look forward to hearing from you all as soon as possible so I can 
submit my budget for the event.


My thanks,
Anita.

On 11/13/2013 01:48 PM, Anita Kuno wrote:
So if you are requesting a letter of invitation to enter Canada, here 
is what I have to do to provide it:

http://www.cic.gc.ca/english/visit/letter.asp

It appears that letters of invitation are only required sometimes:
"Sometimes, when you apply for a visa to visit Canada, we ask you to 
give us a letter of invitation from someone in Canada."
so I will encourage you to contact your closest Canadian embassy or 
consulate outside of Canada to assess if you need one. Hopefully if 
you are planning on staying less that 1 week, you won't need one. But 
contact the embassy and be sure.


Thanks,
Anita.

On 11/13/2013 01:25 PM, Edgar Magana wrote:

Will do ASAP.

Thanks,

Edgar

On 11/13/13 10:20 AM, "Anita Kuno"  wrote:


Hi Edgar:

I hadn't thought of that, I guess I am going to have to do that.

For others, check if you need a visa to enter Canada:
http://www.cic.gc.ca/ENGLISH/visit/visas.asp
Please notify me ASAP if you do, even if you aren't sure you can attend
so I can get the paperwork you need.

Edgar, can you email me your address to my personal email anteaya at
anteaya dot info so I can work on this for you.

Thanks,
Anita.

On 11/13/2013 01:12 PM, Edgar Magana wrote:

Anita,

Could you prepare the invitation letters for the ones that will 
require

a
visa?, which is my case.

Thanks,

Edgar

On 11/13/13 8:10 AM, "Anita Kuno"  wrote:


Neutron Tempest code sprint

In the second week of January in Montreal, Quebec, Canadathere 
will be

a
Neutron Tempest code sprint to improve the status of Neutron tests in
Tempest and to add new tests.
It will be a 3 day event. Right now there are 14 peoplewho came 
forward
when it was announced on the Friday at the summit. We need to know 
how

many additional people are interested in attending.

This is an impromptu event based on my assessment of the need for 
this

to happen, so don't feel left out if you didn't know about it in
advance.

We picked Montreal for two main reasons:
1. All 4 people whose attendance is critical (markmclain, 
salv-orlando,

sdague and mtrenish) can get there. It was New York or Montreal.
2. I can't think in New York, love it, can't compose a thought, so
Montreal it is.

It turns out this location choice has some resultant effects:
1. People who wouldn't have time to get a visa to attend an event in
the
States have an easier time entering Canada.
  US requires visa applications filed 2 months in advance of 
travel

and we are inside that timeframe.
2. Montreal is cheaper than NYC.
3. Being Canadian it is going to be easier for me to produce this 
event

in Canada since I am in Canada.
4. It will be cold. We had few choices on the timing and this event
can't wait on good weather.

There is no location that will make everyone happy, so people will be
disappointed by this choice and I accept that. It is my hope that 
this

event is a success and we can create a schedule of some sort so that
people who have a high possibility of attending can vote on the
location. So that is the future vision.

I have a tenative hold on a venue and am working on getting a rate 
on a

block of rooms at a hotel.

I am preparing a budget to submit to the Foundation in the hopes they
will sponsor the event. Since this was planned with no warning, the
Foundation has no budget for it. Mark is supportive of the event
happening and if I can come up with some reasonable numbers, I hope
that
the money can come from the Foundation.

The event will be vendor neutral. We will talk to each other based on
who we are and our interests, not based on who signs our 
paycheque. If

folks arrive with logoed shirts (I don't know which logos are work
logos
and which aren't, so I will request no logos please) I will issue 
you a

white T-shirt to wear. We need to work collaboratively to effectlvely
make progress during the code sprint.

Someone at the summit choose not to wear footwear at the event. If 
you

want to come to the code sprint please plan on wearing appropriate
footwear in the public areas at the code sprint. For two reasons:
1. It will be cold.
2. The event is meant to facilitate mutual respect between us to
increase communication, both at the event and afterwards. I feel
wearing
appropriate footwear supports this goal.

Please indicate your interest by sending an email to
ante...@anteaya.info, subject "Neutron Tempest code sprint". Don't
worry
about the body of the email, I just need addresses. We will send out
subsequent emails to this group

Re: [openstack-dev] [Glance] Summit Session Summaries

[Zhi Yan Liu]

Awesome Mark! It's really useful to help us start next works to
organize, prioritize and realize icehouse BPs, thanks.

Seems here is a good place to continue our discussion around my
proposal so I have added some inline replies to "Enhancing Image
Locations" section, you know 50 mins is a little tight to me :) I have
a lot of point try to address.

On Sat, Nov 16, 2013 at 8:29 AM, Yongsheng Gong  wrote:
> great, thanks
>
>
> On Sat, Nov 16, 2013 at 5:10 AM, Mark Washenberger
>  wrote:
>>
>> Hi folks,
>>
>> My summary notes from the OpenStack Design Summit Glance sessions follow.
>> Enjoy, and please help correct any misunderstandings.
>>
>>
>>
>> Image State Consistency:
>> 
>>
>> https://etherpad.openstack.org/p/icehouse-summit-image-state-consistency
>>
>> In this session, we focused on the problem of snapshots that fail
>> after the image is created but before the image data is uploaded
>> result in a pending image that will never become active, and the
>> only operation nova can do is to delete the image. Thus there is
>> not a very good way to communicate the failure to users without
>> just leaving a useless image record around.
>>
>> A solution was proposed to allow Nova to directly set the status
>> of the image, say to "killed" or some other state.
>>
>> A problem with the proposed solution is that we generally have
>> kept the "status" field internally controlled by glance, which
>> means there are some modeling and authorization concerns.
>> However, it is actually something Nova could do today through
>> the hacky mechanism of initiating a PUT with data, but then
>> terminating the connection without sending a complete body. So
>> the authorization aspects are not really a fundamental concern.
>>
>> It was suggested that the solution to this problem
>> is to make Nova responsible for reporting these failures rather
>> than Glance. In the short term, we could do the following
>>  - have nova delete the image when snapshot fails (already merged)
>>  - merge nova patch to report the failure as part of instance
>>error reporting
>>
>> In the longer term, it was seen as desirable for nova to treat
>> snapshots as asynchronous tasks and reflect those tasks in the
>> api, including the failure/success of those tasks.
>>
>> Another long term option that was viewed mostly favorably was
>> to add another asynchronous task to glance for vanilla uploads
>> so that nova snapshots can avoid creating the image until it
>> is fully active.
>>
>> Fei Long Wang is going to follow up on what approach makes the
>> most sense for Nova and report back for our next steps.
>>
>>
>>
>> What to do about v1?
>> 
>>
>> https://etherpad.openstack.org/p/icehouse-summit-images-v1-api
>>
>> In this discussion, we hammered out the details for how to drop
>> the v1 api and in what timetable.
>>
>> Leaning heavily on cinder's experience dropping v1, we came
>> up with the following schedule.
>>
>> Icehouse:
>> - Announce plan to deprecate the V1 API and registry in J and remove
>> it in K
>> - Announce feature freeze for v1 API immediately
>> - Make sure everything in OpenStack is using v2 (cinder, nova, ?)
>> - Ensure v2 is being fully covered in tempest tests
>> - Ensure there are no gaps in the migration strategy from v1 to v2
>> - after the fact, it seems to me we need to produce a migration
>> guide as a way to evaluate the presence of such gaps
>> - Make v2 the default in glanceclient
>> - Turn v2 on by default in glance API
>>
>> "J":
>> - Mark v1 as deprecated
>> - Turn v1 off by default in config
>>
>> "K":
>> - Delete v1 api and v1 registry
>>
>>
>> A few gotchas were identified, in particular, a concern was raised
>> about breaking stable branch testing when we switch the default in
>> glanceclient to v2--since latest glanceclient will be used to test
>> glance  in say Folsom or Grizzly where the v2 api didn't really
>> work at all.
>>
>> In addition, it was suggested that we should be very aggressive
>> in using deprecation warnings for config options to communicate
>> this change as loudly as possible.
>>
>>
>>
>>
>> Image Sharing
>> -
>>
>> https://etherpad.openstack.org/p/icehouse-summit-enhance-v2-image-sharing
>>
>> This session focused on the gaps between the current image sharing
>> functionality and what is needed to establish an image marketplace.
>>
>> One issue was the lack of verification of project ids when sharing an
>> image.
>>
>> A few other issues were identified:
>> - there is no way to share an image with a large number of projects in a
>> single api operation
>> - membership lists are not currently paged
>> - there is no way to share an image with everyone, you must know each
>> other project id
>>
>> We identified a potential issue with bulk operations and
>> verification--namely there is no way to do bulk verification of project ids
>> in keystone that we know of, so probably keystone wo

Re: [openstack-dev] Split of the openstack-dev list (summary so far)

[Anita Kuno]

On 11/16/2013 02:52 AM, Monty Taylor wrote:


On 11/15/2013 05:06 AM, Thierry Carrez wrote:

Wow, lots of different opinions! let's try to summarize:

Arguments in favor of splitting openstack-dev / stackforge-dev
* People can easily filter out all non-openstack discussions
* Traffic would drop by about 25%
* Removes confusion as to which projects are actually "in openstack"

Arguments in favor of keeping it the same
* Provides a cross-pollination forum where external projects can learn
* More chaos creates more innovation

Personally I was fine with having everyone in the same "burgeoning city"
(to quote the lyrical Clint) until we recently crossed the bar of making
that city painful for a lot of people. Especially the people who work on
serving the needs of all OpenStack projects (think release management,
doc, QA, infra) and who have to pay some level of attention to every thread.

Yes, those people can filter out all stackforge discussions into a
separate folder: identify all the corresponding prefixes and setting
filters for them (and praying that they would all just use the right
suffixes). But rather than forcing everyone to go through that setup,
why not set up a list and make it more convenient for everyone to apply
different (or similar !) reading rules to the two different groups.

Because they ARE two different groups. One is "OpenStack" and must get
the extra attention of all the people working on horizontal functions
(that is what incubation is about, carefully controlling access to extra
common resources). The other is "not yet OpenStack", free-for-all. The
latter group clearly benefits from being on the same list: they get
extra attention from all those smart OpenStack people, and their
marketing can benefit from the very blurry line between openstack and
not-yet-openstack we maintain on the list.

I don't think this applies at the mailing list level. If someone wants
attention from the infra team, for instance, I certainly hope they don't
think they're going to get it by mentioning the need inside of a mailing
list thread and hoping we'll see it.

Mailing lists are for conversation and discussion. I see absolutely no
reason to segregate some of those conversations as "real" and others as
not. In fact, our original hard insistence that projects started off in
the corner until they magically one day became openstack is what got us
into the mess we've gone through originally with keystone (which needed
a complete from-scratch rewrite) and now with neutron.
I wouldn't have believed it until I witnessed it myself but yes, Monty 
is absolutely correct in this regard. I will be changing my vote on 
https://review.openstack.org/#/c/56432/


Needing to see things for myself is why I am where I am, and while I am 
not comfortable where I am, it sure gives me a whole lot of information 
I didn't have before.

  Both of those
came about before we had more inclusive ways of projects growing themselves.

tl;dr Separation has been tried before, and it simple does not work.


In summary, I certainly see the benefits of a single list for stackforge
developers (and why people working on a limited number of vertical
projects don't really mind either way...). But I fear that we maintain
those benefits at the expense of the sanity of the horizontal programs
in openstack, and therefore lower the quality of OpenStack as a result.

PS: I don't think we can reach consensus on that one -- we might need to
push it to the TC to make a final call.


___
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] Split of the openstack-dev list (summary so far)

[Matt Riedemann]

On Saturday, November 16, 2013 2:09:35 AM, Monty Taylor wrote:



On 11/15/2013 12:08 PM, Thierry Carrez wrote:

Adrian Otto wrote:

If OpenStack starts a culture of exclusion instead of inclusion, that would start a 
dangerous trend that sets the wrong tone. It would quickly reach the point where new 
projects like mine would simply not come here. We would go somewhere else that does have 
a culture of inclusion. We would not employ the values of open design and open 
collaboration, and we would be back to the "throw stuff over the wall" approach 
to open source. That would be a tragedy. Don't destroy the things about OpenStack's 
community that make it awesome.


It's definitely a trade-off between usability and community inclusion...
Trust me, I understand the value of cross-pollination, which is why I
wouldn't support a pure per-project split (as suggested elsewhere in
this thread). I'm just trying to find the right balance.


Because they ARE two different groups.


That thinking is backwards. From a community perspective we are not two 
different groups. Making us into two groups is a huge mistake.


I was talking about groups of projects. We have an incubation process to
decide when new projects are allowed to start tapping into OpenStack
common resources, like use an openstack/* repo, get into the integrated
gate, or tap into QA or release management dudes for guidance. I see
openstack-dev ML space as one of those common resources. Letting anyone
use it to talk about their new stackforge project has some cost, even if
it's an externality to you.

This is not about excluding anyone, it's about prioritizing our
resources. If we followed your line of thought, we should just abandon
the project incubation process because it's a way to prevent promising
projects from accessing resources they need in order to develop their
full potential.

Anyway, I don't expect to convince you, since you're clearly the one
benefiting the most from the current setup. I'm on the other end of the
spectrum, trying my best to keep my sanity with the ever-growing number
of things I need to keep an eye on :) And maybe the benefits of
unlimited cross-pollination are worth more than the drawback of forcing
everyone to process enormous email piles every day. (Filtering is an
option I have with well-behaved projects like Solum, I just fear it
would not work so well for less "filterable" threads.)


Can I suggest that you don't try purely mechanical filtering into
folders? Instead, for a while, try using a threaded client, and
configure it to show threads unexpanded by default. Then, when you're
going to read openstack-dev, you can scan the subject lines with your
eyes, which are AMAZINGLY good at pattern recognition and
contextualization. It's pretty easy to skip over the non-OpenStack threads.

BTW - in the 55 most recently active threads in openstack-dev, 8 of them
are for topics that are only of interest to 'official' OpenStack
projects. All 8 of them are properly prefixed and easy to ignore. There
are a few, like:

[openstack-dev] [Trove][Savanna][Murano] Unified Agent proposal
discussion at Summit

that involve integrated, incubated, and stackforge projects. But those
are still related to integrated or incubated, so I did not include them
in the 8.

For the record, I'm pasting the topics and message counts here:

[openstack-dev] Split of the openstack-dev list (48 messages)
[openstack-dev] [Neutron] New plug-ins requirements (7 messages)
[openstack-dev] Is Havana keystone rpm actually splitting identity and
assignment? (4 messages)
[openstack-dev] Using AD for keystone authentication only (9 messages)
[openstack-dev] Openstack + OpenContrail (2 messages)
[openstack-dev] [Glance] Summit Session Summaries (2 messages)
[openstack-dev] [nova][api] Is this a potential issue (11 messages)
[openstack-dev] sqlalchemy-migrate 0.8.1 (2 messages)
[openstack-dev] [qa] Proposals for Tempest core (5 messages)
[openstack-dev] [Heat] Continue discussing multi-region orchestration
(13 messages)
[openstack-dev] Congress: an open policy framework (10 messages)
[openstack-dev] [nova][object] One question to the resource tracker
session (11 messages)
[openstack-dev] [Solum] SFO Design Workshop
[openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of
January, Montreal, QC, Canada (27 messages)
[openstack-dev] [Neutron] Troubleshooting OVS RPC API unit test error (3
messages)
[openstack-dev] sqlalchemy-migrate needs a new release (15 messages)
[openstack-dev] [Neutron] Find the compute host on which a VM runs (2
messages)
[openstack-dev] [Neutron] Plugin and Driver Inclusion Requirements (4
messages)
[openstack-dev] Shall backward compatibility env. vars be removed from
python-clients? (6 messages)
[openstack-dev] [horizon] User registrations (9 messages)
[openstack-dev] [Heat] rough draft of Heat autoscaling API (26 messages)
[openstack-dev] [Solum] Command Line Interface for Solum (20 messages)
[openstack-dev] [nova] future fate of 

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

[Angus Salkeld]

On 15/11/13 08:46 -0600, Christopher Armstrong wrote:

On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter  wrote:


On 15/11/13 02:48, Christopher Armstrong wrote:


On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld mailto:asalk...@redhat.com>> wrote:

On 14/11/13 10:19 -0600, Christopher Armstrong wrote:

http://docs.heatautoscale.__apiary.io/



I've thrown together a rough sketch of the proposed API for
autoscaling.
It's written in API-Blueprint format (which is a simple subset
of Markdown)
and provides schemas for inputs and outputs using JSON-Schema.
The source
document is currently at
https://github.com/radix/heat/__raw/as-api-spike/
autoscaling.__apibp




Things we still need to figure out:

- how to scope projects/domains. put them in the URL? get them
from the
token?
- how webhooks are done (though this shouldn't affect the API
too much;
they're basically just opaque)

Please read and comment :)


Hi Chistopher

In the group create object you have 'resources'.
Can you explain what you expect in there? I thought we talked at
summit about have a unit of scaling as a nested stack.

The thinking here was:
- this makes the new config stuff easier to scale (config get applied
  per scaling stack)

- you can potentially place notification resources in the scaling
  stack (think marconi message resource - on-create it sends a
  message)

- no need for a launchconfig
- you can place a LoadbalancerMember resource in the scaling stack
  that triggers the loadbalancer to add/remove it from the lb.


I guess what I am saying is I'd expect an api to a nested stack.


Well, what I'm thinking now is that instead of "resources" (a mapping of
resources), just have "resource", which can be the template definition
for a single resource. This would then allow the user to specify a Stack
resource if they want to provide multiple resources. How does that sound?



My thought was this (digging into the implementation here a bit):

- Basically, the autoscaling code works as it does now: creates a template
containing OS::Nova::Server resources (changed from AWS::EC2::Instance),
with the properties obtained from the LaunchConfig, and creates a stack in
Heat.
- LaunchConfig can now contain any properties you like (I'm not 100% sure
about this one*).
- The user optionally supplies a template. If the template is supplied, it
is passed to Heat and set in the environment as the provider for the
OS::Nova::Server resource.



I don't like the idea of binding to OS::Nova::Server specifically for
autoscaling. I'd rather have the ability to scale *any* resource, including
nested stacks or custom resources. It seems like jumping through hoops to


big +1 here, autoscaling should not even know what it is scaling, just
some resource. solum might want to scale all sorts of non-server
resources (and other users).


support custom resources by overriding OS::Nova::Server instead of just
allowing users to specify the resource that they really want directly.

How about we offer two "types" of configuration, one which supports
arbitrary resources and one which supports OS::Nova::Server-specific launch
configurations? We could just add a type="server" / type="resource"
parameter which specifies which type of scaling unit to use.



How about just one "nested-stack".
Keep it simple.





This should require no substantive changes to the code since it uses
existing abstractions, it makes the common case the default, and it avoids
the overhead of nested stacks in the default case.


-1



cheers,
Zane.

* One thing the existing LaunchConfig does is steer you in the direction
of not doing things that won't work - e.g. you can't specify a volume to
attach to the server, because you can't attach a single boot volume to
multiple servers. The way to do that correctly will be to include the
volume in the provider template. So maybe we should define a set of allowed
properties for the LaunchConfig, and make people hard-code anything else
they want to do in the provider template, just to make it harder to do
wrong things. I'm worried that would make composition in general harder
though.



If we offer a type="server" then the launch configuration can be restricted
to things that can automatically be scaled. I think if users want more
interesting scaling units they should use resources and specify both a
server and a volume as heat resources.

--
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
O

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

[Angus Salkeld]

On 15/11/13 16:32 +0100, Zane Bitter wrote:

On 14/11/13 19:53, Christopher Armstrong wrote:

Thanks for the comments, Zane.


On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter mailto:zbit...@redhat.com>> wrote:
   A few comments...

   #1 thing is that the launch configuration needs to be somehow
   represented. In general we want the launch configuration to be a
   provider template, but we'll want to create a shortcut for the
   obvious case of just scaling servers. Maybe we pass a provider
   template (or URL) as well as parameters, and the former is optional.


I'm a little unclear as to what point you're making here. Right now, the
"launch configuration" is specified in the scaling group by the
"resources" property of the request json body. It's not a full template,
but just a "snippet" of a set of resources you want scaled.


Right, and this has a couple of effects, particularly for Heat:
1) You can't share a single launch config between scaling groups - 
this hurts composability of templates.
2) The AWS::EC2::Launch config wouldn't correspond to a real API, so 
we would have to continue to implement it using the current hack.


IMHO we should not let the design be altered by aws resources.
- let lauchconfing be ugly.
- make the primary interface of a scaling unit be a nested stack (with
  our new config resources etc..)



Fixing (2) is one of my top two reasons for even having an autoscaling API.


As an aside, maybe we should replace this with a singlular "resource"
and allow people to use a Stack resource if they want to represent
multiple resources.

I guess we can have a simpler API for using an old-style,
server-specific "launch configuration", but I am skeptical of the
benefit, since specifying a single Instance resource is pretty simple.


See my other message for implementation suggestion.


   I'm not sure I understand the webhooks part... webhook-exec is the
   thing that e.g. Ceilometer will use to signal an alarm, right? Why
   is it not called something like
   /groups/{group_id}/policies/{__policy_id}/alarm ? (Maybe because it
   requires different auth middleware? Or does it?)


Mostly because it's unnecessary. The idea was to generate a secret,
opaque, revokable ID that maps to the specific policy.
Â


Seems like it would be nice to look at the webhook URL and be able to 
figure out what it's for. I disagree that a secret URL is sufficient 
here, but even if it were it could be something like:


/groups/{group_id}/policies/{policy_name}/alarm/{secret_code}



   And the other ones are setting up the notification actions? Can we
   call them notifications instead of webhooks? (After all, in the
   future we will probably want to add Marconi support, and maybe even
   Mistral support.) And why are these attached to the policy? Isn't
   the notification connected to changes in the group, rather than
   anything specific to the policy? Am I misunderstanding how this
   works? What is the difference between 'uri' and 'capability_uri'?



Policies represent ways to change a group ("add +5% to this group").
Webhooks execute policies.

A "capability URI" is a URI which represents a capability to do
something all by itself. capability_uri would be the webhook-exec thing.
The regular URI would be the thing under
/groups/{group_id}/policies/{policy_id}/webhooks. That URI needs to
exist so you can perform the DELETE operation on it. (but you can't
DELETE the capability_uri, only POST to it to execute the policy).
Â


Oh, I was misunderstanding... this doesn't set up the notifications, 
it allows you to create and revoke multiple webhook URLs for the 
alarms.


I have reservations about this whole area.


I'll think more about webhooks vs notifications.


Seems like a way to configure the notifications is missing altogether.

cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration

[Zane Bitter]

On 16/11/13 00:07, Georgy Okrokvertskhov wrote:

Hi,

With slight modifications of (2) one can benefit of availability:
1. There should not be a master node. Each heat engine should be able to
act as a master if someone asks it to deploy a template. Current master
engine will be responsible to contact other engines and pass them the
same template and wait for confirmation.
2. Each Heat engine instance receives whole template but deploys only
resources which are designated to engine's zone

This will provide all benefits of availability as all engines will keep
a copy of a template and you can update template by using any heat
engine. For example if heat engine in region 1 is down or whole site 1
is down you can update a template with new region settings and update it
with using heat engine in region 2.


What you're describing is basically Option (5) - build a globally 
highly-available distributed Heat engine. I don't see how you can 
describe that as a "slight modification", it's an entire research 
project that is probably  bigger in scope than everything else we have 
to do in Icehouse put together. As stated previously, I am heavily -2 on 
this idea.



The multi-region support proposal contains information and proposal for
"what" and "how" but does not describe "why". If we talk just about
multi-region placement support then option (4) works fine. If there is
an intension to build a solution for HA, DR, elastic scalability for
spike loads then we need to keep availability as a part of a design.


I think we should build a system that allows our users to manage 
highly-available global apps, not try to build one ourselves.


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Split of the openstack-dev list (summary so far)

[Monty Taylor]

On 11/15/2013 12:08 PM, Thierry Carrez wrote:
> Adrian Otto wrote:
>> If OpenStack starts a culture of exclusion instead of inclusion, that would 
>> start a dangerous trend that sets the wrong tone. It would quickly reach the 
>> point where new projects like mine would simply not come here. We would go 
>> somewhere else that does have a culture of inclusion. We would not employ 
>> the values of open design and open collaboration, and we would be back to 
>> the "throw stuff over the wall" approach to open source. That would be a 
>> tragedy. Don't destroy the things about OpenStack's community that make it 
>> awesome.
> 
> It's definitely a trade-off between usability and community inclusion...
> Trust me, I understand the value of cross-pollination, which is why I
> wouldn't support a pure per-project split (as suggested elsewhere in
> this thread). I'm just trying to find the right balance.
> 
>>> Because they ARE two different groups.
>>
>> That thinking is backwards. From a community perspective we are not two 
>> different groups. Making us into two groups is a huge mistake.
> 
> I was talking about groups of projects. We have an incubation process to
> decide when new projects are allowed to start tapping into OpenStack
> common resources, like use an openstack/* repo, get into the integrated
> gate, or tap into QA or release management dudes for guidance. I see
> openstack-dev ML space as one of those common resources. Letting anyone
> use it to talk about their new stackforge project has some cost, even if
> it's an externality to you.
> 
> This is not about excluding anyone, it's about prioritizing our
> resources. If we followed your line of thought, we should just abandon
> the project incubation process because it's a way to prevent promising
> projects from accessing resources they need in order to develop their
> full potential.
> 
> Anyway, I don't expect to convince you, since you're clearly the one
> benefiting the most from the current setup. I'm on the other end of the
> spectrum, trying my best to keep my sanity with the ever-growing number
> of things I need to keep an eye on :) And maybe the benefits of
> unlimited cross-pollination are worth more than the drawback of forcing
> everyone to process enormous email piles every day. (Filtering is an
> option I have with well-behaved projects like Solum, I just fear it
> would not work so well for less "filterable" threads.)

Can I suggest that you don't try purely mechanical filtering into
folders? Instead, for a while, try using a threaded client, and
configure it to show threads unexpanded by default. Then, when you're
going to read openstack-dev, you can scan the subject lines with your
eyes, which are AMAZINGLY good at pattern recognition and
contextualization. It's pretty easy to skip over the non-OpenStack threads.

BTW - in the 55 most recently active threads in openstack-dev, 8 of them
are for topics that are only of interest to 'official' OpenStack
projects. All 8 of them are properly prefixed and easy to ignore. There
are a few, like:

[openstack-dev] [Trove][Savanna][Murano] Unified Agent proposal
discussion at Summit

that involve integrated, incubated, and stackforge projects. But those
are still related to integrated or incubated, so I did not include them
in the 8.

For the record, I'm pasting the topics and message counts here:

[openstack-dev] Split of the openstack-dev list (48 messages)
[openstack-dev] [Neutron] New plug-ins requirements (7 messages)
[openstack-dev] Is Havana keystone rpm actually splitting identity and
assignment? (4 messages)
[openstack-dev] Using AD for keystone authentication only (9 messages)
[openstack-dev] Openstack + OpenContrail (2 messages)
[openstack-dev] [Glance] Summit Session Summaries (2 messages)
[openstack-dev] [nova][api] Is this a potential issue (11 messages)
[openstack-dev] sqlalchemy-migrate 0.8.1 (2 messages)
[openstack-dev] [qa] Proposals for Tempest core (5 messages)
[openstack-dev] [Heat] Continue discussing multi-region orchestration
(13 messages)
[openstack-dev] Congress: an open policy framework (10 messages)
[openstack-dev] [nova][object] One question to the resource tracker
session (11 messages)
[openstack-dev] [Solum] SFO Design Workshop
[openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of
January, Montreal, QC, Canada (27 messages)
[openstack-dev] [Neutron] Troubleshooting OVS RPC API unit test error (3
messages)
[openstack-dev] sqlalchemy-migrate needs a new release (15 messages)
[openstack-dev] [Neutron] Find the compute host on which a VM runs (2
messages)
[openstack-dev] [Neutron] Plugin and Driver Inclusion Requirements (4
messages)
[openstack-dev] Shall backward compatibility env. vars be removed from
python-clients? (6 messages)
[openstack-dev] [horizon] User registrations (9 messages)
[openstack-dev] [Heat] rough draft of Heat autoscaling API (26 messages)
[openstack-dev] [Solum] Command Line Interface for Solum (20 messages)
[openstack-dev]

Re: [openstack-dev] Split of the openstack-dev list (summary so far)

[Monty Taylor]

On 11/15/2013 05:06 AM, Thierry Carrez wrote:
> Wow, lots of different opinions! let's try to summarize:
> 
> Arguments in favor of splitting openstack-dev / stackforge-dev
> * People can easily filter out all non-openstack discussions
> * Traffic would drop by about 25%
> * Removes confusion as to which projects are actually "in openstack"
> 
> Arguments in favor of keeping it the same
> * Provides a cross-pollination forum where external projects can learn
> * More chaos creates more innovation
> 
> Personally I was fine with having everyone in the same "burgeoning city"
> (to quote the lyrical Clint) until we recently crossed the bar of making
> that city painful for a lot of people. Especially the people who work on
> serving the needs of all OpenStack projects (think release management,
> doc, QA, infra) and who have to pay some level of attention to every thread.
> 
> Yes, those people can filter out all stackforge discussions into a
> separate folder: identify all the corresponding prefixes and setting
> filters for them (and praying that they would all just use the right
> suffixes). But rather than forcing everyone to go through that setup,
> why not set up a list and make it more convenient for everyone to apply
> different (or similar !) reading rules to the two different groups.
> 
> Because they ARE two different groups. One is "OpenStack" and must get
> the extra attention of all the people working on horizontal functions
> (that is what incubation is about, carefully controlling access to extra
> common resources). The other is "not yet OpenStack", free-for-all. The
> latter group clearly benefits from being on the same list: they get
> extra attention from all those smart OpenStack people, and their
> marketing can benefit from the very blurry line between openstack and
> not-yet-openstack we maintain on the list.

I don't think this applies at the mailing list level. If someone wants
attention from the infra team, for instance, I certainly hope they don't
think they're going to get it by mentioning the need inside of a mailing
list thread and hoping we'll see it.

Mailing lists are for conversation and discussion. I see absolutely no
reason to segregate some of those conversations as "real" and others as
not. In fact, our original hard insistence that projects started off in
the corner until they magically one day became openstack is what got us
into the mess we've gone through originally with keystone (which needed
a complete from-scratch rewrite) and now with neutron. Both of those
came about before we had more inclusive ways of projects growing themselves.

tl;dr Separation has been tried before, and it simple does not work.

> In summary, I certainly see the benefits of a single list for stackforge
> developers (and why people working on a limited number of vertical
> projects don't really mind either way...). But I fear that we maintain
> those benefits at the expense of the sanity of the horizontal programs
> in openstack, and therefore lower the quality of OpenStack as a result.
> 
> PS: I don't think we can reach consensus on that one -- we might need to
> push it to the TC to make a final call.
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev