- openstack-discuss - lists.openstack.org

[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

[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 04 Dec '18

04 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 04 Dec '18

04 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 04 Dec '18

04 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 04 Dec '18

04 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 04 Dec '18

04 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

Octavia Production Deployment Confused
by Zufar Dhiyaulhaq 04 Dec '18

04 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

2 2

[Nova] Increase size limits for user data
by Flavio Percoco 04 Dec '18

04 Dec '18

Greetings, I've been working on a tool that requires creating CoreOS nodes on OpenStack. Sadly, I've hit the user data limit, which has blocked the work I'm doing. One big difference between CoreOS images and other cloud images out there is that CoreOS images don't use cloud-init but a different tool called Ignition[0], which uses JSON as its serialization format. The size of the configs that I need to pass to the instance is bigger than the limit imposed by Nova. I've worked on reducing the size as much as possible and even generating a compressed version of it but the data is still bigger than the limit (144 kb vs 65kb). I'd like to understand better what the nature of the limit is (is it because of the field size in the database? Is it purely an API limit? Is it because it causes problems depending on the vendor? As far as I can tell the limit is just being enforced by the API schema[1] and not the DB as it uses a MEDIUMTEXT field. I realize this has been asked before but I wanted to get a feeling of the current opinion about this. Would the Nova team consider increasing the limit of the API considering that more use cases like this may be more common these days? [0] https://coreos.com/ignition/docs/latest/ [1] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/sc… Thanks, Flavio -- @flaper87 Flavio Percoco

6 6

[dev] [os-vif][nova][neutron][kuryr] os-vif serialisation, persistence and version compatiablity moving to v2.0
by Sean Mooney 04 Dec '18

04 Dec '18

Hi I wanted to raise the topic of os-vif, its public api what client are allowed to do and how that related to serialisation, persistence of os-vif objects and version compatibility. sorry this is a bit of a long mail so here is a TL;DR and I have separated the mail into a background and future section. - we are planning to refine our data model in os-vf for hardware offloads. https://review.openstack.org/#/c/607610/ - we have been talking on and off about using os-vif on for nova neutron port binding and negotiation. to do that we will need to support serialisation in the future. - there are some uses of os-vif in kuryr-kubenetes that are currently out of contract that we would like to correct as they may break in the future. https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/… - what would we like to see in an os-vif 2.0 background ========== Before I get to the topic of os-vif I wanted to take an aside to set the basis of how I wanted to frame the topic. So in C++ land, there is an international standard that defines the language and the standard library for the C++ language. one of the stipulations of that standard is that users of the standard library are allowed to construct types defined by the standard library and you can call functions and methods defined by the library. C++ has different semantics then python so the implication of the statement you can call functions may not be apparent. In C++ it is technically undefined behaviour to take the address of a standard library function you may only call it. This allows the library author to implement it as a macro,lambda, function, function object or any other callable. So, in other words, there is a clear delineation between the public API and host that API is implemented. Bringing this back to os-vif we also have a finite public API and seperate internal implementation and I want to talk about internal changes that may affect observable features from the client perspective. specifically things that client can depend on and things they cannot. first of all the public api of os-vif is defined by https://github.com/openstack/os-vif/blob/master/os_vif/plugin.py this module defined the base class of all plugins and is the only class a plugin must inherit from and the only class defined in os-vif that a plugin or client of os-vif may inherit from outside of the exception classes defined in https://github.com/openstack/os-vif/blob/master/os_vif/exception.py. the second part of os-vif public api is a collection of data structures defined in https://github.com/openstack/os-vif/tree/master/os_vif/objects that clients are expected to _construct_ and plugins may _read_ from. I highlight construct and read as that is the extent to which we currently promise to clients or plugins. specifically today our version compatibility for objects is partially enabled by our use of oslo versioned objects. since os-vif objects are OVOs they have additional methods such as obj_to_primitive and obj_from_primitive that exist but that are _not_ part of the public api. Because serialisation (out side of serialisation via privsep) and persistence of os-vif longer then the lifetime of a function call, is not today part of the supported use cases of os-vif, that has enabled us to be less strict with version compatible then we would have to be If we supported those features. For example, we have in general added obj_make_compatible methods to objects when we modify os-vif objects https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L120-… but we have often discussed should we add these functions as there are no current uses. future ====== That brings me to the topic of how os-vif is used in kuryr and how we would like to use it in neutron in the future. Part of the reason we do not allow clients to extend VIF objects is to ensure that os-vif plugins are not required on controller nodes and so we can control the set of vocabulary types that are exchanged and version them. To help us move to passing os-vif object via the api we need to remove the out of tree vif types that in use in kuryr and move them to os-vif. https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/… we had mentioned this 2 or 3 releases ago but the change that prompted this email was https://github.com/openstack/kuryr-kubernetes/commit/7cc187806b42fee5ea660f… i would like to know how kuryr-kubernetes is currently using the serialised os-vif objects. - are they being stored? - to disk - in a db - in etcd - are they bining sent to other services - are how are you serialising them. - obj_to_primitive - other - are you depending on obj_make_compatible - how can we help you not use them until we actually support this use case. In the future, we will support serialising os-vif object but the topic of should we use ovo has been raised. Initially, we had planned to serialise os-vif objects by calling obj_to_primitive and then passing that to oslo.serialsiation json utils. For python client, this makes it relatively trivial to serialise and deserialise the objects when calling into neutron but it has a disadvantage in that the format of the payload crated is specific to OpenStack, it is very verbose and it is not the most friendly format for human consumption. The other options that have come up in the past few months have been removing OVOs and validating with json schema or more recently replacing OVOs with protobufs. now we won't be doing either in the stein cycle but we had considered flattening our data models once https://review.openstack.org/#/c/607610/ is implemented and removing some unused filed as part of a 2.0 release in preparation for future neutron integration in Train. To that end, I would like to start the discussion about what we would want from a 2.0 release if and when we create one, how we can better docuemnt and enformce our public api/ supported usage patterens and are there any other users of os-vif outside of nova and kuryr today. regards sean.

2 1

Berlin Summit recap on Edge
by Ildiko Vancsa 04 Dec '18

04 Dec '18

Hi, I hope those of you who came to the Berlin Summit had a great event, a good trip home and got some rest, caught up with work and those who went on vacation had a great time. Hereby I would like to give a short summary to everyone either as a reminder or as a package to help you catch up briefly with what happened around edge in Berlin. As you most probably know we had a dedicated track for Edge Computing with numerous presentations and panel discussions at the conference which were recorded. If you would like to catch up or see some sessions again please visit the OpenStack website[1] for the videos. In parallel to the conference we were having the Forum taking place with 40-minute-long working sessions for developers, operators and users to meet and discuss new requirements, challenges and pain points to address. We had quite a few sessions around edge which you’ll find a brief recap of here. I would like to start with the OSF Edge Computing Group also Edge WG’s sessions, if you are new to the activities of this group you may want to read my notes[2] on the Denver PTG to catch up on the community’s and the group's work on defining reference architectures for edge use cases. During the Forum we continued to discuss the Minimum Viable Product (MVP) architecture topic[3] that we’ve started at the last PTG. As the group and attendees had limited amount of time available for the topic we concluded on some basics and agreed on action items to follow up on. The session attendees agreed that the MVP architecture is an important first step and we will keep its scope limited to the current OpenStack services listed on the wiki capturing the details[4]. While there is interest in adding further services such as Ironic or Qinling we will discuss those in this context in upcoming phases. The Edge WG is actively working on capturing edge computing use cases in order to understand better the requirements and to work together with OpenStack and StarlingX projects on design and implementation work based the input the groups has been collecting[5]. We had a session about use cases[6] to identify which are the ones the group should focus on with immediate actions where we got vRAN and edge cloud, uCPE and industrial control with most interest in the room to work on. The group is actively working on the map the MVP architecture options to the use cases identified by the group and to get more details on the ones we identified during the Forum session. If you are interested in participating in these activities please see the details[7] of the group’s weekly meetings. While the MVP architecture work is focusing on a minimalistic view to provide a reference architecture with the covered services prepared for edge use cases there is work ongoing in parallel in several OpenStack projects. You can find notes on the Forum etherpads[8][9][10] on the progress of projects such as Cinder, Ironic, Kolla-Ansible and TripleO. The general consensus of the project discussions were that the services are in a good shape when edge requirements are concerned and there is a good view on the way forward like improving availability zone functionality or remote management of bare metal nodes. With all the work ongoing in the projects as well as in the Edge WG the expectation is that we will be able to easily move to the next phases with the MVP architectures work when the working group is ready. Both the group and the projects are looking for contributors for both identifying further requirements, use cases or do the implementation and testing work. Testing is an area that will be crucial for edge and we are looking into both cross-project and cross-community collaborations for that for instance with OPNFV and Akraino. While we didn’t have a Keystone specific Forum session for edge this time a small group of people came together to discuss next steps with federation. We are converging towards some generic feature additions to Keystone based on the Athenz plugin from Oath. You can read a Keystone summary[11] for the week in Berlin from Lance Bragsad including plans related to edge. We had a couple of sessions at the Summit about StarlingX both in the conference part as well as the Forum. You can check out videos such as the project update[12] and other relevant sessions[13] among the Summit videos. As the StarlingX community is working closely with the Edge WG as well as the relevant OpenStack project teams at the Forum we had sessions that were focusing on some specific items for planning future work and understanding requirements better for the project. The team had a session on IoT[14] to talk about the list of devices to consider and the requirements systems need to address in this space. The session also identified a collaboration option between StarlingX, IoTronic[15] and Ironic when it comes to realizing and testing use cases. With putting more emphasis on containers at the edge the team also had a session on containerized application requirements[16] with a focus on Kubernetes clusters. During the session we talked about areas like container networking, multi-tenancy, persistent storage and a few more to see what options we have for them and what is missing today to have the particular area covered. The StarlingX community is focusing more on containerization in the upcoming releases for which the feedback and ideas during the session are very important to have. One more session to mention is the ‘Ask me anything about StarlingX’ one at the Forum where experts from the community offered help in general to people who are new and/or have questions about the project. The session was well attended and questions were focusing more on the practical angles like footprint or memory consumption and a few more specific questions that were beyond generic interest and overview of the project. These were the activities in high level around edge without going into too much detail on either of the topics as that would be a way longer e-mail. :) I hope you found interesting topics and useful pointers for more information to catch up on. If you would like to participate in these activities you can dial-in to the Edge WG weekly calls[17] or weekly Use cases calls[18] or check the StarlingX sub-project team calls[19] and further material on the website[20] about how to contribute or jump on IRC for OpenStack project team meetings[21] in the area of your interest. Please let me know if you have any questions to either of the above items. :) Thanks and Best Regards, Ildikó (IRC: ildikov) [1] https://www.openstack.org/videos/ [2] http://lists.openstack.org/pipermail/edge-computing/2018-September/000432.h… [3] https://etherpad.openstack.org/p/BER-MVP-architecture-for-edge [4] https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Archite… [5] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases [6] https://etherpad.openstack.org/p/BER-edge-use-cases-and-requirements [7] https://wiki.openstack.org/wiki/Edge_Computing_Group [8] https://etherpad.openstack.org/p/BER-Cinder_at_the_Edge [9] https://etherpad.openstack.org/p/BER-ironic-edge [10] https://etherpad.openstack.org/p/BER-tripleo-undercloud-edge [11] https://www.lbragstad.com/blog/openstack-summit-berlin-recap [12] https://www.openstack.org/videos/berlin-2018/starlingx-project-update-6-mon… [13] https://www.openstack.org/videos/search?search=starlingx [14] https://etherpad.openstack.org/p/BER-integrating-iot-device-mgmt-with-edge-… [15] https://github.com/openstack/iotronic [16] https://etherpad.openstack.org/p/BER-containerized-app-reqmts-on-kubernetes… [17] https://www.openstack.org/assets/edge/OSF-Edge-Computing-Group-Weekly-Calls… [18] https://www.openstack.org/assets/edge/OSF-Edge-WG-Use-Cases-Weekly-Calls.ics [19] https://wiki.openstack.org/wiki/Starlingx/Meetings [20] https://www.starlingx.io [21] http://eavesdrop.openstack.org

1 0

Re: [Release-job-failures][release][tripleo] Tag of openstack/tripleo-heat-templates failed
by Doug Hellmann 04 Dec '18

04 Dec '18

> On Dec 4, 2018, at 11:00 AM, zuul(a)openstack.org wrote: > > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/p… : POST_FAILURE in 5m 02s > - publish-openstack-releasenotes http://logs.openstack.org/7b/7baea84f1168d72b0eb8901da47d5f4efbaccff8/tag/p… : SUCCESS in 5m 04s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like tripleo-heat-templates still has both release notes jobs configured, so there was a race condition in publishing. Doug

2 3

Re: [Release-job-failures] Release of openstack/networking-ansible failed
by Doug Hellmann 04 Dec '18

04 Dec '18

zuul(a)openstack.org writes: > Build failed. > > - release-openstack-python http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/relea… : SUCCESS in 4m 09s > - announce-release http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/relea… : SUCCESS in 4m 16s > - propose-update-constraints http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/relea… : SUCCESS in 3m 49s > - trigger-readthedocs-webhook http://logs.openstack.org/62/62d263ef737957dce0e83526268f20ae4bdd3b21/relea… : FAILURE in 1m 57s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures It looks like the networking-ansible project needs to do some work on the readthedocs integration. -- Doug

1 0

Octavia Production Deployment Confused
by Zufar Dhiyaulhaq 04 Dec '18

04 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

1 0

[dev][neutron] neutron-lib work items
by Boden Russell 04 Dec '18

04 Dec '18

Awhile back we asked for volunteers willing to help with the neutron-lib effort [1]. Now that we have some volunteers [2], I've gone ahead and added some high-level work items to that list [2]. For those who choose to drive one of the items, please put your name next to it so that we don't step on each others toes during the effort. Feel free to reach out to me for questions/details. Also a friendly reminder to all; please help out this effort by reviewing neutron-lib patches as they arrive in your project's review queue. Thanks [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/135279.ht… [2] https://etherpad.openstack.org/p/neutron-lib-volunteers-and-punch-list

1 0

[sigs] Monthly Update
by Melvin Hillsman 04 Dec '18

04 Dec '18

Hi everyone, During the Forum we discussed one simple way we could move forward to hopefully get more visibility and activity within SIGs. Here is a proposal for such a step. Send out a monthly email to openstack-discuss with the following information from each SIG captured via etherpad [0] 1. What success(es) have you had this month as a SIG? 2. What should we know about the SIG for the next month? 3. What would you like help (hands) or feedback (eyes) on? Besides the ML, other places this could be re-used in whole or part is on social media, SU Blog, etc. Thoughts? [0] https://etherpad.openstack.org/p/sig-updates -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

2 1

[openstack-dev] [kuryr] kuryr libnetwork installation inside the vm is failing
by Vikrant Aggarwal 04 Dec '18

04 Dec '18

Started one Fedora 29 VM on openstack using official qcow2 image. I followed this doc for kuryr installation inside the VM. https://docs.openstack.org/kuryr-libnetwork/latest/readme.html My objective is to run the nested docker i.e inside the VM. While installing the kuryr-libbetwork from the source. it's getting failed with following error: ~~~ [root@vm0 kuryr-libnetwork]# pip install . WARNING: Running pip install with root privileges is generally not a good idea. Try `pip install --user` instead. Processing /root/kuryr-libnetwork Requirement already satisfied: Babel!=2.4.0,>=2.3.4 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (2.6.0) Requirement already satisfied: Flask!=0.11,>=0.10 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.0.2) Requirement already satisfied: ipaddress>=1.0.17 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.0.22) Requirement already satisfied: jsonschema<3.0.0,>=2.6.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (2.6.0) Collecting kuryr-lib>=0.5.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/19/f0/8a425cb4a34ce641e32c5bba3cddc… Requirement already satisfied: neutron-lib>=1.13.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.20.0) Collecting os-client-config>=1.28.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e5/af/2f3bf859a25c98993f85ff1eb1776… Requirement already satisfied: oslo.concurrency>=3.25.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.29.0) Requirement already satisfied: oslo.config>=5.2.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (6.7.0) Requirement already satisfied: oslo.log>=3.36.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.41.0) Requirement already satisfied: oslo.utils>=3.33.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (3.37.1) Requirement already satisfied: pbr!=2.1.0,>=2.0.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (5.1.1) Collecting python-neutronclient>=6.7.0 (from kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/cd/40/2fee7f7f2b562f987c59dfa499ed0… Requirement already satisfied: six>=1.10.0 in /usr/lib/python2.7/site-packages (from kuryr-libnetwork==2.0.1.dev20) (1.11.0) Requirement already satisfied: pytz>=0a in /usr/lib/python2.7/site-packages (from Babel!=2.4.0,>=2.3.4->kuryr-libnetwork==2.0.1.dev20) (2018.7) Requirement already satisfied: Werkzeug>=0.14 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (0.14.1) Requirement already satisfied: click>=5.1 in /usr/lib64/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (7.0) Requirement already satisfied: itsdangerous>=0.24 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: Jinja2>=2.10 in /usr/lib/python2.7/site-packages (from Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (2.10) Requirement already satisfied: functools32; python_version == "2.7" in /usr/lib/python2.7/site-packages (from jsonschema<3.0.0,>=2.6.0->kuryr-libnetwork==2.0.1.dev20) (3.2.3.post2) Requirement already satisfied: keystoneauth1>=3.4.0 in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (3.11.1) Requirement already satisfied: oslo.i18n>=3.15.3 in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (3.23.0) Requirement already satisfied: pyroute2>=0.4.21; sys_platform != "win32" in /usr/lib/python2.7/site-packages (from kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (0.5.3) Requirement already satisfied: SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.2.14) Requirement already satisfied: osprofiler>=1.4.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.5.1) Requirement already satisfied: oslo.versionedobjects>=1.31.2 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.34.1) Requirement already satisfied: oslo.context>=2.19.2 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.21.0) Requirement already satisfied: oslo.policy>=1.30.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.41.1) Requirement already satisfied: oslo.db>=4.27.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.42.0) Requirement already satisfied: os-traits>=0.9.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.10.0) Requirement already satisfied: oslo.serialization!=2.19.1,>=2.18.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.28.1) Requirement already satisfied: oslo.service!=1.28.1,>=1.24.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.33.0) Requirement already satisfied: WebOb>=1.7.1 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.8.4) Requirement already satisfied: oslo.messaging>=5.29.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (9.2.1) Requirement already satisfied: stevedore>=1.20.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.30.0) Requirement already satisfied: weakrefmethod>=1.0.2; python_version == "2.7" in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.3) Requirement already satisfied: pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 in /usr/lib/python2.7/site-packages (from neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.3.2) Collecting openstacksdk>=0.13.0 (from os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/05/e1/38b3fe8b3fa8b78c8917bc78e2aa3… Requirement already satisfied: enum34>=1.0.4; python_version == "2.7" or python_version == "2.6" or python_version == "3.3" in /usr/lib/python2.7/site-packages (from oslo.concurrency>=3.25.0->kuryr-libnetwork==2.0.1.dev20) (1.1.6) Requirement already satisfied: fasteners>=0.7.0 in /usr/lib/python2.7/site-packages (from oslo.concurrency>=3.25.0->kuryr-libnetwork==2.0.1.dev20) (0.14.1) Requirement already satisfied: rfc3986>=0.3.1 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: netaddr>=0.7.18 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (0.7.19) Requirement already satisfied: PyYAML>=3.12 in /usr/lib64/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (3.13) Requirement already satisfied: requests>=2.18.0 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2.20.1) Requirement already satisfied: debtcollector>=1.2.0 in /usr/lib/python2.7/site-packages (from oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.20.0) Requirement already satisfied: monotonic>=1.4 in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (1.5) Requirement already satisfied: python-dateutil>=2.7.0 in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (2.7.5) Requirement already satisfied: pyinotify>=0.9.6; sys_platform != "win32" and sys_platform != "darwin" and sys_platform != "sunos5" in /usr/lib/python2.7/site-packages (from oslo.log>=3.36.0->kuryr-libnetwork==2.0.1.dev20) (0.9.6) Requirement already satisfied: netifaces>=0.10.4 in /usr/lib64/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (0.10.7) Requirement already satisfied: pyparsing>=2.1.0 in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (2.3.0) Requirement already satisfied: funcsigs>=1.0.0; python_version == "2.7" or python_version == "2.6" in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (1.0.2) Requirement already satisfied: iso8601>=0.1.11 in /usr/lib/python2.7/site-packages (from oslo.utils>=3.33.0->kuryr-libnetwork==2.0.1.dev20) (0.1.12) Collecting osc-lib>=1.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/8d/a8/b63a53baed828a3e46ff2d1ee5cb6… Collecting python-keystoneclient>=3.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/51/48/c25bb60d7b95294cc5e49a406ae0b… Collecting cliff!=2.9.0,>=2.8.0 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/8e/1a/5404afee3d83a2e5f27e0d20ac701… Collecting simplejson>=3.5.1 (from python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f8… Requirement already satisfied: MarkupSafe>=0.23 in /usr/lib64/python2.7/site-packages (from Jinja2>=2.10->Flask!=0.11,>=0.10->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: os-service-types>=1.2.0 in /usr/lib/python2.7/site-packages (from keystoneauth1>=3.4.0->kuryr-lib>=0.5.0->kuryr-libnetwork==2.0.1.dev20) (1.3.0) Requirement already satisfied: PrettyTable<0.8,>=0.7.2 in /usr/lib/python2.7/site-packages (from osprofiler>=1.4.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.7.2) Requirement already satisfied: testscenarios>=0.4 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.0) Requirement already satisfied: alembic>=0.9.6 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.5) Requirement already satisfied: testresources>=2.0.0 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.0.1) Requirement already satisfied: sqlalchemy-migrate>=0.11.0 in /usr/lib/python2.7/site-packages (from oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.11.0) Requirement already satisfied: msgpack>=0.5.2 in /usr/lib64/python2.7/site-packages (from oslo.serialization!=2.19.1,>=2.18.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.6) Requirement already satisfied: Paste>=2.0.2 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.4) Requirement already satisfied: PasteDeploy>=1.5.0 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.5.2) Requirement already satisfied: greenlet>=0.4.10 in /usr/lib64/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.4.15) Requirement already satisfied: Routes>=2.3.1 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.4.1) Requirement already satisfied: fixtures>=3.0.0 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.0) Requirement already satisfied: eventlet!=0.18.3,!=0.20.1,>=0.18.2 in /usr/lib/python2.7/site-packages (from oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.24.1) Requirement already satisfied: kombu!=4.0.2,>=4.0.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.2.1) Requirement already satisfied: oslo.middleware>=3.31.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.36.0) Requirement already satisfied: cachetools>=2.0.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.0.0) Requirement already satisfied: futurist>=1.2.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.8.0) Requirement already satisfied: amqp>=2.3.0 in /usr/lib/python2.7/site-packages (from oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.3.2) Requirement already satisfied: logutils>=0.3 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.3.5) Requirement already satisfied: singledispatch in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.4.0.3) Requirement already satisfied: Mako>=0.4.0 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.7) Requirement already satisfied: WebTest>=1.3.1 in /usr/lib/python2.7/site-packages (from pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.0.32) Collecting dogpile.cache>=0.6.2 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/73/bf/0cbed594e4f0f9360bfb98e727613… Requirement already satisfied: decorator>=3.4.0 in /usr/lib/python2.7/site-packages (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) (4.3.0) Requirement already satisfied: futures>=3.0.0; python_version == "2.7" or python_version == "2.6" in /usr/lib/python2.7/site-packages (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) (3.2.0) Collecting requestsexceptions>=1.2.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/01/8c/49ca60ea8c907260da4662582c434… Collecting cryptography>=2.1 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/7f/ba/383b51cc26e3141c689ce98881438… Collecting munch>=2.1.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/68/f4/260ec98ea840757a0da09e0ed8135… Collecting appdirs>=1.3.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/56/eb/810e700ed1349edde4cbdc1b2a21e… Collecting jsonpatch!=1.20,>=1.16 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/a0/e6/d50d526ae2218b765ddbdb2dda14d… Collecting jmespath>=0.9.0 (from openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/b7/31/05c8d001f7f87f0f07289a5fc0fc3… Requirement already satisfied: idna<2.8,>=2.5 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2.7) Requirement already satisfied: chardet<3.1.0,>=3.0.2 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (3.0.4) Requirement already satisfied: urllib3<1.25,>=1.21.1 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.24.1) Requirement already satisfied: certifi>=2017.4.17 in /usr/lib/python2.7/site-packages (from requests>=2.18.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (2018.10.15) Requirement already satisfied: wrapt>=1.7.0 in /usr/lib/python2.7/site-packages (from debtcollector>=1.2.0->oslo.config>=5.2.0->kuryr-libnetwork==2.0.1.dev20) (1.10.11) Collecting cmd2!=0.8.3,<0.9.0; python_version < "3.0" (from cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/e9/40/a71caa2aaff10c73612a7106e2d35… Collecting unicodecsv>=0.8.0; python_version < "3.0" (from cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/6f/a4/691ab63b17505a26096608cc30996… Requirement already satisfied: testtools in /usr/lib/python2.7/site-packages (from testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (2.3.0) Requirement already satisfied: python-editor>=0.3 in /usr/lib/python2.7/site-packages (from alembic>=0.9.6->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.3) Requirement already satisfied: sqlparse in /usr/lib/python2.7/site-packages (from sqlalchemy-migrate>=0.11.0->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.2.4) Requirement already satisfied: Tempita>=0.4 in /usr/lib/python2.7/site-packages (from sqlalchemy-migrate>=0.11.0->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.2) Requirement already satisfied: repoze.lru>=0.3 in /usr/lib/python2.7/site-packages (from Routes>=2.3.1->oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.7) Requirement already satisfied: dnspython>=1.15.0 in /usr/lib/python2.7/site-packages (from eventlet!=0.18.3,!=0.20.1,>=0.18.2->oslo.service!=1.28.1,>=1.24.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.15.0) Requirement already satisfied: statsd>=3.2.1 in /usr/lib/python2.7/site-packages (from oslo.middleware>=3.31.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (3.3.0) Requirement already satisfied: contextlib2>=0.4.0; python_version < "3.0" in /usr/lib/python2.7/site-packages (from futurist>=1.2.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (0.5.5) Requirement already satisfied: vine>=1.1.3 in /usr/lib/python2.7/site-packages (from amqp>=2.3.0->oslo.messaging>=5.29.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.4) Requirement already satisfied: beautifulsoup4 in /usr/lib/python2.7/site-packages (from WebTest>=1.3.1->pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (4.6.3) Requirement already satisfied: waitress>=0.8.5 in /usr/lib/python2.7/site-packages (from WebTest>=1.3.1->pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Collecting cffi!=1.11.3,>=1.7 (from cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/14/dd/3e7a1e1280e7d767bd3fa15791759… Collecting asn1crypto>=0.21.0 (from cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e… Collecting jsonpointer>=1.9 (from jsonpatch!=1.20,>=1.16->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/18/b0/a80d29577c08eea401659254dfaed… Requirement already satisfied: pyperclip in /usr/lib/python2.7/site-packages (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) (1.7.0) Requirement already satisfied: wcwidth; sys_platform != "win32" in /usr/lib/python2.7/site-packages (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) (0.1.7) Collecting subprocess32; python_version < "3.0" (from cmd2!=0.8.3,<0.9.0; python_version < "3.0"->cliff!=2.9.0,>=2.8.0->python-neutronclient>=6.7.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/be/2b/beeba583e9877e64db10b52a96915… Requirement already satisfied: extras>=1.0.0 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.0) Requirement already satisfied: unittest2>=1.0.0 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.1.0) Requirement already satisfied: traceback2 in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.4.0) Requirement already satisfied: python-mimeparse in /usr/lib/python2.7/site-packages (from testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.6.0) Collecting pycparser (from cffi!=1.11.3,>=1.7->cryptography>=2.1->openstacksdk>=0.13.0->os-client-config>=1.28.0->kuryr-libnetwork==2.0.1.dev20) Using cached https://files.pythonhosted.org/packages/68/9e/49196946aee219aead1290e00d1e7… Requirement already satisfied: argparse in /usr/lib/python2.7/site-packages (from unittest2>=1.0.0->testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.4.0) Requirement already satisfied: linecache2 in /usr/lib/python2.7/site-packages (from traceback2->testtools->testscenarios>=0.4->oslo.db>=4.27.0->neutron-lib>=1.13.0->kuryr-libnetwork==2.0.1.dev20) (1.0.0) Installing collected packages: subprocess32, cmd2, unicodecsv, cliff, dogpile.cache, requestsexceptions, pycparser, cffi, asn1crypto, cryptography, munch, appdirs, jsonpointer, jsonpatch, jmespath, openstacksdk, simplejson, osc-lib, python-keystoneclient, os-client-config, python-neutronclient, kuryr-lib, kuryr-libnetwork Running setup.py install for subprocess32 ... error Complete output from command /usr/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-tVH19b/subprocess32/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-_SN4DI/install-record.txt --single-version-externally-managed --compile: running install running build running build_py creating build creating build/lib.linux-x86_64-2.7 copying subprocess32.py -> build/lib.linux-x86_64-2.7 running build_ext running build_configure checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/tmp/pip-install-tVH19b/subprocess32': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details Traceback (most recent call last): File "<string>", line 1, in <module> File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 120, in <module> main() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 114, in main 'Programming Language :: Python :: Implementation :: CPython', File "/usr/lib/python2.7/site-packages/setuptools/__init__.py", line 140, in setup return distutils.core.setup(**attrs) File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib/python2.7/site-packages/setuptools/command/install.py", line 61, in run return orig.install.run(self) File "/usr/lib64/python2.7/distutils/command/install.py", line 563, in run self.run_command('build') File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 41, in run self.run_command(command) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/tmp/pip-install-tVH19b/subprocess32/setup.py", line 26, in run raise RuntimeError(configure_command + ' failed.') RuntimeError: sh ./configure failed. ---------------------------------------- Command "/usr/bin/python2 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-tVH19b/subprocess32/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-_SN4DI/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-tVH19b/subprocess32/ ~~~ python-dev and docker is already installed on the machine. Any help is highly appreciated. Thanks & Regards, Vikrant Aggarwal __________________________________________________________________________ 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

2 1

[tripleo][openstack-ansible] collaboration on os_tempest role update II
by Chandan kumar 04 Dec '18

04 Dec '18

Hello, It's more than 2 weeks, here is the another updates on what we have done till today i.e. on Dec 4th, 2018 on collaborating on os_tempest role [1]. * Add centos-7 job with support to python-tempestconf - https://review.openstack.org/#/c/619021/ * Enable support to pass override option to tempestconf - https://review.openstack.org/#/c/619986/ * Added task to list tempest tests - https://review.openstack.org/619024 Work still going on: * Use tempest run for generating subunit results - https://review.openstack.org/621584 * python-tempestconf extra cli support in os_tempest - https://review.openstack.org/620800 * Better blacklist and whitelist tests management - https://review.openstack.org/621605 In upcoming two weeks, we are planning to finish * complete python-tempestconf named_arguments support in os_tempest * Better blacklist and whitelist tests management. Here is the first update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136452.html Thanks, Chandan Kumar

1 0

[ops] Ops Meetup proposal, Berlin, early 2019
by Chris Morgan 04 Dec '18

04 Dec '18

Hello Everyone, Deutsche Telekom has kindly offered to host an OpenStack Operators Meetup early next year see https://etherpad.openstack.org/p/ops-meetup-venue-discuss-1st-2019-berlin This is the only current offer so far for the first Ops Meetup of 2019 so is very likely to be approved. If you have feedback on this please join us at our weekly IRC meeting or forward your feedback to an Ops Meetups Team member (see https://wiki.openstack.org/wiki/Ops_Meetups_Team for details of the current team). This proposal meets the consensus goal of Europe as the region for the 1st meetup, making it likely that the following one later in 2019 would be in North America. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[ops] last week's Ops Meetups team minutes
by Chris Morgan 04 Dec '18

04 Dec '18

Meeting ended Tue Nov 27 15:56:56 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:57 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:57 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… 10:57 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2018/ops_meetup_tea… Next meeting in just under an hour from now on #openstack-operators Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[neutron] [octavia] Manual deployment step for octavia on packstack
by Vikrant Aggarwal 04 Dec '18

04 Dec '18

Hello Team, Do we have the steps documented somewhere to install octavia manually like we have for zun [1]? I have done the openstack deployment using packstack and now I want to install the octavia manually on it. I have done the following steps: # groupadd --system octavia # useradd --home-dir "/var/lib/octavia" --create-home --system --shell /bin/false -g octavia octavia # cd /var/lib/octavia/ # git clone https://github.com/openstack/octavia.git # chown -R octavia:octavia * # pip install -r requirements.txt # python setup.py install # openstack user create --domain default --password-prompt octavia # openstack role add --project service --user octavia admin # openstack service create --name octavia --description "Octavia Service" "Octavia Load Balancing Servic" # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" public http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" admin http://10.121.19.50:9876/v1 # openstack endpoint create --region RegionOne "Octavia Load Balancing Servic" internal http://10.121.19.50:9876/v1 Made the following changes in the configuration file. [root@packstack1 octavia(keystone_admin)]# diff etc/octavia.conf /etc/octavia/octavia.conf 20,21c20,21 < # bind_host = 127.0.0.1 < # bind_port = 9876 --- > bind_host = 10.121.19.50 > bind_port = 9876 38c38 < # api_v2_enabled = True --- > # api_v2_enabled = False 64c64 < # connection = mysql+pymysql:// --- > connection = mysql+pymysql://octavia:octavia@10.121.19.50/octavia 109c109 < # www_authenticate_uri = https://localhost:5000/v3 --- > www_authenticate_uri = https://10.121.19.50:5000/v3 111,114c111,114 < # auth_url = https://localhost:5000/v3 < # username = octavia < # password = password < # project_name = service --- > auth_url = https://10.121.19.50:35357/v3 > username = octavia > password = octavia > project_name = service 117,118c117,118 < # project_domain_name = Default < # user_domain_name = Default --- > project_domain_name = default > user_domain_name = default Generated the certificates using the script and copy the following certificates in octavia: [root@packstack1 octavia(keystone_admin)]# cd /etc/octavia/ [root@packstack1 octavia(keystone_admin)]# ls -lhrt total 28K -rw-r--r--. 1 octavia octavia 14K Dec 4 05:50 octavia.conf -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.key -rw-r--r--. 1 octavia octavia 989 Dec 4 05:55 client.csr -rw-r--r--. 1 octavia octavia 1.7K Dec 4 05:55 client.pem Can anyone please guide me about the further configuration? [1] https://docs.openstack.org/zun/latest/install/controller-install.html Thanks & Regards, Vikrant Aggarwal

1 0

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

04 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

[openlab] Weekly Meeting
by Melvin Hillsman 03 Dec '18

03 Dec '18

Hi everyone, Please see the following links for full log of today’s meeting and a more concise summary: Full Log: https://meetings.openlabtesting.org/devops/2018/devops.2018-12-04-02.00.log… Summary (Minutes): https://meetings.openlabtesting.org/devops/2018/devops.2018-12-04-02.00.html Help Wanted: Setup os_loganalyze – https://github.com/theopenlab/openlab/issues/137 There is always an opportunity to grab items off the project board – https://github.com/orgs/theopenlab/projects/1 If you have any questions regarding the meeting please send email response to this email for follow-up. -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[openstack-dev] [Neutron] Bugs deputy report week of November 26th
by Miguel Lavalle 03 Dec '18

03 Dec '18

Hi Neutron team, I was the bugs deputy the week of November 26th. It was a relatively quite week. These are the bugs reported during the period: *Medium priority* - https://bugs.launchpad.net/neutron/+bug/1805824, The dhcp port's address may be messed when the port's network has multiple subnets. Fix proposed here: https://review.openstack.org/#/c/620900/. It undoes a previous fix, https://bugs.launchpad.net/neutron/+bug/1581918, so another alternative has to be found - https://bugs.launchpad.net/neutron/+bug/1805808, Openvswitch firewall driver don't reinitialize after ovs-vswitchd restart. Fix proposed here: https://review.openstack.org/620886 - https://bugs.launchpad.net/neutron/+bug/1805456, [DVR] Neutron doesn't configure multiple external subnets for one network properly. Owner assigned *Low priority* - https://bugs.launchpad.net/neutron/+bug/1805844*, *When debugging fullstack tests, "cmd" module is incorrectly imported*. *Fix already in progress: https://review.openstack.org/620916 - https://bugs.launchpad.net/neutron/+bug/1805126, confusing wording in config-dns-int.rst. Fixed proposed: https://review.openstack.org/620017 *Incomplete* - https://bugs.launchpad.net/neutron/+bug/1805769, maximum RPC response timeout is not reasonable. Requested clarification from submitter - https://bugs.launchpad.net/neutron/+bug/1805356, Convert instance method to staticmethod in linux bridge agent. Requested clarification from submitter *Needs further investigation* - https://bugs.launchpad.net/neutron/+bug/1805132, bulk creation of security group rules fails StaleDataError. Couldn't reproduce

1 0

[openstack-dev] [magnum] kubernetes images for magnum rocky
by Spyros Trigazis 03 Dec '18

03 Dec '18

Hello all, Following the vulnerability [0], with magnum rocky and the kubernetes driver on fedora atomic you can use this tag "v1.11.5-1" [1] for new clusters. To upgrade the apiserver in existing clusters, on the master node(s) you can run: sudo atomic pull --storage ostree docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 sudo atomic containers update --rebase docker.io/openstackmagnum/kubernetes-apiserver:v1.11.5-1 kube-apiserver You can upgrade the other k8s components with similar commands. I'll share instructions for magnum queens tomorrow morning CET time. Cheers, Spyros [0] https://github.com/kubernetes/kubernetes/issues/71411 [1] https://hub.docker.com/r/openstackmagnum/kubernetes-apiserver/tags/ __________________________________________________________________________ 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

1 2

[all] We've combined the lists! Now what?
by Jeremy Stanley 03 Dec '18

03 Dec '18

As previously discussed[0], proposed[1] and subsequently announced[2], the openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists are being replaced by this new mailing list to which you've subscribed. As of now it's officially open for posts from subscribers, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. Here follows few brief notes on the nature of this new list: 1. Like mentioned in the original announcement, there is an etherpad[3] where we can brainstorm subject tags we want to use. I think most of our needs are already covered there, but I'll give it a little longer to collect more ideas before I attempt to document them somewhere durable. We've already got these as a start: all, ops, dev, $projectname, $signame-sig, $groupname-wg, release, goals, uc, tc, ptl. Because we're interested in moving to Mailman 3 as our listserv in the not-too-distant future and the upstream Mailman maintainers decided to drop support for server-side topic filters, you'll need to set up client-side mail filtering if you're only interested in seeing messages for a subset of them. 2. As I've subscribed the new list to the old ones, cross-posts between them may result in some message duplication, but at least we won't have to endure it for long. 3. Remember there is no Subject header mangling on this list, so if you want to perform client-side matching it's strongly recommended you use the List-Id header to identify it. You'll likely also notice there is no list footer appended to every message. These changes in behavior from our previous lists are part of an effort to avoid creating unnecessary DMARC/DKIM violations. 4. This list is starting out with 280 early subscribers, but I expect a bunch more before the old lists are finally closed down in 3 weeks' time. [0] https://etherpad.openstack.org/p/infra-ptg-denver-2018 [1] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134046.html [2] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… [3] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley

5 9

[nova][ops] Migrating instances with old extra specs info.
by Roman Dobosz 03 Dec '18

03 Dec '18

Hi, We have an issue regarding live migrate old instances. On our infrastructure based on Newton, we had not well named our aggregation groups and we decided to completely change the naming conventions. We are using extra specs/metadata in flavors/aggregates and AggregateInstanceExtraSpecsFilter to select the set of hosts. After changing one of the key (lets call it 'kind') of extra spec/metadata to the new value, we are able to create new instances, but unable to live-migrate old one. This is because of stored flavor extra specs in instance_extra, which still holds the old value for the 'kind' key, and make the aggregate filter fail to match the hosts. In our opinion, it should be able to live-migrate such instance, since only the flavor metadata has changed, while other fields doesn't (vcpus, memory, disk). Is it a bug? Or maybe it is possible to change the instance flavor extra spec? -- Cheers, Roman Dobosz

3 6

[oslo] Berlin Summit Recap
by Ben Nemec 03 Dec '18

03 Dec '18

A bit late because I was on PTO the week after and it turns out I had a lot more to say than I realized. :-) There wasn't a ton of Oslo stuff going on, but there were a few interesting things that I discuss in [1]. I also ended up writing my thoughts about some non-Oslo-specific sessions I attended, including one that I split off in its own post because it got a bit long and deserved standalone attention[2]. 1: http://blog.nemebean.com/content/berlin-summit-recap 2: http://blog.nemebean.com/content/upstream-openstack-performance-and-release… -Ben

1 0

[senlin] New meeting time for odd weeks
by Jude Cross 03 Dec '18

03 Dec '18

+1 -------------------------------------------------------------------------------------------------------------------- As discussed in our last Senlin meeting [1], I would like to propose holding the weekly meeting during odd weeks at a time that is more convenient for US and Europe. The proposal is to have the meeting at 19:00 UTC (11am PST) for odd weeks, while the meeting time for even weeks stays at the current time of 5:30 UTC. If accepted, the meeting times for upcoming weeks would be as follows: - Thursday, December 6, 2018 at 19:00:00 UTC - Friday, December 14, 2018 at 05:30:00 UTC - Thursday, December 20, 2018 at 19:00:00 UTC ... Please reply with any feedback. Regards, Duc (dtruong) [1] http://eavesdrop.openstack.org/meetings/senlin/2018/senlin.2018-11-30-05.30…

1 0

[openstack-dev] [kuryr] can we start kuryr libnetwork in container inside the nova VM.
by Vikrant Aggarwal 03 Dec '18

03 Dec '18

Hello Team, I have seen the steps of starting the kuryr libnetwork container on compute node. But If I need to run the same container inside the VM running on compute node, is't possible to do that? I am not sure how can I map the /var/run/openvswitch inside the nested VM because this is present on compute node. https://docs.openstack.org/kuryr-libnetwork/latest/readme.html Thanks & Regards, Vikrant Aggarwal __________________________________________________________________________ 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

2 3

[ptl][release] Proposed changes for cycle-with-intermediary services releases
by Sean McGinnis 03 Dec '18

03 Dec '18

This is a continuation of the effort the release team had started after the Denver PTG with simplifying and better aligning the release models in use. We noticed a handful of projects that had, intentionally or unintentionally, only made one release during the Rocky cycle. This result wasn't quite was intended, so we had discussed how we might encourage things so consumers of the community output get what they are expecting during the cycle. The intermediary model should be used to be able to deliver multiple releases at any point throughout the cycle. It should not be used as a way to avoid doing any releases until the very end of the cycle. To encourage (force?) this, we would require at least two releases of a non-library cycle-with-intermediary project during the cycle. If a release is not done by milestone 2, these projects would be switched to the new cycle-with-rc. This may actually be preferable for some with the reduced administrative overhead that should provide. Of course, teams are encouraged to decide and follow their preferred release model for whatever makes the most sense for their project. If you are the PTL or release liaison for one of these projects, please take some time to consider if the current cycle-with-intermediary release model is right for you, or if you should switch over to the newer cycle-with-rc model. The release team will review the current state of things after the second milestone at the beginning of January to try to help any projects that may benefit from choosing a different declared release model. Thanks! Sean McGinnis and the Release Team

1 0

Fwd: [Action Needed] Update your Zoom clients
by Melvin Hillsman 03 Dec '18

03 Dec '18

Hi everyone, It was mentioned to me last week an issue with Zoom by some community members who know I use it and I keep my client updated but maybe you do not. Got another email this morning so, that being said, if you did not already know: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15715 Upgrade your client: https://support.zoom.us/hc/en-us/articles/201362233-Where-Do-I-Download-The… -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[all][uc] OpenStack UC Meeting @ 1900 UTC
by Melvin Hillsman 03 Dec '18

03 Dec '18

Hi everyone, Just a reminder that the UC meeting will be in #openstack-uc in a little more than an hour and a half from now. Please feel empowered to add to the agenda here - https://etherpad.openstack.org/p/uc - and we hope to see you there! -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[goal][python3] week R-18 update
by Doug Hellmann 03 Dec '18

03 Dec '18

This is the weekly update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html) I've missed sending this email for a few weeks again, due to the Summit, holiday, and then illness. == Ongoing and Completed Work == We're still making good progress, but several teams have a ways to go on the tox defaults patches and 3.6 unit tests. Please prioritize these reviews so we can move on to the more complicated parts of the goal! +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ | Team | tox defaults | Docs | 3.6 unit | Failing | Unreviewed | Total | Champion | +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ | adjutant | 1/ 1 | - | + | 0 | 1 | 2 | Doug Hellmann | | barbican | + | 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | blazar | + | + | + | 0 | 0 | 9 | Nguyen Hai | | Chef OpenStack | + | - | - | 0 | 0 | 2 | Doug Hellmann | | cinder | + | + | + | 0 | 0 | 11 | Doug Hellmann | | cloudkitty | + | + | + | 0 | 0 | 9 | Doug Hellmann | | congress | + | + | + | 0 | 0 | 9 | Nguyen Hai | | cyborg | + | + | + | 0 | 0 | 7 | Nguyen Hai | | designate | + | + | + | 0 | 0 | 9 | Nguyen Hai | | Documentation | + | + | + | 0 | 0 | 10 | Doug Hellmann | | ec2-api | + | + | + | 0 | 0 | 7 | | | freezer | + | + | + | 0 | 0 | 11 | | | glance | + | + | + | 0 | 0 | 10 | Nguyen Hai | | heat | 2/ 8 | + | 1/ 7 | 1 | 0 | 21 | Doug Hellmann | | horizon | + | + | + | 0 | 0 | 34 | Nguyen Hai | | I18n | + | - | - | 0 | 0 | 1 | Doug Hellmann | | InteropWG | 2/ 3 | + | 1/ 3 | 1 | 1 | 9 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 | 35 | Doug Hellmann | | karbor | + | + | + | 0 | 0 | 7 | Nguyen Hai | | keystone | + | + | + | 0 | 0 | 18 | Doug Hellmann | | kolla | + | + | + | 0 | 0 | 5 | | | kuryr | + | + | + | 0 | 0 | 9 | Doug Hellmann | | magnum | 2/ 5 | + | + | 0 | 1 | 10 | | | manila | + | + | + | 0 | 0 | 13 | Goutham Pacha Ravi | | masakari | 2/ 5 | + | - | 0 | 2 | 6 | Nguyen Hai | | mistral | + | + | + | 0 | 0 | 13 | Nguyen Hai | | monasca | 1/ 17 | + | + | 0 | 1 | 34 | Doug Hellmann | | murano | + | + | + | 0 | 0 | 14 | | | neutron | 5/ 19 | 1/ 14 | 1/ 13 | 4 | 3 | 46 | Doug Hellmann | | nova | + | + | + | 0 | 0 | 14 | | | octavia | + | + | + | 0 | 0 | 12 | Nguyen Hai | | OpenStack Charms | 8/ 73 | - | - | 8 | 3 | 73 | Doug Hellmann | | OpenStack-Helm | + | + | - | 0 | 0 | 4 | | | OpenStackAnsible | + | + | - | 0 | 0 | 152 | | | OpenStackClient | + | + | + | 0 | 0 | 11 | | | OpenStackSDK | + | + | + | 0 | 0 | 10 | | | oslo | + | + | + | 0 | 0 | 63 | Doug Hellmann | | Packaging-rpm | + | + | + | 0 | 0 | 6 | Doug Hellmann | | PowerVMStackers | - | - | + | 0 | 0 | 3 | Doug Hellmann | | Puppet OpenStack | + | + | - | 0 | 0 | 44 | Doug Hellmann | | qinling | + | + | + | 0 | 0 | 6 | | | Quality Assurance | 3/ 11 | + | + | 0 | 2 | 32 | Doug Hellmann | | rally | 1/ 3 | + | - | 1 | 1 | 5 | Nguyen Hai | | Release Management | - | - | + | 0 | 0 | 1 | Doug Hellmann | | requirements | - | + | + | 0 | 0 | 2 | Doug Hellmann | | sahara | 1/ 6 | + | + | 0 | 0 | 13 | Doug Hellmann | | searchlight | + | + | + | 0 | 0 | 9 | Nguyen Hai | | senlin | + | + | + | 0 | 0 | 9 | Nguyen Hai | | SIGs | + | + | + | 0 | 0 | 13 | Doug Hellmann | | solum | + | + | + | 0 | 0 | 7 | Nguyen Hai | | storlets | + | + | + | 0 | 0 | 4 | | | swift | 2/ 3 | + | + | 1 | 1 | 6 | Nguyen Hai | | tacker | 1/ 3 | + | + | 0 | 1 | 8 | Nguyen Hai | | Technical Committee | + | - | + | 0 | 0 | 4 | Doug Hellmann | | Telemetry | 1/ 7 | + | + | 0 | 1 | 19 | Doug Hellmann | | tricircle | + | + | + | 0 | 0 | 5 | Nguyen Hai | | tripleo | 5/ 55 | + | + | 3 | 1 | 93 | Doug Hellmann | | trove | 1/ 5 | + | + | 0 | 0 | 11 | Doug Hellmann | | User Committee | 3/ 3 | + | - | 0 | 2 | 5 | Doug Hellmann | | vitrage | + | + | + | 0 | 0 | 9 | Nguyen Hai | | watcher | + | + | + | 0 | 0 | 10 | Nguyen Hai | | winstackers | + | + | + | 0 | 0 | 6 | | | zaqar | + | + | + | 0 | 0 | 8 | | | zun | + | + | + | 0 | 0 | 8 | Nguyen Hai | | | 43/ 61 | 55/ 57 | 52/ 55 | 20 | 22 | 1075 | | +---------------------+--------------+---------+----------+---------+------------+-------+--------------------+ == Next Steps == We need to to approve the patches proposed by the goal champions, and then to expand functional test coverage for python 3. PTLs, please document your team's status in the wiki as well: https://wiki.openstack.org/wiki/Python3 == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Ve… 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug

1 0

[Openstack-operators] Spice screen in horizon
by Jawad Ahmed 03 Dec '18

03 Dec '18

Hi all, How can I fit spice screen*(vm console| black screen)* to horizon console. Please see the attachment.Also below messages ,keyboard input is insecure etc.If someone can suggest workaround to remove those messages. I ll appreciate any kind of suggestions.Thank you. -- Greetings, Jawad _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

[openstack-dev] Stepping down from Neutron core team
by Hirofumi Ichihara 03 Dec '18

03 Dec '18

Hi all, I’m stepping down from the core team because my role changed and I cannot have responsibilities of neutron core. My start of neutron was 5 years ago. I had many good experiences from neutron team. Today neutron is great project. Neutron gets new reviewers, contributors and, users. Keep on being a great community. Thanks, Hirofumi __________________________________________________________________________ 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

5 5

[openstack-ansible] Evaluating meeting schedule + method
by Mohammed Naser 03 Dec '18

03 Dec '18

Hey everyone: Over the past few weeks, the OpenStack Ansible meetings have had increasingly less attendance. In addition, the engagement seems to be decreased as well. I think IRC meetings are generally awful and it's really hard to come up with a proper engagement, because you get pulled into 60 other things and the meeting gets forgotten. I'd like to suggest a few things: - Look into a voice-based meeting system which is recorded + notes: This will help with engagement and discussion, we'll actually be able to get things done. - Change meeting topics: perhaps people don't care about what we discuss? - Change meetings to once every 2 weeks or month (or even cancel them). I'm sending this to the community to hear what they have to say about this. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[Searchlight] Cancel meeting today
by Trinh Nguyen 03 Dec '18

03 Dec '18

Hi team, Everybody is busy today so we will cancel the meeting today. Please ping me on the channel #openstack-searchlight. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[openstack-dev][sahara] Sahara APIv2 Worklist
by Telles Nobrega 03 Dec '18

03 Dec '18

Hi Saharans, One of the main focus of this cycle, and it has been for a while now, is the work on APIv2. During the last Sahara meeting we came up with a list of the reamining work left so we can release APIv2 as stable this cycle. I created a worklist[1] on storyboard so we can more easily track the progress of the few remaining tasks. Thanks all, [1] https://storyboard.openstack.org/#!/worklist/533 -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil <https://www.redhat.com/> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo tenobreg(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil pelo Great Place to Work.

1 0

Re: [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
by Bogdan Dobrelya 03 Dec '18

03 Dec '18

To follow up and explain the patches for code review: The "header" patch https://review.openstack.org/620310 -> (requires) https://review.rdoproject.org/r/#/c/17534/, and also https://review.openstack.org/620061 -> (which in turn requires) https://review.openstack.org/619744 -> (Kolla change, the 1st to go) https://review.openstack.org/619736 Please also read the commit messages, I tried to explain all "Whys" very carefully. Just to sum up it here as well: The current self-containing (config and runtime bits) architecture of containers badly affects: * the size of the base layer and all containers images as an additional 300MB (adds an extra 30% of size). * Edge cases, where we have containers images to be distributed, at least once to hit local registries, over high-latency and limited bandwith, highly unreliable WAN connections. * numbers of packages to update in CI for all containers for all services (CI jobs do not rebuild containers so each container gets updated for those 300MB of extra size). * security and the surface of attacks, by introducing systemd et al as additional subjects for CVE fixes to maintain for all containers. * services uptime, by additional restarts of services related to security maintanence of irrelevant to openstack components sitting as a dead weight in containers images for ever. On 11/27/18 4:08 PM, Bogdan Dobrelya wrote: > Changing the topic to follow the subject. > > [tl;dr] it's time to rearchitect container images to stop incluiding > config-time only (puppet et al) bits, which are not needed runtime and > pose security issues, like CVEs, to maintain daily. > > Background: 1) For the Distributed Compute Node edge case, there is > potentially tens of thousands of a single-compute-node remote edge sites > connected over WAN to a single control plane, which is having high > latency, like a 100ms or so, and limited bandwith. > 2) For a generic security case, > 3) TripleO CI updates all > > Challenge: > >> Here is a related bug [1] and implementation [1] for that. PTAL folks! >> >> [0] https://bugs.launchpad.net/tripleo/+bug/1804822 >> [1] https://review.openstack.org/#/q/topic:base-container-reduction >> >>> Let's also think of removing puppet-tripleo from the base container. >>> It really brings the world-in (and yum updates in CI!) each job and >>> each container! >>> So if we did so, we should then either install puppet-tripleo and co >>> on the host and bind-mount it for the docker-puppet deployment task >>> steps (bad idea IMO), OR use the magical --volumes-from >>> <a-side-car-container> option to mount volumes from some >>> "puppet-config" sidecar container inside each of the containers being >>> launched by docker-puppet tooling. >> >> On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås <hjensas at redhat.com> >> wrote: >>> We add this to all images: >>> >>> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646… >>> >>> >>> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python >>> socat sudo which openstack-tripleo-common-container-base rsync cronie >>> crudini openstack-selinux ansible python-shade puppet-tripleo python2- >>> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >>> Is the additional 276 MB reasonable here? >>> openstack-selinux <- This package run relabling, does that kind of >>> touching the filesystem impact the size due to docker layers? >>> >>> Also: python2-kubernetes is a fairly large package (18007990) do we use >>> that in every image? I don't see any tripleo related repos importing >>> from that when searching on Hound? The original commit message[1] >>> adding it states it is for future convenience. >>> >>> On my undercloud we have 101 images, if we are downloading every 18 MB >>> per image thats almost 1.8 GB for a package we don't use? (I hope it's >>> not like this? With docker layers, we only download that 276 MB >>> transaction once? Or?) >>> >>> >>> [1] https://review.openstack.org/527927 >> >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando > > -- Best regards, Bogdan Dobrelya, Irc #bogdando

10 27

[forum][tc] Summary of the Vision for OpenStack Clouds session
by Zane Bitter 02 Dec '18

02 Dec '18

During the Berlin summit there were a couple of discussions about the Vision for OpenStack Clouds, culminating in the initial version being merged. You can find it published here: https://governance.openstack.org/tc/reference/technical-vision.html During the joint leadership meeting on the Monday before the Summit, the TC presented the latest draft of the vision to the Foundation Board.[1] All of the feedback we received from board members was positive. Paper copies of the draft were available at the meeting, and it was also posted to the foundation mailing list afterwards.[2] This was followed on Thursday by a Forum session to discuss the next steps: https://etherpad.openstack.org/p/BER-cloud-vision With the review having already accumulated the required number of votes from the TC and nobody objecting, we determined that the next step should be to approve the draft and publish it. This is intended to be a living document, so in that spirit we'll continue to make ongoing tweaks based on feedback. A number of evolutionary improvements have been suggested (my summary): * (mordred) The SDK supports a use case where each Region in a cloud has its own Keystone endpoint, with the data synced behind the scenes. The definition of 'region' contained in the vision does not cover this. ayoung will submit a patch to update the wording. * (gmann) We could mention something about feature discovery in the section on OpenStack-specific considerations, to help ensure interoperability. * (fungi) We could also more explicitly declare that leaking implementation details into the API and beyond is something we're trying to avoid for interoperability reasons. fungi will submit a patch to do that. Doug also suggested that we should try to get this document incorporated into the main openstack.org website somehow, since the governance site is not especially visible even within the technical community and might as well not exist for those outside it. There are technical challenges with keeping a non-static document in sync to openstack.org, and publishing a forward-looking document like this verbatim to a wider audience might risk creating some confusion. However, it would be a shame to squander this opportunity for the technical community to collaborate more with the Foundation's marketing team in how we portray the goals of the OpenStack project. I will contact Lauren Sell on behalf of the TC to start a discussion on how we can make the best use of the document. [1] https://docs.google.com/presentation/d/1wcG7InY2A5y67dt5lC14CI1gQHGZ3db8-ys… [2] http://lists.openstack.org/pipermail/foundation/2018-November/002657.html

1 0

[openstack-dev] [nova] about notification in nova
by Rambo 02 Dec '18

02 Dec '18

Hi, all： I have a question about the notification in nova, that is the actual operator is different from the operator was record in panko. Such as the delete action, we create the VM as user1, and we delete the VM as user2， but the operator is user1 who delete the VM in panko event, not the actual operator user2. Can you tell me more about this?Thank you very much. Best Regards Rambo __________________________________________________________________________ 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

3 2

[Searchlight] Meeting today at 13:30 UTC
by Trinh Nguyen 02 Dec '18

02 Dec '18

Hi team, We will have the team meeting today at 13:30 UTC on #openstack-searchlight. Please join me and the others! Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0