[Openstack] kolla-ansible (queens) questions

Hello, I'm testing kolla-ansible queens deployment. In some reason Orchestration menu is not available in Horizon for Queens, though its available for Pike with the same settings(global.yml and inventory) Can you provide any hints about that ? Also I would like to review the feature: "HOT drag

Re: [openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

Richard Wellum wrote: > So as a current Kolla-Kubernetes Core - I have a slightly different > opinion than most, I'll try to verbalize it coherently. Thanks Rich for posting this -- I was really feeling like we missed part of the story. > Lets talk about what Kolla is: > > Kolla is a project

Re: [openstack-dev] [requirements] Adding objgraph to global requirements

On 29 Mar 2018, 20:20 +0700, Doug Hellmann , wrote: > What sorts of tools are you talking about building? Well, some more high level functions to diagnose memory usage, especially aids to help find memory leaks. Or not even necessary memory leaks, we may also want/need

Re: [openstack-dev] [nova] The createBackup API

On Fri, Mar 30, 2018 at 11:44 AM, Alex Xu wrote: > There is spec proposal to fix a bug of createBackup API with microversion. > (https://review.openstack.org/#/c/511825/) > > When rotation parameter is '0', the createBackup API just do a snapshot, and > then delete all the

[openstack-dev] [keystone] Keystone Team Update - Week of 26 March 2018

# Keystone Team Update - Week of 26 March 2018 ## News ### JSON Web Tokens Lance found an interesting article denouncing JWT[1][2] which, in an ironic twist, also advocated fernet as an alternative. We're still plowing forward on the JWT spec[3], but we need to be very precise in our design

Re: [openstack-dev] [nova][oslo] what to do with problematic mocking in nova unit tests

Anyone? > On Mar 28, 2018, at 1:26 PM, Doug Hellmann wrote: > > In the course of preparing the next release of oslo.config, Ben noticed > that nova's unit tests fail with oslo.config master [1]. > > The underlying issue is that the tests mock things that oslo.config > is

[openstack-dev] [tc] Technical Committee Status update, March 30th

Hi! This is the weekly summary of Technical Committee initiatives. You can find the full list of currently-considered changes at: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at:

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

> While at it, we should also discuss about what will be the NEXT_MIN > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > spent going through different distributions and updated the >

[openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Solar" release

The last version bump was in "Pike" release (commit: b980df0, 11-Feb-2017), and we didn't do any bump during "Queens". So it's time to increment the versions (which will also makes us get rid of some backward compatibility cruft), and pick future versions of libvirt and QEMU.

[openstack-dev] [nova] [placement] placement update 18-13

This is an "expand" style update. Meaning I'm actively searching for code and specs that didn't show up on last week's update (which was a "contract"). # Most Important What's pretty obvious from this expand session is we probably have way too much work in progress for the number of people

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

On Fri, 30 Mar 2018 at 08:45 Paul Grist wrote: > On Thu, Mar 29, 2018 at 5:32 PM, Emilien Macchi > wrote: > >> Greeting folks, >> >> During the last PTG we spent time discussing some ideas around an >> All-In-One installer, using 100% of the TripleO bits

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

> While at it, we should also discuss about what will be the NEXT_MIN > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > spent going through different distributions and updated the >

[Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

The last version bump was in "Pike" release (commit: b980df0, 11-Feb-2017), and we didn't do any bump during "Queens". So it's time to increment the versions (which will also makes us get rid of some backward compatibility cruft), and pick future versions of libvirt and QEMU.

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

> -Original Message- > From: Emilien Macchi [mailto:emil...@redhat.com] > Sent: Thursday, March 29, 2018 5:33 PM > To: OpenStack Development Mailing List d...@lists.openstack.org> > Subject: [openstack-dev] [tripleo] PTG session about All-In-One installer: > recap & roadmap > >

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

On Thu, Mar 29, 2018 at 5:32 PM, Emilien Macchi wrote: > Greeting folks, > > During the last PTG we spent time discussing some ideas around an > All-In-One installer, using 100% of the TripleO bits to deploy a single > node OpenStack very similar with what we have today with

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

;) On Fri, Mar 30, 2018 at 9:49 AM, Sean McGinnis wrote: > > While at it, we should also discuss about what will be the NEXT_MIN > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > spent going through different distributions and updated the > >

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

And just an aside, the All-in-ones are great tools for new operators to be able to get in and learn how to use OpenStack, even if the underlying configuration isn't a multi-node installation. Amy (spotz) On Fri, Mar 30, 2018 at 10:53 AM, Wesley Hayutin wrote: > > > On Fri,

Re: [openstack-dev] [ironic] baremetal firmware lifecycle management

We've experienced different firmware update approaches.. this is a wish list rather than a requirement since in the end, it can all be scripted if needed. Currently, these are manpower intensive and require a lot of co-ordination since the upgrade operation has to be performed by the hardware

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

;) On Fri, Mar 30, 2018 at 9:49 AM, Sean McGinnis wrote: > > While at it, we should also discuss about what will be the NEXT_MIN > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > spent going through different distributions and updated the > >

[openstack-dev] [placement] Anchor/Relay Providers

Folks who care about placement (but especially Jay and Tetsuro)- I was reviewing [1] and was at first very unsatisfied that we were not returning the anchor providers in the results. But as I started digging into what it would take to fix it, I realized it's going to be nontrivial. I wanted to

Re: [openstack-dev] [cinder][nova] about re-image the volume

On 3/29/2018 8:36 PM, Matt Riedemann wrote: On 3/29/2018 6:50 PM, Sean McGinnis wrote: May we can add a "Reimaging" state to the volume? Then Nova could poll for it to go from that back to Available? That would be fine with me, and maybe similar to how 'extending' and 'retyping' work for

Re: [openstack-dev] [requirements] Adding objgraph to global requirements

On Mar 30, 2018, at 4:08 AM, Renat Akhmerov > wrote: > On 29 Mar 2018, 20:20 +0700, Doug Hellmann >, wrote: > >> What sorts of tools are you talking about building? > > Well,

Re: [openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

On March 30, 2018 at 2:17:09 AM, Thierry Carrez (thie...@openstack.org) wrote: There is a 3rd option, which I've been advocating for a while. The tension here lies in the fact that the Kolla team is both a low-level provider (Kolla the docker image provider) and a