[nova] Stein forum session notes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[nova] Stein forum session notes

melanie witt-3
Hey all,

Here's some notes I took in forum sessions I attended -- feel free to
add notes on sessions I missed.

Etherpad links: https://wiki.openstack.org/wiki/Forum/Berlin2018

Cheers,
-melanie


TUE
---

Cells v2 updates
================
- Went over the etherpad, no objections to anything
- Not directly related to the session, but CERN (hallway track) and
NeCTAR (dev ML) have both given feedback and asked that the
policy-driven idea for handling quota for down cells be avoided. Revived
the "propose counting quota in placement" spec to see if there's any way
forward here

Getting users involved in the project
=====================================
- Disconnect between SIGs/WGs and project teams
- Too steep a first step to get involved by subscribing to ML
- People confused about how to participate

Community outreach when culture, time zones, and language differ
================================================================
- Most discussion around how to synchronize real-time communication
considering different time zones
- Best to emphasize asynchronous communication. Discussion on ML and
gerrit reviews
- Helpful to create weekly meeting agenda in advance so contributors
from other time zones can add notes/response to discussion items

WED
---

NFV/HPC pain points
===================
Top issues for immediate action: NUMA-aware live migration (spec just
needs re-approval), improved scheduler logging (resurrect cfriesen's
patch and clean it up), distant third is SRIOV live migration

BFV improvements
================
- Went over the etherpad, no major objections to anything
- Agree: we should expose boot_index from the attachments API
- Unclear what to do about post-create delete_on_termination. Being able
to specify it for attach sounds reasonable, but is it enough for those
asking? Or would it end up serving no one?

Better expose what we produce
=============================
- Project teams should propose patches to openstack/openstack-map to
improve their project pages
- Would be ideal if project pages included a longer paragraph explaining
the project, have a diagram, list SIGs/WGs related to the project, etc

Blazar reservations to new resource types
=========================================
- For nova compute hosts, reservations are done by putting reserved
hosts into "blazar" host aggregate and then a special scheduler filter
is used to exclude those hosts from scheduling. But how to extend that
concept to other projects?
- Note: the nova approach will change from scheduler filter => placement
request filter

Edge use cases and requirements
===============================
- Showed the reference architectures again
- Most popular use case was "Mobile service provider 5G/4G virtual RAN
deployment and Edge Cloud B2B2X" with seven +1s on the etherpad

Deletion of project and project resources
=========================================
- What is wanted: a delete API per service that takes a project_id and
force deletes all resources owned by it with --dry-run component
- Challenge to work out the dependencies for the order of deletion of
all resources in all projects. Disable project, then delete things in
order of dependency
- Idea: turn os-purge into a REST API and each project implement a
plugin for it

Getting operators' bug fixes upstreamed
=======================================
- Problem: operator reports a bug and provides a solution, for example,
pastes a diff in launchpad or otherwise describes how to fix the bug.
How can we increase the chances of those fixes making it to gerrit?
- Concern: are there legal issues with accepting patches pasted into
launchpad by someone who hasn't signed the ICLA?
- Possible actions: create a best practices guide tailored for operators
and socialize it among the ops docs/meetup/midcycle group. Example:
guidance on how to indicate you don't have time to add test coverage,
etc when you propose a patch

THU
---

Bug triage: why not all the community?
======================================
- Cruft and mixing tasks with defect reports makes triage more difficult
to manage. Example: difference between a defect reported by a user vs an
effective TODO added by a developer. If New bugs were reliably from end
users, would we be more likely to triage?
- Bug deputy weekly ML reporting could help
- Action: copy the generic portion of the nova bug triage wiki doc into
the contributor guide docs. The idea/hope being that easy-to-understand
instructions available to the wider community might increase the chances
of people outside of the project team being capable of triaging bugs, so
all of it doesn't fall on project teams
- Idea: should we remove the bug supervisor requirement from nova to
allow people who haven't joined the bug team to set Status and Importance?

Current state of volume encryption
==================================
- Feedback: public clouds can't offer encryption because keys are stored
in the cloud. Telcos are required to make sure admin can't access
secrets. Action: SecuStack has a PoC for E2E key transfer, mnaser to
help see what could be upstreamed
- Features needed: ability for users to provide keys or use customer
barbican or other key store. Thread:
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136258.html

Cross-technical leadership session (OpenStack, Kata, StarlingX, Airship,
Zuul)
========================================================================
- Took down the structure of how leadership positions work in each
project on the etherpad, look at differences
- StarlingX taking a new approach for upstreaming, New strategy: align
with master, analyze what they need, and address the gaps (as opposed to
pushing all the deltas up). Bug fixes still need to be brought forward,
that won't change

Concurrency limits for service instance creation
================================================
- Looking for ways to test and detect changes in performance as a
community. Not straightforward because test hardware must stay
consistent in order to detect performance deltas, release to release.
Infra can't provide such an environment
- Idea: it could help to write up a doc per project with a list of the
usual tunables and basic info about how to use them

Change of ownership of resources
================================
- Ignore the network piece for now, it's the most complicated. Being
able to transfer everything else would solve 90% of City Network's use cases
- Some ideas around having this be a keystone auth-based access granting
instead of an update of project/user, but if keystone could hand user A
a token for user B, that token would apply to all resources of user B's,
not just the ones desired for transfer

Update on placement extraction from nova
========================================
- Upgrade step additions from integrated placement to extracted
placement in TripleO and OpenStackAnsible are being worked on now
- Reshaper patches for libvirt and xenapi drivers are up for review
- Lab test for vGPU upgrade and reshape + new schedule for libvirt
driver patch has been done already
- FFU script work needs an owner. Will need to query libvirtd to get
mdevs and use PlacementDirect to populate placement

Python bindings for the placement API
=====================================
- Placement client code replicated in different projects: nova, blazar,
neutron, cyborg. Want to commonize into python bindings lib
- Consensus was that the placement bindings should go into openstacksdk
and then projects will consume it from there

T series community goal discussion
==================================
- Most popular goal ideas: Finish moving legacy python-*client CLIs to
python-openstackclient, Deletion of project resources as discussed in
forum session earlier in the week, ensure all projects use ServiceTokens
when calling one another with incoming token

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova] Stein forum session notes

Matt Riedemann-3
On 11/19/2018 3:17 AM, melanie witt wrote:
> - Not directly related to the session, but CERN (hallway track) and
> NeCTAR (dev ML) have both given feedback and asked that the
> policy-driven idea for handling quota for down cells be avoided. Revived
> the "propose counting quota in placement" spec to see if there's any way
> forward here

Should this be abandoned then?

https://review.openstack.org/#/c/614783/

Since there is no microversion impact to that change, it could be added
separately as a bug fix for the down cell case if other operators want
that functionality. But maybe we don't know what other operators want
since no one else is at multi-cell cells v2 yet.

--

Thanks,

Matt

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova] Stein forum session notes

Surya Seetharaman


On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann <[hidden email]> wrote:
On 11/19/2018 3:17 AM, melanie witt wrote:
> - Not directly related to the session, but CERN (hallway track) and
> NeCTAR (dev ML) have both given feedback and asked that the
> policy-driven idea for handling quota for down cells be avoided. Revived
> the "propose counting quota in placement" spec to see if there's any way
> forward here

Should this be abandoned then?

https://review.openstack.org/#/c/614783/

Since there is no microversion impact to that change, it could be added
separately as a bug fix for the down cell case if other operators want
that functionality. But maybe we don't know what other operators want
since no one else is at multi-cell cells v2 yet.


I thought the policy check was needed until the "propose counting quota in placement"
has been implemented as a workaround and that is what the "handling down cell" spec also proposed,
unless the former spec would be implemented within this cycle in which case we do not need the
policy check.

--

Regards,
Surya.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova] Stein forum session notes

melanie witt-3
On Mon, 19 Nov 2018 17:19:22 +0100, Surya Seetharaman wrote:

>
>
> On Mon, Nov 19, 2018 at 2:39 PM Matt Riedemann <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/19/2018 3:17 AM, melanie witt wrote:
>      > - Not directly related to the session, but CERN (hallway track) and
>      > NeCTAR (dev ML) have both given feedback and asked that the
>      > policy-driven idea for handling quota for down cells be avoided.
>     Revived
>      > the "propose counting quota in placement" spec to see if there's
>     any way
>      > forward here
>
>     Should this be abandoned then?
>
>     https://review.openstack.org/#/c/614783/
>
>     Since there is no microversion impact to that change, it could be added
>     separately as a bug fix for the down cell case if other operators want
>     that functionality. But maybe we don't know what other operators want
>     since no one else is at multi-cell cells v2 yet.
>
>
> I thought the policy check was needed until the "propose counting quota
> in placement"
> has been implemented as a workaround and that is what the "handling down
> cell" spec also proposed,
> unless the former spec would be implemented within this cycle in which
> case we do not need the
> policy check.

Right, I don't think that anyone _wants_ the policy check approach. That
was just the workaround, last resort idea we had for dealing with down
cells in the absence of being able to count quota usage from placement.

The operators we've discussed with (CERN, NeCTAR, Oath) would like quota
counting not to depend on cell databases, if possible. But they are
understanding and will accept the policy-driven workaround if we can't
move forward with counting quota usage from placement.

If we can get agreement on the count quota usage from placement spec (I
have updated it with new proposed details), then we should abandon the
policy-driven behavior patch. I am eager to find out what everyone
thinks of the latest proposal.

Cheers,
-melanie

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev