Re: [openstack-dev] [tripleo] Recap of Python 3 testing session at PTG

On Fri, Apr 13, 2018 at 8:48 PM, Thomas Goirand wrote: > On 03/17/2018 09:34 AM, Emilien Macchi wrote: > > The other one that isn't Py3 ready *in stable* is trove-dashboard. I > have sent backport patches, but they were not approved because of the > stable gate having issues: >

[openstack-dev] [osc][swift] Setting storage policy for a container possible via the client?

Swift has had storage policies for a while now. These are enabled by setting the 'X-Storage-Policy' header on a container. It looks to me like this is not possible using openstack-client (even in master branch) - while there is a 'set' operation for containers this will *only* set  'Meta-*'

Re: [openstack-dev] [stable][trove] keep trove-stable-maint members up-to-date

Matt, Thanks a lot! On Thu, Apr 19, 2018 at 2:01 AM, Matt Riedemann wrote: > On 4/17/2018 8:49 PM, 赵超 wrote: > >> Thanks for approving the stable branch patches of trove and python-trove, >> we also have some in the trove-dashboard. >> > > I also went through the

Re: [openstack-dev] [openstack-infra] How to take over a project?

Ian, Thank you so much for your help. I have requested Vikram to add me to the release team. He should be able to help me. :-) Sangho > On 19 Apr 2018, at 8:36 AM, Ian Wienand wrote: > > On 04/19/2018 01:19 AM, Ian Y. Choi wrote: >> By the way, since the

Re: [openstack-dev] [openstack-infra] How to take over a project?

Vikram, According to https://review.openstack.org/#/admin/groups/1002,members , you are the member of networking-onos release team. Can you please add me to the group so that I can create a new branch? Thank you, Sangho > On 19 Apr

Re: [openstack-dev] [openstack-infra] How to take over a project?

On 04/19/2018 01:19 AM, Ian Y. Choi wrote: By the way, since the networking-onos-release group has no neutron release team group, I think infra team can help to include neutron release team and neutron release team can help to create branches for the repo if there is no reponse from current

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

> > This looks like some behavior that has been pulled out as part of pbr 4 > (version 3 is being used in the stable branch). Perhaps we want to > update the pbr constraint there to use the newer version? > And it looks like doing that for stable/queens, at least from an ironic-inspector point of

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

> I have a feeling we're just going to go back and forth on this, as we > have for weeks now, and not reach any conclusion that is satisfactory to > everyone. And we'll delay, yet again, getting functionality into this > release that serves 90% of use cases because we are obsessing over the >

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 04:52 PM, Eric Fried wrote: I can't tell if you're being facetious, but this seems sane, albeit complex. It's also extensible as we come up with new and wacky affinity semantics we want to support. I was not being facetious. I can't say I'm sold on requiring `proximity`

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Sorry, addressing gaffe, bringing this back on-list... On 04/18/2018 04:36 PM, Ed Leafe wrote: > On Apr 18, 2018, at 4:11 PM, Eric Fried wrote: >>> That makes a lot of sense. Since we are already suffixing the query param >>> “resources” to indicate granular, why not add a

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

> Cool. So let's not use a GET for this and instead change it to a POST > with a request body that can more cleanly describe what the user is > requesting, which is something we talked about a long time ago. I kinda doubt we could agree on a format for this in the Rocky timeframe. But for the

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Chris- Going to accumulate a couple of your emails and answer them. I could have answered them separately (anti-affinity). But in this case I felt it appropriate to provide responses in a single note (best fit). > I'm a bit conflicted.  On the one hand... > On the other hand, Right;

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

I can't tell if you're being facetious, but this seems sane, albeit complex. It's also extensible as we come up with new and wacky affinity semantics we want to support. I can't say I'm sold on requiring `proximity` qparams that cover every granular group - that seems like a pretty onerous

Re: [openstack-dev] [nova] Default scheduler filters survey

Artom Lifshitz writes: > To that end, we'd like to know what filters operators are enabling in > their deployment. If you can, please reply to this email with your > [filter_scheduler]/enabled_filters (or > [DEFAULT]/scheduler_default_filters if you're using an older version) > option from

Re: [openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

Excerpts from Jim Rollenhagen's message of 2018-04-18 13:44:08 -0400: > Hi all, > > We have a number of stable branch jobs failing[0] with an error about pep8 > not being importable[1], when it's clearly installed[2]. We first saw this > when installing networking-generic-switch on queens in our

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

> Having briefly read the cloud-init snippet which was linked earlier in > this thread, the requirement seems to be that the guest exposes the > device as /dev/srX or /dev/cdX. So I guess in order to make this work: > > * You need to tell z/VM to expose the virtual disk as an optical disk > * The

Re: [openstack-dev] [nova] Concern about trusted certificates API change

> Maybe it wasn't clear but I'm not advocating that we block the change > until volume-backed instances are supported with trusted certs. I'm > suggesting we add a policy rule which allows deployers to at least > disable it via policy if it's not supported for their cloud. That's fine with me,

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 4/18/2018 12:40 PM, Jay Pipes wrote: We can go even deeper if you'd like, since NFV means "never-ending feature velocity". Just let me know. Cool. So let's not use a GET for this and instead change it to a POST with a request body that can more cleanly describe what the user is

Re: [openstack-dev] [stable][trove] keep trove-stable-maint members up-to-date

On 4/17/2018 8:49 PM, 赵超 wrote: Thanks for approving the stable branch patches of trove and python-trove, we also have some in the trove-dashboard. I also went through the trove-dashboard ones, just need another stable-maint-core to approve those.

[openstack-dev] [ironic][infra][qa] Jobs failing; pep8 not found

Hi all, We have a number of stable branch jobs failing[0] with an error about pep8 not being importable[1], when it's clearly installed[2]. We first saw this when installing networking-generic-switch on queens in our multinode grenade job. We hacked a fix there[3], as we couldn't figure it out

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 11:58 AM, Matt Riedemann wrote: On 4/18/2018 9:06 AM, Jay Pipes wrote: "By default, should resources/traits submitted in different numbered request groups be supplied by separate resource providers?" Without knowing all of the hairy use cases, I'm trying to channel my inner

Re: [openstack-dev] [nova] Default scheduler filters survey

On Wed, Apr 18, 2018 at 05:20:13PM +, Tim Bell wrote: :I'd suggest asking on the openstack-operators list since there is only a subset of operators who follow openstack-dev. I'd second that, which I'm (obviously) subscribed to both I do pay more attention to operators, and almost missed this

Re: [openstack-dev] [nova] Default scheduler filters survey

I'd suggest asking on the openstack-operators list since there is only a subset of operators who follow openstack-dev. Tim -Original Message- From: Chris Friesen Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [nova] Concern about trusted certificates API change

On 04/18/2018 01:14 PM, Matt Riedemann wrote: On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol?  If so, then I think that's totally fine. If you're

Re: [openstack-dev] [nova] Concern about trusted certificates API change

On 4/18/2018 12:09 PM, Chris Friesen wrote: If this happens, is it clear to the end-user that the reason the boot failed is that the cloud doesn't support trusted cert IDs for boot-from-vol?  If so, then I think that's totally fine. If you're creating an image-backed server and requesting

Re: [openstack-dev] [nova] Concern about trusted certificates API change

On 4/18/2018 11:57 AM, Jay Pipes wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager,

Re: [openstack-dev] [nova] Concern about trusted certificates API change

On 04/18/2018 10:57 AM, Jay Pipes wrote: On 04/18/2018 12:41 PM, Matt Riedemann wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based

Re: [openstack-dev] [nova] Concern about trusted certificates API change

On 04/18/2018 12:41 PM, Matt Riedemann wrote: There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key

[openstack-dev] [tripleo] CI & Tempest squad planning summary: Sprint 12

Greetings, The TripleO CI & Tempest squads have begun work on Sprint 12. This is a 3 week sprint. The Ruck & Rover for this sprint are quiquell and panda. ## CI Squad Goals: "As a developer, I want reproduce a multinode CI job on a bare metal host using libvirt" "Enable the same workflows

[openstack-dev] [nova] Concern about trusted certificates API change

There is a compute REST API change proposed [1] which will allow users to pass trusted certificate IDs to be used with validation of images when creating or rebuilding a server. The trusted cert IDs are based on certificates stored in some key manager, e.g. Barbican. The full nova spec is

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On Wed, 18 Apr 2018, Jay Pipes wrote: Stackers, Thanks for doing this. Seeing it gathered in one place like this in neither IRC nor gerrit is way easier on my brain (for whatever reason, don't know why). Eric Fried and I are currently at an impasse regarding a decision that will have

Re: [openstack-dev] [nova] Default scheduler filters survey

On 04/18/2018 09:17 AM, Artom Lifshitz wrote: To that end, we'd like to know what filters operators are enabling in their deployment. If you can, please reply to this email with your [filter_scheduler]/enabled_filters (or [DEFAULT]/scheduler_default_filters if you're using an older version)

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On Apr 18, 2018, at 10:58 AM, Matt Riedemann wrote: > > So for this case, if I'm requesting numbered request groups, why doesn't the > API just require that I pass a query parameter telling it how I'd like those > requests to be handled, either via affinity or

Re: [openstack-dev] [tripleo] Ironic Inspector in the overcloud

On 18 April 2018 at 14:22, Bogdan Dobrelya wrote: > On 4/18/18 12:07 PM, Derek Higgins wrote: > >> Hi All, >> >> I've been testing the ironic inspector containerised service in the >> overcloud, the service essentially works but there is a couple of hurdles >> to tackle to

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 09:58 AM, Matt Riedemann wrote: On 4/18/2018 9:06 AM, Jay Pipes wrote: "By default, should resources/traits submitted in different numbered request groups be supplied by separate resource providers?" Without knowing all of the hairy use cases, I'm trying to channel my inner

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 08:06 AM, Jay Pipes wrote: Stackers, Eric Fried and I are currently at an impasse regarding a decision that will have far-reaching (and end-user facing) impacts to the placement API and how nova interacts with the placement service from the nova scheduler. We need to make a

Re: [openstack-dev] [nova] Rocky forum topics brainstorming

On Fri, 13 Apr 2018 08:00:31 -0700, Melanie Witt wrote: +openstack-operators (apologies that I forgot to add originally) On Mon, 9 Apr 2018 10:09:12 -0700, Melanie Witt wrote: Hey everyone, Let's collect forum topic brainstorming ideas for the Forum sessions in Vancouver in this etherpad [0].

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On Wed, Apr 18, 2018 at 10:56 AM, Matthew Booth wrote: > > > I agree with Mikal that needing more agent behavior than cloud-init does > > a disservice to the users. > > > > I feel like we get a lot of "but no, my hypervisor is special!" > > reasoning when people go to add a

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 4/18/2018 9:06 AM, Jay Pipes wrote: "By default, should resources/traits submitted in different numbered request groups be supplied by separate resource providers?" Without knowing all of the hairy use cases, I'm trying to channel my inner sdague and some of the similar types of

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Wednesday, April 18, 2018 3:39 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [placement][nova] Decision time on > granular request groups for like resources > > On 04/18/2018 10:30 AM,

Re: [openstack-dev] [openstack-infra] How to take over a project?

Hello Sangho, When I see https://review.openstack.org/#/admin/projects/openstack/networking-onos,access page, it seems that networking-onos-release group members can create stable branches for the repository. By the way, since the networking-onos-release group has no neutron release team

[openstack-dev] [nova] Default scheduler filters survey

Hi all, A CI issue [1] caused by tempest thinking some filters are enabled when they're really not, and a proposed patch [2] to add (Same|Different)HostFilter to the default filters as a workaround, has led to a discussion about what filters should be enabled by default in nova. The default

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

On 18 April 2018 at 15:10, Dan Smith wrote: >> Thanks for the concern and fully under it , the major reason is >> cloud-init doesn't have a hook or plugin before it start to read >> config drive (ISO disk) z/VM is an old hypervisor and no way to do >> something like libvirt to

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

On 04/18/2018 10:30 AM, Eric Fried wrote: Thanks for describing the proposals clearly and concisely, Jay. My preamble would have been that we need to support two use cases: - "explicit anti-affinity": make sure certain parts of my request land on *different* providers; - "any fit": make sure

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Thanks for describing the proposals clearly and concisely, Jay. My preamble would have been that we need to support two use cases: - "explicit anti-affinity": make sure certain parts of my request land on *different* providers; - "any fit": make sure my instance lands *somewhere*. Both

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

> Thanks for the concern and fully under it , the major reason is > cloud-init doesn't have a hook or plugin before it start to read > config drive (ISO disk) z/VM is an old hypervisor and no way to do > something like libvirt to define a ISO format disk in xml definition, > instead, it can define

[openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Stackers, Eric Fried and I are currently at an impasse regarding a decision that will have far-reaching (and end-user facing) impacts to the placement API and how nova interacts with the placement service from the nova scheduler. We need to make a decision regarding the following question:

Re: [openstack-dev] [horizon] Meeting time and location are changed

Hi, It's just a reminder that we've got our meeting today at 15.00UTC at openstack-meeting-alt channel. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Apr 16, 2018 at 12:01 PM, Ivan Kolodyazhny wrote: > Hi team, > > Please be informed that Horizon meeting time has

[openstack-dev] [docs] Documentation meeting today

Hi all, The docs meeting will continue today at 16:00 UTC in #openstack-doc, as scheduled. For more details, see the meeting page: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting Cheers, pk __ OpenStack Development

[openstack-dev] [keystone] [all] openstack-specs process

Hi all, There is a specification proposed to openstack/openstack-specs that summarizes some outcomes from the PTG in Dublin [0]. The keystone team had some questions about what happens next regarding that specification in this week's meeting [1]. What is the process for that repository? Is there

Re: [openstack-dev] [tripleo] Ironic Inspector in the overcloud

On 4/18/18 12:07 PM, Derek Higgins wrote: Hi All, I've been testing the ironic inspector containerised service in the overcloud, the service essentially works but there is a couple of hurdles to tackle to set it up, the first of these is how to get  the IPA kernel and ramdisk where they need

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

On Tue, 17 Apr 2018, Thierry Carrez wrote: So... Is there any specific topic you think we should cover in that meeting ? I'll bite. I've got two topics that I think are pretty critical to address with the various segments of the community that are the source of code commits and reviews.

[openstack-dev] [tripleo] Ironic Inspector in the overcloud

Hi All, I've been testing the ironic inspector containerised service in the overcloud, the service essentially works but there is a couple of hurdles to tackle to set it up, the first of these is how to get the IPA kernel and ramdisk where they need to be. These need to be be present in the

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

Thanks for the concern and fully under it , the major reason is cloud-init doesn't have a hook or plugin before it start to read config drive (ISO disk) z/VM is an old hypervisor and no way to do something like libvirt to define a ISO format disk in xml definition, instead, it can define disks in

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

Added a update to the spec to the issues that requested https://review.openstack.org/#/c/562154/ , including: 1) How the config drive (Metadata) defined 2) Special AE reason and why it's needed, also ,some documentation and source code links 3) neutron agent for z/VM Best Regards! Kevin (Chen)

[openstack-dev] [cyborg]Weekly Team Meeting 2018.04.18

Hi Team, Weekly meeting as usual starting UTC1400 at #openstack-cyborg, initial agenda as follows: 1. MS1 preparation 2. bug report on storyboard 3. Rocky critical spec review 4. open patches discussion -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

+1 On 18/04/18 02:51, Jeffrey Zhang wrote: Since many of the contributors in the kolla-kubernetes project are moved to other things. And there is no active contributor for months.  On the other hand, there is another comparable project, openstack-helm, in the community.  For less confusion

Re: [openstack-dev] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

On Wed, Apr 18, 2018 at 12:02 PM, Michel Peterson wrote: > How can we fix this? There are several ways I can think of the top of my > head: > > >1. When encountered with edge cases like this one, first install that >dependency with a manual pip run [2] >2. Modify

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

I'm confused about the design of AE to be honest. Is there a good reason that this functionality couldn't be provided by cloud-init? I think there's a lot of cost in deviating from the industry standard, so the reasons to do so have to be really solid. I'm also a bit confused by what seems to be

Re: [openstack-dev] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

Hi, I'm one of the networking-odl core devs. On Wed, Apr 18, 2018 at 5:48 AM, Jeffrey Zhang wrote: > > Recently, one of networking-odl package breaks kolla's gate[0]. The direct > issue is ceilometer is added in networking-odl's requirements.txt file[1] > This is an

Re: [openstack-dev] [tripleo] The Weekly Owl - 17th Edition

On 4/18/18 3:54 AM, Wesley Hayutin wrote: On Tue, Apr 17, 2018 at 9:44 PM Emilien Macchi > wrote: Note: this is the seventeeth edition of a weekly update of what happens in TripleO. The goal is to provide a short reading (less than

Re: [openstack-dev] [kolla][neutron][requirements][pbr]Use git+https line in requirements.txt break the pip install

As I understand, this is due to a not-yet-completed transition in networking-odl after stopping the use of the tools/tox_install.sh and relying on the tox-sibling CI role instead. I'm not able to explain the difference between the two "pip install" run variants that you see, though. For the

Re: [openstack-dev] [openstack-ansible] Problems with Openstack services while migrating VMs

Maybe worth posting on operators, but it looks like the scheduling of the action fails, which let me think that nova is not running fine somewhere. Why is the restart in a random order? That can cause issues, and that's the whole reason why we are orchestrating the deploys/upgrade with ansible.

Re: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project

+1 From: Jeffrey Zhang [mailto:zhang.lei@gmail.com] Sent: Wednesday, April 18, 2018 10:52 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [kolla][vote]Retire kolla-kubernetes project Since many of the contributors in the kolla-kubernetes