Re: [openstack-dev] Building Openstack Trove Images

[Ritesh Vishwakarma]

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

[Ritesh Vishwakarma]

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

[Emilien Macchi]

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 

Re: [openstack-dev] Building Openstack Trove Images

[Amrith Kumar]

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

[Emilien Macchi]

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

[Emilien Macchi]

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

[Stephen Finucane]

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

[Jason E. Rist]

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

[Doug Hellmann]

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

[Andy Botting]

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

[Wesley Hayutin]

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

[Emilien Macchi]

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

[Emilien Macchi]

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

[Bogdan Dobrelya]

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

[Michael Johnson]

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

[Balazs Gibizer]

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

[Arx Cruz]

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

[Honza Pokorny]

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

[Bogdan Dobrelya]

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

[Juan Antonio Osorio]

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 

Re: [openstack-dev] [tripleo] Help needed on debugging upgrade jobs on Pike

[Jiří Stránský]

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

[Kashyap Chamarthy]

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

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 try 

Re: [openstack-dev] [TripleO] containerized undercloud in Queens

[Bogdan Dobrelya]

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

[Rong Zhu]

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

[Jiří Stránský]

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

[Marios Andreou]

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

[duon...@vn.fujitsu.com]

+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

[Marius Cornea]

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