December 2018 - openstack-discuss

[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