- openstack-discuss - lists.openstack.org

[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

[scientific-sig] No IRC Meeting today
by Stig Telfer 05 Dec '18

05 Dec '18

Hi all - Apologies, there will be no Scientific SIG IRC meeting today. It’s too busy a week on other fronts. We’ll carry over agenda items to the next session and hopefully make up for lost time there. Best wishes, Stig

1 0

[cyborg] IRC meeting for Dec 5th
by Li Liu 05 Dec '18

05 Dec '18

Hi team, The IRC meeting will be held at the normal time again this week. *Starting next week*, we will move it to 0300 UTC, which 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) / 11am beijing time (Wednesday) For this week's meeting, we will try to 1. finalize the new DB scheme design 2. finalize the question from Xinran's email on whether we should use conductor or agent to do the diff/update in DB 3. Track status on miscs -- Thank you Regards Li

1 0

[tripleo] cleanup upgrade_tasks
by Emilien Macchi 05 Dec '18

05 Dec '18

Upgrade folks, Please take a look at https://review.openstack.org/622578. We don't run the upgrade_tasks Ansible tasks that stop systemd services and remove the packages since all services are containerized. These tasks were useful in Rocky when we converted the Undercloud from baremetal to containers but in Stein this is not useful anymore. It's actually breaking upgrades for Podman, as containers are now seen by systemd, and these tasks conflicts with the way containers are managed in Paunch. Thanks, -- Emilien Macchi

2 2

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 05 Dec '18

05 Dec '18

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[openstack-ansible] avoid approving changes hitting centos-7 jobs
by Mohammed Naser 05 Dec '18

05 Dec '18

Hi everyone: With the release of CentOS 7.6, we are unable to merge any code which runs on CentOS 7 because of the fact that our containers are still 7.5 however the host is 7.6 There is an issue open to get CentOS 7.6 images in: https://github.com/CentOS/sig-cloud-instance-images/issues/133 We’re hoping that upstream can provide this CentOS image soon to unbreak us but until then we’ll be blocked. I’ll try to reach out to anyone on the CentOS 7 team who can help us, but for the meantime, let’s avoid approving anything with voting CentOS 7 jobs. Thanks! Mohammed

1 0

[self-healing-sig] reminder: self-healing SIG IRC meetings tomorrow (Wed)
by Adam Spiers 05 Dec '18

05 Dec '18

Just a reminder that the second batch of the new series of IRC meetings for the self-healing SIG are happening tomorrow (well, today depending on where you live), i.e. Wednesday at 0900 UTC and 1700 UTC, in the #openstack-self-healing channel on Freenode: http://eavesdrop.openstack.org/#Self-healing_SIG_Meeting All are welcome!

1 0