[openstack-dev] 答复: [Senlin] Proposing Liyi as core reviewer

[liu.xuefeng1]

+1

Weclome, liyi. 






原始邮件



发件人： 
收件人： 
日 期 ：2017年08月16日 12:57
主 题 ：[openstack-dev] [Senlin] Proposing Liyi as core reviewer





Dear Senlin cores,

As you might have witnessed, Liyi has been a solid contributor to Senlin
during Pike cycle. His patches are of high quality, showing that he has
a good grasp of the design and the code. Based on the contribution
record and his agreement to work with the team more closely, I'm
proposing adding him to the core team.

Please reply this email if there are concerns or comments.

Happy coding!

- Qiming


__
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] [Senlin] Proposing Liyi as core reviewer

[YUAN RUIJIE]

Congrats Liyi.

+2 from me :)

2017-08-16 12:50 GMT+08:00 Qiming Teng :

> Dear Senlin cores,
>
> As you might have witnessed, Liyi has been a solid contributor to Senlin
> during Pike cycle. His patches are of high quality, showing that he has
> a good grasp of the design and the code. Based on the contribution
> record and his agreement to work with the team more closely, I'm
> proposing adding him to the core team.
>
> Please reply this email if there are concerns or comments.
>
> Happy coding!
>
> - Qiming
>
>
> __
> 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] [Senlin] Proposing Liyi as core reviewer

[Qiming Teng]

Dear Senlin cores,

As you might have witnessed, Liyi has been a solid contributor to Senlin
during Pike cycle. His patches are of high quality, showing that he has
a good grasp of the design and the code. Based on the contribution
record and his agreement to work with the team more closely, I'm
proposing adding him to the core team.

Please reply this email if there are concerns or comments.

Happy coding!

- Qiming


__
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] [acceleration] a basic workflow of Cyborg

[朱力]

Hi Team,

I have proposed a patch https://review.openstack.org/#/c/492134/, which
pulls together the api,conductor,db processes to implement a basic workflow
please help review the patch :)


Hi jkilpatr,

I think you can start your automated deployment work above it


best.
__
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] critical situation with CI / upgrade jobs

[Wesley Hayutin]

On Tue, Aug 15, 2017 at 9:33 PM, Emilien Macchi  wrote:

> So far, we're having 3 critical issues, that we all need to address as
> soon as we can.
>
> Problem #1: Upgrade jobs timeout from Newton to Ocata
> https://bugs.launchpad.net/tripleo/+bug/1702955
> Today I spent an hour to look at it and here's what I've found so far:
> depending on which public cloud we're running the TripleO CI jobs, it
> timeouts or not.
> Here's an example of Heat resources that run in our CI:
> https://www.diffchecker.com/VTXkNFuk
> On the left, resources on a job that failed (running on internap) and
> on the right (running on citycloud) it worked.
> I've been through all upgrade steps and I haven't seen specific tasks
> that take more time here or here, but some little changes that make
> the big change at the end (so hard to debug).
> Note: both jobs use AFS mirrors.
> Help on that front would be very welcome.
>
>
> Problem #2: from Ocata to Pike (containerized) missing container upload
> step
> https://bugs.launchpad.net/tripleo/+bug/1710938
> Wes has a patch (thanks!) that is currently in the gate:
> https://review.openstack.org/#/c/493972
> Thanks to that work, we managed to find the problem #3.
>
>
> Problem #3: from Ocata to Pike: all container images are
> uploaded/specified, even for services not deployed
> https://bugs.launchpad.net/tripleo/+bug/1710992
> The CI jobs are timeouting during the upgrade process because
> downloading + uploading _all_ containers in local cache takes more
> than 20 minutes.
> So this is where we are now, upgrade jobs timeout on that. Steve Baker
> is currently looking at it but we'll probably offer some help.
>
>
> Solutions:
> - for stable/ocata: make upgrade jobs non-voting
> - for pike: keep upgrade jobs non-voting and release without upgrade
> testing
>
> Risks:
> - for stable/ocata: it's highly possible to inject regression if jobs
> aren't voting anymore.
> - for pike: the quality of the release won't be good enough in term of
> CI coverage comparing to Ocata.
>
> Mitigations:
> - for stable/ocata: make jobs non-voting and enforce our
> core-reviewers to pay double attention on what is landed. It should be
> temporary until we manage to fix the CI jobs.
> - for master: release RC1 without upgrade jobs and make progress
> - Run TripleO upgrade scenarios as third party CI in RDO Cloud or
> somewhere with resources and without timeout constraints.
>
> I would like some feedback on the proposal so we can move forward this
> week,
> Thanks.
> --
> Emilien Macchi
>

I think due to some of the limitations with run times upstream we may need
to rethink the workflow with upgrade tests upstream. It's not very clear to
me what can be done with the multinode nodepool jobs outside of what is
already being done.  I think we do have some choices with ovb jobs.   I'm
not going to try and solve in this email but rethinking how we CI upgrades
in the upstream infrastructure should be a focus for the Queens PTG.  We
will need to focus on bringing run times significantly down as it's
incredibly difficult to run two installs in 175 minutes across all the
upstream cloud providers.

Thanks Emilien for all the work you have done around upgrades!



>
> __
> 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] [Octavia]Questions about octavia flavors spec

[何庆]

Hi, I'm trying to figure out how the flavor will be implemented and have
few questions about the flavor spec[1]

1. What does "*RO*" mean in API* /flavors*? Is it short for ReadOnly?
In my understanding, user need create flavor by himself, so the flavor API
should not be readonly.

FLAVOR(/flavors)

+-+---+-+-++-+
|Attribute|Type   |Access   |Default  |Validation/ |Description  |
|Name |   | |Value|Conversion  | |
+=+===+=+=++=+
|id   |string |RO, admin|generated|N/A |identity |
| |(UUID) | | || |
+-+---+-+-++-+
|name |string |RO, admin|''   |string  |human-readable   |
| |   | | ||name |
+-+---+-+-++-+
|description  |string |RO, admin|''   |string  |human-readable   |
| |   | | ||description  |
+-+---+-+-++-+
|enabled  |bool   |RO, admin|true |bool|toggle   |
| |   | | || |
+-+---+-+-++-+
|flavor_profile_id|string |RO, admin| |string  |human-readable   |
| |   | | ||flavor_profile_id|
+-+---+-+-++-+

2. Do we also need an API like */providers* to query providers and metadata
available？



[1] https://review.openstack.org/#/c/392485/
__
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] [keystone] office hours report 2017-08-15

[Lance Bragstad]

Hey all,

Office hours was pretty focused today. We spent the majority of the time
discussing and merging fixes we need for RC2. In addition to that we
discussed plans for the PTG as well as the schedule. Full details can be
found in the logs [0].

Thanks,

Lance


[0]
http://eavesdrop.openstack.org/meetings/keystone_office_hours/2017/keystone_office_hours.2017-08-15-18.57.log.html




signature.asc
Description: OpenPGP digital 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] [tripleo] critical situation with CI / upgrade jobs

[Emilien Macchi]

So far, we're having 3 critical issues, that we all need to address as
soon as we can.

Problem #1: Upgrade jobs timeout from Newton to Ocata
https://bugs.launchpad.net/tripleo/+bug/1702955
Today I spent an hour to look at it and here's what I've found so far:
depending on which public cloud we're running the TripleO CI jobs, it
timeouts or not.
Here's an example of Heat resources that run in our CI:
https://www.diffchecker.com/VTXkNFuk
On the left, resources on a job that failed (running on internap) and
on the right (running on citycloud) it worked.
I've been through all upgrade steps and I haven't seen specific tasks
that take more time here or here, but some little changes that make
the big change at the end (so hard to debug).
Note: both jobs use AFS mirrors.
Help on that front would be very welcome.


Problem #2: from Ocata to Pike (containerized) missing container upload step
https://bugs.launchpad.net/tripleo/+bug/1710938
Wes has a patch (thanks!) that is currently in the gate:
https://review.openstack.org/#/c/493972
Thanks to that work, we managed to find the problem #3.


Problem #3: from Ocata to Pike: all container images are
uploaded/specified, even for services not deployed
https://bugs.launchpad.net/tripleo/+bug/1710992
The CI jobs are timeouting during the upgrade process because
downloading + uploading _all_ containers in local cache takes more
than 20 minutes.
So this is where we are now, upgrade jobs timeout on that. Steve Baker
is currently looking at it but we'll probably offer some help.


Solutions:
- for stable/ocata: make upgrade jobs non-voting
- for pike: keep upgrade jobs non-voting and release without upgrade testing

Risks:
- for stable/ocata: it's highly possible to inject regression if jobs
aren't voting anymore.
- for pike: the quality of the release won't be good enough in term of
CI coverage comparing to Ocata.

Mitigations:
- for stable/ocata: make jobs non-voting and enforce our
core-reviewers to pay double attention on what is landed. It should be
temporary until we manage to fix the CI jobs.
- for master: release RC1 without upgrade jobs and make progress
- Run TripleO upgrade scenarios as third party CI in RDO Cloud or
somewhere with resources and without timeout constraints.

I would like some feedback on the proposal so we can move forward this week,
Thanks.
-- 
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] Proposal to require bugs for tech debt

[Emilien Macchi]

On Tue, Aug 15, 2017 at 5:46 PM, Alex Schultz  wrote:
> Hey folks,
>
> I'm proposing that in order to track tech debt that we're adding in as
> part of development that we create a way to track these items and not
> approve them without a bug (and a reference to said bug)[0].  Please
> take a moment to review the proposed policy and comment. I would like
> to start this for the queens cycle.

I also think we should frequently review the status of these bugs.
Maybe unofficially from time to time and officially during milestone-3
of each cycle.

I like the proposal so far, thanks.

> A real world example of where this would beneficial would be the
> workaround we had for buggy ssh[1]. This patch was merged 6 months ago
> to work around an issue in ssh that was recently fixed. However we
> would most likely never have remembered to revert this. It was only
> because someone[2] spotted it and mentioned it that it is being
> reverted now.
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/494044/
> [1] 
> https://review.openstack.org/#/q/6e8e27488da31b3b282fe1ce5e07939b3fa11b2f,n,z
> [2] Thanks pabelanger
>
> __
> 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



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

[openstack-dev] [tripleo] Proposal to require bugs for tech debt

[Alex Schultz]

Hey folks,

I'm proposing that in order to track tech debt that we're adding in as
part of development that we create a way to track these items and not
approve them without a bug (and a reference to said bug)[0].  Please
take a moment to review the proposed policy and comment. I would like
to start this for the queens cycle.

A real world example of where this would beneficial would be the
workaround we had for buggy ssh[1]. This patch was merged 6 months ago
to work around an issue in ssh that was recently fixed. However we
would most likely never have remembered to revert this. It was only
because someone[2] spotted it and mentioned it that it is being
reverted now.

Thanks,
-Alex

[0] https://review.openstack.org/#/c/494044/
[1] 
https://review.openstack.org/#/q/6e8e27488da31b3b282fe1ce5e07939b3fa11b2f,n,z
[2] Thanks pabelanger

__
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] Declaring explicit minimum database versions

[Anita Kuno]

On 2017-08-15 11:59 AM, Monty Taylor wrote:

stabbing himself in the eyes yesterday


I find it interesting that I was just about to read this article: 
https://www.thestar.com/opinion/commentary/2017/08/15/boys-and-men-must-do-the-right-thing-it-will-save-female-lives.html 
when I noticed Monty posted and wanted to read what he had to say.


I still wonder what it will take for leaders in this tech community to 
hold themselves to some sort of account when deciding what language to 
use in work situations.


I am not of the opinion that Monty was advocating violence towards 
anyone. But I do feel the article makes a strong point in that language 
choice matters and normalizing violence is unhealthy if we want to reach 
our stated goals of beneficial gender interactions, including those 
where gender is not front of mind in the interaction.


As for the issue of databases, I hope for Morgan's wellbeing a solution 
can be found.


Thank you,
Anita.

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

Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

[Amrith Kumar]

Tim,

This is an idea that was discussed at a trove midcycle a long time back
(Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but
was quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others
want to add topics to that list, the etherpad is at
https://etherpad.openstack.org/p/trove-queens-ptg​

Thanks!

-amrith



On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell  wrote:

> One idea I found interesting from the past discussion was the approach
> that the user need is a database with a connection string.
>
>
>
> How feasible is the approach where we are provisioning access to a
> multi-tenant database infrastructure rather than deploying a VM with
> storage and installing a database?
>
>
>
> This would make the service delivery (monitoring, backup, upgrades) in the
> responsibility of the cloud provider rather than the end user. Some
> quota/telemetry would be needed to allocate costs to the project.
>
>
>
> Tim
>
>
>
> *From: *Amrith Kumar 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, 15 August 2017 at 17:44
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [trove][tc][all] Trove restart - next steps
>
>
>
> Now that we have successfully navigated the Pike release and branched
> the tree, I would like to restart the conversation about how to revive
> and restart the Trove project.
>
> Feedback from the last go around on this subject[1] resulted in a
> lively discussion which I summarized in [2]. The very quick summary is
> this, there is interest in Trove, there is a strong desire to maintain
> a migration path, there is much that remains to be done to get there.
>
> What didn't come out of the email discussion was any concrete and
> tangible uptick in the participation in the project, promises
> notwithstanding.
>
> There have however been some new contributors who have been submitting
> patches and to help channel their efforts, and any additional
> assistance that we may receive, I have created the (below) list of
> priorities for the project. These will also be the subject of
> discussion at the PTG in Denver.
>
>- Fix the gate
>
>- Update currently failing jobs, create xenial based images
>- Fix gate jobs that have gone stale (non-voting, no one paying
>  attention)
>
>- Bug triage
>
>- Bugs in launchpad are really out of date, assignments to
>  people who are no longer active, bugs that are really support
>  requests, etc.,
>- Prioritize fixes for Queens and beyond
>
>- Get more active reviewers
>
>- There seems to still be a belief that 'contributing' means
>  'fixing bugs'. There is much more value in actually doing
>  reviews.
>- Get at least a three member active core review team by the
>  end of the year.
>
>- Complete Python 3 support
>
>   - Currently not complete; especially on the guest side
>
>- Community Goal, migrate to oslo.policy
>
>- Anything related to new features
>
> This is clearly an opinionated list, and is open to change but I'd
> like to do that based on the Agile 'stand up' meeting rules. You know, the
> chicken and pigs thing :)
>
> So, if you'd like to get on board, offer suggestions to change this
> list, and then go on to actually implement those changes, c'mon over.
>
> -amrith
>
>
>
> [1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
> [2] http://markmail.org/message/gfqext34xh5y37ir
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Adding Kristi Nikolla to keystone-core

[Rodrigo Duarte]

Congrats Kristi! Well deserved.

On Tue, Aug 15, 2017 at 4:54 PM, Davanum Srinivas  wrote:

> Go Kristi!
>
> On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad 
> wrote:
> > I made the announcement in today's keystone meeting [0] that the current
> > reviewers have decided to add Kristi Nikolla (knikolla) to the team.
> >
> > Kristi has been an extremely valuable asset to the team over the last
> > couple of releases. He especially stepped up to the plate during Pike.
> > He provides consistent and valuable feedback on reviews, actively
> > participates in discussions about the project's future, and takes
> > initiative when something needs to get done. In addition to that, he's
> > been great about helping folks out in the channel and getting our Pike
> > release candidate out the door.
> >
> > I'm excited to add Kristi to the keystone core group and I look forward
> > to seeing him make positive changes. Thanks for all the dedication and
> > hard work, Kristi!
> >
> > [0]
> > http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-08-15-18.00.log.html#l-130
> >
> >
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



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

[openstack-dev] [tacker] vim fernet keys HA deployment

[Eduardo Gonzalez]

Hi,

While deploying master multinode realized vim fernet keys are created
locally only in one node unless barbican is used. This causes only be able
to run one tacker-server service simultaneously.

Question: Is there a method in tacker to make HA multinode without barbican
and without shared storage for vim fernet directory.

This is similar to a glance deployment with file based backend.

Regards
__
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] Adding Kristi Nikolla to keystone-core

[Davanum Srinivas]

Go Kristi!

On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad  wrote:
> I made the announcement in today's keystone meeting [0] that the current
> reviewers have decided to add Kristi Nikolla (knikolla) to the team.
>
> Kristi has been an extremely valuable asset to the team over the last
> couple of releases. He especially stepped up to the plate during Pike.
> He provides consistent and valuable feedback on reviews, actively
> participates in discussions about the project's future, and takes
> initiative when something needs to get done. In addition to that, he's
> been great about helping folks out in the channel and getting our Pike
> release candidate out the door.
>
> I'm excited to add Kristi to the keystone core group and I look forward
> to seeing him make positive changes. Thanks for all the dedication and
> hard work, Kristi!
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-08-15-18.00.log.html#l-130
>
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [kolla-kubernetes] Proposing Rich Wellum to core team

[Steve Wilkerson]

+1 from me as well.  Great job Rich :D

On Fri, Aug 11, 2017 at 11:01 AM, Michał Jastrzębski  wrote:
> Hello,
>
> It's my pleasure to start another core team vote. This time for our
> colleague rwellum. I propose that he joins kolla-kubernetes team.
>
> This is my +1 vote. Every kolla-kubernetes core has a vote and it can
> be veto'ed.
>
> Voting will last 2 weeks and will end at 25th of August.
>
> Cheers,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to core team

[Pete Birley]

Would be great to have Rich, an enthusiastic +1 from me :)

On Sat, Aug 12, 2017 at 11:38 AM, Serguei Bezverkhi (sbezverk) <
sbezv...@cisco.com> wrote:

> +1
>
> well deserved
>
> Serguei
>
> *From: *"Vikram Hosakote (vhosakot)" 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, August 11, 2017 at 7:31 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla-kubernetes] Proposing Rich Wellum
> to core team
>
>
>
> Rich? Well, um ;)
>
>
>
> Although I’m not a kolla-kubernetes core and my vote does not matter at
> all, I’ll still give
>
> my +1 to Rich J.
>
>
>
> Amazing work in kolla-kubernetes Rich especially your recent contribution
> of the Python
>
> tool to automate the deployment of kolla-kubernetes.
>
>
>
> https://review.openstack.org/#/c/487972/
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC: vhosakot
>
>
>
> *From: *Michał Jastrzębski 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, August 11, 2017 at 12:01 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [kolla-kubernetes] Proposing Rich Wellum to
> core team
>
>
>
> Hello,
>
>
>
> It's my pleasure to start another core team vote. This time for our
>
> colleague rwellum. I propose that he joins kolla-kubernetes team.
>
>
>
> This is my +1 vote. Every kolla-kubernetes core has a vote and it can
>
> be veto'ed.
>
>
>
> Voting will last 2 weeks and will end at 25th of August.
>
>
>
> Cheers,
>
> Michal
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

[image: Port.direct] 

Pete Birley / Director
pete@port.direct / +447446862551

*PORT.*DIRECT
United Kingdom
https://port.direct

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.
__
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] Adding Kristi Nikolla to keystone-core

[Steve Martinelli]

Congrats Kristi! Well deserved indeed!

On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad  wrote:

> I made the announcement in today's keystone meeting [0] that the current
> reviewers have decided to add Kristi Nikolla (knikolla) to the team.
>
> Kristi has been an extremely valuable asset to the team over the last
> couple of releases. He especially stepped up to the plate during Pike.
> He provides consistent and valuable feedback on reviews, actively
> participates in discussions about the project's future, and takes
> initiative when something needs to get done. In addition to that, he's
> been great about helping folks out in the channel and getting our Pike
> release candidate out the door.
>
> I'm excited to add Kristi to the keystone core group and I look forward
> to seeing him make positive changes. Thanks for all the dedication and
> hard work, Kristi!
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-08-15-18.00.log.html#l-130
>
>
>
> __
> 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] [keystone] Adding Kristi Nikolla to keystone-core

[Lance Bragstad]

I made the announcement in today's keystone meeting [0] that the current
reviewers have decided to add Kristi Nikolla (knikolla) to the team.

Kristi has been an extremely valuable asset to the team over the last
couple of releases. He especially stepped up to the plate during Pike.
He provides consistent and valuable feedback on reviews, actively
participates in discussions about the project's future, and takes
initiative when something needs to get done. In addition to that, he's
been great about helping folks out in the channel and getting our Pike
release candidate out the door.

I'm excited to add Kristi to the keystone core group and I look forward
to seeing him make positive changes. Thanks for all the dedication and
hard work, Kristi!

[0]
http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-08-15-18.00.log.html#l-130




signature.asc
Description: OpenPGP digital 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] [tc] [all] TC Report 33

[Chris Dent]

(If you prefer HTML: https://anticdent.org/tc-report-33.html )

Some are still in peak release cycle time and others have left for
their summer holidays, so once again: a bit of a slow week. No major
spectacles or controversies, so the best I can do is give some
summaries of the conversations in the `#openstack-tc` IRC channel.

# Continuous Deployment Continued

The Wednesday morning (at least in UTC) [office
hour](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-09.log.html#t2017-08-09T01:00:01)
continued the discussion about whether or not Continuous Deployment is
an integral part of the OpenStack development experience. There was
some disagreement on who had made what kind of commitment and since
when, but there's agreement in principle that:


We need a "Declare plainly the current state of CD in OpenStack"
[3RAY](http://p.anticdent.org/3RAY)


# Maintenance Status

The Thursday afternoon office hour started [a few hours
early](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-10.log.html#t2017-08-10T12:43:59)
with discussion about those projects that do not have PTLs. This
evolved to some discussion about the implications of single PTLs
volunteering leading to projects not needing elections. I suggested
that perhaps the job was too hard, or too difficult to manage without
sustained commitment from an employer and that such commitment was
harder to come by these days. Anyone care to dissuade me of this
opinion?

# Board Meeting Agendas

As we rolled around to [actual office hour
time](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-10.log.html#t2017-08-10T15:00:31)
the discussion returned to building agendas for the upcoming meetings
with the board. This was mentioned [last
week](https://anticdent.org/tc-report-32.html). My idea for a generic
retrospective was considered too open-ended and too much of an
invitation for unproductive complaining, so we discussed some ideas on
how to narrow things down.


less "it's hard" and more "it's hard because X" 
[2yZa](http://p.anticdent.org/2yZa)


This migrated to the common topic of "how do we get corporate
engagement to be strong enough and focused on the right things" which
naturally led to (because it was rc1 week) "ow, we could do with some
more CI nodes".

And finally, on today's [office
hour](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-15.log.html#t2017-08-15T09:04:39)
we came back to the agenda question and after discussion came to two
relatively concrete topics:

* What else should go on the top-5 list? Is what's there already
  correct?
* What is the status of the strategic goals? Are there areas that we
  are missing or need revision?

These were added to the [meeting 
agenda](https://wiki.openstack.org/wiki/Governance/Foundation/10Sep2017BoardMeeting#Leadership_Meeting_Agenda).

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [watcher] Stepping down as Watcher spec core

[Joe Cropper]

Antoine,

It’s been a pleasure getting to work alongside you in the open source 
community.  Your leadership was paramount to the project and I wish you all the 
best in your next chapter!

Best,
Joe (jwcroppe)


> On Aug 15, 2017, at 1:26 PM, Susanne Balle  wrote:
> 
> Thanks for all the hard work. best of luck, 
> 
> Susanne
> 
> On Fri, Jul 21, 2017 at 3:48 AM, Чадин Александр (Alexander Chadin) 
> mailto:a.cha...@servionica.ru>> wrote:
> Antoine,
> 
> Congratulations to the new step of your life!
> You’ve set high level of project management and this is big honour to me to 
> fit it.
> Hope to see you in Vancouver!
> 
> Best Regards,
> _
> Alexander Chadin
> OpenStack Developer
> 
>> On 21 Jul 2017, at 03:44, Hidekazu Nakamura > > wrote:
>> 
>> Hi Antoine,
>> 
>> I am grateful for your support from my starting contributing to Watcher.
>> Thanks to you I am contributing to Watcher actively now. 
>> 
>> I wish you live a happy life and a successful career.
>> 
>> Hidekazu Nakamura
>> 
>> 
>>> -Original Message-
>>> From: Antoine Cabot [mailto:antoinecabo...@gmail.com 
>>> ]
>>> Sent: Thursday, July 20, 2017 6:35 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> >> >
>>> Subject: [openstack-dev] [watcher] Stepping down as Watcher spec core
>>> 
>>> Hey guys,
>>> 
>>> It's been a long time since the last summit and our last discussions !
>>> I hope Watcher is going well and you are getting more traction
>>> everyday in the OpenStack community !
>>> 
>>> As you may guess, my last 2 months have been very busy with my
>>> relocation in Vancouver with my family. After 8 weeks of active job
>>> search in the cloud industry here in Vancouver, I've got a Senior
>>> Product Manager position at Parsable, a start-up leading the Industry
>>> 4.0 revolution. I will continue to deal with very large customers but
>>> in different industries (Oil & Gas, Manufacturing...) to build the
>>> best possible product, leveraging cloud and mobile technologies.
>>> 
>>> It was a great pleasure to lead the Watcher initiative from its
>>> infancy to the OpenStack Big Tent and be able to work with all of you.
>>> I hope to be part of another open source community in the near future
>>> but now, due to my new attributions, I need to step down as a core
>>> contributor to Watcher specs. Feel free to reach me in any case if I
>>> still hold restricted rights on launchpad or anywhere else.
>>> 
>>> I hope to see you all in Vancouver next year for the summit and be
>>> part of the traditional Watcher dinner (I will try to find the best
>>> place for you guys).
>>> 
>>> Cheers,
>>> 
>>> Antoine
>>> 
>>> __
>>> 
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org 
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [watcher] Stepping down as Watcher spec core

[Susanne Balle]

Thanks for all the hard work. best of luck,

Susanne

On Fri, Jul 21, 2017 at 3:48 AM, Чадин Александр (Alexander Chadin) <
a.cha...@servionica.ru> wrote:

> Antoine,
>
> Congratulations to the new step of your life!
> You’ve set high level of project management and this is big honour to me
> to fit it.
> Hope to see you in Vancouver!
>
> Best Regards,
> _
> Alexander Chadin
> OpenStack Developer
>
> On 21 Jul 2017, at 03:44, Hidekazu Nakamura 
> wrote:
>
> Hi Antoine,
>
> I am grateful for your support from my starting contributing to Watcher.
> Thanks to you I am contributing to Watcher actively now.
>
> I wish you live a happy life and a successful career.
>
> Hidekazu Nakamura
>
>
> -Original Message-
> From: Antoine Cabot [mailto:antoinecabo...@gmail.com
> ]
> Sent: Thursday, July 20, 2017 6:35 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [watcher] Stepping down as Watcher spec core
>
> Hey guys,
>
> It's been a long time since the last summit and our last discussions !
> I hope Watcher is going well and you are getting more traction
> everyday in the OpenStack community !
>
> As you may guess, my last 2 months have been very busy with my
> relocation in Vancouver with my family. After 8 weeks of active job
> search in the cloud industry here in Vancouver, I've got a Senior
> Product Manager position at Parsable, a start-up leading the Industry
> 4.0 revolution. I will continue to deal with very large customers but
> in different industries (Oil & Gas, Manufacturing...) to build the
> best possible product, leveraging cloud and mobile technologies.
>
> It was a great pleasure to lead the Watcher initiative from its
> infancy to the OpenStack Big Tent and be able to work with all of you.
> I hope to be part of another open source community in the near future
> but now, due to my new attributions, I need to step down as a core
> contributor to Watcher specs. Feel free to reach me in any case if I
> still hold restricted rights on launchpad or anywhere else.
>
> I hope to see you all in Vancouver next year for the summit and be
> part of the traditional Watcher dinner (I will try to find the best
> place for you guys).
>
> Cheers,
>
> Antoine
>
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core group

[Susanne Balle]

+1

On Thu, Aug 3, 2017 at 7:40 PM, Hidekazu Nakamura <
hid-nakam...@vf.jp.nec.com> wrote:

> +1
>
> > -Original Message-
> > From: Чадин Александр (Alexander Chadin)
> > [mailto:a.cha...@servionica.ru]
> > Sent: Wednesday, August 02, 2017 9:48 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: [openstack-dev] [watcher] nominate Aditi Sharma to Watcher Core
> > group
> >
> > Aditi Sharma (adisky in IRC) has been working on OpenStack Watcher since
> > this March
> > and has done some valuable patches[1] along with Action Plan cancelling
> > blueprint (spec and
> > implementation have been merged).
> > I’d like to nominate Aditi Sharma to Watcher Core group and waiting for
> > your vote.
> > Please, give +1/-1 in reply to this message.
> >
> > [1] :
> > https://review.openstack.org/#/q/owner:%22aditi+sharma+%253Caditi.s%25
> > 40nectechnologies.in%253E%22
> >
> > Best Regards,
> > __
> > Alexander Chadin
>
> __
> 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][elections] Last days to elect your PTL for Ironic and Documentation

[Kendall Nelson]

Hello Ironic and Documentation contributors,

Just a quick reminder that elections are closing soon, if you haven't
already you should use your right to vote and pick your favorite candidate!
You have until August 16th, 2017 at 23:45 UTC.

Thanks for your time!

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

Re: [openstack-dev] [oslo][oslo.messaging] Proposing Andy Smith as an oslo.messaging core reviewers

[Davanum Srinivas]

+1

On Tue, Aug 15, 2017 at 12:21 PM, Ben Nemec  wrote:
> +1
>
>
> On 08/14/2017 05:59 AM, ChangBo Guo wrote:
>>
>> I propose that we add Andy Smith to the oslo.messaging team.
>>
>> Andy Smith has been actively contributing to oslo.messaging for a while
>> now, both
>> in helping make oslo.messaging better via code contribution(s) and by
>> helping with
>> the review load when he can. He's been involved on the AMQP 1.0 side for
>> awhile. He's really interested in taking ownership of the experimental Kafka
>> driver, which would be great to have someone able to drive that.
>>
>> Please respond with +1/-1
>>
>> Voting will last 2 weeks and will end at 28th of August.
>>
>> Cheers,
>> --
>> ChangBo Guo(gcb)
>>
>>
>> __
>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

[Tim Bell]

One idea I found interesting from the past discussion was the approach that the 
user need is a database with a connection string.

How feasible is the approach where we are provisioning access to a multi-tenant 
database infrastructure rather than deploying a VM with storage and installing 
a database?

This would make the service delivery (monitoring, backup, upgrades) in the 
responsibility of the cloud provider rather than the end user. Some 
quota/telemetry would be needed to allocate costs to the project.

Tim

From: Amrith Kumar 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

   - Fix the gate

   - Update currently failing jobs, create xenial based images
   - Fix gate jobs that have gone stale (non-voting, no one paying
 attention)

   - Bug triage

   - Bugs in launchpad are really out of date, assignments to
 people who are no longer active, bugs that are really support
 requests, etc.,
   - Prioritize fixes for Queens and beyond

   - Get more active reviewers

   - There seems to still be a belief that 'contributing' means
 'fixing bugs'. There is much more value in actually doing
 reviews.
   - Get at least a three member active core review team by the
 end of the year.

   - Complete Python 3 support

  - Currently not complete; especially on the guest side

   - Community Goal, migrate to oslo.policy

   - Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the 
chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.
-amrith



[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir

__
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][oslo.messaging] Proposing Andy Smith as an oslo.messaging core reviewers

[Ben Nemec]

+1

On 08/14/2017 05:59 AM, ChangBo Guo wrote:

I propose that we add Andy Smith to the oslo.messaging team.

Andy Smith has been actively contributing to oslo.messaging for a while 
now, both
in helping make oslo.messaging better via code contribution(s) and by 
helping with
the review load when he can. He's been involved on the AMQP 1.0 side for 
awhile. He's really interested in taking ownership of the experimental 
Kafka driver, which would be great to have someone able to drive that.


Please respond with +1/-1

Voting will last 2 weeks and will end at 28th of August.

Cheers,
--
ChangBo Guo(gcb)


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



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

Re: [openstack-dev] [keystone] using only sql for resource backends

[Morgan Fainberg]

On Tue, Aug 15, 2017 at 7:36 AM, Lance Bragstad  wrote:
> During RC, Morgan's made quite a bit of progress on a bug found by the
> gate [0]. Part of the solution led to another patch that removes the
> ability to configure anything but sql for keystone's resource backend
> (`keystone.conf [resource] driver`). The reasoning behind this is that
> there were FK constraints introduced between the identity and resource
> tables [1] during the Ocata development cycle. This leaves us with two
> options moving forward:
>
> 1.) Drop the FK constraints entirely and backport those
> migrations/models to Ocata
> 2.) Ensure the resource backend is always configured as SQL - and keep
> the FKs setup between the resource and identity tables (note; this
> doesn't prevent the usage of non-sql identity backends, but just ensures
> that when sql is used for identity, resource is also used).
>
> Sending this out as a heads up for those deployments that might fall
> into this category. Let me know if you have any questions.
>
> Thanks,
>
> Lance
>
>
> [0] https://launchpad.net/bugs/1702211
> [1]
> https://github.com/openstack/keystone/commit/2bd88d30e1d2873470af7f40db45a99e07e12ce6
>
>
> __
> 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
>

The removal of the FKs also requires backporting schema updates (which
is both painful and much higher risk). As it stands it is highly
unlikely anyone is using non-SQL resource backends as any use of the
SQL Identity backend requires resource to be SQL. The Resource data is
highly relational and very keystone/openstack specific. The lowest
impact choice is to make [resource] always SQL.

__
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] Declaring explicit minimum database versions

[Monty Taylor]

Hey all,

Morgan was stabbing himself in the eyes yesterday dealing with a 
database issue in keystone related to datetimes and subsecond precision. 
As usually happens when people want to stab MySQL I got roped in and my 
first thought was "dude, we landed the subsecond precision patches in 
Drizzle back in 2008 - they can't possible not be in mainline by now."


Turns out - they are, which is great. EXCEPT ... drum roll ...

We don't explicitly declare a minimum supported MySQL version, so 
updating the DDL to just set datetime subsecond precision fields seems 
like a thing we can't do.


We do imply a minimum version via our distro support policy - but we 
don't really say anything about version of externally managed database 
tiers.


With that - I would like to suggest we explicitly declare that the 
minimum supported version of any given database is the minimum found in 
the union of our supported distros, which is the latest RHEL/CentOS and 
latest LTS of Ubuntu.


For the MySQL family, that currently resolves to MariaDB 5.5 / MySQL 
5.7.11, the upside being that it should be safe to depend, in any MySQL 
drivers, on any features that are included in MariaDB 5.5 or MySQL 5.7.11.


I have submitted a patch to governance to add this to our description of 
base services:


https://review.openstack.org/493932

Thoughts or objections?

Monty

__
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] [snaps] proposing Pete Vander Giessen for snaps-core and snaps-release group membership

[Corey Bryant]

On Mon, Aug 14, 2017 at 4:27 PM, Ryan Beisner 
wrote:

> Hi Snappers
>
> I'm writing to propose Pete Vander Giessen to the *snaps-core* and
> *snaps-release* groups.  Pete has done a good bit of work in OpenStack
> Snaps, particularly snap testing and CI tooling.  I feel he would add a lot
> of value to the general dev/review process, as well as to the release
> processes.
>
> Cheers,
>
> Ryan
>

Definitely a +2 from me. Pete has been providing solid reviews for a while
now. Pete is also leading snap testing/CI/CD, and has been contributing
significantly to these efforts.

Thanks,
Corey
__
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] [trove][tc][all] Trove restart - next steps

[Amrith Kumar]

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

   - Fix the gate

   - Update currently failing jobs, create xenial based images
   - Fix gate jobs that have gone stale (non-voting, no one paying
 attention)

   - Bug triage

   - Bugs in launchpad are really out of date, assignments to
 people who are no longer active, bugs that are really support
 requests, etc.,
   - Prioritize fixes for Queens and beyond

   - Get more active reviewers

   - There seems to still be a belief that 'contributing' means
 'fixing bugs'. There is much more value in actually doing
 reviews.
   - Get at least a three member active core review team by the
 end of the year.

   - Complete Python 3 support

  - Currently not complete; especially on the guest side

   - Community Goal, migrate to oslo.policy

   - Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the
chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith



[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir
__
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] [snaps] proposing David Ames for snaps-core and snaps-release group membership

[Corey Bryant]

On Mon, Aug 14, 2017 at 4:22 PM, Ryan Beisner 
wrote:

> Hi Snappers
>
> I'm writing to propose David Ames to the *snaps-core* and *snaps-release*
> groups.  David has done a good bit of work in OpenStack Snaps.  I feel he
> would add a lot of value to the general dev/review process, as well as to
> the release processes.
>
> Cheers,
>
> Ryan
>
>
Definitely a +2 from me. David is an excellent reviewer, providing solid
reviews to the snaps themselves. He also has a perspective that is very
useful in that he has been working on enabling snaps in the OpenStack
charms.

Thanks,
Corey
__
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] [nova] notification subteam meeting is canceled

[Balazs Gibizer]

Hi,

The notification subteam meeting is canceled this week.

Cheers,
gibi


__
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] [keystone] using only sql for resource backends

[Lance Bragstad]

During RC, Morgan's made quite a bit of progress on a bug found by the
gate [0]. Part of the solution led to another patch that removes the
ability to configure anything but sql for keystone's resource backend
(`keystone.conf [resource] driver`). The reasoning behind this is that
there were FK constraints introduced between the identity and resource
tables [1] during the Ocata development cycle. This leaves us with two
options moving forward:

1.) Drop the FK constraints entirely and backport those
migrations/models to Ocata
2.) Ensure the resource backend is always configured as SQL - and keep
the FKs setup between the resource and identity tables (note; this
doesn't prevent the usage of non-sql identity backends, but just ensures
that when sql is used for identity, resource is also used).

Sending this out as a heads up for those deployments that might fall
into this category. Let me know if you have any questions.

Thanks,

Lance


[0] https://launchpad.net/bugs/1702211
[1]
https://github.com/openstack/keystone/commit/2bd88d30e1d2873470af7f40db45a99e07e12ce6



signature.asc
Description: OpenPGP digital 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] tools for creating new releases

[Dmitry Tantsur]

On 08/08/2017 03:30 PM, Doug Hellmann wrote:

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

$ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

$ tox -e venv -- new-release pike cinder rc


On systems with Python 3 by default this fails on installing lazr.restfulclient. 
I think we should add


 basepython = python2

for now.



detects that this is the first release candidate and updates the
file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
and instructions to create a new stable branch at that tag.

There are some more details in the README.rst file in the releases
repository, and as usual you'll find us in #openstack-release if you
have questions.

Doug

__
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] [masakari]I withdraw my remark of today's IRC meerting.

[Sam P]

Hi Rikimaru,

 Thank you for verification.

--- Regards,
Sampath



On Tue, Aug 15, 2017 at 7:37 PM, Rikimaru Honjo
 wrote:
> Hello,
>
> In today's Masakari IRC meeting, I said that executing masakari notification
> API was failed in the latest devstack environment[1].
>
> I rebuilt my environment after that.
> As a result, I couldn't reproduce the issue.
>
> So I don't report it to launchpad.
> Sorry.
>
> [1]
> http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-08-15-04.00.log.html#l-132
>
> Best regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> 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] [masakari]I withdraw my remark of today's IRC meerting.

[Rikimaru Honjo]

Hello,

In today's Masakari IRC meeting, I said that executing masakari notification
API was failed in the latest devstack environment[1].

I rebuilt my environment after that.
As a result, I couldn't reproduce the issue.

So I don't report it to launchpad.
Sorry.

[1]
http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-08-15-04.00.log.html#l-132

Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



__
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] PTG Planning with online meeting

[ChangBo Guo]

Hi ALL,


Oslo team will try to set up online meeting( maybe zoom) during the PTG,
then others who can't travel to Denver  can join the discussion.  will send
out the meeting link before the PTG.

So please add topics in https://etherpad.openstack.org/p/oslo-ptg-queens
even you can't attend
the PTG.



2017-07-28 15:11 GMT+08:00 ChangBo Guo :

> Just a reminder,  please add your name and topic in the etherpad if you
> will join the discussion abouth Oslo at the PTG.
>
> 2017-07-10 21:48 GMT+08:00 ChangBo Guo :
>
>> Hi Oslo folks,
>>
>> I created a planning etherpad[1] for topics for the next PTG in Denver.
>> Please add any topics there,  then we can schedule the topics before the
>> PTG.
>>
>> [1]https://etherpad.openstack.org/p/oslo-ptg-queens
>>
>> --
>> ChangBo Guo(gcb)
>>
>
>
>
> --
> ChangBo Guo(gcb)
>



-- 
ChangBo Guo(gcb)
__
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] [l2gw] How to handle correctly unknown-dst traffic

[Saverio Proto]

> The ucast-mac-remote table is filled with information that don't match
> your comments. In my environment, I have created only one neutron
> network, one l2gw instance and one l2gw connection. However, the mac
> reflected in that table corresponds to the dhcp port of the Neutron
> network (I've checked the mac on the dhcp namespace and it's the same).
> I've created several VMs in different compute nodes and there is only
> one line there. Could you check again the MAC address?

Hello,

I confirm I have one line per VM

root@l2gw-0:/# vtep-ctl list-remote-macs
ee87db33-1b3a-42e9-bc09-02747f8a0ad5
ucast-mac-remote
  fa:16:3e:6b:6e:d1 -> vxlan_over_ipv4/10.1.1.161
  fa:16:3e:7f:18:77 -> vxlan_over_ipv4/10.1.0.126
  fa:16:3e:90:7f:f9 -> vxlan_over_ipv4/10.1.1.177
  fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167
  fa:16:3e:ca:ad:c6 -> vxlan_over_ipv4/10.1.0.126
  fa:16:3e:f0:21:01 -> vxlan_over_ipv4/10.1.1.175

I have the indication of the mac address of the VM, and the IP address
of the hypervisor where it is hosted.


> In my setup I get this automatically:
> 
> mcast-mac-remote
>   unknown-dst -> vxlan_over_ipv4/192.0.2.6 
> 
> If you're using the agent, it might be a bug.

I am running Openstack Newton, on what version is based your PoC ?

thank you

Saverio


__
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