June 2019 - openstack-discuss - lists.openstack.org

RE: '[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
by Kumari, Madhuri 07 Jun '19

07 Jun '19

Hi Eric, >-----Original Message----- >From: Eric Fried [mailto:openstack@fried.cc] >Waitwait. The VM needs to be rebooted for the BIOS change to take effect? >So (non-live) resize would actually satisfy your use case just fine. But the >problem is that the ironic driver doesn't support resize at all? > Yes you're right here. But the resize in Nova does migration which we don't want to do. Just apply the new traits and IronicDriver will run the matching deploy steps. >Without digging too hard, that seems like it would be a fairly straightforward >thing to add. It would be limited to only "same host" >and initially you could only change this one attribute (anything else would >have to fail). > >Nova people, thoughts? > >efried >. Regards, Madhuri

1 0

[nova] Validation for requested host/node on server create
by Matt Riedemann 06 Jun '19

06 Jun '19

It seems we've come to an impasse on this change [1] because of a concern about where to validate the requested host and/or hypervisor_hostname. The change is currently validating in the API to provide a fast fail 400 response to the user if the host and/or node don't exist. The concern is that the lookup for the compute node will be done again in the scheduler [2]. Also, if the host is not provided, then to validate the node we have to iterate the cells looking for the given compute node (we could use placement though, more on that below). I've added this to the nova meeting agenda for tomorrow but wanted to try and enumerate what I see are the options before the meeting so we don't have to re-cap all of this during the meeting. The options as I see them are: 1. Omit the validation in the API and let the scheduler do the validation. Pros: no performance impact in the API when creating server(s) Cons: if the host/node does not exist, the user will get a 202 response and eventually a NoValidHost error which is not a great user experience, although it is what happens today with the availability_zone forced host/node behavior we already have [3] so maybe it's acceptable. 2. Only validate host in the API since we can look up the HostMapping in the API DB. If the user also provided a node then we'd just throw that on the RequestSpec and let the scheduler code validate it. Pros: basic validation for the simple and probably most widely used case since for non-baremetal instances the host and node are going to be the same Cons: still could have a late failure in the scheduler with NoValidHost error; does not cover the case that only node (no host) is specified 3. Validate both the host and node in the API. This can be broken down: a) If only host is specified, do #2 above. b) If only node is specified, iterate the cells looking for the node (or query a resource provider with that name in placement which would avoid down cell issues) c) If both host and node is specified, get the HostMapping and from that lookup the ComputeNode in the given cell (per the HostMapping) Pros: fail fast behavior in the API if either the host and/or node do not exist Cons: performance hit in the API to validate the host/node and redundancy with the scheduler to find the ComputeNode to get its uuid for the in_tree filtering on GET /allocation_candidates. Note that if we do find the ComputeNode in the API, we could also (later?) make a change to the Destination object to add a node_uuid field so we can pass that through on the RequestSpec from API->conductor->scheduler and that should remove the need for the duplicate query in the scheduler code for the in_tree logic. I'm personally in favor of option 3 since we know that users hate NoValidHost errors and we have ways to mitigate the performance overhead of that validation. Note that this isn't necessarily something that has to happen in the same change that introduces the host/hypervisor_hostname parameters to the API. If we do the validation in the API I'd probably split the validation logic into it's own patch to make it easier to test and review on its own. [1] https://review.opendev.org/#/c/645520/ [2] https://github.com/openstack/nova/blob/2e85453879533af0b4d0e1178797d26f026a… [3] https://docs.openstack.org/nova/latest/admin/availability-zones.html -- Thanks, Matt

4 6

[goal][python3] Train unit tests weekly update (goal-14)
by Corey Bryant 06 Jun '19

06 Jun '19

This is the goal-14 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 14 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. That is the main goal. Other work items will consist of: * Dropping py35 and old py3 zuul templates (e.g. drop 'openstack-python35-jobs', 'openstack-python36-jobs', 'openstack-python37-jobs', etc) * Updating setup.cfg classifiers (e.g. drop 'Programming Language :: Python :: 3.5' and add 'Programming Language :: Python :: 3.7') * Updating the list of default tox.ini environment (e.g. drop py35 and add py37) For complete details please see [1]. == Role of Goal Champion == Ensure patches are proposed to all affected repositories, encourage teams to help land patches, and report weekly status. == Role of Project Teams == Fix failing tests so that the proposed patches can merge. Project teams should merge the change to the Zuul config before the end of the Train cycle. == Ongoing Work == I will be the goal champion for this goal. I'm just getting organized at this point. Over the next week I plan to get scripts working to automate patch generation for all supported projects and start submitting patches. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged (Wow, look at that! Thanks Zhong Shengping.) == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your project(s). Python 3.7 unit tests will be self-testing in zuul. If you're interested in helping submit patches, please let me know. Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… == Reference Material == [1] Goal description: https://review.opendev.org/#/c/657908 [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/board/<TBD> Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?
by Matt Riedemann 06 Jun '19

06 Jun '19

On 8/18/2018 10:09 PM, Matt Riedemann wrote: >> This sounds promising and there seems to be a feasible way to do this, >> but it also sounds like a decent amount of effort and would be a new >> feature in a future release rather than a bugfix - am I correct in >> that assessment? > > Yes I'd say it's a blueprint and not a bug fix - it's not something we'd > backport to stable branches upstream, for example. Just an update on this since it came up in IRC today (unrelated discussion which reminded me of this thread), Kashyap has created a nova blueprint: https://blueprints.launchpad.net/nova/+spec/pick-guest-arch-based-on-host-a… -- Thanks, Matt

1 0

[tc] Recap for Technical Committee Meeting 6 June 2019 @ 1400 UTC
by Alexandra Settle 06 Jun '19

06 Jun '19

Hello all, Thanks to those who joined the TC meeting today and running through it with me at the speed of light. Gif game was impeccably strong and that's primarily what I like about this community. For a recap of the meeting, please see the eavesdrop [0] for full detailed logs and action items. All items in the agenda [1] were covered and no major concerns raised. Next meeting will be on the 8th of July 2019. Cheers, Alex [0] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-06-06-14.00.txt [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006877.html

1 0

[blazar] IRC meeting today
by Pierre Riteau 06 Jun '19

06 Jun '19

Hello, We have our biweekly Blazar IRC meeting in less than one hour: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_06_Jun_2019_.28A… We have the opportunity of discussing further how we can enforce policies for limiting reservation usage. I would also like to discuss downstream patches which could be contributed to the project. Everyone is welcome to join. Cheers, Pierre

1 0

[tc][kolla][kayobe] Feedback request: kayobe seeking official status
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, The Kayobe project [1] seeks to become an official OpenStack project during the Train cycle. Kayobe is a deployment tool that uses Kolla Ansible and Bifrost to deploy a containerised OpenStack control plane to bare metal. The project was started 2 years ago to fill in some gaps in Kolla Ansible, and has since been used for a number of production deployments. It's frequently deployed in Scientific Computing environments, but is not limited to this. We ran a packed workshop on Kayobe at the Denver summit and got some great feedback, with many people agreeing that it makes Kolla Ansible easier to adopt in environments with no existing provisioning system. We use OpenStack development workflows, including IRC, the mailing list, opendev, zuul, etc. We see two options for becoming an official OpenStack project: 1. become a deliverable of the Kolla project 2. become an official top level OpenStack project Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach. There is currently only one person (me) who is a member of both core teams, although all kayobe cores are active in the Kolla community. I would not expect core memberships to change, although we would probably end up combining IRC channels, meetings and design sessions. I would hope that combining these communities would be to the benefit of both. Please provide feedback on this matter - whether positive or negative. Thanks, Mark [1] http://kayobe.readthedocs.io

4 4

[horizon] dropping 2012.2 tag on pypi
by Guilherme Steinmüller 06 Jun '19

06 Jun '19

Hello, As we've discussed with nova tag recently [1], I'd suggest the same for horizon. When we search on pypi the version it shows is 2012.2 and when we click release history we can see that the most recent version is 15.1.0 [2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006780.html [2] https://pypi.org/project/horizon/#history Regards, Guilherme Steinmuller

3 2

[cloudkitty] Shift IRC meeting of June 7th
by Luka Peschke 06 Jun '19

06 Jun '19

Hi all, Tomorrow's IRC meeting for CloudKitty will be held at 14h UTC (16 CEST) instead of 15h UTC as huats and I won't be available at 15h. Cheers, -- Luka Peschke

1 0

[glance] zeroing image, preserving other parameters
by Volodymyr Litovka 06 Jun '19

06 Jun '19

Dear colleagues, for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database. First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead. Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)" I found https://docs.openstack.org/glance/rocky/contributor/database_architecture.h…'s "image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions? Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 3