Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

I’m in.

Br,
Gerg0

From: Miguel Lavalle 
Sent: Saturday, September 8, 2018 10:30 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next 
week - ACTION NEEDED

Hi Ildikó,

Wednesday lunch is fine with me

Regards

On Fri, Sep 7, 2018 at 5:30 PM, Ildiko Vancsa 
mailto:ildiko.van...@gmail.com>> wrote:
Hi Training Team,

As a couple of us will be at the PTG next week it would be great to get 
together one of the days maybe for lunch.

Wednesday would work the best for Kendall and me, but we can look into other 
days as well if it would not work for the majority of people around.

So my questions would be:

* Are you interested in getting together one of the lunch slots during next 
week?

* Would Wednesday work for you or do you have another preference?

Please drop a response to this thread and we will figure it out by Monday or 
early next week based on the responses.

Thanks,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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] [goals][python3][qa] Re: starting zuul configuration migration for QA team

[Doug Hellmann]

Excerpts from Ghanshyam Mann's message of 2018-08-31 19:56:33 +0900:
> 
> 
> 
> Thanks Doug. QA is ready for this work. Let me know the link and ll review 
> those. 

Here's the list of patches for the QA team.

++-+-+--+-+---+---+
| Subject| Repo 
   | Tests   | Workflow | URL | 
Branch| Owner |
++-+-+--+-+---+---+
| import zuul job settings from project-config   | 
openstack-dev/bashate   | UNKNOWN | NEW  | 
https://review.openstack.org/600987 | master| Doug Hellmann |
| switch documentation job to new PTI| 
openstack-dev/bashate   | UNKNOWN | NEW  | 
https://review.openstack.org/600988 | master| Doug Hellmann |
| add python 3.6 unit test job   | 
openstack-dev/bashate   | UNKNOWN | NEW  | 
https://review.openstack.org/600989 | master| Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/600990 | master| Doug Hellmann |
| switch documentation job to new PTI| 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/600991 | master| Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/601022 | stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/601024 | stable/pike   | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/601026 | stable/queens | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/devstack  | UNKNOWN | NEW  | 
https://review.openstack.org/601029 | stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/grenade   | UNKNOWN | NEW  | 
https://review.openstack.org/600992 | master| Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/grenade   | PASS| NEW  | 
https://review.openstack.org/601023 | stable/ocata  | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/grenade   | UNKNOWN | NEW  | 
https://review.openstack.org/601025 | stable/pike   | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/grenade   | UNKNOWN | NEW  | 
https://review.openstack.org/601027 | stable/queens | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/grenade   | UNKNOWN | NEW  | 
https://review.openstack.org/601030 | stable/rocky  | Doug Hellmann |
| import zuul job settings from project-config   | 
openstack-dev/hacking   | UNKNOWN | NEW  | 
https://review.openstack.org/600993 | master| Doug Hellmann |
| switch documentation job to new PTI| 
openstack-dev/hacking   | UNKNOWN | NEW  | 
https://review.openstack.org/600994 | master| Doug Hellmann |
| add python 3.6 unit test job   | 
openstack-dev/hacking   | UNKNOWN | NEW  | 
https://review.openstack.org/600995 | master| Doug Hellmann |
| remove job settings for Quality Assurance repositories | 
openstack-infra/project-config  | UNKNOWN | WIP  | 
https://review.openstack.org/601032 | master| Doug Hellmann |
| import zuul job settings from project-config   | 
openstack/coverage2sql  | UNKNOWN | NEW  | 
https://review.openstack.org/600984 | master| Doug Hellmann |
| switch documentation job to new PTI| 
openstack/coverage2sql  | UNKNOWN | NEW  | 
https://review.openstack.org/600985 | master| Doug Hellmann |
| add python 3.6 unit test job   | 
openstack/coverage2sql  | UNKNOWN | NEW  | 
https://review.openstack.org/600986 | master| Doug Hellmann |
| import zuul job settings from project-config   | 
openstack/devstack-plugin-ceph  | UNKNOWN | NEW  | 
https://review.openstack.org/600996 | master| Doug Hellmann |
| import zuul job settings from 

Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

[Miguel Lavalle]

Hi Ildikó,

Wednesday lunch is fine with me

Regards

On Fri, Sep 7, 2018 at 5:30 PM, Ildiko Vancsa 
wrote:

> Hi Training Team,
>
> As a couple of us will be at the PTG next week it would be great to get
> together one of the days maybe for lunch.
>
> Wednesday would work the best for Kendall and me, but we can look into
> other days as well if it would not work for the majority of people around.
>
> So my questions would be:
>
> * Are you interested in getting together one of the lunch slots during
> next week?
>
> * Would Wednesday work for you or do you have another preference?
>
> Please drop a response to this thread and we will figure it out by Monday
> or early next week based on the responses.
>
> Thanks,
> Ildikó
> (IRC: ildikov)
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] about unified limits

[Jay S Bryant]

Ben,

Ping me when you are planning on having this discussion if you think of 
it.  Since there is interest in this for Cinder I would like to try to 
be there.


Thanks!

Jay


On 9/7/2018 1:43 PM, Ben Nemec wrote:
I will also note that I had an oslo.limit topic on the Oslo PTG 
schedule: https://etherpad.openstack.org/p/oslo-stein-ptg-planning


I don't know whether anybody from Jaze's team will be there, but if so 
that would be a good opportunity for some face-to-face discussion. I 
didn't give it a whole lot of time, but I'm open to extending it if 
that would be helpful.


On 09/07/2018 01:34 PM, Lance Bragstad wrote:
That would be great! I can break down the work a little bit to help 
describe where we are at with different parts of the initiative. 
Hopefully it will be useful for your colleagues in case they haven't 
been closely following the effort.


# keystone

Based on the initial note in this thread, I'm sure you're aware of 
keystone's status with respect to unified limits. But to recap, the 
initial implementation landed in Queens and targeted flat enforcement 
[0]. During the Rocky PTG we sat down with other services and a few 
operators to explain the current status in keystone and if either 
developers or operators had feedback on the API specifically. Notes 
were captured in etherpad [1]. We spent the Rocky cycle fixing 
usability issues with the API [2] and implementing support for a 
hierarchical enforcement model [3].


At this point keystone is ready for services to start consuming the 
unified limits work. The unified limits API is still marked as stable 
and it will likely stay that way until we have at least one project 
using unified limits. We can use that as an opportunity to do a final 
flush of any changes that need to be made to the API before fully 
supporting it. The keystone team expects that to be a quick 
transition, as we don't want to keep the API hanging in an 
experimental state. It's really just a safe guard to make sure we 
have the opportunity to use it in another service before fully 
committing to the API. Ultimately, we don't want to prematurely mark 
the API as supported when other services aren't even using it yet, 
and then realize it has issues that could have been fixed prior to 
the adoption phase.


# oslo.limit

In parallel with the keystone work, we created a new library to aid 
services in consuming limits. Currently, the sole purpose of 
oslo.limit is to abstract project and project hierarchy information 
away from the service, so that services don't have to reimplement 
client code to understand project trees, which could arguably become 
complex and lead to inconsistencies in u-x across services.


Ideally, a service should be able to pass some relatively basic 
information to oslo.limit and expect an answer on whether or not 
usage for that claim is valid. For example, here is a project ID, 
resource name, and resource quantity, tell me if this project is over 
it's associated limit or default limit.


We're currently working on implementing the enforcement bits of 
oslo.limit, which requires making API calls to keystone in order to 
retrieve the deployed enforcement model, limit information, and 
project hierarchies. Then it needs to reason about those things and 
calculate usage from the service in order to determine if the request 
claim is valid or not. There are patches up for this work, and 
reviews are always welcome [4].


Note that we haven't released oslo.limit yet, but once the basic 
enforcement described above is implemented we will. Then services can 
officially pull it into their code as a dependency and we can work 
out remaining bugs in both keystone and oslo.limit. Once we're 
confident in both the API and the library, we'll bump oslo.limit to 
version 1.0 at the same time we graduate the unified limits API from 
"experimental" to "supported". Note that oslo libraries <1.0 are 
considered experimental, which fits nicely with the unified limit API 
being experimental as we shake out usability issues in both pieces of 
software.


# services

Finally, we'll be in a position to start integrating oslo.limit into 
services. I imagine this to be a coordinated effort between keystone, 
oslo, and service developers. I do have a patch up that adds a 
conceptual overview for developers consuming oslo.limit [5], which 
renders into [6].


To be honest, this is going to be a very large piece of work and it's 
going to require a lot of communication. In my opinion, I think we 
can use the first couple iterations to generate some well-written 
usage documentation. Any questions coming from developers in this 
phase should probably be answered in documentation if we want to 
enable folks to pick this up and run with it. Otherwise, I could see 
the handful of people pushing the effort becoming a bottle neck in 
adoption.


Hopefully this helps paint the landscape of where things are 
currently with respect to each piece. As always, let me 

Re: [openstack-dev] [os-upstream-institute] Team lunch at the PTG next week - ACTION NEEDED

[Jay S Bryant]

Ildiko,

Sounds like a good plan.  I don't think I have other plans for Wednesday 
so that should work.


Look forward to seeing you next week!

Jay


On 9/7/2018 5:30 PM, Ildiko Vancsa wrote:

Hi Training Team,

As a couple of us will be at the PTG next week it would be great to get 
together one of the days maybe for lunch.

Wednesday would work the best for Kendall and me, but we can look into other 
days as well if it would not work for the majority of people around.

So my questions would be:

* Are you interested in getting together one of the lunch slots during next 
week?

* Would Wednesday work for you or do you have another preference?

Please drop a response to this thread and we will figure it out by Monday or 
early next week based on the responses.

Thanks,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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] [release] Release countdown for week R-30 and R-29, September 10-21

[Trinh Nguyen]

Thank Sean.


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Sat, Sep 8, 2018 at 11:24 PM Sean McGinnis  wrote:

> On Sat, Sep 08, 2018 at 09:54:33AM +0900, Trinh Nguyen wrote:
> > Hi,
> >
> > Thanks for the summary.
> >
> > I just added Searchlight to the Stein deliverable [1]. One concern is we
> > moved our projects to Storyboard last week, do I have to change the
> project
> > file to reflect that and how?
> >
> > Thanks,
> >
> > [1] https://review.openstack.org/#/c/600889/
> >
>
> Hey Trinh,
>
> The deliverable should be switched over to reflect the change to use
> storyboard. Here is an example of a patch that did that for another
> deliverable:
>
>
> https://review.openstack.org/#/c/553900/1/deliverables/_independent/reno.yaml
>
> So once you get the storyboard ID, you just swap out the "launchpad:" line
> for
> a "storyboard:" one.
>
> Jeremy's idea of supporting the names from the other thread seems like a
> good
> idea to me, so I will have to take a look at that proposal.
>
> Sean
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Release countdown for week R-30 and R-29, September 10-21

[Sean McGinnis]

On Sat, Sep 08, 2018 at 09:54:33AM +0900, Trinh Nguyen wrote:
> Hi,
> 
> Thanks for the summary.
> 
> I just added Searchlight to the Stein deliverable [1]. One concern is we
> moved our projects to Storyboard last week, do I have to change the project
> file to reflect that and how?
> 
> Thanks,
> 
> [1] https://review.openstack.org/#/c/600889/
> 

Hey Trinh,

The deliverable should be switched over to reflect the change to use
storyboard. Here is an example of a patch that did that for another
deliverable:

https://review.openstack.org/#/c/553900/1/deliverables/_independent/reno.yaml

So once you get the storyboard ID, you just swap out the "launchpad:" line for
a "storyboard:" one.

Jeremy's idea of supporting the names from the other thread seems like a good
idea to me, so I will have to take a look at that proposal.

Sean

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

Re: [openstack-dev] [kuryr] Some questions about kuryr

[Shuai Zhao]

Hi Kuryr,
We still have the issue on this.
any update on the question will be really appreciated. Thanks～

On Mon, Sep 3, 2018 at 1:56 PM Shuai Zhao  wrote:

> Hi daniel,
>
> As we know, there are two ways to deploy network for Pod-in-VM in
> openstack through kuryr, macvlan and trunk.
>
> Why do we just create ports in neutron and attach this port to VM then we
> can easily use eth* in VM to deploy network for Pod-in-VM?
>
> And if we use macvlan mode when VMs are running on overlay network, how
> could we resolve the l2-population?
>
> Best wishes to you !
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev