Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 09/08/14 05:09, Russell Bryant wrote:

On 08/06/2014 01:41 PM, Jay Pipes wrote:

On 08/06/2014 01:40 AM, Tom Fifield wrote:

On 06/08/14 13:30, Robert Collins wrote:

On 6 August 2014 17:27, Tom Fifield t...@openstack.org wrote:

On 06/08/14 13:24, Robert Collins wrote:



What happened to your DB migrations then? :)



Sorry if I misunderstood, I thought we were talking about running VM
downtime here?


While DB migrations are running things like the nova metadata service
can/will misbehave - and user code within instances will be affected.
Thats arguably VM downtime.

OTOH you could define it more narrowly as 'VMs are not powered off' or
'VMs are not stalled for more than 2s without a time slice' etc etc -
my sense is that most users are going to be particularly concerned
about things for which they have to *do something* - e.g. VMs being
powered off or rebooted - but having no network for a short period
while vifs are replugged and the overlay network re-establishes itself
would be much less concerning.


I think you've got it there, Rob - nicely put :)

In many cases the users I've spoken to who are looking for a live path
out of nova-network on to neutron are actually completely OK with some
API service downtime (metadata service is an API service by their
definition). A little 'glitch' in the network is also OK for many of
them.

Contrast that with the original proposal in this thread (snapshot VMs
in old nova-network deployment, store in Swift or something, then launch
VM from a snapshot in new Neutron deployment) - it is completely
unacceptable and is not considered a migration path for these users.


Who are these users? Can we speak with them? Would they be interested in
participating in the documentation and migration feature process?


Yes, I'd really like to see some participation in the development of a
solution if it's an important requirement.  Until then, it feels like a
case of an open question of what do you want.  Of course the answer is
a pony.



... and this is exactly why ...raising this concept only on a 
development mailing list is a bad idea


If anyone is serious about not providing a proper migration path for 
these users that need it, there is a need to be yelling this for 
probably a few of summits in a row and every OpenStack event we have in 
between, as well as the full gamut of periodic surveys, blogs, twitters, 
weibos, linkedins, facebooks etc,


So, get cracking :)


Regards,


Tom


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

Re: [openstack-dev] Which program for Rally

[Tom Fifield]

On 13/08/14 19:55, Boris Pavlovic wrote:
 Matt, 
 
 
 On Mon, Aug 11, 2014 at 07:06:11PM -0400, Zane Bitter wrote:
  On 11/08/14 16:21, Matthew Treinish wrote:
  I'm sorry, but the fact that the
  docs in the rally tree has a section for user testimonials [4] I feel 
 speaks a
  lot about the intent of the project.
 
 
 Yes, you are absolutely right it speaks a lot about the intent of the
 project. 
 
 One of the goal of Rally is to be the bridge between Operators and
 OpenStack community. 

Just throwing something out of left field here, but since the purpose of
the User Committee is basically that, maybe there's something to be
investigated there ...

Regards,


Tom

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

Re: [openstack-dev] Contact information required for ICLA -- getting a server error

[Tom Fifield]

On 18/08/14 19:01, Udi Kalifon wrote:
 Hi.
 
 I am trying to update my contact information in order to submit my first 
 gerrit review. I go to review.openstack.org and log in, then go to my account 
 settings and click on Contact Information. I provide my address and click 
 Save Changes and get:
 
 Code Review - Error
 Server Error
 Cannot store contact information
 
 This has been going on for 2 days already... Who is the admin responsible?
 
 Thanks in advance,
 Udi.

Hi Udi,

Sorry to hear you're having troubles!

One of the most common causes of this error is that the email address
you entered in your OpenStack Foundation profile does not match the
Preferred Email you set in Gerrit.

Can you double check this and get back to us if it works/doesn't work?



FAQ Link:
https://wiki.openstack.org/wiki/CLA-FAQ#When_trying_to_sign_the_new_ICLA_and_include_contact_information.2C_why_am_I.27m_getting_an_error_message_saying_that_my_E-mail_address_doesn.27t_correspond_to_a_Foundation_membership.3F



Regards,


Tom


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

Re: [openstack-dev] Criteria for giving a -1 in a review

[Tom Fifield]

On 22/08/14 00:40, Adam Young wrote:
 On 08/21/2014 12:21 PM, Daniel P. Berrange wrote:
 On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
 I would prefer that you didn't merge this.

 i.e. The project is better off without it.
 A bit off topic, but I've never liked this message that gets added
 as it think it sounds overly negative. It would better written
 as

This patch needs further work before it can be merged
 Excellent.


Clark has helpfully created a patch that would facilitate this change:

https://review.openstack.org/#/c/116176


Regards,


Tom

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

Re: [openstack-dev] [all] webnumbr bug graphs appear dead for bug triage

[Tom Fifield]

On 10/09/14 22:51, Sean Dague wrote:
 All the various bug triage graphs point out to webnumbr urls from our
 wiki - https://wiki.openstack.org/wiki/BugTriage
 
 All of webnumbr appears to be dead and not returning any data.
 
 Why this service was used predates me. Does anyone know why? Anyone know
 if it's going to come back? Or should we just purge those links?

Not sure why it was used either, but it has been very flaky for quite a
while. The most recent downtime has been the longest, and I believe we
should indeed use another service to replace webnumbr. I think we
already have similar graphs from bugday
(http://status.openstack.org/bugday/), but only for one day, and/or the
activity portal (http://activity.openstack.org/dash/browser/its-repos.html).


Regards,


Tom



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

Re: [openstack-dev] [all] Design Summit planning

[Tom Fifield]

On 18/09/14 16:03, Thierry Carrez wrote:
 Maish Saidel-Keesing wrote:
 On 17/09/2014 23:12, Anita Kuno wrote:
 On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote:
 This looks great - but I am afraid that something might be missing.

 As part of the Design summit in Atlanta there was an Ops Meetup track.
 [1] I do not see where this fits into the current planning process that
 has been posted.
 I would like to assume that part of the purpose of the summit is to also
 collect feedback from Enterprise Operators and also from smaller ones as
 well.

 If that is so then I would kindly request that there be some other way
 of allowing that part of the community to voice their concerns, and
 provide feedback.

 Perhaps a track that is not only Operator centric - but also an End-user
 focused one as well (mixing the two would be fine as well)

 Most of them are not on the openstack-dev list and they do not
 participate in the IRC team meetings, simply because they have no idea
 that these exist or maybe do not feel comfortable there. So they will
 not have any exposure to the process.

 My 0.02 Shekels.

 [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup

 Hi Maish:

 This thread is about the Design Summit, the Operators Track is a
 different thing.

 In Atlanta the Operators Track was organized by Tom Fifield and I have
 every confidence he is working hard to ensure the operators have a voice
 in Paris and that those interested can participate.

 Last summit the Operators Track ran on the Monday and the Friday giving
 folks who usually spend most of the time at the Design summit to
 participate and hear the operator's voices. I know I did and I found it
 highly educational.

 Thanks,
 Anita.
 Thanks for the clarification Anita :)
 
 I think the plan is to have the Ops summit run on Monday, with an extra
 day on Thursday to continue the discussions. I CCed Tom for more input
 on that.


Sorry for the delay all, and thanks for the kind notes. The ops meetup
will indeed return in Paris. Standby for details and planning etherpad
any day now - on the openstack-operators mailing list.


Regards,


Tom


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

Re: [openstack-dev] [Openstack] Friday Dec 20th - Doc Bug Day

[Tom Fifield]

Reminder: Friday next week - Doc Bug Day.

Current number of doc bugs: 505

On 22/11/13 11:27, Tom Fifield wrote:
 All,
 
 This month, docs reaches 500 bugs, making it the 2nd-largest project by
 bug count in all of OpenStack. Yes, it beats Cinder, Horizon, Swift,
 Keystone and Glance, and will soon surpass Neutron.
 
 In order to start the new year in a slightly better state, we have
 arranged a bug squash day:
 
 
 Friday, December 20th
 
 
 https://wiki.openstack.org/wiki/Documentation/BugDay
 
 
 Join us in #openstack-doc whenever you get to your computer, and let's
 beat the bugs :)
 
 
 For those who are unfamiliar:
 Bug days are a day-long event where all the OpenStack community focuses
 exclusively on a task around bugs corresponding to the bug day topic.
 With so many community members available around the same task, these
 days are a great way to start joining the OpenStack community.
 
 
 Regards,
 
 
 Tom
 
 ___
 Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


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

Re: [openstack-dev] [bugs] definition of triaged

[Tom Fifield]

On 13/12/13 19:13, Thierry Carrez wrote:
 Robert Collins wrote:
 
 Confirmed The bug was reproduced or confirmed as a genuine bug
 Triaged The bug comments contain a full analysis on how to properly
 fix the issue
 

 From wiki.openstack.org/wiki/Bugs

 Putting aside the difficulty of complete reproduction sometimes, I
 don't understand the use of Triaged here.

 In LP they mean:

 Confirmed Verified by someone other than the reporter.
 Triaged Verified by the bug supervisor.

 So our meaning is very divergent. I'd like us to consolidate on the
 standard meaning - which is that the relative priority of having a
 doctor [developer] attack the problem has been assessed.
 
 I'm the one who established, a long time ago, this divergence between
 Launchpad's classic use of those statuses and OpenStack's. In my
 experience NOBODY ever uses Confirmed with the LP meaning, so I
 figured we should use it for something more useful: to describe how
 advanced you are in the resolution of the issue.
 
 This is why I proposed (and we used) the following distinction, as
 described in https://wiki.openstack.org/wiki/BugTriage :
 
 Confirmed bugs are genuine bugs but nobody really looked into the best
 way to fix them yet. They are confirmed, priority-assigned, tagged
 
 Triaged bugs are bugs which are analyzed and have a clear way forward
 to resolve them, just missing someone to actually write the patch
 
 That way developers could pick ready to fix bugs by searching
 Triaged bugs rather than Confirmed ones.
 
 Specifically:
  - we should use Triaged to indicate that:
 - we have assigned a priority
 - we believe it's a genuine bug
 - we have routed[tagged] it to what is probably the right place
 [vendor driver/low-hanging-fruit etc]
  - we should use Incomplete if we aren't sure that its a bug and need
 the reporter to tell us more to be sure
  - triagers shouldn't ever set 'confirmed' - thats reserved solely for
 end users to tell us that more than one user is encountering the
 problem.
 
 I can see how that works for Ubuntu. But did you ever see, in OpenStack,
 an end user tell us that they /also encountered/ the problem ?
 
 The end result of your proposal is that we stop using Confirmed and
 use Triaged instead (to describe the exact same thing). We lose the
 ability to use Triaged to indicate a more analyzed state. I'm not
 sure that's a net win, or worth asking anyone to change their habits, or
 worth changing the BugTriage wikipage (and/or any other page that
 repeated it).
 
 I'll gladly admit that my meaning of Triaged was not used that much
 and that it could be replaced by something more useful. But merely using
 triaged for our old meaning of confirmed (and stop using
 confirmed) sounds like change for the sake of change.

Just want to back Thierry here - find the current Triaged/Confirmed
distinction quite useful.

In the documentation case, Triaged often means that there's a note of
which files to edit and/or has text included in the bug or linked to
somewhere that can be used to write the content needed. This exactly
matches with:

 Triaged bugs are bugs which are analyzed and have a clear way forward
 to resolve them, just missing someone to actually write the patch

and it appears to be working well for facilitating the long tail
contributors, who might just drop by for a patch or two.

Sometimes, we can work out that the issue is real but it might be a
particularly complex fix across multiple books, or need a developer's
input to work out what the actual behaviour should be. These get set as
'confirmed' during the Triage process.

Like others have noted, I've not seen cases where users have marked bugs
as 'confirmed'. Even our tamer in-community operators tend to wait for a
TriagePerson to set it to 'confirmed' - and this is for mere typos in
docs :)

I guess, in short - I'm not sure there's an issue on 'triaged' vs
'confirmed'?

Though, the idea in later emails than this that existing bugs should be
looked at only once or twice a cycle worries me :) I'll leave that for
the more wisened to debate for now ...


Regards,



Tom










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

Re: [openstack-dev] [Openstack] Today - Doc Bug Day

[Tom Fifield]

Reminder: Doc Bug Day is today.

On 13/12/13 08:16, Tom Fifield wrote:
 Reminder: Friday next week - Doc Bug Day.
 
 Current number of doc bugs: 505
 
 On 22/11/13 11:27, Tom Fifield wrote:
 All,

 This month, docs reaches 500 bugs, making it the 2nd-largest project by
 bug count in all of OpenStack. Yes, it beats Cinder, Horizon, Swift,
 Keystone and Glance, and will soon surpass Neutron.

 In order to start the new year in a slightly better state, we have
 arranged a bug squash day:


 Friday, December 20th


 https://wiki.openstack.org/wiki/Documentation/BugDay


 Join us in #openstack-doc whenever you get to your computer, and let's
 beat the bugs :)


 For those who are unfamiliar:
 Bug days are a day-long event where all the OpenStack community focuses
 exclusively on a task around bugs corresponding to the bug day topic.
 With so many community members available around the same task, these
 days are a great way to start joining the OpenStack community.


 Regards,


 Tom

 ___
 Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 
 
 ___
 Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openst...@lists.openstack.org
 Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 


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

[openstack-dev] Status of nova-network deprecation

[Tom Fifield]

Hi all,

It's a couple of weeks out from the slated decision milestone 
(icehouse-2) to potentially deprecate nova-network. Since I guess 
there's still time to affect this outcome, but I haven't seen much 
communication recently, here's a thread!



I think a series of beautiful write-ups could help inform this decision, 
perhaps some/all of these (taken from survey results, and previous 
mailing list discussion):


* How to use neutron to achieve FlatDHCP Multi-Host HA (eg 
https://wiki.openstack.org/wiki/NovaNetNeutronRecipes#Every_compute_node_also_a_network_controller)


* How to migrate from an existing nova-network installation to Neutron

* A performance comparison of nova-network and neutron of some kind

* Addressing the progress on the pain points discussed at the summit: 
usability, complexity and reliability 
(https://etherpad.openstack.org/p/icehouse-summit-neutron-pain-points)


* How neutron has improved in terms of providing simple solutions for 
simple use cases



= Does anyone have any time to inform about these points, or any other 
salient ones?



Regards,


Tom

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

Re: [openstack-dev] [stackalytics] Pull request on default_data.json (addition of a domain)

[Tom Fifield]

Hi Fukuda san,

You will probably receive an automated message like this soon, but:

stackforge/stackalytics uses Gerrit for code review, and does not accept 
pull requests on github.


To commit your change, you will need to follow the instructions on the 
OpenStack Gerrit Workflow: https://wiki.openstack.org/wiki/GerritWorkflow


Please let us know if you require any assistance.


Regards,


Tom

On 27/02/14 10:05, Fukuda, Yuko wrote:

Hi,

I want to add the domain of my email address onto the
stackalytics default_data.json file.

I have made the necessary additions, and created patch-1.
Can someone with the credentials approve and merge?
(my ID is fukuday)

Thanks in advance,

Yuko


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




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

[openstack-dev] [glance] Switching from sql_connection to [database] connection ?

[Tom Fifield]

Hi,

As best I can tell, all other services now use this syntax for 
configuring database connections:


[database]
connection = sqlite:///etc,omg


whereas glance appears to still use

[DEFAULT]
...
sql_connection = sqlite:///etc,omg


Is there a plan to switch to the former during Icehouse development?

From a user standpoint it'd be great to finally have consistency 
amoungst all the services :)



Regards,


Tom

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

Re: [openstack-dev] [Neutron] Docs for new plugins

[Tom Fifield]

On 13/03/14 13:43, Mohammad Banikazemi wrote:

Thanks for your response.

It looks like the page you are referring to gets populated automatically
and I see a link already added to it for the new plugin. I also see a
file corresponding to the new plugin having been created and populated
with the plugin config options in the latest openstack-manuals cloned
from github.

After talking to the docs people on #openstack-docs, now I know that
these files get created automatically and periodically. Any changes to
the docs should come through changes to the config file in the code
which will be automatically picked up at some point when the docs
scripts get executed.


Just to clarify one point - the text comes from the code, in the oslo 
option registration's helptext, not from the configuration files in etc.



It looks like there is nothing to be done in this front for adding the
docs for the new plugin. If that seems reasonable, I will close the bug
I had opened for the the docs for our plugin.

Thanks,

-Mohammad





Inactive hide details for Edgar Magana ---03/12/2014 06:10:31 PM---You
should be able to add your plugin here: http://docs.openEdgar Magana
---03/12/2014 06:10:31 PM---You should be able to add your plugin here:
http://docs.openstack.org/havana/config-reference/conten

From: Edgar Magana emag...@plumgrid.com
To: Mohammad Banikazemi/Watson/IBM@IBMUS, OpenStack Development Mailing
List (not for usage questions) openstack-dev@lists.openstack.org,
Date: 03/12/2014 06:10 PM
Subject: Re: [openstack-dev] [Neutron] Docs for new plugins





You should be able to add your plugin here:
_http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html_

Thanks,

Edgar

*From: *Mohammad Banikazemi _...@us.ibm.com_ mailto:m...@us.ibm.com*
Date: *Monday, March 10, 2014 2:40 PM*
To: *OpenStack List _openstack-dev@lists.openstack.org_
mailto:openstack-dev@lists.openstack.org*
Cc: *Edgar Magana _emagana@plumgrid.com_ mailto:emag...@plumgrid.com*
Subject: *Re: [openstack-dev] [Neutron] Docs for new plugins

Would like to know what to do for adding documentation for a new plugin.
Can someone point me to the right place/process please.

Thanks,

Mohammad



___
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] Operators Design Summit ideas for Atlanta

[Tom Fifield]

All,

Many times we've heard a desire for more feedback and interaction from 
users. However, their attendance at design summit sessions is met with 
varied success.


However, last summit, by happy accident, a swift session turned into a 
something a lot more user driven. A competent user was able to describe 
their use case, and the developers were able to stage a number of 
question to them. In this way, some of the assumptions about the way 
certain things were implemented, and the various priorities of future 
plans became clearer. It worked really well ... perhaps this is 
something we'd like to have happen for all the projects?


*Idea*: Add an ops session for each project in the design summit
https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


Most operators running OpenStack tend to treat it more holistically than 
those coding it. They are aware of, but don't necessarily think or work 
in terms of project  breakdowns. To this end, I'd imagine the such 
sessions would:


 * have a primary purpose for developers to ask the operators to answer
   questions, and request information

 * allow operators to tell the developers things (give feedback) as a
   secondary purpose that could potentially be covered better in a
   cross-project session

 * need good moderation, for example to push operator-to-operator
   discussion into forums with more time available (eg
   https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

 * be reinforced by having volunteer good users in potentially every
   design summit session
   (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


Anyway, just a strawman - please jump on the etherpad 
(https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions) 
or leave your replies here!



Regards,


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

Re: [openstack-dev] [all] sample config files should be ignored in git...

[Tom Fifield]

On 28/03/14 04:58, Joe Gordon wrote:




On Thu, Mar 27, 2014 at 1:11 PM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:

On 03/27/2014 02:54 PM, Joe Gordon wrote:
 
 
 
  On Thu, Mar 27, 2014 at 2:21 AM, Dirk Müller d...@dmllr.de
mailto:d...@dmllr.de
  mailto:d...@dmllr.de mailto:d...@dmllr.de wrote:
 
  Hi,
 
   When I was an operator, I regularly referred to the sample
config
  files
   in the git repository.
 
  The sample config files in git repository are tremendeously
useful for
  any operator and OpenStack Packager. Having them generateable
with a
  tox line is very cumbersome.
 
 
  Why is it cumbersome? We do the same thing.

Because we've already got a working tox environment. Which includes
knowing, in advance that you can't just pip install tox (as 1.7.x is
broken), and that you need to have postgresql and mysql and libffi dev
packages installed, and a C compiler.

Start with a pristine Linux it is a lot manual steps you have to go
through to get a working config out of tox -e genconfig.

So I think it's a fair concern that we did just move a burden back onto
users because we dug a hole by letting libraries declare arbitrary
required variables in our config files.


Good answer.


+1


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

Re: [openstack-dev] Operators Design Summit ideas for Atlanta

[Tom Fifield]

Thanks to those projects that responded. I've proposed sessions in 
swift, ceilometer, tripleO and horizon.


On 17/03/14 07:54, Tom Fifield wrote:

All,

Many times we've heard a desire for more feedback and interaction from
users. However, their attendance at design summit sessions is met with
varied success.

However, last summit, by happy accident, a swift session turned into a
something a lot more user driven. A competent user was able to describe
their use case, and the developers were able to stage a number of
question to them. In this way, some of the assumptions about the way
certain things were implemented, and the various priorities of future
plans became clearer. It worked really well ... perhaps this is
something we'd like to have happen for all the projects?

*Idea*: Add an ops session for each project in the design summit
https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


Most operators running OpenStack tend to treat it more holistically than
those coding it. They are aware of, but don't necessarily think or work
in terms of project  breakdowns. To this end, I'd imagine the such
sessions would:

  * have a primary purpose for developers to ask the operators to answer
questions, and request information

  * allow operators to tell the developers things (give feedback) as a
secondary purpose that could potentially be covered better in a
cross-project session

  * need good moderation, for example to push operator-to-operator
discussion into forums with more time available (eg
https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

  * be reinforced by having volunteer good users in potentially every
design summit session
(https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


Anyway, just a strawman - please jump on the etherpad
(https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions)
or leave your replies here!


Regards,


Tom


___
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] [glance] Switching from sql_connection to [database] connection ?

[Tom Fifield]

On 27/02/14 18:47, Flavio Percoco wrote:

On 27/02/14 12:12 +0800, Tom Fifield wrote:

Hi,

As best I can tell, all other services now use this syntax for
configuring database connections:

[database]
connection = sqlite:///etc,omg


whereas glance appears to still use

[DEFAULT]
...
sql_connection = sqlite:///etc,omg


Is there a plan to switch to the former during Icehouse development?

From a user standpoint it'd be great to finally have consistency
amoungst all the services :)


It already did. It looks like the config sample needs to be updated.

To be more precise, `sql_connection` is marked as deprecated.[0]

[0]
https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/session.py#L329




Just noting that the sample config has still not been updated.


Regards,


Tom


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

[openstack-dev] Doc to with pointers on how to review?

[Tom Fifield]

Hi,

Just wondering, do we have a document somewhere that educates people on 
how to do a code review? eg giving a few pointers that reviewers for a 
particular project normally look for


So far everything I've seen (aside from 
https://wiki.openstack.org/wiki/GerritJenkinsGit#Reviewing_a_Change) is 
written from the perspective of how the review process works when you're 
submitting a patch and others are reviewing your code.


However, it's early in the morning and it's likely my google-fu is at 
low levels ... perhaps such a doc exists? Maybe on a blog somewhere?



Regards,


Tom

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

Re: [openstack-dev] Doc to with pointers on how to review?

[Tom Fifield]

On 31/03/14 12:24, Ruslan Kamaldinov wrote:

On Mon, Mar 31, 2014 at 5:57 AM, Tom Fifield t...@openstack.org wrote:

Hi,

Just wondering, do we have a document somewhere that educates people on how
to do a code review? eg giving a few pointers that reviewers for a
particular project normally look for


Hi Tom,

The closest to your description document is:
https://wiki.openstack.org/wiki/ReviewChecklist


Thanks! That's just what I was looking for :)

Now to link to it from everywhere...

Regards,

Tom


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

Re: [openstack-dev] bug/129135

[Tom Fifield]

Yes, that does seem odd.

See also related Documentation bugs and patch:

https://bugs.launchpad.net/openstack-manuals/+bug/1273412
https://review.openstack.org/#/c/81858/

Regards,

Tom

On 01/04/14 03:42, Nathanael Burton wrote:

Also, how does this work for RHEL-based distros where they tend to
backport new kernel features?  For instance vxlan support was added in
the kernel for RHEL6.5 which is 2.6.32-based...  That changeset looks
like it breaks Neutron for ovs + vxlan on RHEL distros.

Nate


On Mon, Mar 31, 2014 at 1:07 PM, sowmini.varad...@hp.com
mailto:sowmini.varad...@hp.com wrote:


openstack-dev,

A question about the fix from https://review.openstack.org/#/c/82931

After this fix, the neutron code now explicitly checks for kernel
version 3.13- was this deliberate? (I was using an older 3.11 version
before, and did not seem to have any issues before this change).

Is there a specific kernel patch that ovs-vxlan is dependant on?

Thanks
Sowmini

___
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

Re: [openstack-dev] [glance] Switching from sql_connection to [database] connection ?

[Tom Fifield]

Since it's missed RC1, I'm guessing that this confusion to users will be 
ongoing for another six months ? :)


Regards,


Tom

On 30/03/14 23:24, Zhi Yan Liu wrote:

Hi

We have no plan to update sample template in I release for it, but
https://review.openstack.org/#/c/77379/ is on reviewing, IFY.

zhiyan

Sent from my iPad

On 2014年3月30日, at 13:04, Tom Fifield t...@openstack.org
mailto:t...@openstack.org wrote:


On 27/02/14 18:47, Flavio Percoco wrote:

On 27/02/14 12:12 +0800, Tom Fifield wrote:

Hi,

As best I can tell, all other services now use this syntax for
configuring database connections:

[database]
connection = sqlite:///etc,omg


whereas glance appears to still use

[DEFAULT]
...
sql_connection = sqlite:///etc,omg


Is there a plan to switch to the former during Icehouse development?

From a user standpoint it'd be great to finally have consistency
amoungst all the services :)


It already did. It looks like the config sample needs to be updated.

To be more precise, `sql_connection` is marked as deprecated.[0]

[0]
https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/session.py#L329




Just noting that the sample config has still not been updated.


Regards,


Tom


___
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

Re: [openstack-dev] [OpenStack][neutron][docs] netconn-api doc - adding a new chapter

[Tom Fifield]

Feel free to submit doc patches that don't build for review - docs 
reviewers are known to fix markup for you :)


On 04/04/14 11:11, Rajdeep Dua wrote:

I was trying to modify netconn-api docs with a new chapter.
Added a file in v2.0/ch_neutron_python_client.xml

modified:   v2.0/neutron-api-guide.xml by adding the following line

  xi:include href=ch_neutron_python_client.xml/

It gives a compilation error on executing mvn generate-sources

Details about the error

http://pastebin.com/LqTKb0Ct

Thanks
Rajdeep


___
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] Operators Design Summit ideas for Atlanta

[Tom Fifield]

So far, there's been no comment from anyone working on nova, so there's 
been no session proposed.


I can, of course, propose a session ... but without buy-in from the 
project team it's unlikely to be accepted.



Regards,


Tom


On 01/04/14 22:44, Matt Van Winkle wrote:

So, I've been watching the etherpad and the summit submissions and I
noticed that there isn't anything for nova.  Maybe I'm off base, but it
seems like we'd be missing the mark to not have a Developer/Operator's
exchange on the key product.  Is there anything we can do to get a session
slotted like these other products?

Thanks!
Matt

On 3/28/14 2:01 AM, Tom Fifield t...@openstack.org wrote:


Thanks to those projects that responded. I've proposed sessions in
swift, ceilometer, tripleO and horizon.

On 17/03/14 07:54, Tom Fifield wrote:

All,

Many times we've heard a desire for more feedback and interaction from
users. However, their attendance at design summit sessions is met with
varied success.

However, last summit, by happy accident, a swift session turned into a
something a lot more user driven. A competent user was able to describe
their use case, and the developers were able to stage a number of
question to them. In this way, some of the assumptions about the way
certain things were implemented, and the various priorities of future
plans became clearer. It worked really well ... perhaps this is
something we'd like to have happen for all the projects?

*Idea*: Add an ops session for each project in the design summit

https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


Most operators running OpenStack tend to treat it more holistically than
those coding it. They are aware of, but don't necessarily think or work
in terms of project  breakdowns. To this end, I'd imagine the such
sessions would:

   * have a primary purpose for developers to ask the operators to answer
 questions, and request information

   * allow operators to tell the developers things (give feedback) as a
 secondary purpose that could potentially be covered better in a
 cross-project session

   * need good moderation, for example to push operator-to-operator
 discussion into forums with more time available (eg
 https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

   * be reinforced by having volunteer good users in potentially every
 design summit session
 (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


Anyway, just a strawman - please jump on the etherpad

(https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-session
s)
or leave your replies here!


Regards,


Tom


___
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] Operators Design Summit ideas for Atlanta

[Tom Fifield]

If the timing works, that seems fine :)

Regards,


Tom

On 07/04/14 10:32, Michael Still wrote:

It might be that this is happening because there is no clear incumbent
for the Nova PTL position. Is it ok to hold off on this until after
the outcome of the election is known?

Michael

On Mon, Apr 7, 2014 at 2:23 PM, Tom Fifield t...@openstack.org wrote:

So far, there's been no comment from anyone working on nova, so there's been
no session proposed.

I can, of course, propose a session ... but without buy-in from the project
team it's unlikely to be accepted.


Regards,


Tom



On 01/04/14 22:44, Matt Van Winkle wrote:


So, I've been watching the etherpad and the summit submissions and I
noticed that there isn't anything for nova.  Maybe I'm off base, but it
seems like we'd be missing the mark to not have a Developer/Operator's
exchange on the key product.  Is there anything we can do to get a session
slotted like these other products?

Thanks!
Matt

On 3/28/14 2:01 AM, Tom Fifield t...@openstack.org wrote:


Thanks to those projects that responded. I've proposed sessions in
swift, ceilometer, tripleO and horizon.

On 17/03/14 07:54, Tom Fifield wrote:


All,

Many times we've heard a desire for more feedback and interaction from
users. However, their attendance at design summit sessions is met with
varied success.

However, last summit, by happy accident, a swift session turned into a
something a lot more user driven. A competent user was able to describe
their use case, and the developers were able to stage a number of
question to them. In this way, some of the assumptions about the way
certain things were implemented, and the various priorities of future
plans became clearer. It worked really well ... perhaps this is
something we'd like to have happen for all the projects?

*Idea*: Add an ops session for each project in the design summit


https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


Most operators running OpenStack tend to treat it more holistically than
those coding it. They are aware of, but don't necessarily think or work
in terms of project  breakdowns. To this end, I'd imagine the such
sessions would:

* have a primary purpose for developers to ask the operators to
answer
  questions, and request information

* allow operators to tell the developers things (give feedback) as a
  secondary purpose that could potentially be covered better in a
  cross-project session

* need good moderation, for example to push operator-to-operator
  discussion into forums with more time available (eg
  https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

* be reinforced by having volunteer good users in potentially every
  design summit session
  (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


Anyway, just a strawman - please jump on the etherpad


(https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-session
s)
or leave your replies here!


Regards,


Tom


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




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




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




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







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

Re: [openstack-dev] Havana RC1 available in the Ubuntu Cloud Archive for 12.04

[Tom Fifield]

Thanks James!!

On 11/10/13 23:47, James Page wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Folks

I've just finishing promoting all of the Havana RC1 packages and
associated dependencies to the Ubuntu Cloud Archive for Ubuntu 12.04 LTS.

For details of how to use the Ubuntu Cloud Archive for Havana, please
refer to:

   https://wiki.ubuntu.com/ServerTeam/CloudArchive

The latest packages are all now in the updates pocket (they have been
kicking around in proposed for a few days now - we where just waiting
on Swift so that we could complete final smoke testing).

You can track which versions of what are where here:


http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/havana_versions.html

Please use the 'ubuntu-bug' tool to report bugs back to Launchpad, for
example:

   ubuntu-bug nova-compute

This will log the bug against the right project in launchpad and
collect some basic information about which versions of packages you
are using.

Enjoy

James

- --
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSV/NHAAoJEL/srsug59jDT+UP/R7EJcOW63KS7l33/7+GFtuu
vAIYP/WAlUgC6ShUDD2TfFvKFCQ7HA7Ctw5qB5MjvTBH8ZV43/IDiYaww0gyq6ah
BIWmiJhu+6Vq/KRb93fYenpDPV5oFnCy5jbtZnN6DmwEsCcYPanzI9GToyLDxR1n
dzTO6im3HCcm55j+cAd3ehCmkcy4GHk+5pJqKtssGRCKHaRTl2YJ3XaGKTDlDFj1
P967dJFeWr/b3AJif7siKapJSOoJH5wvhwmaEu44bkRfZp8kOdEIEXP19fJKchZi
+TdNyyjf1DWJcMTdHxEbDJ+oCH7bfehekqhg0y8Y2ASdkuhbntjXEEVS9Zaj1m3F
GVTeM/dvumG4YYdAWllF/9i480frifBr7s/5QyTR63seOOBgyb8PRWanDqv8+OGk
4VP6km+U4Q2fO3BsD04YhR0NAcV0wZvc8B2Hn+ut+mdsxLellMhlgew//S/Jj6SW
ict/xuw7bXgHk3ROtnT48WOBEoNxqKxlZA+WntFzn5d4lbqpR2HuLXCtOOU6m1Jy
QDjBAwpQ1V8Bu1qI2ZiVT55S8YhU1EMLRqO4E85Wg/SstemXLj4jC8jTMi5c3hWl
wHMCmJhLZMLq3N2b4ojKmYSlfvfXwGyhSr9hvtJSol8dhRpGw+meVUc2eWeCc7kz
9E7YADmdKW1DTUx+KHbI
=VLr+
-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

[openstack-dev] Doc Team meeting - in an hour

[Tom Fifield]

Hi all,

The OpenStack Doc team meeting will take place in #openstack-meeting on 
IRC at 13:00 UTC - about an hour from now. The Agenda is here:


https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting


Please add items of interest to you and join us.


Regards,


Tom

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

Re: [openstack-dev] [Nova] Blueprint review process

[Tom Fifield]

On 30/10/13 07:58, Russell Bryant wrote:

On 10/29/2013 04:24 PM, Stefano Maffulli wrote:

On 10/28/2013 10:28 AM, Russell Bryant wrote:

2) Setting clearer expectations.  Since we have so many blueprints for
Nova, I feel it's very important to accurately set expectations for how
the priority of different projects compare.  In the last cycle,
priorities were mainly subjectively set by me.  Setting priorities based
on what reviewers are willing to spend time on is a more accurate
reflection of the likelihood of a set of changes making it in to the
release.


I'm all for managing expectations :) I had a conversation with Tom about
this and we agreed that there may be a risk that new contributors with
not much karma in the project would have a harder time getting their
blueprint assigned higher priorities. If a new group proposes a
blueprint, they may need to court bp reviewers to convince them to
dedicate attention to their first bp. The risk is that the reviewers of
Blueprints risk of becoming a sort of gatekeeper, or what other projects
call 'committers'.

I think this is a concrete risk, it exists but I don't know if it's
possible to eliminate it. I don't think we have to eliminate it but we
need to manage it to minimize it in order to keep our promise of being
'open' as in open to new contributors, even the ones with low karma.

What do you think?


I think you're right, but it's actually no different than things have
been in the past.  It's just blueprints better reflecting how things
actually work.



However, people that have a proven track record of producing high
quality work are going to have an easier time getting attention, because
it takes less work overall to get their patches in.  With that said, if
the blueprint is good, it should get priority based on its merit, even
if the submitter has lower karma in the community.

Where we seem to hit the most friction is actually when merit alone
doesn't grant higher priority (only relevant to a small number of users,
for example), and submitter hasn't built up karma, either.  Those are
the ones that have a hard time, but it's not that surprising.


The user committee might be able to help here. Through the user survey, 
and engagement with communities around the world, they have an idea of 
what affects what number of users and how.


So, how would you feel about giving some priority manipulation abilities 
to the user committee? :)



Regards,


Tom







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

Re: [openstack-dev] [Nova] Blueprint review process

[Tom Fifield]

On 30/10/13 17:14, Russell Bryant wrote:

On 10/29/2013 07:14 PM, Tom Fifield wrote:

On 30/10/13 07:58, Russell Bryant wrote:

On 10/29/2013 04:24 PM, Stefano Maffulli wrote:

On 10/28/2013 10:28 AM, Russell Bryant wrote:

2) Setting clearer expectations.  Since we have so many blueprints for
Nova, I feel it's very important to accurately set expectations for how
the priority of different projects compare.  In the last cycle,
priorities were mainly subjectively set by me.  Setting priorities
based
on what reviewers are willing to spend time on is a more accurate
reflection of the likelihood of a set of changes making it in to the
release.


I'm all for managing expectations :) I had a conversation with Tom about
this and we agreed that there may be a risk that new contributors with
not much karma in the project would have a harder time getting their
blueprint assigned higher priorities. If a new group proposes a
blueprint, they may need to court bp reviewers to convince them to
dedicate attention to their first bp. The risk is that the reviewers of
Blueprints risk of becoming a sort of gatekeeper, or what other projects
call 'committers'.

I think this is a concrete risk, it exists but I don't know if it's
possible to eliminate it. I don't think we have to eliminate it but we
need to manage it to minimize it in order to keep our promise of being
'open' as in open to new contributors, even the ones with low karma.

What do you think?


I think you're right, but it's actually no different than things have
been in the past.  It's just blueprints better reflecting how things
actually work.

However, people that have a proven track record of producing high
quality work are going to have an easier time getting attention, because
it takes less work overall to get their patches in.  With that said, if
the blueprint is good, it should get priority based on its merit, even
if the submitter has lower karma in the community.

Where we seem to hit the most friction is actually when merit alone
doesn't grant higher priority (only relevant to a small number of users,
for example), and submitter hasn't built up karma, either.  Those are
the ones that have a hard time, but it's not that surprising.


The user committee might be able to help here. Through the user survey,
and engagement with communities around the world, they have an idea of
what affects what number of users and how.

So, how would you feel about giving some priority manipulation abilities
to the user committee? :)


Abilities, no, but input, of course.


Any practical ideas on the best way to make that work for you?

___
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

[Tom Fifield]

On 15/11/13 02:40, Chmouel Boudjnah wrote:
 
 On Thu, Nov 14, 2013 at 2:22 PM, Julien Danjou jul...@danjou.info
 mailto:jul...@danjou.info wrote:
 
  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.
 
 Good suggestion.
 
 
 Or this can be moved to the announcement list?

It's my impression that the announce list has a different purpose than
such mundane things as weekly meeting reminders :)

Announces about OpenStack new releases, stable releases and security
advisories

I'd think that based on the description (and in some sense how we've
communicated it) that list would be quite low traffic - like 1-2
messages per month.


However, do  you think an devel-announce or meeting-announce list would
be valuable?


Regards,


Tom

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

Re: [openstack-dev] RFC: Potential to increase min required libvirt version to 0.9.8 ?

[Tom Fifield]

On 20/11/13 14:33, Robert Collins wrote:

On 20 November 2013 08:02, Daniel P. Berrange berra...@redhat.com wrote:

Currently the Nova libvirt driver is declaring that it wants a minimum
of libvirt 0.9.6.

...

If there are other distros I've missed which expect to support deployment
of Icehouse please add them to this list. Hopefully there won't be any
with libvirt software older than Ubuntu 12.04 LTS


The reason I'm asking this now, is that we're working to make the libvirt
python module a separate tar.gz that can build with multiple libvirt
versions, and I need to decide how ancient a libvirt we should support
for it.


Fantastic!!!

The Ubuntu cloud archive
https://wiki.ubuntu.com/ServerTeam/CloudArchive is how OpenStack is
delivered by Canonical for Ubuntu LTS users. So I think you can go
with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say.


Just confirming that the documentation for Ubuntu sets users up with the 
Cloud Archive. In Havana, Libvirt is 1.1.1 and qemu is 1.5.0. I've added 
a row to the table.


Regards,

Tom


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

[openstack-dev] OFF TOPIC Re: Image without host-id

[Tom Fifield]

On 20/11/13 15:43, Santosh Kumar wrote:

I am following Havana guide for creating three node set up.

Everything has been installed and configured.

However not able to create network for VMs , That's why when creating VM .. 
they come out be without host-id ( VM gets lauch ).

#Nova network-create , is not working for me. Any pointer for the same.



Hi Santosh,

Thank you for supporting OpenStack.

Unfortunately, this discussion is OFF TOPIC on this list.

This list for the developers of OpenStack to discuss development issues
and roadmap.

It is focused on the next release of OpenStack: you should post on this
list if you are a contributor to OpenStack or are very familiar with
OpenStack development and want to discuss very precise topics,
contribution ideas and similar. Do not ask support requests on this
list.

Please move the discussion to the General mailing list
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack or
https://ask.openstack.org

Regards,

Tom

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

Re: [openstack-dev] Propose project story wiki idea

[Tom Fifield]

Love the idea Boris - a nice read :)

Regards,

Tom

On 20/11/13 16:45, Michael Bright wrote:

+1


On 20 November 2013 06:33, Boris Pavlovic bpavlo...@mirantis.com
mailto:bpavlo...@mirantis.com wrote:

Hi stackers,


Currently what I see is growing amount of interesting projects, that
at least I would like to track. But reading all mailing lists, and
reviewing all patches in all interesting projects to get high level
understanding of what is happing in project now, is quite hard or
even impossible task (at least for me). Especially after 2 weeks
vacation =)


The idea of this proposal is that every OpenStack project should
have story wiki page. It means to publish every week one short
message that contains most interesting updates for the last week,
and high level road map for future week. So reading this for 10-15
minutes you can see what changed in project, and get better
understanding of high level road map of the project.

E.g. we start doing this in Rally:
https://wiki.openstack.org/wiki/Rally/Updates


I think that the best way to organize this, is to have person (or
few persons) that will track all changes in project and prepare such
updates each week.



Best regards,
Boris Pavlovic
--
Mirantis Inc.

___
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] Friday Dec 20th - Doc Bug Day

[Tom Fifield]

All,

This month, docs reaches 500 bugs, making it the 2nd-largest project by 
bug count in all of OpenStack. Yes, it beats Cinder, Horizon, Swift, 
Keystone and Glance, and will soon surpass Neutron.


In order to start the new year in a slightly better state, we have 
arranged a bug squash day:



Friday, December 20th


https://wiki.openstack.org/wiki/Documentation/BugDay


Join us in #openstack-doc whenever you get to your computer, and let's 
beat the bugs :)



For those who are unfamiliar:
Bug days are a day-long event where all the OpenStack community focuses 
exclusively on a task around bugs corresponding to the bug day topic. 
With so many community members available around the same task, these 
days are a great way to start joining the OpenStack community.



Regards,


Tom

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

Re: [openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.

[Tom Fifield]

On 05/12/13 01:14, Brent Eagles wrote:
 Hi,
 
 As part of the Icehouse nova-networking parity effort, we need to
 describe how nova-networking managers work and how the behavior is
 mapped to neutron. The benefits are:
 
 1. It aides migration: deployers who are nova-network savvy can see how
 functionality maps from one to the other.
 
 2. It aides implementation: if we cannot provide a mapping, there is a
 breakage in parity and it needs to be addressed somehow.
 
 3. It aides testing (and debugging): by illuminating points where the
 implementations differ, it makes it easier to design and implement tests
 that can be expected to function the same for each networking
 implementation.
 
 4. It aides acceptance: at some point, the proverbial *we* are going to
 decide whether neutron is ready to replace nova. The existence of
 working recipes is a pretty strong set of acceptance criteria.  Another
 way to look at it is that the recipes are essentially a high level
 description of how to go about manually testing parity.
 
 5. It aides support and documentation efforts: nearly any point in the
 openstack user spectrum (casual experimenter to hard-core
 developer/implementer) who has anything to do with legacy deployments or
 parity itself will benefit from having these recipes on hand. NOT to
 mention the rtfm option when somebody asks I'm using FlatManager in
 nova-network and want to do the same in neutron, how does that work? (I
 love being able to write rtfm, don't you?)
 
 Sounds great!?! Cool! Do you want to help or know someone who does (or
 should - third-person volunteering not discouraged!)? We need
 nova-networking savvy and neutron savvy folks alike, though you need not
 necessarily be both at the same time.
 
 As some of the aforementioned benefits are directly relevant to the
 Icehouse development cycle AND the holiday season is upon us, it is
 important to get the ball rolling ASAP. To be specific, working recipes
 are most valuable if they are available for Icehouse-2 (see reasons 2, 3
 and most importantly 4).
 
 Please respond if interested, want to volunteer someone or have comments
 and suggestions.

I think that's a great idea.

What kind of format would you like to see the recepies in?

Regards,

Tom


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

Re: [openstack-dev] [glance] Unifying configuration file

[Tom Fifield]

On 17/06/14 23:30, Arnaud Legendre wrote:

@ZhiYan: I don't like the idea of removing the sample configuration file(s) 
from the git repository. Many people do not want to have to checkout the entire 
codebase and tox every time they have to verify a variable name in a 
configuration file. I know many people who were really frustrated where they 
realized that the sample config file was gone from the Nova repo.


For reference, see also the recent discussion around cinder.conf.sample: 
https://review.openstack.org/#/c/96581/ to learn more about ops wishes 
regarding sample configuration files.



However, I agree with the fact that it would be better if the sample was 100% 
accurate: so the way I would love to see this working is to generate the sample 
file every time there is a config change (this being totally automated (maybe 
at the gate level...)).

@Julien: I would be interested to understand the value that you see of having 
only one config file? At this point, I don't see why managing one file is more 
complicated than managing several files especially when they are organized by 
categories. Also, scrolling through the registry settings every time I want to 
modify an api setting seem to add some overhead.

Thanks,
Arnaud


- Original Message -
From: Zhi Yan Liu lzy@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Tuesday, June 17, 2014 7:47:53 AM
Subject: Re: [openstack-dev] [glance] Unifying configuration file

Frankly I don't like the idea of using single configuration for all
service too, I think it will be cool if we can generate separated
configuration template files automatically for each Glance service. So
besides https://review.openstack.org/#/c/83327/ , actually I'm working
on that idea as well, to allow deployer generates separated
configuration files on demand, and then probably we could move those
templates away from code repo.

But I like your idea for paste.ini template part.

zhiyan

On Tue, Jun 17, 2014 at 10:29 PM, Kuvaja, Erno kuv...@hp.com wrote:

I do not like this idea. As now we are on 5 different config files (+ policy 
and schema). One for each (API and Registry) would still be ok, but putting all 
together would just become messy.

If the *-paste.ini will be migrated to .conf files that would bring it down, 
but please do not try to mix reg and API configs together.

- Erno (jokke) Kuvaja


-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: 17 June 2014 15:19
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Unifying configuration file

On 17/06/14 15:59 +0200, Julien Danjou wrote:

Hi guys,

So I've started to look at the configuration file used by Glance and I
want to switch to one configuration file only.
I stumbled upon this blueprint:

  
https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/glance/%2Bspec/use-oslo-configk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0Am=QTguordmDDZNC%2FRUVedjVKf5cPErz5dhlJAZA56YqWU%3D%0As=ce068ea89b0fbf4260f6f8f18758f99b407536ec391c7c7392a079fc550ba468



w.r.t using config.generator https://review.openstack.org/#/c/83327/


which fits.

Does not look like I can assign myself to it, but if someone can do so,
go ahead.

So I've started to work on that, and I got it working. My only problem
right now, concerned the [paste_deploy] options that is provided by
Glance. I'd like to remove this section altogether, as it's not
possible to have it and have the same configuration file read by both
glance-api and glance-registry.
My idea is also to unify glance-api-paste.ini and
glance-registry-paste.ini into glance-paste.ini and then have each
server reads their default pipeline (pipeline:glance-api).

Does that sounds reasonable to everyone?


+1, it sounds like a good idea. I don't think we need to maintain 2
separate config files, especially now that the registry service is optional.

Thanks for working on this.
Flavio

--
@flaper87
Flavio Percoco

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


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

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




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

[openstack-dev] Release notes as we go?

[Tom Fifield]

Hi,

Remembering the last minute rush to get release notes ready for 
Icehouse, I was very pleased to see that the Juno release notes page has 
been already started!


https://wiki.openstack.org/wiki/ReleaseNotes/Juno

Perhaps if people are working on release-note worthy things, they could 
add a point on the wiki page as it is merged ?


I think it might provide at least a good memory aid when the 
end-of-release craziness sets in :)



Regards,


Tom

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

[openstack-dev] [Nova] Xen docs haven't been updated in two years

[Tom Fifield]

Hi all,

Almost a year ago a blueprint entitled Re-document Xen integration with 
OpenStack was created, because at that time, the Xen documentation 
hadn't been touched for more than a year.


We also added a prominent warning on the lead page that the ...section 
is low quality, and contains out of date information ... and that help 
is being sought.


So far, no-one has come forward.

It's a shame, because the fine folks at VMWare, the community for KVM 
and Hyper-V have been good in helping out the docs team in the technical 
bits that aren't pure OpenStack.



Is anyone out there developing or using XenServer with OpenStack?


Please consider signing up for the blueprint: 
https://blueprints.launchpad.net/openstack-manuals/+spec/redocument-xen


posting on the docs mailing list 
(http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs) or 
wandering into #openstack-doc on freenode for assistance.



Regards,


Tom


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

Re: [openstack-dev] [Keystone] Announcing Keystone Middleware Project

[Tom Fifield]

On 25/06/14 07:24, Morgan Fainberg wrote:

The Keystone team would like to announce the official split of
python-keystoneclient and the Keystone middleware code.
Over time the middleware (auth_token, s3_token, ec2_token) has developed
into a fairly expansive code base and
includes dependencies that are not necessarily appropriate for the
python-keystoneclient library and CLI tools. Combined
with the desire to be able to release updates of the middleware code
without requiring an update of the CLI and
  python-keystoneclient library itself, we have opted to split the
packaging of the middleware.


Seems sane :) If you haven't already, please consider giving a heads up 
to the debian/redhat/suse/ubuntu packagers so they're prepped as early 
as possible.



Regards,


Tom

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

[openstack-dev] Call for Speakers Open, OpenStack Summit in Paris

[Tom Fifield]

Hi Everyone,

*The Call for Speakers is OPEN for the November OpenStack Summit in 
Paris! Submit your talks here: 
https://www.openstack.org/summit/openstack-paris-summit-2014/call-for-speakers/.*


There are a few new speaking tracks in the Summit lineup this year so 
please review the below list before you submit a talk.


Don't wait! _The Call for Speakers will close on July 28 at 11:59pm CDT._

The Summit will take place in Paris at Le Palais des Congrès, November 
3-7. The main conference and expo will run Monday - Wednesday and the 
design summit will run Tuesday - Friday. Continue to visit 
openstack.org/summit http://openstack.org/summit for information 
including: event format, registration, hotel room blocks, visa letters, etc.


If you have any Summit related questions please email 
eve...@openstack.org mailto:eve...@openstack.org.


Cheers,
Claire


_Proposed Speaking Tracks for the OpenStack Summit in Paris:_

 * *Enterprise IT Strategies*

 * Enterprise IT leaders building their cloud business case are facing
   unique requirements to manage legacy applications, new software
   development and shadow IT within industry regulations and business
   constraints. In this track, we'll discuss how OpenStack is meeting
   enterprise IT technical requirements and cover topics relevant to
   planning your cloud strategy, including culture change, cost
   management, vendor strategy and recruiting.

 * *Telco Strategies*

 * Telecommunications companies are one of the largest areas of growth
   for OpenStack around the world. In this track, we'll feature content
   relevant to these users, addressing the evolution of the network and
   emerging NFV architecture, the global IaaS market and role of
   telcos, industry regulation and data sovereignty, and industry
   cooperation around interoperability and federation.

 * *How to Contribute*

 * The How to Contribute track is for new community members and
   companies interested in contributing to the open source code, with a
   focus on OpenStack community processes, tools, culture and best
   practices.

 * *Planning Your OpenStack Project*

 * If you are new to OpenStack or just getting started planning your
   cloud strategy, this track will cover the basics for you to evaluate
   the technology, understand the different ways to consume OpenStack,
   review popular use cases and determine your path forward.

 * *Products, Tools  Services*

 * OpenStack's vibrant ecosystem and the different ways to consume it
   are among it's greatest strengths. In this track, you'll hear about
   the latest products, tools and services from the OpenStack ecosystem.

 * *User Stories*

 * Sharing knowledge is a core value for the OpenStack community. In
   the user stories track, you'll hear directly from enterprises,
   service providers and application developers who are using OpenStack
   to address their business problems. Learn best practices, challenges
   and recommendations directly from your industry peers.

 * *Community Building*

 * OpenStack is a large, diverse community with more than 75 user
   groups around the world. In the community building track, user group
   leaders will share their experiences growing and maturing their
   local groups, community leaders will discuss new tools and metrics,
   and we'll shine a spotlight on end user and contributing
   organizations who have experienced a significant internal culture
   change as participants of the OpenStack community.

 * *Related OSS Projects*

 * There is a rich ecosystem of open source projects that sit on top
   of, plug into or support the OpenStack cloud software. In this
   track, we'll demonstrate the capabilities and preview the roadmaps
   for open source projects relevant to OpenStack. This presentation
   track is separate from the open source project working sessions,
   which allow the contributors to those projects to gather and discuss
   features and requirements relevant to their integration with
   OpenStack. A separate application for those working sessions will be
   announced.

 * *Operations*

 * The Operations track is 100% focused on what it takes to run a
   production OpenStack cloud. Every presenter has put endless
   coffee-fueled hours into making services scale robustly, never go
   down, and automating, automating, automating. The track will cover
   efficient use of existing tools, managing upgrades and staying
   up-to-date with one of the world's fastest-moving code bases and
   Architecture show and tell, where established clouds will lead a
   discussion around their architecture. If you're already running a
   cloud, you should also join us in the /Ops Summit/ for some serious
   working sessions (no basic intros here) on making the OpenStack
   software and ops tools for it better.

 * *Cloud Security*

 * The Security track will feature technical presentations, design and
   implementation disussions relevant to cloud security and OpenStack.

 * 

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

[Tom Fifield]

On 25/07/14 06:05, Robert Collins wrote:

On 25 July 2014 08:01, Sean Dague s...@dague.net wrote:


I'd like us to think about whether they is anything we can do to make
life easier in these kind of hard debugging scenarios where the regular
logs are not sufficient.


Agreed. Honestly, though we do also need to figure out first fail
detection on our logs as well. Because realistically if we can't debug
failures from those, then I really don't understand how we're ever going
to expect large users to.



I'm so glad you said that :). In conversations with our users, and
existing large deployers of Openstack, one thing has come through very
consistently: our default logs are insufficient.

We had an extensive discussion about this in the TripleO mid-cycle
meetup, and I think we reached broad consensus on the following:
  - the defaults should be what folk are running in production
  - we don't want to lead on changing defaults - its a big enough thing
we want to drive the discussion but not workaround it by changing our
defaults
  - large clouds are *today* running debug (with a few tweaks to remove
the most egregious log spammers and known security issues [like
dumping tokens into logs]
  - AFAICT productised clouds (push-button deploy etc) are running
something very similar
  - we would love it if developers *also* saw what users will see by
default, since that will tend to both stop things getting to spammy,
and too sparse.

So - I know thats brief - what we'd like to do is to poll a slightly
wider set of deployers - e.g. via a spec, perhaps some help from Tom
with the users and ops groups - and get a baseline of things that
there is consensus on and things that aren't, and then just change the


If a starting point is needed, the last discussion we had around 
'reasonable' defaults is here:


https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults



defaults to match. Further, to achieve the 'developers see the same
thing as users' bit, we'd like to make devstack do what TripleO does -
use defaults for logging levels, particularly in the gate.

Its totally true that we have a good policy about logging and we're
changing things to fit it but thats the long term play: short term,
making the default meet our deployments seems realtively easy and
immensely sane.

-Rob




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

Re: [openstack-dev] debug logs and defaults was (Thoughts on the patch test failure rate and moving forward)

[Tom Fifield]

On 28/07/14 09:18, Robert Collins wrote:

On 28 July 2014 13:11, Tom Fifield t...@openstack.org wrote:


If a starting point is needed, the last discussion we had around
'reasonable' defaults is here:

https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults


Thanks Tom!

I note that logging isn't in there, so either its not an issue (in
which case why are we putting all this overhaul effort in), or else
deployers have already tackled it in general and its not felt as a
current pain point (or perhaps we didn't get enough folk in the
room...)


Logging discussion is at:

https://etherpad.openstack.org/p/juno-summit-ops-monitoringlogging


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

Re: [openstack-dev] [nova] Why people don't close bugs?

[Tom Fifield]

On 04/08/14 17:46, Dmitry Guryanov wrote:

Hello!

I looked through launchpad bugs and it seems there are a lot of bugs,
which are fixed already, but still open, here are 3 ones:

https://bugs.launchpad.net/nova/+bug/909096

https://bugs.launchpad.net/nova/+bug/1206762

https://bugs.launchpad.net/nova/+bug/1208743

I've posted comments on these bugs, but nobody replied. How is it
possible, to close them?


Hi Dimiry,

Thanks for looking into the bug tracker. We definitely always need more 
people helping with triage (https://wiki.openstack.org/BugTriage).


If you join the Nova Bug Team (https://launchpad.net/~nova-bugs) you 
will be able to change the bugs' status as appropriate.


Regards,


Tom

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

Re: [openstack-dev] Networking Docs Swarm - Brisbane 9 August

[Tom Fifield]

How about writing up something in a bug report:

https://bugs.launchpad.net/openstack-manuals/+filebug

or a mailing list post about what you'd like to see?


Regards,


Tom

On 05/08/14 12:22, Stuart Fox wrote:

Cant make it to Brisbane but this doc is so needed. Any chamce you could
put round a questionaire or sethomg similar to get input from those who
cant make it?Â

Â

--

BR,

Stuart

Â


On 14-08-04 8:05 PM Lana Brindley wrote:

Hi everyone,

I just wanted to let you all know about the OpenStack Networking Docs
Swarm being held in Brisbane on 9 August.

Currently, there is no OpenStack Networking Guide, so the focus of this
swarm is to combine the existing networking content into a single doc so
that it can be updated, reviewed, and hopefully completed for the Juno
release.

We need both tech writers and OpenStack admins for the event to be a
success. Even if you can only make it for half an hour, your presence
would be greatly appreciated!

RSVP here:
http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.ba=co2.b_grprv=rcs.b

More information here:
http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.ba=co2.b_grprv=rcs.b

See you on Saturday!

Lana

--
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.ba=co2.b_grprv=rcs.b

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
http://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.ba=co2.b_grprv=rcs.b




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




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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 06/08/14 03:54, Jay Pipes wrote:

On 08/05/2014 03:23 PM, Collins, Sean wrote:

On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote:

However, I think the cost to providing that path far outweighs
the benefit in the face of other things on our plate.


Perhaps those large operators that are hoping for a
Nova-Network-Neutron zero-downtime live migration, could dedicate
resources to this requirement? It is my direct experience that features
that are important to a large organization will require resources
from that very organization to be completed.


Indeed, that's partly why I called out Metacloud in the original post,
as they were brought up as a deployer with this potential need. Please,
if there are any other shops that:

* Currently deploy nova-network
* Need to move to Neutron
* Their tenants cannot tolerate any downtime due to a cold migration

Please do comment on this thread and speak up.


Just to chip in for the dozens of users I have personally spoken to that 
do have the requirement for nova-network to neutron migration, and would 
be adversely affected if it was not implemented prior to deprecating 
nova-network: raising this concept only on a development mailing list is 
a bad idea :)


If anyone is serious about not providing a proper migration path for 
these users that need it, there is a need to be yelling this for 
probably a few of summits in a row and every OpenStack event we have in 
between, as well as the full gamut of periodic surveys, blogs, twitters, 
weibos, linkedins, facebooks etc,



Regards,


Tom

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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 06/08/14 12:40, Jay Pipes wrote:

On 08/05/2014 11:25 PM, Tom Fifield wrote:

On 06/08/14 03:54, Jay Pipes wrote:

On 08/05/2014 03:23 PM, Collins, Sean wrote:

On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote:

However, I think the cost to providing that path far outweighs
the benefit in the face of other things on our plate.


Perhaps those large operators that are hoping for a
Nova-Network-Neutron zero-downtime live migration, could dedicate
resources to this requirement? It is my direct experience that features
that are important to a large organization will require resources
from that very organization to be completed.


Indeed, that's partly why I called out Metacloud in the original post,
as they were brought up as a deployer with this potential need. Please,
if there are any other shops that:

* Currently deploy nova-network
* Need to move to Neutron
* Their tenants cannot tolerate any downtime due to a cold migration

Please do comment on this thread and speak up.


Just to chip in for the dozens of users I have personally spoken to that
do have the requirement for nova-network to neutron migration, and would
be adversely affected if it was not implemented prior to deprecating
nova-network: raising this concept only on a development mailing list is
a bad idea :)

If anyone is serious about not providing a proper migration path for
these users that need it, there is a need to be yelling this for
probably a few of summits in a row and every OpenStack event we have in
between, as well as the full gamut of periodic surveys, blogs, twitters,
weibos, linkedins, facebooks etc,


Well, yes, I agree that other methods of gathering that information
would indeed be good. I'll work on that.

Note, however, that nobody is suggesting not having a migration path.
I'm just suggesting relaxing the requirement that the migration from
nova-network to neutron be without any downtime of instances.


These users do not consider that a migration path, so actually that is 
what is being suggested.



Regards,


Tom


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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 06/08/14 13:18, Robert Collins wrote:

On 6 August 2014 16:57, Tom Fifield t...@openstack.org wrote:


Note, however, that nobody is suggesting not having a migration path.
I'm just suggesting relaxing the requirement that the migration from
nova-network to neutron be without any downtime of instances.



These users do not consider that a migration path, so actually that is what
is being suggested.


We can't even deploy an upgrade of Nova-Nova without some downtime
today


Actually, that's not true :) I've done even it personally on a 
production system. Several versions ago :)


Regards,


Tom


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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 06/08/14 13:24, Robert Collins wrote:

On 6 August 2014 17:22, Tom Fifield t...@openstack.org wrote:

On 06/08/14 13:18, Robert Collins wrote:


On 6 August 2014 16:57, Tom Fifield t...@openstack.org wrote:


Note, however, that nobody is suggesting not having a migration path.
I'm just suggesting relaxing the requirement that the migration from
nova-network to neutron be without any downtime of instances.




These users do not consider that a migration path, so actually that is
what
is being suggested.



We can't even deploy an upgrade of Nova-Nova without some downtime
today



Actually, that's not true :) I've done even it personally on a production
system. Several versions ago :)


What happened to your DB migrations then? :)


Sorry if I misunderstood, I thought we were talking about running VM 
downtime here?


Regards,

Tom


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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis

[Tom Fifield]

On 06/08/14 13:30, Robert Collins wrote:

On 6 August 2014 17:27, Tom Fifield t...@openstack.org wrote:

On 06/08/14 13:24, Robert Collins wrote:



What happened to your DB migrations then? :)



Sorry if I misunderstood, I thought we were talking about running VM
downtime here?


While DB migrations are running things like the nova metadata service
can/will misbehave - and user code within instances will be affected.
Thats arguably VM downtime.

OTOH you could define it more narrowly as 'VMs are not powered off' or
'VMs are not stalled for more than 2s without a time slice' etc etc -
my sense is that most users are going to be particularly concerned
about things for which they have to *do something* - e.g. VMs being
powered off or rebooted - but having no network for a short period
while vifs are replugged and the overlay network re-establishes itself
would be much less concerning.


I think you've got it there, Rob - nicely put :)

In many cases the users I've spoken to who are looking for a live path 
out of nova-network on to neutron are actually completely OK with some 
API service downtime (metadata service is an API service by their 
definition). A little 'glitch' in the network is also OK for many of them.


Contrast that with the original proposal in this thread (snapshot VMs 
in old nova-network deployment, store in Swift or something, then launch 
VM from a snapshot in new Neutron deployment) - it is completely 
unacceptable and is not considered a migration path for these users.



Regards,


Tom


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

Re: [openstack-dev] [glance] Switching from sql_connection to [database] connection ?

[Tom Fifield]

Due to the lack of response, I'm proposing to switch the documentation 
back to using sql_connection. I hope there wasn't a plan to deprecate 
this option any time soon :)



Regards,


Tom

On 02/04/14 10:22, Tom Fifield wrote:

Since it's missed RC1, I'm guessing that this confusion to users will be
ongoing for another six months ? :)

Regards,


Tom

On 30/03/14 23:24, Zhi Yan Liu wrote:

Hi

We have no plan to update sample template in I release for it, but
https://review.openstack.org/#/c/77379/ is on reviewing, IFY.

zhiyan

Sent from my iPad

On 2014年3月30日, at 13:04, Tom Fifield t...@openstack.org
mailto:t...@openstack.org wrote:


On 27/02/14 18:47, Flavio Percoco wrote:

On 27/02/14 12:12 +0800, Tom Fifield wrote:

Hi,

As best I can tell, all other services now use this syntax for
configuring database connections:

[database]
connection = sqlite:///etc,omg


whereas glance appears to still use

[DEFAULT]
...
sql_connection = sqlite:///etc,omg


Is there a plan to switch to the former during Icehouse development?

From a user standpoint it'd be great to finally have consistency
amoungst all the services :)


It already did. It looks like the config sample needs to be updated.

To be more precise, `sql_connection` is marked as deprecated.[0]

[0]
https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/session.py#L329





Just noting that the sample config has still not been updated.


Regards,


Tom


___
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] [horizon][heat] Unusable error messages in dashboard for Orchestration

[Tom Fifield]

Hi,

Lodged a bug the day after Havana came out to hope to get this usability 
problem addressed.


https://bugs.launchpad.net/horizon/+bug/1241395

Essentially, if something goes wrong creating a stack through the 
dashboard, all the user ever sees is:


Stack creation failed.


... which is, a little less than useful in terms of enabling them to fix 
the problem.


Testing using RC1 today, there is no improvement, and I was shocked to 
discover the the bug submitted was not even triaged during icehouse!


Any ideas? :)


Regards,


Tom

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

[openstack-dev] [glance] Release notes for Icehouse

[Tom Fifield]

Hi,

Is someone working on release notes for glance? At the moment it's 
looking pretty bare :)


https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse


Regards,


Tom

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

Re: [openstack-dev] [nova] Summit schedule draft

[Tom Fifield]

On 28/04/14 05:02, Michael Still wrote:

Hi.

I've just pushed a draft summit schedule to sched.org. I'd be
interested in people who proposed a session that was accepted checking
if their session time clashes with other commitments that they have,
as well as people who are passionate about a given proposal ensuring
that they're available at the scheduled time.

Bear in mind that this is a non-trivial problem though... There's only
so much schedule shuffling that can be done.

Thanks,
Michael



Nova session: Next steps in live upgrade

clashes with

neutron session: Nova-Net to Neutron migration

2:40pm on Wednesday.

Since these are both specifically about upgrades that involve nova, 
perhaps there's enough of a shared audience they should go in separate 
times?



Regards,


Tom

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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

[Tom Fifield]

On 02/05/14 22:09, Mark McClain wrote:
 
 On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote:
 
 Some non insignificant number of devstack changes related to neutron
 seem to be neutron plugins having to do all kinds of manipulation of
 extra config files. The grenade upgrade issue in neutron was because of
 some placement change on config files. Neutron seems to have *a ton* of
 config files and is extremely sensitive to their locations/naming, which
 also seems like it ends up in flux.
 
 We have grown in the number of configuration files and I do think some of the 
 design decisions made several years ago should probably be revisited.  One of 
 the drivers of multiple configuration files is the way that Neutron is 
 currently packaged [1][2].  We’re packaged significantly different than the 
 other projects so the thinking in the early years was that each 
 plugin/service since it was packaged separately needed its own config file.  
 This causes problems because often it involves changing the init script 
 invocation if the plugin is changed vs only changing the contents of the init 
 script.  I’d like to see Neutron changed to be a single package similar to 
 the way Cinder is packaged with the default config being ML2.
 

 Is there an overview somewhere to explain this design point?
 
 Sadly no.  It’s a historical convention that needs to be reconsidered.
 

 All the other services have a single config config file designation on
 startup, but neutron services seem to need a bunch of config files
 correct on the cli to function (see this process list from recent
 grenade run - http://paste.openstack.org/show/78430/ note you will have
 to horiz scroll for some of the neutron services).

 Mostly it would be good to understand this design point, and if it could
 be evolved back to the OpenStack norm of a single config file for the
 services.

 
 +1 to evolving into a more limited set of files.  The trick is how we 
 consolidate the agent, server, plugin and/or driver options or maybe we don’t 
 consolidate and use config-dir more.  In some cases, the files share a set of 
 common options and in other cases there are divergent options [3][4].   
 Outside of testing the agents are not installed on the same system as the 
 server, so we need to ensure that the agent configuration files should stand 
 alone.  
 
 To throw something out, what if moved to using config-dir for optional 
 configs since it would still support plugin scoped configuration files.  
 
 Neutron Servers/Network Nodes
 /etc/neutron.d
   neutron.conf  (Common Options)
   server.d (all plugin/service config files )
   service.d (all service config files)
 
 
 Hypervisor Agents
 /etc/neutron
   neutron.conf
   agent.d (Individual agent config files)
 
 
 The invocations would then be static:
 
 neutron-server —config-file /etc/neutron/neutron.conf —config-dir 
 /etc/neutron/server.d
 
 Service Agents:
 neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir 
 /etc/neutron/service.d
 
 Hypervisors (assuming the consolidates L2 is finished this cycle):
 neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir 
 /etc/neutron/agent.d
 
 Thoughts?

What do operators want?



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

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

[Tom Fifield]

On 22/05/14 04:55, James E. Blair wrote:

Hi,

On Friday, May 23 at 21:00 UTC Gerrit will be unavailable for about 20
minutes while we rename some projects.  Existing reviews, project
watches, etc, should all be carried over.  The current list of projects
that we will rename is:

stackforge/barbican - openstack/barbican
openstack/oslo.test - openstack/oslotest
openstack-dev/openstack-qa - openstack-attic/openstack-qa
openstack/melange - openstack-attic/melange
openstack/python-melangeclient - openstack-attic/python-melangeclient
openstack/openstack-chef - openstack-attic/openstack-chef
stackforge/climate - stackforge/blazar
stackforge/climate-nova - stackforge/blazar-nova
stackforge/python-climateclient - stackforge/python-blazarclient
openstack/database-api - openstack-attic/database-api
openstack/glance-specs - openstack/image-specs
openstack/neutron-specs - openstack/networking-specs
openstack/oslo-specs - openstack/common-libraries-specs



May I ask, will the old names have some kind of redirect to the new names?

For example, after the change, what would a user visiting: 
https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z 



see?

We've gone to quite a bit of effort of late to communicate the new 
*-specs repositories to people (particularly for nova and neutron), and 
it would be a really bad experience - especially for those from the 
non-developer side of things - to be presented with some kind of error 
or empty list after following the link we gave them.



Regards,


Tom



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

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

[Tom Fifield]

On 22/05/14 05:48, James E. Blair wrote:

Tom Fifield t...@openstack.org writes:


May I ask, will the old names have some kind of redirect to the new names?


Of course you may ask!  And it's a great question!  But sadly the answer
is no.  Unfortunately, Gerrit's support for renaming projects is not
very good (which is why we need to take downtime to do it).

I'm personally quite fond of stable URLs.  However, these started as an
experiment so we were bound to get some things wrong (and will
probably continue to do so) and it's better to try to fix them early.


This is a really poor outcome.

Can we delay the migration until we have some time to think about the 
communication strategy?


At the least, I'd suggest a delay for renaming neutron-specs until until 
after the peak of the Juno blueprint work is done. Say in ~3 weeks time.



Regards,

Tom


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

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

[Tom Fifield]

On 22/05/14 11:06, Kyle Mestery wrote:

On Wed, May 21, 2014 at 5:06 PM, Tom Fifield t...@openstack.org wrote:

On 22/05/14 05:48, James E. Blair wrote:


Tom Fifield t...@openstack.org writes:


May I ask, will the old names have some kind of redirect to the new
names?



Of course you may ask!  And it's a great question!  But sadly the answer
is no.  Unfortunately, Gerrit's support for renaming projects is not
very good (which is why we need to take downtime to do it).

I'm personally quite fond of stable URLs.  However, these started as an
experiment so we were bound to get some things wrong (and will
probably continue to do so) and it's better to try to fix them early.



This is a really poor outcome.

Can we delay the migration until we have some time to think about the
communication strategy?

At the least, I'd suggest a delay for renaming neutron-specs until until
after the peak of the Juno blueprint work is done. Say in ~3 weeks time.


I tend to agree with James that we should do this early and take the
bullet on renaming now. The process for adding new Neutron specs is
outlined here [1], and this will be updated once the repository is
renamed. In addition, I'm working on adding/updating some Neutron wiki
pages around the Neutron development process, and the specs repo will
be highlighted there once that's done. It would be good to have the
renaming done before then.


... and how would you propose we communicate this to the users we've 
been asking to do blueprint review specifically during this early 
period? We can't exactly send them an email saying sorry, the link we 
mentioned earlier is now wrong :)


What would you gain from doing it this week instead of later in the month?

We're really trying to engage users to help out with the spec review 
process, but it seems they weren't taken into account at all when 
planning this change. Seems like a bad precedent to set for our first 
experiment.



Regards,


Tom

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

Re: [openstack-dev] [Ironic] Get rid of the sample config file

[Tom Fifield]

On 26/09/14 03:35, Morgan Fainberg wrote:
 -Original Message-
 From: John Griffith john.griffi...@gmail.com
 Reply: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: September 25, 2014 at 12:27:52
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject:  Re: [openstack-dev] [Ironic] Get rid of the sample config file
 
 On Thu, Sep 25, 2014 at 12:34 PM, Devdatta Kulkarni 
 devdatta.kulka...@rackspace.com wrote:
  
 Hi,

 We have faced this situation in Solum several times. And in fact this was
 one of the topics
 that we discussed in our last irc meeting.

 We landed on separating the sample check from pep8 gate into a non-voting
 gate.
 One reason to keep the sample check is so that when say a feature in your
 code fails
 due to some upstream changes and for which you don't have coverage in your
 functional tests then
 a non-voting but failing sample check gate can be used as a starting point
 of the failure investigation.

 More details about the discussion can be found here:

 http://eavesdrop.openstack.org/meetings/solum_team_meeting/2014/solum_team_meeting.2014-09-23-16.00.log.txt
   

 - Devdatta

 --
 *From:* David Shrewsbury [shrewsbury.d...@gmail.com]
 *Sent:* Thursday, September 25, 2014 12:42 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Ironic] Get rid of the sample config file

 Hi!

 On Thu, Sep 25, 2014 at 12:23 PM, Lucas Alvares Gomes 
 lucasago...@gmail.com wrote:

 Hi,

 Today we have hit the problem of having an outdated sample
 configuration file again[1]. The problem of the sample generation is
 that it picks up configuration from other projects/libs
 (keystoneclient in that case) and this break the Ironic gate without
 us doing anything.

 So, what you guys think about removing the test that compares the
 configuration files and makes it no longer gate[2]?

 We already have a tox command to generate the sample configuration
 file[3], so folks that needs it can generate it locally.

 Does anyone disagree?


 +1 to this, but I think we should document how to generate the sample
 config
 in our documentation (install guide?).

 -Dave
 --
 David Shrewsbury (Shrews)

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


 I tried this in Cinder a while back and was actually rather surprised by
 the overwhelming push-back I received from the Operator community, and
 whether I agreed with all of it or not, the last thing I want to do is
 ignore the Operators that are actually standing up and maintaining what
 we're building.
  
 Really at the end of the day this isn't really that big of a deal. It's
 relatively easy to update the config in most of the projects tox
 -egenconfig see my posting back in May [1]. For all the more often this
 should happen I'm not sure why we can't have enough contributors that are
 just pro-active enough to fix it up when they see it falls out of date.
  
 John
  
 [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-May/036438.html 
  
 
 +1 to what John just said.
  
 I know in Keystone we update the sample config (usually) whenever we notice 
 it out of date. Often we ask developers making config changes to run `tox 
 -esample_config` and re-upload their patch. If someone misses we (the cores) 
 will do a patch that just updates the sample config along the way. Ideally we 
 should have a check job that just reports the config is out of date (instead 
 of blocking the review).
 
 The issue is the premise that there are 2 options:
 
 1) Gate on the sample config being current
 2) Have no sample config in the tree.
 
 The missing third option is the proactive approach (plus having something 
 convenient like `tox -egenconfig` or `tox -eupdate_sample_config` to make it 
 convenient to update the sample config) is the approach that covers both 
 sides nicely. The Operators/deployers have the sample config in tree, the 
 developers don’t get patched rejected in the gate because the sample config 
 doesn’t match new options in an external library.
 
 I know a lot of operators and deployers appreciate the sample config being 
 in-tree.

Just confirming this is definitely the case.

Regards,


Tom


___
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

[Tom Fifield]

Hi Joe,

On 01/10/14 09:10, joehuang wrote:
 OpenStack cascading: to integrate multi-site / multi-vendor OpenStack 
 instances into one cloud with OpenStack API exposed.
 Cells: a single OpenStack instance scale up methodology

Just to let you know - there are actually some users out there that use
cells to integrate multi-site / multi-vendor OpenStack instances into
one cloud with OpenStack API exposed., and this is their main reason
for using cells - not as a scale up methodology.


Regards,

Tom

___
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

[Tom Fifield]

On 02/10/14 14:32, Łukasz Jernaś wrote:
 On Wed, Oct 1, 2014 at 6:04 PM, Akihiro Motoki amot...@gmail.com wrote:
 Hi,
 
 Hi Akihiro!
 
 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).
 
 I'd go for (a), as traditionally message catalogs were compiled during
 the packaging step for Linux software (of course your experiences may
 vary).
 Of course if it was pretty straightforward to integrate it into pip
 install it would also be a good solution.

(a) sounds sane, but we should ensure that we tell the packagers that we
expect them to make the compiled message catalogues so ops can more
easily use the translations. (I guess this is like a modified version of
(b))

Regards,

Tom

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

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

[Tom Fifield]

On 04/10/14 04:03, Nick Chase wrote:
 
 On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org
 mailto:stef...@openstack.org wrote:
   1. Pick an existing topic or create a new topic. For new topics,
 we're
  primarily interested in deployment scenarios.
   2. Develop content (text and/or diagrams) in a format that
 supports at
  least basic markup (e.g., titles, paragraphs, lists, etc.).
   3. Provide a link to the content (e.g., gist on github.com
 http://github.com, wiki page,
  blog post, etc.) under the associated topic.
 
 Points 1-3 seem to be oriented at removing Launchpad from the equation.
 Is that all there is? I guess it makes sense to remove obstacles,
 although editing the wiki (since it requires a launchpad account anyway)
 may not be the best way to track progress and see assignments.
 
 
 No, really, the main change is in step 5.  Launchpad isn't the problem,
 as far as we can tell; Docbook is.

Hi Nick,

As best I can tell - 'step 5' has been in place for at least the last
few summits at least, so this is not a change :) We have had a policy
where anyone can dump text in bug reports and we'll wrangle it. This has
been popular, see eg Marco Cossoni's contributions, but in my opinion
not widely enough communicated - so thanks for your efforts.


   4. Send e-mail to reviewers network...@openstacknow.com
 mailto:network...@openstacknow.com.
 
 Why not use the docs mailing list or other facilities on
 @openstack.org http://openstack.org?
 Who is responding to that address?
 
 
 If someone want to provide us a list on @openstack.org
 http://openstack.org, that'd be awesome.  I set up this address
 because I control the forwarding and could do it immediately without
 having to ask for anyone's approval. :)  
 
 People on the alias are myself, Edgar Magana, Matt Kasawara, Phil
 Hopkins, Anne Gentle, and Elke Vorheis.

I find it quite odd that the larger team is being excluded from this
effort. Why would it need a separate mailing list?



Regards,


Tom



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

Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!

[Tom Fifield]

On 06/10/14 11:38, Nick Chase wrote:
 On Sun, Oct 5, 2014 at 11:26 PM, Tom Fifield t...@openstack.org
 mailto:t...@openstack.org wrote:
 
 On 04/10/14 04:03, Nick Chase wrote:
 
  On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli stef...@openstack.org 
 mailto:stef...@openstack.org
  mailto:stef...@openstack.org mailto:stef...@openstack.org wrote:
1. Pick an existing topic or create a new topic. For new topics,
  we're
   primarily interested in deployment scenarios.
2. Develop content (text and/or diagrams) in a format that
  supports at
   least basic markup (e.g., titles, paragraphs, lists, etc.).
3. Provide a link to the content (e.g., gist on github.com 
 http://github.com
  http://github.com, wiki page,
   blog post, etc.) under the associated topic.
 
  Points 1-3 seem to be oriented at removing Launchpad from the 
 equation.
  Is that all there is? I guess it makes sense to remove obstacles,
  although editing the wiki (since it requires a launchpad account 
 anyway)
  may not be the best way to track progress and see assignments.
 
 
  No, really, the main change is in step 5.  Launchpad isn't the problem,
  as far as we can tell; Docbook is.
 
 Hi Nick,
 
 As best I can tell - 'step 5' has been in place for at least the last
 few summits at least, so this is not a change :) We have had a policy
 where anyone can dump text in bug reports and we'll wrangle it. This has
 been popular, see eg Marco Cossoni's contributions, but in my opinion
 not widely enough communicated - so thanks for your efforts.
 
 
 Right, again, it's fantastic that people can dump text in bug reports,
 and yes, it's probably not well known.  We're just trying to sort of
 widen out what people are sending from a few paragraphs to entire
 topics.  But hey, the general idea is the same. We're all trying to get
 to the same point.
 
 Obviously there's something about the current process that's not working
 as well as it could.  This experiment is about trying to figure out
 what.  If all we're changing is moving the contribution point from a bug
 report to a wiki, then great; having just one changed variable among
 control variables is good science.
  
 
 
4. Send e-mail to reviewers network...@openstacknow.com 
 mailto:network...@openstacknow.com
  mailto:network...@openstacknow.com
 mailto:network...@openstacknow.com.
 
  Why not use the docs mailing list or other facilities on
  @openstack.org http://openstack.org http://openstack.org?
  Who is responding to that address?
 
 
  If someone want to provide us a list on @openstack.org 
 http://openstack.org
  http://openstack.org, that'd be awesome.  I set up this address
  because I control the forwarding and could do it immediately without
  having to ask for anyone's approval. :)
 
  People on the alias are myself, Edgar Magana, Matt Kasawara, Phil
  Hopkins, Anne Gentle, and Elke Vorheis.
 
 I find it quite odd that the larger team is being excluded from this
 effort. Why would it need a separate mailing list?
 
 
 We haven't intentionally excluded anybody; we were just keeping it small
 both to keep it a focused effort -- this way we could more easily hash
 things out without anybody stepping on anybody else -- and so that we
 weren't essentially volunteering people against their will. :) But we
 can easily change it over to the main docs list.

Yup - I think that would be more in the spirit of our Open Development
core principle and I would encourage you to do so.


Regards,

Tom


___
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

[Tom Fifield]

On 08/10/14 20:51, James Page wrote:
 On 07/10/14 18:00, Julie Pichon wrote:
 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.
 
 I'm in agreement that option a) is the best way to go; on the
 assumption that compiling the message catalogs won't bring in
 requirements for new dependencies, we can deal with that for rc2 in
 Ubuntu for Juno.

I've put some information for you on what it takes to compile messages
over at:
https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1377923

 
 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
 


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

Re: [openstack-dev] [Nova] Cells conversation starter

[Tom Fifield]

On 22/10/14 03:07, Andrew Laski wrote:
 
 On 10/21/2014 04:31 AM, Nikola Đipanov wrote:
 On 10/20/2014 08:00 PM, Andrew Laski wrote:
 One of the big goals for the Kilo cycle by users and developers of the
 cells functionality within Nova is to get it to a point where it can be
 considered a first class citizen of Nova.  Ultimately I think this comes
 down to getting it tested by default in Nova jobs, and making it easy
 for developers to work with.  But there's a lot of work to get there.
 In order to raise awareness of this effort, and get the conversation
 started on a few things, I've summarized a little bit about cells and
 this effort below.


 Goals:

 Testing of a single cell setup in the gate.
 Feature parity.
 Make cells the default implementation.  Developers write code once and
 it works for  cells.

 Ultimately the goal is to improve maintainability of a large feature
 within the Nova code base.

 Thanks for the write-up Andrew! Some thoughts/questions below. Looking
 forward to the discussion on some of these topics, and would be happy to
 review the code once we get to that point.

 Feature gaps:

 Host aggregates
 Security groups
 Server groups


 Shortcomings:

 Flavor syncing
  This needs to be addressed now.

 Cells scheduling/rescheduling
 Instances can not currently move between cells
  These two won't affect the default one cell setup so they will be
 addressed later.


 What does cells do:

 Schedule an instance to a cell based on flavor slots available.
 Proxy API requests to the proper cell.
 Keep a copy of instance data at the global level for quick retrieval.
 Sync data up from a child cell to keep the global level up to date.


 Simplifying assumptions:

 Cells will be treated as a two level tree structure.

 Are we thinking of making this official by removing code that actually
 allows cells to be an actual tree of depth N? I am not sure if doing so
 would be a win, although it does complicate the RPC/Messaging/State code
 a bit, but if it's not being used, even though a nice generalization,
 why keep it around?
 
 My preference would be to remove that code since I don't envision anyone
 writing tests to ensure that functionality works and/or doesn't
 regress.  But there's the challenge of not knowing if anyone is actually
 relying on that behavior.  So initially I'm not creating a specific work
 item to remove it.  But I think it needs to be made clear that it's not
 officially supported and may get removed unless a case is made for
 keeping it and work is put into testing it.

While I agree that N is a bit interesting, I have seen N=3 in production

[central API]--[state/region1]--[state/region DC1]
   \-[state/region DC2]
  --[state/region2 DC]
  --[state/region3 DC]
  --[state/region4 DC]




 Plan:

 Fix flavor breakage in child cell which causes boot tests to fail.
 Currently the libvirt driver needs flavor.extra_specs which is not
 synced to the child cell.  Some options are to sync flavor and extra
 specs to child cell db, or pass full data with the request.
 https://review.openstack.org/#/c/126620/1 offers a means of passing full
 data with the request.

 Determine proper switches to turn off Tempest tests for features that
 don't work with the goal of getting a voting job.  Once this is in place
 we can move towards feature parity and work on internal refactorings.

 Work towards adding parity for host aggregates, security groups, and
 server groups.  They should be made to work in a single cell setup, but
 the solution should not preclude them from being used in multiple
 cells.  There needs to be some discussion as to whether a host aggregate
 or server group is a global concept or per cell concept.

 Have there been any previous discussions on this topic? If so I'd really
 like to read up on those to make sure I understand the pros and cons
 before the summit session.
 
 The only discussion I'm aware of is some comments on
 https://review.openstack.org/#/c/59101/ , though they mention a
 discussion at the Utah mid-cycle.
 
 The main con I'm aware of for defining these as global concepts is that
 there is no rescheduling capability in the cells scheduler.  So if a
 build is sent to a cell with a host aggregate that can't fit that
 instance the build will fail even though there may be space in that host
 aggregate from a global perspective.  That should be somewhat
 straightforward to address though.
 
 I think it makes sense to define these as global concepts.  But these
 are features that aren't used with cells yet so I haven't put a lot of
 thought into potential arguments or cases for doing this one way or
 another.
 
 
 Work towards merging compute/api.py and compute/cells_api.py so that
 developers only need to make changes/additions in once place.  The goal
 is for as much as possible to be hidden by the RPC layer, which will
 determine whether a call goes to a compute/conductor/cell.

 

Re: [openstack-dev] [glance] Permissions differences for glance image-create between Icehouse and Juno

[Tom Fifield]

This was covered in the release notes for glance, under Upgrade notes:

https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_3

* The ability to upload a public image is now admin-only by default. To
continue to use the previous behaviour, edit the publicize_image flag in
etc/policy.json to remove the role restriction.

Regards,


Tom

On 28/10/14 01:22, Jay Pipes wrote:
 Hello Glancers,
 
 Peter and I are having issues working with a Juno Glance endpoint.
 Specifically, a glance image-create ... --is_public=True CLI command
 that *was* working in our Icehouse cloud is now failing in our Juno
 cloud with a 403 Forbidden.
 
 The specific command in question is:
 
 glance image-create --name cirros-0.3.2-x86_64 --file
 /var/tmp/cirros-0.3.2-x86_64-disk.img --disk-format qcow2
 --container-format bare --is_public=True
 
 If we take off the is_public=True, everything works just fine. We are
 executing the above command as a user with a user called admin having
 the role admin in a project called admin.
 
 We have enabled debug=True conf option in both glance-api.conf and
 glance-registry.conf, and unfortunately, there is no log output at all,
 other than spitting out the configuration option settings on daemon
 startup and a few messages like Loaded policy rules: ... which don't
 actually provide any useful information about policy *decisions* that
 are made... :(
 
 Any help is most appreciated. Our policy.json file is the stock one that
 comes in the Ubuntu Cloud Archive glance packages, i.e.:
 
 http://paste.openstack.org/show/125420/
 
 Best,
 -jay
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [glance] Permissions differences for glance image-create between Icehouse and Juno

[Tom Fifield]

Sorry, early morning!

I can confirm that in your policy.json there is:

publicize_image: role:admin,

which seems to match what's needed :)

Regards,


Tom

On 28/10/14 10:18, Jay Pipes wrote:
 Right, but as you can read below, I'm using an admin to do the operation...
 
 Which is why I'm curious what exactly I'm supposed to do :)
 
 -jay
 
 On 10/27/2014 09:04 PM, Tom Fifield wrote:
 This was covered in the release notes for glance, under Upgrade notes:

 https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_3

 * The ability to upload a public image is now admin-only by default. To
 continue to use the previous behaviour, edit the publicize_image flag in
 etc/policy.json to remove the role restriction.

 Regards,


 Tom

 On 28/10/14 01:22, Jay Pipes wrote:
 Hello Glancers,

 Peter and I are having issues working with a Juno Glance endpoint.
 Specifically, a glance image-create ... --is_public=True CLI command
 that *was* working in our Icehouse cloud is now failing in our Juno
 cloud with a 403 Forbidden.

 The specific command in question is:

 glance image-create --name cirros-0.3.2-x86_64 --file
 /var/tmp/cirros-0.3.2-x86_64-disk.img --disk-format qcow2
 --container-format bare --is_public=True

 If we take off the is_public=True, everything works just fine. We are
 executing the above command as a user with a user called admin having
 the role admin in a project called admin.

 We have enabled debug=True conf option in both glance-api.conf and
 glance-registry.conf, and unfortunately, there is no log output at all,
 other than spitting out the configuration option settings on daemon
 startup and a few messages like Loaded policy rules: ... which don't
 actually provide any useful information about policy *decisions* that
 are made... :(

 Any help is most appreciated. Our policy.json file is the stock one that
 comes in the Ubuntu Cloud Archive glance packages, i.e.:

 http://paste.openstack.org/show/125420/

 Best,
 -jay

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


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

 
 ___
 OpenStack-dev 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] fix latency on requirements breakage

[Tom Fifield]

On 18/11/14 18:51, Thierry Carrez wrote:
 Christopher Yeoh wrote:
 On Tue, Nov 18, 2014 at 9:32 AM, Sean Dague s...@dague.net
 mailto:s...@dague.net wrote:

 waiting extra long for valid test results. People don't realize their
 code can't pass and just keep pushing patches up consuming resources
 which means that parts of the project that could pass tests, is backed
 up behind 100% guarunteed failing parts. All in all, not a great system.


 Maybe a MOTD at the top of http://review.openstack.org could help here?
 Have a button
 that the QA/infra people can hit when everything is broken that puts up
 a message
 there asking people to stop rechecking/submitting patches.
 
 We can already ask statusbot
 (http://ci.openstack.org/irc.html#statusbot) to show up messages on
 status.openstack.org and log them to
 https://wiki.openstack.org/wiki/Infrastructure_Status
 
 It's just not used as much as it used to for CI breakage those days.
 

I have to say, extending statusbot to do MOTD on
http://review.openstack.org sounds like a great idea to me. It also
sounds like one of those changes to gerrit that might actually be in the
'achievable' bucket :D

Regards,

Tom

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

Re: [openstack-dev] Program Proposal: refstack

[Tom Fifield]

On 10/07/13 01:01, Monty Taylor wrote:

Hey all,

I'd like to propose an official program to the TC - refstack, a program
for verifying interoperability between implementations via FITS testing.

Official Title: OpenStack Interoperability
Initial PTL: Monty Taylor mord...@inaugust.com
Mission Statement:
   Develop and maintain FITS testing and interoperability reporting for
   OpenStack deployments and distributions.


No problems with the program, but I would caution the title. 
'Interoperability' is much broader than 'interoperability between 
OpenStack clouds'. This could be a potential point of confusion for 
those who are looking for other kinds of interoperability - unless you 
want to take those on too ? ;)



Regards,


Tom

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

Re: [openstack-dev] [Neutron][docs] Why is the neutron security group extension disabled by default?

[Tom Fifield]

Dear caller, your bug is important to us, and will be addressed by the 
first available operator. You are currently. number. two ... hundred ... 
and. forty. eight. in the queue.


http://bit.ly/17cJejn


https://bugs.launchpad.net/openstack-manuals/+bug/1190940

;)


Regards,

Tom

On 14/07/13 12:44, Robert Collins wrote:

I've previously filed a bug about the docs; I agree that this seems like
something to make enabled by default, particularly with nova-network now
on the deprecation path.

-Rob

On 14 July 2013 14:08, Matt Riedemann mrie...@us.ibm.com
mailto:mrie...@us.ibm.com wrote:

I had to figure out via the code that unless you specify a firewall
driver in the neutron plugin's ini file (I'm using openvswitch in
this case), the neutron security group extension is disabled.

The admin doc tells you what to do in nova.conf to get nova to proxy
security group calls through neutron:


_http://docs.openstack.org/trunk/openstack-network/admin/content/nova_config_security_groups.html_

But there is no mention of setting the firwall_driver property in
the [securitygroup] section of your plugin's ini file.  For OVS, it
would be setting this:


_http://gerrit.rtp.raleigh.ibm.com/gitweb?p=osee-tools.git;a=blob;f=install/build.include;h=2089a32f1da4ad92a61601a4d46a5b34b312f644;hb=refs/heads/osee-havana#l103_

In nova, security groups work out of the box (well, at least they
are enabled, you still have to setup the rules).

Is there a design point of why the neutron security group extension
is disabled by default (maybe so it doesn't interfere with nova
somehow)?  If so, we can work on getting the docs updated.
  Otherwise it seems like a bug in the code.


Thanks,

*MATT RIEDEMANN*
Advisory Software Engineer
Cloud Solutions and OpenStack Development

*Phone:*1-507-253-7622 tel:1-507-253-7622| *Mobile:*1-507-990-1889
tel:1-507-990-1889*
E-mail:*_mrie...@us.ibm.com_ mailto:mrie...@us.ibm.com  
IBM

3605 Hwy 52 N
Rochester, MN 55901-1407
United States



___
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




--
Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com
Distinguished Technologist
HP Cloud Services


___
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] [Grizzly] Retrieving a flavors extra-specs in horizon

[Tom Fifield]

Can you update 
https://ask.openstack.org/question/3674/get-a-flavors-extra-specs-in-horizon/ 
too :)


Regards,

Tom

On 02/08/13 11:50, Dale, StewartX T wrote:

Switching to your mentioned function fixed my issues.  Thanks!
-Original Message-
From: Kieran Spear [mailto:kisp...@gmail.com]
Sent: Thursday, August 01, 2013 5:30 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Grizzly] Retrieving a flavors extra-specs in
horizon

On 2 August 2013 09:32, Dale, StewartX T stewartx.t.d...@intel.com wrote:

Hi List,



I'm trying to port some UI(horizon) customization I did in Folsom so
that it works in Grizzly and I could use everyone's help. Must of the
process has gone smoothly, just one piece that isn't working. It's the
code that gets the extra-specs of a flavor. My old Folsom based code looks

like this:




flavor = api.flavor_get(self.request, flavor_id)

extras = flavor.get_keys()

inst.flavor_id = flavor_id

if extras:

  inst.myvalue = extras['mySpecs']

else:

  inst.myvalue = -



But using that code in Grizzly causes a crash ( and no log entries so
I don't even know why, just the). I did some research and saw in the
release notes of Grizzly that they had added support for getting a
flavors extra specs in horizon
(https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Flavor_Extra_Spe
cs_Support) but I can't find any actual examples of how to do it.


The flavor part of code above should work fine (assuming 'mySpecs' is
actually in the returned specs). But there's a flavor_get_extras function
you can use too:


extras = api.nova.flavor_get_extras(self.request, flavor_id,
raw=True) extras

{u'test': u'value'}

extras.get('test', '-')

u'value'

extras.get('mySpecs', '-')

'-'

Check out the admin flavors panel for other examples.

Kieran





I am hoping someone on the list might know.





-Stewart Dale




___
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] About multihost patch review

[Tom Fifield]

On 27/08/13 15:23, Maru Newby wrote:
 
 On Aug 26, 2013, at 9:39 PM, Yongsheng Gong gong...@unitedstack.com wrote:
 
 First 'be like nova-network' is a merit for some deployments.
 
 I'm afraid 'merit' is a bit vague for me.  Would you please elaborate?

One area of 'merit' in this area is for migration from nova-network to
neutron. If there's something exactly analogous to something that
already exists, its easier to move across.

 
 second, To allow admin to decide which network will be multihosted at 
 runtime will enable the neutron to continue using the current network node 
 (dhcp agent) mode at the same time.
 
 If multi-host and non- multi-host networks are permitted to co-exist (because 
 configuration is per-network), won't compute nodes have to be allowed to be 
 heterogenous (some multi-host capable, some not)?  And won't Nova then need 
 to schedule VMs configured with multi-host networks on compatible nodes?  I 
 don't recall mention of this issue in the blueprint or design doc, and would 
 appreciate pointers to where this decision was documented.
 
 

 If we force the network multihosted when the configuration enable_multihost 
 is true, and then administrator wants to transfer to normal neutron way, 
 he/she must modify the configuration item and then restart.
 
 I'm afraid I don't follow - are you suggesting that configuring multi-host 
 globally will be harder on admins than the change under review?  Switching to 
 non multi-host under the current proposal involves reconfiguring and 
 restarting of an awful lot of agents, to say nothing of the db changes.
 
 
 m. 
 
 



 On Tue, Aug 27, 2013 at 9:14 AM, Maru Newby ma...@redhat.com wrote:

 On Aug 26, 2013, at 4:06 PM, Edgar Magana emag...@plumgrid.com wrote:

 Hi Developers,

 Let me explain my point of view on this topic and please share your 
 thoughts in order to merge this new feature ASAP.

 My understanding is that multi-host is nova-network HA  and we are 
 implementing this bp 
 https://blueprints.launchpad.net/neutron/+spec/quantum-multihost for the 
 same reason.
 So, If in neutron configuration admin enables multi-host:
 etc/dhcp_agent.ini

 # Support multi host networks
 # enable_multihost = False

 Why do tenants needs to be aware of this? They should just create networks 
 in the way they normally do and not by adding the multihost extension.

 I was pretty confused until I looked at the nova-network HA doc [1].  The 
 proposed design would seem to emulate nova-network's multi-host HA option, 
 where it was necessary to both run nova-network on every compute node and 
 create a network explicitly as multi-host.  I'm not sure why nova-network 
 was implemented in this way, since it would appear that multi-host is 
 basically all-or-nothing.  Once nova-network services are running on every 
 compute node, what does it mean to create a network that is not multi-host?

 So, to Edgar's question - is there a reason other than 'be like 
 nova-network' for requiring neutron multi-host to be configured per-network?


 m.

 1: 
 http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html


 I could be totally wrong and crazy, so please provide some feedback.

 Thanks,

 Edgar


 From: Yongsheng Gong gong...@unitedstack.com
 Date: Monday, August 26, 2013 2:58 PM
 To: Kyle Mestery (kmestery) kmest...@cisco.com, Aaron Rosen 
 aro...@nicira.com, Armando Migliaccio amigliac...@vmware.com, Akihiro 
 MOTOKI amot...@gmail.com, Edgar Magana emag...@plumgrid.com, Maru Newby 
 ma...@redhat.com, Nachi Ueno na...@nttmcl.com, Salvatore Orlando 
 sorla...@nicira.com, Sumit Naiksatam sumit.naiksa...@bigswitch.com, 
 Mark McClain mark.mccl...@dreamhost.com, Gary Kotton 
 gkot...@vmware.com, Robert Kukura rkuk...@redhat.com
 Cc: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: About multihost patch review

 Hi,
 Edgar Magana has commented to say:
 'This is the part that for me is confusing and I will need some 
 clarification from the community. Do we expect to have the multi-host 
 feature as an extension or something that will natural work as long as the 
 deployment include more than one Network Node. In my opinion, Neutron 
 deployments with more than one Network Node by default should call DHCP 
 agents in all those nodes without the need to use an extension. If the 
 community has decided to do this by extensions, then I am fine' at
 https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py

 I have commented back, what is your opinion about it?

 Regards,
 Yong Sheng Gong


 On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) 
 kmest...@cisco.com wrote:
 Hi Yong:

 I'll review this and try it out today.

 Thanks,
 Kyle

 On Aug 15, 2013, at 10:01 PM, Yongsheng Gong gong...@unitedstack.com 
 wrote:

 The multihost patch is there for a long long time, can someone help to 
 review?
 https://review.openstack.org/#/c/37919/




 
 
 

Re: [openstack-dev] [Ceilometer] Documentation and patches

[Tom Fifield]

On 01/09/13 23:02, Anne Gentle wrote:




On Sat, Aug 31, 2013 at 9:09 AM, Lorin Hochstein
lo...@nimbisservices.com mailto:lo...@nimbisservices.com wrote:


On Fri, 30 Aug 2013 08:33:40 -0500, Anne Gentle wrote:


I applaud Julien's note and we're happy to work with the teams on
finding
where docs should go. Julien's feeling very behind, and I'm sure other
projects are feeling the same.

We all have to set priorities. Here's where I'd start.

Log doc bugs in openstack-manuals for:
installation
configuration
day-to-day running
end-user tasks
admin tasks
troubleshooting

Log doc bugs in openstack-api-site for:
API reference docs



Would it help  if doc bugs were associated with the relevant
OpenStack project, in addition to the openstack-manauls project? For
example, we could mark nova-related doc bugs as nova project bugs
in addition to openstack-manuals project bugs.


I like this idea and it seems fairly trivial to do automatically --
teams, unless you see a big problem with this approach I'll patch the
DocImpact automation tool on Monday.


... and I'll do a manual update of the current bug list:

https://launchpad.net/openstack-manuals/+milestone/havana

https://launchpad.net/openstack-api-site/+milestone/havana

which anyone is welcome to work on before then :) even just dumps of 
rant-y text in the bugs you care about welcome!




Anne


This would make outstanding doc issues more visible to the relevant
devs, and would reinforce the idea that missing/incorrect
documentation in, say, nova should be viewed as a *nova* issue and
not simply a *documentation* issue. In particular, it could generate
more doc-focused effort when it comes time for the pre-release bug
squashing activities, since devs will be encouraged to squash those
bugs in their project.

Take care,

Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com https://www.nimbisservices.com/


___
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




--
Anne Gentle
annegen...@justwriteclick.com mailto:annegen...@justwriteclick.com


___
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] [Swift] Small cluster size

[Tom Fifield]

Here's a straw-man:

* 5 storage nodes
* 2 proxy servers

5 storage nodes for a reasonable zone breakdown for 3 replicas; separate
proxy nodes for security segregation (working to avoid unencrypted,
unauthenticated rsync having any chance of leaking through the net) and
network segregation (separating replication traffic); and at 2 proxies
for HA.


Regards,

Tom


On 05/09/13 06:38, Snider, Tim wrote:
 I'd like to get input from the community on a 'realistic' size of a small 
 Swift cluster that might be deployed  used in the field for production. SAIO 
 / test / lab setups aren't a consideration. I'm interested in hearing about 
 both private and public cluster sizes that are deployed for production use.  
 4 nodes or fewer doesn't  seems pretty small - 6 or 8 seems like a more 
 realistic size of a small cluster. But I don't have any actual data/customer 
 experience for those assumptions.
 Followup questions:
 Given that cluster size,  do all nodes act as both Swift proxy and storage 
 nodes? I assume they do.
 How big does a cluster get before node roles are separated?
 Thanks for the input,
 Tim
 
 ___
 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] Vancouver Design Summit format changes

[Tom Fifield]

On 10/01/15 03:26, Michael Dorman wrote:
 (X-posted to -operators.)
 
 Any thoughts on how the ops track spaces would be requested, since there 
 is not a real ‘operators project’, PTL, etc.?

Based on our past events and summit survey feedback from Paris, I've
mentioned to Thierry that we probably need at least:

3 large rooms * 1 day's worth of slots each (for general sessions)
3 small rooms * 1 day's worth of slots each (for working groups)

The content for these should, as Tim mentions, be chosen by discussion.
Previously, etherpad and ops-ml has worked well for us, but open to
other ideas!

In terms of the actual scheduling, I think it makes sense to have the
'general sessions' scheduled in a block so you can find them easily and
just stay there all day. The working group sessions are probably of more
specialised interest and distributing them throughout the week could
actually help people get to more of them compared to running them in
parallel as we did in Paris.


 I assume this would come from the operators group as a whole, so probably 
 something we should put on the agenda at the ops meet up in March.  (I’ve 
 added it to the etherpad.)
 
 Mike
 
 
 
 
 
 On 1/9/15, 2:50 PM, Thierry Carrez thie...@openstack.org wrote:
 
 Hi everyone,

 The OpenStack Foundation staff is considering a number of changes to the
 Design Summit format for Vancouver, changes on which we'd very much like
 to hear your feedback.

 The problems we are trying to solve are the following:
 - Accommodate the needs of more OpenStack projects
 - Reduce separation and perceived differences between the Ops Summit and
 the Design/Dev Summit
 - Create calm and less-crowded spaces for teams to gather and get more
 work done

 While some sessions benefit from large exposure, loads of feedback and
 large rooms, some others are just workgroup-oriented work sessions that
 benefit from smaller rooms, less exposure and more whiteboards. Smaller
 rooms are also cheaper space-wise, so they allow us to scale more easily
 to a higher number of OpenStack projects.

 My proposal is the following. Each project team would have a track at
 the Design Summit. Ops feedback is in my opinion part of the design of
 OpenStack, so the Ops Summit would become a track within the
 forward-looking Design Summit. Tracks may use two separate types of
 sessions:

 * Fishbowl sessions
 Those sessions are for open discussions where a lot of participation and
 feedback is desirable. Those would happen in large rooms (100 to 300
 people, organized in fishbowl style with a projector). Those would have
 catchy titles and appear on the general Design Summit schedule. We would
 have space for 6 or 7 of those in parallel during the first 3 days of
 the Design Summit (we would not run them on Friday, to reproduce the
 successful Friday format we had in Paris).

 * Working sessions
 Those sessions are for a smaller group of contributors to get specific
 work done or prioritized. Those would happen in smaller rooms (20 to 40
 people, organized in boardroom style with loads of whiteboards). Those
 would have a blanket title (like infra team working session) and
 redirect to an etherpad for more precise and current content, which
 should limit out-of-team participation. Those would replace project
 pods. We would have space for 10 to 12 of those in parallel for the
 first 3 days, and 18 to 20 of those in parallel on the Friday (by
 reusing fishbowl rooms).

 Each project track would request some mix of sessions (We'd like 4
 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on
 Friday) and the TC would arbitrate how to allocate the limited
 resources. Agenda for the fishbowl sessions would need to be published
 in advance, but agenda for the working sessions could be decided
 dynamically from an etherpad agenda.

 By making larger use of smaller spaces, we expect that setup to let us
 accommodate the needs of more projects. By merging the two separate Ops
 Summit and Design Summit events, it should make the Ops feedback an
 integral part of the Design process rather than a second-class citizen.
 By creating separate working session rooms, we hope to evolve the pod
 concept into something where it's easier for teams to get work done
 (less noise, more whiteboards, clearer agenda).

 What do you think ? Could that work ? If not, do you have alternate
 suggestions ?

 -- 
 Thierry Carrez (ttx)

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] The state of nova-network to neutron migration

[Tom Fifield]

On 09/01/15 08:06, Maru Newby wrote:
 
 On Jan 8, 2015, at 3:54 PM, Sean Dague s...@dague.net wrote:

 On 01/08/2015 06:41 PM, Maru Newby wrote:
 As per a recent exchange on #openstack-neutron, I’ve been asked to present 
 my views on this effort.  What follows is in no way intended to detract 
 from the hard work and dedication of those undertaking it, but I think that 
 their energy could be better spent.

 At nova’s juno mid-cycle in July, there was a discussion about deprecating 
 nova-network.  Most of the work-items on the TC’s gap analysis [1] had been 
 covered off, with one notable exception: Gap 6, the requirement to provide 
 a migration plan between nova-network and neutron, had stalled over 
 questions of implementation strategy.

 In my recollection of the conversation that followed, broad consensus was 
 reached that the costs of automating a reliable and fault-tolerant 
 migration strategy would be  considerable.  The technical complexity of 
 targeting a fixed deployment scenario would be challenging enough, and 
 targeting heterogenous scenarios would magnify that complexity many-fold.  
 Given the cost and high risks associated with implementing an automated 
 solution, everyone seemed to agree that it was not worth pursuing.  Our 
 understanding was that not pursuing an automated solution could still be in 
 keeping with the TC’s requirements for deprecation, which required that a 
 migration plan be formulated but not that it be automated.  Documentation 
 was deemed sufficient, and that was to be the path forward in covering Gap 
 6.  The documentation would allow deployers and operators to devise 
 migration strategies to suit their individual requirements.

 Then, when the Kilo summit schedule was announced, there was a session 
 scheduled in the nova track for discussing how to implement an automated 
 migration.  I only managed to catch the tail end of the session, but the 
 etherpad [2] makes no mention of the rationale for requiring an automated 
 migration in the first place.  It was like the discussion at the mid-cycle, 
 and all the talk of the risks outweighing the potential benefits of such an 
 effort, had simply not occurred.

 So, in the interests of a full and open discussion on this matter, can 
 someone please explain to me why the risks discussed at the mid-cycle were 
 suddenly deemed justifiable, seemingly against all technical rationale?  
 Criticism has been leveled at the neutron project for our supposed inaction 
 in implementing an automated solution, and I don’t think I’m the only one 
 who is concerned that this is an unreasonable requirement imposed without 
 due consideration to the risks involved.  Yes, most of us want to see 
 nova-network deprecated, but why is the lack of migration automation 
 blocking that?  An automated migration was not a requirement in the TC’s 
 original assessment of the preconditions for deprecation.  I think that if 
 neutron is deemed to be of sufficiently high quality that it can serve as 
 an effective replacement for nova-network, and we can document a migration 
 plan between them, then deprecation should proceed.


 Maru

 The crux of it comes from the fact that the operator voice (especially
 those folks with large nova-network deploys) wasn't represented there.
 Once we got back from the mid-cycle and brought it to the list, there
 was some very understandable push back on deprecating without a
 migration plan.
 
 I think it’s clear that a migration plan is required.  An automated 
 migration, not so much.
 

 I believe we landed at the need for the common case, flat multi host
 networking, to be migrated to something equivalent in neutron land
 (dvr?). And it needs to be something that Metacloud and CERN can get
 behind, as they represent 2 very large nova-network deploys (and have
 reasonably well defined down time allowances for this).

 This doesn't have to be automation for all cases, but we need to support
 a happy path from one to the other that's repeatable, reasonably
 automatic (as much as possible), and provides minimum down time for
 guests running on the environment.
 
 The fact that operators running nova-network would like the upstream 
 community to pay for implementing an automated migration solution for them is 
 hardly surprising.  It is less clear to me that implementing such a solution, 
 with all the attendant cost and risks, should take priority over efforts that 
 benefit a broader swath of the community.  Are the operators in question so 
 strapped for resources that they are not able to automate their migrations 
 themselves, provided a sufficiently detailed plan to do so?

Maru,

This effort does benefit a broad swath of the community.


Regards,


Tom


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

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Tom Fifield]

On 03/03/15 05:35, Clay Gerrard wrote:
 
 
 On Mon, Mar 2, 2015 at 8:07 AM, Duncan Thomas duncan.tho...@gmail.com
 mailto:duncan.tho...@gmail.com wrote:
 
 Why do you say auto-abandon is the wrong tool? I've no problem with
 the 1 week warning if somebody wants to implement it - I can see the
 value. A change-set that has been ignored for X weeks is pretty much
 the dictionary definition of abandoned
 
 
 +1 this
 
 I think Tom's suggested help us help you is a great pre-abandon
 warning.  In swift as often as not the last message ended with something
 like you can catch me on freenode in #openstack-swift if you have any
 questions  
 
 But I really can't fathom what's the harm in closing abandoned patches
 as abandoned?

It might be an interesting exercise to consider how areas like
feedback, criticism or asking for help could potentially differ in
cultures and levels of skill other than the one with which one may be
most familiar.

Now, look at the wording of my above sentence and consider whether you'd
ever write it that way. Pretty damn indirect, and vague right?

It turns out that there are large swathes of the world that operate in
this much more nuanced way. Taking direct action against something
someone has produced using (from their perspective) strong/emotive
language can be at basically the same level as punching someone in the
face and yelling You suck! in other areas :)

I'm sure you are aware of these things - I don't mean to preach, but I
thought it would be a good chance to explain what  what the help us
help you message might come across to these kind of folks:
* This isn't your fault, it's OK!
* We're here to help, and you have permission to ask us for help.
* Here are some steps you can take, and you have permission to take
those steps.
* Here are some standard procedures that everyone follows, so if you
follow them you won't be caught standing out.
* If something happens after this, it's a random third party actor
that's doing it (the system), not a person criticising you.

Anyway, I guess I better dig up jeepyb again ...


 If the author doesn't care about the change enough to address the review
 comments (or failing tests!) and the core reviewers don't care about it
 enough to *fix it for them* - where do we think the change is going to
 go?!  It sounds like the argument is just that instead of using
 abandoned as an explicit description of an implicit state we can just
 filter these out of every view we use to look for something useful as
 no changes for X weeks after negative feedback rather than calling a
 spade a spade.
 
 I *mostly* look at patches that don't have feedback.  notmyname
 maintains the swift review dashboard AFAIK:
 
 http://goo.gl/r2mxbe
 
 It's possible that a pile of abandonded-changes-not-marked-as-abandonded
 wouldn't actually interrupt my work-flow.  But I would imagine
 maintaining the review dashboard might occasionally require looking at
 ALL the changes in the queue in an effort to look for a class of changes
 that aren't getting adequate feedback - that workflow might find the
 extra noise less than helpful.
 
 -Clay
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Tom Fifield]

On 28/02/15 09:02, John Griffith wrote:
 
 
 On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli stef...@openstack.org
 mailto:stef...@openstack.org wrote:
 
 I'm not expressing myself cleary enough. I don't advocate for the
 removal of anything because I like pretty charts. I'm changing the
 subject to be even more clear.
 
 On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote:
  I am asking you to please independently remove changes that you don't
  think should be considered from your metrics.
 
 I'm saying that the reports have indicators that seem to show struggle.
 In a previous message Kevin hinted that probably a reason for those bad
 looking numbers was due to a lot of reviews that appear to have been
 abandoned. This doesn't seem the case because some projects have a
 habit of 'purging'.
 
 I have never explicitly ordered developers to purge anything. If their
 decision to purge is due to the numbers they may have seen on the
 reports I'd like to know.
 
 That said, the problem that the reports highlight remains confirmed so
 far: contributors seem to be left in some cases hanging, for many many
 days, *after a comment* and they don't come back.
 
  I think abandoning changes so that the metrics look the way we
 want is a
  terrible experience for contributors.
 
 I agree, that should not be a motivator. Also, after chatting with you
 on IRC I tend to think that instead of abandoning the review we should
 highlight them and have humans act on them. Maybe build a dashboard of
 'old stuff' to periodically sift through and see if there are things
 worth picking up again or to ping the owner or something else managed by
 humans.
 
 I happened to have found one of such review automatically closed that
 could have been fixed with a trivial edit in commit message instead:
 
 https://review.openstack.org/#/c/98735/
 
 (that owner had a bunch of auto-abandoned patches
 https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%
 2540gmail.com%253E%22,n,z
 https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%
 2540gmail.com%253E%22,n,z). I have made a note to reach out to him and
 get more anecdotes.
 
  Especially as it appears some projects, such as nova, are in a
 position
  where they are actually leaving -2 votes on changes which will not be
  lifted for 2 or 3 months.  That means that if someone runs a
 script like
  Sean's, these changes will be abandoned, yet there is nothing that the
  submitter can do to progress the change in the mean time.  Abandoning
  such a review is making an already bad experience for contributors
 even
  worse.
 
 this sounds like a different issue :(
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ​
 For what it's worth, at one point the Cinder project setup an
 auto-abandon job that did purge items that had a negative mark either
 from a reviewer or from Jenkins and had not been updated in over two
 weeks.  This had absolutely nothing to do with metrics or statistical
 analysis of the project.  We simply had a hard time dealing with patches
 that the submitter didn't care about.  If somebody takes the time to
 review a patch, then I don't think it's too much to ask that the
 submitter respond to questions or comments within a two week period. 
 Note, the auto purge in our case only purged items that had no updates
 or activity at all.
 
 We were actually in a position where we had patches that were submitted,
 failed unit tests in the gate (valid failures that occurred 100% of the
 time) and had sat for an entire release without the submitter ever
 updating the patch. I don't think it's unreasonable at all to abandon
 these and remove them from the queue.  I don't think this is a bad
 thing, I think it's worse to leave them as active when they're
 bit-rotted and the submitter doesn't even care about them any longer. 
 The other thing is, those patches are still there, they can still be
 accessed and reinstated.
 
 There's a lot of knocks against core teams regarding time to review and
 keeping up with the work load.. that's fine, but at the same time if you
 submit something you should follow through on it and respond to comments
 or test failures in a timely manner.  Also there should be some scaling
 factor here; if a patch that needs updating should be expected to be
 able to sit in the queue for a month for example, then we should give
 one month for each reviewer; so minimum of three months for a +1, +2 and +A.
 
 I don't think it's 

Re: [openstack-dev] [nova] Ubuntu, qemu, NUMA support

[Tom Fifield]

On 17/02/15 23:32, Chris Friesen wrote:
 
 Hi all,
 
 Just thought I'd highlight here that Ubuntu 14.10 is using qemu 2.1, but
 they're not currently enabling NUMA support.
 
 I've reported it as a bug and it's been fixed for 15.04, but there is
 some pushback about fixing it in 14.10 on the grounds that it is a
 feature enhancement and not a bugfix:
 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1417937

FYI, it looks like they're OK with it in Utopic now - the package has
been made and is awaiting SRU verification.

 Also, we currently assume that qemu can pin to NUMA nodes.  This is an
 invalid assumption since this was only added as of qemu 2.1, and there
 only if it's compiled with NUMA support.  At the very least we should
 have a version check, but if Ubuntu doesn't fix things then maybe we
 should actually verify the functionality first before trying to use it.
 
 I've opened a bug to track this issue:
 https://bugs.launchpad.net/nova/+bug/1422775

This bug might still be worthwhile, as quite a few folks will likely
stick with Trusty for Kilo. Though, did you by change check the flag
status of the package in the Ubuntu Cloud Archive? It packages a
different Qemu (ver 2.2) to the main repo ...


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] translations gone wild

[Tom Fifield]

On 26/02/15 21:18, Sean Dague wrote:
 This morning in the nova channel we were trying to get to the bottom of
 the unit tests failing lxsi and gillard in en_GB on some string
 comparisons. Something is breaking down in our i18n null fixture for the
 tests.
 
 However, in trying to track down the route of their messages I ran into
 things like this:
 
 https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L1410-L1411
 
 
 https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L3481-L3485
 
 https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L5790-L5793
 
 
 https://github.com/openstack/nova/blob/master/nova/locale/en_US/LC_MESSAGES/nova.po#L3278-L3282
 
 
 
 So, correct me if I'm wrong, but I think that means that when running in
 en_US those log messages are going to get overridden. And in many of
 these cases they are getting overridden to completely unrelated messages.
 
 That seems quite dangerous. Is there a reason that en_US locale tree
 exists at all (given that we've treated it as base locale historically).
 It seems like it's existence can only cause issues.
 
 What's the right way to test / checkpoint on this on a regular basis?
 
   -Sean


en_US does not exist on transifex. It existed once by mistake, but was
later removed. This is probably why it's in a weird state. I think that
file should be deleted.


Regards,


Tom


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

[Tom Fifield]

On 24/02/15 19:27, Daniel P. Berrange wrote:
 On Tue, Feb 24, 2015 at 12:05:17PM +0100, Thierry Carrez wrote:
 Daniel P. Berrange wrote:
 [...]

First, Daniel, thank you for the well-written and thought-through post.
I have some comments on translation specifically which I hope can shed
some light on this particular horizontal effort.

With the idea as stated below implemented, I think it would basically
demoralise our translation teams to the point they'd give up. We already
get complaints about people not respecting string freeze as it is :D


 I'm not familiar with how the translations works, but if they are
 waiting until the freeze before starting translation work I'd
 say that is a mistaken approach. Obviously during active dev part
 of the cycle, some translated strings are in flux, so if translation
 was taking place in parallel there could be some wasted effort, but
 I'd expect that to be the minority case. I think the majority of
 translation work can be done in parallel with dev work and the freeze
 time just needs to tie up the small remaining bits.


So, two points:

1) We wouldn't be talking about throwing just a couple of percent of
their work away.

As an example, even without looking at the introduction of new strings
or deleting others, you may not be aware that changing a single word in
a string in the code means that entire string needs to be re-translated.
Even with the extensive translation memory systems we have making
suggestions as best they can, we're talking about very, very significant
amounts of wasted effort. Something as simple as adding ing on a
verb to fix an English grammar mistake means a completely different
sentence in languages I'm familiar with.


2) The overwhelming majority of our [hundreds of] translators are
volunteers.

Unlike many of those writing the software, they are not paid to do what
they do, and do it in their spare time. Make it less fun, and they
simply walk away.



To try and put this in a way that may be more understandable for a
non-translator ... your (impressive!) original email in this thread was
around 3000 words. Translatable strings in horizon is around five times
that at the moment. So imagine that, when writing an email five times
longer than the one you wrote, unpaid, someone you don't really know
that well decided that the section on the key observations (230 words
- about 1% of the text of our 'horizon') you just wrote should be
re-arranged - the order of the observations changed, one of them removed
and replaced with another slightly different one, and the conclusion
paragraph wording should be amended to suit.

It would be an understatement to say that such behaviour would be
'annoying' if it happened constantly as you were writing your email.
Consider then if it applied to every email you sought to write :)

Now, the amount of string changes within a release can be left for
someone to work out, but it's certainly a great deal more than a single
percent. Multiply that poor experience by the reality of string change
across all the projects we want to translate. Then multiply it by the
number of languages we want. Finally, multiply it by the number of
people we need to translate a single language. That's a really bad time
for a whole lot of people.


At the moment we're fixing this with string freeze, and that's generally
going pretty well. Right now I don't have a good solution if the strings
in code never stop changing for any period of time, but what has been
proposed above while well-meaning is unfortunately not workable.

We really need to keep our translators as happy as we can. People who
are literate in multiple languages are difficult to find, moreso those
who have technical vocabulary experience in both, and even moreso those
who'll give up their time to help us reach our mission goal of being the
ubiquitous Open Source Cloud Computing platform. We do need them to
achieve it.


Regards,


Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

[Tom Fifield]

On 14/04/15 23:36, Dean Troyer wrote:

On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
mangel...@redhat.com mailto:mangel...@redhat.com wrote:

Why would operators install from devstack? that’s not going to be
the case.


If they do they need more help than we can give...


So, ummm, there is actually a valid use case for ops on devstack: it's 
part of the learning process.


In my rounds, I've had feedback from more than a few whose first 
OpenStack experience was to run up a devstack, so they could run ps 
aufx, brctl, iptables, etc just to see what was going on under the 
covers before moving on to something more 'proper'.



While acknowledging that the primary purpose and audience of devstack is 
and should remain development and developers, if there is something we 
can do to improve the experience for those ops first-timers that doesn't 
have a huge impact on devs, it would be kinda nice.


After all, one of the reasons this thread exists is because of problems 
with that ramp up process, no?





I believe we should have both LB  OVS well tested, if LB is a good
option for
some operators willing to migrate from nova, that’s great, let’s
make sure LB
is perfectly tested upstream.


+1

But by doing such change we can’t let OVS code rot and we would be
neglecting
a big customer base which is now making use of the openvswitch
mechanism.
(may be I’m miss understanding  the scope of the change).


Changing DevStack's default doesn't remove anything OVS-related, nor
does it by itself remove any OVS jobs.  It gives everyone who is happy
with nova-net (or more correctly doesn't think about it) a new default
that changes their experience the least for when nova-net disappears.

dt

--

Dean Troyer
dtro...@gmail.com mailto:dtro...@gmail.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

[Tom Fifield]

On 16/04/15 10:54, Fox, Kevin M wrote:

Yes, but if stuff like dvr is the only viable replacement to
nova-network in production, then learning the non representitive config
of neutron with linuxbridge might be misleading/counter productive since
ovs looks very very different.


Sure, though on the other hand, doesn't current discussion seem to 
indicate that OVS with DVR is not a viable replacement for nova-network 
multi-host HA (eg due to complexity), and this is why folks were working 
towards linux bridge?


In essence: if linux bridge was a viable nova-network multi-host HA 
replacement, you'd be OK with this change?




Kevin *
*

*From:* Tom Fifield
*Sent:* Wednesday, April 15, 2015 5:58:43 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the
default in DevStack [was: Status of the nova-network to Neutron
migration work]



On 14/04/15 23:36, Dean Troyer wrote:

On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
mangel...@redhat.com mailto:mangel...@redhat.com wrote:

Why would operators install from devstack? that’s not going to be
the case.


If they do they need more help than we can give...


So, ummm, there is actually a valid use case for ops on devstack: it's
part of the learning process.

In my rounds, I've had feedback from more than a few whose first
OpenStack experience was to run up a devstack, so they could run ps
aufx, brctl, iptables, etc just to see what was going on under the
covers before moving on to something more 'proper'.


While acknowledging that the primary purpose and audience of devstack is
and should remain development and developers, if there is something we
can do to improve the experience for those ops first-timers that doesn't
have a huge impact on devs, it would be kinda nice.

After all, one of the reasons this thread exists is because of problems
with that ramp up process, no?




I believe we should have both LB  OVS well tested, if LB is a good
option for
some operators willing to migrate from nova, that’s great, let’s
make sure LB
is perfectly tested upstream.


+1

But by doing such change we can’t let OVS code rot and we would be
neglecting
a big customer base which is now making use of the openvswitch
mechanism.
(may be I’m miss understanding  the scope of the change).


Changing DevStack's default doesn't remove anything OVS-related, nor
does it by itself remove any OVS jobs.  It gives everyone who is happy
with nova-net (or more correctly doesn't think about it) a new default
that changes their experience the least for when nova-net disappears.

dt

--

Dean Troyer
dtro...@gmail.com mailto:dtro...@gmail.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]

[Tom Fifield]

On 17/04/15 03:09, Assaf Muller wrote:



- Original Message -

if linux bridge was a viable nova-network multi-host HA replacement, you'd
be OK with this change?

I'd be much more in favor of it. yes. Though I think its a long way from
being there...

planet openstack has a nice set of articles on how dvr works right now,


Thank you :)


and having read through, I think its going to be very difficult to implement
that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge
has nothing like that as far as I know.


To be brutally honest I think that any solution that tries to implement DVR
with Linux bridge will be shot down by the Neutron community. We're already
struggling to maintain DVR, polish it and have it well tested. Adding more
complexity seems outright insane to me and I suspect that others will share
the sentiment.



Because of that, I would expect that as DVR matures, the LinuxBridge
implementation will wither further on the vine. :/

Just my 2 cents. Ops will probably need to consider the complexity
necessary, just like the linux kernel is complex but in the end, the
complexity is well worth it.


That's what Neutron developers are likely to say.


... and so we go around in the circle again, because:


The biggest disconnect in the model seems to be that Neutron assumes
you want self service networking. Most of these deploys don't. Or even
more importantly, they live in an organization where that is never
going to be an option.


http://lists.openstack.org/pipermail/openstack-dev/2015-March/058801.html


So, if ops don't need and/or can't use the features the additional 
complexity provides, there's no way they'll consider the complexity 
necessary, and will keep using nova-network :)



In addition - we kinda have part of our mission statement that has the 
words simple to implement, so it's very rarely OK to say just eat up 
the complexity, kthxbai.







To get a truly scalable NaaS, which I think is critical, you need advanced
SDN and I'm not convinced LinuxBridge is advanced enough to work long
term...

Thanks,
Kevin


From: Tom Fifield [t...@openstack.org]
Sent: Wednesday, April 15, 2015 7:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in
DevStack [was: Status of the nova-network to Neutron migration work]

On 16/04/15 10:54, Fox, Kevin M wrote:

Yes, but if stuff like dvr is the only viable replacement to
nova-network in production, then learning the non representitive config
of neutron with linuxbridge might be misleading/counter productive since
ovs looks very very different.


Sure, though on the other hand, doesn't current discussion seem to
indicate that OVS with DVR is not a viable replacement for nova-network
multi-host HA (eg due to complexity), and this is why folks were working
towards linux bridge?

In essence: if linux bridge was a viable nova-network multi-host HA
replacement, you'd be OK with this change?



Kevin *
*

*From:* Tom Fifield
*Sent:* Wednesday, April 15, 2015 5:58:43 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the
default in DevStack [was: Status of the nova-network to Neutron
migration work]



On 14/04/15 23:36, Dean Troyer wrote:

On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo
mangel...@redhat.com mailto:mangel...@redhat.com wrote:

 Why would operators install from devstack? that’s not going to be
 the case.


If they do they need more help than we can give...


So, ummm, there is actually a valid use case for ops on devstack: it's
part of the learning process.

In my rounds, I've had feedback from more than a few whose first
OpenStack experience was to run up a devstack, so they could run ps
aufx, brctl, iptables, etc just to see what was going on under the
covers before moving on to something more 'proper'.


While acknowledging that the primary purpose and audience of devstack is
and should remain development and developers, if there is something we
can do to improve the experience for those ops first-timers that doesn't
have a huge impact on devs, it would be kinda nice.

After all, one of the reasons this thread exists is because of problems
with that ramp up process, no?




 I believe we should have both LB  OVS well tested, if LB is a good
 option for
 some operators willing to migrate from nova, that’s great, let’s
 make sure LB
 is perfectly tested upstream.


+1

 But by doing such change we can’t let OVS code rot and we would be
 neglecting
 a big customer base which is now making use of the openvswitch
 mechanism.
 (may be I’m miss understanding  the scope of the change).


Changing DevStack's default doesn't remove anything OVS-related, nor
does it by itself remove any OVS jobs.  It gives everyone who is happy

Re: [openstack-dev] [Manila] Question on documentation reviews

[Tom Fifield]

On 08/04/15 03:36, Ben Swartzlander wrote:
 On 04/07/2015 12:58 PM, Luis Pabon wrote:
 Hi guys,
I have been reviewing https://review.openstack.org/#/c/171166/, but
 I am concerned that I provided more of a hindrance than assistance.
 Instead I would like to propose the method used by Swift for document
 reviews, where reviewers provide a patch to the author as in
 https://review.openstack.org/#/c/169990 .

 What do you think?
 
 Makes sense to me. We should definitely discuss this at the weekly
 meeting, but it seems like for certain types of edits it would be
 dramatically more efficient.
 
 I can think of 3 possible issues:
 1) If we allow this, then authors will have to be careful about pulling
 the lateset patchset from gerrit before they make their changes, to
 avoid accidentally clobbering changes from other authors.
 2) Reviewers would need to talk to the original author before pushing
 another patchset in case the original author was working on a second
 draft or responding to comments from other reviews -- the reviewer
 wouldn't want to clobber the original's author's unsubmitted work.
 3) Presumably for small edits, the existing scheme is still more
 efficient, so reviewers will have to make a judgement call whether to
 leave comments or push a patch.
 
 We'd need guidelines to cover the above 3 situations.

This wording (from over at openstack-manuals) might be helpful:

https://etherpad.openstack.org/p/docs-fixed-it-for-you

Regards,


Tom


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] Openstack Diversity Working Group

[Tom Fifield]

If anyone needs help with the timezone conversion, I recommend

http://www.timeanddate.com/worldclock/meeting.html

Just put in Portland and your nearest city into the boxes and you'll
get an hour-by-hour breakdown :)

On 10/06/15 23:39, Barrett, Carol L wrote:
 The Doodle time zone doesn’t seem to be appearing in the local timebased
 upon the viewer.
 
  
 
 Sorry – The time zone is US/Pacific time (UTC-7), you’ll need to do your
 own conversion.
 
  
 
 Thanks
 
 Carol
 
  
 
 *From:*Sousou, Imad [mailto:imad.sou...@intel.com]
 *Sent:* Tuesday, June 09, 2015 11:34 AM
 *To:* foundat...@lists.openstack.org; openst...@lists.openstack.org;
 commun...@lists.openstack.org; foundation-bo...@lists.openstack.org;
 openstack-dev@lists.openstack.org
 *Subject:* [OpenStack Foundation] Openstack Diversity Working Group
 
  
 
 Stackers – We’re happy to announce the creation of a Diversity Working
 Group. The genesis for this work group was a discussion at the May
 meeting of the OpenStack Board of Directors ahead of the Vancouver Summit.
 
  
 
 The Board is committed to fostering an inclusive and welcoming place for
 all people to collaborate to drive innovation and design cutting-edge
 data center capabilities, while finding the best answers to our most
 pressing challenges. To achieve this, the Board formed this Work Group
 to determine what actions are required to fulfill this commitment. Three
 Board members volunteered to work with community members in this Work
 Group and bring updates/requests to the Board for discussion and action
 on a regular basis, starting with the July meeting.
 
  
 
 If you’re interested in joining this effort, please:
 
 · Join the Foundation mail list to participate in discussions
 and shape the direction: click here
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
 
 · Visit the wiki page for this work group to learn more about
 the charter: click here https://wiki.openstack.org/wiki/Diversity
 
 · Plan to join the kick-off IRC meeting and let us know what
 day/times work for you by accessing the Doodle here: click here
 http://doodle.com/z85c23dtexx8qzq7
 
  
 
 We will send out the results of the Doodle to the mail list and look
 forward to working with you to foster a strong and diverse community.
 
  
 
 Thanks
 
 Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)
 
  
 
  
 
  
 
  
 
  
 
  
 
  
 
 
 
 ___
 Foundation mailing list
 foundat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Need help! Zuul can not connect to port 29418 of review.openstack.org

[Tom Fifield]

On 12/06/15 17:04, liuxinguo wrote:

Hi,

Recentlyour CI can not connect to port 29418 of
review.openstack.org.app:ds:recently

Following are the failuer message, is there anyone know the reasion why
our CI can not cennect to 29418 of review.openstack.org?



That port on review.openstack.org currently appears to be blocked by 
China country-level firewall.


In this case, changing access from SSH to HTTPS could help avoid the
block, like in Clark's email:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html


Regards,


Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack Foundation] Openstack Diversity Working Group

[Tom Fifield]

It turns out that if you accidentally forgot to enable timezone support
when creating a doodle poll (the link isn't exactly the easiest to
remember), you can't turn it on later.


Regards,


Tom

On 11/06/15 03:15, Tristan Goode wrote:
 Why not just enable time zone support for the doodle poll? That would be
 a good example of improving diversity by being inclusive.
 
 Cheers
 Tristan
 
 
 
 
 On Wed, Jun 10, 2015 at 8:50 AM -0700, Tom Fifield t...@openstack.org
 mailto:t...@openstack.org wrote:
 
 If anyone needs help with the timezone conversion, I recommend
 
 http://www.timeanddate.com/worldclock/meeting.html
 
 Just put in Portland and your nearest city into the boxes and you'll
 get an hour-by-hour breakdown :)
 
 On 10/06/15 23:39, Barrett, Carol L wrote:
  The Doodle time zone doesn’t seem to be appearing in the local timebased
  upon the viewer.
  
   
  
  Sorry – The time zone is US/Pacific time (UTC-7), you’ll need to do your
  own conversion.
  
   
  
  Thanks
  
  Carol
  
   
  
  *From:*Sousou, Imad [mailto:imad.sou...@intel.com]
  *Sent:* Tuesday, June 09, 2015 11:34 AM
  *To:* foundat...@lists.openstack.org; openst...@lists.openstack.org;
  commun...@lists.openstack.org; foundation-bo...@lists.openstack.org;
  openstack-dev@lists.openstack.org
  *Subject:* [OpenStack Foundation] Openstack Diversity Working Group
  
   
  
  Stackers – We’re happy to announce the creation of a Diversity Working
  Group. The genesis for this work group was a discussion at the May
  meeting of the OpenStack Board of Directors ahead of the Vancouver 
 Summit.
  
   
  
  The Board is committed to fostering an inclusive and welcoming place for
  all people to collaborate to drive innovation and design cutting-edge
  data center capabilities, while finding the best answers to our most
  pressing challenges. To achieve this, the Board formed this Work Group
  to determine what actions are required to fulfill this commitment. Three
  Board members volunteered to work with community members in this Work
  Group and bring updates/requests to the Board for discussion and action
  on a regular basis, starting with the July meeting.
  
   
  
  If you’re interested in joining this effort, please:
  
  · Join the Foundation mail list to participate in discussions
  and shape the direction: click here
  
  
  · Visit the wiki page for this work group to learn more about
  the charter: click here 
  
  · Plan to join the kick-off IRC meeting and let us know what
  day/times work for you by accessing the Doodle here: click here
  
  
   
  
  We will send out the results of the Doodle to the mail list and look
  forward to working with you to foster a strong and diverse community.
  
   
  
  Thanks
  
  Imad Sousou (Intel), Egle Sigler (Rackspace), Kavit Munshi (Aptira)
  
   
  
   
  
   
  
   
  
   
  
   
  
   
  
  
  
  ___
  Foundation mailing list
  foundat...@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
  
 
 
 ___
 Foundation mailing list
 foundat...@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Can not connect to host review.openstack.org port 29418

[Tom Fifield]

On 11/06/15 11:33, 苌智 wrote:
 I met problem when run git review. It says that  ssh: connect to host
 review.openstack.org port 29418: No route to host . There is no
 response when I run telnet review.openstack.org 29418. And my screen
 only displays Trying 104.130.159.134 Does anyone meets the same
 problem as me? 

Still working for me.

Based on greatfire.org, it currently appears to be blocked by China
country-level firewall.

In this case, changing access from SSH to HTTPS could help avoid the
block, like in Clark's email:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html


Regards,


Tom


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

[Tom Fifield]

Many thanks to Thomas and the other packagers for a great discussion at
the summit and this fast follow-up, explained well. Looking forward to
seeing what can be achieved!

On 27/05/15 16:14, Thomas Goirand wrote:
 Hi all,
 
 tl;dr:
 - We'd like to push distribution packaging of OpenStack on upstream
 gerrit with reviews.
 - The intention is to better share the workload, and improve the overall
 QA for packaging *and* upstream.
 - The goal is *not* to publish packages upstream
 - There's an ongoing discussion about using stackforge or openstack.
 This isn't, IMO, that important, what's important is to get started.
 - There's an ongoing discussion about using a distribution specific
 namespace, my own opinion here is that using /openstack-pkg-{deb,rpm} or
 /stackforge-pkg-{deb,rpm} would be the most convenient because of a
 number of technical reasons like the amount of Git repository.
 - Finally, let's not discuss for too long and let's do it!!! :)
 
 Longer version:
 
 Before I start: some stuff below is just my own opinion, others are just
 given facts. I'm sure the reader is smart enough to guess which is what,
 and we welcome anyone involved in the project to voice an opinion if
 he/she differs.
 
 During the Vancouver summit, operation, Canonical, Fedora and Debian
 people gathered and collectively expressed the will to maintain
 packaging artifacts within upstream OpenStack Gerrit infrastructure. We
 haven't decided all the details of the implementation, but spent the
 Friday morning together with members of the infra team (hi Paul!) trying
 to figure out what and how.
 
 A number of topics have been raised, which needs to be shared.
 
 First, we've been told that such a topic deserved a message to the dev
 list, in order to let groups who were not present at the summit. Yes,
 there was a consensus among distributions that this should happen, but
 still, it's always nice to let everyone know.
 
 So here it is. Suse people (and other distributions), you're welcome to
 join the effort.
 
 - Why doing this
 
 It's been clear to both Canonical/Ubuntu teams, and Debian (ie: myself)
 that we'd be a way more effective if we worked better together, on a
 collaborative fashion using a review process like on upstream Gerrit.
 But also, we'd like to welcome anyone, and especially the operation
 folks, to contribute and give feedback. Using Gerrit is the obvious way
 to give everyone a say on what we're implementing.
 
 As OpenStack is welcoming every day more and more projects, it's making
 even more sense to spread the workload.
 
 This is becoming easier for Ubuntu guys as Launchpad now understand not
 only BZR, but also Git.
 
 We'd start by merging all of our packages that aren't core packages
 (like all the non-OpenStack maintained dependencies, then the Oslo libs,
 then the clients). Then we'll see how we can try merging core packages.
 
 Another reason is that we believe working with the infra of OpenStack
 upstream will improve the overall quality of the packages. We want to be
 able to run a set of tests at build time, which we already do on each
 distribution, but now we want this on every proposed patch. Later on,
 when we have everything implemented and working, we may explore doing a
 package based CI on every upstream patch (though, we're far from doing
 this, so let's not discuss this right now please, this is a very long
 term goal only, and we will have a huge improvement already *before*
 this is implemented).
 
 - What it will *not* be
 ===
 We do not have the intention (yet?) to publish the resulting packages
 built on upstream infra. Yes, we will share the same Git repositories,
 and yes, the infra will need to keep a copy of all builds (for example,
 because core packages will need oslo.db to build and run unit tests).
 But we will still upload on each distributions on separate repositories.
 So published packages by the infra isn't currently discussed. We could
 get to this topic once everything is implemented, which may be nice
 (because we'd have packages following trunk), though please, refrain to
 engage in this topic right now: having the implementation done is more
 important for the moment. Let's try to stay on tracks and be constructive.
 
 - Let's keep efficiency in mind
 ===
 Over the last few years, I've been able to maintain all of OpenStack in
 Debian with little to no external contribution. Let's hope that the
 Gerrit workflow will not slow down too much the packaging work, even if
 there's an unavoidable overhead. Hopefully, we can implement some
 liberal ACL policies for the core reviewers so that the Gerrit workflow
 don't slow down anyone too much. For example we may be able to create
 new repositories very fast, and it may be possible to self-approve some
 of the most trivial patches (for things like typo in a package
 description, adding new debconf translations, and such obvious fixes, we
 shouldn't 

Re: [openstack-dev] App Catalog IRC meeting minutes - 7/2/2015

[Tom Fifield]

On 07/07/15 04:25, Christopher Aedo wrote:
 * Stale URL checker (gosha)  (docaedo, 17:27:48)

The docs-tools repository has a tool that does this that can probably be
re-purposed.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

[Tom Fifield]

On 19/08/15 11:52, Edgar Magana wrote:

Folks,

I just want to share with you the feedback collected today during the
networking session on Ops Meet-up:
https://etherpad.openstack.org/p/PAO-ops-network-model

Special thanks to Ryan and Doug for helping on some questions.


Line 28 on https://etherpad.openstack.org/p/PAO-ops-deployment-tips also 
has some stuff on networking


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] User Survey Results - October 2015

[Tom Fifield]

Hi everyone,

Working with the user committee, we run a survey of users every six 
months. We are pleased to share the results of the latest survey, 
conducted in September.


Each survey is meant to provide a sample representation of OpenStack 
users and deployment profiles, with the goals to identify challenges and 
help inform developers planning the next release, help other users 
understand technology decisions made by their peers and help the 
ecosystem better understand the user profile and needs.



You can download the full report at:

 http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf


This would not be possible without the efforts of users and application 
developers to fill out the survey, and our entire community to help 
shape it. We hope this data and feedback will be a good resource heading 
into the Tokyo summit planning sessions and discussions




Thank you for all of your support and input, and see you at the summit!




Regards,




Tom, on behalf of the User Committee and Foundation Team


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Tom Fifield]

On 13/10/15 21:13, Vladimir Kuklin wrote:

Puppetmaster and Fuelers,

Last week I mentioned that I would like to bring the theme of using
native ruby OpenStack client and use it within the providers.

Emilien told me that I had already been late and the decision was made
that puppet-openstack decided to not work with Aviator based on [0]. I
went through this thread and did not find any unresolvable issues with
using Aviator in comparison with potential benefits it could have
brought up.

What I saw actually was like that:

* Pros

1) It is a native ruby client
2) We can import it in puppet and use all the power of Ruby
3) We will not need to have a lot of forks/execs for puppet
4) You are relying on negotiated and structured output provided by API
(JSON) instead of introducing workarounds for client output like [1]

* Cons

1) Aviator is not actively supported
2) Aviator does not track all the upstream OpenStack features while
native OpenStack client does support them
3) Ruby community is not really interested in OpenStack (this one is
arguable, I think)

* Proposed solution

While I completely understand all the cons against using Aviator right
now, I see that Pros above are essential enough to change our mind and
invest our own resources into creating really good OpenStack binding in
Ruby.
Some are saying that there is not so big involvement of Ruby into
OpenStack. But we are actually working with Puppet/Ruby and are invloved
into community. So why should not we own this by ourselves and lead by
example here?

I understand that many of you do already have a lot of things on their
plate and cannot or would not want to support things like additional
library when native OpenStack client is working reasonably well for you.
But if I propose the following scheme to get support of native Ruby
client for OpenStack:

1) we (community) have these resources (speaking of the company I am
working for, we at Mirantis have a set of guys who could be very
interested in working on Ruby client for OpenStack)
2) we gradually improve Aviator code base up to the level that it
eliminates issues that are mentioned in  'Cons' section
3) we introduce additional set of providers and allow users and
operators to pick whichever they want
4) we leave OpenStackClient default one

Would you support it and allow such code to be merged into upstream
puppet-openstack modules?


Hi,

I'm just throwing this out there since I didn't see it mentioned in 
either this thread or the linked one on the puppet-openstack ML, but ...


... has anyone looked into fog (http://fog.io/ ) ?


In my experience it generally works, and is updated fairly frequently.



Regards,


Tom




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] Anyone using containers?

[Tom Fifield]

On 02/09/15 17:36, Thierry Carrez wrote:

Lowery, Mathew wrote:

Just curious if anyone is using containers in their deployments. If so,
in what capacity? What are the advantages, gotchas, and pain points?


This might trigger more responses on the openstack-operators mailing-list.



+1 :)

There are a few notes on using containers for deployment from the recent 
ops meetup here: 
https://etherpad.openstack.org/p/PAO-ops-containers-for-deployment



Regards,

Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing Liberty RC1 availability in Debian

[Tom Fifield]

On 30/09/15 19:58, Thomas Goirand wrote:

Hi everyone!

1/ Announcement
===

I'm pleased to announce, in advance of the final Liberty release, that
Liberty RC1 not only has been fully uploaded to Debian Experimental, but
also that the Tempest CI (which I maintain and is a package only CI, no
deployment tooling involved), shows that it's also fully installable and
working. There's still some failures, but these are, I am guessing, not
due to problems in the packaging, but rather some Tempest setup problems
which I intend to address.

If you want to try out Liberty RC1 in Debian, you can either try it
using Debian Sid + Experimental (recommended), or use the Jessie
backport repository built out of Mirantis Jenkins server. Repositories
are listed at this address:

http://liberty-jessie.pkgs.mirantis.com/

2/ Quick note about Liberty Debian repositories
===

During Debconf 15, someone reported that the fact the Jessie backports
are on a Mirantis address is disturbing.

Note that, while the above really is a non-Debian (ie: non official
private) repository, it only contains unmodified source packages, only
just rebuilt for Debian Stable. Please don't be afraid by the tainted
"mirantis.com" domain name, I could have as well set a debian.net
address (which has been on my todo list for a long time). But it is
still Debian only packages. Everything there is strait out of Debian
repositories, nothing added, modified or removed.

I believe that Liberty release in Sid, is currently working very well,
but I haven't tested it as much as the Jessie backport.

Started with the Kilo release, I have been uploading packages to the
official Debian backports repositories. I will do so as well for the
Liberty release, after the final release is out, and after Liberty is
fully migrated to Debian Testing (the rule for stable-backports is that
packages *must* be available in Testing *first*, in order to provide an
upgrade path). So I do expect Liberty to be available from
jessie-backports maybe a few weeks *after* the final Liberty release.
Before that, use the unofficial Debian repositories.

3/ Horizon dependencies still in NEW queue
==

It is also worth noting that Horizon hasn't been fully FTP master
approved, and that some packages are still remaining in the NEW queue.
This isn't the first release with such an issue with Horizon. I hope
that 1/ FTP masters will approve the remaining packages son 2/ for
Mitaka, the Horizon team will care about freezing external dependencies
(ie: new Javascript objects) earlier in the development cycle. I am
hereby proposing that the Horizon 3rd party dependency freeze happens
not later than Mitaka b2, so that we don't experience it again for the
next release. Note that this problem affects both Debian and Ubuntu, as
Ubuntu syncs dependencies from Debian.

5/ New packages in this release
===

You may have noticed that the below packages are now part of Debian:
- Manila
- Aodh
- ironic-inspector
- Zaqar (this one is still in the FTP masters NEW queue...)

I have also packaged a few more, but there are still blockers:
- Congress (antlr version is too low in Debian)
- Mistral

6/ Roadmap for Liberty final release


Next on my roadmap for the final release of Liberty, is finishing to
upgrade the remaining components to the latest version tested in the
gate. It has been done for most OpenStack deliverables, but about a
dozen are still in the lowest version supported by our global-requirements.

There's also some remaining work:
- more Neutron drivers
- Gnocchi
- Address the remaining Tempest failures, and widen the scope of tests
(add Sahara, Heat, Swift and others to the tested projects using the
Debian package CI)

I of course welcome everyone to test Liberty RC1 before the final
release, and report bugs on the Debian bug tracker if needed.

Also note that the Debian packaging CI is fully free software, and part
of Debian as well (you can look into the openstack-meta-packages package
in git.debian.org, and in openstack-pkg-tools). Contributions in this
field are also welcome.

7/ Thanks to Canonical & every OpenStack upstream projects
==

I'd like to point out that, even though I did the majority of the work
myself, for this release, there was a way more collaboration with
Canonical on the dependency chain. Indeed, for this Liberty release,
Canonical decided to upload every dependency to Debian first, and then
only sync from it. So a big thanks to the Canonical server team for
doing community work with me together. I just hope we could push this
even further, especially trying to have consistency for Nova and Neutron
binary package names, as it is an issue for Puppet guys.

Last, I would like to hereby thanks everyone who helped me fixing issues
in these packages. Thank you if you've 

Re: [openstack-dev] Mitaka travel tips ?

[Tom Fifield]

On 24/09/15 16:43, Thierry Carrez wrote:

David Moreau Simard wrote:

There was a travel tips document for the Kilo summit in Paris [1].
Lots of great helpful information in there not covered on the Openstack
Summit page [2] like where to get SIM cards and stuff.

Is there one for Mitaka yet ? I can't find it.


There isn't one yet (that I know of). In Paris (and Hong-Kong) it was
created by the local OpenStack user group, so hopefully the Japanese
user group will set up something :)



I found some! buried in the FAQ!

https://www.openstack.org/summit/tokyo-2015/faq/#Category-5

but, maybe we need a wiki page to collect more. I suggest:

https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Travel_Tips


Regards,


Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack-Announce List

[Tom Fifield]

... and back to this thread after a few weeks :)

The conclusions I saw were:
* Audience for openstack-announce should be "users/non-dev"
* Service project releases announcements are good
* Client library release announcements good
* Security announcements are good
* Internal library (particularly oslo) release announcements don't fit

Open Questions:
* Where do Internal library release announcements go? [-dev or new 
-release list or batched inside the weekly newsletter]

* Do SDK releases fit on -announce?


Regards,


Tom


On 20/11/15 12:00, Tom Fifield wrote:

Hi all,

I'd like to get your thoughts about the OpenStack-Announce list.

We describe the list as:

"""
Subscribe to this list to receive important announcements from the
OpenStack Release Team and OpenStack Security Team.

This is a low-traffic, read-only list.
"""

Up until July 2015, it was used for the following:
* Community Weekly Newsletter
* Stable branch release notifications
* Major (i.e. Six-monthly) release notifications
* Important security advisories

and had on average 5-10 messages per month.

After July 2015, the following was added:
* Release notifications for clients and libraries (one email per
library, includes contributor-focused projects)

resulting in an average of 70-80 messages per month.


Personally, I no longer consider this volume "low traffic" :)

In addition, I have been recently receiving feedback that users have
been unsubscribing from or deleting without reading the list's posts.

That isn't good news, given this is supposed to be the place where we
can make very important announcements and have them read.

One simple suggestion might be to batch the week's client/library
release notifications into a single email. Another might be to look at
the audience for the list, what kind of notifications they want, and
chose the announcements differently.

What do you think we should do to ensure the announce list remains useful?



Regards,


Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack-Announce List

[Tom Fifield]

On 14/12/15 19:33, Thierry Carrez wrote:

Tom Fifield wrote:

... and back to this thread after a few weeks :)

The conclusions I saw were:
* Audience for openstack-announce should be "users/non-dev"
* Service project releases announcements are good
* Client library release announcements good
* Security announcements are good
* Internal library (particularly oslo) release announcements don't fit

Open Questions:
* Where do Internal library release announcements go? [-dev or new
-release list or batched inside the weekly newsletter]


I'd say -dev + batched inside the weekly -dev digest from thingee (and
crosspost that one to -announce). Even if the audience is "users" I
think getting a weekly digest from the -dev ML can't hurt ?


Yup, feedback I have says it's enjoyed cross-discipline :)


* Do SDK releases fit on -announce?


I guess they could -- how many of those are we expecting ?



So far it looks close to zero emails :) PythonSDK is the only one that's 
in the OpenStack namespace I can see at quick search.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [doc] DocImpact vs. reno

[Tom Fifield]

On 08/01/16 21:15, Sean Dague wrote:

On 01/07/2016 06:21 PM, Lana Brindley wrote:



On 7 Jan 2016, at 2:09 AM, Sean Dague  wrote:

On 01/06/2016 09:02 AM, Jeremy Stanley wrote:

On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
[...]

I think auto openning against a project, and shuffling it to
manuals manually (with details added by humans) would be fine.

It's not clear to me why a new job was required for that.


The new check job was simply a requirement of the Docs team, since
they were having trouble triaging auto-generated bugs they were
receiving and wanted to enforce the inclusion of some expository
metadata.


Sure, but if that triage is put back on the Nova team, that seems fine.


So you’re thinking we should make all docimpact bugs go to the project bug 
queue? Even for defcore?


Yes, because then it would be the responsibility of the project team to
ensure there is enough info before passing it onto the docs team.




It also doesn't make sense to me there would be a DocImpact change that
wouldn't also have a reno section. The reason someone thinks that a
change needs reflection in the manual is that it adds/removes/changes a
feature that would also show up in release notes. Perhaps my imagination
isn't sufficient to come up with a scenario where DocImpact is valid,
but we wouldn't have content in one of those sections.


I can think of plenty. What about where a command is changed slightly? Or an 
output is formatted differently? Or where flags have been removed, or default 
values changed, or ….


Nearly all of those changes have been triggering release notes at this
point. They are all changes the user needs to adapt to because they
potentially impact compatibility.


Would love it to be the case, but I don't think that's correct. Or if 
it's supposed to be correct, it hasn't been well communicated :)


Few random reviews from the DocImpact queue that didn't have relnotes:

https://review.openstack.org/#/c/180202/
https://review.openstack.org/#/c/249814/
https://review.openstack.org/#/c/250818/
https://review.openstack.org/#/c/230983/

Didn't really look closely into these - would encourage someone with a 
bit more time to do so, but the fact that these were so trivial to eke 
out means that "nearly all" is almost certainly a bad assumption.





Bugs and relnotes are two very different things.

L

Lana Brindley
writer:speaker:blogger
http://lanabrindley.com





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

[Tom Fifield]

On 24/11/15 19:20, Dolph Mathews wrote:

Scenarios I've been personally involved with where the
"distrustful" model either did help or would have helped:

- Employee is reprimanded by management for not positively reviewing &
approving a coworkers patch.

- A team of employees is pressured to land a feature with as fast as
possible. Minimal community involvement means a faster path to "merged,"
right?

- A large group of reviewers from the author's organization repeatedly
throwing *many* careless +1s at a single patch. (These happened to not
be cores, but it's a related organizational behavior taken to an extreme.)

I can actually think of a few more specific examples, but they are
already described by one of the above.

It's not cores that I do not trust, its the organizations they operate
within which I have learned not to trust.


I think this is a good summary of people's fears and practical experience.

Though, It seems that those cases above are derived from not 
understanding how we work, rather than out of deliberate malice. We can 
fix this kind of stuff with education :)


Putting this out there - over at the Foundation, we're here to Protect 
and Empower you. So, if you've ever been reprimanded by management for 
choosing not to abuse the community process, perhaps we should arrange 
an education session with that manager (or their manager) on how 
OpenStack works.





On Monday, November 23, 2015, Morgan Fainberg > wrote:

Hi everyone,

This email is being written in the context of Keystone more than any
other project but I strongly believe that other projects could
benefit from a similar evaluation of the policy.

Most projects have a policy that prevents the following scenario (it
is a social policy not enforced by code):

* Employee from Company A writes code
* Other Employee from Company A reviews code
* Third Employee from Company A reviews and approves code.

This policy has a lot of history as to why it was implemented. I am
not going to dive into the depths of this history as that is the
past and we should be looking forward. This type of policy is an
actively distrustful policy. With exception of a few potentially bad
actors (again, not going to point anyone out here), most of the
folks in the community who have been given core status on a project
are trusted to make good decisions about code and code quality. I
would hope that any/all of the Cores would also standup to their
management chain if they were asked to "just push code through" if
they didn't sincerely think it was a positive addition to the code base.

Now within Keystone, we have a fair amount of diversity of core
reviewers, but we each have our specialities and in some cases
(notably KeystoneAuth and even KeystoneClient) getting the required
diversity of reviews has significantly slowed/stagnated a number of
reviews.

What I would like us to do is to move to a trustful policy. I can
confidently say that company affiliation means very little to me
when I was PTL and nominating someone for core. We should explore
making a change to a trustful model, and allow for cores (regardless
of company affiliation) review/approve code. I say this since we
have clear steps to correct any abuses of this policy change.

With all that said, here is the proposal I would like to set forth:

1. Code reviews still need 2x Core Reviewers (no change)
2. Code can be developed by a member of the same company as both
core reviewers (and approvers).
3. If the trust that is being given via this new policy is violated,
the code can [if needed], be reverted (we are using git here) and
the actors in question can lose core status (PTL discretion) and the
policy can be changed back to the "distrustful" model described above.

I hope that everyone weighs what it means within the community to
start moving to a trusting-of-our-peers model. I think this would be
a net win and I'm willing to bet that it will remove noticeable
roadblocks [and even make it easier to have an organization work
towards stability fixes when they have the resources dedicated to it].

Thanks for your time reading this.

Regards,
--Morgan
PTL Emeritus, Keystone



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack-Announce List

[Tom Fifield]

Hi all,

I'd like to get your thoughts about the OpenStack-Announce list.

We describe the list as:

"""
Subscribe to this list to receive important announcements from the 
OpenStack Release Team and OpenStack Security Team.


This is a low-traffic, read-only list.
"""

Up until July 2015, it was used for the following:
* Community Weekly Newsletter
* Stable branch release notifications
* Major (i.e. Six-monthly) release notifications
* Important security advisories

and had on average 5-10 messages per month.

After July 2015, the following was added:
* Release notifications for clients and libraries (one email per 
library, includes contributor-focused projects)


resulting in an average of 70-80 messages per month.


Personally, I no longer consider this volume "low traffic" :)

In addition, I have been recently receiving feedback that users have 
been unsubscribing from or deleting without reading the list's posts.


That isn't good news, given this is supposed to be the place where we 
can make very important announcements and have them read.


One simple suggestion might be to batch the week's client/library 
release notifications into a single email. Another might be to look at 
the audience for the list, what kind of notifications they want, and 
chose the announcements differently.


What do you think we should do to ensure the announce list remains useful?



Regards,


Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev