Open Stack

Yet again, let me try to provide you a summary about our previous PTG, this
time for the Zed release.

You can see all the notes thanks to this read-only etherpad :
https://etherpad.opendev.org/p/r.75a986ce3ac43bb74b93c5de63d84fe9


### Cross-project discussions ###

# Neutron cross-project discussion with Nova

- The nova community asked how to require Neutron backends to support a
list of Neutron API extensions (for example multiple port bindings). We
discussed whether it was rather a documentation issue or a code issue, but
eventually it was rather a supporting concern as we don't test all of the
backends for Nova. We then agreed on discussing this during the next
OpenInfra Summit in Berlin with operators then, if possible.
 - We agreed on providing a new job for verifying whether
heal_instance_info_cache_interval
is no longer needed.

# Cinder cross-project discussion with Nova

- We discussed how we could remove the os-brick rootwrap config from nova
and rather moving the config into directly os-brick. We eventually agreed
on trying to rather implement the rootwrap->privsep transition, hopefully,
thanks to some Stephen's help ;)

# Cyborg cross-project discussion with Nova

- We agreed on continuing to accept to provide traits for Resource
Providers for owners (OWNER_NOVA at least). Context is
https://review.opendev.org/c/openstack/nova-specs/+/836583 and we discussed
about some implementation nits.


### Nova specific topics ###

# Procedural discussions

- We discussed on Yoga retrospective. We were happy to not have a RC2, to
have new contributors and to have provided features to Placement for the
last two cycles. We agreed to stopping to accept blind rechecks and to use
the review priority label. Eventually we agreed on maybe adding new stable
cores.
- We need to fix Placement tests that verify the number of traits as for
the moment it creates some issues. We agreed on relaxing those tests and to
add a PTL doc saying we would bump os-traits and os-resource-classes usage
in placement before RC1.
- We agreed on having the same deadlines that for the last cycle, which
are, Spec approval freeze for Zed-2 milestone (July 14th), and
FeatureFreeze for Zed-3 (Sep 1st). We will have two spec review days
- We agreed on keeping the same release model for os-vif
- We agreed on continuing to use the review priority label in Gerrit and
encourage contributors to use it (once we land the necessary changes in
Gerrit)
 - Follow-up discussion on the novaclient CLI deprecation we agreed on
Yoga. We'll modify the spec template to ask for rather updating OSC instead
of the shell, and how to return some warnings if you use the shell.
 - We agreed on having some bug triage rotation between our contributors.
I'll explain it in our next team meeting today :-)
 - We agreed on saying 'Unsupported' instead of 'Deprecated" for some
features that need help if we don't want to remove them :-)
- Again, we loudly said ***NO FOR BLIND RECHECKS***
https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures


# New Release cadence (ie. the tick-tock release balance)

- We agreed on writing some guidelines in our Nova documentation explaining
the differences between tick and tock releases from a nova perspective and
what people could do. We agreed on *not* bumping the compute minimum
supported version in a tick release. That would also be super cool if we
could have some sphinx directive in reno that contributors would use if
they add/modify things in a tock release but want operators to know in the
next tick.


# Planned API modifications

- We agreed on testing new policy defaults in the gate and not yet enforce
new scopes until we are sure everything works correctly. Devstack will need
modifications for those enablements and proper communication has to be made
to deployment projects to make sure they're on the same page before we
change anything.
- We agreed on deprecating the possibility to generate new keypairs thru
the Nova API. Only keypair imports will be accepted in the future.
- We agreed on some usecase for adding network domain name in our metadata
API. Things have to be further discussed in a spec but the direction sounds
reasonable.
- We agreed on letting userdata be editables. Details were discussed about
the limits of this new mutable field (configdrive et when to apply) but
spec will be updated accordingly.
- Being able to unshelve an instance by passing a destination seems a valid
usecase, spec has to be reviewed besides the implementation.
- We'll try to somehow ensure that renaming tenant_id into project_id in
our API isn't yet again deferred to the next cycle, even tho the series is
large and merge conflicts are important.
- Manila shares could be attached or detached to instances thru a new API
and notifications would be emitted

# Other
- Centos9 will be tested on a weekly basis in our gate at first
- Nova healthcheck is definitely a thing we want, but we miss hands on deck.
- having PCI devices being tracked in Placement is also something we'd love
to see arriving on this cycle
- we'll continue further testing emulated hardware. Maybe some blueprints
would come up but we also said we'll try to give visibility on the periodic
gate runs by looking at them in our weekly meeting.
- We discussed a very interesting case with the Scaphandre project that
needs to use virtio-fs for passing system usage to the guests. We
eventually agreed on two possible directions, with one preferred, which is
to reuse the Manila shares support we're going to add in Zed.
- We can be smarter on placing guest CPUs on physical cores or dies, but
this requires a blueprint at least as we agreed on providing some flavor
extraspec or image property for letting operators to define the CPU
placement.
- Windows guests would benefit from new enlightenments in Zed if we merge
some small change
- Having CPU cores be externally managed by a daemon that would turn them
on/off based on consumption seems a valid usecase. We discussed about some
details but spec has to be reproposed.



That's it. If you reached this line, kudos, you're brave. I tried to be
short, but it looks to me I failed.
Anyway, the source of truth remains the etherpad, just please avoid to
amend it now.

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220412/1b1bde83/attachment.htm>