May 2019 - openstack-discuss - lists.openstack.org

[placement][nova][ptg] Summary: Consumer Types
by Chris Dent 09 May '19

09 May '19

We had a brief conversation in the placement room yesterday (Saturday May 5th) to confirm we were all on the same page with regard to consumer types. These provide a way to say that a set of allocations "is an instance" or "is a migration" and will help with quota accounting. We decided that since no one has stepped forward with a more complicated scenario, at this time, we will go with the simplest implementation, for now: * add a consumer types table that has a key and string (length to be determined, values controlled by clients) that represents a "type". For example (1, 'instance') * add a column on consumer table that takes one of those keys * create a new row in the types table only when a new type is created, don't worry about expiring them * provide an online migration to default existing consumers to 'instance' and treat unset types as 'instance' [1]. This probably needs some confirmation from mel and others that it is suitable. If not, please provide an alternative suggestion. * In a new microversion: allow queries to /usages to use a consumer type parameter to limit results to particular types and add 'consumer_type' key will be added to the body of an 'allocations' in both PUT and POST. * We did not discuss in the room, but the email thread [2] did: We may need to consider grouping /usages results by type but we could probably get by without changing that (and do multiple requests, sometimes). Surya, thank her very much, has volunteered to work on this and has started a spec at [3]. We have decided, again due to lack of expressed demand, to do any work (at this time) related to resource provider partitioning [4]. There's a pretty good idea on how to do this, but enough other stuff going on there's not time. Because we decided in that thread that any one resource provider can only be in one partition, there is also a very easy workaround: Run another placement server. It takes only a few minutes to set one up [5] This means that all of the client services of a single placement service need to coordinate on what consumer types they are using. (This was already true, but stated here for emphasis.) [1] I'm tempted to test how long a million or so rows of consumers would take to update. If it is short enough we may wish to break with the nova tradition of not doing data migrations in schema migrations (placement-manage db sync). But we didn't get a chance to discuss that in the room. [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.ht… [3] https://review.opendev.org/#/c/654799/ [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004721.ht… [5] https://docs.openstack.org/placement/latest/install/from-pypi.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 6

[cinder][ops] Nested Quota Driver Use?
by Sean McGinnis 09 May '19

09 May '19

Hey everyone, I'm hoping to get some feedback from folks, especially operators. In the Liberty release, Cinder introduced the ability to use a Nest Quota Driver to handle cases of heirarchical projects and quota enforcement [0]. I have not heard of anyone actually using this. I also haven't seen any bugs filed, which makes me a little suspicious given how complicated it can be. I would like to know if any operators are using this for nested quotas. There is an effort underway for a new mechanism called "unified limits" that will require a lot of modifications to the Cinder code. If this quota driver is not needed, I would like to deprecated it in Train so it can be removed in the U release and hopefully prevent some unnecessary work being done. Any feedback on this would be appreciated. Thanks! Sean [0] https://specs.openstack.org/openstack/cinder-specs/specs/liberty/cinder-nes…

4 4

topic: ironic boot from cinder volume(the cinder volume backend is ceph storage)
by 陈杰 09 May '19

09 May '19

Nowdays , the opestack rocky release ironic , is support ironic boot from cinder volume(the cinder volume backend is ceph storage)? My goal is to achieve this. Who can tell me about this principle? looking forward to a reply thank you all.

4 9

[nova] Stein regressions
by Matt Riedemann 09 May '19

09 May '19

Hey cool cats, I know we just released Stein last week so what better time to write an email about a bunch of Stein regressions?! I wanted to dump this in the list so (a) I don't lose track of them all and (b) other people are aware and get involved. In no particular order: 1. https://bugs.launchpad.net/nova/+bug/1822801 There is a patch being worked: https://review.openstack.org/#/c/649345/ The workaround for this would be to disable the _heal_instance_info_cache periodic in nova-compute services that manage baremetal nodes by setting the heal_instance_info_cache_interval value to 0. 2. https://bugs.launchpad.net/nova/+bug/1824435 We have a re-create scenario for this in devstack (noted in the bug report). I've been unable to recreate in a functional test, possibly because of how sqlite deals with NULL values in unique constraints differently from mysql. I would have thought this regression test [1] would have hit it but it didn't. There are some options for fixing this, some more hacky than others, e.g.: https://review.openstack.org/#/c/653065/ Need some input from others on fixing that bug in maybe a less hacky way. 3. https://bugs.launchpad.net/nova/+bug/1825034 I found this when writing [1] to try and recreate the previous bug 1824435. I have a series up for this starting with a recreate patch [1]. The fix on top is one of a few options I detailed in the bug report. It's not pretty but it works. The workaround for this would be to archive deleted records but you'd have to do that after each run of the online data migration which is not great. 4. https://bugs.launchpad.net/nova/+bug/1825020 I just triaged this a couple of hours ago. I plan on writing a functional regression recreate test since the recreate scenario seems pretty easy - try to resize a volume-backed server where the new flavor has a smaller disk than the old flavor. The fix should also be relatively straight-forward. -- Once we get fixes landed and backported to stable/stein for these bugs we should do a patch release ASAP. [1] https://review.openstack.org/#/c/653098/ -- Thanks, Matt

1 2

Re: [nova][ptg] Summary: Resource Management Daemon
by Eric Fried 09 May '19

09 May '19

> [1] There has been a recurring theme of needing "some kind of config" - > not necessarily nova.conf or any oslo.config - that can describe: > - Resource provider name/uuid/parentage, be it an existing provider or a > new nested provider; > - Inventory (e.g. last-level cache in this case); > - Physical resource(s) to which the inventory corresponds (e.g. "cache > ways" in this case); > - Traits, aggregates, other? > As of this writing, no specifics have been decided, even to the point of > positing that it could be the same file for some/all of the specs for > which the issue arose. A proposal extremely close to this has been in the works in various forms for about a year now, the latest iteration of which can be found at [2]. Up to this point, there has been a general lack of enthusiasm for it, probably because we just didn't have any really strong use cases yet. I think we do now, given that RMD and others (including [3]) have expressed a need for it in Train. As such, Dakshina and team have agreed to take over that spec and move forward with it. To be clear, this will drive toward a general-purpose resource provider customization/description mechanism, not be RMD-specific. efried [2] https://review.opendev.org/#/c/612497/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005802.html

1 0

[nova][ptg] Summary: Tech Debt
by Eric Fried 09 May '19

09 May '19

Tech debt items we discussed, and actions to be taken thereon: - Remove cellsv1: (continue to) do it [1] - Remove nova-network: do it - Remove the nova-console, nova-consoleauth, nova-xvpxvncproxy services: do it - Migrating rootwrap to privsep: (continue to) do it [2] - Bump the minimum microversion: don't do it - Remove mox: (continue to) do it [3] It's possible I missed some; if so, please reply. efried [1] https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma… [2] https://review.opendev.org/#/q/project:openstack/nova+branch:master+topic:m… [3] https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma…

2 1

[ops][nova]Logging in nova and other openstack projects
by Jean-Philippe Méthot 09 May '19

09 May '19

Hi, We’ve been modifying our login habits for Nova on our Openstack setup to try to send only warning level and up logs to our log servers. To do so, I’ve created a logging.conf and configured logging according to the logging module documentation. While what I’ve done works, it seems to be a very convoluted process for something as simple as changing the logging level to warning. We worry that if we upgrade and the syntax for this configuration file changes, we may have to push more changes through ansible than we would like to. Is there an easier way to set the nova logs to warning level and up than making an additional config file for the python logging module? Best regards, Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

3 8

[nova][ops] 'Duplicate entry for primary key' problem running nova-manage db archive_deleted_rows
by Massimo Sgaravatto 09 May '19

09 May '19

Hi Fron time to time I use to move entries related to deleted instances to shadow tables, using the command: nova-manage db archive_deleted_rows This is now failing [*] for the instance_metadata table because of a 'duplicate entry for the primary key' problem: DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, u"Duplicate entry '6' for key 'PRIMARY'") [SQL: u'INSERT INTO shadow_instance_metadata (created_at, updated_at, deleted_at, deleted, id, `key`, value, instance_uuid) SELECT instance_metadata.created_at, instance_metadata.updated_at, instance_metadata.deleted_at, instance_metadata.deleted, instance_metadata.id, instance_metadata.`key`, instance_metadata.value, instance_metadata.instance_uuid \nFROM instance_metadata \nWHERE instance_metadata.deleted != %(deleted_1)s ORDER BY instance_metadata.id \n LIMIT %(param_1)s'] [parameters: {u'param_1': 1, u'deleted_1': 0}] Indeed: mysql> SELECT instance_metadata.created_at, instance_metadata.updated_at, instance_metadata.deleted_at, instance_metadata.deleted, instance_metadata.id, instance_metadata.`key`, instance_metadata.value, instance_metadata.instance_uuid FROM instance_metadata WHERE instance_metadata.deleted != 0 ORDER BY instance_metadata.id limit 1; +---------------------+------------+---------------------+---------+----+-------+-------+--------------------------------------+ | created_at | updated_at | deleted_at | deleted | id | key | value | instance_uuid | +---------------------+------------+---------------------+---------+----+-------+-------+--------------------------------------+ | 2018-09-20 07:40:56 | NULL | 2018-09-20 07:54:26 | 6 | 6 | group | node | a9000ff7-2298-454c-bf71-9e3c62ec0f3c | +---------------------+------------+---------------------+---------+----+-------+-------+--------------------------------------+ 1 row in set (0.00 sec) But there is a 5-years old entry (if I am not wrong we were running Havana at that time) in the shadow table with that id: mysql> select * from shadow_instance_metadata where id='6'; +---------------------+------------+---------------------+----+----------+---------------------+--------------------------------------+---------+ | created_at | updated_at | deleted_at | id | key | value | instance_uuid | deleted | +---------------------+------------+---------------------+----+----------+---------------------+--------------------------------------+---------+ | 2014-11-04 12:57:10 | NULL | 2014-11-04 13:06:45 | 6 | director | microbosh-openstack | 5db5b17b-69f2-4f0a-bdd2-efe710268021 | 6 | +---------------------+------------+---------------------+----+----------+---------------------+--------------------------------------+---------+ 1 row in set (0.00 sec) mysql> I wonder how could that happen. Can I simply remove that entry from the shadow table (I am not really interested to keep it) or are there better (cleaner) way to fix the problem ? This Cloud is now running Ocata Thanks, Massimo [*] [root@cld-ctrl-01 ~]# nova-manage db archive_deleted_rows --max_rows 1000 --verbose An error has occurred: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nova/cmd/manage.py", line 1617, in main ret = fn(*fn_args, **fn_kwargs) File "/usr/lib/python2.7/site-packages/nova/cmd/manage.py", line 691, in archive_deleted_rows run = db.archive_deleted_rows(max_rows) File "/usr/lib/python2.7/site-packages/nova/db/api.py", line 2040, in archive_deleted_rows return IMPL.archive_deleted_rows(max_rows=max_rows) File "/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 6564, in archive_deleted_rows tablename, max_rows=max_rows - total_rows_archived) File "/usr/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", line 6513, in _archive_deleted_rows_for_table conn.execute(insert) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement compiled_sql, distilled_params File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1337, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 200, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) File "/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 165, in execute result = self._query(query) File "/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 321, in _query conn.query(q) File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 860, in query self._affected_rows = self._read_query_result(unbuffered=unbuffered) File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1061, in _read_query_result result.read() File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1349, in read first_packet = self.connection._read_packet() File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 1018, in _read_packet packet.check_error() File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 384, in check_error err.raise_mysql_exception(self._data) File "/usr/lib/python2.7/site-packages/pymysql/err.py", line 107, in raise_mysql_exception raise errorclass(errno, errval) DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, u"Duplicate entry '6' for key 'PRIMARY'") [SQL: u'INSERT INTO shadow_instance_metadata (created_at, updated_at, deleted_at, deleted, id, `key`, value, instance_uuid) SELECT instance_metadata.created_at, instance_metadata.updated_at, instance_metadata.deleted_at, instance_metadata.deleted, instance_metadata.id, instance_metadata.`key`, instance_metadata.value, instance_metadata.instance_uuid \nFROM instance_metadata \nWHERE instance_metadata.deleted != %(deleted_1)s ORDER BY instance_metadata.id \n LIMIT %(param_1)s'] [parameters: {u'param_1': 1, u'deleted_1': 0}] [root@cld-ctrl-01 ~]#

3 3

[Neutron] Can I create VM on flat network which doesnt have any subnet attached to it.
by Akki yadav 09 May '19

09 May '19

Hello Team, Hope you all are doing good. I wanted to know that can I launch a VM on a flat network directly which doesn't have any subnet attached to it. Steps to be followed: Create a flat Network without a subnet Attach the network to create a VM. Aim :- Spawn 2 VM's on network without any subnet, without any IP assigned to them. Then statically allocate same subnet IP to them and ping each other. Issue:- VM creation is getting failed stating that there is no subnet found. How can we resolve this? Thanks & Regards Akshay

2 1

[ironic] My PTG & Forum notes
by Dmitry Tantsur 08 May '19

08 May '19

Hi folks, I've published my personal notes from the PTG & Forum in Denver: https://dtantsur.github.io/posts/ironic-denver-2019/ They're probably opinionated and definitely not complete, but I still think they could be useful. Also pasting the whole raw RST text below for ease of commenting. Cheers, Dmitry Keynotes ======== The `Metal3`_ project got some spotlight during the keynotes. A (successful!) `live demo`_ was done that demonstrated using Ironic through Kubernetes API to drive provisioning of bare metal nodes. The official `bare metal program`_ was announced to promote managing bare metal infrastructure via OpenStack. Forum: standalone Ironic ======================== On Monday we had two sessions dedicated to the future development of standalone Ironic (without Nova or without any other OpenStack services). During the `standalone roadmap session`_ the audience identified two potential domains where we could provide simple alternatives to depending on OpenStack services: * Alternative authentication. It was mentioned, however, that Keystone is a relatively easy service to install and operate, so adding this to Ironic may not be worth the effort. * Multi-tenant networking without Neutron. We could use networking-ansible_ directly, since they are planning on providing a Python API independent of their ML2 implementation. Next, firmware update support was a recurring topic (also in hallway conversations and also in non-standalone context). Related to that, a driver feature matrix documentation was requested, so that such driver-specific features are easier to discover. Then we had a separate `API multi-tenancy session`_. Three topic were covered: * Wiring in the existing ``owner`` field for access control. The idea is to allow operations for non-administrator users only to nodes with ``owner`` equal to their project (aka tenant) ID. In the non-keystone context this field would stay free-form. We did not agree whether we need an option to enable this feature. An interesting use case was mentioned: assign a non-admin user to Nova to allocate it only a part of the bare metal pool instead of all nodes. We did not reach a consensus on using a schema with the ``owner`` field, e.g. where ``keystone://{project ID}`` represents a Keystone project ID. * Adding a new field (e.g. ``deployed_by``) to track a user that requested deploy for auditing purposes. We agreed that the ``owner`` field should not be used for this purpose, and overall it should never be changed automatically by Ironic. * Adding some notion of *node leased to*, probably via a new field. This proposal was not well defined during the session, but we probably would allow some subset of API to lessees using the policy mechanism. It became apparent that implementing a separate *deployment API endpoint* is required to make such policy possible. Creating the deployment API was identified as a potential immediate action item. Wiring the ``owner`` field can also be done in the Train cycle, if we find volunteers to push it forward. PTG: scientific SIG =================== The PTG started for me with the `Scientific SIG discussions`_ of desired features and fixes in Ironic. The hottest topic was reducing the deployment time by reducing the number of reboots that are done during the provisioning process. `Ramdisk deploy`_ was identified as a very promising feature to solve this, as well as enable booting from remote volumes not supported directly by Ironic and/or Cinder. A few SIG members committed to testing it as soon as possible. Two related ideas were proposed for later brainstorming: * Keeping some proportion of nodes always on and with IPA booted. This is basing directly on the `fast-track deploy`_ work completed in the Stein cycle. A third party orchestrator would be needed for keeping the percentage, but Ironic will have to provide an API to boot an ``available`` node into the ramdisk. * Allow using *kexec* to instantly switch into a freshly deployed operating system. Combined together, these features can allow zero-reboot deployments. PTG: Ironic =========== Community sustainability ------------------------ We seem to have a disbalance in reviews, with very few people handling the majority of reviews, and some of them are close to burning out. * The first thing we discussed is simplifying the specs process. We considered a single +2 approval for specs and/or documentation. Approving documentation cannot break anyone, and follow-ups are easy, so it seems a good idea. We did not reach a firm agreement on a single +2 approval for specs; I personally feel that it would only move the bottleneck from specs to the code. * Facilitating deprecated feature removals can help clean up the code, and it can often be done by new contributors. We would like to maintain a list of what can be removed when, so that we don't forget it. * We would also like to switch to single +2 for stable backports. This needs changing the stable policy, and Tony volunteered to propose it. We felt that we're adding cores at a good pace, Julia had been mentoring people that wanted it. We would like people to volunteer, then we can mentor them into core status. However, we were not so sure we wanted to increase the stable core team. This team is supposed to be a small number of people that know quite a few small details of the stable policy (e.g. requirements changes). We thought we should better switch to single +2 approval for the existing team. Then we discussed moving away from WSME, which is barely maintained by a team of not really interested individuals. The proposal was to follow the example of Keystone and just move to Flask. We can use ironic-inspector as an example, and probably migrate part by part. JSON schema could replace WSME objects, similarly to how Nova does it. I volunteered to come up with a plan to switch, and some folks from Intel expressed interest in participating. Standalone roadmap ------------------ We started with a recap of items from `Forum: standalone Ironic`_. While discussing creating a driver matrix, we realized that we could keep driver capabilities in the source code (similar to existing iSCSI boot) and generate the documentation from it. Then we could go as far as exposing this information in the API. During the multi-tenancy discussion, the idea of owner and lessee fields was well received. Julia volunteered to write a specification for that. We clarified the following access control policies implemented by default: * A user can list or show nodes if they are an administrator, an owner of a node or a leaser of this node. * A user can deploy or undeploy a node (through the future deployment API) if they are an administrator, an owner of this node or a lessee of this node. * A user can update a node or any of its resources if they are an administrator or an owner of this node. A lessee of a node can **not** update it. The discussion of recording the user that did a deployment turned into discussing introducing a searchable log of changes to node power and provision states. We did not reach a final consensus on it, and we probably need a volunteer to push this effort forward. Deploy steps continued ---------------------- This session was dedicated to making the deploy templates framework more usable in practice. * We need to implement support for in-band deploy steps (other than the built-in ``deploy.deploy`` step). We probably need to start IPA before proceeding with the steps, similarly to how it is done with cleaning. * We agreed to proceed with splitting the built-in core step, making it a regular deploy step, as well as removing the compatibility shim for drivers that do not support deploy steps. We will probably separate writing an image to disk, writing a configdrive and creating a bootloader. The latter could be overridden to provide custom kernel parameters. * To handle potential differences between deploy steps in different hardware types, we discussed the possibility of optionally including a hardware type or interface name in a clean step. Such steps will only be run for nodes with matching hardware type or interface. Mark and Ruby volunteered to write a new spec on these topics. Day 2 operational workflow -------------------------- For deployments with external health monitoring, we need a way to represent the state when a deployed node looks healthy from our side but is detected as failed by the monitoring. It seems that we could introduce a new state transition from ``active`` to something like ``failed`` or ``quarantined``, where a node is still deployed, but explicitly marked as at fault by an operator. On unprovisioning, this node would not become ``available`` automatically. We also considered the possibility of using a flag instead of a new state, although the operators in the room were more in favor of using a state. We largely agreed that the already overloaded ``maintenance`` flag should not be used for this. On the Nova side we would probably use the ``error`` state to reflect nodes in the new state. A very similar request had been done for node retirement support. We decided to look for a unified solution. DHCP-less deploy ---------------- We discussed options to avoid relying on DHCP for deploying. * An existing specification proposes attaching IP information to virtual media. The initial contributors had become inactive, so we decided to help this work to go through. Volunteers are welcome. * As an alternative to that, we discussed using IPv6 SLAAC with multicast DNS (routed across WAN for Edge cases). A couple of folks on the room volunteered to help with testing. We need to fix python-zeroconf_ to support IPv6, which is something I'm planning on. Nova room --------- In a cross-project discussion with the Nova team we went through a few topics: * Whether Nova should use new Ironic API to build config drives. Since Ironic is not the only driver building config drives, we agreed that it probably doesn't make much sense to change that. * We did not come to a conclusion on deprecating capabilities. We agreed that Ironic has to provide alternatives for ``boot_option`` and ``boot_mode`` capabilities first. These will probably become deploy steps or built-in traits. * We agreed that we should switch Nova to using *openstacksdk* instead of *ironicclient* to access Ironic. This work had already been in progress. Faster deploy ------------- We followed up to `PTG: scientific SIG`_ with potential action items on speeding up the deployment process by reducing the number of reboots. We discussed an ability to keep all or some nodes powered on and heartbeating in the ``available`` state: * Add an option to keep the ramdisk running after cleaning. * For this to work with multi-tenant networking we'll need an IPA command to reset networking. * Add a provisioning verb going from ``available`` to ``available`` booting the node into IPA. * Make sure that pre-booted nodes are prioritized for scheduling. We will probably dynamically add a special trait. Then we'll have to update both Nova/Placement and the allocation API to support preferred (optional) traits. We also agreed that we could provide an option to *kexec* instead of rebooting as an advanced deploy step for operators that really know their hardware. Multi-tenant networking can be tricky in this case, since there is no safe point to switch from deployment to tenant network. We will probably take a best effort approach: command IPA to shutdown all its functionality and schedule a *kexec* after some time. After that, switch to tenant networks. This is not entirely secure, but will probably fit the operators (HPC) who requests it. Asynchronous clean steps ------------------------ We discussed enhancements for asynchronous clean and deploy steps. Currently running a step asynchronously requires either polling in a loop (occupying a green thread) or creating a new periodic task in a hardware type. We came up with two proposed updates for clean steps: * Allow a clean step to request re-running itself after certain amount of time. E.g. a clean step would do something like .. code-block:: python @clean_step(...) def wait_for_raid(self): if not raid_is_ready(): return RerunAfter(60) and the conductor would schedule re-running the same step in 60 seconds. * Allow a clean step to spawn more clean steps. E.g. a clean step would do something like .. code-block:: python @clean_step(...) def create_raid_configuration(self): start_create_raid() return RunNext([{'step': 'wait_for_raid'}]) and the conductor would insert the provided step to ``node.clean_steps`` after the current one and start running it. This would allow for several follow-up steps as well. A use case is a clean step for resetting iDRAC to a clean state that in turn consists of several other clean steps. The idea of sub-steps was deemed too complicated. PTG: TripleO ============ We discussed our plans for removing Nova from the TripleO undercloud and moving bare metal provisioning from under control of Heat. The plan from the `nova-less-deploy specification`_, as well as the current state of the implementation, were presented. The current concerns are: * upgrades from a Nova based deployment (probably just wipe the Nova database), * losing user experience of ``nova list`` (largely compensated by ``metalsmith list``), * tracking IP addresses for networks other than *ctlplane* (solved the same way as for deployed servers). The next action item is to create a CI job based on the already merged code and verify a few assumptions made above. PTG: Ironic, Placement, Blazar ============================== We reiterated over our plans to allow Ironic to optionally report nodes to Placement. This will be turned off when Nova is present to avoid conflicts with the Nova reporting. We will optionally use Placement as a backend for Ironic allocation API (which is something that had been planned before). Then we discussed potentially exposing detailed bare metal inventory to Placement. To avoid partial allocations, Placement could introduce new API to consume the whole resource provider. Ironic would use it when creating an allocation. No specific commitments were made with regards to this idea. Finally we came with the following workflow for bare metal reservations in Blazar: #. A user requests a bare metal reservation from Blazar. #. Blazar fetches allocation candidates from Placement. #. Blazar fetches a list of bare metal nodes from Ironic and filters out allocation candidates, whose resource provider UUID does not match one of the node UUIDs. #. Blazar remembers the node UUID and returns the reservation UUID to the user. When the reservation time comes: #. Blazar creates an allocation in Ironic (not Placement) with the candidate node matching previously picked node and allocation UUID matching the reservation UUID. #. When the enhancements in `Standalone roadmap`_ are implemented, Blazar will also set the node's lessee field to the user ID of the reservation, so that Ironic allows access to this node. #. A user fetches an Ironic allocation corresponding to the Blazar reservation UUID and learns the node UUID from it. #. A user proceeds with deploying the node. Side and hallway discussions ============================ * We discussed having Heat resources for Ironic. We recommended the team to start with Allocation and Deployment resources (the latter being virtual until we implement the planned deployment API). * We prototyped how Heat resources for Ironic could look, including Node, Port, Allocation and Deployment as a first step. .. _Metal3: http://metal3.io .. _live demo: https://www.openstack.org/videos/summits/denver-2019/openstack-ironic-and-b… .. _bare metal program: https://www.openstack.org/bare-metal/ .. _standalone roadmap session: https://etherpad.openstack.org/p/DEN-train-next-steps-for-standalone-ironic .. _networking-ansible: https://opendev.org/x/networking-ansible .. _API multi-tenancy session: https://etherpad.openstack.org/p/DEN-train-ironic-multi-tenancy .. _Scientific SIG discussions: https://etherpad.openstack.org/p/scientific-sig-ptg-train .. _Ramdisk deploy: https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html#ramdi… .. _fast-track deploy: https://storyboard.openstack.org/#!/story/2004965 .. _python-zeroconf: https://github.com/jstasiak/python-zeroconf .. _nova-less-deploy specification: http://specs.openstack.org/openstack/tripleo-specs/specs/stein/nova-less-de…

2 2