[openstack-dev] [tripleo] Proposing Wesley Hayutin core on TripleO CI
Team, Wes has been consistently and heavily involved in TripleO CI work. He has a very well understanding on how tripleo-quickstart and tripleo-quickstart-extras work, his number and quality of reviews are excellent so far. His experience with testing TripleO is more than valuable. Also, he's always here to help on TripleO CI issues or just improvements (he's the guy filling bugs on a Saturday evening). I think he would be a good addition to the TripleO CI core team (tripleo-ci, t-q and t-q-e repos for now). Anyway, thanks a lot Wes for your hard work on CI, I think it's time to move on and get you +2 ;-) As usual, it's open for voting, feel free to bring any feedback. Thanks 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 - 1st Edition
Note: this is the first 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 or feedback are welcome. +--+ | Continuous Integration | +--+ +--> New rover is Sagi and new ruck is Matt. Please let them know any new CI issue. +--> Team will focus on developers reproduce CI jobs on their own RDO Cloud (https://trello.com/c/EWotWxGe) +--> Promotions look good so far: Master promoted 12/5/2017 - Pike promoted 12/2/2017 - Ocata promoted 12/4/2017 +--> Newton promotion job now handled by rdo-phase1 +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting +-+ | Upgrades | +-+ +--> Some experimental jobs are WIP to test Fast Forward Upgrades (aka FFU). Reviews are needed on https://review.rdoproject.org/r/#/c/10827 and https://review.openstack.org/#/q/topic:ffu/ci+(status:open+OR+status:merged). +--> Some work is being done to make upgrade jobs working from Ocata to Pike in RDO CI - and in the same time some bugs are being fixed regarding this upgrade path. +--> tripleo-upgrade upstream repository is being updated from the old repo, the team is working on it. +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status and https://etherpad.openstack.org/p/tripleo-upgrade-squad-meeting +---+ | Containers | +---+ +--> k8s: good progress on CI when deploying with Kubespray. +--> k8s: working on getting tempest working for ansible-role-k8s-* repos +--> k8s: migrated ansible-role-k8s-glance from external github under `openstack` +--> undercloud: some progress has been made but some bugs are currently under investigation (idempotency issues, Registry config, etc). +--> overcloud: work in progress on image prepare workflows +--> overcloud: Paunch now explicitly pulls images before docker run. +--> overcloud: we can now have the port in the image name and tag discover will still work fine. +--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status +--+ | Integration | +--+ +--> The team is working on Multiple Ceph clusters blueprint and Multiple Ceph pools for Cinder. +--> The team is preparing the integration to deploy Ceph Luminous! +--> Some backports are being done to resolve a CVE: https://review.openstack.org/#/q/topic:bug/1720787+(status:open+OR+status:merged) +--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status +-+ | UI/CLI | +-+ +--> Roles management ready for review on GUI side, waiting for tripleo-common patches to get finished. +--> Nodes registration refactoring merged. +--> The team is still working on testing Pike. +--> Layout changes and refactoring patchset merged +--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status +---+ | Validations | +---+ +--> The team has requested more review from TripleO developers, please help if you can! https://etherpad.openstack.org/p/validations-reviews +--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status +---+ | Networking | +---+ +--> In the last meeting, the team discussed about the future of os-net-config, routed-networks and OVS containerization. +--> In the next meeting, the team will discuss about how we can prepare nodes for NFV features and the state of tests for containerized deployments and networking. +--> Some folks are also focused on Octavia integration. +--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status +--+ | Workflows | +--+ +--> No update this week. +--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status ++ | Weekly Owl | ++ The Barn Owl (aka Tyto alba) is a medium sized owl with no ear-tufts and a heart-shaped face. These pale, nearly worldwide birds are closely associated with man through their traditional use of barn lofts and church steeples as nesting sites. The species name "alba" refers to the white color. Other names for the Barn Owl have included Monkey-faced Owl, Ghost Owl, and Church Owl. (source: https://www.owlpages.com/owls/species.php?s=10) 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] upstream OVB jobs - roadmap
Quick update on this topic: - ovb-ha is now running a strict minimum of services (Glance, Keystone, Nova, Neutron, Swift) and executes Tempest. - ovb-ha-ipv6 now works! patches are ready for review: https://review.openstack.org/#/q/topic:fs035+status:open the job deploy ipv6 network isolation, introspection, pacemaker on 3 controllers, containerized overcloud, TLS and it runs Tempest (shiny eh?). Thanks a lot to Sagi, Juan and reviewers who helped to make that effort. On Thu, Nov 23, 2017 at 2:44 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Thu, Nov 23, 2017 at 1:54 PM, Emilien Macchi <emil...@redhat.com> wrote: >> On Thu, Nov 23, 2017 at 1:49 PM, Emilien Macchi <emil...@redhat.com> wrote: >>> So far in my testing I found 2 issues: >>> >>> - IPv6 + TLS doesn't work in tripleo-ci, certificates aren't good >>> (expected). We might need to generate new ones, I'll take a look >>> myself probably. >>> >>> http://logs.openstack.org/18/522618/2/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq-ipv6/d21046c/logs/undercloud/home/zuul/overcloud_deploy_post.log.txt.gz#_2017-11-23_20_59_28 >> >> I just found out there is a test-environments/enable-tls-ipv6.yaml - >> beautiful. Problem solved I guess. >> >>> - Running Tempest on OVB jobs with TLS doesn't work for me yet: >>> >>> http://logs.openstack.org/10/522310/6/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq/ad6c2c1/logs/undercloud/home/zuul/tempest_output.log.txt.gz#_2017-11-23_21_03_57 >>> Any help on that one is welcome > > I sent https://review.openstack.org/522677 which I think is the way to > go, any feedback is welcome. > >>> Thanks, >>> >>> On Thu, Nov 23, 2017 at 11:37 AM, Emilien Macchi <emil...@redhat.com> wrote: >>>> I forgot to add an ongoing effort to reduce number of services >>>> deployed on ovb jobs at a strict minimum: >>>> https://review.openstack.org/522310 >>>> So we hope to run the job faster and more efficiently. Our scenarios >>>> already cover services like Cinder, Heat and Swift. We don't need them >>>> anymore on OVB. >>>> >>>> On Thu, Nov 23, 2017 at 10:59 AM, Emilien Macchi <emil...@redhat.com> >>>> wrote: >>>>> Queens's main theme is stabilization. >>>>> That's what we're currently working on in our CI, see which areas we >>>>> can consolidate and stabilize so we can continue to scale TripleO >>>>> development. >>>>> >>>>> One of the challenges that we had in the last years was the high >>>>> demand of OVB jobs versus the capacity. >>>>> To address that, we recently decided to remove ovb-nonha. It was a good >>>>> start. >>>>> >>>>> Now we have: >>>>> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) >>>>> - ovb-containers which tested a containerized overcloud >>>>> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from >>>>> ovb-updates and is supposed to test ipv6 overcloud, stack updates & >>>>> ceph. It doesn't test stack updates (since the switch to >>>>> tripleo-quickstart), and Ceph is already extensively tested in >>>>> multinode scenario001/004 jobs. >>>>> >>>>> That said, I think we can consolidate the OVB jobs in 2: >>>>> >>>>> - keep ovb-ha and containerize it in Queens and beyond: it was already >>>>> approved and change is being applied now: >>>>> https://review.openstack.org/#/c/522293/ >>>>> indeed, we decided as a community that we would stop supporting >>>>> non-containerized overclouds in Queens and beyond. >>>>> - remove ovb-containers in Queens and beyond: useless now, since we >>>>> have ovb-ha containerized: https://review.openstack.org/#/c/522579/ >>>>> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: >>>>> https://review.openstack.org/#/c/522618/ >>>>> indeed, ceph is already well tested in scenarios, ipv6 would be >>>>> tested in ovb-ha-ipv6. >>>>> for overcloud updates, I haven't seen the feature in quickstart but >>>>> I might have missed something (any help here is welcome). >>>>> >>>>> At the end, we should end up with 2 OVB jobs: >>>>> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) >>>>> - ovb-ha-ipv6 >>>>> >>>>> Both would
Re: [openstack-dev] [tripleo] rename ovb jobs?
Bogdan and Dmitry's suggestions are imho a bit too much and would lead to very very (very) long names... Do we actually want that? On Fri, Dec 1, 2017 at 2:02 AM, Sanjay Upadhyay <supad...@redhat.com> wrote: > > > On Fri, Dec 1, 2017 at 2:17 PM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >> >> On 11/30/17 8:11 PM, Emilien Macchi wrote: >>> >>> A few months ago, we renamed ovb-updates to be >>> tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024. >>> The name is much longer but it describes better what it's doing. >>> We know it's a job with one controller, one compute and one storage >>> node, deploying the quickstart featureset n°24. >>> >>> For consistency, I propose that we rename all OVB jobs this way. >>> For example, tripleo-ci-centos-7-ovb-ha-oooq would become >>> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001 >>> etc. >>> >>> Any thoughts / feedback before we proceed? >>> Before someone asks, I'm not in favor of renaming the multinode >>> scenarios now, because they became quite familiar now, and it would >>> confuse people to rename the jobs. >>> >>> Thanks, >>> >> >> I'd like to see featuresets clarified in names as well. Just to bring the >> main message, w/o going into the test matrix details, like >> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001-ovn/ceph/k8s/tempest >> whatever it is. >> > > How is this looking? > > tripleo-ci/os/centos/7/ovb/ha/nodes/3ctrlr_1comp.yaml > tripleo-ci/os/centos/7/ovb/ha/featureset/ovn_ceph_k8s_with-tempest.yaml > > I also think we should have clear demarcation of the oooq variables ie > machine specific goes to nodes/* and feature related goes to featureset/* > > regards > /sanjay > > >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando >> >> >> __ >> 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] rename ovb jobs?
A few months ago, we renamed ovb-updates to be tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024. The name is much longer but it describes better what it's doing. We know it's a job with one controller, one compute and one storage node, deploying the quickstart featureset n°24. For consistency, I propose that we rename all OVB jobs this way. For example, tripleo-ci-centos-7-ovb-ha-oooq would become tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001 etc. Any thoughts / feedback before we proceed? Before someone asks, I'm not in favor of renaming the multinode scenarios now, because they became quite familiar now, and it would confuse people to rename the jobs. 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 Ronelle Landy for Tripleo-Quickstart/Extras/CI core
On Wed, Nov 29, 2017 at 11:34 AM, John Trowbridge <tr...@redhat.com> wrote: > I would like to propose Ronelle be given +2 for the above repos. She has > been a solid contributor to tripleo-quickstart and extras almost since the > beginning. She has solid review numbers, but more importantly has always > done quality reviews. She also has been working in the very intense rover > role on the CI squad in the past CI sprint, and has done very well in that > role. solid +1 :-) Thanks for your work Ronelle! -- 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] [all] [tc] Community Goals for Rocky
Hi everyone, It's time to plan what goals we would like to achieve during the Rocky cycle. If you're not familiar with goals, I suggest this reading first: https://governance.openstack.org/tc/goals/ Chandan and Lance did an more-than-awesome work in championing the 2 goals for Queens cycle, I think we should continue to have goal champions in the future. This decision is currently under discussion here: https://review.openstack.org/#/c/510656/ Looking forward, it's time to discuss about the goals we want to work on during Rocky. As a reminder, the full list of proposed goals is documented here: https://etherpad.openstack.org/p/community-goals Based on our experience, we would like our goals to: - have at least one or multiple champions, who commit to work with the project teams so they know what to do in order to achieve the goal. The champion(s) aren't supposed (but free) to actually implement the goals. - be achievable in one cycle. A goal that isn't doable in 6 months is probably too wide and need to be split into smaller steps to achieve the goal. - meet OpenStack roadmap. There are some goals more urgent than others, we need to take that in consideration. With that said, the discussion is open. So far we already have one proposal: https://review.openstack.org/#/c/513875/ (Migration to Storyboard, championed by Kendall). Suggestions are welcome: - on the mailing-list, in a new thread per goal [all] [tc] Proposing goal XYZ for Rocky - on Gerrit in openstack/governance like Kendall did. 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] upstream OVB jobs - roadmap
On Mon, Nov 27, 2017 at 5:44 AM, Alfredo Moralejo Alonso <amora...@redhat.com> wrote: > > > On Thu, Nov 23, 2017 at 7:59 PM, Emilien Macchi <emil...@redhat.com> wrote: >> >> Queens's main theme is stabilization. >> That's what we're currently working on in our CI, see which areas we >> can consolidate and stabilize so we can continue to scale TripleO >> development. >> >> One of the challenges that we had in the last years was the high >> demand of OVB jobs versus the capacity. >> To address that, we recently decided to remove ovb-nonha. It was a good >> start. >> >> Now we have: >> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) >> - ovb-containers which tested a containerized overcloud >> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from >> ovb-updates and is supposed to test ipv6 overcloud, stack updates & >> ceph. It doesn't test stack updates (since the switch to >> tripleo-quickstart), and Ceph is already extensively tested in >> multinode scenario001/004 jobs. >> >> That said, I think we can consolidate the OVB jobs in 2: >> >> - keep ovb-ha and containerize it in Queens and beyond: it was already >> approved and change is being applied now: >> https://review.openstack.org/#/c/522293/ >> indeed, we decided as a community that we would stop supporting >> non-containerized overclouds in Queens and beyond. > > > We still have some multinode jobs running non-containerized deployment in > periodic pipeline (failing after https://review.openstack.org/#/c/518423/). > Should we remove these jobs? Yes and sorry if we missed it. >> >> - remove ovb-containers in Queens and beyond: useless now, since we >> have ovb-ha containerized: https://review.openstack.org/#/c/522579/ >> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: >> https://review.openstack.org/#/c/522618/ >> indeed, ceph is already well tested in scenarios, ipv6 would be >> tested in ovb-ha-ipv6. >> for overcloud updates, I haven't seen the feature in quickstart but >> I might have missed something (any help here is welcome). >> >> At the end, we should end up with 2 OVB jobs: >> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) >> - ovb-ha-ipv6 >> >> Both would test the things that can't be tested by multinode: >> - Nova / Ironic / Mistral workflow >> - Introspection >> - TLS >> - Network Isolation >> - IPv6 for the ovb-ha-ipv6 >> - Containerized overcloud >> >> As a result, we have more coverage (except for stack updates but it >> needs to be addressed in quickstart first) and less jobs, so less >> resources consumed. >> >> Any feedback on this plan is more than 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 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] upstream OVB jobs - roadmap
On Thu, Nov 23, 2017 at 1:54 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Thu, Nov 23, 2017 at 1:49 PM, Emilien Macchi <emil...@redhat.com> wrote: >> So far in my testing I found 2 issues: >> >> - IPv6 + TLS doesn't work in tripleo-ci, certificates aren't good >> (expected). We might need to generate new ones, I'll take a look >> myself probably. >> >> http://logs.openstack.org/18/522618/2/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq-ipv6/d21046c/logs/undercloud/home/zuul/overcloud_deploy_post.log.txt.gz#_2017-11-23_20_59_28 > > I just found out there is a test-environments/enable-tls-ipv6.yaml - > beautiful. Problem solved I guess. > >> - Running Tempest on OVB jobs with TLS doesn't work for me yet: >> >> http://logs.openstack.org/10/522310/6/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq/ad6c2c1/logs/undercloud/home/zuul/tempest_output.log.txt.gz#_2017-11-23_21_03_57 >> Any help on that one is welcome I sent https://review.openstack.org/522677 which I think is the way to go, any feedback is welcome. >> Thanks, >> >> On Thu, Nov 23, 2017 at 11:37 AM, Emilien Macchi <emil...@redhat.com> wrote: >>> I forgot to add an ongoing effort to reduce number of services >>> deployed on ovb jobs at a strict minimum: >>> https://review.openstack.org/522310 >>> So we hope to run the job faster and more efficiently. Our scenarios >>> already cover services like Cinder, Heat and Swift. We don't need them >>> anymore on OVB. >>> >>> On Thu, Nov 23, 2017 at 10:59 AM, Emilien Macchi <emil...@redhat.com> wrote: >>>> Queens's main theme is stabilization. >>>> That's what we're currently working on in our CI, see which areas we >>>> can consolidate and stabilize so we can continue to scale TripleO >>>> development. >>>> >>>> One of the challenges that we had in the last years was the high >>>> demand of OVB jobs versus the capacity. >>>> To address that, we recently decided to remove ovb-nonha. It was a good >>>> start. >>>> >>>> Now we have: >>>> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) >>>> - ovb-containers which tested a containerized overcloud >>>> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from >>>> ovb-updates and is supposed to test ipv6 overcloud, stack updates & >>>> ceph. It doesn't test stack updates (since the switch to >>>> tripleo-quickstart), and Ceph is already extensively tested in >>>> multinode scenario001/004 jobs. >>>> >>>> That said, I think we can consolidate the OVB jobs in 2: >>>> >>>> - keep ovb-ha and containerize it in Queens and beyond: it was already >>>> approved and change is being applied now: >>>> https://review.openstack.org/#/c/522293/ >>>> indeed, we decided as a community that we would stop supporting >>>> non-containerized overclouds in Queens and beyond. >>>> - remove ovb-containers in Queens and beyond: useless now, since we >>>> have ovb-ha containerized: https://review.openstack.org/#/c/522579/ >>>> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: >>>> https://review.openstack.org/#/c/522618/ >>>> indeed, ceph is already well tested in scenarios, ipv6 would be >>>> tested in ovb-ha-ipv6. >>>> for overcloud updates, I haven't seen the feature in quickstart but >>>> I might have missed something (any help here is welcome). >>>> >>>> At the end, we should end up with 2 OVB jobs: >>>> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) >>>> - ovb-ha-ipv6 >>>> >>>> Both would test the things that can't be tested by multinode: >>>> - Nova / Ironic / Mistral workflow >>>> - Introspection >>>> - TLS >>>> - Network Isolation >>>> - IPv6 for the ovb-ha-ipv6 >>>> - Containerized overcloud >>>> >>>> As a result, we have more coverage (except for stack updates but it >>>> needs to be addressed in quickstart first) and less jobs, so less >>>> resources consumed. >>>> >>>> Any feedback on this plan is more than welcome, >>>> -- >>>> Emilien Macchi >>> >>> >>> >>> -- >>> Emilien Macchi >> >> >> >> -- >> Emilien Macchi > > > > -- > 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] upstream OVB jobs - roadmap
On Thu, Nov 23, 2017 at 1:49 PM, Emilien Macchi <emil...@redhat.com> wrote: > So far in my testing I found 2 issues: > > - IPv6 + TLS doesn't work in tripleo-ci, certificates aren't good > (expected). We might need to generate new ones, I'll take a look > myself probably. > > http://logs.openstack.org/18/522618/2/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq-ipv6/d21046c/logs/undercloud/home/zuul/overcloud_deploy_post.log.txt.gz#_2017-11-23_20_59_28 I just found out there is a test-environments/enable-tls-ipv6.yaml - beautiful. Problem solved I guess. > - Running Tempest on OVB jobs with TLS doesn't work for me yet: > > http://logs.openstack.org/10/522310/6/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq/ad6c2c1/logs/undercloud/home/zuul/tempest_output.log.txt.gz#_2017-11-23_21_03_57 > Any help on that one is welcome > > Thanks, > > On Thu, Nov 23, 2017 at 11:37 AM, Emilien Macchi <emil...@redhat.com> wrote: >> I forgot to add an ongoing effort to reduce number of services >> deployed on ovb jobs at a strict minimum: >> https://review.openstack.org/522310 >> So we hope to run the job faster and more efficiently. Our scenarios >> already cover services like Cinder, Heat and Swift. We don't need them >> anymore on OVB. >> >> On Thu, Nov 23, 2017 at 10:59 AM, Emilien Macchi <emil...@redhat.com> wrote: >>> Queens's main theme is stabilization. >>> That's what we're currently working on in our CI, see which areas we >>> can consolidate and stabilize so we can continue to scale TripleO >>> development. >>> >>> One of the challenges that we had in the last years was the high >>> demand of OVB jobs versus the capacity. >>> To address that, we recently decided to remove ovb-nonha. It was a good >>> start. >>> >>> Now we have: >>> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) >>> - ovb-containers which tested a containerized overcloud >>> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from >>> ovb-updates and is supposed to test ipv6 overcloud, stack updates & >>> ceph. It doesn't test stack updates (since the switch to >>> tripleo-quickstart), and Ceph is already extensively tested in >>> multinode scenario001/004 jobs. >>> >>> That said, I think we can consolidate the OVB jobs in 2: >>> >>> - keep ovb-ha and containerize it in Queens and beyond: it was already >>> approved and change is being applied now: >>> https://review.openstack.org/#/c/522293/ >>> indeed, we decided as a community that we would stop supporting >>> non-containerized overclouds in Queens and beyond. >>> - remove ovb-containers in Queens and beyond: useless now, since we >>> have ovb-ha containerized: https://review.openstack.org/#/c/522579/ >>> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: >>> https://review.openstack.org/#/c/522618/ >>> indeed, ceph is already well tested in scenarios, ipv6 would be >>> tested in ovb-ha-ipv6. >>> for overcloud updates, I haven't seen the feature in quickstart but >>> I might have missed something (any help here is welcome). >>> >>> At the end, we should end up with 2 OVB jobs: >>> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) >>> - ovb-ha-ipv6 >>> >>> Both would test the things that can't be tested by multinode: >>> - Nova / Ironic / Mistral workflow >>> - Introspection >>> - TLS >>> - Network Isolation >>> - IPv6 for the ovb-ha-ipv6 >>> - Containerized overcloud >>> >>> As a result, we have more coverage (except for stack updates but it >>> needs to be addressed in quickstart first) and less jobs, so less >>> resources consumed. >>> >>> Any feedback on this plan is more than welcome, >>> -- >>> Emilien Macchi >> >> >> >> -- >> Emilien Macchi > > > > -- > 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] upstream OVB jobs - roadmap
So far in my testing I found 2 issues: - IPv6 + TLS doesn't work in tripleo-ci, certificates aren't good (expected). We might need to generate new ones, I'll take a look myself probably. http://logs.openstack.org/18/522618/2/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq-ipv6/d21046c/logs/undercloud/home/zuul/overcloud_deploy_post.log.txt.gz#_2017-11-23_20_59_28 - Running Tempest on OVB jobs with TLS doesn't work for me yet: http://logs.openstack.org/10/522310/6/check-tripleo/tripleo-ci-centos-7-ovb-ha-oooq/ad6c2c1/logs/undercloud/home/zuul/tempest_output.log.txt.gz#_2017-11-23_21_03_57 Any help on that one is welcome Thanks, On Thu, Nov 23, 2017 at 11:37 AM, Emilien Macchi <emil...@redhat.com> wrote: > I forgot to add an ongoing effort to reduce number of services > deployed on ovb jobs at a strict minimum: > https://review.openstack.org/522310 > So we hope to run the job faster and more efficiently. Our scenarios > already cover services like Cinder, Heat and Swift. We don't need them > anymore on OVB. > > On Thu, Nov 23, 2017 at 10:59 AM, Emilien Macchi <emil...@redhat.com> wrote: >> Queens's main theme is stabilization. >> That's what we're currently working on in our CI, see which areas we >> can consolidate and stabilize so we can continue to scale TripleO >> development. >> >> One of the challenges that we had in the last years was the high >> demand of OVB jobs versus the capacity. >> To address that, we recently decided to remove ovb-nonha. It was a good >> start. >> >> Now we have: >> - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) >> - ovb-containers which tested a containerized overcloud >> - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from >> ovb-updates and is supposed to test ipv6 overcloud, stack updates & >> ceph. It doesn't test stack updates (since the switch to >> tripleo-quickstart), and Ceph is already extensively tested in >> multinode scenario001/004 jobs. >> >> That said, I think we can consolidate the OVB jobs in 2: >> >> - keep ovb-ha and containerize it in Queens and beyond: it was already >> approved and change is being applied now: >> https://review.openstack.org/#/c/522293/ >> indeed, we decided as a community that we would stop supporting >> non-containerized overclouds in Queens and beyond. >> - remove ovb-containers in Queens and beyond: useless now, since we >> have ovb-ha containerized: https://review.openstack.org/#/c/522579/ >> - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: >> https://review.openstack.org/#/c/522618/ >> indeed, ceph is already well tested in scenarios, ipv6 would be >> tested in ovb-ha-ipv6. >> for overcloud updates, I haven't seen the feature in quickstart but >> I might have missed something (any help here is welcome). >> >> At the end, we should end up with 2 OVB jobs: >> - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) >> - ovb-ha-ipv6 >> >> Both would test the things that can't be tested by multinode: >> - Nova / Ironic / Mistral workflow >> - Introspection >> - TLS >> - Network Isolation >> - IPv6 for the ovb-ha-ipv6 >> - Containerized overcloud >> >> As a result, we have more coverage (except for stack updates but it >> needs to be addressed in quickstart first) and less jobs, so less >> resources consumed. >> >> Any feedback on this plan is more than welcome, >> -- >> Emilien Macchi > > > > -- > 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] upstream OVB jobs - roadmap
I forgot to add an ongoing effort to reduce number of services deployed on ovb jobs at a strict minimum: https://review.openstack.org/522310 So we hope to run the job faster and more efficiently. Our scenarios already cover services like Cinder, Heat and Swift. We don't need them anymore on OVB. On Thu, Nov 23, 2017 at 10:59 AM, Emilien Macchi <emil...@redhat.com> wrote: > Queens's main theme is stabilization. > That's what we're currently working on in our CI, see which areas we > can consolidate and stabilize so we can continue to scale TripleO > development. > > One of the challenges that we had in the last years was the high > demand of OVB jobs versus the capacity. > To address that, we recently decided to remove ovb-nonha. It was a good start. > > Now we have: > - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) > - ovb-containers which tested a containerized overcloud > - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from > ovb-updates and is supposed to test ipv6 overcloud, stack updates & > ceph. It doesn't test stack updates (since the switch to > tripleo-quickstart), and Ceph is already extensively tested in > multinode scenario001/004 jobs. > > That said, I think we can consolidate the OVB jobs in 2: > > - keep ovb-ha and containerize it in Queens and beyond: it was already > approved and change is being applied now: > https://review.openstack.org/#/c/522293/ > indeed, we decided as a community that we would stop supporting > non-containerized overclouds in Queens and beyond. > - remove ovb-containers in Queens and beyond: useless now, since we > have ovb-ha containerized: https://review.openstack.org/#/c/522579/ > - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: > https://review.openstack.org/#/c/522618/ > indeed, ceph is already well tested in scenarios, ipv6 would be > tested in ovb-ha-ipv6. > for overcloud updates, I haven't seen the feature in quickstart but > I might have missed something (any help here is welcome). > > At the end, we should end up with 2 OVB jobs: > - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) > - ovb-ha-ipv6 > > Both would test the things that can't be tested by multinode: > - Nova / Ironic / Mistral workflow > - Introspection > - TLS > - Network Isolation > - IPv6 for the ovb-ha-ipv6 > - Containerized overcloud > > As a result, we have more coverage (except for stack updates but it > needs to be addressed in quickstart first) and less jobs, so less > resources consumed. > > Any feedback on this plan is more than 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] upstream OVB jobs - roadmap
Queens's main theme is stabilization. That's what we're currently working on in our CI, see which areas we can consolidate and stabilize so we can continue to scale TripleO development. One of the challenges that we had in the last years was the high demand of OVB jobs versus the capacity. To address that, we recently decided to remove ovb-nonha. It was a good start. Now we have: - ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics) - ovb-containers which tested a containerized overcloud - ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from ovb-updates and is supposed to test ipv6 overcloud, stack updates & ceph. It doesn't test stack updates (since the switch to tripleo-quickstart), and Ceph is already extensively tested in multinode scenario001/004 jobs. That said, I think we can consolidate the OVB jobs in 2: - keep ovb-ha and containerize it in Queens and beyond: it was already approved and change is being applied now: https://review.openstack.org/#/c/522293/ indeed, we decided as a community that we would stop supporting non-containerized overclouds in Queens and beyond. - remove ovb-containers in Queens and beyond: useless now, since we have ovb-ha containerized: https://review.openstack.org/#/c/522579/ - Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6: https://review.openstack.org/#/c/522618/ indeed, ceph is already well tested in scenarios, ipv6 would be tested in ovb-ha-ipv6. for overcloud updates, I haven't seen the feature in quickstart but I might have missed something (any help here is welcome). At the end, we should end up with 2 OVB jobs: - ovb-ha (could be renamed in ovb-ha-ipv4 if that helps) - ovb-ha-ipv6 Both would test the things that can't be tested by multinode: - Nova / Ironic / Mistral workflow - Introspection - TLS - Network Isolation - IPv6 for the ovb-ha-ipv6 - Containerized overcloud As a result, we have more coverage (except for stack updates but it needs to be addressed in quickstart first) and less jobs, so less resources consumed. Any feedback on this plan is more than 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
Re: [openstack-dev] [Release-job-failures] Release of openstack/tripleo-ui failed
On Wed, Nov 22, 2017 at 7:50 AM, Sean McGinnis <sean.mcgin...@gmail.com> wrote: > I just put up a patch to fix the failing job: > > https://review.openstack.org/#/c/522284/ > > Are you saying it was redundant though? I was just wondering if we actually need this post-release job. But I'll let the tripleo-ui maintainers to answer that question. > > > On Wed, Nov 22, 2017 at 9:43 AM, Emilien Macchi <emil...@redhat.com> wrote: >> >> Yeah, I confirm we were able to build an RPM and release a new version >> of TripleO UI, which was our goal. I guess we can remove the >> flacky/failing job. >> >> On Wed, Nov 22, 2017 at 3:54 AM, Honza Pokorny <ho...@redhat.com> wrote: >> > I'm investigating on behalf of the tripleo-ui team. It looks like the >> > definition for the jobs changed under us, and we'll need to update our >> > configuration. I'll track it down. >> > >> > For the time being, though, we can safely ignore this issue. As >> > indicated, the publish-openstack-javascript-tarball job succeeded. I >> > checked the tarballs listing, and the file is in fact present. Our >> > project doesn't produce any other release artifacts upstream. >> > >> > Please direct any future failures to me (in addition to the mailing list >> > of course) >> > >> > Thanks >> > >> > Honza Pokorny >> > >> > On 2017-11-21 21:34, Emilien Macchi wrote: >> >> Indeed, adding Jason in copy. >> >> >> >> Do we actually need release-openstack-javascript job? >> >> >> >> On Tue, Nov 21, 2017 at 8:27 PM, Tony Breeds <t...@bakeyournoodle.com> >> >> wrote: >> >> > On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote: >> >> >> Build failed. >> >> >> >> >> >> - publish-openstack-javascript-tarball >> >> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/ >> >> >> : SUCCESS in 4m 58s >> >> >> - release-openstack-javascript >> >> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/ >> >> >> : POST_FAILURE in 6m 37s >> >> >> - announce-release announce-release : SKIPPED >> >> > >> >> > I'm not certain what went wrong here but [1] looks problematic >> >> > >> >> > Yours Tony. >> >> > >> >> > [1] >> >> > http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499 >> >> > >> >> > ___ >> >> > Release-job-failures mailing list >> >> > release-job-failu...@lists.openstack.org >> >> > >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >> >> >> >> >> >> >> >> -- >> >> 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 >> >> >> >> -- >> Emilien Macchi >> >> ___ >> Release-job-failures mailing list >> release-job-failu...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > > > > ___ > Release-job-failures mailing list > release-job-failu...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- 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] [Release-job-failures] Release of openstack/tripleo-ui failed
Yeah, I confirm we were able to build an RPM and release a new version of TripleO UI, which was our goal. I guess we can remove the flacky/failing job. On Wed, Nov 22, 2017 at 3:54 AM, Honza Pokorny <ho...@redhat.com> wrote: > I'm investigating on behalf of the tripleo-ui team. It looks like the > definition for the jobs changed under us, and we'll need to update our > configuration. I'll track it down. > > For the time being, though, we can safely ignore this issue. As > indicated, the publish-openstack-javascript-tarball job succeeded. I > checked the tarballs listing, and the file is in fact present. Our > project doesn't produce any other release artifacts upstream. > > Please direct any future failures to me (in addition to the mailing list > of course) > > Thanks > > Honza Pokorny > > On 2017-11-21 21:34, Emilien Macchi wrote: >> Indeed, adding Jason in copy. >> >> Do we actually need release-openstack-javascript job? >> >> On Tue, Nov 21, 2017 at 8:27 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: >> > On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote: >> >> Build failed. >> >> >> >> - publish-openstack-javascript-tarball >> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/ >> >> : SUCCESS in 4m 58s >> >> - release-openstack-javascript >> >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/ >> >> : POST_FAILURE in 6m 37s >> >> - announce-release announce-release : SKIPPED >> > >> > I'm not certain what went wrong here but [1] looks problematic >> > >> > Yours Tony. >> > >> > [1] >> > http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499 >> > >> > ___ >> > Release-job-failures mailing list >> > release-job-failu...@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >> >> >> >> -- >> 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 -- 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] [ec2api] legacy-functional-neutron-dsvm-ec2api on stable/pike looks broken
I'm trying to backport zuulv3 layout in ec2api but it seems like the gate is broken: https://review.openstack.org/#/c/521592/ Bringing it here for visibility, hopefully someone from the project can have a look. 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] [Release-job-failures] Release of openstack/tripleo-ui failed
Indeed, adding Jason in copy. Do we actually need release-openstack-javascript job? On Tue, Nov 21, 2017 at 8:27 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Wed, Nov 22, 2017 at 03:07:33AM +, z...@openstack.org wrote: >> Build failed. >> >> - publish-openstack-javascript-tarball >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/publish-openstack-javascript-tarball/9908482/ >> : SUCCESS in 4m 58s >> - release-openstack-javascript >> http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/ >> : POST_FAILURE in 6m 37s >> - announce-release announce-release : SKIPPED > > I'm not certain what went wrong here but [1] looks problematic > > Yours Tony. > > [1] > http://logs.openstack.org/e5/e5831f230bd29516dc202eb406270604f27e27f9/release/release-openstack-javascript/95af4ef/job-output.txt.gz#_2017-11-22_03_01_48_750499 > > ___ > Release-job-failures mailing list > release-job-failu...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures -- 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] Planning for job execution outside the gate with Zuul v3
On Mon, Nov 20, 2017 at 2:31 PM, David Moreau Simard <d...@redhat.com> wrote: > Hi, > > As the migration of review.rdoproject.org to Zuul v3 draws closer, I'd like > to open up the discussion around how we want to approach an eventual > migration to Zuul v3 outside the gate. > I'd like to take this opportunity to allow ourselves to think outside the > box, think about how we would like to shape the CI of TripleO from upstream > to the product and then iterate to reach that goal. > > The reason why I mention "outside the gate" is because one of the features > of Zuul v3 is to dynamically construct its configuration by including > different repositories. > For example, the Zuul v3 from review.rdoproject.org can selectively include > parts of git.openstack.org/openstack-infra/tripleo-ci [1] and it will load > the configuration found there for jobs, nodesets, projects, etc. > > This opens a great deal of opportunities for sharing content or centralizing > the different playbooks, roles and job parameters in one single repository > rather than spread across different repositories across the production > chain. > If we do things right, this could give us the ability to run the same jobs > (which can be customized with parameters depending on the environment, > release, scenario, etc.) from the upstream gate down to > review.rdoproject.org and the later productization steps. > > There's pros and cons to the idea, but this is just an example of what we > can do with Zuul v3. > > Another example of an interesting thought from Sagi is to boot virtual > machines directly with pre-built images instead of installing the > undercloud/overcloud every time. > Something else to think about is how can we leverage all the Ansible things > from TripleO Quickstart in Zuul v3 natively. > > There's of course constraints about what we can and can't do in the upstream > gate... but let's avoid prematurely blocking ourselves and try to think > about what we want to do ideally and figure out if, and how, we can do it. > Whether it's about the things that we would like to do, can't do, or the > things that don't work, I'm sure the feedback and outcome of this could > prove useful to improve Zuul. > > How would everyone like to proceed ? Should we start an etherpad ? Do some > "design dession" meetings ? > I'm willing to help get the ball rolling and spearhead the effort but this > is a community effort :) It's good you started this thread, I had a discussion with Sam Doran (on PTO this week AFIK) who is highly invested in Ansible and motivated to help to have proper playbooks calling tripleo-quickstart-extras roles. One of the ideas that we discussed was to remove toci_gate_* scripts and write Ansible playbooks that call the right modules with the right variables. +1 for an etherpad and start planning this work. > Thanks ! > > [1]: http://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/zuul.d > > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] -- 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] Migrating TripleO CI in-tree tomorrow - please README
Quick update - our plan worked quite well. https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 Here's what has been done: - Migrate most of TripleO projects to zuul layout in-tree + backports to stable branches. - Some projects have broken gate and I plan to take a look on Monday - any help is welcome. - I pushed patches in OpenStack projects where TripleO jobs were running, waiting for review. - Alex and I made scenario001 and 003 non voting due to instabilities. We really need help on these ones (see alerts on #tripleo). Next steps: - Fix gate issue to merge the rest of zuulv3 migration patches - Start planning work to convert legacy playbooks into proper Ansible tasks, and re-using quickstart modules. If you notice any issue or strange thing please let us know. Thanks, On Fri, Nov 17, 2017 at 7:18 AM, Alex Schultz <aschu...@redhat.com> wrote: > On Thu, Nov 16, 2017 at 11:20 AM, Emilien Macchi <emil...@redhat.com> wrote: >> TL;DR: don't approve or recheck any tripleo patch from now, until >> further notice on this thread. >> >> Some good progress has been made on migrating legacy tripleo CI jobs >> to be in-tree: >> https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 >> >> The next steps: >> - Let the current gate to finish their jobs running. >> - Stop approving patches from now, and wait the gate to be done and cleared >> - Alex and I will approve the migration patches tomorrow and we hope >> to have them in the gate by Friday afternoon (US time) when gate isn't >> busy anymore. We'll also have to backport them all. > > They have been pushed to the gate. There are a few patches in front of > them before they will hit. please do not approve anything until the v3 > cut over lands as you'll end up with double the amount of jobs running > on your gate patches until the project-config change lands. > > Thanks, > -Alex > > >> - When these patches will be merged (it might take the weekend to >> land, depending how the gate will be), we'll run duplicated jobs until >> https://review.openstack.org/514778 is merged. I'll try to ping >> someone from Infra over the week-end if we can land it, that would be >> great. >> - Once https://review.openstack.org/514778 is merged, people are free >> to do recheck or approve any patches. We hope it should happen over >> the weekend. >> - I'll continue to migrate all other tripleo projects to have in-tree >> layout. On the list: t-p-e, t-i-e, paunch, os-*-config, >> tripleo-validations. >> >> 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 > > __________ > 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] Migrating TripleO CI in-tree tomorrow - please README
TL;DR: don't approve or recheck any tripleo patch from now, until further notice on this thread. Some good progress has been made on migrating legacy tripleo CI jobs to be in-tree: https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 The next steps: - Let the current gate to finish their jobs running. - Stop approving patches from now, and wait the gate to be done and cleared - Alex and I will approve the migration patches tomorrow and we hope to have them in the gate by Friday afternoon (US time) when gate isn't busy anymore. We'll also have to backport them all. - When these patches will be merged (it might take the weekend to land, depending how the gate will be), we'll run duplicated jobs until https://review.openstack.org/514778 is merged. I'll try to ping someone from Infra over the week-end if we can land it, that would be great. - Once https://review.openstack.org/514778 is merged, people are free to do recheck or approve any patches. We hope it should happen over the weekend. - I'll continue to migrate all other tripleo projects to have in-tree layout. On the list: t-p-e, t-i-e, paunch, os-*-config, tripleo-validations. 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] Nominate chem and matbu for tripleo-core !
On Thu, Nov 16, 2017 at 2:31 AM, Marios Andreou <mandr...@redhat.com> wrote: [...] > I'll ping alex when he's online later to check that chem and matbu are added > to the right launchpad and gerrit groups. Note: we accept anyone willing to do self triage in Launchpad group, not only cores. If you can't self triage a bug in Launchpad, please let us know and we'll fix it, even if you're not core. The URL to do it is: https://launchpad.net/~tripleo-drivers/+addmember For Gerrit, I took care of 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] [tripleo] removing zuul v3 legacy jobs
Some progress today: https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3+(status:open+OR+status:merged) - TripleO UI switched to new jobs - tripleo-ci has playbooks, jobs and templates ready for review - THT and puppet-tripleo has project layout ready for review Next by order: tripleo-common, python-tripleoclient, instack-undercloud, t-q and t-q-e, all other tripleo projects. Any help in review this work is welcome. So far tests are running fine now, sounds like good progress so far. Note: this is a first migration step. Of course in the future we'll think about how we can "ansiblelize" the tasks and optimize things. But before that, we need to migrate and do this first step now. Thanks, On Tue, Nov 14, 2017 at 4:18 PM, Emilien Macchi <emil...@redhat.com> wrote: > Hi, > > I'm working on migrating all TripleO CI jobs to be in-tree, I'm also > refactoring the layout and do some cleanup. > It's a bit of work, that can be followed here: > https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 > > The only thing I ask from our team is to let me know any change in > project-config & zuul layout, so we can update my work in tripleo-ci > patch, otherwise it will be lost when we land the patches. > > 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
Re: [openstack-dev] [tripleo] removing zuul v3 legacy jobs
On Tue, Nov 14, 2017 at 11:44 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2017-11-15 01:18, Emilien Macchi wrote:
>> Hi,
>>
>> I'm working on migrating all TripleO CI jobs to be in-tree, I'm also
>> refactoring the layout and do some cleanup.
>
> Please don't move *all* in tree - only the legacy ones. There's a
> specific set of jobs we (infra, release team) like to keep in
> project-config, see
> https://docs.openstack.org/infra/manual/zuulv3.html#what-not-to-convert
Yes, sorry for confusion, I'm only working on legacy jobs.
>> It's a bit of work, that can be followed here:
>> https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3
>>
>> The only thing I ask from our team is to let me know any change in
>> project-config & zuul layout, so we can update my work in tripleo-ci
>> patch, otherwise it will be lost when we land the patches.
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __
> 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] removing zuul v3 legacy jobs
Hi, I'm working on migrating all TripleO CI jobs to be in-tree, I'm also refactoring the layout and do some cleanup. It's a bit of work, that can be followed here: https://review.openstack.org/#/q/topic:tripleo/migrate-to-zuulv3 The only thing I ask from our team is to let me know any change in project-config & zuul layout, so we can update my work in tripleo-ci patch, otherwise it will be lost when we land the patches. 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] Nominate chem and matbu for tripleo-core !
On Thu, Nov 9, 2017 at 7:44 PM, Marios Andreou <mandr...@redhat.com> wrote: > Hello fellow owls, > > I would like to nominate (and imo these are both long overdue already): > > Sofer Athlan Guyot (chem) and > > Mathieu Bultel (matbu) > > to tripleo-core. They have both made many many core contributions to the > upgrades & updates over the last 3 cycles touching many of the tripleo repos > (tripleo-heat-templates, tripleo-common, python-tripleoclient, tripleo-ci, > tripleo-docs and others tripleo-quickstart/extras too unless am mistaken). Yes, +2. Mathieu and Sofer have been highly involved in TripleO, and have an excellent understanding on how things work. They would be an great addition to the core team, without any doubt. > IMO their efforts and contributions are invaluable for the upgrades squad > (and beyond - see openstack overcloud config download for example) and we > will be very lucky to have them as fully voting cores. > > Please vote with +1 or -1 for either or both chem and matbu - I'll keep it > open for a week as customary, Thanks Marios for proposing them :-) And Merci Sofer & Mathieu for your 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] Proposing John Fulton core on TripleO
Of course +1, thanks for your hard work! Stay awesome. --- Emilien Macchi On Nov 9, 2017 4:58 PM, "Marios Andreou" <mandr...@redhat.com> wrote: > > > On Thu, Nov 9, 2017 at 12:24 AM, Giulio Fidente <gfide...@redhat.com> > wrote: > >> Hi, >> >> I would like to propose John Fulton core on TripleO. >> >> I think John did an awesome work during the Pike cycle around the >> integration of ceph-ansible as a replacement for puppet-ceph, for the >> deployment of Ceph in containers. >> >> I think John has good understanding of many different parts of TripleO >> given that the ceph-ansible integration has been a complicated effort >> involving changes in heat/tht/mistral workflows/ci and last but not >> least, docs and he is more recently getting busier with reviews outside >> his main comfort zone. >> >> I am sure John would be a great addition to the team and I welcome him >> first to tune into radioparadise with the rest of us when joining #tripleo >> >> Feedback is welcomed! >> > > +1 > > >> -- >> Giulio Fidente >> GPG KEY: 08D733BA >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > __ 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]
On Wed, Nov 8, 2017 at 9:54 AM, Wesley Hayutin <whayu...@redhat.com> wrote: [...] > There are already several upgrade jobs defined in the experimental queue > that can be triggered with "check rdo experimental" > Let's iterate on those, and then make them full 3rd party check jobs. > We talked about allowing rdo sf to -2 reviews upstream as well which would > be handy. LGTM. Thanks for the clarification. -- 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]
On Wed, Nov 8, 2017 at 9:29 AM, Wesley Hayutin <whayu...@redhat.com> wrote: > Greetings, > > I'd like to propose we remove the upgrade jobs that are consistently failing > from the upstream infrastructure and instead focus our efforts in RDO > Software Factory. > > The jobs listed in https://review.openstack.org/#/c/518405/ are consistently > failing after being reviewed by myself and Mathieu. I am leaving > legacy-tripleo-ci-centos-7-multinode-upgrades in place as it's passing with > an overall rate of 87%. > > It doesn't make any sense to continue to tax upstream resources on failing > jobs, lets get the jobs running correctly and consistently in rdo software > factory before moving these back to our mainline CI. > > Please let me know what you think of the proposal. +1 to remove them if we have the scenario upgrades (with parity from what we had upstream) in RDO CI. We'll need to make the job experimental in RDO CI, so we can only run them at demand until they actually work. Can we do that as well? 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 in Queens
On Wed, Nov 8, 2017 at 3:30 AM, James Slagle <james.sla...@gmail.com> wrote: > On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi <emil...@redhat.com> wrote: >> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@redhat.com> wrote: >> [...] >> >>> -CI resources: better use of CI resources. At the PTG we received >>> feedback from the OpenStack infrastructure team that our upstream CI >>> resource usage is quite high at times (even as high as 50% of the >>> total). Because of the shared framework and single node capabilities we >>> can re-architecture much of our upstream CI matrix around single node. >>> We no longer require multinode jobs to be able to test many of the >>> services in tripleo-heat-templates... we can just use a single cloud VM >>> instead. We'll still want multinode undercloud -> overcloud jobs for >>> testing things like HA and baremetal provisioning. But we can cover a >>> large set of the services (in particular many of the new scenario jobs >>> we added in Pike) with single node CI test runs in much less time. >> >> After the last (terrible) weeks in CI, it's pretty clear we need to >> find a solution to reduce and optimize our testing. >> I'm now really convinced by switching our current scenarios jobs to >> NOT deploy the overcloud, and just an undercloud with composable >> services & run tempest. > > +1 if you mean just the scenarios. Yes, just scenarios. > I think we need to keep at least 1 multinode job voting that deploys > the overcloud, probably containers-multinode. Yes, exactly, and also work on optimizing OVB jobs (maybe just keep one or 2 jobs, instead 3). >> Benefits: >> - deploy 1 node instead of 2 nodes, so we save nodepool resources >> - faster (no overcloud) >> - reduce gate queue time, faster development process, faster CI >> >> Challenges: >> - keep overcloud testing, with OVB > > This is why I'm not sure what you're proposing. Do you mean switch all > multinode jobs to be just an undercloud, or just the scenarios? Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be tested with multinode though but well). >> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic >> containerized services on overcloud. >> >> I really want to get consensus on these points, please raise your >> voice now before we engage some work on that front. > > I'm fine to optimize the scenarios to be undercloud driven, but feel > we still need a multinode job that deploys the overcloud in the gate. > Otherwise, we'll have nothing that deploys an overcloud in the gate, > which is a step in the wrong direction imo. Primarily, b/c of the loss > of coverage around mistral and all of our workflows. Perhaps down the > road we could find ways to optimize that by using an ephemeral Mistral > (similar to the ephemeral Heat container), and then use a single node, > but we're not there yet. > > On the other hand, if the goal is just to test less upstream so that > we can more quickly merge code, then *not* deploying an overcloud in > the gate at all seems to fit that goal. Is that what you're after? Yes. Thanks for reformulate with better words. Just to be clear, I want to transform the scenarios into single-node jobs that deploy the SAME services (using composable services) from the undercloud, using the new ansible installer. I also want to keep running Tempest. And of course, like we said, keep one multinode job to test overcloud workflow, and OVB with some adjustments. Is it good? 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 in Queens
I took an action to remove scenarios/baremetal jobs on pike/master: https://review.openstack.org/518210 I think it's a good step forward cleaning things up and saving CI resources. I also think we should keep one multinode/baremetal job on pike (and probably ovb), and kill all baremetal jobs in master. That would be the next iteration I guess. Any feedback is welcome, On Mon, Nov 6, 2017 at 6:22 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin <whayu...@redhat.com> wrote: >> >> >> On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >>> >>> On 11/6/17 1:01 AM, Emilien Macchi wrote: >>>> >>>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@redhat.com> wrote: >>>> [...] >>>> >>>>> -CI resources: better use of CI resources. At the PTG we received >>>>> feedback from the OpenStack infrastructure team that our upstream CI >>>>> resource usage is quite high at times (even as high as 50% of the >>>>> total). Because of the shared framework and single node capabilities we >>>>> can re-architecture much of our upstream CI matrix around single node. >>>>> We no longer require multinode jobs to be able to test many of the >>>>> services in tripleo-heat-templates... we can just use a single cloud VM >>>>> instead. We'll still want multinode undercloud -> overcloud jobs for >>>>> testing things like HA and baremetal provisioning. But we can cover a >>>>> large set of the services (in particular many of the new scenario jobs >>>>> we added in Pike) with single node CI test runs in much less time. >>>> >>>> >>>> After the last (terrible) weeks in CI, it's pretty clear we need to >>>> find a solution to reduce and optimize our testing. >>>> I'm now really convinced by switching our current scenarios jobs to >>>> NOT deploy the overcloud, and just an undercloud with composable >>>> services & run tempest. >>> >>> >>> +1 >>> And we should start using the quickstart-extras undercloud-reploy role for >>> that. >>> >>>> >>>> Benefits: >>>> - deploy 1 node instead of 2 nodes, so we save nodepool resources >>>> - faster (no overcloud) >>>> - reduce gate queue time, faster development process, faster CI >>>> >>>> Challenges: >>>> - keep overcloud testing, with OVB >>>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic >>>> containerized services on overcloud. >>>> >>>> I really want to get consensus on these points, please raise your >>>> voice now before we engage some work on that front. >>>> >>>> [...] >>>> >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Irc #bogdando >>> >>> __ >>> 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 >> >> >> OK, >> Just got off the containers call. We discussed the CI requirements for the >> containerized undercloud. >> >> In the upstream, launched via quickstart not tripleo.sh we want to see >> >> 1) undercloud-containers - a containerized install, should be voting by m1 > > Hum. We're already in m2 now FYI. > >> 2) undercloud-containers-update - minor updates run on containerized >> underclouds, should be voting by m2 >> 3) undercloud-containers-upgrade - major upgrade from >> non-containerized to containerized undercloud, should be voting by m2. >> >> The above three items will enable us to test the quality of just the >> undercloud install. >> >> Ian and I are also working together on testing full deployments with the >> containerized >> undercloud to test how stable full runs are generally. This will >> help us assess the readiness of switching over in full in queens. >> >> This will also then lead into discussions and planning around where we can >> remove >> multinode testing in upstream and start to fully utilize the benefits of the >> containerized undercloud. >> >> Please contact myself or Sagi regarding changes in the CI for the >> undercloud. >> Thanks > > I
Re: [openstack-dev] [TripleO] containerized undercloud in Queens
On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin <whayu...@redhat.com> wrote: > > > On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >> >> On 11/6/17 1:01 AM, Emilien Macchi wrote: >>> >>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@redhat.com> wrote: >>> [...] >>> >>>> -CI resources: better use of CI resources. At the PTG we received >>>> feedback from the OpenStack infrastructure team that our upstream CI >>>> resource usage is quite high at times (even as high as 50% of the >>>> total). Because of the shared framework and single node capabilities we >>>> can re-architecture much of our upstream CI matrix around single node. >>>> We no longer require multinode jobs to be able to test many of the >>>> services in tripleo-heat-templates... we can just use a single cloud VM >>>> instead. We'll still want multinode undercloud -> overcloud jobs for >>>> testing things like HA and baremetal provisioning. But we can cover a >>>> large set of the services (in particular many of the new scenario jobs >>>> we added in Pike) with single node CI test runs in much less time. >>> >>> >>> After the last (terrible) weeks in CI, it's pretty clear we need to >>> find a solution to reduce and optimize our testing. >>> I'm now really convinced by switching our current scenarios jobs to >>> NOT deploy the overcloud, and just an undercloud with composable >>> services & run tempest. >> >> >> +1 >> And we should start using the quickstart-extras undercloud-reploy role for >> that. >> >>> >>> Benefits: >>> - deploy 1 node instead of 2 nodes, so we save nodepool resources >>> - faster (no overcloud) >>> - reduce gate queue time, faster development process, faster CI >>> >>> Challenges: >>> - keep overcloud testing, with OVB >>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic >>> containerized services on overcloud. >>> >>> I really want to get consensus on these points, please raise your >>> voice now before we engage some work on that front. >>> >>> [...] >>> >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Irc #bogdando >> >> __ >> 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 > > > OK, > Just got off the containers call. We discussed the CI requirements for the > containerized undercloud. > > In the upstream, launched via quickstart not tripleo.sh we want to see > > 1) undercloud-containers - a containerized install, should be voting by m1 Hum. We're already in m2 now FYI. > 2) undercloud-containers-update - minor updates run on containerized > underclouds, should be voting by m2 > 3) undercloud-containers-upgrade - major upgrade from > non-containerized to containerized undercloud, should be voting by m2. > > The above three items will enable us to test the quality of just the > undercloud install. > > Ian and I are also working together on testing full deployments with the > containerized > undercloud to test how stable full runs are generally. This will > help us assess the readiness of switching over in full in queens. > > This will also then lead into discussions and planning around where we can > remove > multinode testing in upstream and start to fully utilize the benefits of the > containerized undercloud. > > Please contact myself or Sagi regarding changes in the CI for the > undercloud. > Thanks I did this patch: https://review.openstack.org/518197 So we can switch our non voting job to use the quickstart featureset. Once the switch is made, we need to make sure the job actually works fine, otherwise we'll have to make adjustments. Next iterations in my mind: - run undercloud sanity test on undercloud-container job - switch existing featureset for scenarios to only deploy a containerized undercloud & run Tempest. The only blocker I see for that is the fact scenarios are multinode, and we now want one node. 2 options: - switch scenarios iteratively and when one works, patch infra to switch the job to 1node. - (expensive) create experimental jobs for each scenarios (and featuresets...) and make the switch at some point. I have a preference for option 1 which sounds easier and faster. Do we have an etherpad where we can collaborate and list tasks & assign folks? I don't want to overlap with any ongoing effort. If not, let's create one. Thanks Wes for your help, it's really cool to see we're making progress here. -- 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] Help needed on debugging upgrade jobs on Pike
Thanks folks :-) you rock! On Mon, Nov 6, 2017 at 5:05 AM, Jiří Stránský <ji...@redhat.com> wrote: > On 6.11.2017 11:17, Jiří Stránský wrote: >> >> On 6.11.2017 10:52, Marios Andreou wrote: >>> >>> On Mon, Nov 6, 2017 at 11:09 AM, Marius Cornea <mari...@redhat.com> >>> wrote: >>> >>>> On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi <emil...@redhat.com> >>>> wrote: >>>>> >>>>> Since we've got promotion, we can now properly test upgrades from ocata >>>> >>>> to pike. >>>>> >>>>> It's now failing for various reasons, as you can see on: >>>>> https://review.openstack.org/#/c/500625/ >>>>> >>>>> I haven't filled bug yet but this is the kind of thing I see now: >>>>> >>>>> http://logs.openstack.org/25/500625/20/check/legacy-tripleo-ci-centos-7- >>>> >>>> scenario002-multinode-oooq-container-upgrades/62e7f14/ >>>> logs/undercloud/home/zuul/overcloud_upgrade_console.log. >>>> txt.gz#_2017-11-04_00_14_17 >>>> >>>> I think this is related to https://review.openstack.org/#/c/510577/ >>>> which introduced running os-net-config during the major upgrade >>>> composable step. In case of environments without network isolation >>>> /etc/os-net-config/config.json doesn't exist so the os-net-config >>>> command fails. I filed https://bugs.launchpad.net/tripleo/+bug/1730328 >>>> to keep track of it. >>>> >>>> >>> heh, beat me to it :) I was about to file that. Indeed from logs @ [0] >>> you >>> can see the step3 ansible-playbook failing for >>> >>> https://github.com/openstack/tripleo-heat-templates/blob/e463ca15fb2189fde7e7e2de136cfb2303d3171f/puppet/services/tripleo-packages.yaml#L56-L64 >>> >>> I had a poke at one of the other jobs too since there are apparently >>> multiple issues - I found a different one >>> for legacy-tripleo-ci-centos-7-containers-multinode-upgrades and filed >>> https://bugs.launchpad.net/tripleo/+bug/1730349 for that. It looks like >>> all >>> the upgrade_tasks pass there but then fails on docker-puppet >> >> >> I'm not sure if it's related to that ^ error in particular > > > Yea the backport [2] seems to have fixed that issue. The upgrade now > completed successfully, but the job failed on validation. I've +A'd the > backport as it gets us closer to green. > > >> , but since we >> landed deploy/upgrade scenario separation [1], the upgrade job on Pike >> effectively started testing non-pacemaker to pacemaker upgrade, which >> won't work. Due to a chicken-and-egg issue with landing related patches >> we could not set the dependencies properly. There's a patch fixing this >> issue and making the Pike upgrade pacemaker-to-pacemaker [2]. This may >> not solve all the issues, but i think we need it merged to at least have >> a chance at a green result. >> >>> >>> [0] >>> >>> http://logs.openstack.org/25/500625/20/check/legacy-tripleo-ci-centos-7-scenario002-multinode-oooq-container-upgrades/62e7f14/logs/subnode-2/var/log/messages.txt.gz#_Nov__4_00_13_55 >> >> [1] https://review.openstack.org/#/c/500552 >> [2] https://review.openstack.org/#/c/512305 >>> >>> >>> thanks, >>> >>> marios >>> >>> >>>> I'm requesting some help from the upgrades squad, if they already saw >>>>> >>>>> the failures, etc. It would be great to have the jobs passing at some >>>>> point, now the framework is in place and we had promotion. >>>>> >>>>> 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 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] Nominate akrivoka for tripleo-validations core
On Mon, Nov 6, 2017 at 6:32 AM, Honza Pokorny <ho...@redhat.com> wrote: > Hello people, > > I would like to nominate Ana Krivokapić (akrivoka) for the core team for > tripleo-validations. She has really stepped up her game on that project > in terms of helpful reviews, and great patches. > > With Ana's help as a core, we can get more done, and innovate faster. > > If there are no objections within a week, we'll proceed with adding Ana > to the team. +1, good work Ana! Thanks Honza for the proposal :) -- 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 in Queens
On Mon, Nov 6, 2017 at 4:35 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: > On 11/6/17 1:01 AM, Emilien Macchi wrote: >> >> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@redhat.com> wrote: >> [...] >> >>> -CI resources: better use of CI resources. At the PTG we received >>> feedback from the OpenStack infrastructure team that our upstream CI >>> resource usage is quite high at times (even as high as 50% of the >>> total). Because of the shared framework and single node capabilities we >>> can re-architecture much of our upstream CI matrix around single node. >>> We no longer require multinode jobs to be able to test many of the >>> services in tripleo-heat-templates... we can just use a single cloud VM >>> instead. We'll still want multinode undercloud -> overcloud jobs for >>> testing things like HA and baremetal provisioning. But we can cover a >>> large set of the services (in particular many of the new scenario jobs >>> we added in Pike) with single node CI test runs in much less time. >> >> >> After the last (terrible) weeks in CI, it's pretty clear we need to >> find a solution to reduce and optimize our testing. >> I'm now really convinced by switching our current scenarios jobs to >> NOT deploy the overcloud, and just an undercloud with composable >> services & run tempest. > > > +1 > And we should start using the quickstart-extras undercloud-reploy role for > that. YES! and reflect what our users would do in real life. No workaround. >> >> Benefits: >> - deploy 1 node instead of 2 nodes, so we save nodepool resources >> - faster (no overcloud) >> - reduce gate queue time, faster development process, faster CI >> >> Challenges: >> - keep overcloud testing, with OVB >> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic >> containerized services on overcloud. >> >> I really want to get consensus on these points, please raise your >> voice now before we engage some work on that front. >> >> [...] >> > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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] containerized undercloud in Queens
On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@redhat.com> wrote: [...] > -CI resources: better use of CI resources. At the PTG we received > feedback from the OpenStack infrastructure team that our upstream CI > resource usage is quite high at times (even as high as 50% of the > total). Because of the shared framework and single node capabilities we > can re-architecture much of our upstream CI matrix around single node. > We no longer require multinode jobs to be able to test many of the > services in tripleo-heat-templates... we can just use a single cloud VM > instead. We'll still want multinode undercloud -> overcloud jobs for > testing things like HA and baremetal provisioning. But we can cover a > large set of the services (in particular many of the new scenario jobs > we added in Pike) with single node CI test runs in much less time. After the last (terrible) weeks in CI, it's pretty clear we need to find a solution to reduce and optimize our testing. I'm now really convinced by switching our current scenarios jobs to NOT deploy the overcloud, and just an undercloud with composable services & run tempest. Benefits: - deploy 1 node instead of 2 nodes, so we save nodepool resources - faster (no overcloud) - reduce gate queue time, faster development process, faster CI Challenges: - keep overcloud testing, with OVB - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic containerized services on overcloud. I really want to get consensus on these points, please raise your voice now before we engage some work on that front. [...] -- 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] Help needed on debugging upgrade jobs on Pike
Since we've got promotion, we can now properly test upgrades from ocata to pike. It's now failing for various reasons, as you can see on: https://review.openstack.org/#/c/500625/ I haven't filled bug yet but this is the kind of thing I see now: http://logs.openstack.org/25/500625/20/check/legacy-tripleo-ci-centos-7-scenario002-multinode-oooq-container-upgrades/62e7f14/logs/undercloud/home/zuul/overcloud_upgrade_console.log.txt.gz#_2017-11-04_00_14_17 I'm requesting some help from the upgrades squad, if they already saw the failures, etc. It would be great to have the jobs passing at some point, now the framework is in place and we had promotion. 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] onboarding session in Sydney
Anyone interested by TripleO and going to Sydney, We'll hold an onboarding session during the Summit, on Monday 6th at 4.20pm in C4.7 room. https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20438/tripleo-project-onboarding Everything will be tracked on this etherpad [1]. What to expect from this session: - Meet TripleO contributors - Ask any question, any help, on anything related to TripleO - Learn where to get started, how to contribute and how things work What to *not* expect: - an agenda (the session is driven by people in the room) - a presentation about our roadmap (we have a session for that, see [2] We're really exciting to hold this session for a second time, we're looking forward to meeting you there! [1] https://etherpad.openstack.org/p/SYD-forum-tripleo-onboarding [2] https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20398/tripleo-project-update -- Emilien Macchi on behalf of the TripleO team __ 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] Blocking gate - do not recheck / rebase / approve any patch now (please)
On Wed, Oct 25, 2017 at 1:59 PM, Emilien Macchi <emil...@redhat.com> wrote: > Quick update before being afk for some hours: > > - Still trying to land https://review.openstack.org/#/c/513701 (thanks > Paul for promoting it in gate). Landed. > - Disabling voting on scenario001 and scenario004 container jobs: > https://review.openstack.org/#/c/515188/ Done, please be very careful while these jobs are not voting. If any doubt, please ping me or fultonj or gfidente on #tripleo. > - overcloudrc/keystone v2 workaround: > https://review.openstack.org/#/c/515161/ (d0ugal will work on proper > fix for https://bugs.launchpad.net/tripleo/+bug/1727454) Merged - Dougal will work on the real fix this week but not urgent anymore. > - Fixing zaqar/notification issues on > https://review.openstack.org/#/c/515123 - we hope that helps to reduce > some failures in gate In gate right now and hopefully merged in less than 2 hours. Otherwise, please keep rechecking it. According to Thomas Hervé, il will reduce the change to timeout. > - puppet-tripleo gate broken on stable branches (syntax jobs not > running properly) - jeblair is looking at it now jeblair will provide a fix hopefully this week but this is not critical at this time. Thanks Jim for your help. > Once again, we'll need to retrospect and see why we reached that > terrible state but let's focus on bringing our CI in a good shape > again. > Thanks a ton to everyone who is involved, I'm now restoring all patches that I killed from the gate. You can now recheck / rebase / approve what you want, but please save our CI resources and do it with moderation. We are not done yet. I won't call victory but we've merged almost all our blockers, one is missing but currently in gate: https://review.openstack.org/515123 - need babysit until merged. Now let's see how RDO promotion works. We're close :-) Thanks everyone, > On Wed, Oct 25, 2017 at 7:25 AM, Emilien Macchi <emil...@redhat.com> wrote: >> Status: >> >> - Heat Convergence switch *might* be a reason why overcloud timeout so >> much. Thomas proposed to disable it: >> https://review.openstack.org/515077 >> - Every time a patch fails in the tripleo gate queue, it reset the >> gate. I proposed to remove this common queue: >> https://review.openstack.org/515070 >> - I cleared the patches in check and queue to make sure the 2 blockers >> are tested and can be merged in priority. I'll keep an eye on it >> today. >> >> Any help is very welcome. >> >> On Wed, Oct 25, 2017 at 5:58 AM, Emilien Macchi <emil...@redhat.com> wrote: >>> We have been working very hard to get a package/container promotions >>> (since 44 days) and now our blocker is >>> https://review.openstack.org/#/c/513701/. >>> >>> Because the gate queue is huge, we decided to block the gate and kill >>> all the jobs running there until we can get >>> https://review.openstack.org/#/c/513701/ and its backport >>> https://review.openstack.org/#/c/514584 (both are blocking the whole >>> production chain). >>> We hope to promote after these 2 patches, unless there is something >>> else, in that case we would iterate to the next problem. >>> >>> We hope you understand and support us during this effort. >>> So please do not recheck, rebase or approve any patch until further notice. >>> >>> Thank you, >>> -- >>> Emilien Macchi >> >> >> >> -- >> Emilien Macchi > > > > -- > 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] Blocking gate - do not recheck / rebase / approve any patch now (please)
Quick update before being afk for some hours: - Still trying to land https://review.openstack.org/#/c/513701 (thanks Paul for promoting it in gate). - Disabling voting on scenario001 and scenario004 container jobs: https://review.openstack.org/#/c/515188/ - overcloudrc/keystone v2 workaround: https://review.openstack.org/#/c/515161/ (d0ugal will work on proper fix for https://bugs.launchpad.net/tripleo/+bug/1727454) - Fixing zaqar/notification issues on https://review.openstack.org/#/c/515123 - we hope that helps to reduce some failures in gate - puppet-tripleo gate broken on stable branches (syntax jobs not running properly) - jeblair is looking at it now Once again, we'll need to retrospect and see why we reached that terrible state but let's focus on bringing our CI in a good shape again. Thanks a ton to everyone who is involved, On Wed, Oct 25, 2017 at 7:25 AM, Emilien Macchi <emil...@redhat.com> wrote: > Status: > > - Heat Convergence switch *might* be a reason why overcloud timeout so > much. Thomas proposed to disable it: > https://review.openstack.org/515077 > - Every time a patch fails in the tripleo gate queue, it reset the > gate. I proposed to remove this common queue: > https://review.openstack.org/515070 > - I cleared the patches in check and queue to make sure the 2 blockers > are tested and can be merged in priority. I'll keep an eye on it > today. > > Any help is very welcome. > > On Wed, Oct 25, 2017 at 5:58 AM, Emilien Macchi <emil...@redhat.com> wrote: >> We have been working very hard to get a package/container promotions >> (since 44 days) and now our blocker is >> https://review.openstack.org/#/c/513701/. >> >> Because the gate queue is huge, we decided to block the gate and kill >> all the jobs running there until we can get >> https://review.openstack.org/#/c/513701/ and its backport >> https://review.openstack.org/#/c/514584 (both are blocking the whole >> production chain). >> We hope to promote after these 2 patches, unless there is something >> else, in that case we would iterate to the next problem. >> >> We hope you understand and support us during this effort. >> So please do not recheck, rebase or approve any patch until further notice. >> >> Thank you, >> -- >> Emilien Macchi > > > > -- > 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] Blocking gate - do not recheck / rebase / approve any patch now (please)
Status: - Heat Convergence switch *might* be a reason why overcloud timeout so much. Thomas proposed to disable it: https://review.openstack.org/515077 - Every time a patch fails in the tripleo gate queue, it reset the gate. I proposed to remove this common queue: https://review.openstack.org/515070 - I cleared the patches in check and queue to make sure the 2 blockers are tested and can be merged in priority. I'll keep an eye on it today. Any help is very welcome. On Wed, Oct 25, 2017 at 5:58 AM, Emilien Macchi <emil...@redhat.com> wrote: > We have been working very hard to get a package/container promotions > (since 44 days) and now our blocker is > https://review.openstack.org/#/c/513701/. > > Because the gate queue is huge, we decided to block the gate and kill > all the jobs running there until we can get > https://review.openstack.org/#/c/513701/ and its backport > https://review.openstack.org/#/c/514584 (both are blocking the whole > production chain). > We hope to promote after these 2 patches, unless there is something > else, in that case we would iterate to the next problem. > > We hope you understand and support us during this effort. > So please do not recheck, rebase or approve any patch until further notice. > > Thank you, > -- > 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] Blocking gate - do not recheck / rebase / approve any patch now (please)
We have been working very hard to get a package/container promotions (since 44 days) and now our blocker is https://review.openstack.org/#/c/513701/. Because the gate queue is huge, we decided to block the gate and kill all the jobs running there until we can get https://review.openstack.org/#/c/513701/ and its backport https://review.openstack.org/#/c/514584 (both are blocking the whole production chain). We hope to promote after these 2 patches, unless there is something else, in that case we would iterate to the next problem. We hope you understand and support us during this effort. So please do not recheck, rebase or approve any patch until further notice. Thank you, -- 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] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
I figured that Sydney would be a great opportunity to have face2face discussion around this topic, and I commit to be there and try to make progress on this discussion. I would love to get some people representing their deployment projects and operators as well. Please join us : https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20456/what-do-operators-want-from-the-stable-policy and probably https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20480/upstream-lts-releases Thanks, On Tue, Oct 17, 2017 at 8:32 AM, Fox, Kevin M <kevin@pnnl.gov> wrote: > So, my $0.02. > > A supported/recent version of a tool to install an unsupported version of a > software is not a bad thing. > > OpenStack has a bad reputation (somewhat deservedly) for being hard to > upgrade. This has mostly gotten better over time but there are still a large > number of older, unsupported deployments at this point. > > Sometimes, burning down the cloud isn't an option and sometimes upgrading in > place isn't an option either, and they are stuck on an unsupported version. > > Being able to deploy with a more modern installer the same version of the > cloud your running in production and shift the load to it (sideways upgrade), > but then have an upgrade path provided by the tool would be a great thing. > > Thanks, > Kevin > > From: Michał Jastrzębski [inc...@gmail.com] > Sent: Monday, October 16, 2017 3:50 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] > [puppet] Proposing changes in stable policy for installers > > So my 0.02$ > > Problem with handling Newton goes beyond deployment tools. Yes, it's > popular to use, but if our dependencies (openstack services > themselves) are unmaintained, so should we. If we say "we support > Newton" in deployment tools, we make kind of promise we can't keep. If > for example there is CVE in Nova that affects Newton, there is nothing > we can do about it and our "support" is meaningless. > > Not having LTS kind of model was issue for OpenStack operators > forever, but that's not problem we can solve in deployment tools > (although we are often asked for that because our communities are > largely operators and we're arguably closest projects to operators). > > I, for one, think we should keep current stable policy, not make > exception for deployment tools, and address this issue across the > board. What Emilien is describing is real issue that hurts operators. > > On 16 October 2017 at 15:38, Emilien Macchi <emil...@redhat.com> wrote: >> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez <thie...@openstack.org> >> wrote: >>> Emilien Macchi wrote: >>>> [...] >>>> ## Proposal >>>> >>>> Proposal 1: create a new policy that fits for projects like installers. >>>> I kicked-off something here: https://review.openstack.org/#/c/511968/ >>>> (open for feedback). >>>> Content can be read here: >>>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases >>>> Tag created here: https://review.openstack.org/#/c/511969/ (same, >>>> please review). >>>> >>>> The idea is really to not touch the current stable policy and create a >>>> new one, more "relax" that suits well for projects like installers. >>>> >>>> Proposal 2: change the current policy and be more relax for projects >>>> like installers. >>>> I haven't worked on this proposal while it was something I was >>>> considering doing first, because I realized it could bring confusion >>>> in which projects actually follow the real stable policy and the ones >>>> who have exceptions. >>>> That's why I thought having a dedicated tag would help to separate them. >>>> >>>> Proposal 3: no change anywhere, projects like installer can't claim >>>> stability etiquette (not my best option in my opinion). >>>> >>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla, >>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has >>>> this need), please get involved in the review process. >>> >>> My preference goes to proposal 1, however rather than call it "relaxed" >>> I would make it specific to deployment/lifecycle or cycle-trailing >
Re: [openstack-dev] [TripleO] Deployment workflow changes for ui/client
On Tue, Oct 24, 2017 at 8:16 AM, James Slagle <james.sla...@gmail.com> wrote: > On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek <jtoma...@redhat.com> wrote: >> Having a workflow which wraps whole deployment sounds great from the UI side >> too as it allows us to simplify the steps you described above. IIRC the >> reason the whole deployment did not get wrapped into a single workflow >> before is that the workflow/tasks timeouted before the deployment could >> finish which caused the workflow to fail. >> >> It should not be problematic to integrate these changes in GUI. The soon we >> can test it the better. As Brad noted, it is important to get as many Zaqar >> messages as possible so we can track the progress properly. > > Thanks :). Sounds like at least the 3 of us, are in general agreement > about moving more towards wrapping all the deployment logic into a > single workflow, or as few workflows as possible. Doing so will reduce > the amount of logic we have to do client side and in the UI. > > That being said...as I started to look in that direction, I realized > it is a lot of work to get us there, even if we did just enough to > support using config-download. I feel like such an effort should > probably be tracked in its own blueprint and properly scoped so that > the risk is well understood. I'd estimate it to be fairly disruptive > given the amount of changes needed in the clients and workflows. > > To that end, I'm proposing we push such an effort off to Rocky, given > we already passed Queens-1. +1, let's make iterations and config-download seems an excellent one. > For config-download for Queens, I've proposed the following as an > alternative solution: > > https://review.openstack.org/#/c/514701/ (python-tripleoclient) > https://review.openstack.org/#/c/512876/ (tripleo-common) > > I think it's fairly simple with low risk and it just follows the > existing pattern of calling an additional workflow to add > functionality. If we're happy with where we get to in queens with > config-download, we could consider making it the default. We'll give feedback in the review. Thanks James for this update, -- 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 CI Community meeting tomorrow
On Tue, Oct 24, 2017 at 8:50 AM, Arx Cruz <arxc...@redhat.com> wrote: > Hello > > We are going to have a TripleO CI Community meeting tomorrow 10/25/2017 at 1 > pm UTC time. > The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo > channel. > > After that, we will hold Office Hours starting at 4PM UTC in case someone > from community have any questions related to CI. > > Hope to see you there. > > 1 - https://bluejeans.com/7071866728 > > > Kind regards, > Arx Cruz quick question, is it a regular time or will it change in the future? (so I can update my calendar) 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] latest centos iptables rpm broke tripleo ci
On Sat, Oct 21, 2017 at 7:42 AM, Wesley Hayutin <whayu...@redhat.com> wrote: > Greetings, > > TripleO CI started to hit errors in any of the multinode node pool jobs last > Friday afternoon. > Please review the bug and patch to bring CI back online [1-2] > > More work needs to be done to discover exactly why the latest rpm breaks the > vxlan network link between nodes. It's also a good time to investigate > options regarding additional gatting for CentOS packages. This patch brings > TripleO CI back online, but does not close the issue. > > Thanks, have a good weekend. > > [1] https://bugs.launchpad.net/tripleo/+bug/1725451 > [2] https://review.openstack.org/#/c/513891/ > Just an FYI bis - David is working on a fix in the zuul-v3 playbooks, which will probably help to solve the root cause issue: https://review.openstack.org/#/c/513943/ Thanks Wes & David for helping 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
[openstack-dev] [tripleo] Issue with Zuul v3 / Gerrit / TripleO Jobs
Since we migrated to Zuul v3 and Zuul is now the default user which vote in Gerrit, we now have a bug with jobs running in the 'check' and the 'check-tripleo' pipeline. Jobs finish in the 'check' pipeline and report their status and then jobs finish in the 'check-tripleo' pipeline, overwriting/discarding the results from the 'check' pipeline. In v2, the check pipeline results were 'additive' but not in v3, it seems. It might be some javascript display in Gerrit but we haven't figured out. Which means... please be careful when you review and check both pipelines results and not the latest one displayed in Gerrit. Please scroll-down to the comments to see first pipeline results as well, so we make sure we're not merging patches that didn't pass some non-voting jobs (specially the ones in check-tripleo). Thank you, -- 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] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez <thie...@openstack.org> wrote: > Emilien Macchi wrote: >> [...] >> ## Proposal >> >> Proposal 1: create a new policy that fits for projects like installers. >> I kicked-off something here: https://review.openstack.org/#/c/511968/ >> (open for feedback). >> Content can be read here: >> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases >> Tag created here: https://review.openstack.org/#/c/511969/ (same, >> please review). >> >> The idea is really to not touch the current stable policy and create a >> new one, more "relax" that suits well for projects like installers. >> >> Proposal 2: change the current policy and be more relax for projects >> like installers. >> I haven't worked on this proposal while it was something I was >> considering doing first, because I realized it could bring confusion >> in which projects actually follow the real stable policy and the ones >> who have exceptions. >> That's why I thought having a dedicated tag would help to separate them. >> >> Proposal 3: no change anywhere, projects like installer can't claim >> stability etiquette (not my best option in my opinion). >> >> Anyway, feedback is welcome, I'm now listening. If you work on Kolla, >> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has >> this need), please get involved in the review process. > > My preference goes to proposal 1, however rather than call it "relaxed" > I would make it specific to deployment/lifecycle or cycle-trailing > projects. > > Ideally this policy could get adopted by any such project. The > discussion started on the review and it's going well, so let's see where > it goes :) Thierry, when I read your comment on Gerrit I understand you prefer to amend the existing policy and just make a note for installers (which is I think the option #2 that I proposed). Can you please confirm that? So far I see option #1 has large consensus here, I'll wait for Thierry's answer to continue to work on it. Thanks for the feedback so far! -- 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][election] Question for all candidates in TC election: What will you do if you don't win?
On Sun, Oct 15, 2017 at 5:15 AM, Amrith Kumar <amrith.ku...@gmail.com> wrote: > Full disclosure, I'm running for election as well. I intend to also > provide an answer to the question I pose here, one that I've posed > before on #openstack-tc in an office hours session. > > Question 1: > > "There are M open slots for the TC and there are N (>>M) candidates > for those open slots. This is a good problem to have, no doubt. > Choice, is a good thing, enthusiasm and participation are good things. > > But clearly, (N-M) candidates will not be elected. > > If you are one of those (N-M) candidates, what then? What do you > believe you can do if you are not elected to the TC, and what will you > do? (concrete examples would be good)" I always plan to work on the same things as usual, I'm not rage quitting :-) The only thing as a TC member is that you can actually vote in Governance changes. All the rest is about your influence in our community, and I already explained what my focus has been until now and what it would be in the near future. > Question 2: > > "If you are one of the M elected candidates, the N-M candidates who > were not elected represent a resource? > > Would you look to leverage/exploit that resource, and if so, how? > (concrete examples would be good)" > > -amrith > > __ > 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] Proposing Alfredo Moralejo core on puppet-openstack-integration
sounds good, updating Gerrit permissions now. Thanks all, On Fri, Oct 13, 2017 at 2:09 PM, Iury Gregory <iurygreg...@gmail.com> wrote: > +1 > > On Oct 13, 2017 17:13, "Alex Schultz" <aschu...@redhat.com> wrote: > > +1 thanks for the great contributions > > On Fri, Oct 13, 2017 at 11:49 AM, Mohammed Naser <mna...@vexxhost.com> > wrote: >> >> >> On Fri, Oct 13, 2017 at 1:21 PM, Emilien Macchi <emil...@redhat.com> >> wrote: >>> >>> Alfredo has been doing an incredible work on maintaining Puppet >>> OpenStack CI; by always testing OpenStack from trunk and taking care >>> of issues. He has been involved in fixing the actual CI problems in >>> OpenStack projects but also maintaining puppet-openstack-integration >>> repository in a consistent and solid manner. >>> Also, he has an excellent understanding how things work in this >>> project and I would like to propose him part of p-o-i maintainers >>> (among the rest of the whole core team and also dmsimard). >> >> >> Indeed, Alfredo has helped us a lot by giving assistance from the >> packagers >> side of things and making sure that they release working packages, and >> proposing fixes for issues that block promotion of packages to avoid >> breaking our CI. >> >> +2 from me :) >> >>> >>> >>> As usual, feel free to vote and give feedback. >>> >>> 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 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 > > > > __ > 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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?
On Fri, Oct 13, 2017 at 5:45 AM, Flavio Percoco <fla...@redhat.com> wrote: > Some of you, TC candidates, expressed concerns about diversity and > inclusiveness (or inclusivity, depending on your taste) in your candidacy. I > believe this > is a broad, and some times ill-used, topic so, I'd like to know, from y'all, > how > you think we could make our community more inclusive. What areas would you > improve first? Some rough ideas, that can be discussed as a community: - Force changes in leadership roles: I'm believe in rotations when that makes sense. We could think at some policy to not being at TC more than 2 cycles in a row (can re-apply after one cycle break). Same for PTL? (not sure on this one, some projects don't have much volunteers do run this position). But you get the idea. (some could ask why I didn't propose that during my TC mandate, it just popup in my mind by writing this email). - Keep encouraging asynchronous collaboration: dropping the TC meeting (and adding office hours) was a good example of how we can now have TC-related discussions around the globe without having to stay until late in the evening. I would like to encourage other projects to look at this concept. Hopefully we can get more contributors from around the globe and not just in US-friendly timezone. - Ensure projects growth: the number of core reviewers for some projects is imho alarming. Lack of reviewers? Lack of trust? Here are some number of the Top 5 projects (# of reviews in Pike, source stackalitics): #1 Nova - 12 cores #2 Infra - 13 cores (core, not root) #3 Cinder - 15 cores #4 Neutron - 13 cores (not counting all plugins repos, but numbers look good, probably thanks to the stadium) #5 TripleO - 32 (and we can continue) What TC can do? promote more mentoring, establish healthy policies to promote cores in projects, by defining as a community the metrics used, etc. Anyway, these things are (again) rough ideas, that we can be discussed here or somewhere else but I strongly believe we need people at TC who can, by their experience and motivation, make our community growing in healthy and diverse ways. -- 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Greeting folks, I hope we can get attention from stable-maint, release-managers and installers projects. ## Background Some projects tried hard to follow stable policy but it didn't finish well: https://review.openstack.org/#/c/507924/ This policy is too strict for projects like installers, although it's not a reason why the projects wouldn't be "stable". We decided to discuss again about the tag and how it works for installers. ## Proposal Proposal 1: create a new policy that fits for projects like installers. I kicked-off something here: https://review.openstack.org/#/c/511968/ (open for feedback). Content can be read here: http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases Tag created here: https://review.openstack.org/#/c/511969/ (same, please review). The idea is really to not touch the current stable policy and create a new one, more "relax" that suits well for projects like installers. Proposal 2: change the current policy and be more relax for projects like installers. I haven't worked on this proposal while it was something I was considering doing first, because I realized it could bring confusion in which projects actually follow the real stable policy and the ones who have exceptions. That's why I thought having a dedicated tag would help to separate them. Proposal 3: no change anywhere, projects like installer can't claim stability etiquette (not my best option in my opinion). Anyway, feedback is welcome, I'm now listening. If you work on Kolla, TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has this need), please get involved in the review process. 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] [puppet] Proposing Alfredo Moralejo core on puppet-openstack-integration
Alfredo has been doing an incredible work on maintaining Puppet OpenStack CI; by always testing OpenStack from trunk and taking care of issues. He has been involved in fixing the actual CI problems in OpenStack projects but also maintaining puppet-openstack-integration repository in a consistent and solid manner. Also, he has an excellent understanding how things work in this project and I would like to propose him part of p-o-i maintainers (among the rest of the whole core team and also dmsimard). As usual, feel free to vote and give feedback. 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][election] Question for the candidates
On Thu, Oct 12, 2017 at 12:42 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote: [...] > To candidates: > > Would you please self select a change (or changes) from > https://github.com/openstack/governance/ in the past ~12 mo or so where they > thought the outcome or the discussion/process was particular good and > explain why you think so? > > It'd be super helpful to me, thanks! The vision exercise was, in my opinion, one of the more exciting things we have done in 2017. It's not an easy thing to do because of our diverses opinions, but together we managed to write something down, propose it to the community in the open and make it better afterward (of course this will never finish). Outcome related, I loved the fact we're thinking outside of the OpenStack community and see how we can make OpenStack projects usable in environments without all the ecosystem. I also like to see our strong efforts to increase diversity in all sorts and our work to improve community health. Beside the outcome, I loved to see all TC members able to work together on this Vision in the open, I hope we can do more of that in the future, even outside of the TC (in teams). (ex: doc team had a PTG session about visioning as well). I hope I answered the question, please let me know if that's not the case if you want more details. -- 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][tc] TC Candidates: what does an OpenStack user look like?
Replying on top of Mohammed, since I like his answer and want to add some comments. On Thu, Oct 12, 2017 at 12:07 PM, Mohammed Naser <mna...@vexxhost.com> wrote: [...] > Ideally, I think that OpenStack should be targeted to become a core > infrastructure tool that's part of organizations all around the world > which can deliver both OpenStack-native services (think Nova for VMs, > Cinder for block storage) and OpenStack-enabled services (think Magnum > which deployed Kubernetes integrated with OpenStack, Sahara which > deploys Big Data software integrated with Swift). > > This essentially makes OpenStack sit at the heart of the operations of > every organization (ideally!). It also translates well with > OpenStack's goal of providing a unified set of APIs and interfaces > which are always predictable to do the operations that you expect them > to do. With time, this will make OpenStack much more accessible, as > it becomes very easy to interact with as any individuals move from one > organization to another. I agree a lot with Mohammed here. I also like to think we build OpenStack to place it at the heart of all organizations consuming infrastructure at any scale or any architecture. It can be some pieces from OpenStack or a whole set of services working together. Also like he said, providing set of API, that are well known; I would add "stable APIs" (see discussions with Glare / Glance) and ensure some "perennity" for our end-users. Having talked with some users, some folks say "OpenStack becomes boring and we like it". Pursuing the discussion, they like to have long life API support and stability in how they operate. I think at a TC level we need to make sure we can both innovate and maintain this stability at a certain level. [...] -- 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][election] Question for the candidates
On Thu, Oct 12, 2017 at 11:38 AM, Ed Leafe <e...@leafe.com> wrote: > In the past year or so, has there been anything that made you think “I wish > the TC would do something about that!” ? If so, what was it, and what would > you have wanted the TC to do about it? I've been part of the TC during the past year (first time) but I still have an answer to that question. There is one thing I wish the TC would do more is to encourage projects to grow and empower trust in certain projects. Beside technical things, we want an healthy community and grow developer's knowledge so OpenStack can be a better place to contribute. I think some projects are doing well but some of them might need some mentoring on that front (maybe from some TC members). For example, I'm thinking about the way some projects handle core reviewers elections and their metrics used to do so. I think the TC might ensure that healthy metrics and discussion happen, so projects can scale. I'm happy to answer questions on that topic. Thanks Ed for this first question :-) -- 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][election] TC non-candidacy
On Tue, Oct 10, 2017 at 4:40 PM, Monty Taylor <mord...@inaugust.com> wrote: [...] > Thank you, from the bottom of my heart, for the trust you have placed in me. > I look forward to seeing as many of you as I can in Sydney, Vancouver, > Berlin and who knows where else. Thanks for all your extreme hard work at the TC, which is a great example for our community. -- 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/Ansible PTG session
loop and can still call into external installers like > Kubernetes if we want to. On the overcloud we'd still be leveraging the high > level Mistral workflow to kick off the initial Ansible playbooks... but once > that happens it would be Ansible driving any external installers directly. > > Dan > >> >> >> Also the interface for services would be clean and simple -- it's always >> the ansible tasks. >> >> And Mistral-less use cases become easier to handle too (= undercloud >> installation when Mistral isn't present yet, or development envs when you >> want to tune the playbook directly without being forced to go through >> Mistral). >> >> Logging becomes a bit more unwieldy in this scenario though, as for the >> nested ansible-playbook execution, all output would go into a task in the >> outer playbook, which would be harder to follow and the log of the outer >> playbook could be huge. >> >> So this solution is no silver bullet, but from my current point of view it >> seems a bit less conceptually foreign than using Mistral to provide step >> loop functionality to Ansible, which should be able to handle that on its >> own. >> >> >>>>>> - It would still be possible to run ansible-playbook directly for >>>>>> various use cases (dev/test/POC/demos). This preserves the quick >>>>>> iteration via Ansible that is often desired. >>>>>> >>>>>> - The remaining SoftwareDeployment resources in tripleo-heat-templates >>>>>> need to be supported by config download so that the entire >>>>>> configuration can be driven with Ansible, not just the deployment >>>>>> steps. The success criteria for this point would be to illustrate >>>>>> using an image that does not contain a running os-collect-config. >>>>>> >>>>>> - The ceph-ansible implementation done in Pike could be reworked to >>>>>> use this model. "config download" could generate playbooks that have >>>>>> hooks for calling external playbooks, or those hooks could be >>>>>> represented in the templates directly. The result would be the same >>>>>> either way though in that Heat would no longer be triggering a >>>>>> separate Mistral workflow just for ceph-ansible. >>>>> >>>>> >>>>> I'd say for ceph-ansible, kubernetes and in general anything else which >>>>> needs to run with a standard playbook installed on the undercloud and >>>>> not one generated via the heat templates... these "external" services >>>>> usually require the inventory file to be in different format, to >>>>> describe the hosts to use on a per-service basis, not per-role (and I >>>>> mean tripleo roles here, not ansible roles obviously) >>>>> >>>>> About that, we discussed a more long term vision where the playbooks >>>>> (static data) needd to describe how to deploy/upgrade a given service >>>>> is >>>>> in a separate repo (like tripleo-apb) and we "compose" from heat the >>>>> list of playbooks to be executed based on the roles/enabled services; >>>>> in >>>>> this scenario we'd be much closer to what we had to do for ceph-ansible >>>>> and I feel like that might finally allow us merge back the ceph >>>>> deployment (or kubernetes deployment) process into the more general >>>>> approach driven by tripleo >>>>> >>>>> James, Dan, comments? >>>> >>>> >>>> Agreed, I think this is the longer term plan in regards to using >>>> APB's, where everything consumed is an external playbook/role. >>>> >>>> We definitely want to consider this plan in parallel with the POC work >>>> that Flavio is pulling together and make sure that they are aligned so >>>> that we're not constantly reworking the framework. >>>> >>>> I've not yet had a chance to review the material he sent out this >>>> morning, but perhaps we could work together to update the sequence >>>> diagram to also have a "future" state to indicate where we are going >>>> and what it would look like with APB's and external paybooks. >> >> >> Indeed that would be great :) IIUC, APBs are deployed by running a >> short-lived container with Ansible inside, which then connects to Kubernetes >> endpoint to create resources. So this should be a less complicated case than >> running non-containerized external playbooks. >> >>> >>> this would be awesome, note that it isn't only ceph and kubernetes >>> anymore in this scenario ... I just spotted a submission for the Skydive >>> composable service and it uses the same mistral/ansible-playbook >>> approach ... so it's already 3 looking forward for this! >>> >>> https://review.openstack.org/#/c/502353/ >>> >> >> [1] >> https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/design.md#deploy >> >> >> __ >> 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] Reminder on bug triage
I think it's useful to share a little reminder about how do we create and manage bugs in TripleO. Bugs in TripleO are reported via launchpad.net/tripleo. The steps are well documented in Launchpad (you have boxes that explain exactly what a bug report should be like) but here are a few reminders. - Find a title related to the problem: Good title: "Mistral workflows tried to use Keystone v2.0 (removed upstream)" "Duplication error when running Ceph OSD & Ceph Mon on same nodes" Bad titles: "Overcloud stack failed to deploy" "gate-tripleo-ci-centos-7-nonha-multinode-oooq failed in periodic jobs" If you're busy and can't spend time to investigate, find some help on IRC or on this mailing-list. - Put good descriptions, with details at how to reproduce the problem. Just please don't throw a random Python Trace or a link to a CI job. Make a little research so our team can easily help. - Set status to Triaged as a first step, or In progress if you're actively working on it. - Set an Importance. Keep in mind Critical is only used when there is no way you can deploy TripleO with this bug (use it wisely). - Set a milestone, or when do you think we should fix the bug. High / critical: queens-1. Medium / low: queens-2, etc. - Set some tags and don't invent tags, there is auto-completion and tags are documented here: https://github.com/openstack/tripleo-specs/blob/master/specs/policy/bug-tagging.rst#tags That's all. If you can make that, you'll help to solve the bugs more quickly and everyone is happy. Any question or feedback is welcome. 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] Unbranched repositories and testing
On Fri, Oct 6, 2017 at 5:09 AM, Jiří Stránský <ji...@redhat.com> wrote: > On 5.10.2017 22:40, Alex Schultz wrote: >> >> Hey folks, >> >> So I wandered across the policy spec[0] for how we should be handling >> unbranched repository reviews and I would like to start a broader >> discussion around this topic. We've seen it several times over the >> recent history where a change in oooqe or tripleo-ci ends up affecting >> either a stable branch or an additional set of jobs that were not run >> on the change. I think it's unrealistic to run every possible job >> combination on every submission and it's also a giant waste of CI >> resources. I also don't necessarily agree that we should be using >> depends-on to prove things are fine for a given patch for the same >> reasons. That being said, we do need to minimize our risk for patches >> to these repositories. >> >> At the PTG retrospective I mentioned component design structure[1] as >> something we need to be more aware of. I think this particular topic >> is one of those types of things where we could benefit from evaluating >> the structure and policy around these unbranched repositories to see >> if we can improve it. Is there a particular reason why we continue to >> try and support deployment of (at least) 3 or 4 different versions >> within a single repository? Are we adding new features that really >> shouldn't be consumed by these older versions such that perhaps it >> makes sense to actually create stable branches? Perhaps there are >> some other ideas that might work? > > > Other folks probably have a better view of the full context here, but i'll > chime in with my 2 cents anyway.. > > I think using stable branches for tripleo-quickstart-extras could be worth > it. The content there is quite tightly coupled with the expected TripleO > end-user workflows, which tend to evolve considerably between releases. > Branching extras might be a good way to "match the reality" in that sense, > and stop worrying about breaking older workflows. (Just recently it came up > that the upgrade workflow in O is slightly updated to make it work in P, and > will change quite a bit for Q. Minor updates also changed between O and P.) > > I'd say that tripleo-quickstart is a different story though. It seems fairly > release-agnostic in its focus. We may want to keep it unbranched (?). That > probably applies even more for tripleo-ci, where ability to make changes > which affect how TripleO does CIing in general, across releases, is IMO a > significant feature. > > Maybe branching quickstart-extras might require some code reshuffling > between what belongs there and what belongs into quickstart itself. I agree a lot with Jirka and I think branching oooq-extras would be a good first start to see how it goes. If we find it helpful and working correctly, we could go the next steps and see if there is any other repo that could be branched (tripleo-ci or oooq) but I guess for now the best candidate is oooq-extras. > (Just my 2 cents, i'm likely not among the most important stakeholders in > this...) > > Jirka > > >> >> Thanks, >> -Alex >> >> [0] https://review.openstack.org/#/c/478488/ >> [1] http://people.redhat.com/aschultz/denver-ptg/tripleo-ptg-retro.jpg >> >> __ >> 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] [stable] Preping for the stable/newton EOL
On Thu, Oct 5, 2017 at 4:01 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: [...] > I'm happy to exclude tripleo from the initial EOL cycle (and had added > tripleo's repos to my list of 'opt-out' repos based on previous emails). > It'd be good if we could setup a one-off time with tripleo, stable (me) > and infra to look at what CI you have an which parts are generally > impacted by repo's EOLing. For example it's probable that > openstack/requiremnets (and that implies openstack-dev/devstack) need to > be the last projects to retire. > > That isn't terrible but I'd still like to make sure we're on the same > page so we can level set everyone's expectations. > > So who from tripleo needs to be there and what TZ are they in? It would be me (PST but flexible enough to work on your morning with you). These are the jobs we currently have for newton: puppet-tripleo: OpenStack Infra: gate-puppet-tripleo-puppet-lint in 11m 51s gate-puppet-tripleo-puppet-syntax-3-legacy-centos-7 in 3m 52s gate-puppet-tripleo-puppet-syntax-4-centos-7 in 3m 11s gate-tripleo-ci-centos-7-nonha-multinode-oooq in 1h 36m 42s gate-tripleo-ci-centos-7-undercloud-oooq in 49m 23s gate-puppet-tripleo-puppet-unit-4.8-centos-7 in 7m 26s RH1: gate-tripleo-ci-centos-7-ovb-ha-oooq in 2h 29m 44s gate-tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024 in 2h 24m 02s tripleo-heat-templates and others: OpenStack Infra: gate-tripleo-ci-centos-7-nonha-multinode-oooq in 1h 45m 38s gate-tripleo-heat-templates-pep8-ubuntu-xenial in 1m 36s RH1: gate-tripleo-ci-centos-7-ovb-ha-oooq in 2h 29m 44s gate-tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024 in 2h 24m 02s We don't have upgrade jobs on stable/newton, so the amount of consumed resources is reasonable I guess. Ping me anytime for further discussion, 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] Repo structure for ansible-k8s-roles-* under TripleO's umbrella
On Tue, Oct 10, 2017 at 4:24 AM, Flavio Percoco <fla...@redhat.com> wrote: [...] > The roles don't have tripleo in their names. The only role that mentions > tripleo > is tripleo specific. As for the APB, yeah, I had thought about renaming that > repo to something without tripleo in there: Perhaps just `ansible-k8s-apbs`. This proposal works for me. > I'm about to refactor this repo to remove all the code duplication. We > should be > able to generate most of the APB code that's in there from a python script. > We > could even have this script in tripleo_common, if it sounds sensible. > > Thoughts? ++ for removing duplication and using common roles / libraries when possible. roles should only have service specific bits at the end. I also see an opportunity to welcome contributors from outside of TripleO if some are interested by deploying OpenStack with Ansible apbs. 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] Repo structure for ansible-k8s-roles-* under TripleO's umbrella
On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco <fla...@redhat.com> wrote: [...] > 1. A repo per role: Each role would have its own repo - this is the way I've > been developing it on Github. This model is closer to the ansible way of > doing > things and it'll make it easier to bundle, ship, and collaborate on, > individual > roles. Going this way would produce something similar to what the > openstack-ansible folks have. +1 on #1 for the composability. [...] Have we considered renaming it to something without tripleo in the name? Or is it too specific to TripleO that we want it in the name? -- 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] [ptls] Sydney Forum Project Onboarding Rooms
On Thu, Oct 5, 2017 at 8:50 AM, Kendall Nelson <kennelso...@gmail.com> wrote: [...] > If you are interested in reserving a spot, just reply directly to me and I > will put your project on the list. Please let me know if you want one and > also include the names and emails anyone that will be speaking with you. TripleO - Emilien Macchi - emil...@redhat.com 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] [tc][election] TC candidacy
Dear community, This is my candidacy for second round of a position on the OpenStack Technical Committee: https://review.openstack.org/#/c/509880/ During the last twelve months, I've contributed to Governance reviews and used my vote by thinking outside of the box. Indeed, my experience on working with installers is pretty unique at the TC and I find it important to represent this world. I've also participated in the Visioning exercise in Boston, and I believe it helped a lot in our community. I hope we can keep iterating on this work during the next months. On a personal note, I really enjoyed working with the community and I believe we keep making progress over the years. And last but not least, I've been PTL on two different projects during five cycles. My focus has always been to find solutions for: - Bringing more trust in our community, and always assuming good faith by default. I think we have still some work to do on that area but I believe we'll continue to make good progress. - Making our operators happy. Working on installers is not the same game as working on devstack, you have to deal with customers and people from a different world. I like to think we're making good progress in how do we test OpenStack. - Scaling-up our community, by voting for governance changes but also at how we operate together on IRC, by e-mail or in person during events. Be more inclusive and help people to grow. We should kill "clubs" and unwelcoming places, and continue to make OpenStack the best Open-Source project to contribute to. Of course you don't need to be TC member to contribute on these topics; though changes made in Governance are voted by TC members; so I would like to be candidate one more time. Thank you for your consideration, -- 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] [docs] Evidence of Success
On Wed, Oct 4, 2017 at 11:18 AM, Jimmy McArthur <ji...@openstack.org> wrote: [...] > For the DoD and Metrics our understanding of the task was that they should > be built into the Evidence of Success, though I think we could still use > some more specific metrics in certain spots. Emilien, would you suggest we > define these as separate line items as well? [...] No, I think it's good as it is now, good 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] [docs] Evidence of Success
On Wed, Oct 4, 2017 at 8:46 AM, Jimmy McArthur <ji...@openstack.org> wrote: > I've made a bit of progress on the collaborative vision for the Docs team: > https://docs.google.com/document/d/1Xy78CnmnKlQ7SbR1XewqgrUdGe7DqnKAGYw_9aj5Ndg/edit# > > This still needs plenty of work, but I wanted to put out what we have so we > can start to get some feedback from other members of the Docs team. The Use > Cases section in particular was really vast and hard to cut down into prose > without getting too detailed. > > Welcome your feedback and input! The draft is really good! It reflects very well what we said we would do at the PTG, way to go. I think the next steps would be: - Definition of Done, or how you consider something achieved (code merged, doc published, etc). - Metrics: what metrics do you use to measure what you're delivering. - What do you expect by end of Queens (put some number in metrics is probably a good start) - it's already mentioned in your draft vision but it might be revisited once you define the 2 previous items. Good 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] containerized undercloud in Queens
On Tue, Oct 3, 2017 at 10:12 AM, Dan Prince <dpri...@redhat.com> wrote: [...] > I would let other chime in but the feedback I've gotten has mostly been > that it improves the dev/test cycle greatly. [...] I like both aschultz & dprince thoughts here, I agree with both of you on most of the points made here. I think we need to engage more efforts on CI (see what Alex wrote about milestone, we should try to respect that, it has proved to be helpful) & documentation as well (let's push doc before end of m2). If we can make CI & doc working before end of m2, it's at least a good step forward. Also, we could ship this feature as "experimental" in Queens and "stable" in Rocky (even if it has been developed since more than one cycle by dprince & co), I think it's a reasonable path for our users. -- 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] plans on testing minor updates?
On Thu, Sep 28, 2017 at 9:22 AM, Wesley Hayutin <whayu...@redhat.com> wrote: [...] > OK.. I think the solution is to start migrating these jobs to RDO Software > Factory third party testing. > > Here is what I propose: > 1. Start with an experiment check job > https://review.rdoproject.org/r/#/c/9823/ > This will help us confirm that everything works or fails as we expect. We > are > also afforded a configurable timeout \0/. It's currently set to 360 minutes > for the overcloud upgrade jobs. > > 2. Once this is proven out, we can run upgrade jobs as third party on any > review upstream > > 3. New coverage should be prototyped in RDO Software Factory > > 4. If jobs prove to be reliable and consistent and run under 170 minutes we > move what > we can back upstream. > > WDYT? I think this is mega cool, although your work is related to *Upgrades* and not minor updates but still super cool. Note: FTR we discussed on IRC that we would probably do the same kind of thing for minor updates testing. Thanks 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
Re: [openstack-dev] [tripleo] plans on testing minor updates?
On Thu, Sep 28, 2017 at 12:23 AM, Steven Hardy <sha...@redhat.com> wrote: [...] > > I completely agree we need this coverage, and honestly we should have > had it a long time ago, but we need to make progress on this last > critical blocker for pike, while continuing to make progress on the CI > coverage (which should certainly be a top priority for the Lifecycle > squad, as soon as we have this completely new-for-pike minor updates > workflow fully implemented and debugged). > > Thanks, > > Steve I guess my -2 was more to highlight the problem and make sure we take some actions. I removed it this morning and you're free to merge the code if you're happy with it. Several things: 1) I created https://bugs.launchpad.net/tripleo/+bug/1720153 to track work that will be done for this CI coverage, please use it when doing the work. 2) I'll allocate some time to work on it with the upgrade team. 3) Since we'll need a new job, I think we might remove some jobs that don't bring much value to keep. For example, the multinode baremetal jobs in Queens could be replaced by this container minor update testing, what do you think? 4) I wanted to point out (and repeat again from what we said at PTG and even before): we should get CI framework ready before implementing features like this. Every time we bring this up, I hear "now it's too late" or "we had no time to work on it". I understand the gap and the fast pace on the upgrade front, but I really think having more investment in CI will help on the long term. If upgrade folks need help on CI, bring it to the TripleO CI squad so they can maybe help, etc... 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] Newton End-Of-Life (EOL) next month (reminder #1)
On Wed, Sep 27, 2017 at 5:37 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Wed, Sep 27, 2017 at 10:39:13AM -0600, Alex Schultz wrote: > >> One idea would be to allow trailing projects additional trailing on >> the phases as well. Honestly 2 weeks for trailing for just GA is hard >> enough. Let alone the fact that the actual end-users are 18+ months >> behind. For some deployment project like tripleo, there are sections >> that should probably follow stable-policy as it exists today but >> elements where there's 3rd party integration or upgrade implications >> (in the case of tripleo, THT/puppet-tripleo) and they need to be more >> flexible to modify things as necessary. The word 'feature' isn't >> necessarily the same for these projects than something like >> nova/neutron/etc. > > There are 2 separate aspects here: > 1) What changes are appropriate on stable/* branches ; and > 2) How long to stable/* stay around for. > > Looking at 1. I totally get that deployment projects have a different > threshold on the bugfix/feature line. That's actually the easy part to > fix. The point of the stable policy is to give users some assurance > that moving from version x.y.z -> x.Y.Z will be a smooth process. We > just need to capture that intent in a policy that works in the context > of a deployment project. It makes total sense to me. BTW we have CI coverage for upgrades from Newton to Ocata (and Ocata to Pike is ongoing but super close; also Pike to Queens is targeted to Queens-1 milestone) so you can see our efforts on that front are pretty heavy. > Looking at 2. The stable policy doesn't say you *need* to EOL on > Oct-11th by default any project that asserts that tag is included but > you're also free to opt out as long as there is a good story around CI > and impact on human and machine resources. We re-evaluate that from > time to time. As an example, group-based-policy otpted out of the > kilo?, liberty and mitaka EOLs, recently dropped everything before > mitaka. I get that GBP has a different footprint in CI than tripleo > does but it illustrates that there is scope to support your users within > the current policy. Again, it makes a lot of sense here. We don't want to burn too much CI resources and keep strict minimum - also make sure we don't burn any external team (e.g. stable-maint). > I'm still advocating for crafting a more appropriate policy for > deployment projects. Cool, it's aligned with what Ben and Alex are proposing, iiuc. >> >> What proposing Giulio probably comes from the real world, the field, >> >> who actually manage OpenStack at scale and on real environments (not >> >> in devstack from master). If we can't have this code in-tree, we'll >> >> probably carry this patch downstream (which is IMHO bad because of >> >> maintenance and lack of CI). In that case, I'll vote to give up >> >> stable:follows-policy so we can do what we need. >> > >> > Rather than give up on the stable:follows policy tag it is possibly >> > worth looking at which portions of tripleo make that assertion. >> > >> > In this specific case, there isn't anything in the bug that indicates >> > it comes from a user report which is all the stable team has to go on >> > when making these types of decisions. >> > >> >> We'll need to re-evaulate what stable-policy means for tripleo. We >> don't want to allow the world for backporting but we also want to >> reduce the patches carried downstream for specific use cases. I think >> in the case of 3rd party integrations we need a better definition of >> what that means and perhaps creating a new repository like THT-extras >> that doesn't follow stable-policy while the main one does. > > Right, I don't pretend to understand the ins-and-outs of tripleo but yes > I think we're mostly agreeing on that point. > > https://review.openstack.org/#/c/507924/ buys everyone the space to make > that evaluation. > > Yours Tony. Thanks Tony for being open on the ideas; I find our discussion very productive despite the fact we want to give up the tag for now. So as a summary: 1) We discuss on 507924 to figure out yes/no we give up the tag and which repos we do it. 2) Someone to propose an amendment to the existing stable policy or propose a new policy. 3) Figure out if we can postpone TripleO Newton EOL and make sure we're doing it right (e.g. having CI jobs working, not burning anything etc). 4) On the long term, figure out how to break down THT (we'll probably want a blueprint for that and some folks working on 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] plans on testing minor updates?
I was reviewing https://review.openstack.org/#/c/487496/ and https://review.openstack.org/#/c/487488/ when I realized that we still didn't have any test coverage for minor updates. We never had this coverage AFICT but this is not a reason to not push forward it. During Ocata and Pike, we saw that having upgrade jobs were extremely useful to actually test the workflow that our users are supposed to do in production, I see zero reason to not doing the same for minor updates. I don't want to be the bad guy here but i've -2 the 2 patches until we find some consensus here (sorry matbu, it's not against you or your code in specific, but more generally speaking about re: implementing features without CI coverage). I'm really willing to help and start to work on tripleo-quickstart roles this week, if someone agrees to pair with me - so we could make progress and have that coverage. Even if the new job would fail, that's OK we know the process might work (or not, TBH, I haven't tried it, probably shardy and some other folks know more about it). Once we have the workflow in place, then iterate into matbu's patches and make it work in CI so we can ship it and be proud to have the feature tested. That's IMHO how we should write our software. If there is any feedback on this, please let us know here, otherwise I'll keep my -2 until we've got this coverage in place. Also please someone (maybe matbu?) raise your hand if you want to pair up and do this quickly. 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] Newton End-Of-Life (EOL) next month (reminder #1)
On Wed, Sep 27, 2017 at 9:39 AM, Alex Schultz <aschu...@redhat.com> wrote: [...] > We'll need to re-evaulate what stable-policy means for tripleo. We > don't want to allow the world for backporting but we also want to > reduce the patches carried downstream for specific use cases. I think > in the case of 3rd party integrations we need a better definition of > what that means and perhaps creating a new repository like THT-extras > that doesn't follow stable-policy while the main one does. Thanks Alex for the notes, while I agree with you, I proposed: https://review.openstack.org/507924 in the meantime. I'm not entirely sure about the THT-extras and the fact it would add another layer of complexity, but I'm happy to discuss about it. Tony, Alex, Steve, (others of course) - if you can look at the governance change and give feedback on it, that would help. 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] Newton End-Of-Life (EOL) next month (reminder #1)
On Tue, Sep 26, 2017 at 10:17 PM, Tony Breeds <t...@bakeyournoodle.com> wrote: > With that in mind I'd suggest that your review isn't appropriate for If we have to give up backports that help customers to get production-ready environments, I would consider giving up stable policy tag which probably doesn't fit for projects like installers. In a real world, users don't deploy master or Pike (even not Ocata) but are still on Liberty, and most of the time Newton. What proposing Giulio probably comes from the real world, the field, who actually manage OpenStack at scale and on real environments (not in devstack from master). If we can't have this code in-tree, we'll probably carry this patch downstream (which is IMHO bad because of maintenance and lack of CI). In that case, I'll vote to give up stable:follows-policy so we can do what we need. -- 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 End-Of-Life (EOL) next month (reminder #1)
Newton is officially EOL next month: https://releases.openstack.org/index.html#release-series As an action from our weekly meeting, we decided to accelerate the reviews for stable/newton before it's too late. This email is a reminder and a last reminder will be sent out before we EOL for real. If you need any help to get backport merged, please raise it here or ask on IRC as usual. -- 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] stable/pike gate is broken with containers
Today I found 2 issues: 1) https://bugs.launchpad.net/tripleo/+bug/1716256 http://logs.openstack.org/94/500794/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/c3e3945/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_14_49_29 I think we need this backport: https://review.openstack.org/#/c/502291 but it fails here: http://logs.openstack.org/91/502291/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/8140294/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_19_42_16 We probably missed some other backports. Can anyone familiar with this piece help? 2) https://bugs.launchpad.net/tripleo/+bug/1716280 stable/pike CI deploys Queens containers, tag is missing in Docker Registry. I'm cc'ing dprince because I think he has access to the dockerhub account, in case we need to do any change there. Thanks for the 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] TripleO Pike RC2 has been released
We released TripleO Pike RC2 today! Here are some numbers: 6 blueprints implemented (from FFE) 70 bugs fixed The release team will propose the final release based on this RC2 tag during the next days. We'll continue to work on Pike stabilization and doing bugfix backports. A new tag will be pushed to newton / ocata / pike every two weeks for now, which should help downstream releases as well. It has been a real pleasure for me to be PTL of TripleO during 2 cycles, I would like to thank everyone for the hard work and patience in difficult times. We have a bunch of challenges ahead but our team is awesome so I have no doubt we'll continue to succeed. Thanks, and enjoy the PTG for the lucky attendees! -- 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] [kolla] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility
On Fri, Sep 8, 2017 at 7:04 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > I know about wed meeting. This is when we wanted to discuss kolla-k8s and > tripleo shared resources, whatever they might be. I assumed Mon meeting is > different? So Monday is cross deployment projects collaboration meeting and Wednesday is whatever TripleO / Kolla collab related things. Does it make sense? -- 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] [kolla] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility
On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum <richwel...@gmail.com> wrote: > Triple-O team - can you please confirm the Monday slot, 2-4pm still works > for you? TripleO / Kolla interactions were scheduled on Wednesday morning in the TripleO room but I'm fine if you want to move it (just let us know). On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO, Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room and collaborate. All of this was scheduled a few days / weeks ago but we're happy to re-visit it. Please let us know though because it will confuse people otherwise. 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] all you need to know for PTG TripleO-related topics
If you use Google Calendar, you really want to use this one: https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics Or view in HTML here: https://calendar.google.com/calendar/embed?src=c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com=America/Denver Which contains an updated agenda for TripleO related topics. We'll track everything in this etherpad: https://etherpad.openstack.org/p/tripleo-ptg-queens I'm looking forward to seeing you folks! Have safe trips, -- 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] pingtest vs tempest
On Tue, Sep 5, 2017 at 11:35 PM, Giulio Fidente <gfide...@redhat.com> wrote: [...] > slightly OT but notable mention, scenario001/container is also the one > gating Ceph via ceph-ansible currently :D > > ... soon to convert scenario004/container as well Really good work Giulio and John to make that happen, thanks again for your 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] pingtest vs tempest
On Wed, Apr 5, 2017 at 1:49 PM, Emilien Macchi <emil...@redhat.com> wrote: [...] > == Solutions > > 1) Switch pingtest to Tempest run on some specific tests, with feature > parity of what we had with pingtest. > For example, we could imagine to run the scenarios that deploys VM and > boot from volume. It would test the same thing as pingtest (details > can be discussed here). > Each scenario would run more tests depending on the service that they > run (scenario001 is telemetry, so it would run some tempest tests for > Ceilometer, Aodh, Gnocchi, etc). > We should work at making the tempest run as short as possible, and the > close as possible from what we have with a pingtest. [...] 4 months later :-) We enabled Tempest on the following jobs: gate-tripleo-ci-centos-7-scenario001-multinode-oooq-container gate-tripleo-ci-centos-7-scenario002-multinode-oooq-container gate-tripleo-ci-centos-7-scenario003-multinode-oooq-container gate-tripleo-ci-centos-7-scenario004-multinode-oooq-container gate-tripleo-ci-centos-7-scenario001-multinode-oooq gate-tripleo-ci-centos-7-scenario002-multinode-oooq gate-tripleo-ci-centos-7-scenario003-multinode-oooq gate-tripleo-ci-centos-7-scenario004-multinode-oooq gate-tripleo-ci-centos-7-nonha-multinode-oooq gate-tripleo-ci-centos-7-containers-multinode It has a feature parity with what pingtest did. For example, scenario001 (focused on Telemetry) test boot from volume and the whole autoscsaling scenario from Telemetry services, so we can test end-to-end that our users can deploy autocsaling apps using OpenStack. We run Tempest on stable/pike and master, and still run pingtest on stable/newton and stable/ocata (no change is planned for stable branches). No change has been planned yet for OVB jobs but we might want to think about it later. You can go on http://status.openstack.org/openstack-health/#/job/gate-tripleo-ci-centos-7-scenario001-multinode-oooq-container and see stats as well. We also watched the amount of time spent on pingtest versus tempest and we knew tempest would take more time. It's the case and we've noticed the average is ~2 min more for now. It's acceptable I guess for now. Anyway, we hope this effort was useful and we can make progress to the next steps: - notify teams when some tests fail - increase test coverage depending on which services are deployed -- 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 meeting next week
We don't run the weekly meeting during the PTG, so next meeting is scheduled for September 19th. Safe travels, -- 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] Add support for Neutron NSX driver
On Tue, Sep 5, 2017 at 10:16 AM, Ben Nemec <openst...@nemebean.com> wrote: > > > On 09/04/2017 11:50 PM, Emilien Macchi wrote: >> >> On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu <lex...@gmail.com> wrote: >>> >>> Hi, >>> >>> In pike release, we added supported for Neutron NSX driver in TripleO [1] >>> by >>> the following patches. This will enable TripleO overcloud deployment to >>> use >>> vmware_nsx as Neutron core_plugin. >>> https://review.openstack.org/#/c/441668/ >>> https://review.openstack.org/#/c/452047/ >>> https://review.openstack.org/#/c/452391/ >>> >>> However, there are some critical issues which prevent it from functional >>> correctly, and we fixed them in master with the following patches. >>> https://review.openstack.org/#/c/499395/ >>> https://review.openstack.org/#/c/498143/ >>> https://review.openstack.org/#/c/498142/ >>> >>> Can we merged these patches and back port to pike? >> >> >> So if we follow all the rules, it goes against how to we handle stable >> branches and release management in general. > > > I don't know that I agree. These patches are all for a feature that merged > earlier in Pike, but apparently is broken. The only real issue I see is > that the first one doesn't have a bug reference and thus isn't valid for > backport as-is. That one might need further discussion, but the others seem > to be legitimate bug fixes. > > I also don't see any blueprint references, so I'm not sure how that came > into the discussion. Maybe some confusion about the process for FFE's vs. > bugs? It doesn't appear to me that a bp should be needed for these changes, > but maybe I'm missing something. In that case let's threat them as bug fixes and let's do the backports to stable/pike. > >> >> Usually what happens is we discuss about blueprints at PTG and then >> during the cycle developers implement the blueprints. >> Sometimes some blueprint get deferred for some reason (quite often >> it's because of overcommit but that's a separated topic) so they can >> as for FFE (feature freeze exception), granted by the PTL. >> >> In your case, it's a bit more complex. You created the blueprint a few >> days before final release of Pike and you're asking us to merge the >> code AND backport it to Pike. >> That's for the facts & context, hope it helps to understand why this >> request is tricky. >> >> Now you're a vendor and you're helping to support your driver, which is >> good. >> >> We'll need to evaluate each commit and see if they are backward >> compatible and actually don't beak any interface (because we want our >> stable branches stable). >> >> I'm ok to make an exception if next time you can do a better job in >> scheduling the work that will be done during one cycle. >> The way we propose blueprint is really lightweight, and in the open, >> so really no complication here. >> >> >> For now, most of the team is quite busy on Pike release (and PTG >> coming next week), so I'm not sure your patches will be reviewed soon >> (if yes, that's good). >> For the backports, we'll have to evaluate case by case and see if it's >> possible. >> >> Thanks for your work and we hope our collaboration can happen earlier >> the next time. >> >>> Thanks, >>> Tong >>> [1] Blueprint: >>> https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver >> >> >> > -- 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] Add Mohammed Naser to cores
+1 - thanks for stepping up and all your contributions :-) On Tue, Sep 5, 2017 at 8:45 AM, Iury Gregory <iurygreg...@gmail.com> wrote: > +1 =) > And also Tks for running for PTL Mohammed > > On Sep 5, 2017 12:43, "Alex Schultz" <aschu...@redhat.com> wrote: >> >> Hey folks, >> >> I'm writing to ask that we add mnaser to the cores list for the puppet >> modules. He's been a user and contributor for some time and is also >> the new PTL. Let me know if there are any objections. >> >> Thanks, >> -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] [tripleo] Add support for Neutron NSX driver
On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu <lex...@gmail.com> wrote: > Hi, > > In pike release, we added supported for Neutron NSX driver in TripleO [1] by > the following patches. This will enable TripleO overcloud deployment to use > vmware_nsx as Neutron core_plugin. > https://review.openstack.org/#/c/441668/ > https://review.openstack.org/#/c/452047/ > https://review.openstack.org/#/c/452391/ > > However, there are some critical issues which prevent it from functional > correctly, and we fixed them in master with the following patches. > https://review.openstack.org/#/c/499395/ > https://review.openstack.org/#/c/498143/ > https://review.openstack.org/#/c/498142/ > > Can we merged these patches and back port to pike? So if we follow all the rules, it goes against how to we handle stable branches and release management in general. Usually what happens is we discuss about blueprints at PTG and then during the cycle developers implement the blueprints. Sometimes some blueprint get deferred for some reason (quite often it's because of overcommit but that's a separated topic) so they can as for FFE (feature freeze exception), granted by the PTL. In your case, it's a bit more complex. You created the blueprint a few days before final release of Pike and you're asking us to merge the code AND backport it to Pike. That's for the facts & context, hope it helps to understand why this request is tricky. Now you're a vendor and you're helping to support your driver, which is good. We'll need to evaluate each commit and see if they are backward compatible and actually don't beak any interface (because we want our stable branches stable). I'm ok to make an exception if next time you can do a better job in scheduling the work that will be done during one cycle. The way we propose blueprint is really lightweight, and in the open, so really no complication here. For now, most of the team is quite busy on Pike release (and PTG coming next week), so I'm not sure your patches will be reviewed soon (if yes, that's good). For the backports, we'll have to evaluate case by case and see if it's possible. Thanks for your work and we hope our collaboration can happen earlier the next time. > Thanks, > Tong > [1] Blueprint: > https://blueprints.launchpad.net/tripleo/+spec/neutron-nsx-driver -- 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] Pike final release - blockers & priorities
On Sun, Sep 3, 2017 at 7:40 PM, Emilien Macchi <emil...@redhat.com> wrote: > Here are the priorities and blockers so we can release final Pike. > If you have any question, or think I missed something, or have any > comment, please reply to this thread. > Also, your help is critical for TripleO team to release the final > version of Pike. > I would like to set a target on Friday 8th (before the PTG) but the > hard limit is actually in ~10 days, so we will see how it goes by > Thursday 7th and take the decision there. > > ## Upgrades from Ocata to Pike > > I'm using this patch to test upgrades: > https://review.openstack.org/#/c/461000/ > At the time I'm writing this, > https://bugs.launchpad.net/tripleo/+bug/1714412 is still open and > remains the major blocker for upgrades. > Folks familiar with upgrades process should help Mathieu Bultel to > finish the upgrade documentation as soon as possible: > https://review.openstack.org/#/c/496223/ A last update before I'm afk: https://review.openstack.org/#/c/493391/ merged and gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv passed. Which means we have the upgrade workflow in place again. Martin, I've been tested https://review.openstack.org/#/c/500364/ with https://review.openstack.org/#/c/461000/ and it fails on all scenarios because it tries to deploy containers when deploying Ocata. See http://logs.openstack.org/00/461000/54/check/gate-tripleo-ci-centos-7-scenario002-multinode-oooq-container-upgrades-nv/f3a1eac/logs/undercloud/home/jenkins/overcloud_deploy.log.txt.gz#_2017-09-04_02_46_41 I'm going a recheck on https://review.openstack.org/#/c/500145 to see how things are on stable/pike. So this is where we are: - containers-multinode-upgrades-nv pass with pingtest but timeouts very often (the job is very long indeed) - I'm trying to enable tempest on this job, just to see how it works: https://review.openstack.org/#/c/500440/ - container scenarios upgrade failed with https://review.openstack.org/#/c/461000/ but not sure without - not sure about how it works on stable/pike Note: oice upgrade job pass on stable/pike, we'll want to make them voting like we did for Ocata. I'll let Steve Baker post an update after our chat on IRC today. > ## Last standing blueprint: > https://blueprints.launchpad.net/tripleo/+spec/websocket-logging > https://review.openstack.org/#/c/469608/ is the last patch but right > now has negative review and doesn't pass CI. > Hopefully we can make some progress this week. > > > We'll probably have more backports to do after final pike, but that's > fine, please use launchpad bugs when you do backports though. > We're almost there! Thanks all for the help, > -- > 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] Pike final release - blockers & priorities
Here are the priorities and blockers so we can release final Pike. If you have any question, or think I missed something, or have any comment, please reply to this thread. Also, your help is critical for TripleO team to release the final version of Pike. I would like to set a target on Friday 8th (before the PTG) but the hard limit is actually in ~10 days, so we will see how it goes by Thursday 7th and take the decision there. ## Upgrades from Ocata to Pike I'm using this patch to test upgrades: https://review.openstack.org/#/c/461000/ At the time I'm writing this, https://bugs.launchpad.net/tripleo/+bug/1714412 is still open and remains the major blocker for upgrades. Folks familiar with upgrades process should help Mathieu Bultel to finish the upgrade documentation as soon as possible: https://review.openstack.org/#/c/496223/ ## Last standing blueprint: https://blueprints.launchpad.net/tripleo/+spec/websocket-logging https://review.openstack.org/#/c/469608/ is the last patch but right now has negative review and doesn't pass CI. Hopefully we can make some progress this week. We'll probably have more backports to do after final pike, but that's fine, please use launchpad bugs when you do backports though. We're almost there! Thanks all for the 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] question about healthcheck
Can someone explain me (sorry for the dumb question) why do we force healthcheck to be positive when deploying TripleO containers? healthcheck: test: /bin/true https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/keystone.yaml#L180-L181 Instead of real checks? I probably missed something (it's WIP?) but I found useful to clarify now, since we're about to release final Pike. 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] Gate is broken - Do not approve any patch until further notice
On Fri, Sep 1, 2017 at 8:27 AM, Marios Andreou <mandr...@redhat.com> wrote: > I don't think this ^^ patch is what causes/ed that bug, at least I haven't > found or seen that this is the case. As we discussed a bit on Wednesday > evening, if you see the elastic-recheck query @ > http://status.openstack.org/elastic-recheck/#1713832 the issue was seen > twice in the last 24 hours and 5 times since the revert landed early > Wednesday EU morning. I think that's roughly the same rate it was being seen > before and after my patch was reverted. > > Do you think we can now consider landing that again with > https://review.openstack.org/#/c/499116/ please ? At that point I would say no. We have been merging so many stuffs lately because of release that we don't even know why this thing broke. Is it in Zaqar? In Swift? In TripleO? So yeah maybe it's not your patch but it's maybe related or maybe not. Since nobody is able to tell it, I would suggest to not revert the revert until we find the root cause and we fix it. Because if we don't do that, we'll merge your patch again and eventually increase the number of hits in the gate which is something we don't want at this stage. When we discussed you told me this patch wasn't a requirement to upgrade but an enhancement. At this stage of the cycle we are looking for stability and not for enhancements, I hope you understand that. It's a difficult choice to make for me but I'll prefer us to fix bugs before we continue to merge new features from now. Keep in mind feature freeze and why we're doing this. > I also see you assigned me that bug - I'll try and have another look at it > next week but we may want to reach out to someone from zaqar see if they > have any ideas about why that happens. Thank you, that would be very helpful. -- 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] PTG Agenda draft - action required
On Fri, Sep 1, 2017 at 6:20 AM, Giulio Fidente <gfide...@redhat.com> wrote: [...] > roger, I have added to the thursday afternoon a 1h slot to discuss future > developments around Ceph integration > > specifically three topics: > > - is use of jinja to create multiple ceph clusters a good idea? > - upgrade ceph to luminous (maybe also in Kolla) > - support multiple ceph-pools for cinder-volume Cool works for me. Kolla PTL in CC, to make sure it's visible. Michal, can you join you think? and some from your team? > ack, will do and add links to the etherpad to some LP blueprints > > thanks Emilien for setting everything up :D I appreciate your help in doing the agenda :-) -- 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] PTG Agenda draft - action required
On Thu, Aug 31, 2017 at 10:27 AM, Emilien Macchi <emil...@redhat.com> wrote: [...] > I'm preparing a Google Calendar today, so everyone can easily > understand the schedule. I prepared this public agenda: https://calendar.google.com/calendar/ical/c1g5npdrsd3p37ods24s19gg0g%40group.calendar.google.com/public/basic.ics That anyone can subscribe. Hope it 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] PTG Agenda draft - action required
I brought some changes in the schedule: - On Wednesday morning, we'll start at 9am and do a one hour retrospective to discuss what went wrong and good in Pike, and see how we can do better in Queens. Alex an I will animate this retro. - Which means, CI topics will be split in 2 times: from 10am to 11am (don't forget to stay in the room after 11am to collaborate with Kolla) and also on the afternoon from 1.45pm to 3pm. I think it's enough time. - Heat / Mistral sessions from 3pm to 5.30pm. I don't count the breaks but we'll figure. I'm preparing a Google Calendar today, so everyone can easily understand the schedule. Any feedback / comment is welcome, thanks. On Tue, Aug 29, 2017 at 8:36 AM, Emilien Macchi <emil...@redhat.com> wrote: > On Mon, Aug 28, 2017 at 3:17 PM, Emilien Macchi <emil...@redhat.com> wrote: > [...] >> Also, it's still time to propose topics, please go ahead and >> contribute to the etherpad. We'll review the schedule before the PTG >> (probably during our weekly meetings tomorrow and next week). > [...] > > I forgot to remind folks that PTG is a very good time to discuss about > blueprints, as we want to schedule together what we do in the next > cycle. > Which means, please be prepared and create blueprints / specs (even > drafts) prior to the PTG, so we have some support that we can use for > scheduling and discussions. > > Thanks a lot, > -- > 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] Gate is broken - Do not approve any patch until further notice
On Tue, Aug 29, 2017 at 4:17 PM, Emilien Macchi <emil...@redhat.com> wrote: > We are currently dealing with 4 issues and until they are fix, please > do not approve any patch. We want to keep the gate clear to merge the > fixes for the 4 problems first. > > 1) devstack-gate broke us because we use it as a library (bad) > https://bugs.launchpad.net/tripleo/+bug/1713868 > > 2) https://review.openstack.org/#/c/474578/ broke us and we're > reverting it https://bugs.launchpad.net/tripleo/+bug/1713832 > > 3) We shouldn't build images on multinode jobs > https://bugs.launchpad.net/tripleo/+bug/1713167 > > 4) We should use pip instead of git for delorean > https://bugs.launchpad.net/tripleo/+bug/1708832 > > > Until further notice from Alex or myself, please do not approve any patch. The 4 problems have been mitigated. You can now proceed to normal review. Please do not recheck a patch without an elastic-recheck comment, we need to track all issues related to CI from now. Paul Belanger has been doing extremely useful work to help us, now let's use elastic-recheck more and stop blind rechecks. All known issues are in http://status.openstack.org/elastic-recheck/ If one is missing, you're welcome to contribute by sending a patch to elastic-recheck. Example with https://review.openstack.org/#/c/498954/ I've restored all patches that were killed from the gate and did recheck already, hopefully we can get some merges and finish this release. Thanks Paul and all Infra for their consistent 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] Gate is broken - Do not approve any patch until further notice
We are currently dealing with 4 issues and until they are fix, please do not approve any patch. We want to keep the gate clear to merge the fixes for the 4 problems first. 1) devstack-gate broke us because we use it as a library (bad) https://bugs.launchpad.net/tripleo/+bug/1713868 2) https://review.openstack.org/#/c/474578/ broke us and we're reverting it https://bugs.launchpad.net/tripleo/+bug/1713832 3) We shouldn't build images on multinode jobs https://bugs.launchpad.net/tripleo/+bug/1713167 4) We should use pip instead of git for delorean https://bugs.launchpad.net/tripleo/+bug/1708832 Until further notice from Alex or myself, please do not approve any patch. 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] PTG Agenda draft - action required
On Mon, Aug 28, 2017 at 3:17 PM, Emilien Macchi <emil...@redhat.com> wrote: [...] > Also, it's still time to propose topics, please go ahead and > contribute to the etherpad. We'll review the schedule before the PTG > (probably during our weekly meetings tomorrow and next week). [...] I forgot to remind folks that PTG is a very good time to discuss about blueprints, as we want to schedule together what we do in the next cycle. Which means, please be prepared and create blueprints / specs (even drafts) prior to the PTG, so we have some support that we can use for scheduling and discussions. Thanks a lot, -- 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] Pacemaker + containers CI
On Tue, Aug 29, 2017 at 2:14 AM, Jiří Stránský <ji...@redhat.com> wrote: [...] > the CI for containerized deployments with Pacemaker is close! In fact, it > works [1][2] (but there are pending changes to merge). Really good news, thanks for the update! > The way it's proposed in gerrit currently is to switch the > centos-7-containers-multinode job (featureset010) to deploy with Pacemaker. > What do you think about making this switch as a first step? [...] I'm ok with the idea as long as gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv keep working fine. Deploying Pacemaker on a single node environment is not optimal but already cover a bunch of code which is good. > Later it would be nice to get a proper clustering test with 3 controllers. > Should we try and switch the centos-7-ovb-ha-oooq job to deploy containers > on master and stable/pike? (Probably by adding a new job that only runs on > master + Pike, and making the old ovb-ha-oooq only run upto Ocata, to keep > the OVB capacity demands unchanged?) I'd be +1 on that since containers are > the intended way of deploying Pike and beyond. WDYT? It's actually a good start to our discussion at the PTG: https://etherpad.openstack.org/p/tripleo-ptg-queens-ci-related-topics (we have a session on Wednesday morning about CI topics, please make sure you can join!) I think in Queens, we'll run container-only jobs, even for OVB. That said, I think OVB coverage in Queens will be very useful to try HA with 3 controllers (containerized) and the baremetal services coverage will only run on Pike, Ocata and Newton. That way, we would have: Queens: - multinode jobs covering basic HA scenario, single node but still useful to test a good part of the code - OVB jobs covering production environment and hopefully spot issues we wouldn't see with multinode jobs Pike, Ocata, Newton: no change on OVB job (note it's a proposal, not a statement) [...] > [3] https://review.openstack.org/498474 approved [...] 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] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG
On Fri, Aug 25, 2017 at 5:00 PM, Emilien Macchi <emil...@redhat.com> wrote: > I created an etherpad: https://etherpad.openstack.org/p/deployment-queens > > Please bring topics (and names) - we'll try to be prepared before the > PTG with an agenda and some scheduling. I think being together in a room during ~2h would be a good start (if we need more we can figure that out during the session). My hope is we can create some ad-hoc collaborations between projects without having everyone involved at the same time. I don't have any specific schedule on the Monday & Tuesday (I'll be walking between rooms and see where I can contribute) - we might want to block a 2h slot in our agenda to make sure we can meet. Let's try with Monday 2pm in the Packaging room (dedicated to Deployment Tools). So we still have the Tuesday in case we need more sessions together. I would like to see people from TripleO, Kolla, OpenStack Ansible, OpenStack Helm (at minimum) signing up on https://etherpad.openstack.org/p/deployment-queens and confirming (or not) that schedule would work. 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] PTG Agenda draft - action required
Please look https://etherpad.openstack.org/p/tripleo-ptg-queens and tell us (in private or here) if there is any conflict with your agenda. This is a draft, a proposal, we can make any change as long as we have the feedback. Also, it's still time to propose topics, please go ahead and contribute to the etherpad. We'll review the schedule before the PTG (probably during our weekly meetings tomorrow and next week). 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] CI design session at the PTG
On Mon, Aug 28, 2017 at 6:42 AM, David Moreau Simard <d...@redhat.com> wrote: [...] > Can we have a formal session on this scheduled somewhere ? Yeah, this session would be interesting to do. Feel free to add it on https://etherpad.openstack.org/p/tripleo-ptg-queens We need to work on scheduling before the PTG but it would likely happen between Wednesday and Friday morning. 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] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG
I created an etherpad: https://etherpad.openstack.org/p/deployment-queens Please bring topics (and names) - we'll try to be prepared before the PTG with an agenda and some scheduling. Thanks, On Fri, Aug 25, 2017 at 4:19 PM, Michał Jastrzębski <inc...@gmail.com> wrote: > We (Kolla) planned some time for that discussion:) It would be awesome > if we could have them on Mon-Tue, because Wed-Fri we'll have > kolla-specific design room. That being said if needed we can use it > for our cross-community discussions. > > Biggest one for me is new direction of tripleo (k8s+ansible) and how > that corresponds to kolla-k8s (k8s+ansible). > > On 25 August 2017 at 15:53, Jean-Philippe Evrard > <jean-phili...@evrard.me> wrote: >> Hello Emilien, >> >> The Discussion room is a good idea. I like it. >> Most of the OpenStack-Ansible crew will be available the whole week, so we >> can even think of doing a conversation outside the Wed-Friday timeframe. >> >> If you/we all have enough time, maybe we could organise two sessions, >> probably with different formats? >> For example, a brainstorming session about how we collaborated on previous >> cycles and how we could collaborate in the future, and another session with >> the real action points based on the first conversation? >> >> On top of that, I have extra points I'd like to discuss with you: >> - Architecture of LB + web server + uwsgi >> - Possibility of sharing infrastructure (mariadb/rabbitmq/...) >> experience/code between projects. >> >> Thank you in advance. >> >> Best regards, >> JP >> >> On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi <emil...@redhat.com> wrote: >>> >>> Cool, sounds like some people are interested (I haven't hear from >>> Kolla yet but I'm sure they are as well). >>> >>> I was wondering if we should take benefit of Discussion Rooms, useful >>> for inter-projects topics: >>> https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms >>> >>> There is still some place, let me know what you think and we can block >>> a slot (maybe 2h?) >>> I want to hear from Kolla and OpenStack Ansible at least and know if >>> you have schedule constraints otherwise I'll go ahead and block a >>> slot. >>> >>> Thanks, >>> >>> On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco <fla...@redhat.com> wrote: >>> > On 17/08/17 10:24 -0500, Major Hayden wrote: >>> >> >>> >> On 08/17/2017 09:30 AM, Emilien Macchi wrote: >>> >>> >>> >>> If you're working on Kolla / OpenStack-Ansible - please let us know if >>> >>> you have specific constraints on the schedule, so we can maybe block a >>> >>> timeslot in the agenda from now. >>> >>> We'll have a "Packaging" room which is reserved for all topics related >>> >>> to OpenStack deployments, so we can use this one. >>> >> >>> >> >>> >> I don't have any constraints (that I'm aware of), but I'd be interested >>> >> in >>> >> participating! Performance in the gate jobs has been one of my tasks >>> >> lately >>> >> and I'd like to see if we can collaborate there to make improvements >>> >> without >>> >> ruining infra's day. ;) >>> >> >>> >> As long as you can put up with a few Dad jokes, I'll be there. >>> > >>> > >>> > ++ I'm interested in this topic too! >>> > >>> > Flavio >>> > >>> > -- >>> > @flaper87 >>> > Flavio Percoco >>> > >>> > >>> > __ >>> > 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 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
