- openstack-discuss - lists.openstack.org

Networking-sfc Installation on Openstack Queens
by Navdeep Uniyal 06 Dec '18

06 Dec '18

Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep

2 1

Networking-sfc Installation on Openstack Queens
by Navdeep Uniyal 06 Dec '18

06 Dec '18

Dear all, I would like to use the networking-sfc in my multi-node openstack (Queens) vanilla installation. All the guides I found focussed on devstack. Please let me know if there is a proper documentation/guide to install the sfc service on my controller and compute nodes including the prerequisites. Please note: as of now I am using linuxbridge agent only. Please state if openVSwitch agent is required and how to install it. Kind Regards, Navdeep

1 0

Re: Anyone using ScaleIO block storage?
by Burak Hoban 06 Dec '18

06 Dec '18

We've been using ScaleIO alongside OpenStack for about 2 years now. From a stability point of view, no issues... we're still running on Mitaka so some of the integration isn't great but with the upgrade cycle coming up for us all of that should be solved. We only utilise (VM) instances on OpenStack though, not bare metal. _____________________________________________________________________ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses. _____________________________________________________________________

2 4

[openstack-dev] [tripleo] Workflows Squad changes
by Jiri Tomasek 06 Dec '18

06 Dec '18

Hi all, Recently, the workflows squad has been reorganized and people from the squad are joining different squads. I would like to discuss how we are going to adjust to this situation to make sure that tripleo-common development is not going to be blocked in terms of feature work and reviews. With this change, most of the tripleo-common maintenance work goes naturally to UI & Validations squad as CLI and GUI are the consumers of the API provided by tripleo-common. Adriano Petrich from workflows squad has joined UI squad to take on this work. As a possible solution, I would like to propose Adriano as a core reviewer to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common patches. It would be great to hear opinions especially former members of Workflows squad and regular contributors to tripleo-common on these changes and in general on how to establish regular reviews and maintenance to ensure that tripleo-common codebase is moved towards converging the CLI and GUI deployment workflow. Thanks __________________________________________________________________________ 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

4 3

[glance] is glance-cache deprecated
by Sumit Jamgade 06 Dec '18

06 Dec '18

Hello, $subject or are there any plans to migrate it to v2 ? I see Ia086230cc8c92f7b7dfd5b001923110d5bc55d4d removed the underlying entrypoint for glanace-cache-manage entrypoint -- thanks Sumit

2 2

Re: [TripleO] Configure SR-IOV VFs in tripleo
by sairam 06 Dec '18

06 Dec '18

we deployed overcloud rhosp10 through sriov but i am not able to create instance through please help me -- Sent from: http://openstack.10931.n7.nabble.com/Developer-f2.html

1 0

[release] Release countdown for week R-17, Dec 10-14
by Sean McGinnis 06 Dec '18

06 Dec '18

Development Focus ----------------- We are coming up on end of year holiday's, so the next few weeks will probably go by fast. Teams should be focused on development plans, but please be aware if there are any project specific milestone 2 deadlines you need to be aware of. General Information ------------------- Just a reminder about the changes this cycle with library deliverables that follow the cycle-with-milestones release model. As announced, we will be automatically proposing releases for these libraries at milestone 2 if there have been any functional changes since the last release to help ensure those changes are picked up by consumers with plenty of time to identify and correct issues. More detail can be found in the original mailing list post describing the changes: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html There are also a set of deliverables following the cycle-with-intermediary model that are not considered libraries. These are services and other somewhat different deliverables. We want to make sure the cycle-with-intermediary release model is not being used as a way to just perform one final release. The intent of this release model is to have multiple releases throughout a development cycle. If you own one of these deliverables, please think about performing a release if one has not already been done for Stein, or decide if the updated cycle-with-rc release model is more appropriate for your needs. More information can be found here: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000465… Upcoming Deadlines & Dates -------------------------- Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

[nova][dev] Bug about disabled compute during scheduling
by Matt Riedemann 06 Dec '18

06 Dec '18

Belmiro/Surya, I'm trying to follow up on something Belmiro mentioned at the summit before I forget about it. CERN sets this value low: https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.… And as a result, when disabling nova-computes during maintenance, you can fail during scheduling because placement only returns resource providers for disabled computes. I believe Dan and I kicked around some ideas on how we could deal with this, like either via a periodic in the compute service or when the compute service is disabled in the API, we would set the 'reserved' inventory value equal to the total to take those computes out of scheduling. I think Belmiro said this is what CERN is doing today as a workaround? For the latter solution, I don't know if we'd proxy that change directly from nova-api to placement, or make an RPC cast/call to nova-compute to do it, but that's an implementation detail. I mostly just want to make sure we get a bug reported for this so we don't lose track of it. Can one of you open a bug with your scenario and current workaround? -- Thanks, Matt

2 1

[tripleo] No weekly meeting on December 25
by Juan Antonio Osorio Robles 06 Dec '18

06 Dec '18

Enjoy the holidays!

1 0

[tripleo] PTL on vacations
by Juan Antonio Osorio Robles 06 Dec '18

06 Dec '18

Hello folks! I'll be on vacations from December 10th to January 2nd. For this reason, I won't be hosting the weekly meetings until I'm back. Best regards

1 0

Octavia Production Deployment Confused
by Zufar Dhiyaulhaq 06 Dec '18

06 Dec '18

Hi, I want to implement Octavia service in OpenStack Queens. I am stuck on two-step : 1. Create Octavia User I am trying to create Octavia user with this command, is this the right way? openstack user create octavia --domain default --password octavia openstack role add --user octavia --project services admin openstack service create --name octavia --description "OpenStack Octavia" load-balancer openstack endpoint create --region RegionOne octavia public http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia internal http://10.60.60.10:9876 openstack endpoint create --region RegionOne octavia admin http://10.60.60.10:9876 2. Load Balancer Network Configuration "Add appropriate routing to/from the ‘lb-mgmt-net’ such that egress is allowed, and the controller (to be created later) can talk to hosts on this network." I don't know how to route from controller host into a private network, is any specific command for doing that? following tutorial from https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-star… . Thank You Best Regards, Zufar Dhiyaulhaq

5 5

[goals][upgrade-checkers] Week R-18 Update
by Matt Riedemann 06 Dec '18

06 Dec '18

First, I'm sorry about the big gap in updates, the last one being before the summit. Things have been busy elsewhere. Second, I'm happy to report the majority of projects have merged the initial framework patch for the "$project-status upgrade check" command. There are a few outstanding patches for projects which need core review (I went through this list today and +1 on them): https://review.openstack.org/#/q/topic:upgrade-checkers+status:open There are a few projects adding real upgrade checks as well, like designate and cloudkitty, which is good to see. For projects that have already merged the framework check, please talk in your meetings about what "real" upgrade check you could add in stein to replace the placeholder/sample check that came with the framework patch. Note that checks added in stein don't necessarily need to be for stein upgrade issues, they could be for something that was an upgrade impact in rocky, queens, etc, because with fast-forward upgrades people will be rolling through and might have missed something in the release notes. If you have questions, feel free to reach out to me in #openstack-dev (mriedem) or reply to this thread. -- Thanks, Matt

1 0

What's Happening in the Open Infrastructure Community
by Allison Price 05 Dec '18

05 Dec '18

Hi everyone, This week, we distributed the first Open Infrastructure Community Newsletter. Our goal with the bi-weekly newsletter is to provide a digest of the latest developments and activities across open infrastructure projects, events and users. This week, we highlighted the Berlin Summit as well as brief updates from OpenStack as well as the OSF's four pilot projects: Airship, Kata Containers, StarlingX and Zuul. You can checkout the full newsletter on Superuser [1], and if you are interested in receiving the upcoming newsletters, you can subscribe here [2]. If you would like to contribute or have feedback, please reach out to community(a)openstack.org. Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org [1] http://superuser.openstack.org/articles/inside-open-infrastructure-newslett… [2] https://www.openstack.org/community/email-signup

1 0

Proposing KaiFeng Wang for ironic-core
by Julia Kreger 05 Dec '18

05 Dec '18

I'd like to propose adding KaiFeng to the ironic-core reviewer group. Previously, we had granted KaiFeng rights on ironic-inspector-core and I personally think they have done a great job there. Kaifeng has also been reviewing other repositories in ironic's scope[1]. Their reviews and feedback have been insightful and meaningful. They have also been very active[2] at reviewing which is an asset for any project. I believe they will be an awesome addition to the team. -Julia [1]: http://stackalytics.com/?module=ironic-group&user_id=kaifeng [2]: http://stackalytics.com/report/contribution/ironic-group/90

5 4

[TC] Forum TC Vision Retrospective summary
by Julia Kreger 05 Dec '18

05 Dec '18

During the Forum in Berlin, the Technical Committee along with interested community members took some time to look back at the vision that written in early 2017. We had three simple questions: * What went well? * What needs improvement? * What should the next steps be? To summarize, the group thought the vision helped guide some thoughts and decisions. Helped provide validation on what was thought to be important. We have seen adjacent communities fostered. We didn't solely focus on the vision which was viewed as a positive as things do change over time. It helped us contrast, and in the process of writing the vision we reached the use of the same words. Most importantly, we learned that we took on too much work. As with most retrospectives, the list of things that needed improvement was a bit longer. There was some perception that it fell off the map, and that not every item received work. Possibly that we even took the vision too literally and too detailed as opposed to use it as more a guiding document to help us evolve as time goes on. There was consensus that there was still room to improve and that we could have done a better at conveying context to express how, what, and why. For next steps, we feel that it is time to revise the vision, albeit in a shorter form. We also felt that there could be a vision for the TC itself, which led to the discussion of providing clarity to the role of the Technical Committee. As for action items and next steps that we reached consensus on: * To refine the technical vision document. * That it was time to compose a new vision for the community. * Consensus was reached that there should be a vision of the TC itself, and as part of this have a living document that describes the "Role of the TC". ** ttx, cdent, and TheJulia have volunteered to continue those discussions. ** mnaser would start a discussion with the community as to what the TC should and shouldn't do. For those reading this, please remember that the TC's role is defined in the foundation bylaws, so this would be more of a collection of perceptions. * TheJulia to propose a governance update to suggest that people proposing TC candidacy go ahead and preemptively seek to answer the question of what the candidate perceives as the role of the TC. The etherpad that followed the discussion can be found at: https://etherpad.openstack.org/p/BER-tc-vision-retrospective -Julia

3 3

[nova] Stein forum session notes
by melanie witt 05 Dec '18

05 Dec '18

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

10 17

OpenStack Summit Berlin Videos Now Available
by Jimmy McArthur 05 Dec '18

05 Dec '18

Thank you again for a wonderful Summit in Berlin. I'm pleased to announce the Summit Videos are now up on the openstack.org website: https://www.openstack.org/videos/summits/berlin-2018 If there was a session you missed, now is your chance to catch up! These videos will also be available in the Summit App as well as on the web under the Berlin Summit Schedule (https://www.openstack.org/summit/berlin-2018/summit-schedule/) If you have any questions or concerns about the videos, please write speakersupport(a)openstack.org. Cheers, Jimmy

8 13

[openstack][diskimage-builder] How to install software packages at building murano-agent image
by zhaolihuisky 05 Dec '18

05 Dec '18

hi, guys How to install software packages at building murano-agent image. I have download telegraf-x.x.x-x86_64.rpm file and how to install this package into murano-agent image. Is there any suggestion? Best Regards.

2 1

[cloudkitty] IRC Meeting of the 7/12 will exceptionally happen at 9h AM UTC
by Luka Peschke 05 Dec '18

05 Dec '18

Hello, After discussion on IRC, it has been decided that the next CloudKitty IRC meeting (which was supposed to happen at 15h UTC on the 7/12) will exceptionally be held at 9h UTC (10h CET) on the same day. The schedule for other meetings remains unchanged (First friday of each month at 15h UTC). Cheers, -- Luka Peschke Développeur +33 (0) 5 82 95 65 36 5 rue du Moulin Bayard - 31000 Toulouse www.objectif-libre.com

1 0

[ptl] [openstack-map] New tags for OpenStack Project Map
by Jimmy McArthur 05 Dec '18

05 Dec '18

Following up on this thread from ttx [1], we are continuing to enhance the content on the OpenStack Project Map [2],[3] through new tags that are managed through the openstack-map repo [4]. * video (id, title, description) - This controls the Project Update video you see on the project page. I've just pushed a review adding all of the Project Updates for Berlin [5] * depends-on - Things that are a strong dependency. This should be used ONLY if your component requires another one to work (e.g. nova -> glance) * see-also - Should list things that are a week dependency or an adjacent relevant thing * support-teams (name: link) - This is meant to give credit to adjacent projects that aren't necessary to run the software (e.g. Oslo, i18n, Docs). We are still determining how best to implement this tag, but we feel it's important to give some credit to these other teams that are so critical in helping to maintain, support, and build OpenStack If you have some time, please go to the git repo [4] and review your project and help flesh out these new tags (or update old ones) so we can display them in the Project Map [2]. Cheers, Jimmy [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000178… [2] https://www.openstack.org/software/project-navigator/openstack-components [3] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf [4] https://git.openstack.org/cgit/openstack/openstack-map/ [5] https://review.openstack.org/622485

3 3

[tripleo] [validations] Replacement of undercloud_conf module
by Emilien Macchi 05 Dec '18

05 Dec '18

Hi folks, Context: https://bugs.launchpad.net/tripleo/+bug/1805825 Today I randomly found this module: https://github.com/openstack/tripleo-validations/blob/d21e7fa30f9be15bb9802… And it gave me 2 ideas, as I think we don't need this module and would consider it as technical debt at this point: - it's relying on a file, which isn't super safe and flexible IMHO. - a lot of validations rely on Hieradata which isn't safe either, we saw it with the Containerized Undercloud. So I propose that: - we export require parameters via the Heat templates into Ansible variables - we consume these variables from tripleo-validations (can be in the inventory or a dedicated var file for validations). So that way we remove the dependency on having the undercloud.conf access from Mistral Executor and also stop depending on Puppet (hieradata) which we don't guarantee to be here in the future. Can someone from TripleO validations team ack this email and put this work in your backlog? If you need assistance we're happy to help but I believe this is an important effort to avoid technical debt here. Thanks, -- Emilien Macchi

4 5

[tripleo] Spec for upgrades including operating system upgrade
by Jiří Stránský 05 Dec '18

05 Dec '18

Hi folks, there's work ongoing to figure out how we can include operating system upgrade into the TripleO upgrade procedure. As we explore the options, it becomes apparent that we need to change the operator workflow, and the OpenStack upgrade including an operating system upgrade will likely end up being our most daring, complex, risky upgrade procedure yet. There's a spec [1] which outlines the expected operator workflow and its implementation, alternatives, current gaps, risks etc. If you maintain any of our composable services, please take some time to review the spec, consider if the upgrade of the service fits the proposed upgrade workflow, and provide feedback or suggestions. The spec is fairly long (the topic is complex), but it's been structured to make the read as comfortable as possible. Thank you, Jirka [1] patch: https://review.openstack.org/#/c/622324 rendered: http://logs.openstack.org/24/622324/1/check/openstack-tox-docs/b047271/html…

1 0

[all][tc][Edge][FEMDC][tripleo][akraino][starlingx] Chronicles Of A Causal Consistency
by Bogdan Dobrelya 05 Dec '18

05 Dec '18

Background. Fact 0. Edge MVP reference architectures are limited to a single control plane that uses a central/global data backend by usual for boring Cloud computing meanings. Fact 1. Edge clouds in Fog computing world are WAN-distributed. Far and middle-level tiers may be communicating to their control planes over high-latency (~50/100ms or more) connections. Fact 2. Post-MVP phases [0] of future reference architectures for Edge imply high autonomity of edge sites (aka cloudlets [1][2]), which is having multiple control planes always maintaining CRUD operations locally and replicating shared state asynchronously, only when "uplinks" are available, if available at all. Fact 3. Distributed Compute Node in the post-MVP phases represents a multi-tiered star topology with middle-layer control planes aggregating thousands of computes at far edge sites and serving CRUD operations for those locally and fully autonomous to upper aggregation edge layers [3]. Those in turn might be aggregating tens of thousands of computes via tens/hundreds of such middle layers. And finally, there may be a central site or a few that want some data and metrics from all of the aggregation edge layers under its control, or pushing deployment configuration down hill through all of the layers. Reality check. That said, the given facts 1-3 contradict to strongly consistent data backends supported in today OpenStack (oslo.db), or Kubernetes as well. That means that neither of two IaaS/PaaS solutions is ready for future post-MVP phases of Edge as of yet. That also means that both will need a new, weaker consistent, data backend to pass the future reality check. If you're interested in formal proves of that claim, please see for sources [4][5][6][7][8]. A [tl;dr] of those: a) It is known that causal consistency is the best suitable for high-latency, high-scale and highly dynamic nature of membership in clusters b) "it it is significantly harder to implement causal consistency than eventual consistency. This explains the fact why there is not even a single commercial database system that uses causal consistency" [6] Challenge accepted! What can we as OpenStack community, joined the Kubernetes/OSF/CNCF communities perhaps, for the bright Edge future can do to make things passing that reality check? It's time to start thinking off it early, before we are to face the post-MVP phases for Edge, IMO. That is also something being discussed in the neighbour topic [9] and that I'm also trying to position as a challenge in that very high-level draft paper [10]. As of potential steps on the way of implementing/adopting such a causal data backend in OpenStack at least, we should start looking into the papers, like [4][5][6][7][8] (or even [11], why not having a FS for that?), and probably more of it as a "theoretical background". [0] https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dub… [1] https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#… [2] https://en.wikipedia.org/wiki/Cloudlet [3] https://github.com/State-of-the-Edge/glossary/blob/master/edge-glossary.md#… [4] http://www.bailis.org/papers/bolton-sigmod2013.pdf [5] http://www.cs.princeton.edu/~wlloyd/papers/eiger-nsdi13.pdf [6] https://www.ronpub.com/OJDB_2015v2i1n02_Elbushra.pdf [7] http://www.cs.cornell.edu/lorenzo/papers/cac-tr.pdf [8] https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf [9] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000492… [10] https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/positio… [11] http://rainbowfs.lip6.fr/data/RainbowFS-2016-04-12.pdf -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[dev][nova][placement][qa] opinion on adding placement tests support in Tempest
by Ghanshyam Mann 05 Dec '18

05 Dec '18

Hi All, As you all know, placement tests (in nova repo or in new placement repo) are implemented using gabbi functional test[1]. There is a patch from amodi about adding placement test in Tempest [2]. Currently, Tempest does not support the placement endpoints. To support placement API in Tempest, it does not need much work (i have listed the todo items in gerrit patch.). Before we start or proceed with the discussion in QA, i would like to get the nova(placement) team opinion on adding the placement support in Tempest. Obviously, we should not duplicate the testing effort between what existing gabbi tests cover or what going to be added in Tempest which we can take care while adding the new tests. [1] https://github.com/openstack/nova/tree/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b… https://github.com/openstack/placement/tree/34f03c297e28ae2c46ab11debdb4bbe… [2] https://review.openstack.org/#/c/621645/2 -gmann

6 8

[dev][qa][devstack] Release management for QA toold and plugins
by Thierry Carrez 05 Dec '18

05 Dec '18

Hi, QA folks, The release management team has been conducting a review of OpenStack official deliverables, to make sure nothing was falling between the cracks release-management-wise. As part of that review, we added a "release-management:" key to deliverables defined in the project governance repository in case they were not to be handled by the release management team using the openstack/releases repository. For example, some deliverables (like docs) are continuously published and therefore marked "release-management:none". Others (like charms) are released manually on 3rd-party platforms and therefore marked "release-management:external". In that context, several QA-maintained tools or related repos are a bit in limbo: * eslint-config-openstack: used to be released regularly, but was never released since we introduced openstack/releases. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-vagrant: never released, no change over the past year. Is it meant to be released in the future (cycle-independent) or considered continuously published (release-management:none) or should it be retired ? * karma-subunit-reporter: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or drop the repository from governance ? * devstack-plugin-*: Some of those were branched using openstack/releases back in Queens, but only devstack-plugin-container. was branched in Rocky. Some consistency here would be good. Should those all be branched every cycle in the future, or should we just branch none of them and consider them all continuously published (release-management:none) ? * devstack-tools: saw some early releases two years ago but not in recent times. Should we just consider it cycle-independent, or consider it abandoned ? Thanks in advance for your guidance, -- Thierry Carrez (ttx) On behalf of the release management team

5 10