- openstack-discuss - lists.openstack.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03 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

[dev][nova] Yay Friday gate regressions!
by Matt Riedemann 01 Dec '18

01 Dec '18

Just FYI there are a couple of regressions hitting nova unit and functional test jobs right now: https://bugs.launchpad.net/nova/+bug/1806123 ^ Is likely due to mocking a global for the new I/O concurrency semaphore stuff in the libvirt driver. I'm not sure what we should do about that one. During the code review I suggested writing a fixture which would essentially maintain the context manager (so we have __enter__ and __exit__) but just make it a noop, but we still want to make sure it's called in places where it's used. https://bugs.launchpad.net/nova/+bug/1806126 ^ Is a bit hairier since I'm seeing both weird, potentially global mock, failures and also timeouts, also potentially because of mocking globals. Since there is no functional code change tied to that one yet (it's still being reviewed, this was a recreate test change only), I have proposed a revert to try and stem the bleeding unless someone (mdbooth?) can root cause and fix it faster. Happy rechecking! -- Thanks, Matt

2 1

[senlin] New meeting time for odd weeks
by Duc Truong 01 Dec '18

01 Dec '18

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] [nova] Would an api option to create an instance without powering on be useful?
by Matthew Booth 01 Dec '18

01 Dec '18

I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __________________________________________________________________________ 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 4