- openstack-discuss - lists.openstack.org

[tc] Technical Committee status update for 6 December
by Doug Hellmann 06 Dec '18

06 Dec '18

This is the (alegedly) weekly summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == It has been 4 weeks since the last update email, in part due to the Summit, then a holiday, then my absense due to illness. Project updates: * Add tenks under Ironic: https://review.openstack.org/#/c/600411/ * Add os_placement role to OpenStack Ansible: https://review.openstack.org/#/c/615187/ * Retired openstack-ansible-os_monasca-ui https://review.openstack.org/#/c/617322/ * Chris Hoge was made the new Loci team PTL https://review.openstack.org/#/c/620370/ Other updates: * Thierry has been working on a series of changes on behalf of the release management team to record the release management style used for each deliverable listed in the governance repository. https://review.openstack.org/#/c/613268/ * Zane updated our guidelines for new projects to clarify the scoping requirements: https://review.openstack.org/#/c/614799/ * Zane also added a Vision for OpenStack Clouds document, describing what we see as the scope of OpenStack overall: https://review.openstack.org/#/c/592205/ * I copied some code we had in a couple of other places into the governance repository to make it easier for the release, goal, and election tools to consume the governance data using the new openstack-governance library from PyPI. https://review.openstack.org/#/c/614599/ * I started a document describing the responsibilities of the TC chair. https://review.openstack.org/#/c/618810/ == TC Meetings == In order to fulfill our obligations under the OpenStack Foundation bylaws, the TC needs to hold meetings at least once each quarter. We agreed to meet monthly, and to emphasize agenda items that help us move initiatives forward while leaving most of the discussion of those topics to the mailing list. The agendas for all of our meetings will be sent to the openstack-dev mailing list in advance, and links to the logs and summary will be sent as a follow up after the meeting. Our most recent meeting was held on 6 Dec 2018. * http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000696… The next meeting will be 3 December @ 1400 UTC in #openstack-tc == Ongoing Discussions == We have several governance changes up for review related to deciding how we will manage future Python 3 upgrades (including adding 3.7 and possibly dropping 3.5 during Stein). These are close to being approved, with some final wording adjustments being made now. * Explicitly declare stein supported runtimes: https://review.openstack.org/#/c/611080/ * Resolution on keeping up with Python 3 releases: https://review.openstack.org/#/c/613145/ I proposed an update to our house rules to allow faster approval of release management metadata maintained in the governance repository. * https://review.openstack.org/#/c/622989/ Thierry and Chris have been working on a description of the role of the TC. * https://review.openstack.org/#/c/622400/ Ghanshyam has proposed an enhancement to the Vision for OpenStack Clouds to cover feature discovery. * https://review.openstack.org/#/c/621516/ Lance has proposed an update to the charter to clarify how we will handle PTL transitions in the middle of a development cycle. * https://review.openstack.org/#/c/620928/ == TC member actions/focus/discussions for the coming week(s) == We have several significant changes up for review. Please take time to consider all of the open patches, then comment and vote on them. It's very difficult to tell if we have reached consensus if everyone waits for the conversation to settle before commenting. == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

3 3

Re: [sdk] Establishing SDK Validation Baseline
by Melvin Hillsman 06 Dec '18

06 Dec '18

On Thu, Dec 6, 2018 at 12:30 PM Artem Goncharov <artem.goncharov(a)gmail.com> wrote: > > > On Thu, 6 Dec 2018, 19:12 Melvin Hillsman, <mrhillsman(a)gmail.com> wrote: > >> Hi everyone, >> >> We have spent some time working to get an idea of what official SDKs >> would look like. We had some sessions during the Berlin summit[0][1] and >> there was a lot of great feedback. >> >> Currently the following SDKs are generally considered usable for their >> respective language; there are others of course: >> >> openstacksdk (Python) >> gophercloud (Go) >> pkgcloud (JavaScript) >> openstack4j (Java) >> rust-openstack (Rust) >> fog-openstack (Ruby) >> php-opencloud (PHP) >> >> After many discussions it seems SDK validation essentially should be >> about confirming cloud state pre/post SDK interaction rather than API >> support. An example is that when I use pkgcloud and ask that a VM be >> created, does the VM exist, in the way I asked it exist, rather than are >> there specific API calls that are being hit along the way to creating my VM. >> >> I am putting this email out to keep the community informed of what has >> been discussed in this space but also and most importantly to get feedback >> and support for this work. It would be great to get a set of official and >> community SDKs, get them setup with CI testing for validation (not changing >> their current CI for unit/functional/acceptance testing; unless asked to >> help do this), and connect the results to the updated project navigator SDK >> section. A list of scenarios has been provided as a good starting point for >> cloud state checks.[2] >> >> Essentially the proposal is to deploy OpenStack from upstream (devstack >> or other), stand up a VM within the cloud, grab all the SDKs, run >> acceptance tests, report pass/fail results, update project navigator. Of >> course there are details to be worked out and I do have a few questions >> that I hope would help get everyone interested on the same page via this >> thread. >> >> >> 1. Does this make sense? >> >> > As a representative of a public cloud operator I say yes. It definitely > makes sense to let users know, which SDKs are certified to work to have > understanding what they can use. However then comes the question, that each > public operator has own "tricks" and possibly even extension services, > which make SDK behave not as expected. I do really see a need to provide a > regular way in each of those SDKs to add and (I really don't want this, but > need unfortunately) sometimes override services implementation if those are > changed in some way. > So the certification make sense, but the CI question probably goes in the > direction of OpenLab > Yes this is definitely something to consider; public cloud tricks and extensions. An idea that was floated is to have an upstream cloud to run against that passes all interop powered programs to run the SDKs against. Even though SDKs provide more coverage an SDK that works against a service that is certified should work in any cloud that is certified? > >> 1. Would folks be interested in a SDK SIG or does it make more sense >> to request an item on the API SIG's agenda? >> >> Both has pro and cons, but I am neutral here > > Same, just wanted to get it out there and hopefully get API SIG members feedback so as not to hijack any of their agendas or creep on their scope without consent. > > >> 1. Bi-weekly discussions a good cadence? >> >> Yes. The regular communication is a requirement. > > > >> 1. Who is interested in tackling this together? >> >> > I do, but not alone > Haha, agreed, but we definitely should work on it and be consistent even if the initial set of folks is small. We have a large community to lean on and should rather than simply going at it alone. > > >> >> >> [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce >> [1] https://etherpad.openstack.org/p/BER-sdk-certification >> [2] >> https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3V… >> >> >> -- >> Kind regards, >> >> Melvin Hillsman >> mrhillsman(a)gmail.com >> mobile: (832) 264-2646 >> > > Regards, > Artem Goncharov > gtema > OpenTelekomCloud > >> -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[openstack-dev] [puppet] [stable] Deprecation of newton branches
by Tobias Urdin 06 Dec '18

06 Dec '18

Hello, We've been talking for a while about the deprecation and removal of the stable/newton branches. I think it's time now that we get rid of them, we have no open patches and Newton is considered EOL. Could cores get back with a quick feedback and then the stable team can get rid of those whenever they have time. Best regards Tobias __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

6 8

[dev][nova] time for another spec review day?
by melanie witt 06 Dec '18

06 Dec '18

Hi All, Our spec freeze is milestone 2 January 10 and I was thinking, because of holiday time coming up, it might be a good idea to have another spec review day ahead of the freeze early next year. I was thinking maybe Tuesday next week December 11, to allow the most amount of time before holiday PTO starts. Please let me know what you think. Cheers, -melanie

1 1

[ops] Disk QoS in Cinder and Nova flavour
by Jean-Philippe Méthot 06 Dec '18

06 Dec '18

Hi, This is something that’s not exactly clear in the documentation and so I thought I’d ask here. There are currently two ways to set disk IO limits, or QoS: through Cinder QoS values or through Nova flavours. My question is, what’s the difference exactly? I assume that Cinder QoS only applies on Cinder volume, but is the same true for flavour QoS? In other words, is QoS through flavour supposed to apply to both Cinder volumes and ephemeral storage or is it only for ephemeral storage? Additionally, I'm under the assumption that once you provision a block device of a certain type with QoS associated to it, it becomes impossible to modify the values afterwards. Is that correct? This is a strange behaviour, considering that technically, you should be able to change QoS when it’s set through flavour using a simple resize. Please correct me if I’m wrong. I feel that this could be better explained in the current documentation. Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

1 0

[tc] agenda for Technical Committee Meeting 6 Dec 2018 @ 1400 UTC
by Doug Hellmann 06 Dec '18

06 Dec '18

TC Members, Our next meeting will be this Thursday, 6 Dec at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee * Follow up on past action items ** dhellmann complete liaison assignments using the random generator I have updated the team liaisons in the wiki [1]. Please review the list of projects to which you are assigned. [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams ** tc-members review the chair duties document The draft document from [2] has been merged and is now available in the governance repo as CHAIR.rst [3]. Please come prepared to discuss any remaining questions about the list of chair duties. [2] https://etherpad.openstack.org/p/tc-chair-responsibilities [3] http://git.openstack.org/cgit/openstack/governance/tree/CHAIR.rst * active initiatives ** keeping up with python 3 releases We are ready to approve Zane's resolution for a process for tracking python 3 versions [4]. There is one wording update [5] that we should prepare for approval as well. The next step will be to approve Sean's patch describing the runtimes supported for Stein [6]. Please come prepared to discuss any issues with those patches so we can resolve them and move forward. [4] https://review.openstack.org/613145 [5] https://review.openstack.org/#/c/621461/1 [6] https://review.openstack.org/#/c/611080/ * follow-up from Berlin Forum ** Vision for OpenStack clouds Zane has summarized the forum session on the mailing list [7], including listing several potential updates to the vision based on our discussion there. Please come prepared to discuss next steps for making those changes. [7] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000431… ** Train cycle goals I posted my summary of the forum session [8]. Each of the candidate goals have work to be done before they could be selected, so we will need to work with the sponsors and champions to see where enough progress is made to let us choose from among the proposals. Lance has agreed to lead the selection process for the Train goals, and will be looking for someone to pair up with on that. [8] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000055… ** Other TC outcomes from Forum We had several other forum sessions, and should make sure we have a good list of any promised actions that came from those discussions. Please come prepared to discuss any sessions you moderated -- having summaries on the mailing list before the meeting would be very helpful. -- Doug

1 1

[senlin] Cancelling this week's meeting
by Duc Truong 06 Dec '18

06 Dec '18

Everyone, The new odd week meeting time has just been approved but due to the short notice and also since there are no important updates since last week, I will cancel the Senlin meeting for this week. Next week the meeting will be on Friday at 530 UTC. Regards, Duc

1 0

[barbican][nova] booting instance from snapshot or unshelve with image signature verification enabled
by Pavlo Shchelokovskyy 06 Dec '18

06 Dec '18

Hi all, I am looking at how Nova is integrated with Barbican and am wondering how the user workflow when booting instance from snapshot should work (including unshelving a shelved instance) when Nova is set to strictly verify Glance images' signatures. Currently Nova strips by default all signature-related image metadata of original image when creating snapshot and for good reason - as the hash of the snapshot is definitely not the same as that of the image it was booted from, the signature of the original image is no longer valid for snapshot. Effectively that means that when strict image signature validation is enabled in Nova, the user can no longer simply boot from that snapshot, and even less obvious, can not unshelve instances the same way as without signature validation enabled. So is it expected that user manually signs her instance snapshots or is there some automagic way to do it? Or is it a known issue / limitation? Unfortunately I couldn't find any existing bugs or mentions in docs on that. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

1 0

Anyone using ScaleIO block storage?
by Kimball (US), Conrad 06 Dec '18

06 Dec '18

Is anyone using ScaleIO (from Dell EMC) as a Cinder storage provider? What has been your experience with it, and at what scale? Our enterprise storage team is moving to ScaleIO and wants our OpenStack deployments to use it, so I'm looking for real life experiences to calibrate vendor stories of wonderfulness. One concern I do have is that it uses a proprietary protocol that in turn requires a proprietary "data client". For VM hosting this data client can be installed in the compute node host OS, but seems like we wouldn't be able to boot a bare-metal instance from a ScaleIO-backed Cinder volume. Conrad Kimball Associate Technical Fellow Enterprise Architecture Chief Architect, Enterprise Cloud Services conrad.kimball(a)boeing.com<mailto:conrad.kimball@boeing.com>

6 7

[dev][nova][glance] Interesting bug about deleting shelved server snapshot
by Matt Riedemann 06 Dec '18

06 Dec '18

I came across this bug during triage today: https://bugs.launchpad.net/nova/+bug/1807110 They are advocating that nova/glance somehow keep a shelved server snapshot image from being inadvertently deleted by the user since it could result in data loss as they can't unshelve the server later (there is metadata in nova that links the shelved server to the snapshot image in glance which is used during unshelve). I don't see a base description field on images but I suppose nova could write a description property that explains what the snapshot is and warn against deleting it. Going a step further, nova could potentially set the protected flag to true so the image cannot be deleted, but I have two concerns about that: 1. I don't see any way to force delete a protected image in glance - does that exist or has it been discussed before? 2. Would the user be able to PATCH the image to change the protected value to false and then delete the image if they really wanted to? The other problem with nova marking the image as protected is that if the user deletes the server, the compute API tries to delete the snapshot image [1] which would fail if it's still protected, and then we could see snapshot images getting orphaned in glance. Arguably nova could detect this situation, update the protected field to false, and then delete the image. Other thoughts? Has this come up before? [1] https://github.com/openstack/nova/blob/c9dca64fa64005e5bea327f06a7a3f4821ab… -- Thanks, Matt

3 4