Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Jeffrey Zhang]

thanks mnaser and sam for the advice.

i think uwsgi + native http is not a good solution, nova. A http
server + uwsgi is better. So i am imaging that the deployment
architecture will be like

haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.

As mnaster said, one http server serve for others uwsgi services.

on the other hand, which following solution is better?

- apache + mod_uwsgi ( not recommended by uwsgi )
- apache + mode_proxy_uwsgi ( recommended by uwsgi)
- nginx + uwsgi

So the question is why community choose apache rather than nginx?

[0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html


On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple  wrote:

> I have been running api services behind uwsgi in http mode from Newton
> forward. I recently switched to the uwsgi+nginx model with 2 containers
> since I was having wierd issues with things that I couldn't track down.
> Mainly after I started using keystone with ldap. There would be timeouts
> and message-to-long type errors that all went away with nginx.
>
> Additionally, running with HTTPS was measurably faster with nginx proxying
> to a uwsgi socket.
>
> This was just my experience with it, if you do want to switch to
> uwsgi+http make sure you do thorough testing of all the components or you
> may be left with a component that just won't work with your model.
>
>
> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
> wrote:
>
>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
>> wrote:
>> > We are moving to deploy service via WSGI[0].
>> >
>> > There are two recommended ways.
>> >
>> > - apache + mod_wsgi
>> > - nginx + uwsgi
>> >
>> > later one is more better.
>> >
>> > For traditional deployment, it is easy to implement. Use one
>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).
>> > Then one nginx process to forward the http require into uwsgi server.
>> >
>> > But kolla is running one process in one container. If we use
>> > the recommended solution, we have to use two container to run
>> > nova-api container. and it will generate lots of containers.
>> > like: nginx-nova-api, uwsig-nova-api.
>> >
>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>> > container is enough to run nova-api service. Base one the official
>> > doc, if there is no static resource, uWSGI is recommended to use
>> > as a real http server.
>> >
>> > So how about this?
>>
>> I think this is an interesting approach.  At the moment, the Puppet
>> modules currently allow deploying for services using mod_wsgi.
>> Personally, I don't think that relying on the HTTP support of uWSGI is
>> very favorable.   It is quite difficult to configure and 'get right'
>> and it leaves a lot to be desired (for example, federated auth relies
>> on Apache modules which would make this nearly impossible).
>>
>> Given that the current OpenStack testing infrastructure proxies to
>> UWSGI, I think it would be best if that approach is taken.  This way,
>> a container (or whatever service) would expose a UWSGI API, which you
>> can connect whichever web server that you need.
>>
>> In the case of Kolla, the `httpd` container would be similar to what
>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>> something to be managed by the user (with some helpers in there).  I
>> think it would be interesting to add the tripleo folks on their
>> opinion here as consumers of the Puppet modules.
>>
>> >
>> >
>> > [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>> -wsgi.html
>> > [1]
>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-u
>> se-uwsgi-s-http-capabilities-in-production
>> >
>> > --
>> > Regards,
>> > Jeffrey Zhang
>> > Blog: http://xcodest.me
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > openstack-operat...@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Juan Antonio Osorio]

On Fri, Aug 25, 2017 at 9:56 AM, Jeffrey Zhang 
wrote:

> thanks mnaser and sam for the advice.
>
> i think uwsgi + native http is not a good solution, nova. A http
> server + uwsgi is better. So i am imaging that the deployment
> architecture will be like
>
> haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.
>
> As mnaster said, one http server serve for others uwsgi services.
>
> on the other hand, which following solution is better?
>
> - apache + mod_uwsgi ( not recommended by uwsgi )
> - apache + mode_proxy_uwsgi ( recommended by uwsgi)
> - nginx + uwsgi
>
> So the question is why community choose apache rather than nginx?
>

Well, in TripleO we're using apache + mod_wsgi [1]   not mod_uwsgi.

[1] https://modwsgi.readthedocs.io/en/develop/

>
> [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html
>
>
> On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple  wrote:
>
>> I have been running api services behind uwsgi in http mode from Newton
>> forward. I recently switched to the uwsgi+nginx model with 2 containers
>> since I was having wierd issues with things that I couldn't track down.
>> Mainly after I started using keystone with ldap. There would be timeouts
>> and message-to-long type errors that all went away with nginx.
>>
>> Additionally, running with HTTPS was measurably faster with nginx
>> proxying to a uwsgi socket.
>>
>> This was just my experience with it, if you do want to switch to
>> uwsgi+http make sure you do thorough testing of all the components or you
>> may be left with a component that just won't work with your model.
>>
>>
>> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
>> wrote:
>>
>>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
>>> wrote:
>>> > We are moving to deploy service via WSGI[0].
>>> >
>>> > There are two recommended ways.
>>> >
>>> > - apache + mod_wsgi
>>> > - nginx + uwsgi
>>> >
>>> > later one is more better.
>>> >
>>> > For traditional deployment, it is easy to implement. Use one
>>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api ,
>>> etc).
>>> > Then one nginx process to forward the http require into uwsgi server.
>>> >
>>> > But kolla is running one process in one container. If we use
>>> > the recommended solution, we have to use two container to run
>>> > nova-api container. and it will generate lots of containers.
>>> > like: nginx-nova-api, uwsig-nova-api.
>>> >
>>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>>> > container is enough to run nova-api service. Base one the official
>>> > doc, if there is no static resource, uWSGI is recommended to use
>>> > as a real http server.
>>> >
>>> > So how about this?
>>>
>>> I think this is an interesting approach.  At the moment, the Puppet
>>> modules currently allow deploying for services using mod_wsgi.
>>> Personally, I don't think that relying on the HTTP support of uWSGI is
>>> very favorable.   It is quite difficult to configure and 'get right'
>>> and it leaves a lot to be desired (for example, federated auth relies
>>> on Apache modules which would make this nearly impossible).
>>>
>>> Given that the current OpenStack testing infrastructure proxies to
>>> UWSGI, I think it would be best if that approach is taken.  This way,
>>> a container (or whatever service) would expose a UWSGI API, which you
>>> can connect whichever web server that you need.
>>>
>>> In the case of Kolla, the `httpd` container would be similar to what
>>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>>> something to be managed by the user (with some helpers in there).  I
>>> think it would be interesting to add the tripleo folks on their
>>> opinion here as consumers of the Puppet modules.
>>>
>>> >
>>> >
>>> > [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>>> -wsgi.html
>>> > [1]
>>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-u
>>> se-uwsgi-s-http-capabilities-in-production
>>> >
>>> > --
>>> > Regards,
>>> > Jeffrey Zhang
>>> > Blog: http://xcodest.me
>>> >
>>> > ___
>>> > OpenStack-operators mailing list
>>> > openstack-operat...@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>> k-operators
>>> >
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> openstack-operat...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstac

[openstack-dev] [docs] [ptls] Install guide testing

[Alexandra Settle]

Hi everyone,

The documentation team is searching for volunteers to help test and verify the 
OpenStack installation instructions here: 
https://docs.openstack.org/install-guide/

Previously this action has been undertaken by a series of volunteers, mostly 
from the documentation team. However due to the migration, and a significant 
drop in contributors, we are now seeking new individuals to help us complete 
this task.

We will be tracking any work here: 
https://wiki.openstack.org/wiki/Documentation/PikeDocTesting You can see what 
we have previously done for testing here: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

PTLs of cinder/keystone/horizon/neutron/nova/glance – Previously the 
documentation team performed the testing tasks for your respective projects as 
they lived within the openstack-manuals repo. We appreciate that you may or may 
not have the resources to continue this effort, but it would be great if your 
teams are able. Please let me know if you are able to so we can verify the 
instructions of these projects :)

Thanks,

Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs] Links to Ocata docs -Request for help to change to pike

[Andreas Jaeger]

Doc writers,

The manuals have references for /ocata/ that should be replaced with
links to /pike/ in the openstack-manuals/doc/ directory.

Patches to update those to /pike/ would be appreciated - and double
check that the new location exists in all case due to the move of documents,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] Technical Committee Status update, August 25th

[Flavio Percoco]

Greetings,

This is the weekly update on Technical Committee initiatives. You can
find the full list of all open topics at:

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

== Recently-approved changes ==

Thierry is out this week so not patches have been approved.

== PTG prep ==

Preparations for the PTG are still in progress. Notes and ideas are being 
proposed on this etherpad:

https://etherpad.openstack.org/p/queens-PTG-TC-SWG

== New project teams ==

As we open Queens cycle development, it's time to reconsider our current
backlog of project additions:

* Stackube: https://review.openstack.org/462460
The project was set up on OpenStack infrastructure, so it's time to
review the proposal again.

* Glare: https://review.openstack.org/479285
* Blazar: https://review.openstack.org/482860
* Gluon: https://review.openstack.org/463069
Also ready for review, those teams will be at the PTG and available to
spend some time in the TC room on Monday-Tuesday


== Open discussions ==

Monty's proposal to be explicit about supported database versions is still under
discussion:

https://review.openstack.org/493932

John updated his resolution to highlight that decisions should be globally
inclusive. The proposal seems to have gotten enough iterations and it will
likely be moved into a reference document:

https://review.openstack.org/#/c/460946/

== Voting in progress ==

Emmet's rewording of the leaderless project resolution reached majority
yesterday and will be approved early next week unless new objections are
brought:

https://review.openstack.org/#/c/492578/

Flavio's resolutions on dropping Technical Committee meetings[3] and allowing
teams to use their channel for meetings[4] are both still under review and
voting:

[3] https://review.openstack.org/459848
[4] https://review.openstack.org/485117

For leaderless teams, the TC is proposing to appoint Kota TSUYUZAKI as Storlets
PTL for Queens. Voting is on going and majority was reached on August 21st:

https://review.openstack.org/#/c/493846/


== Need for a TC meeting next Tuesday ==

There are no meetings scheduled for next week.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing 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] [ironic][docs] I see, you see, we all see red*

[milanisko k]

čt 24. 8. 2017 v 12:19 odesílatel Alexandra Settle 
napsal:

> Hey Ruby!
>
>
>
> Good point – thanks for bringing it up :)
>
>
>
> I was brought up to think that red was one of those colours that people
> had different (and sometimes really negative) associations with. When I
> look at our latest and greatest! ironic documentation (e.g. [1]), I see
> red. Not only do I see red, but the term has a different background colour
> and is bordered (or whatever it is called). Are we using the wrong .rst
> syntax, should we be highlighting terms differently? And/or is there some
> way to change the appearance of highlighted terms? I much prefer something
> simple, like bold black text in some uniform font. On the other hand,
> perhaps lots of others like this and I'm in the minority.
>
>
>
> Andreas is right – the red definitely correct, and this is how we have
> always done it in manuals. But that doesn’t mean we have to continue. We
> just need to come up with another strong, inoffensive colour that matches;
> I believe the red was chosen to simply contrast the blue. A compromise, and
> complementary colour[0], would be orange. How would you feel about this?
>
>
There are places in the documentation, such as API evolution changelogs
,
where the coloured items accumulate heavily. I'm afraid replacing red terms
with orange won't help reduce the visual clutter there. On the other hand I
understand why the ladybug is red.



>
>
> I hesitated about sending this due to the wonderful bike shedding that
> could happen, don't disappoint me, cuz I'm sure we all have opinions about
> colour. :)
>
>
>
> Not going to lie, also afraid of all the bike shedding! But you bring up a
> good point – and I don’t want others to also feel negatively about our
> documentation. We should be as inclusive as we can.
>
>
>
> Also, this email thread isn't about discussing the green and orange
> colours used for the code blocks; feel free to start your own thread about
> that if you want!
>
>
>
> No thanks, if I can avoid it :P
>
>
>
> Cheers,
>
>
>
> Alex
>
>
>
> [0] https://en.wikipedia.org/wiki/Complementary_colors
> __
> OpenStack Development Mailing 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] [ironic] ironic-staging-drivers core cleanup and additions

[Pavlo Shchelokovskyy]

Dmitry and all,

thank you for your trust. I'll do my best to keep the project alive and
healthy.

Best regards,

On Thu, Aug 24, 2017 at 4:15 PM, Dmitry Tantsur  wrote:

> We seem to be in agreement, so I'll apply these changes. Thanks all!
>
>
> On 08/22/2017 11:24 AM, Dmitry Tantsur wrote:
>
>> Hi all!
>>
>> This email concerns the ironic-staging-drivers project which is outside
>> of the official Ironic governance. Please ignore it if you don't care about
>> this project.
>>
>> I've checked the core [1] and the release [2] teams for the project, and
>> I think they need an update based (see [3]).
>>
>> I suggest removing the following people:
>> * Dan Prince (due to inactivity)
>> * Lucas Alvares Gomes (due to priorities change)
>> * Imre Farkas (no longer works on OpenStack)
>>
>> I suggest adding Pavlo Shchelokovskyy, who actively contributes to and
>> reviews the project, to the core team.
>>
>> I've cc'ed affected people as I was a bit too lazy to reach to them on
>> IRC :) Please let me know your opinion.
>>
>> [1] https://review.openstack.org/#/admin/groups/1258,members
>> [2] https://review.openstack.org/#/admin/groups/1259,members
>> [3] http://stackalytics.com/?module=ironic-staging-drivers&release=pike
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] mismatch of user/group id between ovs (baremetal) and libvirt (container)

[Oliver Walsh]

On 23 August 2017 at 07:18, Saravanan KR  wrote:
> On Wed, Aug 23, 2017 at 4:28 AM, Oliver Walsh  wrote:
>> Hi,
>>
>>>   sed -i 's/Group=qemu/Group=42427/'
>>> /usr/lib/systemd/system/ovs-vswitchd.service
>>
>> Can't this be overridden via /etc/systemd/system/ovs-vswitchd.service?
>>
> Yes. I just provided the changes done on a existing deployment to make
> it work. I will incorporate it to templates.
>
>>> This change basically runs ovs with group id of kolla's qemu user
>>> (42427). For the solution, my opinion is that we don't require host's
>>> qemu (107) user in a containerized deployment. I am planning to ensure
>>> that kolla's user id (42427) is updated to the host via the host prep
>>> tasks. Let me know if there is any other aspects to be considered.
>>>
>>
>> Might be worth considering overriding the qemu uid/gid to 107 in the
>> kolla config file instead.
>
> Definitely it will be good for upgrade to keep the same uid/gid so
> that existing DPDK based VMs continue to work after upgrade.
>
> But any other specific reasons for sticking with same qemu uid/gid in
> kolla containers? Do you foresee any particular cases related to it?
>

I don't expect it would cause any issues.

Many of the uids/gids created during rpm installs are dynamic so they
could vary depending on the order that uids are created. This could
result in inconsistent uids/gids across the docker images.
I assume this is the reason that kolla is setting the uids/gids in the
base image - the numeric values are not significant, they just need to
be consistent.

Thanks,
Ollie


> Regards,
> Saravanan KR
>
>>
>> Regards,
>> Ollie
>>
>> __
>> OpenStack Development Mailing 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

Re: [openstack-dev] [tripleo] add mistral to the auto-update package list for TripleO CI

[Brad P. Crochet]

On Thu, Aug 24, 2017 at 5:35 PM, Ben Nemec  wrote:
> I think I'm +0 on this.  On the one hand we do have the gating job on
> Mistral, on the other hand our gate jobs don't exercise all of the
> functionality of some projects, especially Mistral.  I know in the past
> introspection has been broken by changes in Mistral, and that wouldn't be
> caught by gate jobs.  If we start using master all the time that becomes a
> blocker for TripleO since it will prevent our OVB jobs from passing.
>
> So I can understand the desire to use master of a tightly coupled project
> like Mistral, but it does open a hole in our promotion pipeline which I
> don't feel great about.  If we had an OVB job running on every patch (and
> respected by the Mistral cores) I'd be +1 with no reservations.

I am +1 on this. However, I do echo Ben's concerns. I will bring this
up with the Mistral group at the PTG. We already have an experimental
job available, but I'm guessing the major concern will be the amount
of time it takes for a TripleO job to run. It would likely double the
amount of time that a Mistral patch takes to get through CI.

>
>
> On 08/24/2017 04:04 PM, Wesley Hayutin wrote:
>>
>> Greetings,
>>
>> I'd like to propose that the mistral project be added to the list of
>> projects where in CI the very latest built packages are added to each CI run
>> [1].
>>
>> This will help get patches that depend on mistral patches to more quickly
>> be tested and merged.  For example Honza's patch [2] depends on a merged
>> mistral change.  The mistral change has not yet landed in a tripleo build
>> and mistral is not on the auto-update list, so the patch fails.
>>
>> Please respond if you would like to see mistral added or have any comments
>> or concerns.
>>
>> Note that we are able to consider mistral for auto-updates because the
>> mistral project has a voting tripleo job [3] and the tripleo project can be
>> assured that the latest mistral patches will not break tripleo-ci.
>>
>> I would encourage other projects to consider adding tripleo jobs to their
>> project to enable auto-updates as well [4] 
>>
>> [1]
>> https://github.com/openstack/tripleo-quickstart/blob/master/config/release/tripleo-ci/master.yml#L54-L70
>> [2] https://review.openstack.org/#/c/469608/
>> [3]
>> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L11665
>> [4]
>> https://docs.openstack.org/tripleo-docs/latest/contributor/check_gates.html
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>



-- 
Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
Principal Software Engineer

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] [ptls] Install guide testing

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-08-25 08:57:51 +:
> Hi everyone,
> 
> The documentation team is searching for volunteers to help test and verify 
> the OpenStack installation instructions here: 
> https://docs.openstack.org/install-guide/
> 
> Previously this action has been undertaken by a series of volunteers, mostly 
> from the documentation team. However due to the migration, and a significant 
> drop in contributors, we are now seeking new individuals to help us complete 
> this task.
> 
> We will be tracking any work here: 
> https://wiki.openstack.org/wiki/Documentation/PikeDocTesting You can see what 
> we have previously done for testing here: 
> https://wiki.openstack.org/wiki/Documentation/OcataDocTesting
> 
> PTLs of cinder/keystone/horizon/neutron/nova/glance – Previously the 
> documentation team performed the testing tasks for your respective projects 
> as they lived within the openstack-manuals repo. We appreciate that you may 
> or may not have the resources to continue this effort, but it would be great 
> if your teams are able. Please let me know if you are able to so we can 
> verify the instructions of these projects :)
> 
> Thanks,
> 
> Alex

Thanks for starting this thread, Alex.  I want to add a little
background for folks only now catching up with the state of the
migration initiative and documentation for Pike.

At the start of the Pike cycle we lost most of our technical writers.
By the time of the summit in Boston, it wasn't clear (at least to
me) if we would have *any* writers left at the start of the Queens
cycle.  Luckily it seems we will, but without knowing that a few
months ago I encouraged the docs team to make some decisions about
prioritizing work that will leave us in a less than ideal, but
recoverable, state for Pike.

We started by emphasizing the need to move all of the existing
content to a new home so it could be maintained by more owners --
this was the aspect of the migration spec that most of you will be
familiar with, and with over 1100 reviews tagged 'doc-migration' I
think it's safe to say this was the bulk of the work.

We did not completely address two important aspects of managing that
content after the migration: translations and testing.

We looked into translations far enough to know that it would be
possible to set up the jobs and build project docs in multiple
languages. We're already doing this for some other sphinx-based
docs, so we would have a pattern to work from.

I had hoped that if we had time after the import was done, we could
develop a plan for end-of-cycle-testing. That didn't happen, so we
will have to come up with a plan and execute it during Queens. No
one thinks this is a good outcome, but it's where we are. If you're
interested in helping with that work, I expect it will be a big
part of what the docs team discusses at the PTG. Spoiler alert: I
will be advocating distributing the responsibility for verifying
instructions to the project teams.

Doug

PS - By the way, most projects are finished with the migration, but
I see on the dashboard[1] that we still have quite a few open reviews
and a few missing pages. At this point, the missing docs will need
to be backported to the stable/pike branches for those projects.
Let me know if you need help approving things in the stable branches.

[1] https://doughellmann.com/doc-migration/

__
OpenStack Development Mailing 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] placement/resource providers update 33

[Chris Dent]

Here's update 33.

RC2 went to the presses. The result is that we've now got claims
happening earlier and using better information. This ought to mean
that there are fewer retries and failed builds. There's some
cruftiness in the code that manages allocations that will need to be
cleaned up, and bugs and buglets keep getting found in some edge cases
but overall much forward progress. Nice work everyone.

One alternate destinations is done, the next things coming up are
getting shared providers working on the nova side, incorporating
traits in resource requests, and, eventually, nested resource providers.

Presumably at the PTG we'll decide the if/when/how of extracting
placement to its own repo.

This week I've added a section that references bugs that have not yet
seen much action.

# Most Important

Besides reviewing all the stuff in this document, another important
thing to do is to make additions and edits on the PTG etherpad (see
help wanted).

The ongoing work with allocation related functional tests (many listed
below), and the getting alternate destinations working is also
important.

# Help Wanted

There's a swathe of placement related stuff on the PTG planning
etherpad. Please add to that or make some adjustments if you think
something is missing or incomplete:

 https://etherpad.openstack.org/p/nova-ptg-queens

An important aspect of this is determining what kind of dependency
tree is involved with the work.

Also see this new next section.

# Bugs needing attention

(Bugs which are not yet in progress or beyond.)

## Current

* https://bugs.launchpad.net/nova/+bug/1712411
  Allocations may not be removed from dest node during failed migrations

* https://bugs.launchpad.net/nova/+bug/1679750
  Allocations are not cleaned up in placement for instance 'local delete' case

* https://bugs.launchpad.net/nova/+bug/1427772
  Instance that uses force-host still needs to run some filters
  (old bug, but newly relevant in a placement world)

## Old (need to be flushed or refreshed:?)

* https://bugs.launchpad.net/nova/+bug/1683858
  Allocation records do not contain overhead information

* https://bugs.launchpad.net/nova/+bug/1652099
  placement requests from n-cpu logs not found in placement-api logs

* https://bugs.launchpad.net/nova/+bug/1674694
  In placement api error responses choose poor default content-type
  (this was partially fixed in the resource tracker, but not generally.
  as described in the bug, this ought to be relatively straightforward
  to make go)

* https://bugs.launchpad.net/nova/+bug/1662867
  update_available_resource_for_node racing instance deletion
  (Is this one still relevant after all the recent changes to claim
  handling?)

# Docs

There's a stack that documents (with visual aids!) the flow of
scheduler and placement. It is pretty much ready:

https://review.openstack.org/#/c/475810/

# Main Themes

## Alternate Destinations

There's a stack beginning at https://review.openstack.org/#/c/486215/
which proposes the bits necessary to return alternate destinations
besides the claimed destination. These will be used to do within-cell
(v2) retries in case a build can't be done on the claimed destiantion.

The spec revision for that work: https://review.openstack.org/#/c/471927/

Ed has some concerns about the complexity being created, so he wrote
up some issues at:

https://blog.leafe.com/handling-unstructured-data/

In his response to https://review.openstack.org/#/c/495854/3 Jay
suggests a named tuple:

I'm struck that instead of a two-tuple, both elements of the tuple
having lists of lists, would it not be clearer to have the return
value from select_destinations() instead be a single list of
namedtuple elements, where the namedtuple would have a
chosen_host, alternate_hosts, and allocation_requests attribute

## Traits

Work continues apace on getting filtering by traits working:

  https://review.openstack.org/#/c/489206/

This has some overlap with shared provider handling (below).

## Shared Resource Providers

There's some support for shared resource providers on the placement
side of the scheduling equation, but the resource tracker is not yet
ready to support it. There is some work in progress, starting with
functional tests:

 https://review.openstack.org/#/c/490733/

## Nested Resource Providers

This will start back up after we clean off the windscreen. The stack
begins at https://review.openstack.org/#/c/470575/5

# Other Code

* https://review.openstack.org/#/c/493865/
  functional tests for live migrate

* https://review.openstack.org/#/c/494136/
  Allow shuffling of best weighted hosts

* https://review.openstack.org/#/c/495159/
  tests for resource allocation during soft delete

* https://review.openstack.org/#/c/485209/
  gabbi tests for shared custom resource class

* https://review.openstack.org/#/c/495891/
  WIP: test allocation handling during scheduler retry

* https://review.openstack.org/#/c/480379/
  ensure RP

Re: [openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Mohammed Naser]

On Fri, Aug 25, 2017 at 2:56 AM, Jeffrey Zhang  wrote:
> thanks mnaser and sam for the advice.
>
> i think uwsgi + native http is not a good solution, nova. A http
> server + uwsgi is better. So i am imaging that the deployment
> architecture will be like
>
> haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.
>
> As mnaster said, one http server serve for others uwsgi services.
>
> on the other hand, which following solution is better?
>
> - apache + mod_uwsgi ( not recommended by uwsgi )

Not recommended by them is probably a sign to stay away

> - apache + mode_proxy_uwsgi ( recommended by uwsgi)

This has two advantages.   DevStack at the gate tests using this exact
architecture AFAIK which means that we would less likely run into
issues that were never discovered in testing.

> - nginx + uwsgi

I like this a lot, however, for applications such as Keystone, they
sometimes rely on Apache for some features (such as Federation:
https://docs.openstack.org/keystone/latest/advanced-topics/federation/configure_federation.html#configure-apache-to-use-a-federation-capable-authentication-method)

However, Apache has done a lot of improvements in terms of catching up
to nginx and if using an MPM worker such as mpm_event, you would end
up with a very similar architecture and performance.

>
> So the question is why community choose apache rather than nginx?
>
> [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html
>
>
> On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple  wrote:
>>
>> I have been running api services behind uwsgi in http mode from Newton
>> forward. I recently switched to the uwsgi+nginx model with 2 containers
>> since I was having wierd issues with things that I couldn't track down.
>> Mainly after I started using keystone with ldap. There would be timeouts and
>> message-to-long type errors that all went away with nginx.
>>
>> Additionally, running with HTTPS was measurably faster with nginx proxying
>> to a uwsgi socket.
>>
>> This was just my experience with it, if you do want to switch to
>> uwsgi+http make sure you do thorough testing of all the components or you
>> may be left with a component that just won't work with your model.
>>
>>
>> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
>> wrote:
>>>
>>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
>>> wrote:
>>> > We are moving to deploy service via WSGI[0].
>>> >
>>> > There are two recommended ways.
>>> >
>>> > - apache + mod_wsgi
>>> > - nginx + uwsgi
>>> >
>>> > later one is more better.
>>> >
>>> > For traditional deployment, it is easy to implement. Use one
>>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api ,
>>> > etc).
>>> > Then one nginx process to forward the http require into uwsgi server.
>>> >
>>> > But kolla is running one process in one container. If we use
>>> > the recommended solution, we have to use two container to run
>>> > nova-api container. and it will generate lots of containers.
>>> > like: nginx-nova-api, uwsig-nova-api.
>>> >
>>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>>> > container is enough to run nova-api service. Base one the official
>>> > doc, if there is no static resource, uWSGI is recommended to use
>>> > as a real http server.
>>> >
>>> > So how about this?
>>>
>>> I think this is an interesting approach.  At the moment, the Puppet
>>> modules currently allow deploying for services using mod_wsgi.
>>> Personally, I don't think that relying on the HTTP support of uWSGI is
>>> very favorable.   It is quite difficult to configure and 'get right'
>>> and it leaves a lot to be desired (for example, federated auth relies
>>> on Apache modules which would make this nearly impossible).
>>>
>>> Given that the current OpenStack testing infrastructure proxies to
>>> UWSGI, I think it would be best if that approach is taken.  This way,
>>> a container (or whatever service) would expose a UWSGI API, which you
>>> can connect whichever web server that you need.
>>>
>>> In the case of Kolla, the `httpd` container would be similar to what
>>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>>> something to be managed by the user (with some helpers in there).  I
>>> think it would be interesting to add the tripleo folks on their
>>> opinion here as consumers of the Puppet modules.
>>>
>>> >
>>> >
>>> > [0]
>>> > https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
>>> > [1]
>>> >
>>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production
>>> >
>>> > --
>>> > Regards,
>>> > Jeffrey Zhang
>>> > Blog: http://xcodest.me
>>> >
>>> > ___
>>> > OpenStack-operators mailing list
>>> > openstack-operat...@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> openstack-operat...@lists.openstack.org
>

Re: [openstack-dev] [kolla][puppet][openstack-ansible] Better way to run wsgi service.

[Chris Dent]

On Thu, 24 Aug 2017, Jeffrey Zhang wrote:


i propose use uwsgi native http mode[1]. Then one uwsgi
container is enough to run nova-api service. Base one the official
doc, if there is no static resource, uWSGI is recommended to use
as a real http server.


I would consider using uwsgi in uwsgi mode, to run the api server in
a container independently. Using uwsgi mode preserves the capability
of your container (or containers) being anywhere, but is more
performant than http mode.

The relatively new uwsgi stuff on devstack has relatively clean ways
to run uwsgi services under systemd, but does so with unix domain
sockets. This might be a useful guide for writing uwsgi.ini files
for single processes in containers. Some adaptations will be
required.

And then reverse proxy to the container from either nginx or apache2
such that every service is on the same
https://api.mycloud.example.com/ host with the service on a path
prefix: https://api.mycloud.example.com/compute/,
https://api.mycould.example.com/block-storage, etc


--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [docs] Re: Install guide testing

[Roger Luethi]

I don't know what will get changed or created until the release, but
what I can find right now in terms of installation instructions is this:

https://docs.openstack.org/pike/install/

leading to the "OpenStack Installation Tutorial":

https://docs.openstack.org/install-guide/

plus many project-specific instructions:

https://docs.openstack.org//pike/install/

The OpenStack Installation Tuturial is labelled "Installation Guide
15.0", same as Ocata (Newton was 0.1). The URL is not versioned, even
though there will be changes between releases (the instructions for
enabling the OpenStack repository are updated every release, and there
are bound to be other differences). I wonder how that will be handled
in the future.

I have not read all of the new "OpenStack Installation Tutorial", but
looking at the table of contents, there seems to be a gap between
"Environment"->"Memcached" and "Launch an instance". Where do we tell the
readers which project-specific guides to follow, and in what order? Both
pieces of information are rather crucial for a successful installation.

I expect users will find confusing that clicking the "Next" arrow on a
distro-specific page (say, [1]) will often take them to the same page,
just for a different distro. In the keystone install-guide, clicking on
the Next arrow can result in skipped pages (depending on the distro,
e.g. [2]). I realize that distro-specific instructions are not easily
implemented with the new setup, but maybe the doc team could suggest
a way to handle distro-specific paths for all projects.

Roger

[1] https://docs.openstack.org/install-guide/environment-messaging-obs.html
[2] https://bugs.launchpad.net/keystone/+bug/1712335

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

During the week of the PTG ETSI NFV will have its plenary meeting in Denver. To 
benefit from this coincidence there will be a small workshop between ETSI NFV 
delegates and OpenStack contributors in the PTG hotel.

The workshop intends to provide a forum to identify and discuss the common use 
cases and tasks between OpenStack and ETSI NFV and take these items to the next 
level. The co-located workshop will be a working event to discuss the gaps and 
requirements on both sides in details and work on the technical solutions and 
next steps.

We plan to cover the following agenda:

  *   ETSI NFV, Motivation and target, how to make things happen there
  *   OpenStack, Motivation and target, how to make things happen there
  *   TST 003 -> Gap analysis between ETSI NFV specifications and OpenStack
  *   Collaboration via testing
  *   Introduction to the NFV PoC program and the opportunities around Plugtests

More detailed agenda and registration here: 
https://etherpad.openstack.org/p/etsi-nfv-openstack-gathering-denver
Gaps to be discussed are here: 
https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
(as most probably we will not have time to cover all of them, please mark with 
+1 the ones which are interesting to you).

Also please do not forget the workshop organized on Monday around similar 
topics: https://nfvwiki.etsi.org/index.php?title=ETSI_NFV_Tutorial

In case of any questions do not hesitate to contact me.

Br,
Gerg0

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Re: Install guide testing

[Andreas Jaeger]

On 2017-08-25 15:40, Roger Luethi wrote:
> I don't know what will get changed or created until the release, but
> what I can find right now in terms of installation instructions is this:
> 
> https://docs.openstack.org/pike/install/
> 
> leading to the "OpenStack Installation Tutorial":
> 
> https://docs.openstack.org/install-guide/
> 
> plus many project-specific instructions:
> 
> https://docs.openstack.org//pike/install/
> 
> The OpenStack Installation Tuturial is labelled "Installation Guide
> 15.0", same as Ocata (Newton was 0.1). The URL is not versioned, even
> though there will be changes between releases (the instructions for
> enabling the OpenStack repository are updated every release, and there
> are bound to be other differences). I wonder how that will be handled
> in the future.

The introductory document needs little changes for each release, it will
cover several releases. I just pushed two changes up to update that
document.

> 
> I have not read all of the new "OpenStack Installation Tutorial", but
> looking at the table of contents, there seems to be a gap between
> "Environment"->"Memcached" and "Launch an instance". Where do we tell the
> readers which project-specific guides to follow, and in what order? Both
> pieces of information are rather crucial for a successful installation.

https://review.openstack.org/497813

> I expect users will find confusing that clicking the "Next" arrow on a
> distro-specific page (say, [1]) will often take them to the same page,
> just for a different distro. In the keystone install-guide, clicking on
> the Next arrow can result in skipped pages (depending on the distro,
> e.g. [2]). I realize that distro-specific instructions are not easily
> implemented with the new setup, but maybe the doc team could suggest
> a way to handle distro-specific paths for all projects.


We discussed this several times and found no good solution. In
openstack-manuals we build several documents - this would complicate the
project repos significantly. Also, there's so much duplication that
skipping over distros is just a small part,

Andreas

> Roger
> 
> [1] https://docs.openstack.org/install-guide/environment-messaging-obs.html
> [2] https://bugs.launchpad.net/keystone/+bug/1712335
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Pike RC1 has been released, RC2 ongoing

[Emilien Macchi]

TripleO PIke 1 has been released, stable/pike branch was created.

Here are some numbers:

139 bugfix released (62 in ocata-rc1)
8 blueprints completed (6 in ocata-rc1)

The team should now focus on:

- Pike RC2 bugs: https://launchpad.net/tripleo/+milestone/pike-rc2
- backporting upgrade patches or Critical / High bugs into stable/pike
- Proposing topics for Queens PTG in Denver:
https://etherpad.openstack.org/p/tripleo-ptg-queens


Big kudos to the team for this release (and Alex for helping while I was off).
Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] group/host specific config file overrides: how-to?

[Markus Zoeller]

On 23.08.2017 00:16, Jean-Philippe Evrard wrote:
> Hello,
> 
> The variables documented in each of the roles defaults/ are generally what
> you can consider a user level interface (i.e.: what you can modify), while
> the variables from vars/ are generally what's best to avoid overriding.
> 
> We've been slowly phasing out variables insides templates, to exclusively
> rely on config_template overrides (See also: [1] and [2])
> Please note that if a variable is deprecated, we are issuing a release note.
> 
> [1]: https://github.com/openstack/openstack-ansible-os_nova/blob/
> 4b9100a612ba0e9449d792b2783b9ec50a8fb28e/tasks/nova_post_install.yml#L40
> [2]: https://docs.openstack.org/project-deploy-guide/
> openstack-ansible/ocata/app-advanced-config-override.html
> 
> Best regards,
> JP

That helps resolving my issues. Thanks a lot!

-- 
Regards, Markus Zoeller (markus_z)

> 
> On Tue, Aug 22, 2017 at 1:24 PM, Markus Zoeller > wrote:
> 
>> On 22.08.2017 09:46, Flávio Ramalho wrote:
>>> Hi Markus,
>>>
>>> I think you can achieve what you want by simple overriding the host
>>> variables, for example:
>>>
>>> In /etc/openstack_deploy/openstack_user_config.yml:
>>> compute_hosts:
>>>compute1:
>>>  ip: 192.168.100.12
>>>  host_vars:
>>>nova_reserved_host_memory_mb: 256
>>>compute2:
>>>  ip: 192.168.100.10
>>>
>>> In this case you would have compute1 with reserved_host_memory_mb = 256
>> and
>>> compute2 with the default value set for nova_reserved_host_memory_mb.
>>>
>>>
>>> Flávio
>>
>> Oh, I didn't see those variables, good hint! I'll give it a try, maybe
>> that's good enough for me. Thanks a lot Flavio!
>>
>> http://git.openstack.org/cgit/openstack/openstack-ansible-os
>> _nova/tree/templates/nova.conf.j2
>>
>> Despite that this will probably work, is that an "interface" I'm allowed
>> to touch or is it considered an "internal/private" part of
>> OpenStack-Ansible (and/or its roles)?
>>
>> --
>> Regards, Markus Zoeller (markus_z)
>>
>>
>>> On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller <
>> mzoel...@linux.vnet.ibm.com>
>>> wrote:
>>>
 On 21.08.2017 16:40, Andy McCrae wrote:
> Hey Markus,
>
>
>> I'm wondering which possibilities I have to do group/host specific
>> config file overrides. After reading [1], I'm still a little clueless.
>> To be specific, I have this setup (expressed as Ansible inventory
>> file):
>>
>> [z_compute_nodes]
>> compute1
>> # more nodes
>> [x_compute_nodes]
>> compute2
>> # more nodes
>> [computes:children]
>> z_compute_nodes
>> x_compute_nodes
>>
>> As an example, I want to set Nova's config option
>> `reserved_host_memory_mb` of the `DEFAULT` config file section:
>>
>> ### nova.conf
>> [DEFAULT]
>> reserved_host_memory_mb=$VALUE
>>
>> My goal is this:
>>
>>  | reserved_host_memory_mb
>> --
>> compute1 | 256
>> compute2 | 512
>>
>> I know there are overrides like `nova_nova_conf_overrides`.
>> So I tried to set a default override in `user_variables.yml`:
>>
>> ### /etc/openstack_deploy/user_variables.yml 
>>
>> nova_nova_conf_overrides:
>>   DEFAULT:
>> reserved_host_memory_mb: 512
>>
>> But I wanted to override this depending on the host in
>> `openstack_user_config.yml`:
>>
>> ### /etc/openstack_deploy/openstack_user_config.yml 
>> # [...]
>> # nova hypervisors
>> compute_hosts:
>>   compute1:
>> ip: 192.168.100.12
>> host_vars:
>>   nova_nova_conf_overrides:
>> DEFAULT:
>>   reserved_host_memory_mb: 256
>>   compute2:
>> ip: 192.168.100.10
>>
>
> Try change "host_vars" to "container_vars".
> If that doesn't work let me know, I'll spin up a test to recreate the
> actual problem, but at a glance that looks correct otherwise.
>


 Replacing `host_vars` with `container_vars` didn't have an effect:

 ### controller1: /etc/openstack_deploy/openstack_user_config.yml
 # nova hypervisors
 compute_hosts:
   compute1:
 ip: 192.168.100.12
 container_vars:
   nova_nova_conf_overrides:
 DEFAULT:
 reserved_host_memory_mb: 256
   compute2:
 ip: 192.168.100.10

 Both compute nodes still have the same $VALUE, although `compute1`
 should have 256:

 ### compute1: /etc/nova/nova.conf
 root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
 reserved_host_memory_mb = 512


 ### compute2: /etc/nova/nova.conf
 root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
 re

[openstack-dev] [os-upstream-institute][all] Get together at the PTG

[Ildiko Vancsa]

Hi Training Team and All,

As we have our next PTG coming up shortly I think that would be a great 
opportunity for the team and everyone who’s interested to meet and check where 
we are and what our future plans are. :)

I would like to ask you to raise your hand by replying to this mail if you will 
be around during the PTG week in Denver and would be interested in joining. 
Please also indicate your availability for the week.

Based on the responses we will pick a day and a time that works best for most 
to have our gathering.

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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] [os-upstream-institute][all] Get together at the PTG

[Csatari, Gergely (Nokia - HU/Budapest)]

Szia, 

Jovok. Nekem szerdatol jo. 

Udv, 
Gerg0

-Original Message-
From: Ildiko Vancsa [mailto:ildiko.van...@gmail.com] 
Sent: Friday, August 25, 2017 4:37 PM
To: openstack-dev@lists.openstack.org; openstack-d...@lists.openstack.org; 
user-committee 
Subject: [openstack-dev] [os-upstream-institute][all] Get together at the PTG

Hi Training Team and All,

As we have our next PTG coming up shortly I think that would be a great 
opportunity for the team and everyone who’s interested to meet and check where 
we are and what our future plans are. :)

I would like to ask you to raise your hand by replying to this mail if you will 
be around during the PTG week in Denver and would be interested in joining. 
Please also indicate your availability for the week.

Based on the responses we will pick a day and a time that works best for most 
to have our gathering.

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)



__
OpenStack Development Mailing 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] [os-upstream-institute][all] Get together at the PTG

[Sean McGinnis]

On Fri, Aug 25, 2017 at 04:36:55PM +0200, Ildiko Vancsa wrote:
> Hi Training Team and All,
> 
> As we have our next PTG coming up shortly I think that would be a great 
> opportunity for the team and everyone who’s interested to meet and check 
> where we are and what our future plans are. :)
> 
> I would like to ask you to raise your hand by replying to this mail if you 
> will be around during the PTG week in Denver and would be interested in 
> joining. Please also indicate your availability for the week.
> 
> Based on the responses we will pick a day and a time that works best for most 
> to have our gathering.
> 
> Please let me know if you have any questions.
> 
> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
> 

I'd love to get together with everyone. My availability will probably be a
a little crazy, so I'll just watch for what everyone else decides and join
up if I can.

Great idea!


__
OpenStack Development Mailing 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] [os-upstream-institute][all] Get together at the PTG

[Miguel Lavalle]

Ildiko,

For me it would be great if we can meet on Monday or Tuesday. Those two I
have also to find time to get together with the Docs team

Regards

On Fri, Aug 25, 2017 at 9:36 AM, Ildiko Vancsa 
wrote:

> Hi Training Team and All,
>
> As we have our next PTG coming up shortly I think that would be a great
> opportunity for the team and everyone who’s interested to meet and check
> where we are and what our future plans are. :)
>
> I would like to ask you to raise your hand by replying to this mail if you
> will be around during the PTG week in Denver and would be interested in
> joining. Please also indicate your availability for the week.
>
> Based on the responses we will pick a day and a time that works best for
> most to have our gathering.
>
> Please let me know if you have any questions.
>
> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
>
>
>
> __
> OpenStack Development Mailing 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] [tripleo] CI Squad Meeting Summary (week 34)

[Attila Darazs]

If the topics below interest you and you want to contribute to the 
discussion, feel free to join the next meeting:


Time: Thursdays, 14:30-15:30 UTC
Place: https://bluejeans.com/4113567798/

Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

Topics discussed:

We talked about the balance between using openstack-infra supported vs. 
self hosted solutions for graphite, logservers, proxies and mirrors. 
Paul Belanger joined us and the end result seemed to be that we're going 
to try to keep as many services under infra as we can, but sometimes the 
line is not so clear when we're dealing with 3rd party environments like 
rdocloud.


Ronelle talked about changing the overcommit ratio on rdocloud after the 
analysis of our usage. This can be probably done without any issue.


Wes added 
"gate-tripleo-ci-centos-7-scenario003-multinode-oooq-container" to the 
tripleo-quickstart-extras check and gate jobs to make sure we won't 
break containers. and that we get some feedback on the status of 
containers jobs.


RDO packaging changes are now gating with Quickstart 
(multinode-featureset005), though it's non-voting. It might help us 
prevent breaks from the packaging side.


Promotion jobs are still not working fully on RDO Cloud, but we're 
working on it.


That's it for this week, have a nice weekend.

Best regards,
Attila

__
OpenStack Development Mailing 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] About OpenStack's resource limit

[gordon chung]

On 2017-08-24 05:20 AM, rk_1218_l...@i.softbank.jp wrote:
> Because I want to monitor resource usage (CPU utilization, memory, 
> ...etc) with OpenStack!!
> I have one question.

you can monitor resource usage using ceilometer (to generate the 
metrics) and gnocchi (to store/query metrics). you can extend that 
functionality using grafana for visualisations or heat for autoscaling.

> Can I restrict resource with OpenStack?
>
> For example, is it possible to limit the CPU to 20 % for process that 
> normally use 50% CPU?
> If you have such a command, please let me know!

probably better answered by Nova devs but seems this is possible[1][2]

[1] https://blueprints.launchpad.net/nova/+spec/quota-instance-resource
[2] https://wiki.openstack.org/wiki/InstanceResourceQuota

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Re: Install guide testing

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2017-08-25 16:05:41 +0200:
> On 2017-08-25 15:40, Roger Luethi wrote:
> > I don't know what will get changed or created until the release, but
> > what I can find right now in terms of installation instructions is this:
> > 
> > https://docs.openstack.org/pike/install/
> > 
> > leading to the "OpenStack Installation Tutorial":
> > 
> > https://docs.openstack.org/install-guide/
> > 
> > plus many project-specific instructions:
> > 
> > https://docs.openstack.org//pike/install/
> > 
> > The OpenStack Installation Tuturial is labelled "Installation Guide
> > 15.0", same as Ocata (Newton was 0.1). The URL is not versioned, even
> > though there will be changes between releases (the instructions for
> > enabling the OpenStack repository are updated every release, and there
> > are bound to be other differences). I wonder how that will be handled
> > in the future.
> 
> The introductory document needs little changes for each release, it will
> cover several releases. I just pushed two changes up to update that
> document.

Right. We should clean up the version number (either update it or not
show it) but we tried to retain only content that would change
very little or for which we could easily add operating system
version-specific conditionals to the steps.

> > I have not read all of the new "OpenStack Installation Tutorial", but
> > looking at the table of contents, there seems to be a gap between
> > "Environment"->"Memcached" and "Launch an instance". Where do we tell the
> > readers which project-specific guides to follow, and in what order? Both
> > pieces of information are rather crucial for a successful installation.
> 
> https://review.openstack.org/497813

I've +2ed that patch as a good start. We've talked about documenting
some "constellation" configurations for setting up clouds with
different purposes running different services. That page may be a
good place to do that, or it may just be that we link to those
constellations when they are available elsewhere. We can figure out
the best way to do that when someone volunteers to do the work.

> > I expect users will find confusing that clicking the "Next" arrow on a
> > distro-specific page (say, [1]) will often take them to the same page,
> > just for a different distro. In the keystone install-guide, clicking on
> > the Next arrow can result in skipped pages (depending on the distro,
> > e.g. [2]). I realize that distro-specific instructions are not easily
> > implemented with the new setup, but maybe the doc team could suggest
> > a way to handle distro-specific paths for all projects.
> 
> 
> We discussed this several times and found no good solution. In
> openstack-manuals we build several documents - this would complicate the
> project repos significantly. Also, there's so much duplication that
> skipping over distros is just a small part,

Yes, we're still open to suggestions but in the absence of a solution
we've placed a higher priority on the other remaining work.

Doug

> 
> Andreas
> 
> > Roger
> > 
> > [1] https://docs.openstack.org/install-guide/environment-messaging-obs.html
> > [2] https://bugs.launchpad.net/keystone/+bug/1712335
> > 
> > __
> > OpenStack Development Mailing 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] [os-upstream-institute][all] Get together at the PTG

[Kendall Nelson]

I'll be around obviously.

Monday or Tuesday would work best for me as well.

-Kendall (diablo_rojo)

On Fri, Aug 25, 2017 at 8:09 AM Miguel Lavalle  wrote:

> Ildiko,
>
> For me it would be great if we can meet on Monday or Tuesday. Those two I
> have also to find time to get together with the Docs team
>
> Regards
>
> On Fri, Aug 25, 2017 at 9:36 AM, Ildiko Vancsa 
> wrote:
>
>> Hi Training Team and All,
>>
>> As we have our next PTG coming up shortly I think that would be a great
>> opportunity for the team and everyone who’s interested to meet and check
>> where we are and what our future plans are. :)
>>
>> I would like to ask you to raise your hand by replying to this mail if
>> you will be around during the PTG week in Denver and would be interested in
>> joining. Please also indicate your availability for the week.
>>
>> Based on the responses we will pick a day and a time that works best for
>> most to have our gathering.
>>
>> Please let me know if you have any questions.
>>
>> Thanks and Best Regards,
>> Ildikó
>> (IRC: ildikov)
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [requirements] fully unlocking upper-constraints for master (queens)

[Matthew Thode]

Hi everyone,

Just wanted to let you know that since phase R-2 is ending
we are going to be fully unlocking upper-constraints.txt in master.
This means normal (non-freeze) operations can go forward in master
(queens).  If you have any questions feel free to bug in in the
#openstack-requirements channel.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing 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] OpenStack Developer Mailing List Digest August 19-25

[Kendall Nelson]

Hello Everyone :)

HTML Version:
https://www.openstack.org/blog/2017/08/openstack-developer-mailing-list-digest-august-19th-25th/

SuccessBot Says

   -

   rosmaita: Glance is merging like crazy today! welcome back jokke_ , and
   thanks flaper87, mfedosin , abhishekk, and smcginnis [1]
   -

   coolsvap: devs, the community support for pycharm subscription has been
   extended by one year! Enjoy [2]
   -

   Rosmaita:  Glance Pike RC-2 is now available! [3]


PTG Planning

   -

   Skip Level Upgrades[12]
   -

   Cyborg [13]
   -

   Keystone has things they want to share with the Baremetal/VM SIG [14]
   -

   CI Squad week 34 [24]


Summaries

   -

   TC Report 34[4]
   -

   api-sig/news [5]
   -

   TC Update- Aug 25th [15]
   -

   placement/resource providers update 33 [16]


Updates

   -

   Magnum is back to weekly meetings starting 8/22 every Tuesday at 16:00
   UTC
   -

   Updating the Docs Mission Statement  [17]
   -

  Thierry proposed [18]:
  -

 The docs team provides guidance, assistance, tooling, and style
 guides
 enabling OpenStack project teams to produce consistent, accurate,
 and
 high-quality documentation.
 -

  Shifting opinions towards starting from scratch- looking at what the
  docs team actually does/makes before crafting words around it [19]
  -

  Discussion will likely continue at the PTG
  -

   Microversion Parse Growth [20]
   -

  cdent has a patch that has started cleaning up and shifting
  miroversion related functions out of the placement serves and into a
  microversion-parse library [21]
  -

  Still more work to be done- decorators that handle multiple callables
  of the same name based on microversion, utility method to raise a status
  code response based microversion match, etc
  -

  cdent would like opinions on how to proceed
  -

   Custom Resource Classes, Bare Metal Scheduling and You [22]
   -

  If you run a 3rd party CI-- this is important
  -

  In Pike, Nova provides a new way of scheduling baremetal based on
  custom resource classes
  -

  The old way is now deprecated but will be UNAVAILABLE in Queens
  -

  All operators running ironic will have to set the resource class
  field before upgrading to Pike and change flavors before
upgrading to Queens
  -

  The ironic virt driver in Nova is going to be automatically migrating
  the embedded flavor within existing instances in Pike [23]
  -

  A periodic task in the nova-compute service
  will automatically create any custom resource class from an ironic
  node
  in the Placement service if it does not already exist
  -

   Install Guide Testing [25]
   -

  Docs team needs volunteers to test and verify the installation
  instructions [26]
  -

  If you find things that need work, add them here [27]
  -

  Teams in particular that should take note:
  -

 Cinder
 -

 Keystone
 -

 Horizon
 -

 Neutron
 -

 Nova
 -

 Glance
 -

   Reducing Code Complexity as a to-5 goal [6]
   -

  Different than former approaches- cdent proposes prioritization of a
  few simple rules of thumb
  -

 Extracing methods
 -

 Keeping methods short
 -

 Avoiding side effects
 -

 Keeping modules short
 -

  Cdent proposed a patch [7]
  -

  Current Top 5 list [8]
  -

   CleanUp Oslo Deprecated Stuff [9]
   -

  There are a lot of things that need to be cleaned up in Queens that
  have been deprecated in Oslo[10]
  -

  If you have questions- go to the oslo helproom at the PTG
  -

  Common gerrit topic will be ‘oslo-debt-cleanup’ to help track reviews
  around this technical debt
  -

   Marking <= mitaka EOL[11]
   -

  There are a number of old stable/* branches that need to be cleaned up
  -

  If you are involved in the following projects, please speak up!
  -

 QA
 -

 Group-based-policy
 -

 Zaqar
 -

 Packaging-deb
 -

 Fuel
 -

 networking-*
 -

  Removal is set to happen at the PTG


-Kendall Nelson (diablo_rojo)

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-08-21.log.html#t2017-08-21T13:53:36

[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-08-22.log.html#t2017-08-22T10:14:47

[3]
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-08-24.log.html#t2017-08-24T13:53:16

[4]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121383.html

[5]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121462.html

[6]
http://lists.openstack.org/pipe

[openstack-dev] [heat] heat 9.0.0.0rc2 (pike)

[no-reply]

Hello everyone,

A new release candidate for heat for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/heat/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/heat/log/?h=stable/pike

Release notes for heat can be found at:

http://docs.openstack.org/releasenotes/heat/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Emilien Macchi]

Cool, sounds like some people are interested (I haven't hear from
Kolla yet but I'm sure they are as well).

I was wondering if we should take benefit of Discussion Rooms, useful
for inter-projects topics:
https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

There is still some place, let me know what you think and we can block
a slot (maybe 2h?)
I want to hear from Kolla and OpenStack Ansible at least and know if
you have schedule constraints otherwise I'll go ahead and block a
slot.

Thanks,

On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
> On 17/08/17 10:24 -0500, Major Hayden wrote:
>>
>> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
>>>
>>> If you're working on Kolla / OpenStack-Ansible - please let us know if
>>> you have specific constraints on the schedule, so we can maybe block a
>>> timeslot in the agenda from now.
>>> We'll have a "Packaging" room which is reserved for all topics related
>>> to OpenStack deployments, so we can use this one.
>>
>>
>> I don't have any constraints (that I'm aware of), but I'd be interested in
>> participating!  Performance in the gate jobs has been one of my tasks lately
>> and I'd like to see if we can collaborate there to make improvements without
>> ruining infra's day. ;)
>>
>> As long as you can put up with a few Dad jokes, I'll be there.
>
>
> ++ I'm interested in this topic too!
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic-drac-driver]does drac-driver only support 11th or 12th generation of Dell PowerEdge servers?

[Richard.Pioso]

Hi,

I took a look at the Dell PowerEdge R370xd Rack Server web page, 
http://www.dell.com/en-us/work/shop/povw/poweredge-r730xd.  It states that 
Microsoft Windows Server 2008 R2 (W2K8 R2) is supported.

From what you described, it sounds like the issue is that W2K8 R2 does not have 
the device drivers needed for the RAID controller.  I found a Dell OS Driver 
Pack for W2K8 R2 web page, 
http://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverId=MRW6J&fileId=1943535120&osCode=W12R2&productCode=poweredge-r730xd&languageCode=en&categoryId=DD.
  Please note that it states that it does not support W2K8 R2 Service Pack 1 
(SP1).  A driver pack download is available there.  The installation 
instructions on that page are a bit involved; you may have to copy the file to 
a USB driver, plug the USB into the server, boot into the Lifecycle Controller, 
etc., etc.

In the end, while Dell supports that operating system on that server, it does 
not look like ironic will unless you can make a QCOW2 image that has the 
necessary device drivers in it.  I am not sure how exactly to do that.  It 
might be easier to just go with Microsoft Windows Server 2016, which probably 
has the necessary drivers, since there is no OS driver pack for that operating 
system on the Dell support site.

Kind regards,
Rick

From: 王俊 [mailto:wang...@yovole.com]
Sent: Thursday, August 24, 2017 10:36 PM
To: Pioso, Richard 
Subject: 答复: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

Hi Richard:
 Does R730xd support windows2008r2 sp1?I deploy the user image 
success,but it can’t be step in windows system,then I try to install window2008 
with local image(xxx.iso). I can not continue because of it can’t find no-raid 
disk or virtual disk which made by raid configure.
Can you give me some suggestion?

发件人: richard.pi...@dell.com 
[mailto:richard.pi...@dell.com]
发送时间: 2017年8月22日 23:28
收件人: 王俊 mailto:wang...@yovole.com>>
主题: RE: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

Thank you for contacting me.  No bother at all.

I have never seen that error.  It does not appear to be specific to the iDRAC 
driver.

I recommend using IRC for help with this one.

Kind regards,
Rick

From: 王俊 [mailto:wang...@yovole.com]
Sent: Tuesday, August 22, 2017 2:23 AM
To: Pioso, Richard mailto:richard_pi...@dell.com>>
Subject: 答复: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

Sorry  to bother you, I have a problem with install user image, the deploy log 
said like this:

Aug 22 07:40:42 ubuntu ironic-python-agent[1896]: Command: iscsistart -f
Aug 22 07:40:42 ubuntu ironic-python-agent[1896]: Exit code: 21
Aug 22 07:40:42 ubuntu ironic-python-agent[1896]: Stdout: u'Could not get list 
of targets from firmware.\n'
Aug 22 07:40:42 ubuntu ironic-python-agent[1896]: Stderr: u'' _check_for_iscsi 
/usr/share/ironic-python-agent/venv/local/lib/python2.7/site-packages/ironic_python_agent/hardware.py:91

And this:

Aug 22 07:41:27 ubuntu ureadahead[330]: 
ureadahead:/etc/sysctl.d/10-ipv6-privacy.conf: Error retrieving chunk extents: 
Operation not supported
Aug 22 07:41:27 ubuntu ureadahead[330]: 
ureadahead:/etc/sysctl.d/10-kernel-hardening.conf: Error retrieving chunk 
extents: Operation not supported
Aug 22 07:41:27 ubuntu ureadahead[330]: 
ureadahead:/etc/sysctl.d/10-link-restrictions.conf: Error retrieving chunk 
extents: Operation not supported
Aug 22 07:41:27 ubuntu ureadahead[330]: 
ureadahead:/etc/sysctl.d/10-magic-sysrq.conf: Error retrieving chunk extents: 
Operation not supported
Aug 22 07:41:27 ubuntu ureadahead[330]: 
ureadahead:/etc/sysctl.d/10-network-security.conf: Error retrieving chunk 
extents: Operation not supported

Do you ever seen it before?

发件人: richard.pi...@dell.com 
[mailto:richard.pi...@dell.com]
发送时间: 2017年8月18日 6:05
收件人: 王俊 mailto:wang...@yovole.com>>
主题: RE: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

Congratulations!  I am glad to hear that you have gotten by that issue.

Happy to help.

Regards,
Rick

From: 王俊 [mailto:wang...@yovole.com]
Sent: Wednesday, August 16, 2017 11:18 PM
To: Pioso, Richard mailto:richard_pi...@dell.com>>
Subject: 答复: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

I know what’s the problem.I saw the log in deploy image system whitch create by 
IPA, url_api is wrong.
Thanks a lot

发件人: 王俊
发送时间: 2017年8月17日 9:07
收件人: 'richard.pi...@dell.com' 
mailto:richard.pi...@dell.com>>
主题: 答复: [ironic-drac-driver]does drac-driver only support 11th or 12th 
generation of Dell PowerEdge servers?

I was in #openstack-ironic all day,but nobody can answer my question about 
drac-driver.maybe I should read the code to know how  process run. 
Ironic-conductor.log haven’t

Re: [openstack-dev] [docs] [ptls] Install guide testing

[Rochelle Grober]

Might I suggest a PTG activity such as an evening docathon?

Drinks and Docs

Everyone welcome to locate in some convenient location to review/test docs, 
converse and plan for the next dev cycle with Docs folks.  It might not be 
doable at this late date for Pike, but I suspect there may be some availability 
of folks during the PTG.  It's also a great way to tie up a release, having all 
the teams test the docs for the release and get a refresh of what the release 
is and where the next dev cycle needs to start from (yes, I know, it's actually 
already started, but the big plans will start from the PTG).

Just a suggestion on how to spur participation.  Hope it's helpful.

--Rocky

> From: Doug Hellmann 
> 
> Excerpts from Alexandra Settle's message of 2017-08-25 08:57:51 +:
> > Hi everyone,
> >
> > The documentation team is searching for volunteers to help test and
> > verify the OpenStack installation instructions here:
> > https://docs.openstack.org/install-guide/
> >
> > Previously this action has been undertaken by a series of volunteers,
> mostly from the documentation team. However due to the migration, and a
> significant drop in contributors, we are now seeking new individuals to help
> us complete this task.
> >
> > We will be tracking any work here:
> > https://wiki.openstack.org/wiki/Documentation/PikeDocTesting You can
> > see what we have previously done for testing here:
> > https://wiki.openstack.org/wiki/Documentation/OcataDocTesting
> >
> > PTLs of cinder/keystone/horizon/neutron/nova/glance – Previously the
> > documentation team performed the testing tasks for your respective
> > projects as they lived within the openstack-manuals repo. We
> > appreciate that you may or may not have the resources to continue this
> > effort, but it would be great if your teams are able. Please let me
> > know if you are able to so we can verify the instructions of these
> > projects :)
> >
> > Thanks,
> >
> > Alex
> 
> Thanks for starting this thread, Alex.  I want to add a little background for
> folks only now catching up with the state of the migration initiative and
> documentation for Pike.
> 
> At the start of the Pike cycle we lost most of our technical writers.
> By the time of the summit in Boston, it wasn't clear (at least to
> me) if we would have *any* writers left at the start of the Queens cycle.
> Luckily it seems we will, but without knowing that a few months ago I
> encouraged the docs team to make some decisions about prioritizing work
> that will leave us in a less than ideal, but recoverable, state for Pike.
> 
> We started by emphasizing the need to move all of the existing content to a
> new home so it could be maintained by more owners -- this was the aspect
> of the migration spec that most of you will be familiar with, and with over
> 1100 reviews tagged 'doc-migration' I think it's safe to say this was the 
> bulk of
> the work.
> 
> We did not completely address two important aspects of managing that
> content after the migration: translations and testing.
> 
> We looked into translations far enough to know that it would be possible to
> set up the jobs and build project docs in multiple languages. We're already
> doing this for some other sphinx-based docs, so we would have a pattern to
> work from.
> 
> I had hoped that if we had time after the import was done, we could develop
> a plan for end-of-cycle-testing. That didn't happen, so we will have to come
> up with a plan and execute it during Queens. No one thinks this is a good
> outcome, but it's where we are. If you're interested in helping with that
> work, I expect it will be a big part of what the docs team discusses at the 
> PTG.
> Spoiler alert: I will be advocating distributing the responsibility for 
> verifying
> instructions to the project teams.
> 
> Doug
> 
> PS - By the way, most projects are finished with the migration, but I see on
> the dashboard[1] that we still have quite a few open reviews and a few
> missing pages. At this point, the missing docs will need to be backported to
> the stable/pike branches for those projects.
> Let me know if you need help approving things in the stable branches.
> 
> [1] https://doughellmann.com/doc-migration/
> 
> __
> 
> OpenStack Development Mailing 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] Can we remove the monkey_patch_modules config option?

[Matt Riedemann]

I'm having a hard time tracing what this is necessary for. It's related 
to the notify_decorator which is around for legacy notifications but I 
don't actually see that decorator used anywhere. Given there are other 
options related to the notify_decorator, like "default_publisher_id" if 
we can start unwinding and removing this legacy stuff it would make the 
config (.005%) simpler.


It also just looks like we have a monkey_patch option that is run at the 
beginning of every service, uses monkey_patch_modules and if loaded, 
monkey patches whatever is configured for modules.


I mean, if we thought hooks were bad, this is pretty terrible.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] neutron 11.0.0.0rc3 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/pike

Release notes for neutron can be found at:

http://docs.openstack.org/releasenotes/neutron/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Jean-Philippe Evrard]

Hello Emilien,

The Discussion room is a good idea. I like it.
Most of the OpenStack-Ansible crew will be available the whole week, so we
can even think of doing a conversation outside the Wed-Friday timeframe.

If you/we all have enough time, maybe we could organise two sessions,
probably with different formats?
For example, a brainstorming session about how we collaborated on previous
cycles and how we could collaborate in the future, and another session with
the real action points based on the first conversation?

On top of that, I have extra points I'd like to discuss with you:
- Architecture of LB + web server + uwsgi
- Possibility of sharing infrastructure (mariadb/rabbitmq/...)
experience/code between projects.

Thank you in advance.

Best regards,
JP

On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi  wrote:

> Cool, sounds like some people are interested (I haven't hear from
> Kolla yet but I'm sure they are as well).
>
> I was wondering if we should take benefit of Discussion Rooms, useful
> for inter-projects topics:
> https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>
> There is still some place, let me know what you think and we can block
> a slot (maybe 2h?)
> I want to hear from Kolla and OpenStack Ansible at least and know if
> you have schedule constraints otherwise I'll go ahead and block a
> slot.
>
> Thanks,
>
> On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
> > On 17/08/17 10:24 -0500, Major Hayden wrote:
> >>
> >> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
> >>>
> >>> If you're working on Kolla / OpenStack-Ansible - please let us know if
> >>> you have specific constraints on the schedule, so we can maybe block a
> >>> timeslot in the agenda from now.
> >>> We'll have a "Packaging" room which is reserved for all topics related
> >>> to OpenStack deployments, so we can use this one.
> >>
> >>
> >> I don't have any constraints (that I'm aware of), but I'd be interested
> in
> >> participating!  Performance in the gate jobs has been one of my tasks
> lately
> >> and I'd like to see if we can collaborate there to make improvements
> without
> >> ruining infra's day. ;)
> >>
> >> As long as you can put up with a few Dad jokes, I'll be there.
> >
> >
> > ++ I'm interested in this topic too!
> >
> > Flavio
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Team picture at PTG - save the date!

[Emilien Macchi]

This is an attempt to assemble the team for a nice picture all together.
Everyone is invited to join us on Wednesday at 2:20pm.
I don't know the place yet but this will be communicated.

Bring your good humor and your best smile :-)
Hope to see you there all!
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Michał Jastrzębski]

We (Kolla) planned some time for that discussion:) It would be awesome
if we could have them on Mon-Tue, because Wed-Fri we'll have
kolla-specific design room. That being said if needed we can use it
for our cross-community discussions.

Biggest one for me is new direction of tripleo (k8s+ansible) and how
that corresponds to kolla-k8s (k8s+ansible).

On 25 August 2017 at 15:53, Jean-Philippe Evrard
 wrote:
> Hello Emilien,
>
> The Discussion room is a good idea. I like it.
> Most of the OpenStack-Ansible crew will be available the whole week, so we
> can even think of doing a conversation outside the Wed-Friday timeframe.
>
> If you/we all have enough time, maybe we could organise two sessions,
> probably with different formats?
> For example, a brainstorming session about how we collaborated on previous
> cycles and how we could collaborate in the future, and another session with
> the real action points based on the first conversation?
>
> On top of that, I have extra points I'd like to discuss with you:
> - Architecture of LB + web server + uwsgi
> - Possibility of sharing infrastructure (mariadb/rabbitmq/...)
> experience/code between projects.
>
> Thank you in advance.
>
> Best regards,
> JP
>
> On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi  wrote:
>>
>> Cool, sounds like some people are interested (I haven't hear from
>> Kolla yet but I'm sure they are as well).
>>
>> I was wondering if we should take benefit of Discussion Rooms, useful
>> for inter-projects topics:
>> https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>>
>> There is still some place, let me know what you think and we can block
>> a slot (maybe 2h?)
>> I want to hear from Kolla and OpenStack Ansible at least and know if
>> you have schedule constraints otherwise I'll go ahead and block a
>> slot.
>>
>> Thanks,
>>
>> On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
>> > On 17/08/17 10:24 -0500, Major Hayden wrote:
>> >>
>> >> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
>> >>>
>> >>> If you're working on Kolla / OpenStack-Ansible - please let us know if
>> >>> you have specific constraints on the schedule, so we can maybe block a
>> >>> timeslot in the agenda from now.
>> >>> We'll have a "Packaging" room which is reserved for all topics related
>> >>> to OpenStack deployments, so we can use this one.
>> >>
>> >>
>> >> I don't have any constraints (that I'm aware of), but I'd be interested
>> >> in
>> >> participating!  Performance in the gate jobs has been one of my tasks
>> >> lately
>> >> and I'd like to see if we can collaborate there to make improvements
>> >> without
>> >> ruining infra's day. ;)
>> >>
>> >> As long as you can put up with a few Dad jokes, I'll be there.
>> >
>> >
>> > ++ I'm interested in this topic too!
>> >
>> > Flavio
>> >
>> > --
>> > @flaper87
>> > Flavio Percoco
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][CI] FreeIPA Deployment

[Emilien Macchi]

On Sun, Aug 20, 2017 at 11:45 PM, Juan Antonio Osorio
 wrote:
> The second option seems like the most viable. Not sure how the TripleO
> integration would go though. Care to elaborate on what you had in mind?

Trying to reproduce what we did with ceph-ansible and use Mistral to
deploy FreeIPA with an external deployment tool.
Though I find the solution quite complex, maybe we can come-up with an
easier approach this time?
-- 
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] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Emilien Macchi]

On Thu, Aug 24, 2017 at 4:54 AM, Raildo Mascena de Sousa Filho <
rmasc...@redhat.com> wrote:

> So, I didn't find that topic in the TripleO umbrella[1]. Emilien, can you
> confirm that?
>

It was part of "Follow-up of future of configuration management - what we
have done - where we are and what we plan to do" which is a large topic
that include this effort I believe.



> If not, I have a suggestion, we can schedule into the reservable rooms and
> if we confirm that it will be able to do in the TripleO or any other team's
> agenda, we can remove it.
>
What do you guys think?
>

On another thread [1] we're trying to find the best slot to talk about
common topics between deployment tools. I see this one a really good topic
to discuss together.
Note if we don't have a room (worst case), tripleo team can probably host
the meeting.

Let's find a schedule that works for most of us, in the other thread.

Thanks,

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121509.html
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Emilien Macchi]

I created an etherpad: https://etherpad.openstack.org/p/deployment-queens

Please bring topics (and names) - we'll try to be prepared before the
PTG with an agenda and some scheduling.

Thanks,

On Fri, Aug 25, 2017 at 4:19 PM, Michał Jastrzębski  wrote:
> We (Kolla) planned some time for that discussion:) It would be awesome
> if we could have them on Mon-Tue, because Wed-Fri we'll have
> kolla-specific design room. That being said if needed we can use it
> for our cross-community discussions.
>
> Biggest one for me is new direction of tripleo (k8s+ansible) and how
> that corresponds to kolla-k8s (k8s+ansible).
>
> On 25 August 2017 at 15:53, Jean-Philippe Evrard
>  wrote:
>> Hello Emilien,
>>
>> The Discussion room is a good idea. I like it.
>> Most of the OpenStack-Ansible crew will be available the whole week, so we
>> can even think of doing a conversation outside the Wed-Friday timeframe.
>>
>> If you/we all have enough time, maybe we could organise two sessions,
>> probably with different formats?
>> For example, a brainstorming session about how we collaborated on previous
>> cycles and how we could collaborate in the future, and another session with
>> the real action points based on the first conversation?
>>
>> On top of that, I have extra points I'd like to discuss with you:
>> - Architecture of LB + web server + uwsgi
>> - Possibility of sharing infrastructure (mariadb/rabbitmq/...)
>> experience/code between projects.
>>
>> Thank you in advance.
>>
>> Best regards,
>> JP
>>
>> On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi  wrote:
>>>
>>> Cool, sounds like some people are interested (I haven't hear from
>>> Kolla yet but I'm sure they are as well).
>>>
>>> I was wondering if we should take benefit of Discussion Rooms, useful
>>> for inter-projects topics:
>>> https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>>>
>>> There is still some place, let me know what you think and we can block
>>> a slot (maybe 2h?)
>>> I want to hear from Kolla and OpenStack Ansible at least and know if
>>> you have schedule constraints otherwise I'll go ahead and block a
>>> slot.
>>>
>>> Thanks,
>>>
>>> On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
>>> > On 17/08/17 10:24 -0500, Major Hayden wrote:
>>> >>
>>> >> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
>>> >>>
>>> >>> If you're working on Kolla / OpenStack-Ansible - please let us know if
>>> >>> you have specific constraints on the schedule, so we can maybe block a
>>> >>> timeslot in the agenda from now.
>>> >>> We'll have a "Packaging" room which is reserved for all topics related
>>> >>> to OpenStack deployments, so we can use this one.
>>> >>
>>> >>
>>> >> I don't have any constraints (that I'm aware of), but I'd be interested
>>> >> in
>>> >> participating!  Performance in the gate jobs has been one of my tasks
>>> >> lately
>>> >> and I'd like to see if we can collaborate there to make improvements
>>> >> without
>>> >> ruining infra's day. ;)
>>> >>
>>> >> As long as you can put up with a few Dad jokes, I'll be there.
>>> >
>>> >
>>> > ++ I'm interested in this topic too!
>>> >
>>> > Flavio
>>> >
>>> > --
>>> > @flaper87
>>> > Flavio Percoco
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Emilien Macchi
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle] Tricircle PTG plan

[Vega Cai]

Hello folks,

As discussed in our weekly meeting, since most of our developers are in
China, we will hold a small scale team gathering in China. Please refer to
this etherpad page[1] for the date and place of the gathering. During the
gathering, we will discuss our topics in that etherpad page and
#openstack-tricircle channel, so for those who cannot attend the gathering
but would like to follow the discussion, you can join via etherpad and IRC.
Also, please feel free to add topic to the etherpad page.

[1] https://etherpad.openstack.org/p/tricircle-queens-ptg

BR
Zhiyuan

-- 
BR
Zhiyuan
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[David Moreau Simard]

Good idea for the etherpad.

I've added an item about the oslo/etcd integration we talked about while back.
It seemed like a common interest to align how configuration is
achieved between deployment projects.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


On Fri, Aug 25, 2017 at 8:00 PM, Emilien Macchi  wrote:
> I created an etherpad: https://etherpad.openstack.org/p/deployment-queens
>
> Please bring topics (and names) - we'll try to be prepared before the
> PTG with an agenda and some scheduling.
>
> Thanks,
>
> On Fri, Aug 25, 2017 at 4:19 PM, Michał Jastrzębski  wrote:
>> We (Kolla) planned some time for that discussion:) It would be awesome
>> if we could have them on Mon-Tue, because Wed-Fri we'll have
>> kolla-specific design room. That being said if needed we can use it
>> for our cross-community discussions.
>>
>> Biggest one for me is new direction of tripleo (k8s+ansible) and how
>> that corresponds to kolla-k8s (k8s+ansible).
>>
>> On 25 August 2017 at 15:53, Jean-Philippe Evrard
>>  wrote:
>>> Hello Emilien,
>>>
>>> The Discussion room is a good idea. I like it.
>>> Most of the OpenStack-Ansible crew will be available the whole week, so we
>>> can even think of doing a conversation outside the Wed-Friday timeframe.
>>>
>>> If you/we all have enough time, maybe we could organise two sessions,
>>> probably with different formats?
>>> For example, a brainstorming session about how we collaborated on previous
>>> cycles and how we could collaborate in the future, and another session with
>>> the real action points based on the first conversation?
>>>
>>> On top of that, I have extra points I'd like to discuss with you:
>>> - Architecture of LB + web server + uwsgi
>>> - Possibility of sharing infrastructure (mariadb/rabbitmq/...)
>>> experience/code between projects.
>>>
>>> Thank you in advance.
>>>
>>> Best regards,
>>> JP
>>>
>>> On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi  wrote:

 Cool, sounds like some people are interested (I haven't hear from
 Kolla yet but I'm sure they are as well).

 I was wondering if we should take benefit of Discussion Rooms, useful
 for inter-projects topics:
 https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

 There is still some place, let me know what you think and we can block
 a slot (maybe 2h?)
 I want to hear from Kolla and OpenStack Ansible at least and know if
 you have schedule constraints otherwise I'll go ahead and block a
 slot.

 Thanks,

 On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
 > On 17/08/17 10:24 -0500, Major Hayden wrote:
 >>
 >> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
 >>>
 >>> If you're working on Kolla / OpenStack-Ansible - please let us know if
 >>> you have specific constraints on the schedule, so we can maybe block a
 >>> timeslot in the agenda from now.
 >>> We'll have a "Packaging" room which is reserved for all topics related
 >>> to OpenStack deployments, so we can use this one.
 >>
 >>
 >> I don't have any constraints (that I'm aware of), but I'd be interested
 >> in
 >> participating!  Performance in the gate jobs has been one of my tasks
 >> lately
 >> and I'd like to see if we can collaborate there to make improvements
 >> without
 >> ruining infra's day. ;)
 >>
 >> As long as you can put up with a few Dad jokes, I'll be there.
 >
 >
 > ++ I'm interested in this topic too!
 >
 > Flavio
 >
 > --
 > @flaper87
 > Flavio Percoco
 >
 >
 > __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >



 --
 Emilien Macchi

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __