- openstack-discuss - lists.openstack.org

[TC] [UC] Volunteers for Forum Selection Committee
by Jimmy McArthur 07 Feb '19

07 Feb '19

Hello! We need 2 volunteers from the TC and 2 from the UC for the Denver Forum Selection Committee. For more information, please see: https://wiki.openstack.org/wiki/Forum Please reach out to myself or knelson(a)openstack.org if you're interested. Volunteers should respond before Feb 15, 2019. Note: volunteers are required to be currently serving on either the UC or the TC. Cheers, Jimmy

1 0

[release] Release countdown for week R-8, February 11-15
by Sean McGinnis 07 Feb '19

07 Feb '19

Your long awaited countdown email... Development Focus ----------------- It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly so avoid any last minute rushes to get key functionality in. General Information ------------------- We have a few deadlines coming up as we get closer to the end of the cycle: * Non-client libraries (generally, any library that is not python-${PROJECT}client) must have a final release by February 28. Only critical bugfixes will be allowed past this point. Please make sure any important feature works has required library changes by this time. * Client libraries must have a final release by March 7. We will be proposing a few patches to switch some cycle-with-intermediary deliverables over to cycle-with-rc if they are not actually doing intermediary releases. PTLs and release liaisons, please watch for being added to any of those reviews. If the switch is not desired, this is a good time to do an intermediary release if you have been putting it off. More information can be found in our post to the mailing list back in December: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… It is also a good time to start planning what highlights you want for your project team in the cycle highlights: Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Stein-3 milestone: March 7 -- Sean McGinnis (smcginnis)

1 0

[nova][dev] project self-evaluation against TC technical vision
by melanie witt 07 Feb '19

07 Feb '19

Howdy everyone, About a month ago, the TC sent out a mail [1] asking projects to complete a self-evaluation exercise against the technical vision for OpenStack clouds, published by the TC [2]. The self-evaluation is to be added to our in-tree docs as a living document to be updated over time as things change. To paraphrase from [1], the intent of the exercise is to help projects identify areas they can work on to improve alignment with the rest of OpenStack. The doc should be a concise, easily consumable list of things that interested contributors can work on. Here are examples of vision reflection documents: * openstack/ironic: https://review.openstack.org/629060 * openstack/placement: https://review.openstack.org/630216 I have created an etherpad for us to use to fill in ideas for our vision reflection document: https://etherpad.openstack.org/p/nova-tc-vision-self-eval I'd like to invite everyone in the nova community including operators, users, and developers to join the etherpad and share their thoughts on how nova can improve its alignment to the technical vision for OpenStack clouds. Feel free to add or modify sections as you like. And once we've collected ideas for the doc, I (or anyone) can propose a doc patch to openstack/nova, to be included with our in-tree documentation. Cheers, -melanie [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.… [2] https://governance.openstack.org/tc/reference/technical-vision.html

1 0

OpenStack Foundation 2018 Annual Report
by Allison Price 07 Feb '19

07 Feb '19

Hi everyone, Today, we have published the OpenStack Foundation 2018 Annual Report [1], a yearly report highlighting the incredible work and advancements being achieved by the community. Thank you to all of the community contributors who helped pull the report together. Read the latest on: The Foundation’s latest initiatives to support Open Infrastructure Project updates from the OpenStack, Airship, Kata Containers, StarlingX, and Zuul communities Highlights from OpenStack Workings Groups and SIGs Community programs including OpenStack Upstream Institute, the Travel Support Program, Outreachy Internship Programs, and Contributor recognition OpenStack Foundation events including PTGs, Forums, OpenStack / OpenInfra Days, and the OpenStack Summit With almost 100,000 individual members, our community accomplished a lot last year. If you would like to continue to stay updated in the latest Foundation and project news, subscribe to the bi-weekly Open Infrastructure newsletter [2]. We look forward to another successful year in 2019! Cheers, Allison [1] https://www.openstack.org/foundation/2018-openstack-foundation-annual-report <https://www.openstack.org/foundation/2018-openstack-foundation-annual-report> [2] https://www.openstack.org/community/email-signup <https://www.openstack.org/community/email-signup> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[ironic] Hardware leasing with Ironic
by Lars Kellogg-Stedman 07 Feb '19

07 Feb '19

Howdy. I'm working with a group of people who are interested in enabling some form of baremetal leasing/reservations using Ironic. There are three key features we're looking for that aren't (maybe?) available right now: - multi-tenancy: in addition to the ironic administrator, we need to be able to define a node "owner" (someone who controls a specific node) and a node "consumer" (someone who has been granted temporary access to a specific node). An "owner" always has the ability to control node power or access the console, can mark a node as available or not, and can set lease policies (such as a maximum lease lifetime) for a node. A "consumer" is granted access to power control and console only when they hold an active lease, and otherwise has no control over the node. - leasing: a mechanism for marking nodes as available, requesting nodes for a specific length of time, and returning those nodes to the available pool when a lease has expired. - hardware only: we'd like the ability to leave os provisioning up to the "consumer". For example, after someone acquires a node via the leasing mechanism, they can use Foreman to provisioning an os onto the node. For example, a workflow might look something like this: - The owner of a baremetal node makes the node part of a pool of available hardware. They set a maximum lease lifetime of 5 days. - A consumer issues a lease request for "3 nodes with >= 48GB of memory and >= 1 GPU" and "1 node with >= 16GB of memory and >= 1TB of local disk", with a required lease time of 3 days. - The leasing system finds available nodes matching the hardware requirements and with owner-set lease policies matching the lease lifetime requirements. - The baremetal nodes are assigned to the consumer, who can then attach them to networks and make use of their own provisioning tools (which may be another Ironic instance?) to manage the hardware. The consumer is able to control power on these nodes and access the serial console. - At the end of the lease, the nodes are wiped and returned to the pool of available hardware. The previous consumer no longer has any access to the nodes. Our initial thought is to implement this as a service that sits in front of Ironic and provides the multi-tenancy and policy logic, while using Ironic to actually control the hardware. Does this seem like a reasonable path forward? On paper there's a lot of overlap here between what we want and features provided by things like the Nova schedulers or the Placement api, but it's not clear we can leverage those at the baremetal layer. Thanks for your thoughts, -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

7 21

[tc] agenda for upcoming TC meeting on 7 Feb
by Doug Hellmann 07 Feb '19

07 Feb '19

TC Members, Our next meeting will be on Thursday, 7 Feb at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. * corrections to TC member election section of bylaws are completed (fungi, dhellmann) * status update for project team evaluations based on technical vision (cdent, TheJulia) * defining the role of the TC (cdent, ttx) * keeping up with python 3 releases (dhellmann, gmann) * status update of Train cycle goals selection update (lbragstad, evrardjp) * TC governance resolution voting procedures (dhellmann) * upcoming TC election (dhellmann) * review proposed OIP acceptance criteria (dhellmann, wendar) * TC goals for Stein (dhellmann) [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee -- Doug

1 1

[nova] [placement] extraction checkin meeting at 1700 UTC today
by Chris Dent 07 Feb '19

07 Feb '19

A reminder that as discussed at the last placement extraction checkin meeting [1] we've got another one today at 1700 UTC. Join the #openstack-placement IRC channel around then if you are interested, and a google hangout url will be provided. In the thread with the notes, there was a question that didn't get answered [2] in email and remains open as far as I know. There's an etherpad [3] with pending extraction related tasks. If you've done some of the work on there, please make sure it is up to date. From that, it appears that the main pending things are deployment (with upgrade) and the vgpu reshaper work (which is close). Note that the main question we're trying to answer here is "when can we delete the nova code?", which is closely tied to the unanswered question [2] mentioned above. We are already using the extracted code in the integrate gate and we are not testing the unextracted code anywhere. [1] notes from the last meeting are at http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001789.… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001805.… [3] https://etherpad.openstack.org/p/placement-extract-stein-5 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[charms][zuul] State of external GitHub dependencies
by Frode Nordahl 07 Feb '19

07 Feb '19

Hello all, <tl;dr> The Charms projects are increasingly heavy users of external GitHub dependencies, and we are facing intermittent issues with this at the gate. Does anyone have ideas as to how we should handle this from the point of view of Charm teams? Anyone from Zuul have ideas/pointers on how we could help improve the external GitHub dependency support? </tl;dr> As many of you know the OpenStack Charms project is in the process of replacing the framework for performing functional deployment testing of Charms with ``Zaza`` [0]. Two of the key features of the Zaza framework is reusability of tests simply by referencing already written tests with a Python module path in a test definition in a YAML file, and general applicability across other Charms, not just OpenStack specific ones. Because of this the Zaza project, which also contains the individual functional test modules, is hosted on GitHub and not on the OpenStack Infrastructure. Whenever a change is proposed to a charm that require new or changes to existing functional tests, we need a effective way for the individual contributor to have their Charm change (which is proposed on OpenStack Infrastructure) tested with code from their Zaza change (which is proposed as a PR on GitHub). We have had some success with adding ``Depends-On:`` and the full URL to the GitHub PR in the commit message. There is experimental support for using that as a gate check in Zuul, and Canonical's third party Charm CI is configured to pull the correct version of Zaza based on Depends-On referencing GitHub PRs. However, we often have to go through extra hoops to land things as the gate code appears to not always successfully handle GitHub PR references in Depends-On. For reference, after discussion in #openstack-infra I got a log excerpt [1] and a reference to a WIP PR [2] that might be relevant. 0: https://zaza.readthedocs.io/en/latest/ 1: http://paste.openstack.org/show/744664/ 2: https://review.openstack.org/#/c/613143/ -- Frode Nordahl

1 1

[nova][queens] qeumu-guest-agent
by Ignazio Cassano 07 Feb '19

07 Feb '19

Hello, is it possible to force metadata for instances like the following ? hw_qemu_guest_agent='yes' os_require_quiesce='yes' I know if an instance is created from an image with the above metadata the quemu-guest-agent works, but sometimes instances can start from volumes ( for example after a cnder backup). Regards Ignazio

2 5

[TC][Searchlight] Project health evaluation
by Trinh Nguyen 07 Feb '19

07 Feb '19

Hi TC members and Searchlight team, As we discussed at the beginning of the Stein cycle, Searchlight would go through a propagation period to consider whether to let it continue to operate under the OpenStack foundation's umbrella [1]. For the last two milestones, we have achieved some results [2] [3] and designed a sustainable future for Searchlight with a vision [4]. As we're reaching the Stein-3 milestone [5] and preparing for the Denver summit. We, as a team, would like have a formal project health evaluation in several aspects such as active contributors / team, planning, bug fixes, features, etc. We would love to have some voice from the TC team and anyone from the community who follows our effort during the Stein cycle. We then would want to update the information at [6] and [7] to avoid any confusion that may stop potential contributors or users to come to Searchlight. [1] https://review.openstack.org/#/c/588644/ [2] https://www.dangtrinh.com/2018/10/searchlight-at-stein-1-weekly-report.html [3] https://www.dangtrinh.com/2019/01/searchlight-at-stein-2-r-14-r-13.html [4] https://docs.openstack.org/searchlight/latest/user/usecases.html#our-vision [5] https://releases.openstack.org/stein/schedule.html [6] https://governance.openstack.org/election/results/stein/ptl.html [7] https://wiki.openstack.org/wiki/OpenStack_health_tracker Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2