Re: [openstack-dev] [tripleo] Workflows Squad changes
On Wed, Nov 28, 2018 at 5:13 AM Jiri Tomasek wrote: [...] > As a possible solution, I would like to propose Adriano as a core reviewer > to tripleo-common and adding tripleo-ui cores right to +2 tripleo-common > patches. > [...] Not a member of the squad but +2 to the idea Thanks for proposing, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Feedback about our project at Summit
Hi folks, I wasn't at the Summit but I was interested by the feedback people gave about TripleO so I've discussed with a few people who made the trip. I would like to see what actions we can take on short and long term to address it. I collected some thoughts here: https://etherpad.openstack.org/p/BER-tripleo-feedback Which is based on https://etherpad.openstack.org/p/BER-deployment-tools-feedback initially. Feel fee to add more feedback if missing, and also comment what was written. If you're aware of some WIP that address the feedback, adjust some wording if needed or just put some links if something exists and is documented already. I believe it is critical to us to listen this feedback and include some of it into our short term roadmap, so we can reduce some frustration that we can hear sometimes. Thanks for your help, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [stable] Deprecation of newton branches
+1 for me, I haven't seen much interest in keeping these branches for puppet modules. I also would like to hear from our users though. On Mon, Nov 19, 2018 at 3:18 AM Tobias Urdin wrote: > Hello, > > We've been talking for a while about the deprecation and removal of the > stable/newton branches. > I think it's time now that we get rid of them, we have no open patches > and Newton is considered EOL. > > Could cores get back with a quick feedback and then the stable team can > get rid of those whenever they have time. > > Best regards > Tobias > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO
+1 to have him part of TripleO CI core team, thanks for your dedication and hard work. I'm glad to see you're learning fast. Keep your motivation and thanks again! On Thu, Nov 15, 2018 at 11:33 AM Alex Schultz wrote: > +1 > On Thu, Nov 15, 2018 at 8:51 AM Sagi Shnaidman > wrote: > > > > Hi, > > I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. > Quique is actively involved in improvements and development of TripleO and > TripleO CI. He also helps in other projects including but not limited to > Infrastructure. > > He shows a very good understanding how TripleO and CI works and I'd like > suggest him as core reviewer of TripleO in CI related code. > > > > Please vote! > > My +1 is here :) > > > > Thanks > > -- > > Best regards > > Sagi Shnaidman > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] no recheck / no workflow until gate is stable
We have serious issues with the gate at this time, we believe it is a mix of mirrors errors (infra) and tempest timeouts (see https://review.openstack.org/617845). Until the situation is resolved, do not recheck or approve any patch for now. Thanks for your understanding, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] CI is broken
No alert anymore, gate is green. recheck if needed. On Wed, Nov 7, 2018 at 2:22 PM Emilien Macchi wrote: > I updated the bugs, and so far we have one alert left: > https://bugs.launchpad.net/tripleo/+bug/1801969 > > The patch is in gate, be patient and then we'll be able to +A/recheck > stuff again. > > On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles < > jaosor...@redhat.com> wrote: > >> Hello folks, >> >> >> Please do not attempt to merge or recheck patches until we get this >> sorted out. >> >> We are dealing with several issues that have broken all jobs. >> >> https://bugs.launchpad.net/tripleo/+bug/1801769 >> https://bugs.launchpad.net/tripleo/+bug/1801969 >> https://bugs.launchpad.net/tripleo/+bug/1802083 >> https://bugs.launchpad.net/tripleo/+bug/1802085 >> >> Best Regards! >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] CI is broken
I updated the bugs, and so far we have one alert left: https://bugs.launchpad.net/tripleo/+bug/1801969 The patch is in gate, be patient and then we'll be able to +A/recheck stuff again. On Wed, Nov 7, 2018 at 7:30 AM Juan Antonio Osorio Robles < jaosor...@redhat.com> wrote: > Hello folks, > > > Please do not attempt to merge or recheck patches until we get this > sorted out. > > We are dealing with several issues that have broken all jobs. > > https://bugs.launchpad.net/tripleo/+bug/1801769 > https://bugs.launchpad.net/tripleo/+bug/1801969 > https://bugs.launchpad.net/tripleo/+bug/1802083 > https://bugs.launchpad.net/tripleo/+bug/1802085 > > Best Regards! > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer
done, you're now core in TripleO; Thanks Bob for your hard work! On Mon, Oct 22, 2018 at 4:55 PM Jason E. Rist wrote: > On 10/19/2018 06:23 AM, Juan Antonio Osorio Robles wrote: > > Hello! > > > > > > I would like to propose Bob Fournier (bfournie) as a core reviewer in > > TripleO. His patches and reviews have spanned quite a wide range in our > > project, his reviews show great insight and quality and I think he would > > be a addition to the core team. > > > > What do you folks think? > > > > > > Best Regards > > > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > yup. > > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > Freenode: jrist > github/twitter: knowncitizen > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] request for feedback/review on docker2podman upgrade
A bit of an update here: - We merged the patch in openstack/paunch that stop the Docker container if we try to start a Podman container. - We switched the undercloud upgrade job to test upgrades from Docker to Podman (for now containers are stopped in Docker and then started in Podman). - We are now looking how and where to remove the Docker containers once the upgrade finished. For that work, I started with the Undercloud and patched tripleoclient to run the post_upgrade_tasks which to me is a good candidate to run docker rm. Please look: - tripleoclient / run post_upgrade_tasks when upgrading standalone/undercloud: https://review.openstack.org/614349 - THT: prototype on how we would remove the Docker containers: https://review.openstack.org/611092 Note: for now we assume that Docker is still available on the host after the upgrade as we are testing things under centos7. I'm aware that this assumption can change in the future but we'll probably re-iterate. What I need from the upgrade team is feedback on this workflow, and see if we can re-use these bits originally tested on Undercloud / Standalone, for the Overcloud as well. Thanks for the feedback, On Fri, Oct 19, 2018 at 8:00 AM Emilien Macchi wrote: > On Fri, Oct 19, 2018 at 4:24 AM Giulio Fidente > wrote: > >> 1) create the podman systemd unit >> 2) delete the docker container >> > > We finally went with "stop the docker container" > > 3) start the podman container >> > > and 4) delete the docker container later in THT upgrade_tasks. > > And yes +1 to do the same in ceph-ansible if possible. > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][openstack-ansible][nova][placement] Owners needed for placement extraction upgrade deployment tooling
On the TripleO side, it sounds like Lee Yarwood is taking the lead with a first commit in puppet-placement: https://review.openstack.org/#/c/604182/ Lee, can you confirm that you and your team are working on it for Stein cycle? On Thu, Oct 25, 2018 at 1:34 PM Matt Riedemann wrote: > Hello OSA/TripleO people, > > A plan/checklist was put in place at the Stein PTG for extracting > placement from nova [1]. The first item in that list is done in grenade > [2], which is the devstack-based upgrade project in the integrated gate. > That should serve as a template for the necessary upgrade steps in > deployment projects. The related devstack change for extracted placement > on the master branch (Stein) is [3]. Note that change has some > dependencies. > > The second point in the plan from the PTG was getting extracted > placement upgrade tooling support in a deployment project, notably > TripleO (and/or OpenStackAnsible). > > Given the grenade change is done and passing tests, TripleO/OSA should > be able to start coding up and testing an upgrade step when going from > Rocky to Stein. My question is who can we name as an owner in either > project to start this work? Because we really need to be starting this > as soon as possible to flush out any issues before they are too late to > correct in Stein. > > So if we have volunteers or better yet potential patches that I'm just > not aware of, please speak up here so we know who to contact about > status updates and if there are any questions with the upgrade. > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html > [2] https://review.openstack.org/#/c/604454/ > [3] https://review.openstack.org/#/c/600162/ > > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer
On Fri, Oct 19, 2018 at 8:24 AM Juan Antonio Osorio Robles < jaosor...@redhat.com> wrote: > I would like to propose Bob Fournier (bfournie) as a core reviewer in > TripleO. His patches and reviews have spanned quite a wide range in our > project, his reviews show great insight and quality and I think he would > be a addition to the core team. > > What do you folks think? > Big +1, Bob is a solid contributor/reviewer. His area of knowledge has been critical in all aspects of Hardware Provisioning integration but also in other TripleO bits. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] request for feedback/review on docker2podman upgrade
On Fri, Oct 19, 2018 at 4:24 AM Giulio Fidente wrote: > 1) create the podman systemd unit > 2) delete the docker container > We finally went with "stop the docker container" 3) start the podman container > and 4) delete the docker container later in THT upgrade_tasks. And yes +1 to do the same in ceph-ansible if possible. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] request for feedback/review on docker2podman upgrade
I recently wrote a blog post about how we could upgrade an host from Docker containers to Podman containers. http://my1.fr/blog/openstack-containerization-with-podman-part-3-upgrades/ I managed to get this prototype actually tested in CI: https://review.openstack.org/#/c/608463/ http://logs.openstack.org/63/608463/10/check/tripleo-ci-centos-7-containerized-undercloud-upgrades/c958861/logs/undercloud/var/log/extra/docker/docker_allinfo.log.txt.gz http://logs.openstack.org/63/608463/10/check/tripleo-ci-centos-7-containerized-undercloud-upgrades/c958861/logs/undercloud/var/log/extra/podman/podman_allinfo.log.txt.gz Therefore, I am requesting feedback and reviews on: - openstack/paunch: rm the docker container during upgrade - https://review.openstack.org/#/c/608319/ - openstack/tripleo-upgrade: set container_cli for undercloud - https://review.openstack.org/#/c/608462/ - openstack/tripleo-quickstart: fs050: upgrade the undercloud to Podman containers - https://review.openstack.org/#/c/608463/ Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][all] meetings outside IRC
On Sat, Oct 13, 2018 at 5:30 PM Mohammed Naser wrote: > Hi everyone: > > I was going over our governance documents, more specifically this section: > > "All project meetings are held in public IRC channels and recorded." > > Does this mean that all official projects are *required* to hold their > project meetings over IRC? Is this a hard requirement or is this > something that we're a bit more 'lax about? Do members of the > community feel like it would be easier to hold their meetings if we > allowed other avenues (assuming this isn't allowed?) > > Looking forward to hearing everyone's comments. > In my opinion, IRC is the best place to run meetings in OpenStack community, however we need to acknowledge that not everyone agrees and some functional teams or sub-teams prefer some other tools, including video-conference. What remains critical to me is: - wherever you run the meeting, make it publicly reachable, accessible, visible. - if you run the meeting outside of IRC, take and share notes on public channels. In general: decisions shouldn't not be taken during meetings, but rather on Gerrit or Mailing-lists. Otherwise you're fragmenting the community between those who can attend the meeting and those who can't. My 2 cents, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][ci] Having more that one queue for gate pipeline at tripleo
On Thu, Oct 11, 2018 at 10:01 AM Felix Enrique Llorente Pastora < ellor...@redhat.com> wrote: > Hello there, > >After suffering a lot from zuul's tripleo gate piepeline queue reseting > after failures on patches I have ask myself what would happend if we have > more than one queue for gating tripleo. > >After a quick read here https://zuul-ci.org/docs/zuul/user/gating.html, > I have found the following: > > "If changes with cross-project dependencies do not share a change queue > then Zuul is unable to enqueue them together, and the first will be > required to merge before the second is enqueued." > >So it make sense to share zuul queue, but maybe only one queue for all > tripleo projects is too much, for example sharing queue between tripleo-ui > and tripleo-quickstart, maybe we need for example to queues for product > stuff and one for CI, so product does not get resetted if CI fails in a > patch. > >What do you think ? > Probably a wrong example, as TripleO UI gate is using CI jobs running tripleo-quickstart scenarios. We could create more queues for projects which are really independent from each other but we need to be very careful about it. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)
On Thu, Sep 20, 2018 at 5:47 PM Doug Hellmann wrote: > Excerpts from Jeremy Stanley's message of 2018-09-20 16:32:49 +: > > tl;dr: The openstack, openstack-dev, openstack-sigs and > > openstack-operators mailing lists (to which this is being sent) will > > be replaced by a new openstack-disc...@lists.openstack.org mailing > > list. > > Since last week there was some discussion of including the openstack-tc > mailing list among these lists to eliminate confusion caused by the fact > that the list is not configured to accept messages from all subscribers > (it's meant to be used for us to make sure TC members see meeting > announcements). > > I'm inclined to include it and either use a direct mailing or the > [tc] tag on the new discuss list to reach TC members, but I would > like to hear feedback from TC members and other interested parties > before calling that decision made. Please let me know what you think. > +2 , easier to manage, easier to reach out. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [placement]
On Mon, Sep 17, 2018 at 5:29 AM Lee Yarwood wrote: > FWIW I've also started work on the RDO packaging front [1] and would be > happy to help with this puppet extraction. > Good to know, thanks. Once we have the repo in place, here is a plan proposal: * Populate the repo with cookiecutter & adjust to Placement service * cp code from nova::placement (and nova::wsgi::apache_placement) * package placement and puppet-placement in RDO * start testing puppet-placement in puppet-openstack-integration * switch tripleo-common / THT to deploy placement in nova_placement container * switch tripleo to use puppet-placement (in THT) * probably rename nova_placement container/service into placement or something generic Feedback is welcome, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] [placement]
I'm currently taking care of creating puppet-placement: https://review.openstack.org/#/c/602870/ https://review.openstack.org/#/c/602871/ https://review.openstack.org/#/c/602869/ Once these merge, we'll use cookiecutter, and move things from puppet-nova. We'll also find a way to call puppet-placement from nova::placement class, eventually. Hopefully we can make the switch to new placement during Stein! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls
h is > already > >>>>> there. > >>>>> > >>>>> CRI-O is a socket interface and podman is a CLI interface that both > sit > >>>>> on > >>>>> top of the exact same Go libraries. At this point, switching to > podman > >>>>> needs > >>>>> a much lower development effort because we're replacing docker CLI > >>>>> calls. > >>>>> > >>>> I see good value in evaluating kubelet standalone and leveraging it's > >>>> inbuilt grpc interfaces with cri-o (rather than using podman) as a > long > >>>> term > >>>> strategy, unless we just want to provide an alternative to docker > >>>> container > >>>> runtime with cri-o. > >>> > >>> I see no value using kubelet without kubernetes IMHO. > >>> > >>> > >>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Kevin > >>>>>> > >>>>>> From: Jay Pipes [jaypi...@gmail.com] > >>>>>> Sent: Thursday, August 23, 2018 8:36 AM > >>>>>> To: openstack-dev@lists.openstack.org > >>>>>> Subject: Re: [openstack-dev] [TripleO] podman: varlink interface for > >>>>>> nice > >>>>>> API calls > >>>>>> > >>>>>> Dan, thanks for the details and answers. Appreciated. > >>>>>> > >>>>>> Best, > >>>>>> -jay > >>>>>> > >>>>>> On 08/23/2018 10:50 AM, Dan Prince wrote: > >>>>>>> > >>>>>>> On Wed, Aug 15, 2018 at 5:49 PM Jay Pipes > wrote: > >>>>>>>> > >>>>>>>> On 08/15/2018 04:01 PM, Emilien Macchi wrote: > >>>>>>>>> > >>>>>>>>> On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi < > emil...@redhat.com > >>>>>>>>> <mailto:emil...@redhat.com>> wrote: > >>>>>>>>> > >>>>>>>>>More seriously here: there is an ongoing effort to > converge > >>>>>>>>> the > >>>>>>>>>tools around containerization within Red Hat, and we, > TripleO > >>>>>>>>> are > >>>>>>>>>interested to continue the containerization of our > services > >>>>>>>>> (which > >>>>>>>>>was initially done with Docker & Docker-Distribution). > >>>>>>>>>We're looking at how these containers could be managed by > k8s > >>>>>>>>> one > >>>>>>>>>day but way before that we plan to swap out Docker and > join > >>>>>>>>> CRI-O > >>>>>>>>>efforts, which seem to be using Podman + Buildah (among > other > >>>>>>>>> things). > >>>>>>>>> > >>>>>>>>> I guess my wording wasn't the best but Alex explained way better > >>>>>>>>> here: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52 > >>>>>>>>> > >>>>>>>>> If I may have a chance to rephrase, I guess our current intention > >>>>>>>>> is > >>>>>>>>> to > >>>>>>>>> continue our containerization and investigate how we can improve > >>>>>>>>> our > >>>>>>>>> tooling to better orchestrate the containers. > >>>>>>>>> We have a nice interface (openstack/paunch) that allows us to run > >>>>>>>>> multiple container backends, and we're currently looking outside > of > >>>>>>>>> Docker to see how we could solve our current challenges with the > >>>>>>>>> new > >>>>>>>>> tools. > >>>>>>>>> We're looking at CRI-O because it happens to be a project with a > &g
[openstack-dev] [election] [tc] thank you
After 2 years at the TC, I feel lucky enough to have been part of this group where I hope that my modest contributions helped to make OpenStack a bit better. I've learnt so many things and worked with a talented group where it's not easy every day, but we have made and will continue to progress in the future. I personally feel like some rotation needs to happen, therefore I won't run the current election. I don't plan to leave or anything, I just wanted to say "merci" to the community who gave me a chance to be part of this team. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments
On Fri, Aug 31, 2018 at 4:42 AM Dmitry Tantsur wrote: > This is about a call a week before the PTG, not the PTG itself. You're > still > very welcome to join! > It's good too! Our TripleO IRC meeting is at 14 UTC. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments
On Thu, Aug 30, 2018 at 1:21 PM Julia Kreger wrote: > Greetings everyone, > > It looks like the most agreeable time on the doodle[1] seems to be > Tuesday September 4th at 13:00 UTC. Are there any objections to using > this time? > > If not, I'll go ahead and create an etherpad, and setup a bluejeans > call for that time to enable high bandwidth discussion. > TripleO sessions start on Wednesday, so +1 from us (unless I missed something). -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 29th Edition
Welcome to the twenty-ninthest edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learnwhat's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-August/133094.html General announcements = +--> This week we released Rocky RC1, branched stable/rocky and unless there are critical bugs we'll call it our final stable release. +--> The team is preparing for the next PTG: https://etherpad.openstack.org/p/tripleo-ptg-stein CI status = +--> Sprint theme: Zuul v3 migration ( https://trello.com/b/U1ITy0cu/tripleo-and-rdo-ci?menu=filter=label:Sprint%2018%20CI ) +--> The Ruck and Rover for this sprint are Marios and Wes. Please tell them any CI issue. +--> Promotion on master is 11 days, 1 day on Rocky, 3 days on Queens, 3 days on Pike and 1 days on Ocata. Upgrades = +--> Adding support for upgrades when OpenShift is deployed. Containers = +--> Efforts to support Podman tracked here: https://trello.com/b/S8TmOU0u/tripleo-podman config-download = +--> This squad is down and we move forward with the Edge squad. Edge = +--> New squad created by James: https://etherpad.openstack.org/p/tripleo-edge-squad-status (more to come) Integration = +--> No updates this week. UI/CLI = +--> No updates this week. Validations = +--> No updates this week, reviews are needed: https://etherpad.openstack.org/p/tripleo-validations-squad-status Networking = +--> Good progress on Ansible ML2 driver Workflows = +--> Planning Stein: better Ansible integration, UI convergence, etc. Security = +--> Working on SElinux for containers (related to podman integration mainly) Owl fact = "One single Owl can go fast. Multiple owls, together, can go far." Source: a mix of an African proverb and my Friday-afternoon imagination. Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Rocky RC1 released!
We just released Rocky RC1 and branched stable/rocky for most of tripleo repos, please let us know if we missed something. Please don't forget to backport the patches that land in master and that you want in Rocky. We're currently investigating if we whether or not we'll need an RC2 so don't be surprised if Launchpad bugs are moved around during the next days. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
If I would be a standalone consummer of OpenStack Placement (e.g. I only run cinder or ironic to manage volume / baremetal), and I had to run something like: $ pip install -U placement I would prefer "placement" to be a project driven by diverse people interested by Infrastructure resources placement and not just nova. In other words, I would be afraid of seeing this project owned by the nova team since the scope of placement seems to go beyond compute. Instead I would be at ease to see a separated PTL and core team, who closely work with OpenStack projects consuming placement service. People writting placement's code would *own* this project, and decide of their future. They would serve projects like nova, cinder, maybe ironic one day, etc. By making this team more independent, I believe they could build trust in our community, which is something we desperately need nowadays and have been encouraging over the last years. I have an high level of confidence that this new team would be smart enough to collaborate when it comes to code design decisions, no matter what happened in the past. Let's reset a little bit and give these people a chance here. Let's create this independent team. I believe we could even write down a (short) vision for placement, and a (short) mission statement, then we can set expectations for the near future. On Tue, Aug 21, 2018 at 8:55 AM Thierry Carrez wrote: > Matt Riedemann wrote: > > [...] > > Regarding microversions I was mostly thinking of the various times I've > > been asked in the placement channel if something warrants a microversion > > or if we can just bug fix it in, like microversion 1.26. I then > > generally feel like I need to be defensive when I say, "yes it's a > > behavior change in the API so it should." That makes me question how > > stringent others would be about upholding interoperability concerns if I > > weren't around. [...] > > The issue with that kind of distrust by default is that it's not > sustainable... In a large project you can't have every individual review > everything because they trust noone else. > > That is why in OpenStack we instituted a culture of "trust by default, > then escalate to PTL or TC if shit ever hits the fan". And the fact is, > the PTL (at team level) or the TC (between teams) rarely had to > arbitrate conflicts, because there aren't so many conflicts that are > escalated rather than solved by consensus at the lower level. > > Restoring "trust by default" between placement and the rest of Nova > seems to be the root of the problem here. In a community, it's generally > done by documenting general expectations and shared understandings, so > that you create a common culture and trust by default people to apply it. > > What would you suggest we do to improve that in this specific case? > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls
On Wed, Aug 15, 2018 at 5:31 PM Emilien Macchi wrote: > More seriously here: there is an ongoing effort to converge the tools > around containerization within Red Hat, and we, TripleO are interested to > continue the containerization of our services (which was initially done > with Docker & Docker-Distribution). > We're looking at how these containers could be managed by k8s one day but > way before that we plan to swap out Docker and join CRI-O efforts, which > seem to be using Podman + Buildah (among other things). > I guess my wording wasn't the best but Alex explained way better here: http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-15.log.html#t2018-08-15T17:56:52 If I may have a chance to rephrase, I guess our current intention is to continue our containerization and investigate how we can improve our tooling to better orchestrate the containers. We have a nice interface (openstack/paunch) that allows us to run multiple container backends, and we're currently looking outside of Docker to see how we could solve our current challenges with the new tools. We're looking at CRI-O because it happens to be a project with a great community, focusing on some problems that we, TripleO have been facing since we containerized our services. We're doing all of this in the open, so feel free to ask any question. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] podman: varlink interface for nice API calls
Hi Jay, On Wed, Aug 15, 2018 at 3:59 PM Jay Pipes wrote: > This was news to me. Is this just a triple-o thing? > It's in the newspapers! https://www.serverwatch.com/server-news/red-hat-looks-beyond-docker-for-container-technology.html More seriously here: there is an ongoing effort to converge the tools around containerization within Red Hat, and we, TripleO are interested to continue the containerization of our services (which was initially done with Docker & Docker-Distribution). We're looking at how these containers could be managed by k8s one day but way before that we plan to swap out Docker and join CRI-O efforts, which seem to be using Podman + Buildah (among other things). The work done at this time (so far) is pure investigation, but feedback is always welcome. We're tracking our efforts here: https://etherpad.openstack.org/p/tripleo-podman Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] migrating to storyboard
On Tue, Aug 14, 2018 at 6:33 PM Tobias Urdin wrote: > Please let me know what you think about moving to Storyboard? > Go for it. AFIK we don't have specific blockers to make that migration happening. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 28th Edition
Welcome to the twenty-eightiest edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132672.html +-+ | General announcements | +-+ +--> We're still preparing the first release candidate of TripleO Rocky, please focus on Critical / High bugs. +--> Reminder about PTG etherpad, feel free to propose topics: https://etherpad.openstack.org/p/tripleo-ptg-stein +--> Juan will be the next PTL for Stein cycle, congratulations! +--+ | Continuous Integration | +--+ +--> Sprint theme: migration to zuul v3, including migrating from legacy bash to ansible tasks/playbooks (More on https://trello.com/c/JikmHXSS/881-sprint-17-goals) +--> The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Rafael Folco (rfolco). Please tell them any CI issue. +--> Promotion on master is 2 days, 9 day on Queens, 0 days on Pike and 7 days on Ocata. +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> No updates this week. <https://review.openstack.org/#/q/status:open+branch:master+topic:external-update-upgrade> +---+ | Containers | +---+ +--> The team is looking at podman/buildah support for Stein cycle. More discussions at the PTG, but doing some ground work now. +--+ | config-download | +--+ +--> No updates this week.. +--+ | Integration | +--+ +--> No updates this week. +-+ | UI/CLI | +-+ +--> No updates this week. +---+ | Validations | +---+ +--> No updates this week. +---+ | Networking | +---+ +--> No updates this week. +--+ | Workflows | +--+ +--> Progress on the Mistral tempest plugin and testing on the containerized undercloud job. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Discussion around secret management. +--> Last meeting notes: http://eavesdrop.openstack.org/meetings/tripleo_security_squad/2018/tripleo_security_squad.2018-08-08-12.03.log.html <http://eavesdrop.openstack.org/meetings/security_squad/2018/security_squad.2018-07-18-12.07.html> +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owl Wings Are Helping Silence Airplanes, Fans, and Wind Turbines Nice reading: https://gizmodo.com/owl-wings-are-helping-silence-airplanes-fans-and-wind-1713023055 Thanks Cédric for this contribution! Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships
Thanks Victoria for all your efforts, highly recognized! --- Emilien Macchi On Tue, Aug 7, 2018, 7:48 PM Victoria Martínez de la Cruz, < victo...@vmartinezdelacruz.com> wrote: > Hi all, > > I'm reaching you out to let you know that I'll be stepping down as > coordinator for OpenStack next round. I had been contributing to this > effort for several rounds now and I believe is a good moment for somebody > else to take the lead. You all know how important is Outreachy to me and > I'm grateful for all the amazing things I've done as part of the Outreachy > program and all the great people I've met in the way. I plan to keep > involved with the internships but leave the coordination tasks to somebody > else. > > If you are interested in becoming an Outreachy coordinator, let me know > and I can share my experience and provide some guidance. > > Thanks, > > Victoria > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships
--- Emilien Macchi On Wed, Aug 8, 2018, 5:14 AM Thierry Carrez, wrote: > Victoria Martínez de la Cruz wrote: > > I'm reaching you out to let you know that I'll be stepping down as > > coordinator for OpenStack next round. I had been contributing to this > > effort for several rounds now and I believe is a good moment for > > somebody else to take the lead. You all know how important is Outreachy > > to me and I'm grateful for all the amazing things I've done as part of > > the Outreachy program and all the great people I've met in the way. I > > plan to keep involved with the internships but leave the coordination > > tasks to somebody else. > > Thanks for helping with this effort for all this time ! > > -- > Thierry Carrez (ttx) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO
On Wed, Aug 1, 2018 at 7:33 AM Giulio Fidente wrote: > I would like to propose Lukas Bezdicka core on TripleO. > Thanks Giulio for proposing him. I agree Lukas's technical level has been quite impactful in the Fast-Forward-Upgrades effort, and upgrades in general. Also his strong experience with TripleO testing over the last years will make him a great core reviewer, careful to not break upgrades and maintain code consistency across the project. Thanks Lukas for your efforts, keep going! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 27th Edition
Welcome to the twenty-seventh edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132448.html +-+ | General announcements | +-+ +--> We're preparing the first release candidate of TripleO Rocky, please focus on Critical / High bugs. +--> Reminder about PTG etherpad, feel free to propose topics: https://etherpad.openstack.org/p/tripleo-ptg-stein +--+ | Continuous Integration | +--+ +--> Sprint theme: migration to zuul v3, including migrating from legacy bash to ansible tasks/playbooks (More on https://trello.com/c/JikmHXSS/881-sprint-17-goals) +--> The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Rafael Folco (rfolco). Please tell them any CI issue. +--> Promotion on master is 11 days, 0 day on Queens, 3 days on Pike and 4 days on Ocata. +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Need review on work for updates/upgrades with external installers: https://review.openstack.org/#/q/status:open+branch:master+topic:external-update-upgrade +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> No major update this week, in bug fixing mode. +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> No updates this week.. +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squad-status +--+ | Integration | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> config-download support work is landed! +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> Need review on custom validations support. +--> Efforts around Mistral workflow lookup plugin +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> Policy based routing for os-net-config +--> Patches for Neutron routed networks support using segments for TripleO +--> Ansible ML2 driver: good progress on patches and testing. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> No updates this week. +--> Last meeting notes: http://eavesdrop.openstack.org/meetings/security_squad/2018/security_squad.2018-07-18-12.07.html +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owls have far-sighted, tubular eyes: instead of spherical eyeballs, owls have "eye tubes" that go far back into their skulls - which means their eyes are fixed in place, so they have to turn their heads to see. The size of their eyes helps them see in the dark, and they're far-sighted, which allows them to spot prey from yards away. Up close, everything is blurry, and they depend on small, hair-like feathers on their beaks and feet to feel their food. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Rocky Ceph update/upgrade regression risk (semi-FFE)
On Fri, Jul 27, 2018 at 3:58 AM Jiří Stránský wrote: > I'd call this a semi-FFE, as a few of the patches have characteristics of > feature work, > but at the same time i don't believe we can afford having Ceph > unupgradable in Rocky, so it has characteristics of a regression bug > too. I reported a bug [2] and tagged the patches in case we end up > having to do backports. > Right, let's consider it as a bug and not a feature. Also, it's upgrade related so it's top-priority as we did in prior cycles. Therefore I think it's fine. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Rocky milestone 3 was released!
Kudos to the team, we just release our third Rocky milestone! As usual, I prepared some numbers so you can see our project health: https://docs.google.com/presentation/d/1RV30OVxmXv1y_z33LuXMVB56TA54Urp7oHIoTNwrtzA/edit#slide=id.p Some comments: 1) More bugs were fixed in rocky milestone 3 than before. 2) Milestone 2 and Milestone 2 delivered the same amount of blueprints. 3) Our list of core reviewers keep growing! 4) Commits and LOC are much higher than Queens. Now the focus should be on stabilization and bug fixing, we are in release candidate mode which means no more features unless you have FFE granted. Thanks everyone for this hard work! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On Thu, Jul 26, 2018 at 12:30 PM John Fulton wrote: > Do we have a plan for which Ansible version might be the default in > upcoming TripleO versions? > > If this is the thread to discuss it then, I want to point out that > TripleO's been using ceph-ansible for Ceph integration on the client > and server side since Pike and that ceph-ansible 3.1 (which TripleO > master currently uses) fails on Ansible 2.6 and that this won't be > addressed until ceph-ansible 3.2. > I think the last thing we want is to break TripleO + Ceph integration so we will maintain Ansible 2.5.x in TripleO Rocky and upgrade to 2.6.x in Stein when ceph-ansible 3.2 is used and working well. Hope it's fine for everyone, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 26th Edition
Welcome to the twenty-sixth edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-July/132301.html +-+ | General announcements | +-+ +--> Rocky Milestone 3 is this week. The team should focus on stabilization, bug fixing, testing, so we can make our rocky release more awesome. +--> Reminder about PTG etherpad, feel free to propose topics: https://etherpad.openstack.org/p/tripleo-ptg-stein +--> PTL elections are open! If you want to be the next TripleO PTL, it's the right time to send your candidacy *now* ! +--+ | Continuous Integration | +--+ +--> Sprint theme: migration to Zuul v3 (More on https://trello.com/c/vyWXcKOB/841-sprint-16-goals) +--> Sagi is the rover and Chandan is the ruck. Please tell them any CI issue. +--> Promotion on master is 4 days, 0 days on Queens, 2 days on Pike and 0 day on Ocata. +--> RDO Third Party jobs are currently down: https://tree.taiga.io/project/morucci-software-factory/issue/1560 +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Progress on work for updates/upgrades with external installers: https://review.openstack.org/#/q/status:open+branch:master+topic:external-update-upgrade +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Lot of testing around containerized undercloud, please let us know any problem. +--> Image prepare via workflow is still work in progress. +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> UI integration needs review. +--> Bug with failure listing is in progress: https://bugs.launchpad.net/tripleo/+bug/1779093 +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squad-status +--+ | Integration | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Major Network Configuration patches landed! Congrats team! +--> Config-download patches are being reviewed and a lot of testing is going on. +--> The team is working on a Tempest Plugin for TripleO UI: https://review.openstack.org/#/c/575730/ +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Working on Secrets management. +--> Last meeting notes: http://eavesdrop.openstack.org/meetings/security_squad/2018/security_squad.2018-07-18-12.07.html +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owls feed the strongest babies first. As harsh as it sounds, the parents always feed the oldest and strongest owlet before its sibling. This means that if food is scarce, the youngest chicks will starve. After an owlet leaves the nest, it often lives nearby in the same tree, and its parents still bring it food. If it can survive the first winter on its own, its chances of survival are good. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
Thanks Monty for pointing that out to me today on #ansible-devel. Context: https://github.com/ansible/ansible/pull/41811 The top-level fact vars are currently being deprecated in Ansible, maybe 2.7. It looks like it only affects tripleo-validations (in a quick look), but it could be more. See: http://codesearch.openstack.org/?q=ansible_facts=nope== An example playbook was written to explain what is deprecated: https://github.com/ansible/ansible/pull/41811#issuecomment-399220997 But it seems like, starting with Ansible 2.5 (what we already have in Rocky and beyond), we should encourage the usage of ansible_facts dictionary. Example: var=hostvars[inventory_hostname].ansible_facts.hostname instead of: var=ansible_hostname Can we have someone from TripleO Validations to help, and make sure we make it working for future versions of Ansible. Also there is a way to test this behavior by disabling the 'inject_facts_as_vars' option in ansible.cfg. Hope this helps, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec wrote: > Okay, based on a private conversation this is coming off as way more > troll-ish than I intended. I don't understand where this work is going, > but I don't really need to so I'll step back from the discussion. > Apologies for any offense. > No offense here, Ben. In fact I hope we can still continue to have a productive discussion here. I'm speaking on my own view now, and I'm happy to be wrong and learn but I wanted to explore how far we can bring the work around standalone architecture. If it was worth exploring making it "multi-node" somehow, what would be our technical challenges and more than anything else: what use-case we would enable. I'm actually quite happy to see that people already looked at some of these challenges before (see what Giulio / James / Steve H. already worked on), so I guess it makes sense to continue the investigation. We are not making any decision right now in what API we plan to use. The current production architecture is still undercloud + overcloud, and our day 2 operations are done by Mistral/Heat for now but as we transition more to Ansible I think we wanted to explore more options. I hope this little background helped. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
On Fri, Jul 20, 2018 at 7:43 AM Emilien Macchi wrote: > On Fri, Jul 20, 2018 at 7:09 AM Emilien Macchi wrote: > >> Yeah I thought about this one too but I didn't have this challenge since >> I just wanted nova-compute & neutron-ovs-agent running on the edge. >> > > Actually I just faced it: > Error: Failed to perform requested operation on instance "my-vm", the > instance has an error status: Please try again later [Error: Host > 'standalone-cpu-edge.localdomain' is not mapped to any cell]. > > I had to manually add the edge compute on the central node, so yeah we > need to figure that out for the compute as well (unless I missed something > in the nova config). > Nevermind, I had to set NovaSchedulerDiscoverHostsInCellsInterval to 300, so nova-schedule checks for new compute nodes every 300s and include them in the cell. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
On Fri, Jul 20, 2018 at 7:09 AM Emilien Macchi wrote: > Yeah I thought about this one too but I didn't have this challenge since I > just wanted nova-compute & neutron-ovs-agent running on the edge. > Actually I just faced it: Error: Failed to perform requested operation on instance "my-vm", the instance has an error status: Please try again later [Error: Host 'standalone-cpu-edge.localdomain' is not mapped to any cell]. I had to manually add the edge compute on the central node, so yeah we need to figure that out for the compute as well (unless I missed something in the nova config). -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
On Fri, Jul 20, 2018 at 4:20 AM Giulio Fidente wrote: [...] > I have started experimenting with edge deployments to help out on the > split-controplane spec [1], which Steven started addressing > > I was able to deploy multiple stacks and isolated Ceph clusters, there > are some bits missing to provision a working configuration for > nova-compute to the edge services, but we could probably collect/export > the necessary outputs from the parent stack (eg. rabbit connection > infos) and feed the edge stacks with those. > Indeed, I faced the exact same problems. I could hardcode the rabbit password and memcache IP via hieradata extraconfig, James showed me AllNodesExtraMapData done via https://review.openstack.org/#/c/581080/ which I'll probably give a try. However I couldn't set keystone url for nova / neutron (they are taken from ServiceNetMap). James pointed out to me this patch: https://review.openstack.org/#/c/521929/ - Do you think we should re-use the service net map from the central node, on the edge compute node? A much bigger challenge seems to me that for some services (eg. glance > or cinder) we need to "refresh" the configuration of the controlplane > nodes to push the details of the newly deployed ceph clusters (backends) > of the edge nodes as backends for the controlplane services. > Yeah I thought about this one too but I didn't have this challenge since I just wanted nova-compute & neutron-ovs-agent running on the edge. Alternatively, we could opt for the deployment of cinder-volume > instances on the edge nodes, but we would still have the same problem > for glance and possibly other services. > For now the only thing I see is to manually update the config on the central node and run the deployment again, which should reconfigure the containers. I'd like to discuss further this topic at the PTG to gether more > feedback so I added a bullet to the pad with the Stein PTG topics [2]. It would be awesome to spend time on this topic! Thanks for bringing this blueprint up! Indeed I hope we'll make progress on this one at the PTG, which is why I sent this email really early to groom some ideas. > 1. https://blueprints.launchpad.net/tripleo/+spec/split-controlplane > 2. https://etherpad.openstack.org/p/tripleo-ptg-stein Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Jose Luis Franco for TripleO core reviewer on Upgrade bits
On Fri, Jul 20, 2018 at 4:09 AM Carlos Camacho Gonzalez wrote: > Hi!!! > > I'll like to propose Jose Luis Franco [1][2] for core reviewer in all the > TripleO upgrades bits. He shows a constant and active involvement in > improving and fixing our updates/upgrades workflows, he helps also trying > to develop/improve/fix our upstream support for testing the > updates/upgrades. > > Please vote -1/+1, and consider this my +1 vote :) > Nice work indeed, +1. Keep doing a good job and thanks for all your help! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes
Today I played a little bit with Standalone deployment [1] to deploy a single OpenStack cloud without the need of an undercloud and overcloud. The use-case I am testing is the following: "As an operator, I want to deploy a single node OpenStack, that I can extend with remote compute nodes on the edge when needed." We still have a bunch of things to figure out so it works out of the box, but so far I was able to build something that worked, and I found useful to share it early to gather some feedback: https://gitlab.com/emacchi/tripleo-standalone-edge Keep in mind this is a proof of concept, based on upstream documentation and re-using 100% what is in TripleO today. The only thing I'm doing is to change the environment and the roles for the remote compute node. I plan to work on cleaning the manual steps that I had to do to make it working, like hardcoding some hiera parameters and figure out how to override ServiceNetmap. Anyway, feel free to test / ask questions / provide feedback. Thanks, [1] https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.html -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
On Thu, Jul 19, 2018 at 6:02 AM Raoul Scarazzini wrote: [...] > Small question aside related to all-in-one: we're talking about use > cases in which we might want to go from 1 to 3 controllers, but how this > can become a thing? I always thought to all-in-one as a developer/ci > "tool", so why we should care about giving the possibility to expand? > We have a few other use-cases but 2 of them are: - PoC deployed on the field, start with one controller, scale up to 3 controllers (with compute services deployed as well). - Edge Computing, where we could think of a controller being scaled-out as well, or a remote compute note being added, with VMs in HA with pacemaker. But I agree that the first target for now is to fulfil the developer use case, and PoC use case (on one node). This question is related also to the main topic of this thread: it was > proposed to replace Keepalived with anything (instead of Pacemaker), and > one of the outcomes was that this approach would not guarantee some of > the goals, like undercloud HA and keeping 1:1 structure between > undercloud and overcloud. But what else are we supposed to control with > Pacemaker on the undercloud apart from the IPs? > Nothing, AFIK. The VIPs were the only things we wanted to managed on a single-node undercloud. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] EOL process for newton branches
Option 2, EOL everything. Thanks a lot for your help on this one, Tony. --- Emilien Macchi On Wed, Jul 18, 2018, 7:47 PM Tony Breeds, wrote: > > Hi All, > As of I3671f10d5a2fef0e91510a40835de962637f16e5 we have meta-data in > openstack/releases that tells us that the following repos are at > newton-eol: > - openstack/instack-undercloud > - openstack/os-net-config > - openstack/puppet-tripleo > - openstack/tripleo-common > - openstack/tripleo-heat-templates > > I was setting up the request to create the tags and delete those > branches but I noticed that the following repos have newton branches and > are not in the list above: > > - openstack/instack > - openstack/os-apply-config > - openstack/os-collect-config > - openstack/os-refresh-config > - openstack/python-tripleoclient > - openstack/tripleo-image-elements > - openstack/tripleo-puppet-elements > - openstack/tripleo-ui > - openstack/tripleo-validations > > So I guess there are a couple of options here: > > 1) Just EOL the 5 repos that opensatck/releases knows are at EOL > 2) EOL the repos from both lists ad update openstack/releases to flag >them as such > > I feel like option 2 is the correct option but perhaps there is a reason > those repos where not tagged and released > > > Yours Tony. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
ire to use the same architecture as the > Overcloud (Pacemaker). And there is some competition between them. > > For simplification: If we can eliminate keepalived and still use > HAProxy (thus keeping the SSL termination features working) then I > think that would be worth trying. Specifically can we eliminate > Keepalived without swapping in Pacemaker? Michele: if you have ideas > here lets try them! > > With regards to Pacemaker I think we need to make an exception. It > seems way too heavy for single node setups and increases the complexity > there for very little benefit. To me the shared architecture for > TripleO is the tools we use to setup services. By using t-h-t to drive > our setup of the Undercloud and All-In-One installers we are already > gaining a lot of benefit here. Pacemaker is weird as it is kind of > augments the architecture a bit (HA architecture). But Pacemaker is > also a service that gets configured by TripleO. So it kind of falls > into both categories. Pacemaker gives us features we need in the > Overcloud at the cost of some extra complexity. And in addition to all > this we are still running the Pacemaker processes themselves on > baremetal. All this just to say we are running the same "architecture" > on both the Undercloud and Overcloud? I'm not a fan. > > Dan > > > > > > > > D) Undercloud HA is a nice have which I think we want to get to one > > > day, but it is not in as big demand as for example edge > > > deployments, > > > BM provisioning with pure OS, or multiple envs managed by single > > > undercloud. So even though undercloud HA is important, it won’t > > > bring > > > operators as many benefits as the previously mentioned > > > improvements. > > > Let’s keep it in mind when we are considering the amount of work > > > needed for it. > > > > +100 > > > > > E) One of the use-cases we want to take into account is expanind a > > > single-node deployment (all-in-one) to 3 node HA controller. I > > > think > > > it is important when evaluating PCMK/keepalived > > > > Right, so to be able to implement this, there is no way around having > > pacemaker (at least today until we have galera and rabbit). > > It still does not mean we have to default to it, but if you want to > > scale beyond one node, then there is no other option atm. > > > > > HTH > > > > It did, thanks! > > > > Michele > > > — Jarda > > > > > > > On Jul 17, 2018, at 05:04, Emilien Macchi > > > > wrote: > > > > > > > > Thanks everyone for the feedback, I've made a quick PoC: > > > > https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-de > > > > fault > > > > > > > > And I'm currently doing local testing. I'll publish results when > > > > progress is made, but I've made it so we have the choice to > > > > enable pacemaker (disabled by default), where keepalived would > > > > remain the default for now. > > > > > > > > On Mon, Jul 16, 2018 at 2:07 PM Michele Baldessari > > > n.org> wrote: > > > > On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote: > > > > > On Mon, Jul 16, 2018 at 11:42 AM Dan Prince > > > > > wrote: > > > > > [...] > > > > > > > > > > > The biggest downside IMO is the fact that our Pacemaker > > > > > > integration is > > > > > > not containerized. Nor are there any plans to finish the > > > > > > containerization of it. Pacemaker has to currently run on > > > > > > baremetal > > > > > > and this makes the installation of it for small dev/test > > > > > > setups a lot > > > > > > less desirable. It can launch containers just fine but the > > > > > > pacemaker > > > > > > installation itself is what concerns me for the long term. > > > > > > > > > > > > Until we have plans for containizing it I suppose I would > > > > > > rather see > > > > > > us keep keepalived as an option for these smaller setups. We > > > > > > can > > > > > > certainly change our default Undercloud to use Pacemaker (if > > > > > > we choose > > > > > > to do so). But having keepalived around for "lightweight" > > > > > > (zero or low > > > > > > footprint) installs that wo
[openstack-dev] [tripleo] The Weekly Owl - 25th Edition
Your fellow reporter took a break from writing, but is now back on his pen. Welcome to the twenty-fifth edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131426.html +-+ | General announcements | +-+ +--> Rocky Milestone 3 is next week. After, any feature code will require Feature Freeze Exception (FFE), asked on the mailing-list. We'll enter a bug-fix only and stabilization period, until we can push the first stable version of Rocky. +--> Next PTG will be in Denver, please propose topics: https://etherpad.openstack.org/p/tripleoci-ptg-stein +--> Multiple squads are currently brainstorming a framework to provide validations pre/post upgrades - stay in touch! +--+ | Continuous Integration | +--+ +--> Sprint theme: migration to Zuul v3 (More on https://trello.com/c/vyWXcKOB/841-sprint-16-goals) +--> Sagi is the rover and Chandan is the ruck. Please tell them any CI issue. +--> Promotion on master is 4 days, 0 days on Queens and Pike and 1 day on Ocata. +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Good progress on major upgrades workflow, need reviews! +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> We switched python-tripleoclient to deploy containerized undercloud by default! +--> Image prepare via workflow is still work in progress. +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> UI integration is almost done (need review) +--> Bug with failure listing is being fixed: https://bugs.launchpad.net/tripleo/+bug/1779093 +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squad-status +--+ | Integration | +--+ +--> We're enabling decoupled deployment plans e.g for OpenShift, DPDK etc: https://review.openstack.org/#/q/topic:alternate_plans+(status:open+OR+status:merged) (need reviews). +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Good progress on network configuration via UI +--> Config-download patches are being reviewed and a lot of testing is going on. +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> Working on OpenShift validations, need reviews. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Working on Secrets management and Limit TripleO users efforts +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Elf owls live in a cacti. They are the smallest owls, and live in the southwestern United States and Mexico. It will sometimes make its home in the giant saguaro cactus, nesting in holes made by other animals. However, the elf owl isn’t picky and will also live in trees or on telephone poles. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
Thanks everyone for the feedback, I've made a quick PoC: https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-default And I'm currently doing local testing. I'll publish results when progress is made, but I've made it so we have the choice to enable pacemaker (disabled by default), where keepalived would remain the default for now. On Mon, Jul 16, 2018 at 2:07 PM Michele Baldessari wrote: > On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote: > > On Mon, Jul 16, 2018 at 11:42 AM Dan Prince wrote: > > [...] > > > > > The biggest downside IMO is the fact that our Pacemaker integration is > > > not containerized. Nor are there any plans to finish the > > > containerization of it. Pacemaker has to currently run on baremetal > > > and this makes the installation of it for small dev/test setups a lot > > > less desirable. It can launch containers just fine but the pacemaker > > > installation itself is what concerns me for the long term. > > > > > > Until we have plans for containizing it I suppose I would rather see > > > us keep keepalived as an option for these smaller setups. We can > > > certainly change our default Undercloud to use Pacemaker (if we choose > > > to do so). But having keepalived around for "lightweight" (zero or low > > > footprint) installs that work is really quite desirable. > > > > > > > That's a good point, and I agree with your proposal. > > Michele, what's the long term plan regarding containerized pacemaker? > > Well, we kind of started evaluating it (there was definitely not enough > time around pike/queens as we were busy landing the bundles code), then > due to discussions around k8s it kind of got off our radar. We can > at least resume the discussions around it and see how much effort it > would be. I'll bring it up with my team and get back to you. > > cheers, > Michele > -- > Michele Baldessari > C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
On Mon, Jul 16, 2018 at 11:42 AM Dan Prince wrote: [...] > The biggest downside IMO is the fact that our Pacemaker integration is > not containerized. Nor are there any plans to finish the > containerization of it. Pacemaker has to currently run on baremetal > and this makes the installation of it for small dev/test setups a lot > less desirable. It can launch containers just fine but the pacemaker > installation itself is what concerns me for the long term. > > Until we have plans for containizing it I suppose I would rather see > us keep keepalived as an option for these smaller setups. We can > certainly change our default Undercloud to use Pacemaker (if we choose > to do so). But having keepalived around for "lightweight" (zero or low > footprint) installs that work is really quite desirable. > That's a good point, and I agree with your proposal. Michele, what's the long term plan regarding containerized pacemaker? -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Plan to switch the undercloud to be containerized by default
On Tue, Jul 10, 2018, 7:57 PM Emilien Macchi, wrote: > with [tripleo] tag... > > On Tue, Jul 10, 2018 at 7:56 PM Emilien Macchi wrote: > >> This is an update on where things are regarding $topic, based on feedback >> I've got from the work done recently: >> >> 1) Switch --use-heat to take a boolean and deprecate it >> >> We still want to allow users to deploy non containerized underclouds, so >> we made this patch so they can use --use-heat=False: >> https://review.openstack.org/#/c/581467/ >> Also https://review.openstack.org/#/c/581468 and >> https://review.openstack.org/581180 as dependencies >> >> 2) Configure CI jobs for containerized undercloud, except scenario001, >> 002 for timeout reasons (and figure out this problem in a parallel effort) >> >> https://review.openstack.org/#/c/575330 >> https://review.openstack.org/#/c/579755 >> >> 3) Switch tripleoclient to deploy by default a containerized undercloud >> >> https://review.openstack.org/576218 >> > It merged today, hopefully all CI jobs (including promotion) will continue to run smoothly. Thanks everyone involved in this big effort! >> 4) Improve performances in general so scenario001/002 doesn't timeout >> when containerized undercloud is enabled >> >> https://review.openstack.org/#/c/581183 is the patch that'll enable the >> containerized undercloud >> https://review.openstack.org/#/c/577889/ is a patch that enables >> pipelining in ansible/quickstart, but more is about to come, I'll update >> the patches tonight. >> > These scenarios are still on the edge of a timeout, we'll keep working on those. >> 5) Cleanup quickstart to stop using use-heat except for fs003 (needed to >> disable containers, and keep coverage for non containerized undercloud) >> >> https://review.openstack.org/#/c/581534/ >> >> >> Reviews are welcome, we aim to merge this work by milestone 3, in less >> than 2 weeks from now. >> > Since we merged the majority of the work, I think we can close the blueprint and not require FFE. Any feedback on that statement is welcome. Thanks, Emilien > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
Greetings, We have been supporting both Keepalived and Pacemaker to handle VIP management. Keepalived is actually the tool used by the undercloud when SSL is enabled (for SSL termination). While Pacemaker is used on the overcloud to handle VIPs but also services HA. I see some benefits at removing support for keepalived and deploying Pacemaker by default: - pacemaker can be deployed on one node (we actually do it in CI), so can be deployed on the undercloud to handle VIPs and manage HA as well. - it'll allow to extend undercloud & standalone use cases to support multinode one day, with HA and SSL, like we already have on the overcloud. - it removes the complexity of managing two tools so we'll potentially removing code in TripleO. - of course since pacemaker features from overcloud would be usable in standalone environment, but also on the undercloud. There is probably some downside, the first one is I think Keepalived is much more lightweight than Pacemaker, we probably need to run some benchmark here and make sure we don't make the undercloud heavier than it is now. I went ahead and created this blueprint for Stein: https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default I also plan to prototype some basic code soon and provide an upgrade path if we accept this blueprint. This is something I would like to discuss here and at the PTG, feel free to bring questions/concerns, Thanks! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Rocky blueprints
On Thu, Jul 12, 2018 at 11:07 AM Bogdan Dobrelya wrote: [...] > > - > https://blueprints.launchpad.net/tripleo/+spec/containerized-undercloud > > This needs FFE please. [...] No i don't think we need FFE for containerized undercloud. Most of the code has merged and we're switching the default in tripleoclient as of today if the patches merge (in gate today probably). So we're good on this one. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Updates/upgrades equivalent for external_deploy_tasks
On Tue, Jul 10, 2018 at 10:22 AM Jiří Stránský wrote: > Hi, > > with the move to config-download deployments, we'll be moving from > executing external installers (like ceph-ansible) via Heat resources > encapsulating Mistral workflows towards executing them via Ansible > directly (nested Ansible process via external_deploy_tasks). > > Updates and upgrades still need to be addressed here. I think we should > introduce external_update_tasks and external_upgrade_tasks for this > purpose, but i see two options how to construct the workflow with them. > > During update (mentioning just updates, but upgrades would be done > analogously) we could either: > > A) Run external_update_tasks, then external_deploy_tasks. > > This works with the assumption that updates are done very similarly to > deployment. The external_update_tasks could do some prep work and/or > export Ansible variables which then could affect what > external_deploy_tasks do (e.g. in case of ceph-ansible we'd probably > override the playbook path). This way we could also disable specific > parts of external_deploy_tasks on update, in case reuse is undesirable > in some places. > > B) Run only external_update_tasks. > > This would mean code for updates/upgrades of externally deployed > services would be completely separated from how their deployment is > done. If we wanted to reuse some of the deployment tasks, we'd have to > use the YAML anchor referencing mechanisms. (, *anchor) > > I think the options are comparable in terms of what is possible to > implement with them, the main difference is what use cases we want to > optimize for. > > Looking at what we currently have in external_deploy_tasks (e.g. > [1][2]), i think we'd have to do a lot of explicit reuse if we went with > B (inventory and variables generation, ...). So i'm leaning towards > option A (WIP patch at [3]) which should give us this reuse more > naturally. This approach would also be more in line with how we already > do normal updates and upgrades (also reusing deployment tasks). Please > let me know in case you have any concerns about such approach (looking > especially at Ceph and OpenShift integrators :) ). > +1 for Option A as well, I feel like it's the one which would give us the more of flexibility and also I'm not a big fan of the usage of Anchors for this use case. Some folks are currently working on extracting these tasks out of THT and I can already see something like: external_deploy_tasks - include_role: name: my-service tasks_from: deploy external_update_tasks - include_role: name: my-service tasks_from: update Or we could re-use the same playbooks, but use tags maybe. Anyway, I like your proposal and I vote for option A. > Thanks > > Jirka > > [1] > > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/docker/services/ceph-ansible/ceph-base.yaml#L340-L467 > [2] > > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/extraconfig/services/openshift-master.yaml#L70-L231 > [3] https://review.openstack.org/#/c/579170/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Plan to switch the undercloud to be containerized by default
with [tripleo] tag... On Tue, Jul 10, 2018 at 7:56 PM Emilien Macchi wrote: > This is an update on where things are regarding $topic, based on feedback > I've got from the work done recently: > > 1) Switch --use-heat to take a boolean and deprecate it > > We still want to allow users to deploy non containerized underclouds, so > we made this patch so they can use --use-heat=False: > https://review.openstack.org/#/c/581467/ > Also https://review.openstack.org/#/c/581468 and > https://review.openstack.org/581180 as dependencies > > 2) Configure CI jobs for containerized undercloud, except scenario001, 002 > for timeout reasons (and figure out this problem in a parallel effort) > > https://review.openstack.org/#/c/575330 > https://review.openstack.org/#/c/579755 > > 3) Switch tripleoclient to deploy by default a containerized undercloud > > https://review.openstack.org/576218 > > 4) Improve performances in general so scenario001/002 doesn't timeout when > containerized undercloud is enabled > > https://review.openstack.org/#/c/581183 is the patch that'll enable the > containerized undercloud > https://review.openstack.org/#/c/577889/ is a patch that enables > pipelining in ansible/quickstart, but more is about to come, I'll update > the patches tonight. > > 5) Cleanup quickstart to stop using use-heat except for fs003 (needed to > disable containers, and keep coverage for non containerized undercloud) > > https://review.openstack.org/#/c/581534/ > > > Reviews are welcome, we aim to merge this work by milestone 3, in less > than 2 weeks from now. > Thanks! > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Plan to switch the undercloud to be containerized by default
This is an update on where things are regarding $topic, based on feedback I've got from the work done recently: 1) Switch --use-heat to take a boolean and deprecate it We still want to allow users to deploy non containerized underclouds, so we made this patch so they can use --use-heat=False: https://review.openstack.org/#/c/581467/ Also https://review.openstack.org/#/c/581468 and https://review.openstack.org/581180 as dependencies 2) Configure CI jobs for containerized undercloud, except scenario001, 002 for timeout reasons (and figure out this problem in a parallel effort) https://review.openstack.org/#/c/575330 https://review.openstack.org/#/c/579755 3) Switch tripleoclient to deploy by default a containerized undercloud https://review.openstack.org/576218 4) Improve performances in general so scenario001/002 doesn't timeout when containerized undercloud is enabled https://review.openstack.org/#/c/581183 is the patch that'll enable the containerized undercloud https://review.openstack.org/#/c/577889/ is a patch that enables pipelining in ansible/quickstart, but more is about to come, I'll update the patches tonight. 5) Cleanup quickstart to stop using use-heat except for fs003 (needed to disable containers, and keep coverage for non containerized undercloud) https://review.openstack.org/#/c/581534/ Reviews are welcome, we aim to merge this work by milestone 3, in less than 2 weeks from now. Thanks! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] puppet-senlin development
Also please take a look at this guide to create new modules: https://docs.openstack.org/puppet-openstack-guide/latest/contributor/new-module.html Thanks and welcome! On Mon, Jul 9, 2018 at 1:46 PM Tobias Urdin wrote: > Hello Alex, > > I personally don’t know about any entity specifically working on the > Puppet Senlin module. > > We strongly welcome anybody to contribute to the development of the Puppet > OpenStack modules. > > We are happy to help :) > > Best regards > Tobias > > Sent from my iPhone > > On 9 Jul 2018, at 16:00, Alexandru Sorodoc wrote: > > Hello, > > Is anyone working or planning to work on the puppet-senlin module? We want > to use Senlin in our Pike deployment and we are considering contributing to > its puppet module to bring it to a working state. > > Best regards, > Alex > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet][tripleo] Why is this acceptance test failing?
On Wed, Jul 4, 2018 at 9:53 PM Lars Kellogg-Stedman wrote: > On Wed, Jul 04, 2018 at 07:51:20PM -0600, Emilien Macchi wrote: > > The actual problem is that the manifest isn't idempotent anymore: > > > http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_705516 > > Hey Emilien, thanks for taking a look. I'm not following -- or maybe > I'm just misreading the failure message. It really looks to me as if > the failure is caused by a regular expression; it says: > > Failure/Error: > apply_manifest(pp, :catch_changes => true) do |result| > expect(result.stderr) > .to > include_regexp([/Puppet::Type::Keystone_tenant::ProviderOpenstack: Support > for a resource without the domain.*using 'Default'.*default domain id is > '/]) > end > > And yet, the regular expression in that check clearly matches the > output shown in the failure message. What do you see that points at an > actual idempotency issue? > > (I wouldn't be at all surprised to find an actual problem in this > change; I've fixed several already. I'm just not sure how to turn > this failure into actionable information.) > Sorry for late answers, not doing a good job at catching up emails since I was 2 weeks on PTO. So in order to test if that comes from your code or not, please try the manifest yourself and run puppet 2 times. If the second time is still triggering changes in the catalog, it means the idempotency of the resource is broken, which can also mean the resource itself isn't created properly the first time and a second puppet run tries to create it again. Basically, you shouldn't see that on a second puppet run: /Stage[main]/Keystone/Keystone_domain[my_default_domain]/is_default: is_default changed 'false' to 'true' If you can't reproduce it, let me know on IRC and I'll help you but you could use https://github.com/openstack/puppet-openstack-integration/blob/master/all-in-one.sh if you need a quick way to deploy. Hope this helps, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet][tripleo] Why is this acceptance test failing?
The actual problem is that the manifest isn't idempotent anymore:
http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_705516
So something in your patch is breaking the Keystone_domain provider and
makes it non idempotent.
On Tue, Jul 3, 2018 at 7:30 PM Lars Kellogg-Stedman wrote:
> I need another set of eyes.
>
> I have a review that keeps failing here:
>
>
> http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_696966
>
> It's looking for the regular expression:
>
> /Puppet::Type::Keystone_tenant::ProviderOpenstack: Support for a
> resource without the domain.*using 'Default'.*default domain id is '/
>
> The output shown in the failure message contains:
>
> [1;33mWarning: Puppet::Type::Keystone_tenant::ProviderOpenstack:
> Support for a resource without the domain set is deprecated in
> Liberty cycle. It will be dropped in the M-cycle. Currently using
> 'Default' as default domain name while the default domain id is
> '7ddf1dfa7fac46679ba7ae2245bece2f'.[0m
>
> The regular expression matches the text! The failing test is here:
>
>
> https://github.com/openstack/puppet-keystone/blob/master/spec/acceptance/default_domain_spec.rb#L59
>
> I've been staring at this for a while and I'm not sure what's going
> on.
>
> --
> Lars Kellogg-Stedman | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Newton branch is End-Of-Life
After many postpones, we finally went ahead and closed Newton branch for TripleO repositories A last tag was created and from now we won't accept backports in this branch. RPMs in RDO will be updated with this last tag. If there is any question or concern, please let us know. PS: Thanks to the stable-maint/release-managers who helped in that process. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read
Sending an update before the weekend: Gate was in very bad shape today (long queue, lot of failures) again today, and it turns out we had a few more issues that we tracked here: https://etherpad.openstack.org/p/tripleo-gate-issues-june-2018 ## scenario007 broke because of a patch in networking-ovn https://bugs.launchpad.net/tripleo/+bug/1777168 We made the job non voting and meanwhile tried and managed to fix it: https://review.rdoproject.org/r/#/c/14155/ Breaking commit was: https://github.com/openstack/networking-ovn/commit/2365df1cc3e24deb2f3745c925d78d6d8e5bb5df Kudos to Daniel Alvarez for having the patch ready! Also thanks to Wes for making the job non voting in the meantime. I've reverted the non-voting things are situation is fixed now, so we can vote again on this one. ## Dockerhub proxy issue Infra using wrong image layer object storage proxy for Dockerhub: https://review.openstack.org/#/c/575787/ Huge thanks to infra team, specially Clark for fixing this super quickly, it clearly helped to stabilize our container jobs, I actually haven't seen timeouts since we merged your patch. Thanks a ton! ## RDO master wasn't consistent anymore, python-cloudkittyclient broke The client was refactored: https://git.openstack.org/cgit/openstack/python-cloudkittyclient/commit/?id=d070f6a68cddf51c57e77107f1b823a8f75770ba And it broke the RPM, we had to completely rewrite the dependencies so we can build the package: https://review.rdoproject.org/r/#/c/14265/ Mille merci Heikel for your responsive help at 3am, so we could come back consistent and have our latest rpms that contained a bunch of fixes. ## Where we are now Gate looks stable now. You can recheck and approve things. I went ahead and rechecked everything and made sure nothing was left abandoned. Steve's work has merged so I think we could re-consider https://review.openstack.org/#/c/575330/ again. Special thanks to everyone involved in these issues and Alex & John who also stepped up to help. Enjoy your weekend! On Thu, Jun 14, 2018 at 6:40 AM, Emilien Macchi wrote: > It sounds like we merged a bunch last night thanks to the revert, so I > went ahead and restored/rechecked everything that was out of the gate. I've > checked and nothing was left over, but let me know in case I missed > something. > I'll keep updating this thread with the progress made to improve the > situation etc. > So from now, situation is back to "normal", recheck/+W is ok. > > Thanks again for your patience, > > On Wed, Jun 13, 2018 at 10:39 PM, Emilien Macchi > wrote: > >> https://review.openstack.org/575264 just landed (and didn't timeout in >> check nor gate without recheck, so good sigh it helped to mitigate). >> >> I've restore and rechecked some patches that I evacuated from the gate, >> please do not restore others or recheck or approve anything for now, and >> see how it goes with a few patches. >> We're still working with Steve on his patches to optimize the way we >> deploy containers on the registry and are investigating how we could make >> it faster with a proxy. >> >> Stay tuned and thanks for your patience. >> >> On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi >> wrote: >> >>> TL;DR: gate queue was 25h+, we put all patches from gate on standby, do >>> not restore/recheck until further announcement. >>> >>> We recently enabled the containerized undercloud for multinode jobs and >>> we believe this was a bit premature as the container download process >>> wasn't optimized so it's not pulling the mirrors for the same containers >>> multiple times yet. >>> It caused the job runtime to increase and probably the load on docker.io >>> mirrors hosted by OpenStack Infra to be a bit slower to provide the same >>> containers multiple times. The time taken to prepare containers on the >>> undercloud and then for the overcloud caused the jobs to randomly timeout >>> therefore the gate to fail in a high amount of times, so we decided to >>> remove all jobs from the gate by abandoning the patches temporarily (I have >>> them in my browser and will restore when things are stable again, please do >>> not touch anything). >>> >>> Steve Baker has been working on a series of patches that optimize the >>> way we prepare the containers but basically the workflow will be: >>> - pull containers needed for the undercloud into a local registry, using >>> infra mirror if available >>> - deploy the containerized undercloud >>> - pull containers needed for the overcloud minus the ones already pulled >>> for the undercloud, using infra mirror if available >>> - update containers on the overcloud >>> - deploy the contain
Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read
It sounds like we merged a bunch last night thanks to the revert, so I went ahead and restored/rechecked everything that was out of the gate. I've checked and nothing was left over, but let me know in case I missed something. I'll keep updating this thread with the progress made to improve the situation etc. So from now, situation is back to "normal", recheck/+W is ok. Thanks again for your patience, On Wed, Jun 13, 2018 at 10:39 PM, Emilien Macchi wrote: > https://review.openstack.org/575264 just landed (and didn't timeout in > check nor gate without recheck, so good sigh it helped to mitigate). > > I've restore and rechecked some patches that I evacuated from the gate, > please do not restore others or recheck or approve anything for now, and > see how it goes with a few patches. > We're still working with Steve on his patches to optimize the way we > deploy containers on the registry and are investigating how we could make > it faster with a proxy. > > Stay tuned and thanks for your patience. > > On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi > wrote: > >> TL;DR: gate queue was 25h+, we put all patches from gate on standby, do >> not restore/recheck until further announcement. >> >> We recently enabled the containerized undercloud for multinode jobs and >> we believe this was a bit premature as the container download process >> wasn't optimized so it's not pulling the mirrors for the same containers >> multiple times yet. >> It caused the job runtime to increase and probably the load on docker.io >> mirrors hosted by OpenStack Infra to be a bit slower to provide the same >> containers multiple times. The time taken to prepare containers on the >> undercloud and then for the overcloud caused the jobs to randomly timeout >> therefore the gate to fail in a high amount of times, so we decided to >> remove all jobs from the gate by abandoning the patches temporarily (I have >> them in my browser and will restore when things are stable again, please do >> not touch anything). >> >> Steve Baker has been working on a series of patches that optimize the way >> we prepare the containers but basically the workflow will be: >> - pull containers needed for the undercloud into a local registry, using >> infra mirror if available >> - deploy the containerized undercloud >> - pull containers needed for the overcloud minus the ones already pulled >> for the undercloud, using infra mirror if available >> - update containers on the overcloud >> - deploy the containerized undercloud >> >> With that process, we hope to reduce the runtime of the deployment and >> therefore reduce the timeouts in the gate. >> To enable it, we need to land in that order: https://review.openstac >> k.org/#/c/571613/, https://review.openstack.org/#/c/574485/, >> https://review.openstack.org/#/c/571631/ and https://review.openstack.o >> rg/#/c/568403. >> >> In the meantime, we are disabling the containerized undercloud recently >> enabled on all scenarios: https://review.openstack.org/#/c/575264/ for >> mitigation with the hope to stabilize things until Steve's patches land. >> Hopefully, we can merge Steve's work tonight/tomorrow and re-enable the >> containerized undercloud on scenarios after checking that we don't have >> timeouts and reasonable deployment runtimes. >> >> That's the plan we came with, if you have any question / feedback please >> share it. >> -- >> Emilien, Steve and Wes >> > > > > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] tripleo gate is blocked - please read
https://review.openstack.org/575264 just landed (and didn't timeout in check nor gate without recheck, so good sigh it helped to mitigate). I've restore and rechecked some patches that I evacuated from the gate, please do not restore others or recheck or approve anything for now, and see how it goes with a few patches. We're still working with Steve on his patches to optimize the way we deploy containers on the registry and are investigating how we could make it faster with a proxy. Stay tuned and thanks for your patience. On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi wrote: > TL;DR: gate queue was 25h+, we put all patches from gate on standby, do > not restore/recheck until further announcement. > > We recently enabled the containerized undercloud for multinode jobs and we > believe this was a bit premature as the container download process wasn't > optimized so it's not pulling the mirrors for the same containers multiple > times yet. > It caused the job runtime to increase and probably the load on docker.io > mirrors hosted by OpenStack Infra to be a bit slower to provide the same > containers multiple times. The time taken to prepare containers on the > undercloud and then for the overcloud caused the jobs to randomly timeout > therefore the gate to fail in a high amount of times, so we decided to > remove all jobs from the gate by abandoning the patches temporarily (I have > them in my browser and will restore when things are stable again, please do > not touch anything). > > Steve Baker has been working on a series of patches that optimize the way > we prepare the containers but basically the workflow will be: > - pull containers needed for the undercloud into a local registry, using > infra mirror if available > - deploy the containerized undercloud > - pull containers needed for the overcloud minus the ones already pulled > for the undercloud, using infra mirror if available > - update containers on the overcloud > - deploy the containerized undercloud > > With that process, we hope to reduce the runtime of the deployment and > therefore reduce the timeouts in the gate. > To enable it, we need to land in that order: https://review. > openstack.org/#/c/571613/, https://review.openstack.org/#/c/574485/, > https://review.openstack.org/#/c/571631/ and https://review.openstack. > org/#/c/568403. > > In the meantime, we are disabling the containerized undercloud recently > enabled on all scenarios: https://review.openstack.org/#/c/575264/ for > mitigation with the hope to stabilize things until Steve's patches land. > Hopefully, we can merge Steve's work tonight/tomorrow and re-enable the > containerized undercloud on scenarios after checking that we don't have > timeouts and reasonable deployment runtimes. > > That's the plan we came with, if you have any question / feedback please > share it. > -- > Emilien, Steve and Wes > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] tripleo gate is blocked - please read
TL;DR: gate queue was 25h+, we put all patches from gate on standby, do not restore/recheck until further announcement. We recently enabled the containerized undercloud for multinode jobs and we believe this was a bit premature as the container download process wasn't optimized so it's not pulling the mirrors for the same containers multiple times yet. It caused the job runtime to increase and probably the load on docker.io mirrors hosted by OpenStack Infra to be a bit slower to provide the same containers multiple times. The time taken to prepare containers on the undercloud and then for the overcloud caused the jobs to randomly timeout therefore the gate to fail in a high amount of times, so we decided to remove all jobs from the gate by abandoning the patches temporarily (I have them in my browser and will restore when things are stable again, please do not touch anything). Steve Baker has been working on a series of patches that optimize the way we prepare the containers but basically the workflow will be: - pull containers needed for the undercloud into a local registry, using infra mirror if available - deploy the containerized undercloud - pull containers needed for the overcloud minus the ones already pulled for the undercloud, using infra mirror if available - update containers on the overcloud - deploy the containerized undercloud With that process, we hope to reduce the runtime of the deployment and therefore reduce the timeouts in the gate. To enable it, we need to land in that order: https://review.openstack.org/#/c/571613/, https://review.openstack.org/#/c/574485/, https://review.openstack.org/#/c/571631/ and https://review.openstack.org/#/c/568403. In the meantime, we are disabling the containerized undercloud recently enabled on all scenarios: https://review.openstack.org/#/c/575264/ for mitigation with the hope to stabilize things until Steve's patches land. Hopefully, we can merge Steve's work tonight/tomorrow and re-enable the containerized undercloud on scenarios after checking that we don't have timeouts and reasonable deployment runtimes. That's the plan we came with, if you have any question / feedback please share it. -- Emilien, Steve and Wes __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits
Alan Bishop has been highly involved in the Storage backends integration in TripleO and Puppet modules, always here to update with new features, fix (nasty and untestable third-party backends) bugs and manage all the backports for stable releases: https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22 He's also well knowledgeable of how TripleO works and how containers are integrated, I would like to propose him as core on TripleO projects for patches related to storage things (Cinder, Glance, Swift, Manila, and backends). Please vote -1/+1, Thanks! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 24th Edition
Welcome to the twenty-fourth edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131184.html +-+ | General announcements | +-+ +--> Rocky milestone 3 cycle just started, for a bit less than 1.5 month. +--+ | Continuous Integration | +--+ +--> rlandy is our rover and arxcruz is our ruck. Let them know any CI issues! +--> Promotion status: Master: 8d, Queens: 7d, Pike: 5d and Ocata: 3d. +--> Gate is backed-up today, such is RDO CI. Status can be checked on http://zuul.openstack.org and https://review.rdoproject.org/zuul/. +--> Sprint 14 is in flight and focus is on Upgrades testing +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Standalone documented (first iteration): https://docs.openstack.org/tripleo-docs/latest/install/ +--> containers_deployment/standalone.html +--> Still working on enabling the containerized undercloud everywhere in CI jobs +--> Containerized undercloud upgrade problems were fixed, working on post-upgrade cleanup feature now +--> Good progress on working on updating containers in CI when deploying a containerized undercloud so we can test changes in all repos (need review) +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> Skydive and Octavia integration are now ready for review. +--> UI integration blocked by under-review patches in tripleo-common. +--> the squad is looking at the next steps, which might lead to a new squad. +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squad-status +--+ | Integration | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> More validations, need review. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owls can eat owls. Not only do owls eat surprisingly large prey (some species, like the eagle owl, can even grab small deer), they also eat other species of owls. Great horned owls, for example, will attack the barred owl. The barred owl, in turn, sometimes eats the Western screech-owl. In fact, owl-on-owl predation may be a reason why Western screech-owl numbers have declined. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] StarlingX project status update
On Tue, Jun 12, 2018 at 7:46 AM, Doug Hellmann wrote: > Excerpts from Dean Troyer's message of 2018-06-12 09:28:48 -0500: > > On Mon, Jun 11, 2018 at 5:02 PM, Emilien Macchi > wrote: > > > While I agree with Doug that we assume good faith and hope for the > best, I > > > personally think we should help them (what we're doing now) but also > make > > > sure we DO NOT set a precedent. We could probably learn from this > situation > > > and document in our governance what the TC expects when companies have > a > > > fork and need to contribute back at some point. We all know StarlingX > isn't > > > alone and I'm pretty sure there are a lot of deployments out there who > are > > > in the same situation. > > > > /me pus on ex-TC hat for a minute > > > > Emilien, I totally agree with you here but would word it differently: > > we should absolutely set a precedent, but one that exhibits how we > > want to handle what ttx calls 'convergent' forks. These already > > exist, like it or not. What I hope can be established is some > > guidelines and boundaries on how to deal with these rather than just > > reject them out-of-hand. > > Yes, well said. Indeed, thanks Dean. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] StarlingX project status update
On Tue, Jun 5, 2018 at 9:08 AM, Doug Hellmann wrote: [snip] > When all of this is done, a viable project with real users will be > open source instead of closed source. Those contributors, and users, > will be a part of our community instead of looking in from the > outside. The path is ugly, long, and clearly not ideal. But, I > consider the result a win, overall. While I agree with Doug that we assume good faith and hope for the best, I personally think we should help them (what we're doing now) but also make sure we DO NOT set a precedent. We could probably learn from this situation and document in our governance what the TC expects when companies have a fork and need to contribute back at some point. We all know StarlingX isn't alone and I'm pretty sure there are a lot of deployments out there who are in the same situation. I guess my point is, yes for helping StarlingX now but no for incubating future forks if that happens. Like Graham, I think these methods shouldn't be what we encourage in our position. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 23th Edition
Welcome to the twenty third edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130926.html +-+ | General announcements | +-+ +--> This week is Rocky Milestone 2. +--+ | Continuous Integration | +--+ +--> Ruck is arxcruz and Rover is rlandy. Please let them know any new CI issue. +--> Master promotion is 1 day, Queens is 0 day, Pike is 0 day and Ocata is 0 day. Really nice work CI folks! +--> Sprint 14 is ongoing: Checkout https://trello.com/c/1W62zvhh/770-sprint-14-goals but focus is to finish upgrade CI work. +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Reviews are requested on different topics: CI, Newton, FFU +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Good progress done on All-In-One blueprint, update sent on the ML: http://lists.openstack.org/pipermail/openstack-dev/2018-June/131135.html +--> Still working on Containerized undercloud upgrades (bug with rabbitmq upgrade: https://review.openstack.org/#/c/572449/) +--> Enabling the containerized undercloud everywhere in CI +--> Working on updating containers in CI when deploying a containerized undercloud so we can test changes in all repos +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> checkout the new command: "openstack overcloud failures" for better deployment failures output +--> Documentation was improved with recent changes +--> UI integration is still in progress +--> More: https://etherpad.openstack.org/p/tripleo-config-downlo ad-squad-status +--+ | Integration | +--+ +--> Working on : "Persist ceph-ansible fetch_directory", check it out: https://review.openstack.org/#/c/567782/ +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Beginning trial of using storyboard not just for bugs but also for stories/epics +--> Review of existing config-download patches that still need to merge. Hoping to finalize this week. +--> Network config initial patches are up - very cool so far! +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> Custom validations work +--> Nova event callback validation +--> OpenShift on OpenStack validation work +--> Mistral workflow plugin +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Public TLS is being refactored +--> Working on limiting sudoers rights +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owls were once a sign of victory in battle. In ancient Greece, the Little Owl was the companion of Athena, the Greek goddess of wisdom, which is one reason why owls symbolize learning and knowledge. But Athena was also a warrior goddess and the owl was considered the protector of armies going into war. If Greek soldiers saw an owl fly by during battle, they took it as a sign of coming victory. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)
TL;DR: we made nice progress and you can checkout this demo:
https://asciinema.org/a/185533
We started the discussion back in Dublin during the last PTG. The idea of
Standalone (aka All-In-One, but can be mistaken with all-in-one overcloud)
is to deploy a single node OpenStack where the provisioning happens on the
same node (there is no notion of {under/over}cloud).
A kind of a "packstack" or "devstack" but using TripleO which has can offer:
- composable containerized services
- composable upgrades
- composable roles
- Ansible driven deployment
One of the key features we have been focusing so far are:
- low bar to be able to dev/test TripleO (single machine: VM), with simpler
tooling
- make it fast (being able to deploy OpenStack in minutes)
- being able to make a change in OpenStack (e.g. Keystone) and test the
change immediately
The workflow that we're currently targeting is:
- deploy the system by yourself (centos7 or rhel7)
- deploy the repos, install python-tripleoclient
- run 'openstack tripleo deploy (+ few args)
- (optional) modify your container with a Dockerfile + Ansible
- Test your change
Status:
- tripleoclient was refactored in a way that the undercloud is actually a
special configuration of the standalone deployment (still work in
progress). We basically refactored the containerized undercloud to be more
generic and configurable for standalone.
- we can now deploy a standalone OpenStack with just Keystone +
dependencies - which takes 12 minutes total (demo here:
https://asciinema.org/a/185533 and doc in progress:
http://logs.openstack.org/27/571827/6/check/build-openstack-sphinx-docs/1885304/html/install/containers_deployment/standalone.html
)
- we have an Ansible role to push modifications to containers via a Docker
file: https://github.com/openstack/ansible-role-tripleo-modify-image/
What's next:
- Documentation: as you can see the documentation is still in progress (
https://review.openstack.org/#/c/571827/)
- Continuous Integration: we're working on a new CI
job: tripleo-ci-centos-7-standalone
https://trello.com/c/HInL8pNm/7-upstream-ci-testing
- Working on the standalone configuration interface, still WIP:
https://review.openstack.org/#/c/569535/
- Investigate the use case where a developer wants to prepare the
containers before the deployment
I hope this update was useful, feel free to give feedback or ask any
questions,
--
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Containerized Undercloud by default
On Thu, May 31, 2018 at 9:13 PM, Emilien Macchi wrote: > > - all multinode scenarios - current blocked by 1774297 as well but also >> https://review.openstack.org/#/c/571566/ >> > This part is done and ready for review (CI team + others): https://review.openstack.org/#/c/571529/ Thanks! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Containerized Undercloud by default
I forgot to mention Steve's effort to update the containers when deploying the undercloud, this is a critical piece if we want to continue to test changes in projects like tripleo-common that are embedded in Mistral containers for example. The patch that will enable it is https://review.openstack.org/#/c/571631/ and thanks to this work we'll make unify the container registry for both the undercloud and overcloud, using the same [updated] containers. It is important to have this feature enabled in our CI to maintain the parity with how we tested TripleO when undercloud wasn't containeirized, so this is something we want to achieve before switching all the TripleO CI jobs. On Thu, May 31, 2018 at 8:58 PM, Emilien Macchi wrote: > Hi, > > During Rocky cycle we would like to switch tripleoclient to deploy > containeirzed undercloud by default but before to get there, we want to > switch all CI jobs to it, like it was done when enabling config-download by > default. > Right now we have 3 jobs which test the containerized undercloud: > > - tripleo-ci-centos-7-undercloud-containers: deploy a containerized > undercloud and run Tempest > - tripleo-ci-centos-7-containerized-undercloud-upgrades: deploy a > non-containerized undercloud on Queens and upgrade to a containerized > undercloud on Rocky > - gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master: deploy a > containerized undercloud and an overcloud with HA architecture and IPv4 > network (with introspection, SSL, etc). > > What's next (target is Rocky M3): > - tripleo-ci-centos-7-containers-multinode - currently blocked by > https://bugs.launchpad.net/tripleo/+bug/1774297 > - all multinode scenarios - current blocked by 1774297 as well but also > https://review.openstack.org/#/c/571566/ > - gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset035-master - > currently blocked by https://bugs.launchpad.net/tripleo/+bug/1774557 > (with a potential fix: https://review.openstack.org/571620) > - all other jobs that run on master, except > tripleo-ci-centos-7-undercloud-oooq > that we'll probably keep during Rocky and remove in Stein if we > successfully switch the default. > > Once we've reached that point, we'll change tripleoclient's default, and > hopefully all of this before m3 :-) > > Any question or feedback is highly welcome, > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Containerized Undercloud by default
Hi, During Rocky cycle we would like to switch tripleoclient to deploy containeirzed undercloud by default but before to get there, we want to switch all CI jobs to it, like it was done when enabling config-download by default. Right now we have 3 jobs which test the containerized undercloud: - tripleo-ci-centos-7-undercloud-containers: deploy a containerized undercloud and run Tempest - tripleo-ci-centos-7-containerized-undercloud-upgrades: deploy a non-containerized undercloud on Queens and upgrade to a containerized undercloud on Rocky - gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-master: deploy a containerized undercloud and an overcloud with HA architecture and IPv4 network (with introspection, SSL, etc). What's next (target is Rocky M3): - tripleo-ci-centos-7-containers-multinode - currently blocked by https://bugs.launchpad.net/tripleo/+bug/1774297 - all multinode scenarios - current blocked by 1774297 as well but also https://review.openstack.org/#/c/571566/ - gate-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset035-master - currently blocked by https://bugs.launchpad.net/tripleo/+bug/1774557 (with a potential fix: https://review.openstack.org/571620) - all other jobs that run on master, except tripleo-ci-centos-7-undercloud-oooq that we'll probably keep during Rocky and remove in Stein if we successfully switch the default. Once we've reached that point, we'll change tripleoclient's default, and hopefully all of this before m3 :-) Any question or feedback is highly welcome, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 22th Edition
Welcome to the twenty second edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130528.html +-+ | General announcements | +-+ +--> OpenStack community met last week for the Summit in Vancouver, we had great presentations and also great feedback! +--> Milestone 2 deadline is next week! +-+ | Owls at Summit | +-+ +--> TripleO project updates: from Queens to Rocky and beyond Recording: https://www.youtube.com/watch?v=4q_zkvOP8Dk Slides: https://t.co/DYOAjt1jDk +--> TripleO onboarding session: https://etherpad.openstack.org/p/YVR-forum-tripleo-onboarding People used that time to ask any questions about TripleO and the team was happy to answer and provide support. +--> TripleO Ops and User Feedback: https://etherpad.openstack.org/p/tripleo-rocky-ops-and-user-feedback Feedback about logging, documentation were the main topics we covered but other things were discussed, see etherpad. +--> TripleO and Ansible integration: https://etherpad.openstack.org/p/tripleo-rocky-ansible-integration James did a great job at presenting the config-download feature and how we now use Ansible for some deployment tasks. +--+ | Continuous Integration | +--+ +--> Ruck is arxcruz and Rover is rlandy. Please let them know any new CI issue. +--> Master promotion is 0 day, Queens is 0 days, Pike is 3 days and Ocata is 4 days. +--> Sprint 13 themes were Upgrade CI (new jobs, forward looking release state machine, voting jobs). +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> FFU at Summit: https://www.youtube.com/watch?v=YJXem5d6fkI +--> Need reviews converge patches and docs updates +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Efforts arounds all-in-one installer, image prepare and image workflows, good progress overall. +--> Focus is on stabilization and make the containerized undercloud the default in TripleO. +--> Tomorrow is containerized undercloud deep dive: https://etherpad. openstack.org/p/tripleo-deep-dive-containerized-undercloud +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> config download status commands and workflows +--> UI work still ongoing +--> Major doc update (merged): https://review.openstack.org/#/c/566606 +--> More: https://etherpad.openstack.org/p/tripleo-config-downlo ad-squad-status +--+ | Integration | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> Mistral project update https://www.youtube.com/watch?v=y9qieruccO4 +--> Validate workflow input: https://bugs.launchpad.net/tripleo/+bug/1774166 +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Public TLS is being refactored +--> Kerberos auth for keystone update +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owl flight is silent, unlike most birds, owls make virtually no noise when they fly. They have special feathers that break turbulence into smaller currents, which reduces sound. Soft velvety down further muffles noise. Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Migration to Storyboard
During the Storyboard session today: https://etherpad.openstack.org/p/continuing-the-migration-lp-sb We mentioned that TripleO would continue to migrate during Rocky cycle. Like Alex mentioned in this thread, we need to migrate the scripts used by the CI squad so they work with SB. Once this is done, we'll proceed to the full migration of all blueprints and bugs into tripleo-common project in SB. Projects like tripleo-validations, tripleo-ui (more?) who have 1:1 mapping between their "name" and project repository could use a dedicated project in SB, although we need to keep things simple for our users so they know where to file a bug without confusion. We hope to proceed during Rocky but it'll probably take some time to update our scripts and documentation, also educate our community to use the tool, so we expect the Stein cycle the first cycle where we actually consume SB. I really wanted to thank the SB team for their patience and help, TripleO is big and this migration hasn't been easy but we'll make it :-) Thanks, On Tue, May 15, 2018 at 7:53 AM, Alex Schultz <aschu...@redhat.com> wrote: > Bumping this up so folks can review this. It was mentioned in this > week's meeting that it would be a good idea for folks to take a look > at Storyboard to get familiar with it. The upstream docs have been > updated[0] to point to the differences when dealing with proposed > patches. Please take some time to review this and raise any > concerns/issues now. > > Thanks, > -Alex > > [0] https://docs.openstack.org/infra/manual/developers.html# > development-workflow > > On Wed, May 9, 2018 at 1:24 PM, Alex Schultz <aschu...@redhat.com> wrote: > > Hello tripleo folks, > > > > So we've been experimenting with migrating some squads over to > > storyboard[0] but this seems to be causing more issues than perhaps > > it's worth. Since the upstream community would like to standardize on > > Storyboard at some point, I would propose that we do a cut over of all > > the tripleo bugs/blueprints from Launchpad to Storyboard. > > > > In the irc meeting this week[1], I asked that the tripleo-ci team make > > sure the existing scripts that we use to monitor bugs for CI support > > Storyboard. I would consider this a prerequisite for the migration. > > I am thinking it would be beneficial to get this done before or as > > close to M2. > > > > Thoughts, concerns, etc? > > > > Thanks, > > -Alex > > > > [0] https://storyboard.openstack.org/#!/project_group/76 > > [1] http://eavesdrop.openstack.org/meetings/tripleo/2018/ > tripleo.2018-05-08-14.00.log.html#l-42 > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Cancel IRC meeting for May 22, 2018
On Wed, May 16, 2018 at 1:07 PM, Alex Schultz <aschu...@redhat.com> wrote: > Since the summit is coming up, there will likely be very low > attendance. We'll carry any open items until the following week. > No Weekly Owl as well, but be patient for the next Edition special Summit. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 21th Edition
Welcome to the twenty first edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-May/130273.html +-+ | General announcements | +-+ +--> Migration to Storyboard is scheduled for rocky-m2, please be aware of its usage: https://docs.openstack.org/infra/manual/developers.html#development-workflow +--> We have 3 more weeks until milestone 2 ! Check-out the schedule: https://releases.openstack.org/rocky/schedule.html +--+ | Continuous Integration | +--+ +--> Ruck is Matt and Rover is Sagi. Please let them know any new CI issue. +--> centos 7.5 blockers were solved, now looking at how we can improve centos testing and avoid gate downtime in the future +--> Master promotion is 0 day, Queens is 6 days, Pike is 6 days and Ocata is 6 days. +--> Sprint themes are Upgrade CI (new jobs, forward looking release state machine, voting jobs) and refactor python-tempestconf for service discovery. +--> Discussion in progress around zuul v3 multi-staged check pipelines in TripleO CI +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Collaboration with CI team for upgrade jobs. +--> Need reviews on FFU work, check the etherpad. +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Support of image customization during upload in (good) progress. +--> Efforts arounds all-in-one installer, also good progress. +--> Preparing next deep dive: https://etherpad.openstack.org/p/tripleo-deep-dive-containerized-undercloud +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> config download status commands and workflows (need reviews) +--> UI work still ongoing +--> Major doc update: https://review.openstack.org/#/c/566606 +--> More: https://etherpad.openstack.org/p/tripleo-config- download-squad-status +--+ | Integration | +--+ +--> Need to add support for NodeDataLookup parameter into "config-download" deployment mechanism (not started yet). +--> Need review on https://review.openstack.org/#/c/563112/ +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Still working on Network Wizard. +--> Finishing config-download integration +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> Custom validations spec ready for reviews: https://review.openstack.org/#/c/393775/ +--> Mistral workflow plugin +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> Lot of reviews are needed, please check them out +--> Workflows should now all use the tripleo.messaging.v1.send workflow to send messages +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Swift object encryption by default in the undercloud +--> TLS by default for the overcloud +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Barn Owls swallow their prey whole—skin, bones, and all—and they eat up to 1,000 mice each year. Source: https://www.audubon.org/news/11-fun-facts-about-owls Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Containerized Undercloud deep-dive
Dan and I are organizing a deep-dive session focused on the containerized undercloud. https://etherpad.openstack.org/p/tripleo-deep-dive-containerized-undercloud We proposed a date + list of topics but feel free to comment and ask for topics/questions. Thanks, -- Emilien & Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] tripleo upstream gate outtage, was: -> gate jobs impacted RAX yum mirror
On Sat, May 12, 2018 at 9:10 AM, Wesley Hayutin <whayu...@redhat.com> wrote: > > 2. Shortly after #1 was resolved CentOS released 7.5 which comes directly > into the upstream repos untested and ungated. Additionally the associated > qcow2 image and container-base images were not updated at the same time as > the yum repos. https://bugs.launchpad.net/tripleo/+bug/1770355 > Why do we have this situation everytime the OS is upgraded to a major version? Can't we test the image before actually using it? We could have experimental jobs testing latest image and pin gate images to a specific one? Like we could configure infra to deploy centos 7.4 in our gate and 7.5 in experimental, so we can take our time to fix eventual problems and make the switch when we're ready, instead of dealing with fires (that usually come all together). It would be great to make a retrospective on this thing between tripleo ci & infra folks, and see how we can improve things. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live
On Wed, May 2, 2018 at 5:19 AM, Jimmy McArthur <ji...@openstack.org> wrote: > > No problem, we have both on the schedule. I moved the Project Update to > 11-11:20 so you can have a few minutes before the Onboarding starts at > 11:50. > > https://www.openstack.org/summit/vancouver-2018/summit-sched > ule/global-search?t=TripleO > > Let me know if I can assist further. > Everything looks excellent to me now. Thanks for your help! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live
On Tue, May 1, 2018 at 7:18 AM, Jimmy McArthur <ji...@openstack.org> wrote: > Apologies for the delay, Emilien! I should be adding it today, but it's > definitely yours. > Could we change the title of the slot and actually be a TripleO Project Update session? It would have been great to have the onboarding session but I guess we also have 2 other sessions where we'll have occasions to meet: TripleO Ops and User feedback and TripleO and Ansible integration If it's possible to still have an onboarding session, awesome otherwise it's ok I think we'll deal with it. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 19th Edition
Welcome to the nineteenth edition of a weekly update in TripleO world! The goal is to provide a short reading (less than 5 minutes) to learn what's new this week. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129800.html +-+ | General announcements | +-+ +--> Some efforts will be done during Rocky for splitting out controlplane, see spec: https://review.openstack.org/#/c/523459 +--> We have 5 more weeks until milestone 2 ! Check-out the schedule: https://releases.openstack.org/rocky/schedule.html +--+ | Continuous Integration | +--+ +--> Ruck is Wes and Rover is Gabriele. Please let them know any new CI issue. +--> Master promotion is 0 day, Queens is 0 day, Pike is 3 days and Ocata is 1 days. Kudos folks! +--> Still working on libvirt based multinode reproducer, see https://goo.gl/DYCnkx +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Containerized Undercloud upgrades has made good progress, non-voting CI job almost ready +--> Major efforts in tripleoclient for all-in-one (sorry for all the Merge Conflict) but it was needed +--> ansible-role-container-registry was imported in RDO, now moving forward to consume it in THT. +--> No progress on container updates before undercloud deployment. +--> Still working on parity items between instack-undercloud and containerized undercloud +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> config-download now the default with tripleo-heat-templates! +--> Rewriting enable-ssh-admin.sh in python +--> WIP around importing ansible role for keystone tasks. +--> Progress on OpenStark operations Ansible role: https://github.com/samdoran/ansible-role-openstack-operations +--> Working on Skydive transition +--> Working on improving performances when deploying Ceph with Ansible. +--> More: https://etherpad.openstack.org/p/tripleo-config-download- squad-status +--+ | Integration | +--+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Working on Network Wizard. +--> Finishing config-download integration +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> Working on splitting workflows repository. +--> Efforts around Workflow linting and unit testing. +--> Discussions around usage of Zaqar. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> No updates, still focusing on Public TLS by default and Secret Management. +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Keith Schincke suggested this weekly fact: you can observe owl's eyeball through their ear: https://www.livescience.com/61673-owl-eye-seen-through-ear.html Thank you all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Overriding project-templates in Zuul
On Tue, May 1, 2018 at 10:02 AM, James E. Blair <cor...@inaugust.com> wrote: [...] > Okay, let's summarize: > > Proposal 1: All project-template and project-local job variants matching > the item's branch must also match the item. > > * Files and irrelevant-files on project-template and project stanzas are > essentially combined in a set intersection. > * It's possible to further reduce the scope of jobs, but not expand. > * Files and irrelevant-files are still independent matchers, and if both > are present, both must match. > * It's not possible to alter a job attribute by adding a project-local > variant with only a files matcher (it would cause the whole job to run > or not run). But it's still possible to do that in the main job > definition itself. > > Proposal 2: Files and irrelevant-files are treated as overwriteable > attributes and evaluated after branch-matching variants are combined. > > * Files and irrelevant-files are overwritten, so the last value > encountered when combining all the matching variants (looking only at > branches) wins. > * Files and irrelevant-files will be treated as a pair, so that if > "irrelevant-files" appears, it will erase a previous "files" > attribute. > * It's possible to both reduce and expand the scope of jobs, but the > user may need to manually copy values from a parent or other variant > in order to do so. > * It will no longer be possible to alter a job attribute by adding a > variant with only a files matcher -- in all cases files and > irrelevant-files are used solely to determine whether the job is run, > not to determine whether to apply a variant. > > I think both would be good solutions to the problem. The key points for > me are whether we want to keep the "alter a job attribute with variant > with a files matcher" functionality (the "rebuild_index" example from > above), and whether the additional control of overwriting the matchers > (at the cost of redundancy in configuration) is preferable to combining > the matchers. > In the case of TripleO, I think proposal 2 is what we want. We have stanzas defined in the templates definitions in openstack-infra/tripleo-ci repo, but really want to override the file rules per repo (openstack/tripleo-quickstart for example) and I don't think we want to have them both matching but so the last value encountered would win. I'll let TripleO CI squad to give more thoughts though. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live
On Mon, Apr 30, 2018 at 10:25 AM, Emilien Macchi <emil...@redhat.com> wrote: > On Mon, Apr 30, 2018 at 10:05 AM, Jimmy McArthur <ji...@openstack.org> > wrote: >> >> It looks like we have a spot held for you, but did not receive >> confirmation that TripleO would be moving forward with Project Update. If >> you all will be recording this, we have you down for Wednesday from 11:25 - >> 11:45am. Just let me know and I'll get it up on the schedule. >> > > This slot is perfect, and I'll run it with one of my tripleo co-workers > (Alex won't be here). > Jimmy, could you please confirm we have the TripleO Project Updates slot? I don't see it in the schedule. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Overriding project-templates in Zuul
On Mon, Apr 30, 2018 at 8:58 AM, James E. Blair <cor...@inaugust.com> wrote: [...] > === === > Matcher Template Project Result > === === > files ABBC ABC > irrelevant-files ABBC B > === === > > I believe this will address the shortcoming identified above, but before > we get too far in implementing it, I'd like to ask folks to take a > moment and evaluate whether it will address the issues you've seen, or > if you foresee any problems which I haven't anticipated. > It'll address a need we have in TripleO where we have complex file rules and heavily rely on templates. The matrix proposal looks good to me and will allow us to simplify a bit our templates. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] The Forum Schedule is now live
On Mon, Apr 30, 2018 at 10:05 AM, Jimmy McArthur <ji...@openstack.org> wrote: > > It looks like we have a spot held for you, but did not receive > confirmation that TripleO would be moving forward with Project Update. If > you all will be recording this, we have you down for Wednesday from 11:25 - > 11:45am. Just let me know and I'll get it up on the schedule. > This slot is perfect, and I'll run it with one of my tripleo co-workers (Alex won't be here). Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The Forum Schedule is now live
On Fri, Apr 27, 2018 at 9:04 AM, Jimmy McArthur <ji...@openstack.org> wrote: > Hello all - > > Please take a look here for the posted Forum schedule: > https://www.openstack.org/summit/vancouver-2018/summit-schedule#track=224 > You should also see it update on your Summit App. > Why TripleO doesn't have project update? Maybe we could combine it with TripleO - Project Onboarding if needed but it would be great to have it advertised as a project update! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Proposing Tobias Urdin to join Puppet OpenStack core
+1, thanks Tobias for your contributions! On Fri, Apr 27, 2018 at 8:21 AM, Iury Gregory <iurygreg...@gmail.com> wrote: > +1 > > On Fri, Apr 27, 2018, 12:15 Mohammed Naser <mna...@vexxhost.com> wrote: > >> Hi everyone, >> >> I'm proposing that we add Tobias Urdin to the core Puppet OpenStack >> team as they've been putting great reviews over the past few months >> and they have directly contributed in resolving all the Ubuntu >> deployment issues and helped us bring Ubuntu support back and make the >> jobs voting again. >> >> Thank you, >> Mohammed >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] ironic automated cleaning by default?
On Fri, Apr 27, 2018 at 6:43 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: [...] I would like to run at least one TripleO CI job with cleaning enabled. Any > objections to that? If not, what would be the best job (it has to run > ironic, obviously)? > > [0] https://review.openstack.org/#/q/topic:cleaning+status:open We "only" have 2 jobs in the (third party) gate: fs001 and fs035. Both are testing the same thing the last time I checked except fs035 is ipv6. I would pick one of them and just do it. I'll let CI team comment on that. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: [tripleo] PTG session about All-In-One installer: recap & roadmap
We created a new board where we'll track the efforts for the all-in-one installer: https://trello.com/b/iAHhAgjV/tripleo-all-in-one-installer Note: please do not use the containerized undercloud dashboard for these tasks, it is a separated effort. Feel free to join the board and feed the backlog! Thanks, On Thu, Apr 5, 2018 at 10:02 AM, Dan Prince <dpri...@redhat.com> wrote: > On Thu, Apr 5, 2018 at 12:24 PM, Emilien Macchi <emil...@redhat.com> > wrote: > > On Thu, Apr 5, 2018 at 4:37 AM, Dan Prince <dpri...@redhat.com> wrote: > > > >> Much of the work on this is already there. We've been using this stuff > >> for over a year to dev/test the containerization efforts for a long > >> time now (and thanks for your help with this effort). The problem I > >> think is how it is all packaged. While you can use it today it > >> involves some tricks (docker in docker), or requires you to use an > >> extra VM to minimize the installation footprint on your laptop. > >> > >> Much of the remaining work here is really just about packaging and > >> technical debt. If we put tripleoclient and heat-monolith into a > >> container that solves much of the requirements problems and > >> essentially gives you a container which can transform Heat templates > >> to Ansible. From the ansible side we need to do a bit more work to > >> mimimize our dependencies (i.e. heat hooks). Using a virtual-env would > >> be one option for developers if we could make that work. I lighter set > >> of RPM packages would be another way to do it. Perhaps both... > >> Then a smaller wrapper around these things (which I personally would > >> like to name) to make it all really tight. > > > > > > So if I summarize the discussion: > > > > - A lot of positive feedback about the idea and many use cases, which is > > great. > > > > - Support for non-containerized services is not required, as long as we > > provide a way to update containers with under-review patches for > developers. > > I think we still desire some (basic no upgrades) support for > non-containerized baremetal at this time. > > > > > - We'll probably want to breakdown the "openstack undercloud deploy" > process > > into pieces > > * start an ephemeral Heat container > > It already supports this if use don't use the --heat-native option, > also you can customize the container used for heat via > --heat-container-image. So we already have this! But rather than do > this I personally prefer the container to have python-tripleoclient > and heat-monolith in it. That way everything everything is in there to > generate Ansible templates. If you just use Heat you are missing some > of the pieces that you'd still have to install elsewhere on your host. > Having them all be in one scoped container which generates Ansible > playbooks from Heat templates is better IMO. > > > * create the Heat stack passing all requested -e's > > * run config-download and save the output > > > > And then remove undercloud specific logic, so we can provide a generic > way > > to create the config-download playbooks. > > Yes. Lets remove some of the undercloud logic. But do note that most > of the undercloud specific login is now in undercloud_config.py anyway > so this is mostly already on its way. > > > This generic way would be consumed by the undercloud deploy commands but > > also by the new all-in-one wrapper. > > > > - Speaking of the wrapper, we will probably have a new one. Several names > > were proposed: > > * openstack tripleo deploy > > * openstack talon deploy > > * openstack elf deploy > > The wrapper could be just another set of playbooks. That we give a > name too... and perhaps put a CLI in front of as well. > > > > > - The wrapper would work with deployed-server, so we would noop Neutron > > networks and use fixed IPs. > > This would be configurable I think depending on which templates were > used. Noop as a default for developer deployments but do note that > some services like Neutron aren't going to work unless you have some > basic network setup. Noop is useful if you prefer to do this manually, > but our os-net-config templates are quite useful to automate things. > > > > > - Investigate the packaging work: containerize tripleoclient and > > dependencies, see how we can containerized Ansible + dependencies (and > > eventually reduce them at strict minimum). > > > > Let me know if I missed something important, hopefully we can move things > > forward during this cycle. > > -- > > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 18th Edition
Note: this is the eighteenth edition of a weekly update of what happens in TripleO. The goal is to provide a short reading (less than 5 minutes) to learn where we are and what we're doing. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129450.html +-+ | General announcements | +-+ +--> Rocky milestone 1 was released last week! We're currently in milestone 2 cycle: https://releases.openstack.org/rocky/schedule.html +--+ | Continuous Integration | +--+ +--> Ruck is panda and Rover is quiquell. Please let them know any new CI issue. +--> Master promotion is 4 day, Queens is 0 day, Pike is 7 days and Ocata is 4 days. +--> Still working on libvirt based multinode reproducer, see https://goo.gl/DYCnkx +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> No updates this week, some reviews are still needed. +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Still working on UX and parity topics. +--> Upgrade job is waiting for a promotion on master to work. +--> Still prototyping container updates before undercloud deployment. +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> config-download now the default with tripleoclient! +--> ceph jobs migrated to external_deploy_tasks +--> CI jobs almost all converted (experimental in progress) +--> octavia and skydive still in progress +--> finalizing tripleo-ui integration, tripleo-common patches are now stable +--> need workflows to cancel deployment and undeploy +--> More: https://etherpad.openstack.org/p/tripleo-config-download-squad-status +--+ | Integration | +--+ +--> No updates. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Finishing config-download integration +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> Custom validations/swift storage work. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> Working on neutron sidecar container. +--> NFV deployments testing config-download. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No updates. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> No updates. +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Owls May Have Coexisted With Dinosaurs! "We do know that owl-like birds like Berruornis and Ogygoptynx lived 60 million years ago, during the Paleocene epoch, which means it's entirely possible that the ultimate ancestors of owls coexisted with dinosaurs toward the end of the Cretaceous period. Technically speaking, owls are one of the most ancient groups of terrestrial birds, rivaled only by the gamebirds (i.e., chickens, turkeys and pheasants) of the order Galliformes." Source: https://www.thoughtco.com/fascinating-facts-about-owls-4107228 Thanks all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits
Thanks everyone for your positive feedback. I've updated Gerrit! Welcome Marius and thanks again for your hard work! On Mon, Apr 23, 2018 at 4:55 AM, James Slagle <james.sla...@gmail.com> wrote: > On Thu, Apr 19, 2018 at 1:01 PM, Emilien Macchi <emil...@redhat.com> > wrote: > > Greetings, > > > > As you probably know mcornea on IRC, Marius Cornea has been contributing > on > > TripleO for a while, specially on the upgrade bits. > > Part of the quality team, he's always testing real customer scenarios and > > brings a lot of good feedback in his reviews, and quite often takes care > of > > fixing complex bugs when it comes to advanced upgrades scenarios. > > He's very involved in tripleo-upgrade repository where he's already core, > > but I think it's time to let him +2 on other tripleo repos for the > patches > > related to upgrades (we trust people's judgement for reviews). > > > > As usual, we'll vote! > > > > Thanks everyone for your feedback and thanks Marius for your hard work > and > > involvement in the project. > > +1 > > > -- > -- James Slagle > -- > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Reminder about openstack/instack-undercloud contributions
In case you missed it, the TripleO team is working on making the containerized undercloud by default during Rocky. It means that any patch in instack-undercloud won't probably be useful for Rocky, unless you need to backport something in stable branches then fine. Anything that is new, has to be ported in tripleoclient and tripleo-heat-templates. Feel free to reach out on #tripleo if you have any question! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] roadmap on containers workflow
So the role has proven to be useful and we're now sure that we need it to deploy a container registry before any container in the deployment, which means we can't use the puppet code anymore for this service. I propose that we move the role to OpenStack: https://review.openstack.org/#/c/563197/ https://review.openstack.org/#/c/563198/ https://review.openstack.org/#/c/563200/ So we can properly peer review and gate the new role. In the meantime, we continue to work on the new workflow. Thanks, On Sun, Apr 15, 2018 at 7:24 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Fri, Apr 13, 2018 at 5:58 PM, Emilien Macchi <emil...@redhat.com> > wrote: > >> >> A bit of progress today, I prototyped an Ansible role for that purpose: >> https://github.com/EmilienM/ansible-role-container-registry >> >> The next step is, I'm going to investigate if we can deploy Docker and >> Docker Distribution (to deploy the registry v2) via the existing composable >> services in THT by using external_deploy_tasks maybe (or another interface). >> The idea is really to have the registry ready before actually deploying >> the undercloud containers, so we can modify them in the middle (run >> container-check in our case). >> > > This patch: https://review.openstack.org/#/c/561377 is deploying Docker > and Docker Registry v2 *before* containers deployment in the docker_steps. > It's using the external_deploy_tasks interface that runs right after the > host_prep_tasks, so still before starting containers. > > It's using the Ansible role that was prototyped on Friday, please take a > look and raise any concern. > Now I would like to investigate how we can run container workflows between > the deployment and docker and containers deployments. > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Proposing Marius Cornea core on upgrade bits
Greetings, As you probably know mcornea on IRC, Marius Cornea has been contributing on TripleO for a while, specially on the upgrade bits. Part of the quality team, he's always testing real customer scenarios and brings a lot of good feedback in his reviews, and quite often takes care of fixing complex bugs when it comes to advanced upgrades scenarios. He's very involved in tripleo-upgrade repository where he's already core, but I think it's time to let him +2 on other tripleo repos for the patches related to upgrades (we trust people's judgement for reviews). As usual, we'll vote! Thanks everyone for your feedback and thanks Marius for your hard work and involvement in the project. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] The Weekly Owl - 17th Edition
Note: this is the seventeeth edition of a weekly update of what happens in TripleO. The goal is to provide a short reading (less than 5 minutes) to learn where we are and what we're doing. Any contributions and feedback are welcome. Link to the previous version: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129255.html +-+ | General announcements | +-+ +--> Rocky milestone 1 will be released this week (probably tomorrow)! +--> (reminder) if you're looking at reproducing a CI job, checkout: https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html +--+ | Continuous Integration | +--+ +--> Ruck is quiquell and Rover is panda. Please let them know any new CI issue. +--> Master promotion is 1 day, Queens is 2 days, Pike is 4 days and Ocata is 5 days. +--> Efforts around libvirt based multinode reproducer, see https://trello.com/c/JEGLSVh6/323-reproduce-ci-jobs-with-libvirt +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting and https://goo.gl/D4WuBP +-+ | Upgrades | +-+ +--> Progress on FFU CLI in tripleoclient, need reviews. +--> Work for containerized undercloud upgrades has been merged. Testing will make progress after rocky-m1 (with new tags). +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status +---+ | Containers | +---+ +--> Still working on UX problems +--> Still working on container workflow, good progress last week where container prepare isn't needed. Now working on container updates. +--> Investigating how to bootstrap Docker + Registry before deploying containers +--> Progress on routed networks support +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | config-download | +--+ +--> Moving to config-download by default is coming very soon (once Ceph patches land). +--> Ceph was migrated and all patches are going to merge this week. +--> octavia/skydive migration is wip. +--> Improving deploy-steps-tasks.j2 to improve playbook readability and memory consumption +--> UI work is work in progress. +--> More: https://etherpad.openstack.org/p/tripleo-config-downlo ad-squad-status +--+ | Integration | +--+ +--> No updates. +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Efforts on config-download integration +--> Added type to ansible-playbook messages (feedback needed) +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> No updates. +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> No updates this week. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> Need reviews, see etherpad. +--> Working on workflows v2 +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status +---+ | Security | +---+ +--> Tomorrow's meeting is about Storyboard migration and Secret management. +--> More: https://etherpad.openstack.org/p/tripleo-security-squad ++ | Owl fact | ++ Did you know owls were watching you while working on TripleO? Check this out: https://www.reddit.com/r/pics/comments/8cz8v0/owls_born_outside_of_office_window_wont_stop/ (Thanks Wes for the link) Thanks all for reading and stay tuned! -- Your fellow reporter, Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] roadmap on containers workflow
On Fri, Apr 13, 2018 at 5:58 PM, Emilien Macchi <emil...@redhat.com> wrote: > > A bit of progress today, I prototyped an Ansible role for that purpose: > https://github.com/EmilienM/ansible-role-container-registry > > The next step is, I'm going to investigate if we can deploy Docker and > Docker Distribution (to deploy the registry v2) via the existing composable > services in THT by using external_deploy_tasks maybe (or another interface). > The idea is really to have the registry ready before actually deploying > the undercloud containers, so we can modify them in the middle (run > container-check in our case). > This patch: https://review.openstack.org/#/c/561377 is deploying Docker and Docker Registry v2 *before* containers deployment in the docker_steps. It's using the external_deploy_tasks interface that runs right after the host_prep_tasks, so still before starting containers. It's using the Ansible role that was prototyped on Friday, please take a look and raise any concern. Now I would like to investigate how we can run container workflows between the deployment and docker and containers deployments. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] roadmap on containers workflow
On Wed, Apr 11, 2018 at 3:38 PM, Steve Baker <sba...@redhat.com> wrote: > > - If agreed, we'll create a new Ansible role called > ansible-role-container-registry > that for now will deploy exactly what we have in TripleO, without extra > feature. > > +1 > A bit of progress today, I prototyped an Ansible role for that purpose: https://github.com/EmilienM/ansible-role-container-registry The next step is, I'm going to investigate if we can deploy Docker and Docker Distribution (to deploy the registry v2) via the existing composable services in THT by using external_deploy_tasks maybe (or another interface). The idea is really to have the registry ready before actually deploying the undercloud containers, so we can modify them in the middle (run container-check in our case). -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Recap of Python 3 testing session at PTG
On Tue, Mar 20, 2018 at 10:28 AM, Javier Pena <jp...@redhat.com> wrote: > One point we should add here: to test Python 3 we need some base operating system to work on. For now, our plan is to create a set of stabilized Fedora 28 repositories and use them only for CI jobs. See [1] for details on this plan. Javier, Alfredo, where are we regarding this topic? Have we made some progress on f28 repos? I'm interested to know about the next steps, I really want us to make some progress on python3 testing here. Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] roadmap on containers workflow
On Thu, Apr 12, 2018 at 1:16 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: [...] > Deploy own registry as part of UC deployment or use external. For >> instance, for production use I would like to have a cluster of 3-5 >> registries with HAProxy in front to speed up 1k nodes deployments. >> > > Note that this implies HA undercloud as well. Although, given that HA > undercloud is goodness indeed, I would *not* invest time into reliable > container registry deployment architecture for undercloud as we'll have it > for free, once kubernetes/openshift control plane for openstack becomes > adopted. There is a very strong notion of build pipelines, reliable > containers registries et al. Right. HA undercloud is out of context now. -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
