[openstack-dev] [neutron] Newton release, neutron-lib and decomposed projects

[Gary Kotton]

Hi,
At the moment I am a little confused and need some help please:

1.   Will we be creating release candidates for Networking-l2gw, 
Networking-sfc and Tap-as-a-service. These projects have tons of deprecation 
warnings (dealt with by: https://review.openstack.org/368392, 
https://review.openstack.org/368398, https://review.openstack.org/368400, 
https://review.openstack.org/368403, https://review.openstack.org/369091, 
https://review.openstack.org/369087 etc.)

2.   Will we be cutting an official neutron-lib for the newton release (or 
at least know that version X is the one that is being released). The reason I 
ask this is that in Mitaka there was a period when we had a number of versions 
in flight. Plugins or libraries that used constants from neutron-lib 0.2.0 
broke stable mitaka. More specifically stable/mitaka was released with 0.1.0.

3.   Neutron code is naturally moving forwards. There are some patches that 
are breaking decomposed plugins – for example 
https://review.openstack.org/364681. This is in master and the decomposed 
plugins will need to update accordingly. We just need to make sure that we have 
cut a decomposed release candidate for newton.
I am not sure if the points above are clear. But maybe for the next cycle it 
would be nice if there was a window for us to be able to close release 
candidates across the entire project.
Thanks
Gary

__
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] [infra]exception when uploading file to openstack wiki system

[joehuang]

Hello,

I am editing the wikipage of Tricircle: 
https://wiki.openstack.org/wiki/Tricircle#Cloud_Capacity_Expansion

and want to upload a picture in the wikipage, 
https://wiki.openstack.org/w/index.php?title=Special:Upload=Tricircle_usecase1.png

then exception encountered, and not able to upload any pictures

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

Exception encountered, of type "LocalFileLockError"
[42a77fc122dd851d294aba5b] /wiki/Special:Upload LocalFileLockError from line 
1928 of /srv/mediawiki/w/includes/filerepo/file/LocalFile.php: Could not 
acquire lock for 'Tricircle_usecase1.png.'
Backtrace:
#0 /srv/mediawiki/w/includes/filerepo/file/LocalFile.php(1163): 
LocalFile->lock()
#1 /srv/mediawiki/w/includes/upload/UploadBase.php(730): 
LocalFile->upload(string, string, string, integer, array, boolean, User, array)
#2 /srv/mediawiki/w/includes/specials/SpecialUpload.php(535): 
UploadBase->performUpload(string, string, boolean, User, array)
#3 /srv/mediawiki/w/includes/specials/SpecialUpload.php(206): 
SpecialUpload->processUpload()
#4 /srv/mediawiki/w/includes/specialpage/SpecialPage.php(479): 
SpecialUpload->execute(NULL)
#5 /srv/mediawiki/w/includes/specialpage/SpecialPageFactory.php(576): 
SpecialPage->run(NULL)
#6 /srv/mediawiki/w/includes/MediaWiki.php(282): 
SpecialPageFactory::executePath(Title, RequestContext)
#7 /srv/mediawiki/w/includes/MediaWiki.php(745): MediaWiki->performRequest()
#8 /srv/mediawiki/w/includes/MediaWiki.php(519): MediaWiki->main()
#9 /srv/mediawiki/w/index.php(43): MediaWiki->run()
#10 {main}

Best Regards
Chaoyi Huang(joehuang)

__
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]tempest test case for force detach volume

[joehuang]

Hello, Ken,

Thank you for your information, for APIs without tempest test cases, 
it's due to hard to build the test environment, or it's just for the API
is not mature enough? I want to know why the tempest test cases
were not added at the same time when the features were implemented.

Best Regards
Chaoyi Huang(joehuang)

From: Ken'ichi Ohmichi [ken1ohmi...@gmail.com]
Sent: 15 September 2016 2:02
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder]tempest test case for force detach volume

Hi Chaoyi,

That is a nice point.
Now Tempest have tests for some volume v2 action APIs which doesn't
contain os-force_detach.
The available APIs of tempest are two: os-set_image_metadata and
os-unset_image_metadata like
https://github.com/openstack/tempest/blob/master/tempest/services/volume/v2/json/volumes_client.py#L27
That is less than I expected by comparing the API reference.

The corresponding API tests' patches are welcome if interested in :-)

Thanks
Ken Ohmichi

---


2016-09-13 17:58 GMT-07:00 joehuang :
> Hello,
>
> Is there ant tempest test case for "os-force_detach" action to force detach
> a volume? I didn't find such a test case both in the repository
> https://github.com/openstack/cinder/tree/master/cinder/tests/tempest
> and https://github.com/openstack/tempest
>
> The API link is:
> http://developer.openstack.org/api-ref-blockstorage-v2.html#forcedetachVolume
>
> Best Regards
> Chaoyi Huang(joehuang)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[openstack-dev] [I18n] PTL Candidacy

[Ian Y. Choi]

Hello,

I am writing to announce my candidacy for I18n Ocata PTL.

I have participated in OpenStack translations into Korean
since October 2014. At the first time, I was just a Korean
translator and used Transifex, the previous translation platform.
As I got involved more and more, I have experienced and
learned a lot through the kind help from I18n members and also with
many I18n activities. I went to previous two Summits and it was so
happy to meet many I18n members, Zanata members, and Infra team members
offline. I have committed small patches into Infra, openstack-manuals,
and Stackalytics repositories for better integration with I18n.
Now I am an active translator in Korean team, and also an I18n core 
reviewer.

I am currently ranked as the third top contributor in Translations [1],
and I try to leave review comments with details in
openstack/i18n repository [2].

I18n team has become an official project since June last year [3].
Indeed, internationalizing OpenStack makes OpenStack ubiquitous
accessible to much more members all over the world. To accomplish
our team goal, we have done a lot of things including translation
platform and infrastructure with the collaboration of OpenStack teams.
On the other hand, it seems that currently there are still more things
to do with many translators, language coordinators, and also developers.
In my opinion, we need to find ways to more focus on translation qualities,
and keep better track of the change in evolving OpenStack.

I think I18n team is special because team members have different
language backgrounds and experiences. I like this diversity.
I truly believe that we can make good synergy with the diversity.

In the Ocata cycle, I would like to work with I18n members for:

* Translations are our first important aspect in I18n team.
  For better translations, more conversations and discussions
  with various I18n members are needed. Let's consider the ways
  to better communicate with language translators and coordinators.
  I would like to kindly discuss and cooperate with many members
  to share our good practices and improve OpenStack I18n Guide [4].
  Also, translation support in OpenStack I18n Guide will make our
  significant guide internationally accessible.

* Stablizing our on-going work is also important.
  For example, Stackalytics now shows Translations metric.
  However, more tunings are needed such as applying language filter,
  and showing translations on contribution report.
  Also, we need to apply appropriate ways for translators to regard
  as ATCs with an automated manner rather than registering as extra ATCs.

* Let's facilitate I18n and Inter-Project Cross-Project Liaisons [5].
  Lots of members from different project teams helped a lot.
  Since we have such nice Liaisons relationship with other project teams,
  facilitating Liaisons will be able to go for positive progress.
  For example, I really hope that Infrastructure/I18n Liaisons will
  help successfully land several on-going issues including
  translations check site and Zanata upgrade.

I would like to appreciate previous and current great help from
I18n and also many of different team members. Let's continue our effort
for OpenStack to become more universal! One more thing to mention
is that I am not fully familiar with all of aspects in I18n team.
I need help from many members even if I will be nominated for
I18n Ocata PTL. Please support and encourage me for better I18n project.


[1] http://stackalytics.com/?metric=translations
[2] http://stackalytics.com/report/contribution/i18n/90
[3] 
http://lists.openstack.org/pipermail/openstack-i18n/2015-June/001112.html

[4] http://docs.openstack.org/developer/i18n/
[5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n


With many thanks,

/Ian


__
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] [release] late rc1 release request for tripleo & puppet

[Emilien Macchi]

Hi,

This week was tough for TripleO and we had to deal with critical
problems in our CI, all resolved now.
We managed to stabilize the things and we have now a release candidate.

Please consider this late request:
https://review.openstack.org/#/c/371897/

Same request for Puppet OpenStack, we were waiting a bit more than
usual to reduce the amount of backports between now and final release:
https://review.openstack.org/#/c/371965/


Thanks a lot,
-- 
Emilien Macchi

__
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] [tripleo] focus and Newton release

[Emilien Macchi]

On Sat, Sep 17, 2016 at 12:26 AM, Emilien Macchi  wrote:
> On Fri, Sep 16, 2016 at 1:25 PM, Emilien Macchi  wrote:
>> Quick follow-up on releases.
>>
>> The team should currently focus on:
>>
>> 1) https://review.openstack.org/#/q/topic:tripleo/rc1 - features what
>> we want before tagging rc1.
>> 2) https://launchpad.net/tripleo/+milestone/newton-rc1 bugs
>
> rc1 is ready, I'll proceed to the release request this week-end.

Done: RC1 is ready: https://review.openstack.org/#/c/371897

>
>> 3) https://launchpad.net/tripleo/+milestone/newton-rc2 bugs
>> 4) Upgrade testing (patches will be backported if needed as long as
>> they are backward compatible)
>> 5) IPv6 testing (patch will be backported if needed)
>>
>> When 1) is done, I'll tag tripleo rc1 and defer all bugs to newton-rc2.
>> Another FYI: Puppet OpenStack will release RC1 next week.
>
> Let's focus on rc2 bugs now:
> https://launchpad.net/tripleo/+milestone/newton-rc2
> 4 Confirmed, 13 Triaged, 24 In Progress
>
> + ipv6 and upgrade testing.
>
> Have a great week-end everyone.
>
>> Reminder: when rc1 is created, stable/newton branch is also created,
>> so please take care of backporting your patch merged in master that
>> you think we need in stable branch.
>>
>> Thanks everyone, we're almost there! Keep going :-)
>>
>> On Wed, Sep 14, 2016 at 3:16 PM, Emilien Macchi  wrote:
>>> Folks,
>>>
>>> We're currently dealing with multiple CI issues, bug almost all
>>> blockers are under control.
>>> Until the release, the whole team should focus on what is targeted here:
>>> https://launchpad.net/tripleo/+milestone/newton-rc1
>>> https://launchpad.net/tripleo/+milestone/newton-rc2
>>>
>>> 1) Finish to land patches that are in Newton blueprints: Custom roles,
>>> Ops tools and Manila/CephFS are the top priorities at this time.
>>> 2) Work on newton bugs, critical and high. Note: everything that
>>> concerns Upgrades is critical or high, so it's very important to
>>> finish this work.
>>>
>>> Because of remaining work, we won't tag RC1 this week but wait the
>>> week of September 26. That week, we'll tag RC1 and stable/newton will
>>> be created. Hopefully by this time we solved most of our blockers and
>>> merged the last patches related to Newton features.
>>> From there, we'll have to backport bugfixes (and upgrade work) from
>>> master to stable/newton.
>>>
>>> See more details about release schedule:
>>> https://releases.openstack.org/newton/schedule.html#n-finalrc
>>>
>>> Any feedback or question is more than welcome,
>>> --
>>> Emilien Macchi
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

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

Re: [openstack-dev] [puppet] newton release - update

[Emilien Macchi]

On Fri, Sep 16, 2016 at 1:45 PM, Emilien Macchi  wrote:
> Hey,
>
> Just a quick update about our plans to release Newton rc1 and final.
> I'm preparing rc1 patches:
> https://review.openstack.org/#/q/topic:puppet/9.3.0
> Feel free to review.
>
> We'll likely release next week and then we'll have stable/newton
> branches. From there, only bugfixes can be backported. So let us know
> if there is anything you want merged asap.
> We'll release final Newton on October 3 at maximum.

RC1 is proposed: https://review.openstack.org/#/c/371965/

> Regarding puppet-ceph, I propose we don't branch stable/jewel, as
> jewel is still the ongoing release AFIK. Though I'm proposing a tag to
> make a release:
> https://review.openstack.org/#/c/371719/
> Consider this release stable if you plan to deploy Ceph Jewel.
>
> Any question, feedback, is highly welcome.
>
> Enjoy the week-end!
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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][ptl][election] PTL candidacy

[Will Zhou]

+1.
On Sat, 17 Sep 2016 at 13:44 Steve Martinelli 
wrote:

> Hey everyone,
>
> I'd like to continue to serve as the PTL of the keystone project for the
> Ocata release. I served as PTL of the keystone project for the Mitaka and
> Newton development cycles. I find the role to be extremely rewarding, and
> would be honoured to continue to serve in the same capacity, if you'll have
> me.
>
> During the Mitaka development cycle we accomplished many blueprints and
> hit some important goals, here are a few off the top of my head:
>
>   - Python 3 compatibility (for unit tests)
>   - Credential encryption
>   - PCI support for passwords
>   - Running migration tests on non-sqlite backends
>   - API docs are migrated and fully updated
>   - Introduced the `keystone doctor` helper
>
> For the Ocata release I'd like to take advantage the short development
> cycle to aggressively pay down some of the technical debt we've accumulated
> and also improve user and operator experience. I'd like to limit new
> features to a minimum (maybe 3-5) my short list is the following:
>
>   - Multi Factor Auth (MFA) support
>   - Improving the federated identity mapping engine
>   - Tackle the issue with long running operations timing out
>   - Handle federated authentication without apache libraries
>   - Functional tests with non-standard deployments (ldap, federated
> identity)
>
> With the exception of MFA support, all the features listed above match the
> theme of paying down technical debt or improving user experience.
>
> From a non-technical perspective, I'd like to do the following:
>
>   - Improve communication and engagement with our direct downstream
> consumers (OSA, tripleo, etc)
>   - Continue to work with operators. Create specifications based on real
> world use cases that are driven by operators facing issues with
> performance, usability, scalability, and upgrades.
>   - Appoint a bug czar or perform weekly bug triages and monthly bug
> squashes
>
> Lastly, I'd like to thank anyone that contributed to keystone during the
> Newton release. I'm very excited for what Ocata will bring and look forward
> to working on it in any capacity.
>
> Thanks for reading,
> stevemar
>
> Link to the election repo change: https://review.openstack.org/#/c/371899/
>
> __
> 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
>
-- 

-
​
周正喜
Mobile: 13701280947
​WeChat: 472174291
__
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] Adding ihrachys to the neutron-drivers team

[Henry Gessau]

+1000!

Armando M.  wrote:
> Hi folks,
> 
> I would like to propose Ihar to become a member of the Neutron drivers team 
> [1].
> 
> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
> stable core, downstream package whisperer, release and oslo liaison (I am sure
> I am forgetting some other capacity he is in) is going to put him at great
> comfort in the newly appointed role, and help him grow and become wise even
> further.
> 
> Even though we have not been meeting regularly lately we will resume our
> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> beneficial. 
> 
> Please, join me in welcome Ihar to the team.
> 
> Cheers,
> Armando 
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> 
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> 


__
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] Adding ihrachys to the neutron-drivers team

[Carl Baldwin]

Welcome, Ihar! It will be great to have you on the drivers team.

Carl

On Sat, Sep 17, 2016 at 10:40 AM, Armando M.  wrote:

> Hi folks,
>
> I would like to propose Ihar to become a member of the Neutron drivers
> team [1].
>
> Ihar wide knowledge of the Neutron codebase, and his longstanding duties
> as stable core, downstream package whisperer, release and oslo liaison (I
> am sure I am forgetting some other capacity he is in) is going to put him
> at great comfort in the newly appointed role, and help him grow and become
> wise even further.
>
> Even though we have not been meeting regularly lately we will resume our
> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> beneficial.
>
> Please, join me in welcome Ihar to the team.
>
> Cheers,
> Armando
>
> [1] http://docs.openstack.org/developer/neutron/policies/neutron-teams
> .html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][astara][cloudkitty][dragonflow][i18n][karbor][openstack_ux][openstacksalt][security][senlin][elections] Last hours for PTL candidate announcements

[Tony Breeds]

A quick reminder that we are in the last hours for PTL candidate announcements.

If you want to stand for PTL, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your candidacy have been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:
---
Nominations started   @ 2016-09-12 00:00:00 UTC
Nominations end   @ 2016-09-18 23:45:00 UTC
Nominations duration  : 6 days, 23:45:00
Nominations remaining : 23:54:55
Nominations progress  :  85.74%
---
Projects  :59
Projects with candidates  :50 ( 84.75%)
Projects with election: 3 (  5.08%)
===
Stats gathered@ 2016-09-17 23:50:05 UTC
Projects without candidates[2]
Astara
Cloudkitty
Dragonflow
I18n
Karbor
OpenStack_UX
OpenStackSalt
Security
Senlin


This means that with approximately 1 day left more than 15% of projects will be 
deemed
leaderless.  In this case the TC will be bound by [3].

Thank you,
Tony.

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] Assuming the open reviews below are validated
   https://review.openstack.org/#/q/is:open+project:openstack/election
[3] 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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] [Neutron] Adding ihrachys to the neutron-drivers team

[Assaf Muller]

Well deserved is an understatement! Ihar is consistently integral to
the Neutron project. Ihar has wide knowledge not only of Neutron but
of OpenStack workings and is a key factor to Neutron playing nice with
other projects. Ihar has shown consistent good judgement of priorities
and will in no doubt strengthen the drivers team.

On Sat, Sep 17, 2016 at 1:19 PM, Dariusz Śmigiel
 wrote:
> Congrats Ihar. You deserve this!
>
> 2016-09-17 18:40 GMT+02:00 Armando M. :
>> Hi folks,
>>
>> I would like to propose Ihar to become a member of the Neutron drivers team
>> [1].
>>
>> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
>> stable core, downstream package whisperer, release and oslo liaison (I am
>> sure I am forgetting some other capacity he is in) is going to put him at
>> great comfort in the newly appointed role, and help him grow and become wise
>> even further.
>>
>> Even though we have not been meeting regularly lately we will resume our
>> Thursday meetings soon [2], and having Ihar onboard by then will be highly
>> beneficial.
>>
>> Please, join me in welcome Ihar to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>> __
>> 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
>>
>
>
>
> --
> Darek "dasm" Śmigiel
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [tacker] PTL candidacy

[Janki Chhatbar]

+1

On 17-Sep-2016 10:30 am, "Trinath Somanchi" 
wrote:

> +1
> --
> *From:* Sridhar Ramaswamy 
> *Sent:* Saturday, September 17, 2016 3:40:18 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [tacker] PTL candidacy
>
> Hi Tackers,
>
> I would like to announce my candidacy to continue as Tacker PTL for the
> Ocata
> dev cycle.
>
> I'm a member of the Tacker community right from its Neutron ServiceVM days.
> I actively participated in its transition into NFV Orchestration area and
> its
> graduation into big-tent. Since becoming an official project our developer
> community has grown and has more diverse [1].
>
> Newton was a packed cycle for us with many stellar achievements from the
> community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
> Networking-SFC (we are almost there!) and External Alarm-based Monitoring
> using Ceilometer. As usual tons of refactoring work happened to continue
> to shed the "Neutronisms" in the project.
>
> Along the way, we have become a better openstack citizen following best
> practices like Reno release-notes, better release processes, and better
> python3 support. We also expanded our core-team with three new members.
>
> My vision for Tacker Ocata is along the following workstreams identified
> in the recent weekly meeting.
>
> * Decomposed VIM drivers:
> We need to enable a healthy ecosystem of VIM drivers beyond the current
> default openstack VIM driver. Our user community has mixed hypervisor/cloud
> technology in their deployments - with some existing pre-openstack systems
> (a.la, VMware), some OpenStack based clouds, and, forward looking into
> Containers and public clouds. All this needs an easy to add VIM driver to
> bolt underneath Tacker. Luckily our architecture is designed with this in
> mind right from day one. We just need to make it easy (a) for developers to
> bring in new VIM drivers and (b) for deployers to quickly add new VIM
> capabilities without requiring a fork-lift upgrade of Tacker for every new
> VIM type.
>
> As part of this workstream, I'd work towards bringing in a Container VIM
> type interfacing with Magnum / Zun.
>
> Lifecycle Features:
> * Finish left over Newton features - VNFC and NSD
> * Better integration with external EM / FCAPS systems
> * Enable support for VNFs leveraging Neutron's latest VLAN aware VM
> feature
>
> Project maintenance:
>  * Doc: API reference guide
>  * Pecan API framework
>  * OSC support
>  * Finish python3x TC goal
>
> Tons of fun things to do! However, Ocata is going to be a short cycle.
> So, over next few weeks, I'll help to continue to groom these topics and
> zoom in on those that are implementable in one dev cycle and clearly
> identify some tracks that would carry over to the next cycle.
>
> In Ocata, given an opportunity to serve as your PTL, I'll continue my role
> as the "chief enabler" for this amazing community of developers that I'm so
> proud to lead over the last two cycles.
>
> - Sridhar Ramaswamy (irc: sridhar_ram)
>
> [1] http://stackalytics.com/?module=tacker-group=commits
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] PTL candidacy

[Joshua Harlow]

Howdy folks,

I'd like to run again (before passing the baton) for the PTL of Oslo,

I would like to help out as much as I am able and continue pushing and 
making Oslo be the best it can be during the Ocata release. I have 
probably not done as best as I could during this Newton cycle (due to 
various job movements and such) but I am hoping to help out and improve 
and guide folks during this next cycle.


Thanks for considering myself (and a shout out to the rest of the Oslo 
folks and contributors who keep on chugging forward with the supporting 
foundation of many many projects, inside and outside OpenStack).


P.S.

Election repo review @ https://review.openstack.org/371979

-Josh

__
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] [band] OpenStack Summit - Barcelona - musicians please raise your hands

[Colette Alexander]

On Sat, Sep 17, 2016 at 1:35 PM, Amrith Kumar  wrote:
> So, would y'all musicians who plan to bring your gear to Barcelona please 
> start a little thread here on the ML and let's get a band going?

I would totally bring my gear if my cello didn't need its own plane seat!

If someone in Spain has a cello though, I will totally play.

-colette/gothicmindfood

__
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] [kolla][release] Branching of stable/newton

[Steven Dake (stdake)]

Release team,

At one point Doug had indicated all projects would automatically branch on 
tagging of rc1.  I notice in git no Kolla stable/newton branch exists. Fwiw 
this is actually a good thing, because 33 patches have merged since rc1 
relating to things that need to go into Newton, dramatically reducing the 
amount of backport work we need to do.  Part of this was error on my part – not 
validating all FFE blueprints that were marked Implemented were actually 
implemented.  One related to monitoring (and part of the 33 patches since rc1) 
was actually “Needs Review” rather than Implemented (as it was marked).

I don’t want Kolla to be a special snowflake wrt release processes, and we can 
live with a branch on rc1.  A branch on rc2 would be far better for us as we 
have roughly 250 bugs to triage or fix.  I leave it in the release team’s 
capable judgement to decide best on a course of action.

I would request that the expected time of branch be communicated clearly to us 
for the Newton cycle.  I have been communicating with our team that rc1 is 
where we branch.  Folks are now asking “where is the Newton branch of Kolla?”

Thanks!
-steve
__
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] [band] OpenStack Summit - Barcelona - musicians please raise your hands

[Amrith Kumar]

I had a chat with an openstack newbie on Thursday who has never posted a 
message on the mailing list.

He's a musician and will be at summit in Barcelona, and I happened to mention 
that there were a bunch of other musicians who bring their gear along, and have 
a good time.

I told him to post to the ML and try and muster up a band, he writes rap and I 
proposed that he write a rap song about OpenStack (as long as he said nice 
things about Trove).

OK, ... long story short, he didn't want his first post to the ML to be about 
music at the summit, but I have no such inhibitions.

So, would y'all musicians who plan to bring your gear to Barcelona please start 
a little thread here on the ML and let's get a band going? 

Please ...

-amrith

P.S. I'm not a musician. I don't play one on TV. I just hang out ...

__
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] Adding ihrachys to the neutron-drivers team

[Dariusz Śmigiel]

Congrats Ihar. You deserve this!

2016-09-17 18:40 GMT+02:00 Armando M. :
> Hi folks,
>
> I would like to propose Ihar to become a member of the Neutron drivers team
> [1].
>
> Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
> stable core, downstream package whisperer, release and oslo liaison (I am
> sure I am forgetting some other capacity he is in) is going to put him at
> great comfort in the newly appointed role, and help him grow and become wise
> even further.
>
> Even though we have not been meeting regularly lately we will resume our
> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> beneficial.
>
> Please, join me in welcome Ihar to the team.
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>
> __
> 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
>



-- 
Darek "dasm" Śmigiel


Q: Why is this email five sentences or less?
A: http://five.sentenc.es

__
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] [Neutron] Adding ihrachys to the neutron-drivers team

[Armando M.]

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team
[1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
stable core, downstream package whisperer, release and oslo liaison (I am
sure I am forgetting some other capacity he is in) is going to put him at
great comfort in the newly appointed role, and help him grow and become
wise even further.

Even though we have not been meeting regularly lately we will resume our
Thursday meetings soon [2], and having Ihar onboard by then will be highly
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#
drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
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] [mistral][ptl] PTL candidacy

[Renat Akhmerov]

I'm Renat Akhmerov. I would like to announce my candidacy for being a PTL of
Mistral Workflow Service in Ocata cycle.

I think Mistral now is a pretty mature project which provides really useful
and cool capabilities. The project now is moving into the phase when technical
perfection should be the number one priority. In many case Mistral serves as
one of the central infrastructural components. To be able to build production
ready solutions on top of Mistral it needs to be reliable, demonstrate
excellent performance, provide good usability and comprehensive documentation.

Here are my priorities for Ocata cycle:

* Performance. In Newton cycle we made Mistral work about 30 times faster.
  Now it's able to complete a workflow consisting of hundreds of tasks with
  highly parallel structure and lots of join operations during tens of
  seconds or less depending on workflow actions. That's not all, there's
  still a potential to do even better and also improve Mistral when dealing
  with parallel loads.
* Scaling. Although it's now possible to scale Mistral engine tier we still
  need to improve when having a high load.
* Extensibility. We started working on Custom Action API which will allow
  writing custom Mistral actions in a more flexible, elegant and powerful
  way. We're planning to finish this work in Ocata cycle.
* Usability and documentation. There are some gaps in Mistral documentation.
  User experience, especially CLI, also needs to be improved. We finally
  started gathering ideas for new CLI and API versions in Newton cycle.
* Building even more robust and diverse community.

I'd like to welcome everyone who wants to help with Mistral development.
We'll provide all necessary assistance.

Here’s a link to the patch with the description of my candidacy:
https://review.openstack.org/#/c/371943 


Renat Akhmerov
@Nokia

__
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] [diskimage-builder] Stepping down as diskimage-builder core

[Clint Byrum]

It's been my honor to be included with the core reviewer group on
diskimage-builder, but my focus has changed quite a bit and I'm not
able to keep up with the review load. As a result, I've lost most of
the context and struggle to understand patches enough to +2 them.

Given that, I'm laying down my +2 in diskimage-builder.

__
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] [Fuel] [ptl] Announcing my candidacy for Fuel PTL in the Ocala cycle

[Alexey Shtokolov]

Fuelers,

I would like to announce my candidacy for Fuel PTL in the Ocata cycle.


** Introduction **

First of all, allow me to introduce myself. I joined the OpenStack Community
during the Juno release cycle. I started on a "consumer" side - as a Head of
IT at a media holding I was consuming and bringing Open Source technologies
to an "Enterprise world" as much as it was possible and OpenStack was there
as well. I had been investigating OpenStack and finally deployed my first
private cloud manually. It was Juno 2014.2 and it was a very-very long trip.
Half a year later I found out that Fuel could do it much more faster! I
liked
Fuel mission, both stated and delivered - make OpenStack installation
process
easier and more streamlined. OpenStack was in a serious need of such a tool,
as one of prerequisites for lowering adoption barriers.

Finally, I joined Fuel Community as a deployment engineer. Since 2015 I've
been an active contributor in the very core features of Fuel and have been
leading a Fuel development team [0] at Mirantis. If you're using or
developing
Fuel - you’ve probably heard of some of the features that we designed and
implemented:
Task-based deployment engine [1], Post-deployment plugins installation,
Deployment History [2][3], Data-driven orchestration [4] with Unlocked
Settings and Network tabs [5] (aka Fuel LCM), Custom graphs execution [6],
Release-as-a-Plugin [7] and Everything-as-a-Graph [8].

As you can see, the main goal of this work was to make Fuel more flexible
and
friendly for deployment engineers, based on my and my colleagues’ experience
from real OpenStack deployments. And I would like to keep doing it
as a Fuel PTL.


** Community **

Fuel, as a part of OpenStack BigTent since November 17 2015, had the first
design summit at Austin. Vladimir Kozhukalov did a great job organizing it.
This summit allowed Fuel community to solicit a feedback, to align our goals
with OpenStack community and, the most important, to start having an open
design. Open Design was the last of four Opens [9] to be achieved by Fuel
Community. Unfortunately during the Newton release cycle not all discussions
and decisions were open and public enough. We need to avoid such behaviour
in future. Fuel Community will have a very modest representation during
upcoming Fuel Ocata Design summit at Barcelona and the first Project Teams
Gathering [10] And that’s the reason to make our goal #1: the expansion of
the OpenStack Community involvement into Fuel design during the whole
release
cycle. And as a result encourage new contributors, build a healthy community
around Fuel and achieve the contribution diversity.


** Technical challenges **

October 2015 Fuel was the 5th deployment tool for OpenStack with 12% [11]
but April 2016 Fuel got the 3rd place with 19% [12] right after Puppet and
Ansible. While SaltStack, Chef and Puppet are visibly going down Fuel is
taking over the OpenStack deployment world. But we still have a set of
technical challenges and we must focus on:

* Infrastructure-as-Code (IaC) allows us to provide convenient and familiar
UX
for those user who have experience with dynamic infrastructure in Public
clouds - it's now easy to control OpenStack configuration and versioning via
git. Since nailgun extension for IaC [13] became a part of Fuel project [14]
we should actively support and develop it.

* Lifecycle management. Making changes on already installed clouds is still
complicated. We’ve done a lot of work in this direction, but we are still
not
there.

* The Upgrades of Fuel itself and OpenStack clusters managed by Fuel still
need more flexibility and much better UX. We can fix it using the custom
graphs concept [8].

* Fuel extensions and plugins framework should be polished and provide
itself
with stable API. Moreover extensions and plugins SDK should become
developer-friendly and support all new features like release-as-a-plugin
[7].

* Single Fuel Master node should support multiple different OpenStack
releases.
First step [7] was done. Let’s keep moving.

* Audit, troubleshooting and debugging became easier with Deployment History
features and dry-run/noop deployments but we are still facing with the
inconsistent error reporting and diagnostic snapshots. We can improve it
using
graphs.

* Documentation team has done a great job of restructuring Fuel
documentation
and moving it under OpenStack Doc space. However, as subject matter experts,
we need to proactively review and help the doc team with updates and new
features documentation [15]


** Afterword **

As an epilogue I would like to say: Working closely with OpenStack Community
I see that PTL is more about how to help people come together and achieve
goals, how to built horizontal communications between project teams and how
to keep developers in their zone of maximum performance.

Fuel is a mature project with existing strong development team. And we
should
keep these things in place.

WBR, Alexey Shtokolov
irc: ashtokolov

[0]