[openstack-dev] It's time...

[Tom Fifield]

Hi all,

Tom here, on a personal note.

It's quite fitting that this November our summit is in Australia :)

I'm hoping to see you there because after being part of 15 releases, and 
travelling the equivalent of a couple of round trips to the moon to 
witness OpenStack grow around the world, the timing is right for me to 
step down as your Community Manager.


We've had an incredible journey together, culminating in the healthy 
community we have today. Across more than 160 countries, users and 
developers collaborate to make clouds better for the work that matters. 
The diversity of use is staggering, and the scale of resources being run 
is quite significant. We did that :)



Behind the scenes, I've spent the past couple of months preparing to 
transition various tasks to other members of the Foundation staff. If 
you see a new name behind an openstack.org email address, please give 
them due attention and care - they're all great people. I'll be around 
through to year end to shepherd the process, so please ping me if you 
are worried about anything.


Always remember, you are what makes OpenStack. OpenStack changes and 
thrives based on how you feel and what work you do. It's been a 
privilege to share the journey with you.




So, my plan? After a decade of diligent effort in organisations 
euphemistically described as "minimally-staffed", I'm looking forward to 
taking a decent holiday. Though, if you have a challenge interesting 
enough to wrest someone from a tropical beach or a misty mountain top ... ;)



There are a lot of you out there to whom I remain indebted. Stay in 
touch to make sure your owed drinks make it to you!


+886 988 33 1200
t...@tomfifield.net
https://www.linkedin.com/in/tomfifield
https://twitter.com/TomFifield


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] [doc][ptls][all] Documentation publishing future

[Tom Fifield]

On 廿十七年五月廿四日 朝 09:38, Rochelle Grober wrote:

  From: Ildiko
  > On 2017. May 23., at 15:43, Sean McGinnis 

wrote:


On Mon, May 22, 2017 at 05:50:50PM -0500, Anne Gentle wrote:

On Mon, May 22, 2017 at 5:41 PM, Sean McGinnis

wrote:



[snip]



Hey Sean, is the "right to merge" the top difficulty you envision
with 1 or 2? Or is it finding people to do the writing and reviews?
Curious about your thoughts and if you have some experience with
specific day-to-day behavior here, I would love your insights.

Anne


I think it's more about finding people to do the writing and reviews,
though having incentives like having more say in that area of things
could be beneficial for finding those people.


I think it is important to note here that by having the documentation (in it’s
easily identifiable, own folder) living together with the code in the same
repository you have the developer(s) of the feature as first line candidates
on adding documentation to their change.

I know that writing good technical documentation is it’s own profession, but
having the initial data there which can be fixed by experienced writers if
needed is a huge win compared to anything separated, where you might not
have any documentation at all.

So by having the ability to -1 a change because of the lack of documentation
is on one hand might be a process change for reviewers, but gives you the
docs contributors as well.


Possible side benefits here:  If a new, wannabe developer starts with the docs 
to figure out how to participate in the project, they may/will (if encouraged) 
file bugs against the docs where they are wrong or lacking.  Beyond that, if 
the newbie is reading the code s/he may just fix some low hanging fruit docs 
issues, or even go deeper.  I know, devs don't read docs, but I think they 
sneak looks when they think no one is looking.  And then get infuriated if the 
docs don't match the code.  Perusers of code have more time to address issues 
than firefighters (fixing high priority bugs), so it's possible that this new 
approach will encourage more complete documentation.  I can be optimistic, too.


+1, contributing to documentation should be a much easier starting point 
than code & a good way to learn the gerrit workflow. If the doc patch 
coming in from the newbie is "better than what's there", it should be 
merged swiftly.




--Rocky
  

So to summarize, the changes what Alex described do not indicate that the
core team has to write the documentation themselves or finding a team of
technical writers before applying the changes, but be conscious about caring
whether docs is added along with the code changes.

Thanks,
Ildikó



__

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] project on-board schedule

[Tom Fifield]

On 26/04/17 21:12, Julien Danjou wrote:

On Tue, Apr 25 2017, Tom Fifield wrote:

Hi Tom,


It's listed on the main summit schedule, under the Forum :)

Here's a direct link to the Forum category:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


I've also just realized the Telemetry onboarding session overlaps with
one of my talks:

  
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18698/cloudkittytelemetry-project-onboarding

  
https://www.openstack.org/summit/boston-2017/summit-schedule/events/17530/openstack-telemetry-and-the-1-instances

Any chance to reschedule one or the other?



Sorry to hear! Please contact speakersupp...@openstack.org for assistance :)

__
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] [all] List of all Boston Forum Session Etherpads

[Tom Fifield]

Hi all,

With the forum not long away, it's time to start listing your session 
etherpads. I've gathered all that I knew about on:


https://wiki.openstack.org/wiki/Forum/Boston2017


Please add yours ASAP!


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] project on-board schedule

[Tom Fifield]

On 25/04/17 16:35, joehuang wrote:

Hello,

Where can I find the project on-board schedule in OpenStack Boston
summit? I haven't found it yet, and maybe I missed some mail. Thanks a lot.


It's listed on the main summit schedule, under the Forum :)

Here's a direct link to the Forum category:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Tom Fifield]

Still no email over here :)

On 20/04/17 14:43, Kevin Benton wrote:

FWIW mine just came through yesterday.

On Wed, Apr 19, 2017 at 12:13 PM, Jay S Bryant > wrote:

All,

For those of you haven't received an e-mail, check the inbox you use
for Gerrit.  You can verify what that is by going to
review.openstack.org  , click your
name, go to settings, the e-mail address is set there.

The naming vote and the TC vote e-mails got lost in that inbox for me.

Hopes this helps.

Jay




On 4/12/2017 7:09 AM, Dulko, Michal wrote:

On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:

On 04/06/2017 07:34 AM, Monty Taylor wrote:

Hey all!

I've started the R Release Name poll and currently am
submitting
everyone's email address to the system. In order to not
make our fine
friends at Carnegie Mellon (the folks who run the CIVS
voting service)
upset, I have a script that submits the emails one at a
time with a
half-second delay between each email. That means at
best, since there
are 40k people to process it'll take ~6 hours for them
all to go out.

Which is to say - emails are on their way - but if you
haven't gotten
yours yet, that's fine. I'll send another email when
they've all gone
out, so don't worry about not receiving one until I've
sent that mail.

Well- that took longer than I expected. Because of some rate
limiting,
1/2 second delay was not long enough...

Anyway - all of the emails should have gone out now. Because
that took
so long, I'm going to hold the poll open until next Wednesday.

Monty

Not sure why, but I haven't received an email yet.

Thanks,
Michal

__
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

[openstack-dev] Boston Forum Schedule Online

[Tom Fifield]

Hello all,

The schedule for our the Forum is online:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


==> Session moderators, please start advertising your sessions & 
starting pre-discussions, to get the best, most well-informed people 
there possible!



==> Anyone else, please register your interest for sessions by 'ticking' 
them on th schedule. We use that information for room sizing.



Finally, thank you to the many who reviewed the draft. We fixed up those 
duplicates and made some slight changes to one or two sessions where 
there were conflicting talks. We're still working on contacting a couple 
of those marked as 'incomplete' in the tool, but they should be online 
shortly too.




Regards,


Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee

__
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] Boston Forum Schedule

[Tom Fifield]

On 10/04/17 22:19, Emilien Macchi wrote:

On Mon, Apr 10, 2017 at 7:31 AM, Flavio Percoco <fla...@redhat.com> wrote:

On 10/04/17 17:35 +0800, Tom Fifield wrote:


Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. We
have updated the topic submission site with the status of each - please
check yours.

Please also find attached in PDF the proposed schedule for the Forum in
Boston.


Let us know if you see major issues with it. As Thierry said in design
summits past; "It's difficult to make too many changes at this stage as they
quickly cascade into breaking all sorts of constraints, but we may still be
able to accommodate some." :)

Eagle-eyed readers will see that there are a number of slots in gray (on
Thursday afternoon). These are being deliberately kept aside for the usual
few critical topics that come up in the next few weeks and also for the
discoveries we make in the first 3 days of the summit.

We'll soon publish the Forum sessions on the main schedule, using the
title, abstracts and moderators you submitted, but look forward to your
feedback in the mean-time!

Thank you all very much for making our first Forum a success.




Hey Folks,

Thanks for working on this.

The topic "Future of configuration management tools" seems to have been
scheduled twice. Is that expected or a mistake? In the schedule it's not
explicit whether it's a 2 parts topic or not.


Good point. I think 1 session to keep is enough and I checked both
slots, we can pick one of those, I don't see much conflict that would
prevent folks to have to make an hard choice.

Tom, any chance to remove the second slot please?



Yup, this was a mistake, sorry!


__
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] Boston Forum Schedule

[Tom Fifield]

Hi everyone,

Thank you for the many excellent topics submitted for our first Forum. 
We have updated the topic submission site with the status of each - 
please check yours.


Please also find attached in PDF the proposed schedule for the Forum in 
Boston.



Let us know if you see major issues with it. As Thierry said in design 
summits past; "It's difficult to make too many changes at this stage as 
they quickly cascade into breaking all sorts of constraints, but we may 
still be able to accommodate some." :)


Eagle-eyed readers will see that there are a number of slots in gray (on 
Thursday afternoon). These are being deliberately kept aside for the 
usual few critical topics that come up in the next few weeks and also 
for the discoveries we make in the first 3 days of the summit.


We'll soon publish the Forum sessions on the main schedule, using the 
title, abstracts and moderators you submitted, but look forward to your 
feedback in the mean-time!


Thank you all very much for making our first Forum a success.


Regards,

Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee


BOS-forum.pdf
Description: Adobe PDF document
__
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] [all] BOS Forum - User/Dev Feedback session for your project?

[Tom Fifield]

Hi all,

Forum topic submission closes in 2 days (Sunday 23:59 UTC).

One of the types of topics you could consider submitting is a user/dev 
feedback session for your project. I see Swift, Keystone and Kolla have 
already done this - thanks!


From experience running the ops meetups, the best user/dev feedback 
sessions are co-organised by a leading developer and a prominent user. 
The dev can bring burning questions that the project wants answered; the 
user is great at eliciting information from the room.


If you're interested in doing something like that in Boston,

http://forumtopics.openstack.org/

welcomes you ... for the next 68 hours.


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] Some information about the Forum at the Summit in Boston

[Tom Fifield]

On 廿十七年三月七日 暮 11:26, Matt Riedemann wrote:

On 3/7/2017 6:35 AM, Thierry Carrez wrote:

Hi everyone,

I recently got more information about the space dedicated to the "Forum"
at the OpenStack Summit in Boston. We'll have three different types of
spaces available.

1/ "Forum" proper

There will be 3 medium-sized fishbowl rooms for cross-community
discussions. Topics for the discussions in that space will be selected
and scheduled by a committee formed of TC and UC members, facilitated by
Foundation staff members. In case you missed it, the brainstorming for
topics started last week, announced by Emilien in that email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html

2/ "On-boarding" rooms

We'll have two rooms set up in classroom style, dedicated to project
teams and workgroups who want to on-board new team members. Those can
for example be booked by project teams to run an introduction to their
codebase to prospective new contributors, in the hope that they will
join their team in the future. Those are not meant to do traditional
user-facing "project intro" talks -- there is space in the conference
for that. They are meant to provide the next logical step in
contributing after Upstream University and being involved on the
sidelines. It covers the missing link for prospective contributors
between attending Summit and coming to the PTG. Kendall Nelson and Mike
Perez will soon announce the details for this, including how projects
can sign up.

3/ Free hacking/meetup space

We'll have four or five rooms populated with roundtables for ad-hoc
discussions and hacking. We don't have specific plans for these -- we
could set up something like the PTG ethercalc for teams to book the
space, or keep it open. Maybe half/half.

More details on all this as they come up.
Hoping to see you there !



Thanks for the details, this helps.

Any idea what the breakdown in days are going to be, like "Forum"
sessions are Monday/Tuesday or Tuesday/Wednesday, or are they all four
days?


Probably all four days.


The nova people that are going to be there would like to take advantage
of the face-to-face time to work on some of the priority items for the
Pike release in the free hacking/meetup space but without knowing when
the other sessions are going to be it's hard to know when we can
schedule space in the hacking pit.

If that's all TBD that's fair, I just wanted to ask.



__
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 Summit Boston-CFP closes February 6th

[Tom Fifield]

Should be good for another 24.5 hours now :) Get those presentations in!

On 廿十七年二月六日 暮 01:26, shubham sharma wrote:

Hi,

I am in IST timezone (UTC+5:30) and I am getting error in submitting
proposal with following error.
" *Warning!* Call for Presentations is closed!. "

Anybody else facing this issue?

Regards
Shubham

On Thu, Feb 2, 2017 at 12:44 AM, Erin Disney > wrote:

Hi Everyone-

Don’t forget: the Call for Presentations for the upcoming OpenStack
Summit Boston closes next week!

The submission deadline is February 6, 2017 at 11:59PM PDT (February
7, 2017 at 6:59 UTC).

Reminder: Proposed sessions must indicate a format: Panel,
presentation or lightning talk. Each format has a maximum number of
speakers associated. Panels are allowed a total of four speakers
plus one moderator, whereas presentations and lightning talks are
limited to two speakers.

As a reminder, speakers are limited to a maximum of three
submissions total.

Contact speakersupp...@openstack.org
with any submission questions.

BOSTON REGISTRATION
Attendee registration is now open
. Purchase your
discounted early bird passes now. Prices will increase in mid March.

SPONSORSHIP SALES
Summit sponsorship sales are also open. You can now sign the
electronic contract here

.
If you plan to sponsor both 2017 OpenStack Summits (Boston in May &
Sydney in November), then check out page 4 of the Boston Summit
Sponsorship Prospectus

for
a special 15% discount on Sydney Summit sponsorship packages. Please
note this only applies to companies who sponsor boththe Boston
Summit and Sydney Summit. Full details of the sponsorship signing
process are outlined here
.

If you have any general Summit questions, contact us at
sum...@openstack.org .


Erin Disney
OpenStack Marketing
e...@openstack.org 


__
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] [barbican] Project Navigator Out of Date?

[Tom Fifield]

On 17/01/17 00:14, Thierry Carrez wrote:

Ian Cordasco wrote:

From: Tom Fifield <t...@openstack.org>

On 16/01/17 21:55, Ian Cordasco wrote:


Third, "Existence and quality of packages for this project in popular
distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and
OpenSUSE [5] all have packages (including in stable versions). I can't
speak to the quality of the packages, but knowing the hard work most
of our downstream redistributors put into those packages, I'm certain
they're good quality. This should *definitely* be updated, in my
opinion.


https://bugs.launchpad.net/openstack-org/+bug/1656843

https://github.com/OpenStackweb/openstack-org/pull/59


So, if I understand the two links correctly, changes are planned to
make that tag better and until they're made you're going to stop
displaying it using that with projects. Is that correct? Are there
other ways the community can help keep the navigator up-to-date?


Regarding stable branch policy and standard deprecation, this
information is directly pulled from governance project tags. Both are
assertion tags that the team must assert by themselves (by proposing a
change to openstack/governance).

Quick glance to:
https://governance.openstack.org/tc/reference/projects/barbican.html

shows that those tags haven't been asserted by the Barbican team yet.

Reference:
https://governance.openstack.org/tc/reference/tags/index.html



... and just for completeness, the relatively small number of tags 
starting with ops: are derived from:


https://github.com/openstack/ops-tags-team

patches via the gerrit welcome :)

__
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] [barbican] Project Navigator Out of Date?

[Tom Fifield]

On 16/01/17 21:55, Ian Cordasco wrote:


Third, "Existence and quality of packages for this project in popular
distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and
OpenSUSE [5] all have packages (including in stable versions). I can't
speak to the quality of the packages, but knowing the hard work most
of our downstream redistributors put into those packages, I'm certain
they're good quality. This should *definitely* be updated, in my
opinion.


https://bugs.launchpad.net/openstack-org/+bug/1656843

https://github.com/OpenStackweb/openstack-org/pull/59

__
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] PTG? / Was (Consistent Versioned Endpoints)

[Tom Fifield]

On 14/01/17 04:07, Joshua Harlow wrote:


Sometimes I almost wish we just rented out a football stadium (or
equivalent, a soccer field?) and put all the contributors in the 'field'
with bean bags and some tables and a bunch of white boards (and a lot of
wifi and power cords) and let everyone 'have at it' (ideally in a
stadium with a roof in the winter). Maybe put all the infra people in a
circle in the middle and make the foundation people all wear referee
outfits.

It'd be an interesting social experiment at least :-P


I have been informed we have located at least 3 referee outfits across 
Foundation staff, along with a set of red/yellow cards.


__
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] Fwd: [Openstack] The Forum: in more detail

[Tom Fifield]

Hi *dev,

Post over on the general ML you might be interested in - please send 
replies there to avoid cross-posting pain ;)



Regards,


Tom


 Forwarded Message 
Subject: [Openstack] The Forum: in more detail
Date: Thu, 5 Jan 2017 11:42:53 +0800
From: Tom Fifield <t...@openstack.org>
To: openst...@lists.openstack.org

Hi all,

working with colleagues, I've just put up a post cobbling together some 
more detail on the Forum. Sorry it took so long!


http://superuser.openstack.org/articles/openstack-forum/


There's now also a wiki page to be the reference for us to follow when 
preparing or participating:


https://wiki.openstack.org/wiki/Forum


Please check them out and reply with any thoughts, ideas or angry rants!


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 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] PTG from the Ops Perspective - a few short notes

[Tom Fifield]

Hello all,

It's fantastic to see all of the PTG planning that has been going on in 
recent threads. It's clear there's a bit of confusion too, and as 
mriedem notes - us "mere mortals" are probably going to take some time 
to figure it out. Nothing's final of course, and we're going to take a 
while and iterate to success.


With that in mind, I'm going to don the flame-proof suit and try to list 
a few very short, simple things to try and help, particularly to 
understand from the ops-y side of things. Throwing away all the context 
and nuance here that could stave off attacks, so please be nice :)



* The OpenStack Summit is the start of a release cycle *

If you do nothing else, please check out the diagram on the PTG site - 
it's good. We're finally acknowledging that a release cycle starts with 
planning, rather than when the code branch opens :) It means that we'll 
be finalizing development on one release while planning another, though 
we've actually been doing that already. The difference is that with this 
change, we'll have the summit in the right place to get decent feedback 
and ideas from users: at the very start of the cycle.




* The OpenStack Summit is the place where the entire community gets 
together *


Just because there's the PTG, doesn't mean the Summit becomes some 
marketing thing. If you want to have pre-spec brainstorming or feedback 
discussions with users: Summit. If you need to be involved in the 
strategic direction of OpenStack: Summit. If you just want to hang out 
with your project team and talk code only: you're going to love the PTG :)



* Don't expect Ops at the PTG *

The PTG has been designed for you to have a space to get stuff done.
Unless a user is so deep into code that you basically look at them as 
"one of the team", they're not going to be there. If you'd like feedback 
and ideas from users, plan that to happen at the start of the cycle - 
i.e. Summit :)




Thank you for your exceptional patience as we work all this out! Ready 
for the flame-tan now :)




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] Community Contributor Awards

[Tom Fifield]

Time is running out to nominate for an award!!

https://openstackfoundation.formstack.com/forms/community_contributor_award_nomination_form

On 21/09/16 02:43, Kendall Nelson wrote:

Hello all,


I’m pleased to announce the next round of community contributor awards!
Similar to the Austin Summit, the awards will be presented by the
Foundation at the feedback session of the upcoming Summit in Barcelona.


Now accepting nominations! Please submit anyone you think is deserving
of an award!


https://openstackfoundation.formstack.com/forms/community_contributor_award_nomination_form


Please submit all nominations by the end of day on October 7th.


There are so many people out there who do invaluable work that should be
recognized. People that hold the community together, people that make
working on OpenStack fun, people that do a lot but aren’t called out for
their work, people that speak their mind and aren’t afraid to challenge
the norm.


Like last time, we won’t have a defined set of awards so we take extra
note of what you say about the nominee in your submission to pick the
winners.


We’re excited to hear who you want to celebrate and why you think they
are awesome!


All the Best,


Kendall Nelson (diablo_rojo)




__
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] Too many mails on announce list again :)

[Tom Fifield]

Hi all,

Last November, we discussed the OpenStack-announce list, defined its 
purpose more finely and moved some internal library announcements to 
-dev[1].


For reference, 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.
"""

Unfortunately, the traffic on this list again regularly exceeds 100 
messages a month - worse than last time we talked about it.


The feedback continues to come in from users that they find it more 
'spam' than 'source of important announcements', which is not good news!


Quite a lot of the email rush tends to come from when a particular 
project releases multiple 'components' at once. A fine effort of release 
management, but in the current system each component's release triggers 
its own email.


For example, today the puppet team has been doing some great work with a 
9.3.0 release. Many modules were updated. That's an "important 
announcement" for many of our users.


However, to get the "low-traffic" bit, we need to make that 1 email, 
instead of 30 :)



At least, that's my thinking. What's yours?


Regards,


Tom




[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082182.html


__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 10/09/16 06:12, Tom Fifield wrote:



On 廿十六年九月九日 暮 02:01, Shamail wrote:

Hi Tom,

I'll help with that.  :)


Thanks Shamail - standby - I will write up instructions and send them
through.


I added a section "Helping Real Users avoid the CAPTCHA (admin rights 
needed)" on the wiki gardening page:


https://wiki.openstack.org/wiki/How_To_Use_The_Wiki#Helping_Real_Users_avoid_the_CAPTCHA_.28admin_rights_needed.29

Please try it out and edit as needed!




Thanks,
Shamail


On Sep 9, 2016, at 2:49 PM, Tom Fifield <t...@openstack.org> wrote:


On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's
about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol



How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top
right, click on your username)

I'm also going through the recent edits and adding people to get the
"bulk" of us in there, when time permits. Anyone else that wants to
help is welcome.






Is it possible to disable CAPTCHA for users in group "autopatrol"?

__

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



__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 廿十六年九月九日 暮 02:01, Shamail wrote:

Hi Tom,

I'll help with that.  :)


Thanks Shamail - standby - I will write up instructions and send them 
through.




Thanks,
Shamail


On Sep 9, 2016, at 2:49 PM, Tom Fifield <t...@openstack.org> wrote:


On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:
Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top right, 
click on your username)

I'm also going through the recent edits and adding people to get the "bulk" of 
us in there, when time permits. Anyone else that wants to help is welcome.






Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
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



__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 廿十六年九月九日 朝 11:45, Hayes, Graham wrote:

On 09/09/2016 08:44, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


How would someone get in said list?


$100 donation to the buy-fungi-beer fund.

... and/or email me a link to your wiki user page (Click in the top  
right, click on your username)


I'm also going through the recent edits and adding people to get the  
"bulk" of us in there, when time permits. Anyone else that wants to help  
is welcome.







Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

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


On 廿十六年九月九日 朝 10:51, Morgan Fainberg wrote:



On Fri, Sep 9, 2016 at 8:43 AM, Tom Fifield <t...@openstack.org
<mailto:t...@openstack.org>> wrote:



On 廿十六年九月九日 朝 10:41, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than
a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools
we're
leveraging currently to combat the ongoing
spam/scammer/vandalism
problems on wiki.openstack.org <http://wiki.openstack.org>,
as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and
cleaning up
all their modifications, but am hoping that with other
improvements
we have pending the onslaught will lessen and we can revisit
some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki
admin are
added to a group that bypasses the captcha, and then get a
team of
wiki groomers in the habit of adding known good accounts to that
group).


Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group -
there's about
64 so far:


https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol

<https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol>



Is it possible to disable CAPTCHA for users in group "autopatrol"?


aha! It is indeed.

Adding

$wgGroupPermissions['autopatrol']['skipcaptcha'] = true;


will solve this annoyance for Malini and others


__
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
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>


For what it's worth, the captcha is the reason I stopped using /
updating the wiki and was a driver for keystone to move to using
etherpad for the weekly meeting agenda instead.

--Morgan


__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 廿十六年九月九日 朝 10:41, Tom Fifield wrote:



On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about
64 so far:

https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol



Is it possible to disable CAPTCHA for users in group "autopatrol"?


aha! It is indeed.

Adding

$wgGroupPermissions['autopatrol']['skipcaptcha'] = true;


will solve this annoyance for Malini and others

__
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] venting -- OpenStack wiki reCAPTCHA

[Tom Fifield]

On 廿十六年九月八日 暮 08:36, Jeremy Stanley wrote:

On 2016-09-09 01:10:15 + (+), Bhandaru, Malini K wrote:

Is it just me who likes to hit the save button often?
It gets tedious proving often that you are not a robot. Wiki
reCAPTCHA likes proof even if saves are spaced less than a minute
apart!
Wiki Gods, hear my plea!


I sympathize. That captcha addition is one of several tools we're
leveraging currently to combat the ongoing spam/scammer/vandalism
problems on wiki.openstack.org, as an alternative to shutting it
down completely. Unfortunately even now I still spend a chunk of
every day blocking new accounts created by abusers and cleaning up
all their modifications, but am hoping that with other improvements
we have pending the onslaught will lessen and we can revisit some of
the more intrusive mechanisms on which we've been forced to rely
(for example, I think we should be able to configure it so that
users whose previous edits have been confirmed by a wiki admin are
added to a group that bypasses the captcha, and then get a team of
wiki groomers in the habit of adding known good accounts to that
group).



Indeed - fungi has been doing amazing work :(

I have been adding "known good" accounts to such a group - there's about 
64 so far:


https://wiki.openstack.org/w/index.php?title=Special:ListUsers=autopatrol


Is it possible to disable CAPTCHA for users in group "autopatrol"?

__
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] (no subject)

[Tom Fifield]

On 17/08/16 15:19, UnitedStack 张德通 wrote:

i want to join openstack mailing list


You're on it ^_^


__
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] How to change openstack ID email

[Tom Fifield]

Hi,

Did you try logging in with your @gmail.com address ? :)


Regards,

Tom

On 02/08/16 19:04, zhuna wrote:

Dear,



I had an openstack ID with my company email address(na...@cn.ibm.com), I
change my company recently, so I add an company affiliation with my new
company name.

Now the question is I can not login openstack
(https://openstackid.org/accounts/user/login) by na...@cn.ibm.com
, the error log is “We are sorry, your username
or password does not match an existing record.”

I can not login openstack by my new company email juno@huawei.com
 either, the error log is “member
juno@huawei.com is not verified yet!”, so I click “Verify Openstack
ID” and input my new email address, it prints

“juno@huawei.com, your request was successfully processed! please
verify your INBOX
”,
then I login my inbox, there is no email from openstack.





Really appreciate if you can help to fix it.





BR

Juno











__
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] Troubleshooting and ask.openstack.org

[Tom Fifield]

On 01/07/16 13:01, Adam Young wrote:

On 06/28/2016 11:13 PM, Tom Fifield wrote:

Quick answers in-line

On 29/06/16 05:44, Adam Young wrote:

It seems to me that keystone Core should be able to moderate Keystone
questions on the site.  That means that they should be able to remove
old dead ones, remove things tagged as Keystone that do not apply and so
on.  I would assume the same is true for Nova, Glance, Trove, Mistral
and all the rest.


If you send a list of ask openstack usernames to
community...@openstack.org , happy to give them moderator rights.
Anyone with karma beyond 200 already has them.


The email bounced.


Typo!

communitym...@openstack.org








We need some better top level interface than just the tags, though.
Ideally we would have a page where someone lands when troubleshooting
keystone with a series of questions and links to the discussion pages
for that question.  Like:


I get an error that says "cannot authenticate" what do I do?


Example - something like this link for "Common Upstream Development
Questions"

https://ask.openstack.org/en/questions/tags:common-upstream

?


What is the Engine behind "ask.openstack.org?"  does it have other tools
we could use?


Askbot - https://github.com/ASKBOT/askbot-devel


__

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] Troubleshooting and ask.openstack.org

[Tom Fifield]

Quick answers in-line

On 29/06/16 05:44, Adam Young wrote:

It seems to me that keystone Core should be able to moderate Keystone
questions on the site.  That means that they should be able to remove
old dead ones, remove things tagged as Keystone that do not apply and so
on.  I would assume the same is true for Nova, Glance, Trove, Mistral
and all the rest.


If you send a list of ask openstack usernames to 
community...@openstack.org , happy to give them moderator rights. Anyone 
with karma beyond 200 already has them.




We need some better top level interface than just the tags, though.
Ideally we would have a page where someone lands when troubleshooting
keystone with a series of questions and links to the discussion pages
for that question.  Like:


I get an error that says "cannot authenticate" what do I do?


Example - something like this link for "Common Upstream Development 
Questions"


https://ask.openstack.org/en/questions/tags:common-upstream

?


What is the Engine behind "ask.openstack.org?"  does it have other tools
we could use?


Askbot - https://github.com/ASKBOT/askbot-devel


__
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] Invitation to join Hangzhou Bug Smash

[Tom Fifield]

Hi,

Are there plans to follow the OpenStack events policy this time?

eg Commercial participants should have equal opportunity to sponsor and 
support the activity. When the number of sponsorships is limited, a best 
practice is to publish a sponsorship prospectus online on a date known 
in advance with sponsorships filled on a "first to sign" basis.



Regards,


Tom

On 13/06/16 16:06, Wang, Shane wrote:

Hi, OpenStackers,
As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack
Bug Smash at Hangzhou, China.
The 1st China Bug Smash was at Shanghai, the 2nd was at Xi’an, and the
3rd was at Chengdu.
We are constructing the etherpad page for registration, and the date
will be around July 11 (probably July 6 – 8, but to be determined very
soon).
The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum,
Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers
to join and fix bugs as many as possible, and cores to be on site to
moderate the code changes and merges. Welcome to the smash mash at
Hangzhou -_http://www.chinahighlights.com/hangzhou/attraction/_.
Good news is still that for the first two cores who are from those above
projects and respond to this invitation in my email inbox and copy the
CC list, the sponsors are pleased to sponsor your international travel,
including flight and hotel. Please simply reply to me.
Best regards,
--
China OpenStack Bug Smash 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




__
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] Wiki

[Tom Fifield]

On 11/05/16 09:04, Dan Smith wrote:

Here it is :)

https://wiki.openstack.org/wiki/Special:AncientPages


Great, I see at least one I can nuke on the first page.

Note that I don't seem to have delete powers on the wiki. That's surely
a first step in letting people maintain the relevance of things on the wiki.


Looks like that was just fixed ... :)

__
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] Wiki

[Tom Fifield]

On 11/05/16 02:48, Dan Smith wrote:

Hmm... that's unfortunate, as we were trying to get some of our less
ephemeral items out of random etherpads and into the wiki (which has the
value of being google indexed).


Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
definitely bummed at the thought of losing it.


The Google indexing is also what makes the wiki so painful... After 6
years most of the content there is inaccurate or outdated. It's a
massive effort to clean it up without breaking the Google juice, and
nobody has the universal knowledge to determine if pages are still
accurate or not. We are bitten every day by newcomers finding wrong
information on the wiki and acting using it. It's getting worse every
day we keep on using it.


Sure, I think we all feel the pain of the stale information on the wiki.
What if we were to do what we do for bug or review purges and make a
list of pages, in reverse order of how recently they've been updated?
Then we can have a few sprints to tag obviously outdated things to
purge, and perhaps some things that just need some freshening.


Here it is :)

https://wiki.openstack.org/wiki/Special:AncientPages

MediaWiki also has some other useful tools installed by default:

https://wiki.openstack.org/wiki/Special:SpecialPages

There are also a series of plugins, such as the ones for "patrolling" 
edits, and bots for mass updates and triggers that would potentially be 
helpful.



There are a lot of nova-related things on the wiki that are the
prehistory equivalent of specs, most of which are very misleading to
people about the current state of things. I would think we could purge a
ton of stuff like that pretty quickly. I'll volunteer to review such a
list from the nova perspective.


* Deprecate the current wiki and start over with another wiki (with
stronger ACL support ?)


I'm somewhat surprised that this is an issue, because I thought that the
wiki requires an ubuntu login. Are spammers really getting ubuntu logins
so they can come over and deface our wiki?

--Dan

__
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] [tc] supporting Go

[Tom Fifield]

On 04/05/16 01:58, John Dickinson wrote:

TC,

In reference to 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
Thierry's reply, I'm currently drafting a TC resolution to update 
http://governance.openstack.org/resolutions/20150901-programming-languages.html 
to include Go as a supported language in OpenStack projects.

As a starting point, what would you like to see addressed in the document I'm 
drafting?


Hi,

Not a TC member, and this might not even be the right place for this, 
but ... I think it would be nice if someone has a think about how moving 
from a primarily single language community to a 
multiple-languages-allowed-in-a-bigger-way community impacts the 
"people" side of the community. Then, possibly write that down, maybe 
even with things that we could do to address any badness foreseen.



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] Summit Core Party after Austin

[Tom Fifield]

Hi all,

On 22/04/16 16:40, Clint Byrum wrote:

But in the mean time, maybe we can just send this message
to party planners: Provide us with interesting spaces to converse and
bond in, and we will be happier.


Spoke with the party planners and got the inside gossip :)

The good news: for the Austin summit party, those who are looking for a 
quieter space will be served as well as those who enjoy live music.


ProTip: http://stackcityaustin.openstack.org/map.php

For the quieter space, G'Raj Mahal, Parlor Room and L'Estelle are the 
ones you want. Within these venues, the noise will come from your 
voices, rather than an amplified band.




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] Constant attempts from Matthew Kassawara to remove Debian from the install-guide

[Tom Fifield]

On 09/04/16 14:49, Thomas Goirand wrote:

I still don't have any idea what's wrong with the
Debian guide.


The standing issue that I recall that raises the maintenance burden is 
the use of debconf rather than/in addition to manual config file edits 
as per the other distros. I can't remember whether you already tried a 
version without debconf or not though.


__
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 Contributor Awards

[Tom Fifield]

Reminder :)

We'll probably stop taking entries at the end of next week.

On 16/02/16 18:43, Tom Fifield wrote:

Hi all,

I'd like to introduce a new round of community awards handed out by the
Foundation, to be presented at the feedback session of the summit.

Nothing flashy or starchy - the idea is that these are to be a little
informal, quirky ... but still recognising the extremely valuable work
that we all do to make OpenStack excel.

There's so many different areas worthy of celebration, but we think that
there's a few main chunks of the community that need a little love,

* Those who might not be aware that they are valued, particularly new
contributors
* Those who are the active glue that binds the community together
* Those who share their hard-earned knowledge with others and mentor
* Those who challenge assumptions, and make us think

Since it's first time (recently, at least), rather than starting with a
defined set of awards, we'd like to have submissions of names in those
broad categories. Then we'll have a little bit of fun on the back-end
and try to come up with something that isn't just your standard set of
award titles, and iterate to success ;)

The submission form is here, so please submit anyone who you think is
deserving of an award!



https://docs.google.com/forms/d/1HP1jAobT-s4hlqZpmxoGIGTxZmY6lCWolS3zOq8miDk/viewform




in the meantime, let's use this thread to discuss the fun part: goodies.
What do you think we should lavish award winners with? Soft toys?
Perpetual trophies? baseball caps ?


Regards,


Tom, on behalf of the 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


__
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] [glance] Glance Mitaka: Passing the torch

[Tom Fifield]

A beautiful post, sir. Thank you for everything!

On 09/03/16 22:15, Flavio Percoco wrote:


Greetings,

I'm not going to run for Glance's PTL position for the Newton timeframe.

There are many motivations behind this choice. Some of them I'm willing to
discuss in private if people are interested but I'll go as far as saying
there
are personal and professional reasons for me to not run again.

As I've always done in my past cycles as PTL, I'd like to take some time to
summarize what's happened in the past cycle not only for the new PTL to
know
what's coming up but for the community to know how things went.

Before I even start, I'd like to thank everyone in the Glance community.
I truly
believe this was a great cycle for the project and the community has gotten
stronger. None of this would have been possible without the help of all
of you
and for that, I'm deeply in debt with you all. It does not just take an
employer
to get someone to contribute to a project. Being paid, for those who
are, to do
Open Source is not enough. It takes passion, motivation and a lot of
patience to
analyze a technology, think out of the box and look for ways it can be
improved
either by fixing bugs or by implementing new features. The amount of
time and
dedication this process requires is probably worth way more than what we
get
back from it.

Now, with all that being said, here's Glance Mitaka for all of you:

Completed Features
==

I think I've mentioned this already but I'm proud of it so I'll say it
again.
The prioritization and scheduling of Glance Mitaka went so well that we
managed
to release M-3 without any feature freeze exception (FFE) request. This
doesn't
mean all the features were implemented. In fact, at least 4 were pushed
back to
Newton. However, the team communicated, reviewed, sprinted and coded in
such a
way that we were able to re-organize the schedule to avoid wasting time on
things we new weren't going to make it. This required transparency and hard
decisions but that's part of the job, right?

* [0] CIM Namespace Metadata
* [1] Support download from and upload to Cinder volumes
* [2] Glance db purge utility
* [3] Deprecate Glance v3 API
* [4] Implement trusts for Glance
* [5] Migrate the HTTP Store to Use Requests
* [6] Glance Image Signing and Verification
* [7] Supporting OVF Single Disk Image Upload
* [8] Prevention of Unauthorized errors during upload/download in Swift
driver
* [9] Add filters using an ‘in’ operator

[0]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html

[1]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html

[2]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html

[3]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html

[4]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html

[5]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html

[6]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html

[7]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html

[8]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html

[9]
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html


If the above doesn't sound impressive to you, let me fill you in with
some extra
info about Glance's community.

Community
=

Glance's community currently has 12 core members, 3 of which joined during
Mitaka and 2 of those 3 members joined at the end of the cycle. That
means the
team ran on 9 reviewers for most of the cycle except that out of those
9, 1 left
the team and joined later in the cycle and 3 folks weren't super active
this
cycle. That left the team with 5 constant reviewers throughout the cycle.

Now, the above is *NOT* to say that the success of the cycle is thanks
to those
5 constant reviewers. On the contrary, it's to say that we've managed to
build a
community capable of working together with other non-core reviewers.
This was a
key thing for this cycle.

I don't think it's a secret to anyone that, at the beginning of the
cycle, the
community was fragile and somewhat split. There were different opinions
on what
Glance should (or shouldn't) look like, what new features Glance should (or
shouldn't) have and where the project should be headed in the next 6
months.

The team sat down, the team talked and the team agreed on what the project
should be and that's what the team did in the Mitaka cycle. Sharing one
message
with the rest of the OpenStack community (and especially new Glance
contributors) was a key for the community to become stronger.

What changed? What did the 

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

[Tom Fifield]

On 03/03/16 23:12, Jonathan Proulx wrote:


To go a little further down my wish list I'd really like to do be able
to offer a standard selection of security groups for my site no tjust
'default', but that may be a bit off this topic.  Briefly my
motivation is that 'internal' here includes a number of differnt
netblock some with pretty weird masks so users tend to use 0.0.0.0/0
when they don't really meant to just to save some rather tedious
typing at setup time.


+1 - I've seen some clouds do this as part of their account creation 
process. bug ?


__
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 Contributor Awards

[Tom Fifield]

Excellent, excellent.

What's the best place to buy Raspberry Pis these days?

On 22/02/16 21:09, Victoria Martínez de la Cruz wrote:

Oh I missed this thread... really great initiative! It's time to
recognize the effort of our fellow stackers :D

Raspi/Arduino kits or limited edition t-shirts are very cool goodies

Cheers,

V

2016-02-22 0:21 GMT-03:00 Steve Martinelli <steve...@ca.ibm.com
<mailto:steve...@ca.ibm.com>>:

limited edition (and hilarious) t-shirts are always fun :)

++ on raspberry pis, those are always a hit.

stevemar

Inactive hide details for Hugh Blemings ---2016/02/21 09:54:59
PM---Hiya, On 16/02/2016 21:43, Tom Fifield wrote:Hugh Blemings
---2016/02/21 09:54:59 PM---Hiya, On 16/02/2016 21:43, Tom Fifield
wrote:

From: Hugh Blemings <h...@blemings.org <mailto:h...@blemings.org>>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>, OpenStack Operators
<openstack-operat...@lists.openstack.org
<mailto:openstack-operat...@lists.openstack.org>>
Date: 2016/02/21 09:54 PM
Subject: Re: [openstack-dev] OpenStack Contributor Awards

------------



Hiya,

On 16/02/2016 21:43, Tom Fifield wrote:
 > Hi all,
 >
 > I'd like to introduce a new round of community awards handed out
by the
 > Foundation, to be presented at the feedback session of the summit.
 >
 > Nothing flashy or starchy - the idea is that these are to be a little
 > informal, quirky ... but still recognising the extremely valuable
work
 > that we all do to make OpenStack excel.
 >
 > [...]
 >
 > in the meantime, let's use this thread to discuss the fun part:
goodies.
 > What do you think we should lavish award winners with? Soft toys?
 > Perpetual trophies? baseball caps ?

I can't help but think that given the scale of a typical OpenStack
deployment and the desire for these awards to be a bit quirky, giving
recipients something at the other end of the computing scale - an
Arduino, or cluster of Raspberry Pis or similar could be kinda fun :)

Cheers,
Hugh



__
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





__
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




__
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] [all] A proposal to separate the design summit

[Tom Fifield]

On 26/02/16 22:02, Thomas Goirand wrote:

On 02/23/2016 12:33 AM, Jay Pipes wrote:

OpenStack Conference <-- The main event.
OpenStack:How <-- The developer planning event.

:)

-jay


Probably I'm dumb, but I still don't understand what's wrong with the
name "design summit" for the developer planning event.

Like most free software, OpenStack is a do-o-cracy where one must do the
things to make them happen. Sure, we do listen to our users, but the
design summit is actually where decisions are taken, like it or not...


"Implementation" decisions, yup. However, because of the position in the 
start of the planning stage of the cycle, the "design" decisions will 
happen at the main event, where we've got the users to give input.


__
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] A proposal to separate the design summit

[Tom Fifield]

Hi ops (cc: devs),

I'm writing to you to let you know why I think Thierry's proposal is a 
good one that probably works better for us than the current situation.


The design summit for us at the moment isn't as good as it could be. You 
turn up, ready to contribute and help out developers with feedback and 
ideas, and get told either "that release is too old, we fixed that 
already" or "oh, we're already well into feature design, try next 
cycle?". It's frustrating for all involved.



A key aspect of this change is the shifting of the the release cycle 
(see the diagram from Thierry). The summit becomes situated a few months 
after the previous release, and right at the start of the planning cycle 
for the next next release.


As a result, the kind of sessions we expect developers to continue to 
host at the summit are exactly the kind we can make most difference in: 
gathering feedback from the previous release, discussing requirements 
for the next next release and cross-project planning and strategy.


In that other, "new" separate developer-oriented event, the plan is that 
the discussions are about the code, not the concepts. The "How" to do 
things that were already discussed at the summit. Unless you're a 
hardcore python folk, or have specific interest in the deep details of 
how something works, in theory there'd be nothing of there of interest.


So, I think that by re-tasking the summit time, I think we actually end 
up with much more relevance at the summit for ops. The details are to be 
worked out in coming months, please participate on openstack-dev to 
ensure that we continue to achieve the "Open Design" goals of this project.



Finally, to answer one specific question:

Also where do the current operators design sessions and operators 
midcycle fit in here?


The changes in the proposal don't touch anything about the ops sessions 
at the design summit, or the ops events that happen during the cycle, 
unless you think its a good thing to do :) I have some ideas saved over 
from our last thread talking about those events, but will propose we 
move to a separate thread for this specifically to avoid drowning -dev ;)




Regards,


Tom

On 22/02/16 23:14, Thierry Carrez wrote:

Hi everyone,

TL;DR: Let's split the events, starting after Barcelona.

Long long version:

In a global and virtual community, high-bandwidth face-to-face time is
essential. This is why we made the OpenStack Design Summits an integral
part of our processes from day 0. Those were set at the beginning of
each of our development cycles to help set goals and organize the work
for the upcoming 6 months. At the same time and in the same location, a
more traditional conference was happening, ensuring a lot of interaction
between the upstream (producers) and downstream (consumers) parts of our
community.

This setup, however, has a number of issues. For developers first: the
"conference" part of the common event got bigger and bigger and it is
difficult to focus on upstream work (and socially bond with your
teammates) with so much other commitments and distractions. The result
is that our design summits are a lot less productive than they used to
be, and we organize other events ("midcycles") to fill our focus and
small-group socialization needs. The timing of the event (a couple of
weeks after the previous cycle release) is also suboptimal: it is way
too late to gather any sort of requirements and priorities for the
already-started new cycle, and also too late to do any sort of work
planning (the cycle work started almost 2 months ago).

But it's not just suboptimal for developers. For contributing companies,
flying all their developers to expensive cities and conference hotels so
that they can attend the Design Summit is pretty costly, and the goals
of the summit location (reaching out to users everywhere) do not
necessarily align with the goals of the Design Summit location (minimize
and balance travel costs for existing contributors). For the companies
that build products and distributions on top of the recent release, the
timing of the common event is not so great either: it is difficult to
show off products based on the recent release only two weeks after it's
out. The summit date is also too early to leverage all the users
attending the summit to gather feedback on the recent release -- not a
lot of people would have tried upgrades by summit time. Finally a common
event is also suboptimal for the events organization : finding venues
that can accommodate both events is becoming increasingly complicated.

Time is ripe for a change. After Tokyo, we at the Foundation have been
considering options on how to evolve our events to solve those issues.
This proposal is the result of this work. There is no perfect solution
here (and this is still work in progress), but we are confident that
this strawman solution solves a lot more problems than it creates, and
balances the needs of the various constituents of our community.

[openstack-dev] OpenStack Contributor Awards

[Tom Fifield]

Hi all,

I'd like to introduce a new round of community awards handed out by the 
Foundation, to be presented at the feedback session of the summit.


Nothing flashy or starchy - the idea is that these are to be a little 
informal, quirky ... but still recognising the extremely valuable work 
that we all do to make OpenStack excel.


There's so many different areas worthy of celebration, but we think that 
there's a few main chunks of the community that need a little love,


* Those who might not be aware that they are valued, particularly new 
contributors

* Those who are the active glue that binds the community together
* Those who share their hard-earned knowledge with others and mentor
* Those who challenge assumptions, and make us think

Since it's first time (recently, at least), rather than starting with a 
defined set of awards, we'd like to have submissions of names in those 
broad categories. Then we'll have a little bit of fun on the back-end 
and try to come up with something that isn't just your standard set of 
award titles, and iterate to success ;)


The submission form is here, so please submit anyone who you think is 
deserving of an award!




https://docs.google.com/forms/d/1HP1jAobT-s4hlqZpmxoGIGTxZmY6lCWolS3zOq8miDk/viewform



in the meantime, let's use this thread to discuss the fun part: goodies. 
What do you think we should lavish award winners with? Soft toys? 
Perpetual trophies? baseball caps ?



Regards,


Tom, on behalf of the 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] OpenStack-Announce List

[Tom Fifield]

So, I'm prompted by another 20 oslo release emails to dredge up this 
thread :)


There appears to be broad consensus that those shouldn't be going to the 
announce list ... what do we need to do to get that to change to posted 
to "-dev + batched inside the weekly -dev digest from thingee" as 
Thierry suggested?



Regards,


Tom

On 14/12/15 17:12, 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]
* 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



__
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/01/16 15:22, Andreas Jaeger wrote:

On 2016-01-14 08:13, Tom Fifield wrote:

So, I'm prompted by another 20 oslo release emails to dredge up this
thread :)

There appears to be broad consensus that those shouldn't be going to the
announce list ... what do we need to do to get that to change to posted
to "-dev + batched inside the weekly -dev digest from thingee" as
Thierry suggested?


So, those 20 odd olso release emails all went to -dev, the release team
changed the logic, see also
http://lists.openstack.org/pipermail/openstack-dev/2016-January/083749.html


Apologies to all. Maybe its time to visit the optometrist for me ... I 
haven't been once in my life yet, could be scary :)




Not sure about the "Batching inside the weekly digest from thingee",

Andreas




Regards,


Tom

On 14/12/15 17:12, 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]
* 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



__

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] [doc] DocImpact vs. reno

[Tom Fifield]

On 11/01/16 20:08, Sean Dague wrote:

On 01/10/2016 11:31 PM, Lana Brindley wrote:


Wow. That'll make the release notes process painful this round ... o.O


Hmmm. In my mind it will make it a lot easier. In the past we end up
getting to the release and sit around and go "hmmm, what did we change
in the last 6 months that people care about?" And forget 90% of it. This
does the work up front. We can then just provide a final edit and
summary of highlights, and we're done.

Having spoke with ops over the years, no one is going to be upset if we
tell them all the changes that might impact them.





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/


I can only speak on the Nova change (as that's a team I review for).
You'll see this comment in there -
https://review.openstack.org/#/c/180202/31//COMMIT_MSG - a relnote was
expected for the patch series. Whether or not it managed to slip
through, I don't know.


Confirmed - no relnotes for this.




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.



My experience would indicate that many, many DocImpact bugs are really not 
worthy of relnotes.


Can you provide some references? Again, my imagination doesn't really
come up with a lot of Nova changes that would be valid DocImpact but
wouldn't need a reno. I can see bugs filed against Docs explicitly
because there is a mismatch.


Since you wanted to focus only on nova, here's some more DocImpact 
reviews that did not have relnotes. Again, I basically haven't read 
these -  if someone wanted to do this properly, much appreciated.



https://review.openstack.org/#/c/165750/
https://review.openstack.org/#/c/184153/
https://review.openstack.org/#/c/237643/
https://review.openstack.org/#/c/180202/
https://review.openstack.org/#/c/242213/
https://review.openstack.org/#/c/224500/
https://review.openstack.org/#/c/147516/





-Sean




__
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] 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] [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

[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] 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] [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] [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

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] 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]

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] [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] [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] [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] [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] 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] 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] 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] 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] [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] [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] [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] [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] [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 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] [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] [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] 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] [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] 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] 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] 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] [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] [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] [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] 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

[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] [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