[openstack-dev] Developer Mailing List Digest March 3-9th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8361

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

* kong: Qinling now supports Node.js runtime(experimental)
* AJaeger: Jenkins user and jenkins directory on images are gone.
  /usr/local/jenkins is only created for legacy jobs
* eumel8: Zanata 4 is now here [0]
* smcginnis: Queens has been released!!
* kong: welcome openstackstatus to #openstack-qinling channel!
* Tell us yours in OpenStack IRC channels using the command "#success "
* More: https://wiki.openstack.org/wiki/Successes

[0] - https://www.translate.openstack.org


Thanks Bot Says
===
* Thanks dhellmann for setting up community wide goals + good use of storyboard
  [0]
* Thanks ianw for kind help on upgrading to Zanata 4 which has much better UI
  and improved APIs!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - https://storyboard.openstack.org/#!/project/923

Community Summaries
===
* Release countdown [0]
* TC report [1]
* Technical Committee status update [2]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128036.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128098.html


PTG Summaries
=
Here's some summaries that people wrote for their project at the PTG:

* Documentation and i18n [0]
* First Contact SIG [1]
* Cinder [2]
* Mistral [3]
* Interop [4]
* QA [5]
* Release cycle versus downstream consuming models [6]
* Nova Placements [7]
* Kolla [8]
* Oslo [9]
* Ironic [10]
* Cyborg [11]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127936.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127937.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127968.html
[3] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127988.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127994.html
[5] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128002.html
[6] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html
[7] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128041.html
[8] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128044.html
[9] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128055.html
[10] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128085.html
[11] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128094.html


OpenStack Queens is Officially Released!

Congratulations to all the teams who contributed to this release! Release notes
of different projects for Queens are available [0] and a list of projects [1]
that still need to approve their release note patches!

[0] - https://releases.openstack.org/queens/
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127813.html

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127812.html


Release Cycles vs. Downstream consumers PTG Summary
===
Notes can be found on the original etherpad [0]. A TC resolution is in review
[1]

TLDR summary:
* No consensus on longer / shorter release cycles
* Focus on FFU to make upgrades less painful
* Longer stable branch maintenance time (18 months for Ocata)
* Bootstrap the "extended maintenance" concept with common policy
* Group most impacted by release cadence are packagers/distros/vendors
* Need for finer user survey questions on upgrade models
* Need more data and more discussion, next discussion at Vancouver forum
* Release Management team tracks it between events

[0] - https://etherpad.openstack.org/p/release-cycles-ptg-rocky
[1] - https://review.openstack.org/#/c/548916/

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html


Pros and Cons of face-to-face Meetings
==
Some contributors might not be able to attend the PTG for various reasons:

* Health issues
* Privilege issues (like not getting visa or travel permits)
* Caretaking responsibilities (children, other family, animals, plants)
* Environmental concerns

There is a concern if this is preventing us from meeting our four opens [1] if
people are not able to attend the events. 

The PTG sessions are not recorded, but there is a super user article on how
teams can do this themselves [0]. At the PTG in Denver, the OpenStack
Foundation provided bluetooth speakers for teams to help with remote
participation.

Consensus is this may not be trivial for everyone and it could 

[openstack-dev] [forum] Brainstorming Topics for Vancouver 2018

[Mike Perez]

Hi all,

Welcome to the topic selection process for our Forum in Vancouver. Note that
this is not a classic conference track with speakers and presentations.
OpenStack community members (participants in development teams, SIGS, working
groups, and other interested individuals) discuss the topics they want to cover
and get alignment on and we welcome your participation.

The Forum is for the entire community to come together, to create a 
neutral space rather than having separate "ops" and "dev" days. Users should
should aim to come with ideas for for the next release, gather feedback on the
past version and have strategic discussions that go beyond just one release
cycle. We aim to ensure the broadest coverage of topics that will allow for
multiple parts of the community getting together to discuss key areas within
our community/projects.

There are two stages to the brainstorming:

1. Starting today, set up an etherpad with your team and start 
discussing ideas you'd like to talk about at the Forum and work out 
which ones to submit - just like you did prior to the design summit.

2. Then, in a couple of weeks, we will open up a more formal web-based 
tool for you to submit abstracts for the most popular sessions that came 
out of your brainstorming.

Make an etherpad and add it to the list at: 
https://wiki.openstack.org/wiki/Forum/Vancouver2018

One key thing we'd like to see (as always?) is cross-project 
collaboration, and discussion between every area of the community. Try 
to see if there is an interested working group on the user side to add 
to your ideas.

Examples of typical discussions that include multiple parts of the 
community getting together to discuss:

  * Strategic, whole-of-community discussions, to think about the big
picture, including beyond just one release cycle and new technologies
  o eg Making OpenStack One Platform for containers/VMs/Bare Metal
(Strategic session) the entire community congregates to share
opinions on how to make OpenStack achieve its integration engine
goal
  * Cross-project sessions, in a similar vein to what has happened at
past design summits, but with increased emphasis on issues that are
of relevant to all areas of the community
  o eg Rolling Upgrades at Scale (Cross-Project session) -- the
Large Deployments Team collaborates with Nova, Cinder and
Keystone to tackle issues that come up with rolling upgrades
when there's a large number of machines.
  * Project-specific sessions, where developers can ask users specific
questions about their experience, users can provide feedback from
the last release and cross-community collaboration on the priorities
and 'blue sky' ideas for the next release.
  o eg Neutron Pain Points (Project-Specific session) --
Co-organized by neutron developers and users. Neutron developers
bring some specific questions they want answered, Neutron users
bring feedback from the latest release and ideas about the future.

Think about what kind of session ideas might end up as: 
Project-specific, cross-project or strategic/whole-of-community 
discussions. There'll be more slots for the latter two, so do try and 
think outside the box!

This part of the process is where we gather broad community consensus - 
in theory the second part is just about fitting in as many of the good 
ideas into the schedule as we can.

Further details about the forum can be found at: 
https://wiki.openstack.org/wiki/Forum

-- 
Mike Perez (thingee)


pgpIwWCB79kzi.pgp
Description: PGP signature
__
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] [DriverLog] DriverLog future

[Mike Perez]

On 11:44 Mar 01, Ilya Shakhat wrote:
> Hi!
> 
> For those who do not know, DriverLog is a community registry of 3rd-party
> drivers for OpenStack hosted together with Stackalytics [1]. The project
> started 4 years ago and by now contains information about 220 drivers. The
> data from DriverLog is also consumed by official Marketplace [2].
> 
> Here I would like to discuss directions for DriverLog and 3rd-party driver
> registry as general.
> 
> 1) Being a single community-wide registry was good initially, it allowed to
> quickly collect description for most of drivers in a single place. But in a
> long term this approach stopped working - not many projects remember to
> update the information stored in some random place, right?
> 
> Mike already pointed to this problem a year ago [3] and the idea was to
> move driver list to projects (and thus move responsibility to them too) and
> have an aggregated list of drivers produced by infra. Do we have any
> progress in this direction? Is it a time to start deprecation of DriverLog
> and consider transition during Rocky release?
> 
> 2) As a project with 4 years history DriverLog's list only increased over
> the time with quite few removals. Now it still has drivers with the latest
> version Liberty or drivers for non-maintained projects (e.g. Fuel). While
> it maybe makes sense to keep all of them for operators who run older
> versions, it may produce a feeling that the majority of drivers are old.
> One of solutions for this is to show by default drivers for active releases
> only (Pike and ahead). If done this will apply to both DriverLog and
> Marketplace.
> 
> Any other ideas or suggestions?

Hey Ilya,

Yes there is progress. Thanks to others who have helped me, we have a project
called sphinx-feature-classification [0]. This allows a project to use a sphinx
directive to generate a support matrix based on drivers recorded in a INI file
[1] which lives in the project's repository.

I have also went through and found projects using the duplicate code this
library replaces and proposed changes to those projects [2].

Next steps in the library to account for:

* Releases
* Maintainers
* CI success/failure parsing patterns (do we still need this?)

Am I missing anything else? I noticed we have information in driver log and the
wiki [3] and I kind of don't know now what third-party CI's are dependent on to
work with gerrit. I'll check it out today and report back here, unless someone
knows and replies before I get a chance.


[0] - http://git.openstack.org/cgit/openstack/sphinx-feature-classification
[1] - https://docs.openstack.org/sphinx-feature-classification/latest/usage.html
[2] - https://review.openstack.org/#/q/status:+open+topic:support-matrix
[3] - https://wiki.openstack.org/wiki/ThirdPartySystems

-- 
Mike Perez (thingee)


pgpFI9A8f3PoE.pgp
Description: PGP signature
__
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] Developer Mailing List Digest February 17-23rd

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8332

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

Helpful PTG links
==
PTG is around the corner. Here are some helpful links:

* Main welcome email 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127611.html
* Quick links: http://ptg.openstack.org/
* PDF schedule: 
http://lists.openstack.org/pipermail/openstack-dev/attachments/20180221/5c279bb3/attachment-0002.pdf
* PDf map for PTG venue: 
http://lists.openstack.org/pipermail/openstack-dev/attachments/20180221/5c279bb3/attachment-0003.pdf


Success Bot Says

* mhayden: got centos OSA gate under 2h today
* thingee: we have an on-boarding page and documentation for new contributors! 
[0]
* Tell us yours in OpenStack IRC channels using the command "#success "
* More: https://wiki.openstack.org/wiki/Successes

[0] - https://www.openstack.org/community


Thanks Bot Says
===
* Thanks pkovar for keep the Documentation team going!
* Thanks pabelanger and infra for getting ubuntu mirrors repaired and backup 
quickly!
* Thanks lbragstad for helping troubleshoot an intermittent fernet token 
validation failure in puppet gates
* Thanks TheJulia for helping me with a problem last week, it was really a 
networking problem issue, like you said so :)
* Thanks tosky for backporting devstack ansible changes to pike!
* Thanks thingee for Thanks Bot
* Thanks openstackstatus for logging our things
* Thanks strigazi for the v1.9.3 image
* Thanks smcginnis for not stopping this.
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks


Community Summaries
===
* TC report [0]
* POST /api-sig/news [1]
* Release countdown [2]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127584.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127651.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html


Vancouver Community Contributor Awards
==
The Community contributor awards gives recognition to those that are
undervalued, don't know they're appreciated, bind the community together, keep
things fun, or challenge some norm. There are a lot of people out there that
could use a pat on the back and affirmation that they do good work in the
community.

Nomination period is open now [0] until May 14th. Winners will be announced in
feedback session at Vancouver.

[0] - https://openstackfoundation.formstack.com/forms/cca_nominations_vancouver

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127634.html


Release Naming For S - time to suggest a name!
==
It's time to pick a name for our "S" release! Since the associated Summit will
be in Berlin, the Geographic location has been chosen as "Berlin" (state).
Nominations are now open [0]. Rules and processes can be seen on the Governance
site [1].

[0] - https://wiki.openstack.org/wiki/Release_Naming/S_Proposals
[1] - https://governance.openstack.org/tc/reference/release-naming.html

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127592.html


Final Queens RC Deadline

Thursday 22nd of April is the deadline for any final Queens release candidates.
We'll enter a quiet period for a week in preparation of tagging the final
Queens release during the PTG week. Make sure if  you have patches merged to
stable/queens that you propose a new RC before the deadline. PTLs should watch
for a patch from the release management team tagging the final release. While
not required, an acknowledgement on the patch would be appreciated.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127540.html


Do Not Import oslo_db.tests.*
=
Deprecations were made on oslo_db.sqlalchemy.test_base package of DbFixture and
DbTestCase. In a patch [0], and assumption was made to that these should be
imported from oslo_db.tests.sqlalchemy. Cinder, Ironic and Glance have been
found with this issue [1].

Unfortunately these were not prefixed with underscores to comply with naming
conventions for people to recognize private code. The tests module was included
for consumers to run those tests on their own packages easily.

[0] - https://review.openstack.org/#/c/522290/
[1] - http://codesearch.openstack.org/?q=oslo_db.tests=nope==

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#127531


Some New Zuul Features
==
Default timeout is 30 minutes for "post-run" phase of the job. A new attribute
"timeout" [0] can set this to something else, which could be useful for 

Re: [openstack-dev] [ptg] Lightning talks

[Mike Perez]

I would like to extend the deadline for Lightning Talks at the PTG to February
23rd 23:59 UTC to fill in the few more slots we have available. Details quoted
below, thanks!

-- 
Mike Perez (thingee)

On 02:36 Feb 13, Mike Perez wrote:
> On 11:25 Feb 08, Mike Perez wrote:
> > Hey all!
> > 
> > I'm looking for six 5-minute lightning talks for the PTG in Dublin. This 
> > will
> > be on Friday March 2nd at 13:00-13:30 local time.
> > 
> > Appropriate 5 minute talk examples:
> > * Neat features in libraries like oslo that we should consider adopting in 
> > our
> >   community wide goals.
> > * Features and tricks in your favorite editor that makes doing work easier.
> > * Infra tools that maybe not a lot of people know about yet. Zuul v3 
> > explained
> >   in five minutes anyone?
> > * Some potential API specification from the API SIG that we should adopt as
> >   a community wide goal.
> > 
> > Please email me DIRECTLY the following information:
> > 
> > Title:
> > Speaker(s) full name:
> > Abstract:
> > Link to presentation or attachment if you have it already. Laptop on stage 
> > will
> > be loaded with your presentation already. I'll have open office available so
> > odp, odg, otp, pdf, limited ppt format support.


pgpruIXfUoXrO.pgp
Description: PGP signature
__
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] Thanks Bot - For a happier open source community, give recognition

[Mike Perez]

Every open source community is made up of real people with real feelings. Many
open source contributors are working in their free time to provide essential
software that we use daily. Sometimes praise is lost in the feedback of bugs or
missing features. Focusing on too much negative feedback can lead contributors
to frustration and burnout.

However you end up contributing to OpenStack, or any open source project, I
believe that what gets people excited about working with a community is some
form of recognition.

My first answer to people coming into the OpenStack community is to join our
Project Team Gathering event. Significant changes are discussed here to
understand the technical details to carry out the work in the new release. You
should seek out people who are owners of these changes and volunteer to work on
a portion of the work. Not only are these people interested in your success by
having you take on some of the work they have invested in, but you will be
doing work that interests the entire team. You’ll finish the improvements and
be known as the person in the project with the expertise in that area. You’ll
receive some recognition from the team and the community using your software.
And just like that, you’re hooked because you know your work is making a
difference. Maybe you’ll improve that area of the project more, venture onto
other parts of the project, or even expand to other open source projects.

If you work in the OpenStack community, there’s also another way you can give
and get recognition. In OpenStack IRC channels, you can thank members of the
community publicly with the following command:

#thanks  for being a swell person in that heated discussion!

To be clear,   is replaced with the person you want to give thanks.

Where does this information go? Just like the Success Bot in which we can share
successes as a community, Thanks Bot will post them to the OpenStack wiki. They
will also be featured in the OpenStack Developer Digest.

https://wiki.openstack.org/wiki/Thanks

In developing this feature, I’ve had help and feedback from various members of
the community. You can see my history of thanking people along the way, too.

At the next OpenStack event, you’re still welcome to buy a tasty beverage for
someone to say thanks. But why not give them recognition now too and let them
know how much they’re appreciated in the community?

-- 
Mike Perez (thingee)


pgp31hDmM_C7G.pgp
Description: PGP signature
__
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] [contributor-guide] Contributor Guide Discussion and Hacking Sessions

[Mike Perez]

Hey all,

Our set of Contributor Guides [0] are making progress in providing our
community with content for on-boarding new contributors of different types of
work.

At the PTG we'll be sharing space with the Documentation and i18n teams [2]. On
Tuesday at 9:00-10:15 AM local time we'll be discussing next steps with the
Contributor Guide of what's left from our StoryBoard tasks [3] and the current
vision.

There will also be impromptu meetup/hacking sessions [4] happening Monday thru
Wednesday on the Contributor Guide with the OpenStack Upstream Institute team,
who are interested in using this content for future events. You can read about
contributing to the Contributor Guide for help [5].

I will be unable to physically attend the PTG this time, but Kendall Nelson
(diablo_rojo on IRC) will be around to help lead these sessions. I will however
be around on #openstack-doc to help with reviews or discussions in the
mentioned impromptu hack times.

Thanks everyone!

[1] - https://docs.openstack.org/contributors/
[2] - https://etherpad.openstack.org/p/docs-i18n-ptg-rocky
[3] - https://storyboard.openstack.org/#!/project/913
[4] - https://etherpad.openstack.org/p/OUI-Rocky-PTG
[5] - https://docs.openstack.org/contributors/contributing

-- 
Mike Perez (thingee)


pgplJQTCgXrjL.pgp
Description: PGP signature
__
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] Developer Mailing List Digest February 10-16th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8321

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev and SIG List threads:
* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

None for this week. Tell us yours in OpenStack IRC channels using the command
"#success "

More: https://wiki.openstack.org/wiki/Successes


Thanks Bot Says
===
* diablo_rojo on #openstack-101 [0]: spotz for watching the #openstack-101
  channel and helping to point newcomers to good resources to get them started
  :)
* fungi on #openstack-infra [1]: dmsimard and mnaser for getting deep-linking
  in ara working for firefox
* fungi on #openstack-infra [2]: to Matt Van Winkle for volunteering to act as
  internal advocate at Rackspace for our control plane account there!
* AJaeger on #openstack-doc [3]: corvus for deleting /draft content
* AJaeger on #openstack-infra [4]: cmurphy for your investigation
* AJaeger on #openstack-infra [5]: to mordred for laying wonderful groundwork
  with the tox_siblings work.
* smcginnis on #openstack-infra [6]: fungi jeblair mordred AJaeger and other
  infra-team members for clearing up release job issues
* fungi on #openstack-infra [7]: zuul v3 for having such detailed configuration
  syntax error reporting.
* fungi on #openstack-dev [8]: diablo_rojo and persia for smooth but "rocky"
  ptl elections!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-101/%23openstack-101.2017-12-13.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-20.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-09.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-doc/%23openstack-doc.2018-01-22.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-30.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-03.log.html
[6] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-11.log.html
[7] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-14.log.html
[8] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-15.log.html


Community Summaries
===
Nova Placement update [0]
Release Countdown [1]
TC Report [2]
Technical Committee Status update [3]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127473.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127324.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127467.html


PTG Bot HOWTO for Dublin

The third PTG is an event where topics of discussion are loosely scheduled in
tracks to maximize the attendee productivity. To keep track of what's happening
currently we have an event schedule page [0]. Below are some helpful
discussions in using PTG bot:

Track Leads
---
Track leads will be able issue various commands [1] in irc channel
#openstack-ptg:
* #TRACK now 
  - example: #swift now brainstorming improvements to the ring.

* Cross project interactions #TRACK now :
  - #nova now discussing #cinder interactions

* What's next #TRACK next :
  -  #api-sig next at 2pm we'll be discussing pagination woes

* Clear all now and next entries for a track #TRACK clean:
  - #ironic clean

Booking Reservable Rooms

Reservable rooms and what's being discussed works the same with it showing on
the event schedule page [0].

Different set of commands:
* Get the slot codes with the book command #TRACK book:
* Book a room with #TRACK book 
  - example: #relmgt book Coiste Bainisti-MonP2

Any track can book additional space. These slots are 1 hour and 45 minutes
long. You can ask ttx, diablo_rojo or #openstack-infra to add a track that's
missing. Keep in mind various teams will be soley relying on this for space at
the PTG.

Additional commands can be found in the PTG bot README [1].

[0] - http://ptg.openstack.org/ptg.html
[1] - https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst

Full messages:
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127413.html
and
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127414.html


PTL Election Results and Conclusions

[openstack-dev] Feedback on the Dev Digest

[Mike Perez]

Hey all,

I setup a two question survey asking about your frequency with the Dev Digest,
and how it can be improved:

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

In case you're not familiar, the Dev Digest tries to provide summaries of the
OpenStack Dev mailing list, for people who might not have time to read every
message and thread on the list. The hope is for people to be informed on
discussions they would've otherwise missed, and be able to get caught up to 
chime in if necessary. This is a community effort worked on via etherpad:

https://etherpad.openstack.org/p/devdigest

The content on Fridays is posted to the Dev list in plaintext, LWN, Twitter and
the OpenStack blog:

https://www.openstack.org/blog/

Thank you!

-- 
Mike Perez (thingee)


pgpfVEzvu3UKl.pgp
Description: PGP signature
__
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] Lightning talks

[Mike Perez]

On 11:25 Feb 08, Mike Perez wrote:
> Hey all!
> 
> I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
> be on Friday March 2nd at 13:00-13:30 local time.
> 
> Appropriate 5 minute talk examples:
> * Neat features in libraries like oslo that we should consider adopting in our
>   community wide goals.
> * Features and tricks in your favorite editor that makes doing work easier.
> * Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
>   in five minutes anyone?
> * Some potential API specification from the API SIG that we should adopt as
>   a community wide goal.
> 
> Please email me DIRECTLY the following information:
> 
> Title:
> Speaker(s) full name:
> Abstract:
> Link to presentation or attachment if you have it already. Laptop on stage 
> will
> be loaded with your presentation already. I'll have open office available so
> odp, odg, otp, pdf, limited ppt format support.
> 
> Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
> emails to speakers requesting for slides. Thank you, looking forward to 
> hearing
> some great talks from our community!

Hey all,

Just a reminder that lightning talk proposals for the PTG in Dublin is due
February 16 at 00:00 utc. We're building up a nice line up already. Details
quoted above, Thanks!

-- 
Mike Perez (thingee)


pgp7ITUfTXQZX.pgp
Description: PGP signature
__
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] Developer Mailing List Digest February 3-9th

[Mike Perez]

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: https://www.openstack.org/blog/?p=8287

Success Bot Says
* stephenfin on #openstack-nova [0]: After 3 years and 7 (?) releases,
  encryption between nova's consoleproxy service and compute nodes is finally
* possible ✌️
* AJaeger on #openstack-infra [1]: zuul and nodepool feature/zuulv3 branches
  have merged into master
* ildikov on #openstack-nova [2]: OpenStack now supports to attach a Cinder
  volume to multiple VM instances managed by Nova.
* mriedem on #openstack-nova [3]: osc-placement 1.0.0 released; you can now do
  things with resource providers/classes via OSC CLI now.
* AJaeger on #openstack-infra [4]: All tox jobs have been converted to Zuul v3
  native syntax, run-tox.sh is gone.
* ttx on #openstack-dev [5]: All teams have at least one candidate for PTL for
  the Rocky cycle! Might be the first time.
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-15.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-18.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-23.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-24.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-07.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-08.log.html


Community Summaries
===
* Release countdown [0]
* Nova placement resource provider update [1]
* TC Report [2]
* POST /api-sig/news [3]
* Technical Committee Status Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127120.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127203.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127012.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127140.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127192.html


Dublin PTG Schedule is Up
=
PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to
discuss additional topics that take half a day and can be requested [1]. For
small things (90 min discussions) we can book them dyncamically during the
event with the new PTG bot features. Follow the thread for updates to the
schedule [2].

[0] - https://www.openstack.org/ptg#tab_schedule
[1] - https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892


Last Chance for PTG Dublin Tickets
==
PTG tickets for Dublin were sold out this week, and the Foundation received
many requests for more tickets. Working with the venue to accommodate the extra
capacity, every additional attendee incrementally increases costs to $600. It's
understood the importance of this event and the need to have key team members
present, so the OpenStack Foundation has negotiated an additional 100 tickets
and will partially subsidize to be at sold at $400 [0].

[0] - 
https://www.eventbrite.com/e/project-teams-gathering-dublin-2018-tickets-39055825024

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127129.html


New Zuul Depends-On Syntax

Recently introduced url-based syntax for Depends-On: footer in your commit 
message:

Depends-On: https://review.openstack.org/535851

Old syntax will continue to work for a while, but please begin using the new
syntax. Zuul has grown the ability to talk to multiple backend systems (Gerrit,
Git and plain Git so far).

From a change in gerrit you could have:
Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or from a Github pull request:
Depends-On: https://review.openstack.org/536159

Tips and certain cases contained further in the full message.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html


Call For Mentors and Funding

The Outreachy program [0] helps people of underrepresented groups get involved
in free and open source software by matching interns with established mentors
in the upstream community.

OpenStack will be 

[openstack-dev] [ptg] Lightning talks

[Mike Perez]

Hey all!

I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
be on Friday March 2nd at 13:00-13:30 local time.

Appropriate 5 minute talk examples:
* Neat features in libraries like oslo that we should consider adopting in our
  community wide goals.
* Features and tricks in your favorite editor that makes doing work easier.
* Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
  in five minutes anyone?
* Some potential API specification from the API SIG that we should adopt as
  a community wide goal.

Please email me DIRECTLY the following information:

Title:
Speaker(s) full name:
Abstract:
Link to presentation or attachment if you have it already. Laptop on stage will
be loaded with your presentation already. I'll have open office available so
odp, odg, otp, pdf, limited ppt format support.

Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
emails to speakers requesting for slides. Thank you, looking forward to hearing
some great talks from our community!

-- 
Mike Perez (thingee)


pgppqFF0WWDDV.pgp
Description: PGP signature
__
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] Developer Mailing List Digest January 5-12th

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2018/01/developer-mailing-list-digest-january-5-12th/

Success Bot Says

* e0ne on #openstack-horizon [0]: amotoki runs horizon with django 2.0
* tristianC on #rdo [1]: review.rdoproject.org is now running sf-2.7
* mriedem on #openstack-nova [2]: nova merged alternate hosts support for
  server build
* mriedem on #openstack-nova [3]: After a week of problems, finally got
  a volume multiattach test run to actually attach a volume to two instances
  without melting the world. \o/
* zaneb [4]: 14% reduction in Heat memory use in the TripleO gate from fixing
  https://bugs.launchpad.net/heat/+bug/1731349
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2017-12-18.log.html
[1] - http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2017-12-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-12-22.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-05.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2018-01-09.log.html

Community Summaries
===
* Technical Committee Status update [0]
* POST /api-sig/news [1]
* Release countdown [2]
* Nova placement resource provider update [3]
* Keystone team update [4]
* Nova Notification Update [5]
* TC report [6]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126178.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126147.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125996.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126179.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126188.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126025.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126082.html


Community Goals for Rocky
=
So far one goal has been proposed by Kendall Nelson for migrating to
Storyboard. It was agreed to postpone the goal until the S cycle, as it could
take longer than six months to achieve. There is a good backlog of goals [0],
just no champions. It'll be bad for momentum if we have a cycle with no
community wide goal.

[0] - https://etherpad.openstack.org/p/community-goals

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126090.html

PTG Post-lunch Presentations

Feedback received from past PTG session(s) was the lack of situational
awareness and missed opportunity for "global" communication at the event. In
Dublin we'd used the end of the lunch break to for communications that could be
interesting to OpenStack upstream developers and project team members. The idea
is not to find a presentation for everyday, but if we find content that is
generally useful. Interesting topics include general guidance to make the most
of the PTG weeks (good Monday content), development tricks, code review
etiquette, new library features you should adopt, lightning talks (good Friday
content). We'd like to keep the slot under 20 minutes. If you have ideas please
fill out this etherpad [0] in a few weeks.

[0] - https://etherpad.openstack.org/p/dublin-PTG-postlunch

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126102.html


signature.asc
Description: PGP signature
__
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] Developer Mailing List Digest November 25 to December 1st

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-november-25-to-december-1st/


News

* Project Team Gather (PTG) in Dublin registration is live [0]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124978.html



Community Summaries
===
* TC report by Chris Dent [0]
* Release countdown [1]
* Technical Committee Status updated [2]
* POST /api-sig/news [3]
* Nova notification update [4]
* Nova placement resource providers update [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124964.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125054.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125099.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125071.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125146.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125117.html



Dublin PTG Format
=
We will continue themes as we did in Denver, but shorter times like half 
days.
Flexibility is added for other groups to book the remaining available 
rooms in

90-min slots on-demand driven by the PTG Bot. So far the split of having
Monday-Tuesday be dedicated to themes and Wednesday-Frday dedicated to 
teams as

we've done in previous PTG's is a winning decision.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124898



First Contact SIG
=
A wiki has been created for the group [0]. The group is looking for 
intersted

people being points of contact for newcomers and what specified timezones.
Resource links like contributor portal, mentoring wiki, Upstream Institute,
outreachy are being collected on the wiki page. A representative from the
operators side to chair and represent would be good.

[0] - https://wiki.openstack.org/wiki/First_Contact_SIG

Policy Goal Queens-2 Update
===
Queens-2 coming to a close, we recap our community wide goal for 
policies [0].

If you want your status changed, contact Lance Bragstad. Use the topic
policy-and-docs-in-code for tracking related code changes.

Not Started
---
* ceilometer
* congress
* networking-bgpvpn
* networking-midonet
* networking-odl
* neutron-dynamic-routing
* neutron-fwaas
* neutron-lib
* solum
* swift


In Progress
---
* barbican
* cinder
* cloudkitty
* glance
* heat
* manila
* mistral
* neutron
* panko
* python-heatclient
* tacker
* tricircle
* trove
* vitrage
* watcher
* zaqar

Completed
-
* designate
* freezer
* ironic
* keystone
* magnum
* murano
* nova
* octavia
* sahara
* searchlight
* senlin
* zun


Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124966



Tempest Plugin Split Goal
=
A list of open reviews [0] is available for the Tempest plugin split 
goal [1].


Not Started
---
* Congress
* ec2-api
* freezer
* mistral
* monasca
* senlin
* tacker
* Telemetry
* Trove
* Vitrage

In Progress
---
* Cinder
* Heat
* Ironic
* magnum
* manila
* Neutron
* murano
* networking-l2gw
* octavia

Completed
-
* Barbican
* CloudKitty
* Designate
* Horizon
* Keystone
* Kuryr
* Sahara
* Solum
* Tripleo
* Watcher
* Winstackers
* Zaqar
* Zun

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125131.html



[0] - 
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open
[1] - 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.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] [all] Community managed tech/dev blog: Call for opinions and ideas

[Mike Perez]

On 10:45 Nov 28, Jimmy McArthur wrote:
> Thierry Carrez wrote:
> >
> >What Josh wants is a curated technical blog, so if we reused blog.o.o
> >for this (and I think it's a good idea), we'd likely want to have a bit
> >more rules on what's appropriate.
> 
> Agreed. It's almost solely used for developer digest now and isn't
> frequently updated. Most of the promotion of sponsors and news goes into
> o.o/News, SuperUser, or one of our other marketing channels. It's a good
> time for the community to repurpose it :)

+1 from me to bring more life to the blog than just the dev digest!

-- 
Mike Perez (thingee)


pgpdODcUhXcyI.pgp
Description: PGP signature
__
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] Developer Mailing List Digest November 18-27

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-18-27/


Community Summaries
===
* Glance priorities [0]
* Nova placement resource provider update [1]
* Keystone Upcoming Deadlines [2]
* Ironic priorities and subteam reports [3]
* Keystone office hours [4]
* Nova notification update [5]
* Release countdown [6]
* Technical committee status update [7]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124678.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124429.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124727.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124731.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124820.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124900.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124882.html
[7] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124875.html


Self-healing SIG created


Adam Spiers announced the formation of a SIG around self-healing. Its scope is 
to coordinate the use and development of several OpenStack projects which can 
be combined in various ways to manage OpenStack infrastructure in a 
policy-driven fashion, reacting to failures and other events by automatically 
healing and optimising services.

Full thread: 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000170.html


Proposal for a QA SIG
=

A proposal to to have a co-existing QA special interest group (SIG) that would
be a place for downstream efforts to have a common place in collaborating and
sharing tests. Example today the OPNFV performs QA on OpenStack releases today
and are actively looking for opportunieis to share tools and test cases. While
a SIG can exist to do some code, the QA team will remain for now since there
are around 15 QA projects existing like Tempest and Grenade.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124662


Improving the Process for Release Marketing
===

Collecting and summarizing "top features" during release time is difficult for
both PTL's and Foundation marketing. A system is now in place for PTL's to
highlight release notes [0]. Foundation marketing will work with the various
teams if needed to understand and make things more press friendly.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124726

[0] - http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466

-- 
Mike Perez (thingee)


pgp4aZbH06Cqz.pgp
Description: PGP signature
__
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] Developer Mailing List Digest November 11-17

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-11-17

Summaries
=
* POST /api-sig/news [0]
* Release countdown for week R-14, November 18-24 [1]
[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124633.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124631.html


Upstream Long Term Support Releases
===
The Sydney Summit had a very well attended and productive session [0] about to
go about keeping a selection of past releases available and maintained for long
term support (LTS).

In the past the community has asked for people who are interested in old
branches being maintained for a long time to join the Stable Maintenance team
with the premise that if the stable team grew, it could support more branches
for longer periods. This has been repeated for about years and is not working.

This discussion is about allowing collaboration on patches beyond end of life
(EOL) and enable whoever steps up to maintain longer lived branches to come up
with a set of tests that actually match their needs with tests that would be
less likely to bitrot due to changing OS/PYPI substrate. We need to lower
expectations of what we're likely to produce will get more brittle the older
the branch gets. Any burden created by taking on more work is absorbed by
people doing the work, as does not unduly impact the folks not interested in
doing the work.

The idea is to continue the current stable policy more or less as it is.
Development teams take responsibility of a couple of stable branches. At some
point what we now call an EOL branch, instead of deleting it we would leave it
open and establish a new team of people who want to continue to main that
branch. It's anticipated the members of those new teams are coming mostly from
users and distributors. Not all branches are going to attract teams to maintain
them, and that's OK.

We will stop tagging these branches so the level of support they provide are
understood. Backports and other fixes can be shared, but to consume them, a
user will have to build their own packages.

Test jobs will run as they are, and the team that maintain the branch could
decide how to deal with them. Fixing the jobs upstream where possible is
preferred, but depending on who is maintaining the branch, the level of support
they are actually providing and the nature of the breakage, removing individual
tests or whole jobs is another option. Using third-party testing came up but is
not required.

Policies for the new team being formed to maintain these older branches is
being discussed in an etherpad [2].

Some feedback in the room expressed they to start one release a year who's
branch isn't deleted after a year. Do one release a year and still keep N-2
stable releases around. We still do backports to all open stable branches.
Basically do what we're doing now, but once a year.

Discussion on this suggestion extended to the OpenStack SIG mailing list [1]
suggesting that skip-release upgrades are a much better way to deal with
upgrade pain than extending cycles. Releasing every year instead of a 6 months
means our releases will contain more changes, and the upgrade could become more
painful. We should be release often as we can and makes the upgrades less
painful so versions can be skipped.

We have so far been able to find people to maintain stable branches for 12-18
months. Keep N-2 branches for annual releases open would mean extending that
support period to 2+ years. If we're going to do that, we need to address how
we are going to retain contributors.

When you don't release often enough, the pressure to get a patch "in"
increases. Missing the boat and waiting for another year is not bearable.


[0] - https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
[1] - 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html
[2] - https://etherpad.openstack.org/p/LTS-proposal

-- 
Mike Perez (thingee)


pgpQn5z3KGpek.pgp
Description: PGP signature
__
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] Developer Mailing List Digest October 28th - November 3rd

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-october-28th-november-3rd/

News

* Sydney Summit Etherpads [0]

[0] - https://wiki.openstack.org/wiki/Forum/Sydney2017


Community Summaries
===
Nova Placements Resource Provider Update by Eric Fried [0]
Nova Notification Update by Balazs Gibizer [1]
Technical Committee Status update by Thierry Carrez [2]
Technical Committee Report by Chris Dent [3]
Release Countdown by Sean McGinnis [4]
POST /api-sig/news by Chris Dent [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124233.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124079.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124049.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124134.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123799.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html


TC Election Results (continued)
===
Congrats to our 6 newly elected Technical Committee members:
Colleen Murphy (cmurphy)
Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Julia Kreger (TheJulia)
Paul Belanger (pabelanger)

Full results are available [0]. The process and results are also available [1].
420 voted out of 2430 electorate, giving us a 17.28% turn out with a delta of
29.16% [2].

Reasons for the low turnout is hard to tell without knowing who is voting and
what their activity is in the community. More people are beginning to
understand the point of the TC activities, being more around duties than rights
(e.g. stewardship and leadership). People could care a bit less about specific
individuals and are less motivated by the vote itself. If the activity of the
TC was a lot more conflict and a lot less consensus, people might care about it
more.

[0] - http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
[1] - https://governance.openstack.org/election/
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123848.html

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124004


Security SIG

Our governance used to only have project teams to recognize activity in
OpenStack, so we created a security team. Introduction of sigs provide a new
construct for recognizing activity around a group that share interest around
a topic or practice that are not mainly around software bits.

Security is a great example of a topic that could benefit from this construct
to gather all security-conscious people in our community. SIGs can have
software by-products and own git repositories, and the software is more about
security in general than a piece of OpenStack itself.

It's important to consider the Vulnerability Management Team (VMT) under the
new model, which acts as an independent task force.

The Security team discussed the idea of a SIG in their meeting, and overall
think it's worth exploring by having the SIG and team exist in parallel to see
if there is traction.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124053

-- 
Mike Perez (thingee)


pgpVF01hhDNf9.pgp
Description: PGP signature
__
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] [ptls] MOAR UPDATES: Sydney Project Onboarding

[Mike Perez]

On 02:34 Oct 24, Dave McCowan (dmccowan) wrote:
> We're working on the Barbican Onboarding session now.  I don't think our 
> Boston session went very well, and the results borne out; we were unable to 
> convert any attendee to active contributor.  It was a much bigger group than 
> I was expecting and everyone was at a different starting point .  I was 
> unprepared for both of those situations.
> 
> I'd like to hear some success stories from Boston to learn from.
> 
> For projects that were successful, what topics did you cover?
> For prospective Sydney Onboarders, what do you want to learn at these 
> sessions?

An effort we talked about at the last PTG and finally surfaced is the
contributor portal [1] and contributor guide [2].

The portal is a good landing page to explore different projects and their
contributor guides listed in the project yaml [3].

The contributor guide is included on the portal and the hope is people go
through that first which includes general topics like irc setup, account setup
and git setup. More people can contribute general topics so all projects
benefit.

The contributor guide should at least cover those topics for you to have groups
break off and do. Then you can spend your preparing time on other topics like
team specific topics and tools.

If anyone has time and wants to help all projects choosing to use this guide,
read my previous post [3] announcing this project and asking for help.

[1] - https://www.openstack.org/community/
[2] - https://docs.openstack.org/contributors/
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123740.html

-- 
Mike Perez


pgpECvMlJObHd.pgp
Description: PGP signature
__
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] [ironic] [requirements] moving driver dependencies to global-requirements?

[Mike Perez]

On 17:51 Oct 30, Dmitry Tantsur wrote:
> Hi all,
> 
> So far driver requirements [1] have been managed outside of
> global-requirements. This was mostly necessary because some dependencies
> were not on PyPI. This is no longer the case, and I'd like to consider
> managing them just like any other dependencies. Pros:
> 1. making these dependencies (and their versions) more visible for packagers
> 2. following the same policies for regular and driver dependencies
> 3. ensuring co-installability of these dependencies with each other and with
> the remaining openstack
> 4. potentially using upper-constraints in 3rd party CI to test what
> packagers will probably package
> 5. we'll be able to finally create a tox job running unit tests with all
> these dependencies installed (FYI these often breaks in RDO CI)

I noticed Cinder is doing this with drivers, but in a different file:

http://git.openstack.org/cgit/openstack/cinder/tree/driver-requirements.txt

-- 
Mike Perez


pgpjj5AdeWm9b.pgp
Description: PGP signature
__
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] Developer Mailing List Digest September 30 – October 6

[Mike Perez]

Thanks to Thierry Carrez and Jeremy Stanley for summarizing this issue of the
Dev Digest!

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML Version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-october-21-27-2017/



News

* TC election results [0]
* Next PTG will be in Dublin, the week of February 26, 2018. More details will
  be posted on openstack.org/ptg as soon as we have them. [1]

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123845.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/124021.html

 
SuccessBot Says
===
* gothamr_  [0]:changes to the manila driverfixes branches can finally be
  merged xD Thanks infra folks for ZuulV3!
* andreaf [1]: Tempest test base class is now a stable API for plugins
* More [2]

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2017-10-17.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-10-24.log.html
[2] - https://wiki.openstack.org/wiki/Successes

 
Community Summaries
===
* TC Report 43 by Chris Dent [0]
* Nova Notification Update Week 43 by Balazs Gibizer [1]
* POST /api-sig/news by Chris Dent [2]
* Technical Committee Status Update by Thierry Carrez [3]
* Nova Placements Resource Provider Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123944.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123990.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123818.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124052.html

 
Time to Remove the Ceilometer API?
==
Summarized by Jeremy Stanley
 
The Ceilometer REST API was deprecated in Ocata, a year ago, and the User
Survey indicates more than half its users have switched to the non-OpenStack
Gnocchi service's API instead (using Ceilometer as a backend). The Ceilometer
install guide has also been recommending Gnocchi at least as long ago as
Newton. The old API has become an attractive nuisance from the Telemetry team's
perspective, and they'd like to go ahead and drop it altogether in Queens.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123593.html
 
 
Keystone v2.0 API Removal
=
Summarized by Thierry Carrez
 
Keystone Queen's PTL Lance Bragstad gives notice that the Queen's release will
not be included v2.0, except the ec2-api. This is being done after a lengthy
given deprecation period.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123783.html


pgpB2eZcqVoRU.pgp
Description: PGP signature
__
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] [all] TC Report 43

[Mike Perez]

On 11:17 Oct 25, Flavio Percoco wrote:
> On 24/10/17 19:26 +0100, Chris Dent wrote:
> >It's clear that anyone and everyone _could_ write their own blogs and
> >syndicate to the [OpenStack planet](http://planet.openstack.org/) but
> >this doesn't have the same panache and potential cadence as an
> >official thing _might_. It comes down to people having the time. Eking
> >out the time for this blog, for example, can be challenging.
> >
> >Since this is the second [week in a
> >row](https://anticdent.org/tc-report-42.html) that Josh showed up with
> >an idea, I wonder what next week will bring?
> 
> I might not be exactly the same but, I think the superuser's blog could be a
> good place to do some of this writing. There are posts of various kinds in 
> that
> blog: technical, community, news, etc. I wonder how many folks from the
> community are aware of it and how many would be willing to contribute to it 
> too.
> Contributing to the superuser's blog is quite simple, really.

Anne used to do TC updates and they were posted to the OpenStack Blog:

https://www.openstack.org/blog/category/technical-committee-updates/

-- 
Mike Perez


pgpHJDadMERqZ.pgp
Description: PGP signature
__
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 Dev Digest is Open to Volunteers!

[Mike Perez]

On 19:06 Oct 17, Mike Perez wrote:
> Hey all,
> 
> The OpenStack Dev Digest has been receiving great feedback from various 
> members
> of our community as being a good resource to get important summaries of 
> threads
> they might be interested in responding back to and/or being informed on.
> 
> Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
> when I can, gets posted on the dev list, the operators lists, OpenStack
> twitter, and LWN [2].
> 
> Summarizing everything can be a lot of work. I recently read the User Group
> Newsletter [3] by Sonia Ramza and noticed the content is created by the
> community via an etherpad.
> 
> I would like to do the same with the Dev Digest and have started a new 
> etherpad
> [4]. I will still be writing the Dev Digest and acting editor, but hoping to
> lean more on the community for content I might've missed and getting
> corrections.
> 
> The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
> you!
> 
> [1] - https://www.openstack.org/blog
> [2] - https://lwn.net
> [3] - 
> https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
> [4] - https://etherpad.openstack.org/p/devdigest

Reminder the cut off is tomorrow at 19:00 UTC. Thanks Fungi for writing on
"Time To Remove the Ceilometer API"!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Dev Digest is Open to Volunteers!

[Mike Perez]

Hey all,

The OpenStack Dev Digest has been receiving great feedback from various members
of our community as being a good resource to get important summaries of threads
they might be interested in responding back to and/or being informed on.

Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
when I can, gets posted on the dev list, the operators lists, OpenStack
twitter, and LWN [2].

Summarizing everything can be a lot of work. I recently read the User Group
Newsletter [3] by Sonia Ramza and noticed the content is created by the
community via an etherpad.

I would like to do the same with the Dev Digest and have started a new etherpad
[4]. I will still be writing the Dev Digest and acting editor, but hoping to
lean more on the community for content I might've missed and getting
corrections.

The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
you!

[1] - https://www.openstack.org/blog
[2] - https://lwn.net
[3] - 
https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
[4] - https://etherpad.openstack.org/p/devdigest

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][docs][contributor-guide] Onboarding Contributor Content Help Wanted

[Mike Perez]

Hey all,

tldr; There's an effort to collect general documentation for new OpenStack
contributors. The content that qualifies as general so far is Git, IRC, account
setup. We are looking for help to write new content at the git repo
openstack/contributor-guide.

No that subject tag is not a mistake. There are two projects recently that I've
been active with that have the word "Contributor" in it.

1) Contributor Portal - The openstack.org/community page update that focuses
   more on guiding potential contributors to areas of interest. This will link
   people to the general documentation set for that category (The Contributor
   Guide)and the project team's specific documentation if any. Everyone gets
   general onboarding contributor documentation for free! In addition it serves
   as a great landing page of resources for existing contributors. [1]

2) Contributor Guide - A sphinx project of where the general documentation
   is stored. [2] I'm waiting on a couple of patches to merge [3][4], but this
   will be published at https://docs.openstack.org/contributors

My goal is to make the Contributor Guide and Contributor Portal available to
all projects for their Onboarding rooms in Sydney [5].

If you're not familiar with this effort, we're creating general documentation
(e.g. IRC, git, account setup, and more) in an effort to keep them up-to-date
and not have outdated silos of this type of documentation. From the PTG
discussion [4] it was agreed that general documentation can live in a separate
repository (i.e. Contributor Guide), but project specific documentation will
continue to live in the development documentation of the respected project.

I'm looking for volunteers to help build our Contributor guide. I think
a good starting point is to look at how we can help keep some content fresh for
things like the Upstream Institute [6]. They have a great layout that we can
build off of from their content page [7].

If anyone is interested in helping with making our onboarding experience
better, please checkout the git repository [8] and lets collaborate on this
content. I'm thingee on freenode and in the #openstack-doc room for these
related discussions.

Shout out to Kendall Nelson, Anne Bertucio, Frank Kloeker, Ildiko Vancsa, Amy
Marrich, Thierry Carrez, Lauren Sell, Jimmy McArthur, Wes Wilson, the
Documentation Core team, and Infra core team for getting this project going!

Thanks!

[1] - http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html
[2] - https://review.openstack.org/#/c/511033/
[3] - https://review.openstack.org/#/c/512865/
[4] - https://review.openstack.org/#/c/512871/
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123206.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html
[7] - https://docs.openstack.org/upstream-training/
[8] - 
https://docs.openstack.org/upstream-training/upstream-training-content.html
[9] - https://git.openstack.org/contributor-guide

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [forum] Schedule Is Available

[Mike Perez]

On 16:43 Oct 16, Mike Perez wrote:
> Hey all,
> 
> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
> the
> schedule posted on the Summit site filtering by forum related sessions:
> 
> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63
> 
> Please reply to give corrections.
> 
> I will be sending emails to listed moderators to verify there will be someone
> physically present at the Forum to moderate the session. Thank you!

Hey all,

I was infomed that making changes to the schedule can cause a cascade of
conflicts at this point. If you are scheduled however at multiple places at
once, please let us know at speakersupp...@openstack.org

Thanks everyone!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [forum] Schedule Is Available

[Mike Perez]

Hey all,

Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's the
schedule posted on the Summit site filtering by forum related sessions:

https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63

Please reply to give corrections.

I will be sending emails to listed moderators to verify there will be someone
physically present at the Forum to moderate the session. Thank you!

-- 
Mike Perez


pgp9j7R_QsGGu.pgp
Description: PGP signature
__
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] Developer Mailing List Digest September 30 - October 6

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-september-30-6-2017/

## Summaries
* OpenStack Technical Committee
*  [TC report 
40](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123063.html)
 by Chris Dent
* [TC report 
41](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123397.html)
 by Chris Dent
* [Technical Committee Status update, October 
6th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123236.html)
 by Thierry Carrez
* [Technical Committee Status update, October 
13th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123573.html)
 by Thierry Carrez
* Zuul
* [Zuul v3 Status - and Rollback 
Information](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123049.html)
  by Monty Taylor
* [Important information for people with in-repo Zuul v3 
config](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123064.html)
 by Monty Taylor
* [Zuul v3 rollout, the 
sequel](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html)
 by Jeremy Stanley
* [Zuul v3 Rollout Update - devstack-gate issues 
edition](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123464.html)
 by Monty Taylor
* [Zuul v3 rollout, the sequel 
returns](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123618.html)
 by Jeremy Stanley
* [POST 
/api-sig/news](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123208.html)
* [Release countdown for week R-19, October 
13-20](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123516.html)
 by Sean McGinnis
* [QA Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123520.html)
 by Andrea Frittoli
* [Keystone Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123271.html)
 by Lance Bragstad
* Nova
* [Placement resource providers update 
36](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123244.html)
 by Chris Dent
* [Placement resource providers update 
38](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123581.html)
 by Chris Dent

## Sydney Forum Schedule Available
* [View it 
now!](https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63)

## TC Nomination Period Is Now Over
* Kendall Nelson has announced the [official candidate 
list](https://governance.openstack.org/election/#pike-tc-candidates).

## Prepping for the Stable/Newton EOL
* The [published timeline](https://releases.openstack.org/queens/schedule.html) 
is:
* Sep 29 : Final newton library releases
* Oct 09 : stable/newton branches enter Phase III
* Oct 11 : stable/newton branches get tagged EOL
* Given that those key dates were a little disrupted, Tony Breeds is proposing
  adding a week to each so the new timeline looks like:
* Oct 08 : Final newton library releases
* Oct 16 : stable/newton branches enter Phase III
* Oct 18 : stable/newton branches get tagged EOL
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#123088)

## Policy Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/policy-in-code.html)
* [Burn down chart](https://www.lbragstad.com/policy-burndown/)
* Over half the projects attempted the goal.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123040.html)

## Tempest Plugin Split Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html)
* [The 
reviews](https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open)
* List of projects which have already completed the goal:
- Barbican
- Designate
- Horizon
- Keystone
- Kuryr
- Os-win
- Sahara
- Solum
- Watcher
* List of projects which are working on the goal:
- Aodh
- Cinder
- Magnum
- Manila
- Murano
- Neutron
- Neutron L2GW
- Octavia
- Senlin
- Zaqar
- Zun
- 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html)


signature.asc
Description: PGP signature
__
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] [forum] Draft Schedule - Deadline Oct 13 Friday 20:00 UTC

[Mike Perez]

nder Block Storage Office Hour  Jay Bryant
11/7 5:00-5:40
Keystone Operator & User Feedback Lance Bragstad
11/7 5:50-6:30
Cells v2 update and direction Matt Riedemann
11/7 5:50-6:30
Trove user feedback   Manoj Kumar   
11/7 5:50-6:30
Java SDKs David F Flanders  
11/7 9:00-9:40
Self-healing and optimization SIG Adam Spiers   
11/7 9:00-9:40
Interop Test Library for OpenStack SDKs   megan 
11/7 9:00-9:40
Users / Operators adoption of QA tools / plugins  Andrea Frittoli   
11/7 9:50-10:30
OpenStack Charms user feedback sessionJames Page
11/7 9:50-10:30
Zuulv3 Feedback Session   Clark Boylan  
11/7 9:50-10:30
Placement update and directionMatt Riedemann
11/8 1:50-2:30
Designate Ops / End User feedback Graham Hayes  
11/8 1:50-2:30
Baremetal Scheduling  Julia Kreger  
11/8 1:50-2:30
Bare metal as a service: Ironic vs. Mogan vs. NovaZhenguo Niu   
11/8 11:00-11:40
First Contact SIG Formation DiscussionZhipeng   
11/8 11:00-11:40
"NFV meets cloud   virtio   
 sr-iov
User Committee - Planning activities for next cycle   Edgar Magana  
11/8 11:50-12:30
Features missing in OpenStack core for Public Cloud provider  Tobias Rydberg
11/8 11:50-12:30
Watcher users feedbackHidekazu Nakamura 
11/8 11:50-12:30
Neutron pain points   Miguel Lavalle
11/8 2:40-3:20
Heat ops and users feedback   Rico Lin  
11/8 2:40-3:20
Nova: Queens roadmap and checkpoint   Matt Riedemann
11/8 2:40-3:20
Neutron Quality-Of-Service Discussion Reedip
11/8 3:30-4:10
"Refstack: OpenStack to OPNFV Vertical Integrated   
 Interop"
Upstream LTS Releases Erik McCormick
11/8 9:00-9:40
Roadmap: User Feedback Gathering  Anne Bertucio 
11/8 9:00-9:40
Hardware in the cloud Stephen Finucane  
11/8 9:00-9:40
ETSI NFV Specs’ Requirements vs OpenStack Reality forum   Gergely Csatari   
11/8 9:50-10:30
OpenStack Public Cloud Passport Program   Tobias Rydberg
11/8 9:50-10:30
Multi-cloud management projectMatt McEuen   
11/8 9:50-10:30

-- 
Mike Perez


SYD-OpenStack-Forum.pdf
Description: Adobe PDF document


signature.asc
Description: PGP signature
__
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] Sydney Forum Topic Submission

[Mike Perez]

On 16:15 Sep 21, Shamail Tahir wrote:
> Hi,
> 
> We have made it to the next stage of the topic selection process for the
> Forum in Sydney!
> 
> At the Forum the entire OpenStack community (users and developers) gathers
> to brainstorm the requirements for the next release, gather feedback on the
> past version and have strategic discussions that go beyond just one release
> cycle. The Sydney Forum is the start of the Rocky release cycle. Please
> prepare session ideas with feedback from the Pike release in mind.
> 
> Our submission tool is now open for you to submit abstracts for the most
> popular sessions that came out of your brainstorming.
> 
> Ask all session leaders to submit their abstracts at:
> http://forumtopics.openstack.org/
> 
> before *11:59PM UTC on Friday September 29th*!
> 
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
> 
> We assume that anything submitted to the Forum Topics Tool has achieved a
> good amount of discussion and consensus that it's a worthwhile topic. After
> submissions close, a team of representatives from the User Committee, the
> Technical Committee, and Foundation staff will take the sessions proposed
> by the community and fill out the schedule.
> 
> You can expect the draft schedule to be released on October 9th, 2017.
> 
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum

Hi all!

We're a bit delayed in having that draft available for you all. The committee
has voted on the submitted forum topics and is currently waiting to hold
a discussion on Wednesday October 11th to finalize the selection.

You can now expect a draft available October 12th. Thank you.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Ideas for Graduate Student

[Mike Perez]

On 15:27 Oct 05, Mike Perez wrote:
> On 02:59 Oct 05, Puneet Jain wrote:
> > Hello all,
> > 
> > I am a graduate student and have intermediate knowledge and huge in cloud
> > computing. I am looking for a project idea, particularly any new feature I
> > can implement in OpenStack.
> > 
> > I thought of implementing multi-factor authentication but happened to know
> > that it has already been implemented.
> > https://docs.openstack.org/security-guide/identity/authentication.html
> > 
> > I would prefer to do something in security. Any ideas?
> > 
> > Looking forward to hearing from you guys. Thanks in advance!
> 
> Welcome to the community Puneet! We have various Security group related
> projects listed here:
> 
> https://wiki.openstack.org/wiki/Security
> 
> You can also find various Security/Identity/Compliance OpenStack project
> services listed in our project navigator:
> 
> https://www.openstack.org/software/project-navigator/
> 
> Also on freenode irc we have #openstack-security. You can see more channels:
> 
> https://wiki.openstack.org/wiki/IRC
> 
> Here are some helpful documents in setting up IRC, git, and the various
> accounts you'll be using in our community:
> 
> https://docs.openstack.org/upstream-training/irc.html
> https://docs.openstack.org/upstream-training/git.html
> https://docs.openstack.org/upstream-training/accounts.html
> 
> -- 
> Mike Perez

Actually this account setup documentation is more up-to-date and better:

https://docs.openstack.org/infra/manual/developers.html#account-setup

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Ideas for Graduate Student

[Mike Perez]

On 02:59 Oct 05, Puneet Jain wrote:
> Hello all,
> 
> I am a graduate student and have intermediate knowledge and huge in cloud
> computing. I am looking for a project idea, particularly any new feature I
> can implement in OpenStack.
> 
> I thought of implementing multi-factor authentication but happened to know
> that it has already been implemented.
> https://docs.openstack.org/security-guide/identity/authentication.html
> 
> I would prefer to do something in security. Any ideas?
> 
> Looking forward to hearing from you guys. Thanks in advance!

Welcome to the community Puneet! We have various Security group related
projects listed here:

https://wiki.openstack.org/wiki/Security

You can also find various Security/Identity/Compliance OpenStack project
services listed in our project navigator:

https://www.openstack.org/software/project-navigator/

Also on freenode irc we have #openstack-security. You can see more channels:

https://wiki.openstack.org/wiki/IRC

Here are some helpful documents in setting up IRC, git, and the various
accounts you'll be using in our community:

https://docs.openstack.org/upstream-training/irc.html
https://docs.openstack.org/upstream-training/git.html
https://docs.openstack.org/upstream-training/accounts.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] policy community goal progress

[Mike Perez]

On 09:37 Oct 03, Lance Bragstad wrote:
> Hey all,
> 
> According to our burndown chart [0], just over half the projects have
> started implementing the goal [1]. I've been proposing patches for some
> of the projects in the not-started column. Most patches I've been
> working on would benefit from a review from someone more experienced
> with the project. Some projects have policies aren't documented in their
> respective API reference, so providing useful descriptions is going to
> have to come from project developers. Other patches are tripping over
> fake policies that are inconsistent with the packaged policy file. Those
> could require additional testing logic to ensure the tests are actually
> testing the defaults and not just empty policies ("").
> 
> As always, if you have questions about how to get started, please feel
> free to come find me. If I've proposed an implementation for a your
> project [2], don't hesitate to pick it up and run with it. This will
> free me up to continue helping other projects that have yet to get started.
> 
> Thanks!
> 
> Lance
> 
> [0] https://www.lbragstad.com/policy-burndown/
> [1] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> [2]
> https://review.openstack.org/#/q/topic:policy-and-docs-in-code+status:open

Happy to see openstack-dev/sandbox has come onboard with this effort. I will
definitely start pitching in on the Cinder reviews and promoting in whatever
ways I can with the Dev Digest and resources I have.

Lance, thank you for setting a great example of someone championing
a community-wide goal. 

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Simplification in OpenStack

[Mike Perez]

On 10:45 Sep 12, Mike Perez wrote:
> Hey all,
> 
> Back in a joint meeting with the TC, UC, Foundation and The Board it was
> decided as an area of OpenStack to focus was Simplifying OpenStack. This
> intentionally was very broad so the community can kick start the conversation
> and help tackle some broad feedback we get.
> 
> Unfortunately yesterday there was a low turn out in the Simplification room.
> A group of people from the Swift team, Kevin Fox and Swimingly were nice
> enough to start the conversation and give some feedback. You can see our
> initial ether pad work here:
> 
> https://etherpad.openstack.org/p/simplifying-os
> 
> There are efforts happening everyday helping with this goal, and our team has
> made some documented improvements that can be found in our report to the
> board within the ether pad. I would like to take a step back with this
> opportunity to have in person discussions for us to identify what are the
> area of simplifying that are worthwhile. I’m taking a break from the room at
> the moment for lunch, but I encourage people at 13:30 local time to meet at
> the simplification room level b in the big thompson room. Thank you!

Sorry for the late reply all. Decompression from burning man and ptg :).

Thanks for the discussions everyone has brought to this thread. I think we did
a good job brainstorming and identifying what we have more information on.

I would like to move this discussion to a different thread that focuses on
those more identified areas, with relation to the recent user survey:

http://lists.openstack.org/pipermail/openstack-dev/2017-October/123086.html

Lets keep this momentum going!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [simplification] PTG Recap

[Mike Perez]

th all of these releases. Only do a release once every two 
years

[1] - https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677
[3] - 
https://www.openstack.org/blog/2017/05/openstack-developer-mailing-list-digest-20170526/
 

## Operations
### Etherpad Summary

 Confusion with OpenStack Client and Project Clients
* OpenStack client doesn’t entirely support micro versions on some nova
  functionality.
* Functions that work in OpenStack Client, but not in the project clients
  themselves (e.g., Kerberos)
* Given that OpenStack Client is now available and widely used, I still see new
  projects being created with their project clients which is strange.

 OpenStack Client Needs to Be Better
* The documentation needs to be better, possibly its interface.
* A couple of examples from the current documentation [1]. 
  * get_rdp_console doesn't even tell me what it returns (many calls there have
this issue).
  * The first object on the page, novaclient.v2.servers.NetworkInterface,
refers to a 'manager' - what's a manager? (The answer is probably that this
isn't user callable, but I'd be fine with it saying that.)
  * If people are expected to use these in the right way, let alone use the
right versions, we need to offer them more help than this.
 
 More Documentation
* Scaling the infrastructure. How to do this? When? How to detect?
* Recommendations?
* Ensure high availability. Recommendations?
* Networking: production vs. testing
* Integration with LDAP. Scarcely documented.
* Quotas

[1] - 
https://docs.openstack.org/python-novaclient/pike/reference/api/v2/servers.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][zuul] A Sad Farewell

[Mike Perez]

On 11:17 Oct 03, Dean Troyer wrote:
> On Mon, Oct 2, 2017 at 9:13 PM, Jamie Lennox <jamielen...@gmail.com> wrote:
> > I'm really sad to announce that I'll be leaving the OpenStack community (at
> > least for a while), I've accepted a new position unrelated to OpenStack
> > that'll begin in a few weeks, and am going to be mostly on holiday until
> > then.
> 
> No, this just will not do. -2
> 
> Seriously, it has been a great pleasure to 'try to take over the
> world' with you, at least that is what I recall as the goal we set in
> Hong Kong.  The entire interaction of Python-based clients with
> OpenStack has been made so much better with your contributions and
> OpenStackClient would not have gotten as far as it has without them.
> Thank You.
> 
> dt
> 
> /me looking for one more post-Summit beer-debrief in the hotel lobby
> next month...

Yes add me for some bourbon. Thank you Jamie for helping me with various things
in the keystone api's. It has been a pleasure working with you.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Zuul v3 Status - and Rollback Information

[Mike Perez]

On 19:38 Oct 03, Jean-Philippe Evrard wrote:
> On Tue, Oct 3, 2017 at 5:40 PM, Monty Taylor <mord...@inaugust.com> wrote:
> > Hey everybody!


 
> Hello,
> 
> I'd like to first thank everyone involved, doing this hard work.

Yes thank you all very much for your hardwork. I think we can all agree
"computers happen."

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [storyboard] Should New Projects Be Using Storyboard?

[Mike Perez]

I noticed that the project creator [1] and cookiecutter [2] promote using
launchpad. If we're migrating projects to storyboard today, should we stop
promoting launchpad for new projects?

[1] - https://docs.openstack.org/infra/manual/creators.html
[2] - 
https://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/cookiecutter.json#n6

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Developer Mailing List Digest September 23-29

[Mike Perez]

 the marketing community and projects 
work together to make the release communications happen.
* Having multiple, repetitive demands to summarize" top features" during 
release time can be a pester, and having to re-collect the information each 
time isn't an effective use of time.
* Being asked to make a polished, "Press–Friendly" message out of release 
can feel too far outside of the PTL’s Focus areas or skills.
* Technical content marketers, attempting to find the key features from 
release notes, mailing lists, specifications, roadmaps, whatever means 
interesting features are sometimes overlooked.
* To address this gap, the release team and foundation marketing team proposed 
collecting information as part of the release tagging process.
* We will collect from deliverable files to provide highlights for the 
series (about three items).
* The text will be used to build a landing page on release.openstack.org 
that shows the"Key features" flagged by PTL’s that the marketing teams should 
be looking at during release communication times.
* This page will link to the [release 
notes](https://release.openstack.org) so marketers can gather additional 
information.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122678.html)


## Simplification in OpenStack
* Two camps appear: people that want to see OpenStack as a product with a way 
of doing deployments and the people who want to focus on configuration 
management tools.
* One person gives an example of using both Ubuntu MAAS and Puppet. The 
puppet solution allowed for using existing deployment methodologies unlike the 
former.
* We should start promoting and using a single solution for the bulk of the 
community efforts. Right now we do that with Devstack as a reference 
implementation that nobody should use for anything but dev/test.
* This sort of idea could make other deployment efforts relevant.
* Kolla came up at the PTG: scenario-based testing and documentation based on 
different  “constellations" or use cases.
* Puppet has been doing 
[this](https://github.com/openstack/puppet-openstack-integration) and Triple-o 
has been doing 
[this](https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html).
* If you break down actual use cases, most people want nova (qemu+KVM), 
neutron (vxlan, potentially VLAN), Cinder (ceph).
* If we agreed to cover 90% of users, that'll boil down to 4 to 5 
different “constellations.”
* Someone has been working on a local testing environment, and it boils 
down to [this](https://github.com/test-kitchen/test-kitchen/issues/873).
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122075)


-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [release][ptl] Improving the process for release marketing

[Mike Perez]

On 14:33 Sep 26, Anne Bertucio wrote:
> Release marketing is a critical part of sharing what’s new in each release,
> and we want to rework how the marketing community and projects work together
> to make the release communications happen. 
> 
> Having multiple, repetetive demands to summarize "top features" during
> release time can be pestering and having to recollect the information each
> time isn't an effective use of time. Being asked to make polished,
> "press-friendly" messages out of release notes can feel too far outside of
> the PTL's focus areas or skills. At the same time, for technical content
> marketers, attempting to find the key features from release notes, ML posts,
> specs, Roadmap, etc., means interesting features are sometimes overlooked.
> Marketing teams don't have the latest on what features landed and with what
> caveats.
> 
> To address this gap, the Release team and Foundation marketing team propose
> collecting information as part of the release tagging process. Similar to the
> existing (unused) "highlights" field for an individual tag, we will collect
> some text in the deliverable file to provide highlights for the series (about
> 3 items). That text will then be used to build a landing page on
> release.openstack.org that shows the "key features" flagged by PTLs that
> marketing teams should be looking at during release communication times. The
> page will link to the release notes, so marketers can start there to gather
> additional information, eliminating repetitive asks of PTLs. The "pre
> selection" of features means marketers can spend more time diving into
> release note details and less sifting through them.
> 
> To supplement the written information, the marketing community is also going
> to work together to consolidate follow up questions and deliver them in
> "press corps" style (i.e. a single phone call to be asked questions from
> multiple parties vs. multiple phone calls from individuals).
> 
> We will provide more details about the implementation for the highlights page
> when that is ready, but want to gather feedback about both aspects of the
> plan early.

As being someone who participates in building out that page, I  welcome this to
represent highlights from the community itself better.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Developer Mailing List Digest September 16-22

[Mike Perez]

know where the community needs the most identified help.
* This is a social issue, not a technical issue. Arguing about what is useful 
and what isn’t is probably not worth the effort here.
* Communication and education is probably the best solution here. For repeated 
offenders, off-list email could be fine to make sure the communication is 
clear. Communicating this in the new [contributor 
portal](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html)
 and Upstream Institute would be helpful.
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472)

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Garbage patches for simple typo fixes

[Mike Perez]

On 08:50 Sep 22, Doug Hellmann wrote:
> Excerpts from Tom Barron's message of 2017-09-22 08:10:35 -0400:
> > 
> > On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > > I just wanted to highlight to people that there seems to be a series of
> > > garbage patches in various projects [1] which are basically doing things
> > > like fixing a single typo in a code comment, or very narrowly changing
> > > http to https in links within docs.
> > > 
> > > Also +1ing ones own changes.
> > > 
> > > I've been trying to snuff these out in nova, but I see it's basically a
> > > pattern widespread across several projects.
> > > 
> > > This is the boilerplate comment I give with my -1, feel free to employ
> > > it yourself.
> > > 
> > > "Sorry but this isn't really a useful change. Fixing typos in code
> > > comments when the context is still clear doesn't really help us, and
> > > mostly seems like looking for padding stats on stackalytics. It's also a
> > > drain on our CI environment.
> > > 
> > > If you fixed all of the typos in a single module, or in user-facing
> > > documentation, or error messages, or something in the logs, or something
> > > that actually doesn't make sense in code comments, then maybe, but this
> > > isn't one of those things."
> > > 
> > > I'm not trying to be a jerk here, but this is annoying to the point I
> > > felt the need to say something publicly.
> > > 
> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > > 
> > 
> > The boilerplate is helpful but have we considered putting something
> > along these lines in official documentation so that reviewers can just
> > point to it? It should then be clear to all that negative reviews on
> > these grounds are not simply a function of the individual reviewer's
> > judgment or personality.
> 
> That's a good idea. How about adding a "Contribution Guidelines" section
> to https://docs.openstack.org/project-team-guide/open-development.html
> with this and other tips?

We can make sure this is linked somehow with the contributor portal when
applicable.

http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Garbage patches for simple typo fixes

[Mike Perez]

On 15:04 Sep 22, Jeremy Stanley wrote:
> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
> > On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudb...@gmail.com> wrote:
> > > 3) Delay spin-up of resource-intensive/long-running CI jobs
> > > until after some initial review has been added or time has
> > > passed. Authorized contributors, not necessarily synonymous with
> > > cores, can override the delay if there's a critical patch which
> > > needs to get through the queue quickly.
> >
> > +1. This is done in Go code review process, where CI is run by an
> > explicit Run-TryBot+1 review only after a core developer
> > ascertains that the patch looks okay and most code review comments
> > are addressed. This means no CI resource usage for every change
> > and every single patchset. We could adopt a similar approach so
> > that CI resources aren’t wasted for useless patches. This doesn’t
> > take a whole lot of work for the reviewers than the current review
> > process.
> > 
> > https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
> 
> I'm wary of potential overengineering like this, particularly
> without at least some analysis showing the percentage of CI
> resources we'll save by asking our already overworked (on most teams
> anyway) core reviewers to also take on the task of authorizing basic
> CI jobs. The more likely outcome I foresee is that, much like
> contributions going unreviewed sometimes for weeks or months, the
> change authors won't even know whether their changes are suitable
> for review for some similar period of delay.
> 
> The CI system is there to serve reviewers and contributors, not the
> other way around. The CI resource shortages we see from time to time
> should not be used as an excuse to go on witch hunts so we can find
> ways to save what probably accounts for <1% of our overall
> utilization. That's classic premature optimization. What's important
> in this situation is the time wasted by reviewers having to respond
> to or find ways to ignore these patches, so let's focus on that
> rather than getting bogged down with attractive non-problems for
> which we can more easily engineer technical solutions.

+1

Can you imagine the number of jobs that would be delayed. At least today with
things not be delayed we can see if a patch ever worked when it was rebased in
the CI comments.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][ptls][install] Install guide vs. tutorial

[Mike Perez]

On 11:33 Sep 21, Alexandra Settle wrote:
> > For me, a tutorial is something that teaches. So after I've gone through a
> > tutorial I would expect to have learned how installs work and would
> > just know
> > these things (with an occasional need to reference a few points) going
> > forward.
> >
> > A guide to me is something that I know I will use whenever I need to do
> > something. So for me, having an installation guide is what I would
> > expect
> > from this as every time I need to do a package based install, I am
> > going to pull
> > up the guide to go through it.
> >
>Interesting.
> 
> So Sean has the opposite impression from Eric and I.  Yeah, that does 
> make it seem like reaching a consensus will be difficult.
> 
> At that point I think consistency becomes the most important thing.
> 
> 
> I completely agree consistency is more important, than bike shedding over the
> name :)
> To be honest, it would be easier to change everything to ‘guide’ – seeing as
> all our URLs are ‘install-guide’.
> But that’s the lazy in me speaking.
> 
> Industry wise – there does seem to be more of a trend towards ‘guide’ rather
> than ‘tutorial’. Although, that is at a cursory glance.
> 
> I am happy to investigate further, if this matter is of some contention to
> people?

This is the first time I'm hearing about "Install Tutorial". I'm also lazy, +1
with sticking to install guide.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Garbage patches for simple typo fixes

[Mike Perez]

On 21:21 Sep 21, Matt Riedemann wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
> 
> Also +1ing ones own changes.
> 
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
> 
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
> 
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
> 
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
> 
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
> 
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*

I agree with the frustration here. It was mentioned earlier in the thread the
top 5 wanted [1] is a good step in the right direction. I think also the
efforts on the contributor portal [2] are going to be a helpful link to send
people when they make mistakes.

I'm sure some of the people who haven't had this communicated to them yet
aren't aware, so we should all be aware as demonstrated in Matt's boilerplate
comment to be nice when communicating.

[1] - http://governance.openstack.org/tc/reference/top-5-help-wanted.html 
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Contributor Portal PTG Recap

[Mike Perez]

# Contributor Portal Next Steps

## Landing Page Mock ups
* Current mock up:
https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
* Limited click through mock up:
https://invis.io/CSDEZTBDJ#/252645774_Landing

## Todo
- [ ] thingee: A proposal for the *second level* of what the landing page
shows.
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.

## Communication To The Community
* [Initial
email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
* [Initial full
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)

## Highlights from PTG session
[OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)

### TLDR (big changes from discussion)
* Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
* This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?

### General
* We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
[service type authority
repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
There might be a field in projects.yaml that can help with this.
* Remind Thierry on the service type authority repo for
grouping/mapping project.
* Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast. 
* Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass [ethercalc
sheet](https://ethercalc.openstack.org/github-gerrit).
* Translation team needs to be included
* Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
* Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.

### Upstream Institute
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
[1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
[2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
[3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the [top 5 most wanted
help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!

### User Committee
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
https://etherpad.openstack.org/p/contributor-portal-user-section

### Mock Up Feedback
* Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
project does.
* Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)

### Bikeshed
* A word that combines code and documentation ("team(s)" was already
rejected)

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][nova][mogan] How to show respect to the original authors?

[Mike Perez]

On 15:56 Sep 20, Flavio Percoco wrote:
> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> > [...]
> > > please indicate which file from Nova, so if anyone wanted to cross
> > > check for fixes etc can go look in Nova
> > [...]
> > 
> > While the opportunity has probably passed in this case, the ideal
> > method is to start with a Git fork of the original as your seed
> > project (perhaps with history pruned to just the files you're
> > reusing via git filter-branch or similar). This way the complete
> > change history of the files in question is preserved for future
> > inspection.
> 
> If it's not too late, I would definitely recommend going with a fork, fwiw.
> 
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

+1 please fork instead.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Simplification in OpenStack

[Mike Perez]

On 15:53 Sep 12, Boris Pavlovic wrote:
> Mike,
> 
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described
> in the etherpad mostly..



Definitely agree that it's not going to be a few issues to fix. I purposely was
leading this effort being broad so we can take the comments of OpenStack being
complex, and have a conversation on what that actually means to people. 

The feedback from people on the etherpad, as well as the in person discussions
have been valuable in getting those different perspectives. Unfortunately
participation was low, but I'm interested in seeing if we can identify some
themes to have some actual doable objectives.

I appreciate you taking the time in writing up your feedback on this Boris.
I will make sure it's included in the more polished summary I'll be giving the
TC and the Board to act on. Thank you!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Simplification in OpenStack

[Mike Perez]

Hey all,

I would like to encourage people from different teams to add items of
things they learned at the PTG about simplifying their own projects.
Maybe we can see some themes that can contribute to community wide
goals?

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez

On September 12, 2017 at 15:33:14, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> The session is over. I’m hanging near registration if anyone wants to discuss 
> things.
> Shout out to John for coming by on discussions with simplifying dependencies. 
> I welcome
> more packagers to join the discussion.
>
> https://etherpad.openstack.org/p/simplifying-os
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> > Hey all,
> >
> > Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> > decided as an area
> > of OpenStack to focus was Simplifying OpenStack. This intentionally was 
> > very broad
> > so the community can kick start the conversation and help tackle some broad 
> > feedback
> > we get.
> >
> > Unfortunately yesterday there was a low turn out in the Simplification 
> > room. A group
> > of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> > start the conversation
> > and give some feedback. You can see our initial ether pad work here:
> >
> > https://etherpad.openstack.org/p/simplifying-os
> >
> > There are efforts happening everyday helping with this goal, and our team 
> > has made some
> > documented improvements that can be found in our report to the board within 
> > the ether
> > pad. I would like to take a step back with this opportunity to have in 
> > person discussions
> > for us to identify what are the area of simplifying that are worthwhile. 
> > I’m taking a
> break
> > from the room at the moment for lunch, but I encourage people at 13:30 
> > local time to meet
> > at the simplification room level b in the big thompson room. Thank you!
> >
> > —
> > Mike Perez
>

__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

We now have an ether pad

https://etherpad.openstack.org/p/contributor-portal

—
Mike Perez

On September 13, 2017 at 11:47:16, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> We’ll be meeting with the Documentation team at the ptg in ballroom c today 
> at 14:30 local
> time to discuss progress. Join us and lets help make our on-boarding 
> experience better
> for new contributors!
>
> —
> Mike Perez
>
> On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
> >
> >
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress bar somewhere to show how close you are 
> > to being ready
> > to contribute to whatever team. Of course there are a lot of other fancy 
> > things we can
> come
> > up with, but I think getting something up as an initial pass would be 
> > better than what
> we
> > have today.
> >
> > Here's an example of what the sections/chapters could look like:
> >
> > - Code
> > * Volumes (Cinder)
> > * IRC
> > * Git
> > * Account Setup
> > * Generating Configs
> > * Compute (Nova)
> > * IRC
> > * Git
> > * Account Setup
> > * Something about hypervisors (matrix?)
> > - Use Cases
> > * Products (Product working group)
> > * IRC
> > * Git
> > * Use Case format
> >
> > There are some rough mock up ideas [4]. Probably Sphinx will be fin

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hey all,

We’ll be meeting with the Documentation team at the ptg in ballroom c
today at 14:30 local time to discuss progress. Join us and lets help
make our on-boarding experience better for new contributors!

—
Mike Perez

On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
>
>
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Configs
> * Compute (Nova)
> * IRC
> * Git
> * Account Setup
> * Something about hypervisors (matrix?)
> - Use Cases
> * Products (Product working group)
> * IRC
> * Git
> * Use Case format
>
> There are some rough mock up ideas [4]. Probably Sphinx will be fine for 
> this. Potentially
> we could use this content for conference lunch and learns, upstream 
> university, and
> the on-boarding events at the Forum. What do you all think?
>
> [1] - http://docs.openstack.org/upstream-training/irc.html
> [2] - http://docs.openstack.org/upstream-training/git.html
> [3] - http://docs.openstack.org/upstream-training/accounts.html
> [4] - 
> https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0
>
> —
>
> Mike Perez

__
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] Simplification in OpenStack

[Mike Perez]

Hey all,

The session is over. I’m hanging near registration if anyone wants to
discuss things. Shout out to John for coming by on discussions with
simplifying dependencies. I welcome more packagers to join the
discussion.

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez


On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> decided as an area
> of OpenStack to focus was Simplifying OpenStack. This intentionally was very 
> broad
> so the community can kick start the conversation and help tackle some broad 
> feedback
> we get.
>
> Unfortunately yesterday there was a low turn out in the Simplification room. 
> A group
> of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> start the conversation
> and give some feedback. You can see our initial ether pad work here:
>
> https://etherpad.openstack.org/p/simplifying-os
>
> There are efforts happening everyday helping with this goal, and our team has 
> made some
> documented improvements that can be found in our report to the board within 
> the ether
> pad. I would like to take a step back with this opportunity to have in person 
> discussions
> for us to identify what are the area of simplifying that are worthwhile. I’m 
> taking a break
> from the room at the moment for lunch, but I encourage people at 13:30 local 
> time to meet
> at the simplification room level b in the big thompson room. Thank you!
>
> —
> Mike Perez

__
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] Simplification in OpenStack

[Mike Perez]

Hey all,

Back in a joint meeting with the TC, UC, Foundation and The Board it
was decided as an area of OpenStack to focus was Simplifying
OpenStack. This intentionally was very broad so the community can kick
start the conversation and help tackle some broad feedback we get.

Unfortunately yesterday there was a low turn out in the Simplification
room. A group of people from the Swift team, Kevin Fox and Swimingly
were nice enough to start the conversation and give some feedback. You
can see our initial ether pad work here:

https://etherpad.openstack.org/p/simplifying-os

There are efforts happening everyday helping with this goal, and our
team has made some documented improvements that can be found in our
report to the board within the ether pad. I would like to take a step
back with this opportunity to have in person discussions for us to
identify what are the area of simplifying that are worthwhile. I’m
taking a break from the room at the moment for lunch, but I encourage
people at 13:30 local time to meet at the simplification room level b
in the big thompson room. Thank you!

—
Mike Perez

__
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 Developer Mailing List Digest July 22-28

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/08/openstack-developer-mailing-list-digest-20170728/

Summaries
=
* Nova placement/resource providers update 30 [1]
* TC Report 30 [2]
* POST /api-wg/news [3]
* Release countdown for week R-4, July 28 - Aug 4 [4]
* Technical Committee Status update, July 28 [5]

Project Team Gathering Planning
===
* Nova [6]
* Keystone [7]
* Sahara [8]
* Cinder [9]
* Oslo [10]
* Neutron [11]
* Documentation [12]

Oslo DB Network Database Base namespace throughout OpenStack Projects
=
* Mike Bayer has been working with Octave Oregon on adding the network database
  storage engine for mysql to oslo.db module so other projects can take
  advantage of it. Mike Bayer notes:
  - The code review [13]
  - Support in Nova [14]
  - Support in Neutron [15]
* New data types that map to types from the NDB namespace.
  - oslo_db.sqlalchemy.types.SmallString
  - oslo_db.sqlalchemy.types.String
* Full thread: [16]

1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120290.html
2. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120112.html
3. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120245.html
4. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120304.html
5. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120280.html
6. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120020.html
7. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119299.html
8. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119352.html
9. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119358.html
10. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119462.html
11. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120270.html
12. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119990.html
13. https://review.openstack.org/#/c/427970/
14. https://review.openstack.org/#/c/446643
15. https://review.openstack.org/#/c/446136/
16. 
http://lists.openstack.org/pipermail/openstack-dev/2017-July/thread.html#120037


signature.asc
Description: PGP signature
__
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] [Cinder] Proposing TommyLikeHu for Cinder core

[Mike Perez]

On 03:07 Jul 25, Sean McGinnis wrote:
> I am proposing we add TommyLike as a Cinder core.
> 
> DISCLAIMER: We work for the same company.
> 
> I have held back on proposing him for some time because of this conflict. But
> I think from his number of reviews [1] and code contributions [2] it's
> hopefully clear that my motivation does not have anything to do with this.
> 
> TommyLike has consistently done quality code reviews. He has contributed a
> lot of bug fixes and features. And he has been available in the IRC channel
> answering questions and helping out, despite some serious timezone
> challenges.
> 
> I think it would be great to add someone from this region so we can get more
> perspective from the APAC area, as well as having someone around that may
> help as more developers get involved in non-US and non-EU timezones.
> 
> Cinder cores, please respond with your opinion. If no reason is given to do
> otherwise, I will add TommyLike to the core group in one week.
> 
> And absolutely call me out if you see any in bias in my proposal.

+1

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][all] Improving Vendor Driver Discoverability

[Mike Perez]

On 20:29 Jan 13, Mike Perez wrote:
> Hello all,
> 
> In the spirit of recent Technical Committee discussions I would like to bring
> focus on how we're doing vendor driver discoverability. Today we're doing this
> with the OpenStack Foundation marketplace [1] which is powered by the 
> driverlog
> project. In a nutshell, it is a big JSON file [2] that has information on 
> which
> vendor solutions are supported by which projects in which releases. This
> information is then parsed to generate the marketplace so that users can
> discover them. As discussed in previous TC meetings [3] we need to recognize
> vendors that are trying to make great products work in OpenStack so that they
> can be successful, which allows our community to be successful and healthy.
> 
> In the feedback I have received from various people in the community, some
> didn’t know how it worked, and were unhappy that the projects themselves
> weren’t owning this. I totally agree that project teams should own this and
> should be encouraged to be involved in the reviews. Today that’s not 
> happening.
> I’d like to propose we come up with a way for the marketplace to be more
> community-driven by the projects that are validating these solutions.
> 
> At the Barcelona Summit [4] we discussed ways to improve driverlog. Projects
> like Nova have a support matrix of hypervisors in their in-tree documentation.
> Various members of the Cinder project also expressed interest in using this
> solution. It was suggested in the session that the marketplace should just 
> link
> to the projects' appropriate documentation. The problem with this solution is
> the information is not presented in a consistent way across projects, as
> driverlog does it today. We could accomplish this instead by using a parsable
> format that is stored in each appropriate project's git repository. I'm
> thinking of pretty much how driverlog works today, but broken up into
> individual projects.
> 
> The marketplace can parse this information and present it in one place
> consistently. Projects may also continue to parse this information in their 
> own
> documentation, and we can even write a common tool to do this. The way a 
> vendor
> is listed here is based on being validated by the project team itself. Keeping
> things in the marketplace would also address the suggestions that came out of
> the recent feedback we received from various driver maintainers [4].
> 
> The way validation works is completely up to the project team. In my research
> as shown in the Summit etherpad [5] there's a clear trend in projects doing
> continuous integration for validation. If we wanted to we could also have the
> marketplace give the current CI results, which was also requested in the
> feedback from driver maintainers.
> 
> I would like to volunteer in creating the initial files for each project with
> what the marketplace says today.
> 
> [1] - https://www.openstack.org/marketplace/drivers/
> [2] - 
> http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
> [3] - 
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-10-20.01.log.html#l-106
> [4] - 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
> [5] - https://etherpad.openstack.org/p/driverlog-validation

Hey all,

Continuing things, posted for review is the initial project [1][2], add it to
test-requirements [3] and changes for Nova [4] and Neutron [5].

Review love appreciated!

[1] - https://review.openstack.org/472260
[2] - https://review.openstack.org/472488
[3] - https://review.openstack.org/481294
[4] - https://review.openstack.org/481304
[5] - https://review.openstack.org/481307 

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 22:18 Jun 27, Jeremy Stanley wrote:
> On 2017-06-27 14:34:46 -0700 (-0700), Mike Perez wrote:
> [...]
> > ## PTG
> > 
> > New contributors should be participating in the sessions for a
> > project and get to know who are the people leading those efforts.
> > People leading efforts want help. Whether it be documentation for
> > the thing, implementation, testing, etc. Working with the people
> > involved is a good way to get to know that feature or change. The
> > people leading the effort are now invested in YOU succeeding
> > because if you don't succeed, they don't either. Once you succeed
> > in the feature or change with someone, you have recognition in
> > people knowing you are responsible for it in some way. This is an
> > awesome feeling and will lead you to either improving it more or
> > going onto other things. While you're only understanding of a
> > project is that thing, you may get curious and move onto other
> > parts of the code. This leads to someone in the future leading
> > efforts for new contributors!
> [...]
> 
> If you mean "junior" contributors who have maybe gotten a small
> change merged or fixed a minor bug (but have at least figured out
> what team they probably want to spend a lot of their time helping
> on) then I agree. To me "new" contributors are the ones who still
> need the basics of how to submit a patch, where to find bug reports,
> or whatever and those are being catered to at the Forum (via
> OpenStack 101, Upstream Institute, project onboarding), not the PTG.

Yes I'm talking about both junior and new contributors in the way you're
defining them. If they're new, they can still participate in discussions and
meet the people leading an effort. Processes with launchpad/gerrit etc is all
just tools that can be learned later. Learning these processes should just be
followed up later with the looking at the new contributor portal with the
project they selected to work with and follow instructions and ask for help on
their IRC channel when needed.  

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 00:07 Jun 28, Ildiko Vancsa wrote:


 
> > On 2017. Jun 27., at 23:34, Mike Perez <thin...@gmail.com> wrote:
> > 
> > On 13:52 Jun 23, Michał Jastrzębski wrote:
> >> Great idea!
> >> 
> >> I would also throw another issue new people often have (I had it too).
> >> Namely what to contribute. Lot's of people wants to do something but
> >> not quite know where to start.
> >> So few ideas for start:
> >> * List of triaged bugs
> >> * List of work items of large blueprits
> > 
> > IMO the triaged bugs/low hanging fruit thing seems to be still daunting for 
> > new
> > contributors. There's also not really much gratification or recognition for
> > what you did by the wider community sometimes. This is something I feel that
> > helps in having people come back to contribute.
> 
> From maintenance perspective I would ensure new comers are aware how to find
> those, but don’t give an exact list.
> 
> By having the Project On-boarding sessions, etc. and a bit more focus on
> coaching and mentoring we might be able to get some attention from projects
> regarding maintaining the list of low hanging fruit bugs. Sometimes that tag
> is not really verified and there are also cases when it does not get marked
> as fixed or obsolete. From earlier experience they are not always
> encouraging...
> 
> > This is going on a tangent of something else I have coming in the future but
> > I think there are a few ways a new contributor would come in:
> > 
> > ## PTG
> > 
> > New contributors should be participating in the sessions for a project and
> > get to know who are the people leading those efforts. People leading efforts
> > want help. Whether it be documentation for the thing, implementation, 
> > testing,
> > etc. Working with the people involved is a good way to get to know that 
> > feature
> > or change. The people leading the effort are now invested in YOU succeeding
> > because if you don't succeed, they don't either. Once you succeed in the
> > feature or change with someone, you have recognition in people knowing you 
> > are
> > responsible for it in some way. This is an awesome feeling and will lead 
> > you to
> > either improving it more or going onto other things. While you're only
> > understanding of a project is that thing, you may get curious and move onto
> > other parts of the code. This leads to someone in the future leading efforts
> > for new contributors!
> 
> I think for this we need to encourage people to attend the Summit first and
> come to an On-boarding session if their target project has one. From my
> experience when I attended my first Design Summit I had no clue what’s going
> on and that can be very discouraging and I saw people for whom it was. And in
> my opinion we also cannot expect the project teams to baby sit new people on
> the PTG.
> 
> With that said, I agree we should have new people on this event, but I think
> we need to be more careful with describing and clarifying prerequisites and
> expectations, like basic knowledge of the area and experience or just to do
> their research before they come and they should know this event is not
> focusing on them.
> 
> The portal should be a great place to describe all this and give a list of
> best practices!

I agree. I just know people are going to come regardless of no matter how many
warning signs you throw in front of them. A quick intro into each session that
this going to move fast/has been discussed and not exactly new contributor
friendly but if you are interested in the effort being discussed find . This is just an answer for those people that
miss all those warnings.

> > ## Forum
> > 
> > I would like to see our on-boarding rooms having time to introduce
> > current/future efforts happening in the project. Introduce the people behind
> > those efforts. Give a little time to break out into meet and greet to 
> > remember
> > friendly faces and do as mentioned above.
> 
> +1
> 
> > 
> > ## Internet
> > 
> > People may not be able to attend our events, but want to participate. Using
> > your idea of listing work items of large blueprints is an excellent! It 
> > would
> > be good if we could list those cleanly and who is leading it. Maybe 
> > Storyboard
> > will be able to help with this in the future Kendall?
> 
> Do we/can we have a tag for large blueprints? So we could teach people how to
> find this and give them a search link, etc.?

Either storyboard allows us to filter on the stuff the project teams have set
for a release, or we just use its API and build our own clean listing.


-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 13:52 Jun 23, Michał Jastrzębski wrote:
> Great idea!
> 
> I would also throw another issue new people often have (I had it too).
> Namely what to contribute. Lot's of people wants to do something but
> not quite know where to start.
> So few ideas for start:
> * List of triaged bugs
> * List of work items of large blueprits

IMO the triaged bugs/low hanging fruit thing seems to be still daunting for new
contributors. There's also not really much gratification or recognition for
what you did by the wider community sometimes. This is something I feel that
helps in having people come back to contribute.

This is going on a tangent of something else I have coming in the future but
I think there are a few ways a new contributor would come in:

## PTG

New contributors should be participating in the sessions for a project and
get to know who are the people leading those efforts. People leading efforts
want help. Whether it be documentation for the thing, implementation, testing,
etc. Working with the people involved is a good way to get to know that feature
or change. The people leading the effort are now invested in YOU succeeding
because if you don't succeed, they don't either. Once you succeed in the
feature or change with someone, you have recognition in people knowing you are
responsible for it in some way. This is an awesome feeling and will lead you to
either improving it more or going onto other things. While you're only
understanding of a project is that thing, you may get curious and move onto
other parts of the code. This leads to someone in the future leading efforts
for new contributors!

## Forum

I would like to see our on-boarding rooms having time to introduce
current/future efforts happening in the project. Introduce the people behind
those efforts. Give a little time to break out into meet and greet to remember
friendly faces and do as mentioned above.

## Internet

People may not be able to attend our events, but want to participate. Using
your idea of listing work items of large blueprints is an excellent! It would
be good if we could list those cleanly and who is leading it. Maybe Storyboard
will be able to help with this in the future Kendall?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 09:45 Jun 26, Alexandra Settle wrote:
> I think this is a good idea :) thanks Mike. We get a lot of people coming to
> the docs chan or ML asking for help/where to start and sometimes it’s
> difficult to point them in the right direction.
> 
> Just from experience working with contributor documentation, I’d avoid all
> screen shots if you can – updating them whenever the process changes
> (surprisingly often) is a lot of unnecessary technical debt.

I understand and agree. This was a big selling point to contributors I've spoke
to about this though in avoid walls of text so it's actually something seeming
doable. Perhaps having a small number of steps to a page can still give the
reader a feeling they can finish it in five minutes or less?

> The docs team put a significant amount of effort in a few releases back
> writing a pretty comprehensive Contributor Guide. For the purposes you
> describe below, I imagine a lot of the content here could be adapted. The
> process of setting up for code and docs is exactly the same:
> http://docs.openstack.org/contributor-guide/index.html

Yes I've seen this content and do plan to adapt stuff over!

> 
> I also wonder if we could include a ‘what is openstack’ 101 for new
> contributors. I find that there is a *lot* of material out there, but it is
> often very hard to explain to people what each project does, how they all
> interact, why we install from different sources, why do we have official and
> unofficial projects etc. It doesn’t have to be seriously in-depth, but an
> overview that points people who are interested in the right directions. Often
> this will help people decide on what project they’d like to undertake.

Wonderful idea. I cc'd Anne from the Openstack Foundation who is helping with
this effort. We will be discussing soon on incorporating 101 content over.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Every month we have people asking on IRC or the dev mailing list having
interest in working on OpenStack, and sometimes they're given different
answers from people, or worse, no answer at all.

Suggestion: lets work our efforts together to create some common
documentation so that all teams in OpenStack can benefit.

First it’s important to note that we’re not just talking about code
projects here. OpenStack contributions come in many forms such as running
meet ups, identifying use cases (product working group), documentation,
testing, etc. We want to make sure those potential contributors feel
welcomed too!

What is common documentation? Things like setting up Git, the many accounts
you need to setup to contribute (gerrit, launchpad, OpenStack foundation
account). Not all teams will use some common documentation, but the point
is one or more projects will use them. Having the common documentation
worked on by various projects will better help prevent duplicated efforts,
inconsistent documentation, and hopefully just more accurate information.

A team might use special tools to do their work. These can also be
integrated in this idea as well.

Once we have common documentation we can have something like:
1. Choose your own adventure: I want to contribute by code
2. What service type are you interested in? (Database, Block storage,
compute)
3. Here’s step-by-step common documentation to setting up Git, IRC,
Mailing Lists, Accounts, etc.
4. A service type project might choose to also include additional
documentation in that flow for special tools, etc.

Important things to note in this flow:
* How do you want to contribute?
* Here are **clear** names that identify the team. Not code names like
Cloud Kitty, Cinder, etc.
* The documentation should really aim to not be daunting:
* Someone should be able to glance at it and feel like they can finish
things in five minutes. Not be yet another tab left in their browser that
they’ll eventually forget about
* No wall of text!
* Use screen shots
* Avoid covering every issue you could hit along the way.

## Examples of More Simple Documentation
I worked on some documentation for the Upstream University preparation that
has received excellent feedback meet close to these suggestions:
* IRC [1]
* Git [2]
* Account Setup [3]

## 500 Feet Birds Eye view
There will be a Contributor landing page on the openstack.org website.
Existing contributors will find reference links to quickly jump to things.
New contributors will find a banner at the top of the page to direct them
to the choose your own adventure to contributing to OpenStack, with ordered
documentation flow that reuses existing documentation when necessary.
Picture also a progress bar somewhere to show how close you are to being
ready to contribute to whatever team. Of course there are a lot of other
fancy things we can come up with, but I think getting something up as an
initial pass would be better than what we have today.

Here's an example of what the sections/chapters could look like:

- Code
* Volumes (Cinder)
 * IRC
 * Git
 * Account Setup
 * Generating Configs
* Compute (Nova)
 * IRC
 * Git
 * Account Setup
* Something about hypervisors (matrix?)
-  Use Cases
* Products (Product working group)
* IRC
* Git
* Use Case format

There are some rough mock up ideas [4]. Probably Sphinx will be fine for
this. Potentially we could use this content for conference lunch and
learns, upstream university, and the on-boarding events at the Forum. What
do you all think?

[1] - http://docs.openstack.org/upstream-training/irc.html
[2] - http://docs.openstack.org/upstream-training/git.html
[3] - http://docs.openstack.org/upstream-training/accounts.html
[4] -
https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0

—

Mike Perez
__
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] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Mike Perez]

Hey all,

In the community wide goals, we started as a group discussing goals at the
OpenStack Forum. Then we brought those ideas to the mailing list to
continue the discussion and include those that were not able to be at the
forum. The discussions help the TC decide on what goals we will do for the
Queens release. The goals that have the most support so far are:

1) Split Tempest plugins into separate repos/projects [1]
2) Move policy and policy docs into code [2]

In the recent TC meeting [3] it was recognized that goals in Pike haven't
been going as smoothly and not being completed. There will be a follow up
thread to cover gathering feedback in an etherpad later, but for now the TC
has discussed potential actions to improve completing goals in Queens.

An idea that came from the meeting was creating a role of "Champions", who
are the drum beaters to get a goal done by helping projects with tracking
status and sometimes doing code patches. These would be interested
volunteers who have a good understanding of their selected goal and its
implementation to be a trusted person.

What do people think before we bikeshed on the name? Would having a
champion volunteer to each goal to help? Are there ideas that weren't
mentioned in the TC meeting [3]?

[1] -
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] -
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg106392.html
[3] -
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-06-20-20.01.log.html#l-10

—
Mike Perez
__
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] Status update, Jun 16

[Mike Perez]

On 11:17 Jun 16, Thierry Carrez wrote:
 


> == Need for a TC meeting next Tuesday ==
> 
> In order to make progress on the Pike goal selection, I think a
> dedicated IRC meeting will be necessary. We have a set of valid goals
> proposed already: we need to decide how many we should have, and which
> ones. Gerrit is not great to have that ranking discussion, so I think we
> should meet to come up with a set, and propose it on the mailing-list
> for discussion. We could use the regular meeting slot on Tuesday,
> 20:00utc. How does that sound ?

I will be there since I started facilitating this back at the forum.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][tc][glance] Glance needs help, it's getting critical

[Mike Perez]

On 16:01 Jun 12, Flavio Percoco wrote:
> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
> > My opinion is that Glance stagnates and it's really hard to implement new
> > features there. In two years, only one major improvement was developed
> > (Image Import Refactoring), and no one has tested it in production yet. And
> > this is in the heyday of the community, as you said!
> 
> You're skipping 2 important things here:
> 
> The first one is that focusing on the image import refactor (IIR) was a
> community choice. It's fixing a bigger problem that requires more focus. The
> design of the feature took a couple of cycles too, not the implementation. The
> second thing is that the slow pace may also be caused by the lack of
> contributors.

+1 image import refactor work. That's great that the image import refactor work
is done! 

Mikhail,

I'm pretty thorough on reading this list for the dev digest, so even I missed
that news. Which release was that done in? Are people not using it in
production right away because of having to upgrade to a new release?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [ironic][nova] Goodbye^W See you later

[Mike Perez]

On 08:45 Jun 08, Jim Rollenhagen wrote:
> Hey friends,
> 
> I've been mostly missing for the past six weeks while looking for a new
> job, so maybe you've forgotten me already, maybe not. I'm happy to tell you
> I've found one that I think is a great opportunity for me. But, I'm sad to
> tell you that it's totally outside of the OpenStack community.
> 
> The last 3.5 years have been amazing. I'm extremely grateful that I've been
> able to work in this community - I've learned so much and met so many
> awesome people. I'm going to miss the insane(ly awesome) level of
> collaboration, the summits, the PTGs, and even some of the bikeshedding.
> We've built amazing things together, and I'm sure y'all will continue to do
> so without me.
> 
> I'll still be lurking in #openstack-dev and #openstack-ironic for a while,
> if people need me to drop a -2 or dictate old knowledge or whatever, feel
> free to ping me. Or if you just want to chat. :)

Really appreciated your time as PTL, and congrats on the future.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [oslo.db] Stepping down from core

[Mike Perez]

On 17:32 Jun 11, Roman Podoliaka wrote:
> Hi all,
> 
> I recently changed job and hasn't been able to devote as much time to
> oslo.db as it is expected from a core reviewer. I'm no longer working
> on OpenStack, so you won't see me around much.
> 
> Anyway, it's been an amazing experience to work with all of you! Best
> of luck! And see ya at various PyCon's around the world! ;)

Thanks for all your contributions, and congrats with the new job.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [forum] Future of Stackalytics

[Mike Perez]

On June 8, 2017 at 07:20:23, Jeremy Stanley (fu...@yuggoth.org) wrote:
> > On 2017-06-07 16:36:45 
> > -0700(http://airmail.calendar/2017-06-07%2016:36:45%20PDT)
> (-0700), Ken'ichi Ohmichi wrote:
> [...]
> > one of config files is 30KL due to much user information and that
> > makes the maintenance hard now. I am trying to separate user
> part
> > from the existing file but I cannot find the way to make a
> > consensus for such thing.
>
> There is a foundation member directory API now which provides
> affiliation details and history, so if it were my project (it's
> not
> though) I'd switch to querying that and delete all the static
> affiliation mapping out of that config instead. Not only would
> it
> significantly reduce the reviewer load for Stackalytics, but
> it
> would also provide a greater incentive for contributors to keep
> their affiliation data updated in the foundation member directory.

+1. This would really help me when generating the stats for our yearly
reports/keynote/etc stats instead of having to query multiple sources
and figure out which one is more current.

—
Mike Perez

__
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 Developer Mailing List Digest April 29 - May 5

[Mike Perez]

nstack-dev/2017-May/116401.html
[8] - https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[9] - 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18694/infraqarelease-mgmtregsstable-project-onboarding
[10] - 
https://www.openstack.org/videos/video/openstack-stable-what-it-actually-means-to-maintain-stable-branches
[11] - https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
[12] - 
https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing
[13] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116298


-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][ptl][goals] Community goals for Queen

[Mike Perez]

Hello everyone,

May 11th at 11:00-12:30 at the forum we will be discussing our community wide
goals for the Queen release [1]!

We do OpenStack-wide goals to "achieve visible common changes, push for basic
levels of consistency and user experience, and efficiently improve certain
areas where technical debt payments have become too high – across all OpenStack
projects" [2].

Our goals backlog: [3]

* New goals are highly welcome.
* Each goal would achieveable in one cycle, if not we need to break the goal
  into smaller connected goals.
* Some Goals already have a team (ex: Python 3) but some haven't.  Maybe could
  we dress a list of people able to step-up and volunteer to help on these
  ones.
* Some Goals might require some documentation for how to achieve it.

Thanks to Emilien for leading our community wide goals for Pike [4]

* There was an overwhelming amount of support for beginning Python 3.5 support
  [5] by having our unit tests voting.
* Unfortunately getting our API endpoints to support WSGI still has some work
  [6].

Lets start adding/updating what's in our backlog [3] to prepare for the forum
next week!

[1] - https://governance.openstack.org/tc/goals/pike/index.html
[2] - https://governance.openstack.org/tc/goals/pike/index.html
[3] - https://etherpad.openstack.org/p/community-goals
[4] - https://governance.openstack.org/tc/goals/pike/index.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] Colleen Murphy for core

[Mike Perez]

On 13:15 May 02, Lance Bragstad wrote:
> Hey folks,
> 
> During today's keystone meeting we added another member to keystone's core
> team. For several releases, Colleen's had a profound impact on keystone.
> Her reviews are meticulous and of incredible quality. She has no hesitation
> to jump into keystone's most confusing realms and as a result has become an
> expert on several identity topics like federation and LDAP integration.
> 
> I'd like to thank Colleen for all her hard work and upholding the stability
> and usability of the project.
> 
> 
> Congratulations, Colleen!

Congratulations Colleen!!!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [election] TC non-candidacy

[Mike Perez]

Hi all,

Thanks for letting me serve as a TC member. I will not be running this time
around since fungi is serving from the OpenStack Foundation on the
committee and ttx is more deserving for re-election.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Developer Mailing List Digest March 18-24

[Mike Perez]

SuccessBot Says
===
* Yolanda [1]: Wiki problems have been fixed, it's up and running
* johnthetubaguy [2]: First few patches adding real docs for policy have now
* merged in Nova. A much improved sample file [3].
* Tell us yours via OpenStack IRC channels with message “#success ”
* All: [4]

Release Naming for R

* It's time to pick a name for our “R” release.
* The associated summit will be in Vancouver, so the geographic location has
  been chosen as “British Colombia”.
* Rules:
  - Each release name must start with the letter of the ISO basic Latin
alphabet following the initial letter of the previous release, starting
with the initial release of "Austin". After "Z", the next name should start
with "A" again.
  - The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are
also acceptable.
  - The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part
of the initiation of the selection process.
  - The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".
* Full thread [5]

Moving Gnocchi out 
==
* The project Gnocchi which has been tagged independent since it's inception
  has potential outside of OpenStack.
* Being part of the big tent helped the project be built, but there is a belief
  that it restrains its adoption outside of OpenStack.
* The team has decided to move it out of OpenStack [6].
  - In addition out of the OpenStack infrastructure.
* Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
* Full thread [7]

POST /api-wg/news
=
* Guides under review:
  - Define pagination guidelines (recently rebooted) [8]
  - Create a new set of api stability guidelines [9]
  - Microversions: add next_min_version field in version body [10]
  - Mention max length limit information for tags [11]
  - Add API capabilities discovery guideline [12]
  - WIP: microversion architecture archival doc (very early; not yet ready for
review) [13]
* Full thread [14]

[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-03-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-21.log.html
[3] - https://docs.openstack.org/developer/nova/sample_policy.html
[4] - https://wiki.openstack.org/wiki/Successes
[5] - http://lists.openstack.org/pipermail/openstack-dev/2017-March/114436.html
[6] - https://review.openstack.org/447438
[7] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#114300
[8] - https://review.openstack.org/#/c/446716/
[9] - https://review.openstack.org/#/c/421846/
[10] - https://review.openstack.org/#/c/446138/
[11] - https://review.openstack.org/#/c/447344/
[12] - https://review.openstack.org/#/c/386555/
[13] - https://review.openstack.org/444892
[14] - http://lists.openstack.org/pipermail/openstack-dev/2017-March/114558.html


pgpAKFER2XpHR.pgp
Description: PGP signature
__
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 Developer Mailing List Digest March 11-17

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/03/openstack-developer-mailing-list-digest-20170317/

SuccessBot Says
===
* Dims [1]: Nova now has a python35 based CI job in check queue running Tempest
  tests (everything running on py35)
* jaypipes [2]: Finally got a good functional test created that stresses the
  Ironic and Nova integration and migration from Newton to Ocata.
* Lbragstad [3]: the OpenStack-Ansible project has a test environment that
  automates rolling upgrade performance testing
* annegentle [4]: Craig Sterrett and the App Dev Enablement WG: New links to
  more content for the appdev docs [5]
* jlvillal [6]: Ironic team completed the multi-node grenade CI job
* Tell us yours via OpenStack IRC channels with message “#success ”
* All: [7]

Pike Release Management Communication
=
* The release liaison is responsible for:
  - Coordinating with the release management team.
  - Validating your team release team requests.
  - Ensure release cycle deadlines are met.
  - It's encouraged to nominate a release liaison. Otherwise this tasks falls
back to the PTL.
* Ensure the releaase liaison has time and ability to handle the communication
  necessary.
  - Failing to follow through on a needed process step may block you from
meeting deadlines or releasing as our milestones are date-based, not
feature-based.
* Three primary communication tools:
  - Email for announcements and asynchronous communication
-- “[release]” topic tag on the openstack-dev mailing list.
-- This includes the weekly release countdown emails with details on focus,
   tasks, and upcoming dates.
  - IRC for time sensitive interactions
-- With more than 50 teams, the release team relies on your presence in the
   freenode #openstack-release channel.
  - Written documentation for relatively stable information
-- The release team has published the schedule for the Pike cycle [8]
-- You can add the schedule to your own calendar [9]
* Things to do right now:
  - Update your release liaisons [10].
  - Make sure your IRC and email address listed in projects.yaml [11].
* Update your mail filters to look for “[release]” in the subject line.
* Full thread [12]

OpenStack Summit Boston Schedule Now Live!
==
* Main conference schedule [13]
* Register now [14]
* Hotel discount rates for attendees [15]
* Stackcity party [16]
* Take the certified OpenStack Administrator exam [17]
* City guide of restaurants and must see sites [18]
* Full thread [19]

Some Information About the Forum at the Summit in Boston

* “Forum” proper
  - 3 medium sized fishbowl rooms for cross-community discussions.
  - Selected and scheduled by a committee formed of TC and UC members,
facilitated by the Foundation staff members.
  - Brainstorming for topics [20]
* “On-boarding” rooms
  - Two rooms setup classroom style for projects teams and workgroups who want
to on-board new team members.
  - Examples include providing introduction to your codebase for prospective
new contributors.
  - These should not be tradiitonal “project intro” talks.
* Free hacking/meetup spaces
  - Four to five rooms populated with roundtables for ad-hoc discussions and
hacking.
* Full thread [21]

The Future of the App Catalog
=
* Created early 2015 as a market place of pre-packaged applications [22] that
  you can deploy using Murano.
* This has grown to 45 Glance images, 13 Heat templates and 6 Tosca templates.
  Otherwise did not pick up a lot of steam.
* ~30% are just thin wrappers around Docker containers.
* Traffic stats show 100 visits per week, 75% of which only read the index
  page.
* In parallel, Docker developed a pretty successful containerized application
  marketplace (Docker Hub) with hundreds or thousands regularly updated apps.
  - Keeping the catalog around makes us look like we are unsuccessfully trying
to compete with that ecosystem, while OpenStack is in fact complimentary.
* In the past, we have retired projects that were dead upstream.
  - The app catalog is however has an active maintenance team.
  - If we retire the app catalog, it would not be a reflection on that team
performance, but that the beta was arguably not successful in build an
active market place and a great fit from a strategy perspective.
* Two approaches for users today to deploy docker apps in OpenStack:
  - Container-native approach using “docker run” after using Nova or K8s
cluster using Magnum.
  - OpenStack Native approach “zun create nginx”.
* Full thread [23][24]

ZooKeeper vs etcd for Tooz/DLM
==
* Devstack defaults to ZooKeeper and is opinionated about it.
* Lots of container related projects are using etcd [25], so do we need to
  avoid both ZooKeeper and etcd?
* For things like databases and message queues, it's more 

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Mike Perez]

On 12:35 Mar 14, Jay Pipes wrote:
> On 03/14/2017 08:57 AM, Julien Danjou wrote:
> >On Tue, Mar 14 2017, Davanum Srinivas wrote:
> >
> >>Let's do it!! (etcd v2-v3 in tooz)
> >
> >Hehe. I'll move that higher in my priority list, I swear. But anyone is
> >free to beat me to it in the meantime. ;)
> 
> A weekend experiment:
> 
> https://github.com/jaypipes/os-lively
> 
> Not tooz, because I'm not interested in a DLM nor leader election library
> (that's what the underlying etcd3 cluster handles for me), only a fast
> service liveness/healthcheck system, but it shows usage of etcd3 and Google
> Protocol Buffers implementing a simple API for liveness checking and host
> maintenance reporting.
> 
> My plan is to push some proof-of-concept patches that replace Nova's
> servicegroup API with os-lively and eliminate Nova's use of an RDBMS for
> service liveness checking, which should dramatically reduce the amount of
> both DB traffic as well as conductor/MQ service update traffic.

As Monty has mentioned, I'd love for us to decide on one thing. As being
a moderator of that discussion I was trying not to be one-sided.

Whether or not a decision was made 1.5 years ago, the community that was
present at that time of the decision at the summit decided on an abstraction
layer to have options. Forcing an option on the community without gathering
feedback of what the community currently looks like is not a good idea.

I'd recommend if you want to make this base service, start the discussions in
somewhere other than the dev list, like the Forum.

-- 
Mike Perez


pgpKfEPbE8x16.pgp
Description: PGP signature
__
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] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Mike Perez]

On 16:37 Mar 18, Mike Perez wrote:
> On 16:02 Mar 15, Monty Taylor wrote:
> > On 03/15/2017 02:52 PM, Louis Taylor wrote:
> > > On Wed, Mar 15, 2017 at 1:44 PM, Julien Danjou <jul...@danjou.info> wrote:
> > >> On Wed, Mar 15 2017, Davanum Srinivas wrote:
> > >>
> > >>> Yep, jd__ and i confirmed that things work with 3.x
> > >>
> > >> Though to be clear, what's used in tooz is the v2 HTTP API, not the new
> > >> v3 gRPC API.
> > > 
> > > And just to be double clear: although etcd 3.x comes with a v2 api,
> > > the etcd3 api also has a different data model, so the data stored
> > > using it is not accessible to the v2 api, and vice versa.
> > 
> > AH! That's different...
> > 
> > For my money, not that I have any, I'd still suggest we just pile on
> > getting moved over to v3 gRPC real quick and then make that the default.
> 
> I'm also happy about this move. However, it doesn't matter if we made this
> decision 1.5 years ago. What matters is we this decision in a place that 
> others
> were around to contribute to the decision, which was the summit. The Forum is
> coming up, so I have proposed the topic. Coming to a decision of changing the
> default or even a base service for our operators over the dev list is not
> a good idea.

Thinking about this some more, I guess changing the default in gate won't
matter as long as some implementation of tooz is being used. My mind is fuzzy
whether or not we explicity decided to gate on zookeeper, or if what Monty says
is right that it was the only thing working so we did that. Removed my -1.

-- 
Mike Perez


pgprG61VgrOgM.pgp
Description: PGP signature
__
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] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Mike Perez]

On 16:02 Mar 15, Monty Taylor wrote:
> On 03/15/2017 02:52 PM, Louis Taylor wrote:
> > On Wed, Mar 15, 2017 at 1:44 PM, Julien Danjou <jul...@danjou.info> wrote:
> >> On Wed, Mar 15 2017, Davanum Srinivas wrote:
> >>
> >>> Yep, jd__ and i confirmed that things work with 3.x
> >>
> >> Though to be clear, what's used in tooz is the v2 HTTP API, not the new
> >> v3 gRPC API.
> > 
> > And just to be double clear: although etcd 3.x comes with a v2 api,
> > the etcd3 api also has a different data model, so the data stored
> > using it is not accessible to the v2 api, and vice versa.
> 
> AH! That's different...
> 
> For my money, not that I have any, I'd still suggest we just pile on
> getting moved over to v3 gRPC real quick and then make that the default.

I'm also happy about this move. However, it doesn't matter if we made this
decision 1.5 years ago. What matters is we this decision in a place that others
were around to contribute to the decision, which was the summit. The Forum is
coming up, so I have proposed the topic. Coming to a decision of changing the
default or even a base service for our operators over the dev list is not
a good idea.

-- 
Mike Perez


pgpQN_PCgFfuX.pgp
Description: PGP signature
__
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] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Mike Perez]

On 15:55 Mar 02, Morales, Victor wrote:
> I got this link[11] from Ankur, apparently Nova and Neutron has already 
> started a common effort
> 
> [11] https://review.openstack.org/#/c/330027/

Thanks for pointing me to this Victor! I have spoke to Doug and Sean Dague in
#openstack-dev about this, and I think it'll be fine for us to keep the current
INI file approach. I've reached out to Ankur to hopefully restore and continue
this effort.

What do Designate and Cinder folks think of this approach?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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][swg] per-project "Business only" moderated mailing lists

[Mike Perez]

On 13:04 Feb 27, Clint Byrum wrote:
> Excerpts from Doug Hellmann's message of 2017-02-27 15:43:12 -0500:
> > 
> > As a person who sends a lot of process-driven email to this list,
> > it is not working for my needs to communicate with others.
> > 
> > Over the past few cycles when I was the release PTL, I always had
> > a couple of PTLs say there was too much email on this list for them
> > to read, and that they had not read my instructions for managing
> > releases. That resulted in us having to train folks at the last
> > minute, remind them of deadlines, deal with them missing deadlines,
> > and otherwise increased the release team's workload.
> > 
> > It is possible the situation will improve now that the automation
> > work is mostly complete and we expect to see fewer significant
> > changes in the release workflow. That still leaves quite a few
> > people regularly surprised by deadlines, though.
> > 
> 
> The problem above is really the krux of it. Whether or not you can keep
> up with the mailing list can be an unknown, unknown. Even now, those
> who can't actually handle the mailing list traffic are in fact likely
> missing this thread about whether or not people can handle the mailing
> list traffic (credit fungi for pointing out this irony to me on IRC).

I feel like this subject comes up in different forms.

FWIW, the dev digest does cover information like release deadlines, elections,
etc. Here's an example:

https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170120/

For anyone that feels like the current ML system is not working and you're
missing important information, do yourself a favor and at least double check
the digest. Suggestions are welcome!


-- 
Mike Perez


pgpPPZaNst4PF.pgp
Description: PGP signature
__
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] [cross-project][nova][cinder][designate][neutron] Common support-matrix.py

[Mike Perez]

Hey all,

I kicked off a thread [1] to start talking about approaches with improving
vendor discoveribility by improving our Market Place [2]. In order to improve
our market place, having the projects be more part of the process would allow
the information to be more accurate of what vendors have good support in the
respected service.

It was discovered that we have a common solution of using INI files and parsing
that with a common support-matrix.py script that originated out of nova [3].
I would like to propose we push this into some common sphinx extension project.
Are there any suggestions of where that could live?

I've look at how Nova [3][4], Neutron [5][6] and Designate [7][8] are doing
this today. Nova and Neutron are pretty close, and Designate is a much more
simplified version. Cinder [9][10] is not using INI files, but instead going
off the driver classes themselves. Are there any other projects I'm missing?

Cinder and Designate have drivers per row, as oppose to Nova and Neutron
which have features per row. This makes sense given the difference in drivers
versus features?

I'm assuming the Designate matrix is saying every driver supports every feature
in its API? If so, that's so awesome and makes me happy.

I would like to start brainstorming on how we can converge on a common matrix
table design so things are a bit more consistent and easier for a common
parsing tool.


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
[2] - https://www.openstack.org/marketplace/drivers/
[3] - 
https://docs.openstack.org/developer/nova/support-matrix.html#operation_maintenance_mode
[4] - 
http://git.openstack.org/cgit/openstack/nova/tree/doc/ext/support_matrix.py
[5] - https://review.openstack.org/#/c/318192/76
[6] - 
http://docs-draft.openstack.org/92/318192/76/check/gate-neutron-docs-ubuntu-xenial/48cdeb7//doc/build/html/feature_classification/general_feature_support_matrix.html
[7] - 
https://git.openstack.org/cgit/openstack/designate/tree/doc/ext/support_matrix.py
[8] - https://docs.openstack.org/developer/designate/support-matrix.html
[9] - https://review.openstack.org/#/c/371169/15
[10] - 
http://docs-draft.openstack.org/69/371169/15/check/gate-cinder-docs-ubuntu-xenial/aa1bdb1//doc/build/html/driver_support_matrix.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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] [Cinder] Project mascot available

[Mike Perez]

On 08:24 Feb 14, Walter Boring wrote:
> How does Horse translate to Cinder block?
> I don't get it.  Our original Cinder block made a lot of sense, considering
> the name of the project.
> 
> 
> This is...just an odd horse for no particular reason.

As I remember from the midcycle meetup discussion, we were more interested in
the rear end of the horse being shown, with the horse looking back.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Developer Mailing List Digest January 21-27

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170127/

SuccessBot Says
===
* dims [1] : Nova now has a python35 based CI job in check queue running
  Tempest tests (everything running on py35)
* markvoelker [2]: Newly published Foundation annual report starts off with
  interoperability right in the chairman's note [3]
*  Tell us yours via OpenStack IRC channels with message “#success ”
* All: [4]

Get Active in Upstream Training
===
* There is a continuous effort in helping newcomers join our community by
  organizing upstream contribution trainings [5][6] before every summit.
  - 1.5 - 2 days of hands-on steps of becoming an active OpenStack contributor.
* Like everything else, this is a community effort.
  - In preparation for the Boston summit and the upcoming PTG in Atlanta, we
are looking for coaches and mentors to help us make the training better.
  - If you’re interested in helping contact:
-- Ildiko Vancsa IRC freenode at ildikov or email [7]
-- Kendall Nelson IRC freenode at diablo_rojo or email [8]
* Full thread: [9]

Project Team Gathering Coordination Tool

* No central scheduling, beyond assigned rooms to teams and days.
  - Each team arranges their time in their room.
  - List of etherpads [10]
* We still need centralized communication beyond each room:
  - An event IRC channel: ##openstack-ptg on free node IRC
-- Do public service announcements
-- Pings from room to room.
  - An EtherCalc spreadsheet powered dynamic schedule with extra rooms
available:
-- One fishbowl
-- A few dark rooms with projectors and screens (not all will have a/v
equipment due to budget).
-- Infra is working on setting up EtherCalc
* Full thread: [11]

POST /api-wg/news
=
* API Guidelines proposed for freeze:
  - Add guidelines on usage of state vs. status [12]
  - Clarify the status values in versions [13]
  - Add guideline for invalid query parameters [14]
* Guidelines currently under review:
  - Add guidelines for boolean names [15]
  - Define pagination guidelines [16]
  - Add API capabilities discovery guideline [17]
* Full thread: [18]

Lots of Teams Without PTL Candidates

* We are reaching close to the end of the PTL nominations (Jan 29, 2017 23:45
  UTC), but have projects that are leaderless:
* Community App Catalog
* Ec2 API
* Fuel
* Karbor
* Magnum
* Monasca
* OpenStackClient
* OpenStackUX
* Packaging Prm
* Rally
* RefStack
* Requirements
* Senlin
* Stable Branch Maintenance
* Vitrage
* Zun
* Full thread [19]


[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-python3/%23openstack-python3.2017-01-23.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-interop/%23openstack-interop.2017-01-24.log.html
[3] - 
https://www.openstack.org/assets/reports/OpenStack-2016-Annual-Report-final-draft.pdf
[4] - 
https://www.openstack.org/assets/reports/OpenStack-2016-Annual-Report-final-draft.pdf
[5] - http://docs.openstack.org/upstream-training/
[6] - 
http://superuser.openstack.org/articles/openstack-upstream-training-revamp/
[7] - mailto:ild...@openstack.org
[8] - mailto:knel...@openstack.org
[9] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110788.html
[10] - https://wiki.openstack.org/wiki/PTG/Pike/Etherpads
[11] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110909.html
[12] - https://review.openstack.org/#/c/411528/
[13] - https://review.openstack.org/#/c/411849/
[14] - https://review.openstack.org/417441
[15] - https://review.openstack.org/#/c/411529/
[16] - https://review.openstack.org/#/c/386555/
[17] - https://review.openstack.org/#/c/386555/
[18] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/111058.html
[19] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/111071.html


signature.asc
Description: PGP signature
__
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][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mike Perez]

On 18:16 Jan 24, Mikhail Fedosin wrote:
> Hey, Flavio :) Thanks for your questions!
> 
> As you said currently only Nokia's adopting Glare for its own platform, but
> if we talk about OpenStack, that I believe Mistral will start to use it
> soon.
> In my opinion Glare's adoption is low due to the fact that the project is
> not included under Big Tent. I think it will be changed soon, because now
> I'm finishing Glare v1 API proposal, and when it's done we will apply under
> BT.
> 
> About Glance v2 API - as I said they are +- the same with several cosmetic
> differences (in Glance status is called 'queued', in Glare we renamed it to
> 'drafted', and so on). For this reason I'm going to implement a middleware,
> that will provide a full Image API v2 for Glare (even with unnecessary
> '/v2' prefix) and glance clients will be able to communicate with it as
> with Glance. It's definitely doable and we can discuss it more detailed
> during the PTG.

Both Flavio and Doug asked you to expand on the issues with the Glance API. Can
you please expand on that.

-- 
Mike Perez


pgp07yDGWQQEK.pgp
Description: PGP signature
__
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] PTL Candidacy

[Mike Perez]

On 18:35 Jan 22, Kevin Benton wrote:
> I would like to propose my candidacy for the Neutron PTL.
> 
> I have been contributing to Neutron since the Havana development
> cycle working for a network vendor and then a distribution vendor.
> I have been a core reviewer since the Kilo development cycle and
> I am on the Neutron stable maintenance team as well as the drivers
> team.
> 
> I have a few priorities that I would focus on as PTL:

Do you have any thoughts/plans with plugin validation? [1][2][3]

[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html
[2] - https://review.openstack.org/#/c/391594/
[3] - https://etherpad.openstack.org/p/driverlog-validation

-- 
Mike Perez


pgpxgOUqLRXO4.pgp
Description: PGP signature
__
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 Developer Mailing List Digest January 14-20

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170120/

SuccessBot Says
===
* stevemar [1] : number of open keystone bugs < 100!
* morgan [2] : Good policy meeting, provided history and background that
  cleared up a lot of confusion
*  Tell us yours via OpenStack IRC channels with message “#success ”
* All: https://wiki.openstack.org/wiki/Successes

FIPS Compliance
===
* Previous threads [3] have been discussing enabling Federal Information
  Processing Standards (FIPS).
* Various OpenStack projects make md5 calls. Not for security purposes, just
  hash generation, but even that blocks enabling FIPS.
* A patch has been proposed for newest versions of Python for users to set if
  these are used for security or not [4].
  - Won’t land until next versions of Python, but in place for current RHEL and
CentOS versions.
  - We will create a wrapper around md5 with a useforsecurity=False parameter
to check the signature of hashlib.md5.
* Steps forward:
  - Create the wrapper
  - Replace all md5 calls in OpenStack projects with the wrapper.
* Unfortunately the patch 4 has stopped having progress since 2013. We should
  get that merged first.
  - Even if this did land, it would be a while before it was adopted, since it
would land in Python 3.7.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.html#110278

Refreshing and Revalidating API Compatibility Guidelines

* In the last TC meeting [5] , a tag was in review for supporting API
  compatibility [6] .
* The tag evaluates projects by using the API guideline which is out of date
  [7].
  - A review has been posted to refresh these guidelines [8].
  - API compatibility of overtime is a fundamental aspect of OpenStack
interoperability. Not only do we need to get it it right, we need to make
sure we understand it.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110384.html

Base Services
=
* in open stack all components can assume that a number of external services 
won't be present and available (e.g. A message queue, database).
* The Architecture working group has started this effort [9].
* This proposal [10] is a prerequisite in order for us to have more strategic 
discussions with adding base services.
* Review the proposal and/or join the Architecture working group meeting [11].
* Once solidified the technical committee will have a final discussion and 
approval.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110391.html

Improving Vendor Discoverability

* In previous Technical Committee meetings, it was agreed that vendor
  discoverability needs to be improved.
* This is done today with the OpenStack Foundation marketplace [12] .
  - This is powered by the community driven project call driver log which is
a big JSON file [13].
* Various people in the community did not know how the marketplace worked and
  we're unhappy that the projects themselves weren't owning it.
* The goal of this discussion is to have this process be more community driven
  than it is today.
* Suggestion: Split driver log into smaller JSON files that are inside each
  project to maintain.
  - Projects will set how they validate vendors into this list.
  - There’s a trend today for third party CI’s being a choice of validation
[14].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.html

Nominations for OpenStack PTLs Are Now Open!

* Will remain open until January 29, 2017 23:45 UTC.
* Candidates must submit a text file openstack/election repository [15]
  - Filename convention is $cyclename/$projectname/$ircname.txt.
  - To be eligible, you need to have contributed an accepted patch to one of
the corresponding program’s projects [16] during the Neutron-Ocata
timeframe (April 11, 2016 00:00 UTC to January 23, 2017 23:59 UTC).
* Additional information about the nomination process [17]
* Approved candidates will be listed [18].
* Electorate should confirm their email address in Gerrit [19] in Settings ->
  Contact Information -> Preferred Email prior to Jan 25, 2017 23:59 UTC.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110441.html

The Process of Creating stable/ocata branches
=
* As previously mentioned [20], it’s possible for teams to setup stable
  branches when ready.
* The release team will not be automatically setting up branches this cycle.
  - The release liaison within teams will need to inform when ready.
  - The PTL or release liaison may request a new branch by submitting a patch
to the openstack/releases repository specifying the tagged version to be
used as the base of the branch.
* Guidelines for when 

Re: [openstack-dev] [all] Improving Vendor Driver Discoverability

[Mike Perez]

On 17:38 Jan 18, Morales, Victor wrote:
> Just a FYI, Ankur have been working on have a Feature Classification Matrix
> in Neutron[1] which collects some of this information
> 
> [1] https://review.openstack.org/#/c/318192/

I actually didn't know Nova also generated this with a script and ini file.
Perhaps this would be a better approach than a giant JSON file like driver log
is today. I could then have the marketplace parse these ini files using the
common script. What do others think?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
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 Developer Mailing List Digest January 7-13

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170113/

SuccessBot Says
===
* dims [1]: Rally running against Glance (Both Rally and Glance using py3.5).
* AJaegar [2]: docs.openstack.org is served from the new Infra file server that
  is AFS based.
* jd [3]: Gnocchi 3.1 will be shipped with an empty /etc and will work without
  any config file by default.
* cdent [4] : edleafe found narrowed down an important bug in gabbi.
*  Tell us yours via OpenStack IRC channels with message “#success ”
* All: https://wiki.openstack.org/wiki/Successes

Return of the Architecture Working Group

* Meeting times Alternate, even weeks Thursday at 20:00UTC, odd weeks Thursday
  at 01:00UTC
* Currently two proposes:
  - “Base Services” proposal 5 recognizes components leveraging features from
external services that OpenStack components can assume will be present. Two
kinds:
-- Local (like a hypervisor on a compute node)
-- Global (like a database)
  - “Nova Compute API” proposal 6 breaking nova-compute out of Nova itself.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109893.html

Restarting Service-types-authority / service catalog work
* In anticipation of having a productive time in Atlanta for the PTG, various
  patches have been refreshed 7.
* Two base IASS services aren’t in the list yet because of issues:
  - Neutron / network - discrepancy between common use of “network” and
“networking” in the API reference URL. Other services in the list have the
service-type and the URL name for the API reference are the same.
  - Cinder / volume - Moving forward from using volumev2 and volumev3 in
devstack.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109758.html

Feedback From Driver Maintainers About Future of Driver Projects

* Major observations
  - Yes drivers are an important part of OpenStack.
  - Discoverability of drivers needs to be fixed immediately.
  - It’s important to have visibility in a central place of the status of each
driver.
  - Both driver developer and a high level person at a company should feel
they’re part of something.
  - Give drivers access to publish to docs.openstack.org.
  - What constitutes a project was never for drivers. Drivers are part part of
the project. Driver developers contribute to OpenStack by creating drivers.
* Discoverability:
  - Consensus: it is currently all over the place 8 9 10.
  - There should be CI results available.
  - Discoverability can be fixed independently of governance changes.
* Driver projects official or not?
  - Out-of-tree vendors have a desire to become “official” OpenStack projects.
  - Opinion: let driver projects become official without CI requirements.
  - Opinion: Do not allow drivers projects to become official, that doesn’t
mean they shouldn’t easily be discoverable.
  - Opinion: We don't need to open the flood gates of allowing vendors to be
teams in the OpenStack governance to make the vendors developers happy.
  - Fact: This implies being placed under the TC oversight. It is a significant
move that could have unintended side-effects, it is hard to reverse
(kicking out teams we accepted is worse than not including them in the
first place), and our community is divided on the way forward. So we need
to give that question our full attention and not rush the answer.
  * Opinion: Consider driver log 11 an official OpenStack project to be listed
under governance with a PTL, weekly meetings, and all that it required to
allow the team to be effective in their mission of keeping the marketplace
a trustworthy resource for learning about OpenStack driver ecosystem.
* Driver Developers:
  - Opinion: A driver developer that ONLY contributes to vendor specific driver
code should not have the same influence as other OpenStack developers,
voting for PTL, TC, and ATC status.
  - Opinion: PTLs should leverage the extra-atcs option in the governance repo.
* In-tree VS out-of-tree
  - Cinder has in-tree drivers, but also has out-of-tree drivers when their CI
is not maintained or when minimum feature requirements are not met. They
are marked as ‘not supported’ and have a single release to get things
working before being moved out-of-tree.
  - Ironic has a single out-of-tree repo 12 -- But also in-tree 13
  - Neutron has all drivers out-of-tree, with project names like:
‘networking-cisco’.
  - Many opinions on the “stick-based” approach the cinder team took.
  - Opinion: The in-tree vs out-of-tree argument is developer focused.
Out-of-tree drivers have obvious benefits (develop quickly, maintain their
own team, no need for a core to review the patch). But a vendor that is
looking to make sure a driver is supported will not be 

[openstack-dev] [all] Improving Vendor Driver Discoverability

[Mike Perez]

Hello all,

In the spirit of recent Technical Committee discussions I would like to bring
focus on how we're doing vendor driver discoverability. Today we're doing this
with the OpenStack Foundation marketplace [1] which is powered by the driverlog
project. In a nutshell, it is a big JSON file [2] that has information on which
vendor solutions are supported by which projects in which releases. This
information is then parsed to generate the marketplace so that users can
discover them. As discussed in previous TC meetings [3] we need to recognize
vendors that are trying to make great products work in OpenStack so that they
can be successful, which allows our community to be successful and healthy.

In the feedback I have received from various people in the community, some
didn’t know how it worked, and were unhappy that the projects themselves
weren’t owning this. I totally agree that project teams should own this and
should be encouraged to be involved in the reviews. Today that’s not happening.
I’d like to propose we come up with a way for the marketplace to be more
community-driven by the projects that are validating these solutions.

At the Barcelona Summit [4] we discussed ways to improve driverlog. Projects
like Nova have a support matrix of hypervisors in their in-tree documentation.
Various members of the Cinder project also expressed interest in using this
solution. It was suggested in the session that the marketplace should just link
to the projects' appropriate documentation. The problem with this solution is
the information is not presented in a consistent way across projects, as
driverlog does it today. We could accomplish this instead by using a parsable
format that is stored in each appropriate project's git repository. I'm
thinking of pretty much how driverlog works today, but broken up into
individual projects.

The marketplace can parse this information and present it in one place
consistently. Projects may also continue to parse this information in their own
documentation, and we can even write a common tool to do this. The way a vendor
is listed here is based on being validated by the project team itself. Keeping
things in the marketplace would also address the suggestions that came out of
the recent feedback we received from various driver maintainers [4].

The way validation works is completely up to the project team. In my research
as shown in the Summit etherpad [5] there's a clear trend in projects doing
continuous integration for validation. If we wanted to we could also have the
marketplace give the current CI results, which was also requested in the
feedback from driver maintainers.

I would like to volunteer in creating the initial files for each project with
what the marketplace says today.

[1] - https://www.openstack.org/marketplace/drivers/
[2] - 
http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[3] - 
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-10-20.01.log.html#l-106
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
[5] - https://etherpad.openstack.org/p/driverlog-validation

-- 
Mike Perez

__
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] [release][ptl] not planning to serve as release PTL for Pike

[Mike Perez]

On 15:00 Jan 13, Doug Hellmann wrote:
> I announced this at the release team meeting on 6 Jan, but thought
> I should also post to the list as well:  I do not plan to serve as
> the Release Management team PTL for the Pike release cycle.
> 
> It has been my pleasure to serve as PTL, and we've almost finished
> the automation work that I envisioned when I joined the team. Now
> I would like to shift my focus to some other projects within the
> community.  I will still be an active member of the Release Management
> team, helping with new initiatives and reviews for releases.

Thank you Doug for your continued good work in the community. I'm anxious to
see what you're going to make better next!

-- 
Mike Perez

__
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] [cinder] [infra] drbdmanage is no more GPL2

[Mike Perez]

On 09:44 Jan 10, Sean McGinnis wrote:
> On Mon, Dec 12, 2016 at 07:58:17AM +0100, Mehdi Abaakouk wrote:
> > Hi,
> > 
> > I have recently seen that drbdmanage python library is no more GPL2 but
> > need a end user license agreement [1].
> > 
> > Is this compatible with the driver policy of Cinder ?
> > 
> > [1] 
> > http://git.drbd.org/drbdmanage.git/commitdiff/441dc6a96b0bc6a08d2469fa5a82d97fc08e8ec1
> > 
> > Regards
> > 
> > -- 
> > Mehdi Abaakouk
> > mail: sil...@sileht.net
> > irc: sileht
> > 
> 
> It doesn't look like much has changed here. There has been one commit
> that only slightly modified the new license: [1]
> 
> IANAL, and I don't want to make assumption on what can and can't be
> done, so looking to other more informed folks. Do we need to remove this
> from the Jenkins run CI tests?
> 
> Input would be appreciated.
> 
> Sean

Can we survey from the operators community if anyone cares, and if some people
do, who wants to step up and maintain a forked version for support to remain in
Cinder.

-- 
Mike Perez

__
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] [api-wg] restarting service-types-authority / service catalog work

[Mike Perez]

On 14:10 Jan 06, Sean Dague wrote:
> Cinder / volume - right now the devstack example of using cinder is to
> use volumev2 as the service type (volumev3 is also added), which is kind
> of ugly and not a thing that I'd like us to standardize on. How do we
> move forward here to not make volumev2 a required type?

At one point I did a patch in Cinderclient to not care about the endpoint
having volumev2 as the service type, or version in the endpoint [1], with
examples of this working [2]. This was reverted [3] due to cases where a proxy
was being used and returned internal endpoints. We could probably revisit this
now that the appropriate configuration option to get around this problem has
been around for some time [4].

[1] - https://review.openstack.org/#/c/145613/
[2] - http://paste.openstack.org/raw/155906/
[3] - https://review.openstack.org/#/c/194476/
[4] - https://review.openstack.org/#/c/159374/

-- 
Mike Perez

__
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 Developer Mailing List Digest December 31 - January 6

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170106/

SuccessBot Says
===
* Dims - Keystone now has Devstack based functional test with everything
  running under python3.5.
* Tell us yours via OpenStack IRC channels with message “#success "
* All: https://wiki.openstack.org/wiki/Successes 

Time To Retire Nova-docker
==
* nova-docker has lagged behind the last 6 months of nova development.
* No longer passes simple CI unit tests.
  - There are patches to at least get the unit tests work [1] .
* If the core team no longer has time for it, perhaps we should just archive
  it.
* People ask about it on ##openstack-nova about once or twice a year, but it’s
  not recommended as it’s not maintained.
* It’s believed some people are running and hacking on it outside of the
  community.
* The Sun project provides lifecycle management interface for containers that
  are started in container orchestration engines provided with Magnum.
* Nova-lxc driver provides an ability of treating containers like your virtual
  machines. [2]
  - Not recommended for production use though, but still better maintained than
nova-docker [3].
* Nova-lxd also provides the ability of treating containers like virtual
  machines.
* Virtuozzo which is supported in Nova via libvirt provides both a virtual
  machine and OS containers similar to LXC.
  - These containers have been in production for more than 10 years already.
  - Well maintained and actually has CI testing.
* A proposal to remove it [4].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/thread.html#109387

Community Goals For Pike

* A few months ago the community started identifying work for OpenStack-wide
  goals to “achieve visible common changes, push for basic levels of
  consistency and user experience, and efficiently improve certain areas where
  technical debt payments have become to high - across all OpenStack projects.”
* First goal defined [5] to remove copies of incubated Oslo code.
* Moving forward in Pike:
  - Collect feedback of our first iteration. What went well and what was
challenging?
  - Etherpad for feedback [6]
* Goals backlog [7]
  - New goals welcome
  - Each goal should be achievable in one cycle. If not, it should be broken
up.
  - Some goals might require documentation for how it could be achieved.
* Choose goals for Pike
  - What is really urgent? What can wait for six months?
  - Who is available and interested in contributing to the goal?
* Feedback was also collected at the Barcelona summit [8]
* Digest of feedback:
  - Most projects achieved the goal for Ocata, and there was interest in doing
it on time.
  - Some confusion on acknowledging a goal and doing the work.
  - Some projects slow on the uptake and reviewing the patches.
  - Each goal should document where the “guides” are, and how to find them for
help.
  - Achieving multiple goals in a single cycle wouldn’t be possible for all 
team.
* The OpenStack Product Working group is also collecting feedback for goals [9]
* Goals set for Pike:
  - Split out Tempest plugins [10]
  - Python 3 [11]
* TC agreeements from last meeting:
  - 2 goals might be enough for the Pike cycle.
  - The deadline to define Pike goals would be Ocata-3 (Jan 23-27 week).
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/thread.html#108755

POST /api-wg/news
=
* Guidelines current review:
  - Add guidelines on usage of state vs. status [12]
  - Add guidelines for boolean names [13]
  - Clarify the status values in versions [14]
  - Define pagination guidelines [15]
  - Add API capabilities discovery guideline [16]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109698.html


[1] - 
https://review.openstack.org/#/q/status:open+project:openstack/nova-docker+branch:master+topic:fixes_for_master
 
[2] - http://docs.openstack.org/developer/nova/support-matrix.html
[3] - 
http://docs.openstack.org/newton/config-reference/compute/hypervisor-lxc.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2016-July/098940.html
[5] - http://governance.openstack.org/goals/index.html
[6] - https://etherpad.openstack.org/p/community-goals-ocata-feedback
[7] - https://etherpad.openstack.org/p/community-goals
[8] - https://etherpad.openstack.org/p/ocata-summit-xp-community-wide-goals
[9] - http://lists.openstack.org/pipermail/product-wg/2016-December/001372.html
[10] - https://review.openstack.org/#/c/369749/
[11] - https://review.openstack.org/349069
[12] - https://review.openstack.org/#/c/411528/
[13] - https://review.openstack.org/#/c/411529/
[14] - https://review.openstack.org/#/c/411849/
[15] - https://review.openstack.org/#/c/390973/
[16] - https://review.openstack.org/#/c/386555/

__
OpenStack Development 

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Mike Perez]

On 13:33 Nov 28, Doug Hellmann wrote:
> The OpenStack community wants to encourage collaboration by emphasizing
> contributions to projects that abstract differences between
> vendor-specific products, while still empowering vendors to integrate
> their products with OpenStack through drivers that can be consumed
> by the abstraction layers.
> 
> Some teams for projects that use drivers may not want to manage
> some or all of the drivers that can be consumed by their project
> because they have little insight into testing or debugging the code,
> or do not have the resources needed to manage centrally a large
> number of separate drivers. Vendors are of course free to produce
> drivers to integrate with OpenStack completely outside of the
> community, but because we value having the drivers as well as the
> more general support of vendor companies, we want to encourage a
> higher level of engagement by welcoming vendor-specific teams to
> be a part of our community governance.
> 
> Our Requirements for New Projects list [0] includes a statement
> about establishing a "level and open collaboration playing field"
> 
>   The project shall provide a level and open collaboration playing
>   field for all contributors. The project shall not benefit a single
>   vendor, or a single vendors product offerings; nor advantage
>   contributors from a single vendor organization due to access to
>   source code, hardware, resources or other proprietary technology
>   available only to those contributors.
> 
> This requirement makes it difficult to support having teams focused
> on producing a deliverable that primarily benefits a single vendor.
> So, we have some tension between wanting to collaborate and have a
> level playing field, while wanting to control the amount of driver
> code that projects have to manage.
> 
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"



Sorry for bringing this thread back up as I was gone for paternity leave, and
have been looking into this a bit.

I was reached out by someone at Cisco during the Ocata summit that was
interested in a Cisco driver being more recognized and official. I think a way
forward for us to be able to have an interested party in marking which drivers
are validated to work in Neutron and tested is knowing which tests need to be
tested by which driver type [1]. If we can provide Armando with more support.
I have provided some more detailed information on reviews [1][2], and I think
this will help with what some are seeking with their drivers.

[1] - https://review.openstack.org/#/c/391594
[2] - https://review.openstack.org/#/c/363709

-- 
Mike Perez

__
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] Gnocchi sizing on production

[Mike Perez]

On 16:07 Dec 27, Sam Huracan wrote:
> Hi,
> 
> I'm testing gnocchi on lab and realizing it drains CPU and RAM too much.
> 
> Do you have a recommendtion for sizing Gnocchi Server configuration?
> 
> Thanks and regards,

Hi Sam,

I recommend asking the OpenStack operators mailing list [1] for configuration
help. It's likely someone on their has knowledge of running Gnocchi in
production, as this list is mostly about development discussions.  Thanks!

[1] - http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Mike Perez

__
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 Developer Mailing List Digest November 5-18

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/11/openstack-developer-mailing-list-digest-20161118/

SuccessBot Says
===
* mriedem: We’re now running neutron by default in Ocata CI jobs [1].
* stevemar: fernet token format is now the default format in keystone! thanks
  lbragstad samueldmq and dolphm for making this happen!
* Ajaegar: developer.openstack.org is now hosted by OpenStack infra.
* Tonyb: OpenStack requirements on pypi [2] is now a thing!
* All

Registration Open For the Project Teams Gathering
=
* The first OpenStack Project Teams Gathering event geared toward existing
  upstream team members, providing a venue for those project teams to meet,
  discuss and organize the development work for the Pike release.
* Where: Atlanta, GA
* When: The week of February 20, 2017
* Register and get more info [3]
* Read the FAQ for any questions. If you still have questions, contact Thierry
  (ttx) over IRC on free node, or email foundation staff at p...@openstack.org.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106995.html

Follow up on Barcelona Review Cadence Discussions
=
* Summary of concerns were Nova is a complex beast. Very few people know even
  most of it well.
* There are areas in Nova where mistakes are costly and hard to rectify later.
* Large amount of code does not merge quickly.
* Barrier of entry for Nova core is very high.
* Subsystem maintainer model has been pitched [4].
* Some believe this is still worth giving a try again in attempt to merge good
  code quickly.
* Nova today uses a list of experts [5] to sign off on various changes today.
* Nova PTL Matt Riedemann’s take:
  - Dislikes the constant comparison of Nova and the Linux kernel. Lets instead
say all of OpenStack is the Linux Kernel, and the subsystems are Nova,
Cinder, Glance, etc.
  - The bar for Nova core isn’t as high as some people make it out to be:
-- Involvement
-- Maintenance
-- Willingness to own and fix problems.
-- Helpful code reviews.
  - Good code is subjective. A worthwhile and useful change might actually
break some other part of the system.
  - Nova core Jay Pipes is supportive of the proposal of subsystems, but with
a commitment to gathering data about total review load, merge velocity, and
some kind of metric to assess code quality impact.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106858

Embracing New Languages in OpenStack

* Technical Committee member Flavio Percoco proposes a list of what the
  community should know/do before accepting a new language:
  - Define a way to share code/libraries for projects using the language
-- A very important piece is feature parity on the operator.
-- Oslo.config for example, our config files shouldn't change because of a 
different implementation language.
-- Keystone auth to drive more service-service interactions through the
   catalog to reduce the number of things an operator needs to configure
   directly.
-- oslo.log so the logging is routed to the same places and same format as
   other things.
-- oslo.messaging and oslo.db as well
-- Work on a basic set of libraries for OpenStack base services
-- Define how the deliverables are distributed
-- Define how stable maintenance will work
-- Setup the CI pipelines for the new language
-- Requirements management and caching/mirroring for the gate.
-- Longer version of this [6].
* Previous notes when the Golang discussion was started to work out questions
  [7].
* TC member Thierry Carrez says the most important in introducing the Go should
  not another way for some of our community to be different, but another way
  for our community to be one.
* TC member Flavio Percoco sees part of the community wide concerns that were
  raised originated from the lack of an actual process of this evaluation to be
  done and the lack of up front work, which is something trying to be addressed
  in this thread.
* TC member Doug Hellmann request has been to demonstrate not just that Swift
  needs Go, but that Swift is willing to help the rest of the community in the
  adoption.
  - Signs of that is happening, for example discussion about how oslo.config
can be used in the current version of Swift.
* Flavio has started a patch that documents his post and the feedback from the 
thread [8]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106877

API Working Group News
==
* Guidelines that have been recently merged:
  - Clarify why CRUD is not a great descriptor [9]
  - Add guidelines for complex queries [10]
  - Specify time intervals based filtering queries [11]
* Guidelines currently under review:
  - Define pagination guidelines [12]
  - WIP add 

[openstack-dev] OpenStack Developer Mailing List Digest October 29 to November 4

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/11/openstack-developer-mailing-list-digest-20161104/

Cross Project Proprietary Driver Code Recap
===
* At the Barcelona design summit there was a cross-project session on the
challenge we’re running where to draw the line with proprietary driver code
[1].
* Option 1:
  - All libraries imported by the driver must be licensed such that they are
redistributable by package maintainers and must be compatible with the
Apache license [2].
  - Existing non-compliant driver code would need to be updated by Queens
release.
  - Code that’s not imported at the driver runtime (CLIs, external binaries,
remote application servers) are acceptable to not be redistributable.
* Option 2:
  - Remove all drivers that are not completely open source and contained in the
project repositories.
* Option 3:
  - Require majority of the business logic is in the open source code.
  - Allow third party, non-redistributable libraries and CLIs that are used as
more of an “RPC” type interface.
  - Reviewers should be able to review the driver and at least get some idea of
the steps the driver is doing to perform requests.
* Jeremy Stanley would like to take option 1 a step further and provide better
  guidance. We should recommend against drivers calling proprietary tools. Some
  vendors go this route because they already have a non-free CLI tool and avoid
  code cost duplication. Other vendors may do this to copy other vendors.
  - The desire of having things redistributable is so that downstream consumers
of OpenStack are not beholden to vendors just to be able to use our (free!)
software with hardware they have.
  - For example
-- Vendor decides to stop supporting a proprietary command line tool
-- You decide to stop paying support contracts to download that tool
-- Vendor disappears
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-October/106432.html

Ocata Release Management Communication
==
* To the PTL’s or or volunteers filling in for a PTL:
* Email
  - The “[release]” topic tag on the openstack-dev mailing list will be used
for important messages.
  - Countdown email with updates on focus, tasks, and upcoming dates.
* IRC
  - Be available on #openstack-release, especially during deadline periods.
It’s up to you to configure an IRC bouncer to ensure this.
* Written documentation
  - Read the Ocata cycle schedule [3].
  - Some projects have their own deadlines. Feel free to submit a patch to this
schedule within the openstack/release repository.
* The Ocata cycle overlaps with several major holidays. If you’re planning time
  off, please make sure your duties are covered by someone else on your team.
  Let the release team know about this so they’re not waiting for your +1.
* Failing to follow through on a needed process step may block you from
  successfully meeting deadlines or releasing.
* Releases milestones and deadlines are date-based, not feature based. When the
  date passes, so does the milestone. If you miss it, you miss it.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106509.html

Release Announcements
=
* The release team at the Barcelona summit discussed how to improve release
  announcements as posting them to openstack-dev and openstack-announce has
  proven to be pretty noisy.
* Proposed solution is to move these announcements to another mailing list. 
Choices are:
  - release-announce
  - release-announcements
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#106579

POST /api-wg/news
* API guidelines that will be merged in one week if there is no further
  feedback:
  - Complex queries [4]
  - Specify time intervals based filtering queries [5]
  - Clarify why CRUD is not a great descriptor [6]
* Guidelines under review:
  - Define pagination guidelines [7]
  - Add API capabilities discovery [8]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/106671.html

Release Countdown for Week R-15
===
* Focus:
  - Teams should be focusing on wrapping up incomplete work left over from the
end of the Newton cycle.
  - Finalizing and announcing plans from the summit
  - Completing specs and blueprints
* General notes:
  - Stable and independent releases have resumed.
  - We cut time out of the Ocala schedule before the first milestone. Ocata-1
will be during R-14.
* Release actions:
  - Release liaisons should add their name and contact information to the wiki
[9].
  - Release liaisons should configure their IRC clients to join
#openstack-release.
  - Release liaisons should review the release models for all deliverables and
make any updates with patches to openstack/governance before the first
milestone.
  - PTLs should add their 

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Mike Perez]

On 14:50 Oct 12, Flavio Percoco wrote:
> Greetings,
> 
> One of the common complains about the existing project organization in the big
> tent is that it's difficult to wrap our heads around the many projects there
> are, their current state (in/out the big tent), their tags, etc.
> 
> This information is available on the governance website[0]. Each official
> project team has a page there containing the information related to the
> deliverables managed by that team. Unfortunately, I don't think this page is
> checked often enough and I believe it's not known by everyone.

Besides the governance site, there is also the project navigator [1] which is
a more friendly landing page on projects and their tags. Although it does not
today capture separate deliverables.

Assuming the README files aren't being manually updated, I don't have a problem
with this idea.

[1] - https://www.openstack.org/software/project-navigator/

-- 
Mike Perez

__
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 Developer Mailing List Digest September 24-30

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/09/openstack-developer-mailing-list-digest-20160930/

Candidate Proposals for TC are now open
===
* Candidate proposals for the Technical committee (9 positions) are open and
  will remain open until 2016-10-01, 23:45 UTC.
* Candidacies must submit a text file to the openstack/election repository [1].
* Candidates for the Technical Committee can be any foundation individual
  member, except the seven TC members who were elected for a one year seat in
  April [2].
* The election will be held from October 3rd through to 23:45 October 8th.
* The electorate are foundation individual members that are committers to one of
  the official programs projects [3] over the Mitaka-Newton timeframe
  (September 5, 2015 00:00 UTC to September 4, 2016 23:59 UTC).
* Current accepted candidates [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104486.html


Release countdown for week R-0, 3-7 October
===
* Focus: Final release week. Most project teams should be preparing for the
  summit in Barcelona.
* General notes:
  - Release management team will tag the final Newton release on October 6th. 
-- Project teams don't have to do anything. The release management team
will re-tag the commit used in the most recent release candidate listed in
openstack/releases.
  - Projects not following the milestone model will not be re-tagged.
  - Cycle-trailing projects will be skipped until the trailing deadline.
* Release actions
  - Projects not follow the milestone-based release model who want
stable/newton branches created should talk to the release team about their
needs. Unbranched projects include:
-- cloudkitty
-- fuel
-- monasca
-- openstackansible
-- senlin
-- solum
-- tripleo
* Important dates:
  - Newton final release: October 6th
  - Newton cycle-trailing deadline: October 20th
  - Ocata Design Summit: October 24-28
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104809.html


Removal of Security and OpenStackSalt Project Teams From the Big Tent (cont.)
=
* The change to remove Astara from the big tent was approval by the TC [4].
* The TC has appointed Piet Kruithof as PTL of the UX team [5].
* Based on the thread discussion [6] and engagements of the team, the Security
  project team will be kept as is and Rob Clark continuing as PTL [7].
* The OpenStackSalt team did not produce any deliverable within the Newton
  cycle. The removal was approved by the current Salt team PTL and the TC [8].
* Full thread:
  
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170


[1] - http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] - https://wiki.openstack.org/wiki/TC_Elections_April_2016#Results
[3] - 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections
[4] - https://review.openstack.org/#/c/376609/
[5] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170
[7] - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html
[8] - https://review.openstack.org/#/c/377906/

__
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 Developer Mailing List Digest September 17-23

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/09/openstack-developer-mailing-list-digest-20160923/

Announcing firehose.openstack.org
=
* A MQTT based unified message bus for infra services.
* This allows a single place to go for consuming messages of events from infra
  services.
* Two interfaces for subscribing to topics:
  - MQTT protocol on the default port
  - Websockets over port 80
* Launchpad and gerrit events are the only things currently sending message to
  firehose, but the plan is to expand this.
* An example [1] of gerritbot on the consuming side, which has support for
  subscribing to gerrit event stream over MQTT.
* A spec giving details on firehose [2].
* Docs on firehose [3].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103985.html


Release countdown for week R-1, 26-30
=
* Focus: All teams should be working on release-critical bugs before the final
  release.
* General
  - 29th September is the deadline for the new release candidates or release
from intermediary projects.
  - Quiet period to follow before the last release candidates on 6th October.
* Release actions:
  - Projects not following the milestone-based release model who want
a stable/newton branch created should talk to the release team.
  - Watch for translation patches and merge them quickly to ensure we have as
many user-facing strings translated as possible in the release candidates.
-- If your project has already been branched, make sure those patches are
applied to the stable branch.
  - Liaisons for projects with independent deliverables should import the
release history by preparing patches to openstack/release.
* Important Dates:
  - Newton last RC, 29 September
  - Newton final release, 6 October
  - Newton release schedule [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103252.html


Removal of Security and OpenStackSalt Project Teams From the Big Tent
=
* The Security and OpenStackSalt projects are without PTLs. Projects leaderless
  default to the Technical Committee for decision of what to do with the
  project [5]. Majority of the Technical Committee has agreed to have these
  projects removed.
* OpenStackSalt is a relatively new addition to the Big Tent, so if they got
  their act together, they could be reproposed.
* We still need to care about security., and we still need a home for the
  vulnerability management team (VMT). The suggested way forward is to have the
  VMT apply to be its own official project team, and have security be a working
  group.
* The Mitaka PTL for the Security mentions missing the election date, but
  provides some things the team has been working on:
  - Issuing Security Notes for Glance, Nova, Horizon, Bandit, Neutron and
Barbican.
  - Updating the security guide (the book we wrote on securing OpenStack)
  - Hosting a midcycle and inducting new members
  - Supporting the VMT with several embargoed and complex vulnerabilities
  - Building up a security blog
  - Making OpenStack the biggest open source project to ever receive the Core
  - Infrastructure Initiative Best Practices Badge
  - Working on the OpenStack Security Whitepaper
  - Developing CI security tooling such as Bandit
* One of the Technical Committee members privately received information that
  explains why the security PTL was not on top of things. With ~60 teams around
  there will always be one of two that miss, but here we're not sure it passes
  the bar of “non-alignment with the community” that would make the security
  team unfit to be an official OpenStack Team.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/thread.html#104170


[1] - 
http://git.openstack.org/cgit/openstack-infra/gerritbot/commit/?id=7c6e57983d499b16b3fabb864cf3b
[2] - http://specs.openstack.org/openstack-infra/infra-specs/specs/firehose.html
[3] - http://docs.openstack.org/infra/system-config/firehose.html
[4] - http://releases.openstack.org/newton/schedule.html
[5] - 
http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections

__
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