Re: [openstack-dev] Building Openstack Trove Images
Hi Amrith, Many Thanks for your response. Hope you are doing well! The confusing part here is that the OpenStack tutorial page itself not seems to be updated https://docs.openstack.org/trove/latest/admin/building_guest_images.html#build-guest-images as the *dib-lint* file is there instead of the mentioned *disk-image-create *and when executed just verifies the other elements. I have also tried using https://github.com/denismakogon/trove-guest-image-elements but the error on which I got stuck is “deltarpm not installed” (deltarpm is installed on the host machine). Though yesterday, I came across the https://github.com/openstack/trove-integration which I am going to try out today, kindly let me know if it is the right one or please share any relevant reference on which we can work. Regards, Ritesh On Tue, Nov 7, 2017 at 8:16 AM, Amrith Kumar wrote: > Ha, it isn't often that I get called out by name in a mailing list thread. > > What are the issues that you are facing? Currently there are complete > notes about how to build guest images but the issues you may be facing may > not relate to the images you are building. > > So please provide some more details so I can give you a more accurate > reply. > > Thanks, > > > -amrith > > > On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma < > ritesh.vishwaka...@indusnet.co.in> wrote: > >> Hi Team, >> >> We have installed Openstack Pike in our campus but despite of numerous >> attempts we are just unable to build trove images that we can use to launch >> database instances.We also came across a mail thread where Mr. Amrith >> updates that some review & update of the OpenStack Trove documents was >> going on, kindly provide us some reference document or link which we can >> follow. >> >> https://lists.gt.net/openstack/dev/58182 >> >> We will be eagerly waiting for your response. >> >> >> >> Thanks & Regards, >> Ritesh Vishwakarma >> >> >> __ >> 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] Building Openstack Trove Images
Many thanks Andy for your support, I will surely go through it. Regards, Ritesh On Tue, Nov 7, 2017 at 4:01 AM, Andy Botting wrote: > Hi Ritesh, > > I also found it difficult to build Trove images. We had some > infrastructure already set up for building other images, so we used that > for our Trove images, rather than the OpenStack disk image builder. > > We decided to use Ubuntu Xenial (although not supported in Trove at the > time) with MySQL and PostgreSQL with Ansible roles. > > The interesting parts are here: > https://github.com/NeCTAR-RC/nectar-images/tree/master/ansible/roles/trove > > Hope this helps. > > cheers, > Andy > > > On 6 November 2017 at 18:09, Ritesh Vishwakarma < > ritesh.vishwaka...@indusnet.co.in> wrote: > >> Hi Team, >> >> We have installed Openstack Pike in our campus but despite of numerous >> attempts we are just unable to build trove images that we can use to launch >> database instances.We also came across a mail thread where Mr. Amrith >> updates that some review & update of the OpenStack Trove documents was >> going on, kindly provide us some reference document or link which we can >> follow. >> >> https://lists.gt.net/openstack/dev/58182 >> >> We will be eagerly waiting for your response. >> >> >> >> Thanks & Regards, >> Ritesh Vishwakarma >> >> >> __ >> 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] 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 wrote: > On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin wrote: >> >> >> On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya wrote: >>> >>> On 11/6/17 1:01 AM, Emilien Macchi wrote: On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince 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, > l
Re: [openstack-dev] Building Openstack Trove Images
Ha, it isn't often that I get called out by name in a mailing list thread. What are the issues that you are facing? Currently there are complete notes about how to build guest images but the issues you may be facing may not relate to the images you are building. So please provide some more details so I can give you a more accurate reply. Thanks, -amrith On Mon, Nov 6, 2017 at 6:09 PM, Ritesh Vishwakarma < ritesh.vishwaka...@indusnet.co.in> wrote: > Hi Team, > > We have installed Openstack Pike in our campus but despite of numerous > attempts we are just unable to build trove images that we can use to launch > database instances.We also came across a mail thread where Mr. Amrith > updates that some review & update of the OpenStack Trove documents was > going on, kindly provide us some reference document or link which we can > follow. > > https://lists.gt.net/openstack/dev/58182 > > We will be eagerly waiting for your response. > > > > Thanks & Regards, > Ritesh Vishwakarma > > __ > 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] containerized undercloud in Queens
On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin wrote: > > > On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya wrote: >> >> On 11/6/17 1:01 AM, Emilien Macchi wrote: >>> >>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince 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ý 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 >>> wrote: >>> On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi 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
[openstack-dev] Free documentation using Sphinx extensions
As part of the documentation onboarding session this morning, we gave a small talk on how people can actually avoid writing documentation (or rather use the documentation they have already stored in their code). There seems to be a general lack of awareness about these tools and I've uploaded the slides to SpeakerDeck in the hopes of closing this gap. You can find them here: https://speakerdeck.com/stephenfin/openstack-plus-sphinx-in-a-tree Feel free to reach out to me on IRC (stephenfin) or contact any of the docs team on #openstack-doc if you've any questions or suggestions for these tools. Stephen __ 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 11/06/2017 01:44 PM, Emilien Macchi wrote: > On Mon, Nov 6, 2017 at 6:32 AM, Honza Pokorny 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 > +1 thanks Honza, and thanks Ana for your awesome contributions all over the place __ 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] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
Excerpts from Juan Antonio Osorio's message of 2017-11-06 15:18:33 +0200: > Proposed a patch to be able to enable the JSON formatter via an oslo.log > configuration parameter: > > https://review.openstack.org/#/c/517882/ That's approved, thanks! We should make sure we have a release note before we tag a new release of the library, though. Could you do that in another patch? Doug __ 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] Building Openstack Trove Images
Hi Ritesh, I also found it difficult to build Trove images. We had some infrastructure already set up for building other images, so we used that for our Trove images, rather than the OpenStack disk image builder. We decided to use Ubuntu Xenial (although not supported in Trove at the time) with MySQL and PostgreSQL with Ansible roles. The interesting parts are here: https://github.com/NeCTAR-RC/nectar-images/tree/master/ansible/roles/trove Hope this helps. cheers, Andy On 6 November 2017 at 18:09, Ritesh Vishwakarma < ritesh.vishwaka...@indusnet.co.in> wrote: > Hi Team, > > We have installed Openstack Pike in our campus but despite of numerous > attempts we are just unable to build trove images that we can use to launch > database instances.We also came across a mail thread where Mr. Amrith > updates that some review & update of the OpenStack Trove documents was > going on, kindly provide us some reference document or link which we can > follow. > > https://lists.gt.net/openstack/dev/58182 > > We will be eagerly waiting for your response. > > > > Thanks & Regards, > Ritesh Vishwakarma > > __ > 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] containerized undercloud in Queens
On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya wrote: > On 11/6/17 1:01 AM, Emilien Macchi wrote: > >> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince 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 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 __ 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 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 wrote: > On 11/6/17 1:01 AM, Emilien Macchi wrote: >> >> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince 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] undercloud containers with SELinux Enforcing
So the rule of thumb I propose is "if a container bind-mounts /run (/var/run), make it privileged to not mess with SELinux enforcing". I've yet to found better alternatives to allow containers access the host sockets. Additionally, the patch allows developers of t-h-t docker/services to not guess and repeat :z flags for generic /var/lib/, /etc/puppet/, /usr/share/openstack-puppet/modules and /var/log/containers/ paths for services as the wanted context for those will be configured at the deploy steps tasks [0], and the docker-puppet.py tool [1]. That kind of follows DRY the best. I hope that works. [0] https://review.openstack.org/#/c/513669/11/common/deploy-steps.j2 [1] https://review.openstack.org/#/c/513669/12/docker/docker-puppet.py@277 On 11/6/17 2:49 PM, Bogdan Dobrelya wrote: Hi. I've made some progress with containerized undercloud deployment guide and SELinux enforcing ( the bug [0] and the topic [1] ). Although I'm now completely stuck [2] with fixing t-h-t's docker/services to nail the selinux thing fully, including the containerized *overclouds* part. The main issue is to make some of the host-path volumes bind-mounted, like /run:/run and /dev:/dev, selinux friendly. Any help is appreciated! Hello folks. I need your feedback please on SELinux fixes [0] (or rather workarounds) for containerized undercloud feature, which is experimental in Pike. [TL;DR] The problem I'm trying to solve is primarily allowing TripleO users to follow the guide [1] w/o telling them "please disable SELinux". Especially, given the note "The undercloud is intended to work correctly with SELinux enforcing, and cannot be installed to a system with SELinux disabled". I understand that putting "chcon -Rt svirt_sandbox_file_t -l s0" (see [2]) to all of the host paths bind-mounted into containers is not secure, and from SELinux perspective allows everything to all containers. That could be a first step for docker volumes working w/o shutting down SELinux on *hosts* though. I plan to use the same approach for the t-h-t docker/services host-prep tasks as well. Why not using docker's :z :Z directly? IIUC, it doesn't allow combine with other mount flags, like :ro:z won't work. I look forward for better solutions and ideas! [0] https://review.openstack.org/#/q/topic:bug/1682179 [1] https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/undercloud.html [2] https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/ [0] https://bugs.launchpad.net/tripleo/+bug/1682179 [1] https://review.openstack.org/#/q/topic:bug/1682179 [2] https://review.openstack.org/#/c/517383/ -- 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
Re: [openstack-dev] [octavia] how to recreate amphora instances
I think we helped you get going again in the IRC channel. Please ping us again in the IRC channel if you need more assistance. Michael On Thu, Nov 2, 2017 at 4:42 AM, Kim-Norman Sahm wrote: > Hi, > > after a rabbitmq problem octavia has removed all amphora instances. > the loadbalancers are in provisioning_status "ACTIVE" > > ~$ neutron lbaas-loadbalancer-list > neutron CLI is deprecated and will be removed in the future. Use > openstack CLI instead. > | 07b41df6-bb75-4502-975a-20140b0832dd | Load Balancer > 4 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.18 | ACTIVE | octavia | > | 25664be7-15cb-426b-ad09-6102afb62b14 | Load Balancer > 2 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.7| ACTIVE | octavia | > | 927eb754-7c52-4060-b130-1f5e82d92555 | Load Balancer > 6 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.17 | ACTIVE | octavia | > | b4d93c68-89d6-4e4f-b06c-117d4ea933fa | Load Balancer > 5 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.24 | ACTIVE | octavia | > | d7699f8d-2106-42d6-8797-5feb72de6e2e | Load Balancer > 1 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.5| ACTIVE | octavia | > | dd6114ae-21e9-41bd-b155-325287aed420 | Load Balancer > 3 | 260b0c452e214accaf6cc0e98fb10fc0 | > 192.168.1.23 | ACTIVE | octavia | > > How can we trigger octavia to rebuild the amphore instances? > I've tried to restart the octavia services but it didn't solved the > problem. > > Best regards > Kim > > > Kim-Norman Sahm > Cloud & Infrastructure(OCI) > noris network AG > Thomas-Mann-Straße 16-20 > 90471 Nürnberg > Deutschland > Tel +49 911 9352 1433 > Fax +49 911 9352 100 > > kim-norman.s...@noris.de > https://www.noris.de - Mehr Leistung als Standard > Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel > Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 > > > > > > __ > 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-dev] [nova] Notification update week 45
Hi, Here is the status update / focus settings mail for w45 Bugs [Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration of 'notify_on_state_change' are different from implementation As the behavior is unchanged in the last 5 years a patch is proposed to update the documentation to reflect this long standing behavior. The solution only needs a second +2: https://review.openstack.org/516264 Versioned notification transformation - As the last week's 3 patches have been merged, so this week we will try 4 patches :) * https://review.openstack.org/#/c/482070 Transform instance-live_migration_pre notification * https://review.openstack.org/#/c/420453 Transform instance-live_migration_abort notification * https://review.openstack.org/#/c/410297 Transform missing delete notifications * https://review.openstack.org/#/c/476459 Send soft_delete from context manager Service create and destroy notifications https://blueprints.launchpad.net/nova/+spec/service-create-destroy-notification https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/service-create-destroy-notification.html Still waiting for the implementation to be proposed. Small improvements -- * https://review.openstack.org/#/q/topic:refactor-notification-samples Factor out duplicated notification sample data The series are up to date and show the way how to drastically decrease the amount of json sample data stored in the nova tree. Weekly meeting -- This week's meeting is cancelled due to the Forum in Sydney. Next subteam meeting will be held on 14th of November, Tuesday 17:00 UTC on openstack-meeting-4. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171114T17 Cheers, gibi __ 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 Ci Squad meeting
Hello, A little bit late but here’s the highlights from TripleO CI Squad meeting from October 26 - Roles - The Ruck and the Rover will be responsible for any CI problems, so if you have anything related to CI, please contact them. The rest of the team will work on the sprint - Ruck - Gabrielle Cerami, irc: panda|ruck - Rover - Attila Darazs, irc: adarazs|rover - Backup - Ronelly Landy, irc rlandy - Matt Young, irc myoung - Team - Arx Cruz - Ronelle Landy - Sagi Shnaidman - John Trowbridge - For this sprint 10/26/2017 - 11/8/2017 - After review the proposed topics from the UA, the team voted to work on Reproduce of upstream CI jobs against RDO cloud personal tenant - The epic task with more information can be found here https://trello.com/c/aPuHTfo4/404-reproduce-of-upstream-ci-jobs-against-rdo-cloud-personal-tenant - Tasks can be found in both the trello card above, or in the TripleO CI Squad trello board using the filter by label “Sprint 3 ( Oct 26 - Nov 8)” or clicking in this link here https://tinyurl.com/ybfds8p3 If you have any questions, suggestions please let us know. Your feedback is very important to us! Kind regards, Arx Cruz __ 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] Nominate akrivoka for tripleo-validations core
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. Thanks Honza Pokorny __ 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] undercloud containers with SELinux Enforcing
Hi. I've made some progress with containerized undercloud deployment guide and SELinux enforcing ( the bug [0] and the topic [1] ). Although I'm now completely stuck [2] with fixing t-h-t's docker/services to nail the selinux thing fully, including the containerized *overclouds* part. The main issue is to make some of the host-path volumes bind-mounted, like /run:/run and /dev:/dev, selinux friendly. Any help is appreciated! Hello folks. I need your feedback please on SELinux fixes [0] (or rather workarounds) for containerized undercloud feature, which is experimental in Pike. [TL;DR] The problem I'm trying to solve is primarily allowing TripleO users to follow the guide [1] w/o telling them "please disable SELinux". Especially, given the note "The undercloud is intended to work correctly with SELinux enforcing, and cannot be installed to a system with SELinux disabled". I understand that putting "chcon -Rt svirt_sandbox_file_t -l s0" (see [2]) to all of the host paths bind-mounted into containers is not secure, and from SELinux perspective allows everything to all containers. That could be a first step for docker volumes working w/o shutting down SELinux on *hosts* though. I plan to use the same approach for the t-h-t docker/services host-prep tasks as well. Why not using docker's :z :Z directly? IIUC, it doesn't allow combine with other mount flags, like :ro:z won't work. I look forward for better solutions and ideas! [0] https://review.openstack.org/#/q/topic:bug/1682179 [1] https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/undercloud.html [2] https://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/ [0] https://bugs.launchpad.net/tripleo/+bug/1682179 [1] https://review.openstack.org/#/q/topic:bug/1682179 [2] https://review.openstack.org/#/c/517383/ -- 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
Re: [openstack-dev] [oslo][tripleo][puppet] Logging format: let's discuss a bit about default format, format configuration and so on
Proposed a patch to be able to enable the JSON formatter via an oslo.log configuration parameter: https://review.openstack.org/#/c/517882/ On Mon, Nov 6, 2017 at 9:43 AM, Cédric Jeanneret < cedric.jeanne...@camptocamp.com> wrote: > On 11/06/2017 08:36 AM, Juan Antonio Osorio wrote: > > Giving this a bit more thought; I'm slightly more inclined on merely > adding > > the JSON formatter option to the standard oslo.log configuration options. > > Fine for me. > > > > > This is because we right now have the ability to pass oslo.cfg options > via > > the CLI, and we would loose that with the advanced logging configuration > > file. The aforementioned option is something that we're using for > > containerized openstack services. > > OK - I'll check on my own if I can get something nice with the > logging.conf file. But that won't be for "tomorrow", as I'm not > full-time on openstack (unfortunately :(). Both solutions have their > pros and cons in the end. > > > > > I'll look into adding the ability to turn that handler on/off from > oslo.log. > > Ping me if I can help :). And big thanks for that coming change! > > > > > > > > > On Mon, Nov 6, 2017 at 8:34 AM, Juan Antonio Osorio > > > wrote: > > > >> > >> > >> On Mon, Nov 6, 2017 at 8:04 AM, Cédric Jeanneret < > >> cedric.jeanne...@camptocamp.com> wrote: > >> > >>> On 11/04/2017 07:08 AM, Doug Hellmann wrote: > Excerpts from Juan Antonio Osorio's message of 2017-11-04 00:11:47 > >>> +0200: > >> On 3 Nov 2017 19:59, "Doug Hellmann" wrote: > >> > >> Excerpts from Cédric Jeanneret's message of 2017-11-01 14:54:34 > +0100: > >>> Dear Stackers, > >>> > >>> While working on my locally deployed Openstack (Pike using > TripleO), > >>> I > >>> was a bit struggling with the logging part. Currently, all logs are > >>> pushed to per-service files, in the standard format "one line per > >>> entry", plain flat text. > >>> > >>> It's nice, but if one is wanting to push and index those logs in an > >>> ELK, > >>> the current, default format isn't really good. > >>> > >>> After some discussions about oslo.log, it appears it provides a > nice > >>> JSONFormatter handler¹ one might want to use for each (python) > >>> service > >>> using oslo central library. > >>> > >>> A JSON format is really cool, as it's easy to parse for machines, > >>> and it > >>> can be on a multi-line without any bit issue - this is especially > >>> important for stack traces, as their output is multi-line without > >>> real > >>> way to have a common delimiter so that we can re-format it and feed > >>> it > >>> to any log parser (logstash, fluentd, …). > >>> > >>> After some more talks, olso.log will not provide a unified > interface > >>> in > >>> order to output all received logs as JSON - this makes sens, as > that > >>> would mean "rewrite almost all the python logging management > >>> interface"², and that's pretty useless, since (all?) services have > >>> their > >>> own "logging.conf" file. > >>> > >>> That said… to the main purpose of that mail: > >>> > >>> - Default format for logs > >>> A first question would be "are we all OK with the default output > >>> format" > >>> - I'm pretty sure "humans" are happy with that, as it's really > >>> convenient to read and grep. But on a "standard" Openstack deploy, > >>> I'm > >>> pretty sure one does not have only one controller, one ceph node > and > >>> one > >>> compute. Hence comes the log centralization, and with that, the log > >>> indexation and treatments. > >>> > >>> For that, one might argue "I'm using plain files on my logger, and > >>> grep-ing -r in them". That's a way to do things, and for that, > plain, > >>> flat logs are great. > >>> > >>> But… I'm pretty sure I'm not the only one wanting to use some kind > of > >>> ELK cluster for that kind of purpose. So the right question is: > what > >>> about switching the default log format to JSON? On my part, I don't > >>> see > >>> "cons", only "pros", but my judgment is of course biased, as I'm > >>> "alone > >>> in my corner". But what about you, Community? > >>> > >>> - Provide a way to configure the output format/handler > >>> While poking around in the puppet modules code, I didn't find any > >>> way to > >>> set the output handler for the logs. For example, in puppet-nova³ > we > >>> can > >>> set a lot of things, but not the useful handler for the output. > >>> > >>> It would be really cool to get, for each puppet module, the > >>> capability > >>> to set the handler so that one can just push some stuff in hiera, > and > >>> Voilà, we have JSON logs. > >>> > >>> Doing so would allow people to chose between the default (current) > >>> output, and something more "computable". > >> > >> Using the JSON formatter currently requires setting a
Re: [openstack-dev] [tripleo] Help needed on debugging upgrade jobs on Pike
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 wrote: On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi 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
[openstack-dev] FOSDEM 2018: Call For Proposals: Virtualization & IaaS DevRoom
I'm delighted to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be hosted on February 3 and 4, 2018. This year will mark FOSDEM’s 18th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 3 & 4, 2018. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, libvirt, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2017. --- Important Dates --- Submission deadline: 01 December 2017 Acceptance notifications: 14 December 2017 Final schedule announcement: 21 December 2017 Devroom: 03 and 04 February 2018 (two days- different rooms) - About the Devroom - The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as Apache CloudStack, OpenStack, oVirt, QEMU, OpenNebula, and Ganeti. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. - Submission Guidelines - We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 45 minutes, with 35 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, ." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) - Speaker Mentoring Program - As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for new speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: Never presented before or Presented only lightning talks or Presented full-length talks at small meetups (<50 ppl) - Submission Guidelines - Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will t
Re: [openstack-dev] [TripleO] containerized undercloud in Queens
On 11/6/17 1:01 AM, Emilien Macchi wrote: On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince 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
[openstack-dev] [murano] No meeting 7 Nov
Hi, teams We skip the 7 Nov meeting since some of us join the Sydney Summit. Have a great summit! Thanks, Rong Zhu __ 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
On 6.11.2017 10:52, Marios Andreou wrote: On Mon, Nov 6, 2017 at 11:09 AM, Marius Cornea wrote: On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi 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, 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
Re: [openstack-dev] [tripleo] Help needed on debugging upgrade jobs on Pike
On Mon, Nov 6, 2017 at 11:09 AM, Marius Cornea wrote: > On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi 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 [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 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
Re: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images core team
+1, thank hrw for ARM and Power code. > -Original Message- > From: Michał Jastrzębski [mailto:inc...@gmail.com] > Sent: Thursday, November 02, 2017 10:59 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [kolla] Proposal to add Marcin (hrw) to kolla images > core team > > It's my great pleasure to start another voting for core team addition! > > Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM! > Voting will be open for 14 days (until 16th of Nov). > > Consider this mail my +1 vote > > Regards, > Michal > > __ > > 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] Help needed on debugging upgrade jobs on Pike
On Sat, Nov 4, 2017 at 2:27 AM, Emilien Macchi 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. > 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