Re: [openstack-dev] [oslo][mistral] Mistral expressions package

[Renat Akhmerov]

Hi,

I’m not too happy about the idea of creating one more subproject within 
Mistral. I don’t even see now what else this new library project managed by 
Mistral team will contain besides this expression utils module. I’m also not 
sure about its name. We already have mistral-lib which was created for a 
different purpose (public APIs for making Mistral extensions like actions and 
YAQL/Jinja functions).

Just to clarify: the code we’re talking about is really small and stable (we 
haven’t touched it for a while, it just works), and it’s generic so it can be 
reused in many situations by many projects. That’s why we had an idea to find a 
place within one of the Oslo libraries, just to make one more package (or even 
module), for example, in oslo.utils. As far as maintaining this code, we could 
still do that. But anyway, if that’s not OK, I’d just suggest we leave it as it 
is. If this code needs to be reused somewhere else outside OpenStack space 
(like in Bob’s case) may be it’s just simpler to create a project on github?

Thanks

Renat Akhmerov
@Nokia

On 10 Oct 2017, 22:11 +0700, Doug Hellmann , wrote:
> Excerpts from HADDLETON, Robert W (Bob)'s message of 2017-10-09 19:41:58 
> -0500:
> > On 10/9/2017 2:35 PM, Doug Hellmann wrote:
> > > Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> > > > Hello Oslo team:
> > > >
> > > > The Mistral project has an expressions package [0] that is used to
> > > > evaluate inline expressions using a context. It has a pluggable
> > > > architecture that presently supports Jinja and YAQL expression
> > > > evaluation. It also allows custom functions[1] to provide Python
> > > > implementations of functionality that is then made available to the
> > > > expression evaluation engines.
> > > >
> > > > This functionality was originally developed to support dynamic
> > > > processing within Mistral workflows, but is also very useful in other
> > > > applications that use templates which require runtime evaluation of
> > > > expressions.
> > > >
> > > > I'd like to explore extracting this functionality from mistral to make
> > > > it more widely available with minimal dependencies.
> > > >
> > > > The expressions dependencies are pretty limited:
> > > >
> > > > Jinja2
> > > > oslo.utils
> > > > oslo.log
> > > > stevedore
> > > > yaql
> > > >
> > > > and since 60% are already oslo-maintained packages, it seemed like a
> > > > logical place to start.
> > > >
> > > > I'd appreciate feedback on the topic. There is no real OpenStack
> > > > dependency in the functionality, so maybe a standalone package on pypi
> > > > makes sense.
> > > >
> > > > Thanks for your help,
> > > >
> > > > Bob Haddleton
> > > >
> > > >
> > > > [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> > > > [1]
> > > > https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> > > >
> > > Oslo is a good place for things like this that have no other obvious
> > > home, but if the Mistral team is already managing the code is there any
> > > reason they couldn't also manage the library after you pull it out of
> > > the service? It's much easier for any project team to manage a library
> > > now, and we have several other examples of that pattern already.
> > >
> > > Doug
> > >
> > > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > Hi Doug:
> >
> > That's probably fine, we're just not sure what the process should be and
> > where the library would land?  Do you have an example that we could use
> > as a pattern?
> >
> > Thanks
> >
> > Bob
>
> The first step is to create the repository with the library code. Then
> you would add that repository to the list managed by the mistral team by
> modifying the project list file in the governance repository.
>
> Any of the project client libraries would work as an example of how to
> set up the CI, governance, and release configuration. I think most of
> the steps are covered in
> https://docs.openstack.org/infra/manual/creators.html as well.
>
> If the code is already isolated well within the mistral repo and you
> want to preserve its history, you may also want to take a look at
> http://git.openstack.org/cgit/openstack/oslo.tools/tree/filter_git_history.sh
> as a tool for making the new repository.
>
> I'm happy to help you work out a more detailed plan. Let me know if that
> would be useful.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][mistral] Asking for stable branch policy exception

[Renat Akhmerov]

Dougal,

I forgot to mention that explicitly but, yes, #1 is needed only not to break 
the sequence of migrations. We can manually fix the migration number in #2 just 
for stable/pike but I somewhat don’t like the idea of having different 
migration numbers in different branches.

It’s a good news that we’re not going to break TripleO.

Thanks

Renat Akhmerov
@Nokia

On 17 Oct 2017, 20:21 +0700, Dougal Matthews , wrote:
>
>
> > On 17 October 2017 at 09:19, Renat Akhmerov  
> > wrote:
> > > Hi,
> > >
> > > We have two patches in Mistral that we need to back port to stable/pike. 
> > > However, they are against of stable branch management policy because they 
> > > slightly change the DB schema. The patches are the following:
> > >
> > > 1. https://review.openstack.org/#/c/512528/
> > > 2. https://review.openstack.org/#/c/512256/
> > >
> > >
> > > #2 is a critically important fix that fixes a problem of decreasing 
> > > Mistral performance when DB becomes heavy (has lots of execution 
> > > objects). This is a blocker issue for us (Nokia) preventing us using 
> > > Mistral in production. It also seriously optimizes performance in general.
> > >
> > > So hereby I'm asking your advice on what we can do in this situation. Can 
> > > we merge these patches if we make sure that we don't break anyone in the 
> > > community? For example, TripleO.
> >
> > As far as I am aware, this wont be a problem for TripleO. These patches are 
> > both additive (new db column and new db index).
> >
> > The first patch (512528) is only a candidate for backport to avoid breaking 
> > the migration history order, it isn't otherwise needed in Pike. How is this 
> > normally handled in other projects? i.e. we need to backport migration 24 
> > to Pike, but 23 is in master only. I assume this problem has came up before 
> > and been solved, but I can't find any examples.
> >
> >
> > >
> > > Thanks
> > >
> > > Renat Akhmerov
> > > @Nokia
> > >
> > > __
> > > OpenStack Development Mailing 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] [telemetry] ceilometer-notification restart with no consumers on ceilometer-pipe

[Hanxi Liu]

Hi, tianqing

I saw your pipline.yaml and found the configurations
I think you should remove the excluded symbol because it would
filter all cpu*, disk*, memeory*, network* sources.


Cheers,
Hanxi Liu
irc(lhx_)


On Wed, Oct 18, 2017 at 11:17 AM, 李田清  wrote:

> Hello,
> I am testing ceilometer workload partition. And find that if we
> restart
> agent notification, the ceilometer-pip* queue will not have consumers
> any more.
> Does anyone know this? The pipeline.yaml is here
> http://paste.openstack.org/show/623909/
> And i also find the ceilometer-pipe-meter_source:meter_sink-queue
> always has many messages in it.
> Does anyone met this before, or some suggestions can share? Thanks a
> lot...
>
> __
> OpenStack Development Mailing 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] Unified Limits work stalled - next steps, need for new leadership

[王玺源]

HI Sean,
  I think that we(Lance and I) from Huawei are willing to take over and
continue this feature. I hope that we can get some information and
suggestion from you. Such as: what’s the progress now? What should I do
now? IMHO, the main work now is to update and polish these two specs[1],
right? I'll continue to update them if no objection.

Thanks.


[1]: https://review.openstack.org/#/c/441203
 https://review.openstack.org/#/c/455709

2017-09-08 3:18 GMT+08:00 Sean Dague :

> This is an email that's probably overdue, but time gets away from all of
> us. Coming out of Atlanta and even Boston we were pushing pretty hard on a
> new approach to unify limits, as well as building the infrastructure to
> have hierarchical limits possible in OpenStack (keystone merged spec -
> https://specs.openstack.org/openstack/keystone-specs/specs/
> keystone/ongoing/unified-limits.html)
>
> However, this effort pretty much as run out of gas, and really needs a new
> driver (or set of drivers) to make forward progress. My current set of
> responsibilities doesn't really make it possible for me to own driving this
> (though I will be happy to help others). That seems to also be true of many
> of the others that were engaged.
>
> This is going out in advance of the PTG in case any developer(s), or
> organizations feel that hierarchical limits are a priority for them, and
> would be willing to step up there. If so please feel free to reach out, and
> we can carve out some PTG time in helping a new push organize here.
>
> However, without new leadership here, the current plan is to just put the
> effort to rest.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [telemetry] ceilometer-notification restart with no consumers on ceilometer-pipe

[李田清]

Hello,
I am testing ceilometer workload partition. And find that if we restart 
agent notification, the ceilometer-pip* queue will not have consumers any 
more.
Does anyone know this? The pipeline.yaml is here 
http://paste.openstack.org/show/623909/ 
And i also find the ceilometer-pipe-meter_source:meter_sink-queue always 
has many messages in it. 
Does anyone met this before, or some suggestions can share? Thanks a lot...__
OpenStack Development Mailing 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] [acceleration] Cancellation of Cyborg Team Meeting this week

[Zhipeng Huang]

Hi team,

Since I'm traveling to OpenStack Day Nordic, I would have to cancel our
team meeting this week, but if you have any items to discuss plz feel free
to put them on our irc channel #openstack-cyborg
__
OpenStack Development Mailing 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][blazar][heat] Remove oslotest.mockpatch

[ChangBo Guo]

Zane,

Thanks for the update,  we can clean up this module from Oslo side.


2017-10-18 2:10 GMT+08:00 Zane Bitter :

> On 16/10/17 09:53, ChangBo Guo wrote:
>
>> The oslotest.mockpatch has been deprecated in favor of native fixtures in
>> [1] , need remove its usage in python-heatclient, python-blazarclient
>> [2][3],  Heat/Blazar team please help review, then we'll merge [4]
>>
>>
>> [1]https://review.openstack.org/#/c/245199/
>> [2]https://review.openstack.org/#/c/496120/
>>
>
> I guess this was meant to be a link to https://review.openstack.org/#
> /c/503067/ :)
>
> It turns out there's an identical patch https://review.openstack.org/#
> /c/495533/ that already had one +2, so I approved that one.
>
> - ZB
>
> [3]https://review.openstack.org/#/c/496120/
>> [4] https://review.openstack.org/495534
>>
>> --
>> ChangBo Guo(gcb)
>> Community Director @EasyStack
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
OpenStack Development Mailing 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 Dev Digest is Open to Volunteers!

[Mike Perez]

Hey all,

The OpenStack Dev Digest has been receiving great feedback from various members
of our community as being a good resource to get important summaries of threads
they might be interested in responding back to and/or being informed on.

Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
when I can, gets posted on the dev list, the operators lists, OpenStack
twitter, and LWN [2].

Summarizing everything can be a lot of work. I recently read the User Group
Newsletter [3] by Sonia Ramza and noticed the content is created by the
community via an etherpad.

I would like to do the same with the Dev Digest and have started a new etherpad
[4]. I will still be writing the Dev Digest and acting editor, but hoping to
lean more on the community for content I might've missed and getting
corrections.

The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
you!

[1] - https://www.openstack.org/blog
[2] - https://lwn.net
[3] - 
https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
[4] - https://etherpad.openstack.org/p/devdigest

-- 
Mike Perez


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] IBM z/VM CI asks for reporting permission to Nova changes

[Chen CH Ji]

Hi Andreas
   Exactly, we found the issue yesterday and will fix it
soon,  really appreciate your info and help~

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Andreas Scheuring 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/17/2017 08:10 PM
Subject:Re: [openstack-dev] IBM z/VM CI asks for reporting permission
to Nova changes



Hi Laurene,

at the moment the z/VM CI is posting a +1 even though the job failed.
That’s because in zuul layout.yaml the job is probably set to "voting:
false.” You can easily fix this by setting it to “true”.

For example see https://review.openstack.org/#/c/512190/

Regards,

---
Andreas Scheuring (andreas_s)



  On 12. Oct 2017, at 06:42, Xiao Mei GZ Zheng 
  wrote:



  Hello,

  I'm requesting reporting permission (non-voting) to Nova changes for
  the IBM z/VM CI. The wiki is on link [1].

  We designed the CI using nodepool , zuul and Jenkins. The newly
  uploaded patches will receive an initial +/-1 reports from Jenkins
  only for the nova project (just comments on patches but not vote on
  them). Tests completed on the z/VM Driver CI system check-nova
  pipeline. For more information see[2]. To recheck it, you just submit
  a comment with only zvm:recheck in the comment.

  The IBM z/VM CI system has been running for a long time in a stable
  fashion. We present all test artifacts on a public link [3] to make
  debugging failed tests easier. You can see environment details,
  openstack logs and tempest logs.

  * Gerrit Account: zvmosci

  * Gerrit query on patches where the CI commented: [4]

  * Proposal for naming: IBM z/VM CI

  For any questions feel free to reach out to me (Laurene) or to Leon!

  [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI

  [2] https://wiki.openstack.org/wiki/ZVMDriver/zVM-CI


  [3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/


  [4] https://review.openstack.org/#/c/410596/

  Thanks & Best Regards!

  Laurene(Xiao Mei) Zheng
  
  Software developer, CSTL
  IBM China Systems & Technology Lab (CSTL)



  __

  OpenStack Development Mailing 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
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=qBwOmwjtiIbNH88QysyUiSxJT3O4PS0lsayyEqezZSU=fq-TSltLCGGZjat8QSfPpcqiKSaH9GO4VhovL1ElZWQ=



__
OpenStack Development Mailing 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] [nova][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

[Chen CH Ji]

Thanks for sharing this info, I already keep an eye on this change and
understand the reason,
so if I understand this correctly, out of tree driver only need
'allocations' to be added for spawn and rebuild function and up to the
driver to use it, correct?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Eric Fried 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/18/2017 04:07 AM
Subject:[openstack-dev] [nova][out-of-tree drivers] Breaking change to
ComputeDriver.spawn and friends



Out-of-tree virt driver maintainers, please keep an eye on [1], which
will force you to update the signature of your spawn and rebuild
overrides.  See the commit message for the whys and wherefores, and let
me know if you have any questions.

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_511879=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M=W6Y0oep8w6Gkm_LMDQQb3ISzmAwzMEUej7uIP6wPpGo=


Thanks,
Eric Fried (efried)
.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=8oX5g02pZ4Ix5m6E7QSmfcothpbtEouRYL0QxNGYv9M=oD7yXwwFk6qjyA_YLNpc_ZCPqChdsni1Q7G08p_TXZI=




__
OpenStack Development Mailing 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] [masakari]oslo.context 2.19.1 is currently blocked

[Rikimaru Honjo]

Hello Ben,

On 2017/10/18 0:05, Ben Nemec wrote:

Can you add masakari to https://bugs.launchpad.net/oslo.context/+bug/1721432 so 
we don't miss it in the process of fixing this problem?  At some point we will 
be releasing a new oslo.context and we need to make sure we get all the broken 
projects fixed before then.


OK.
I added masakari to the bug report.


Thanks.

-Ben

On 10/17/2017 04:18 AM, Rikimaru Honjo wrote:

Hello Masakari contributors,

I submitted a patch which fixes masakari UT codes according to oslo.context 
2.19.1.[1]
Because oslo.context 2.19.1 adds 'project' key in context's to_dict function.[2]

But, I realized that the latest global-requirement blocks oslo.context 
2.19.1.[3]
So I abandoned my patch because it is unnecessary.
I think that we can merge "Updated from global requirements" patch now.

[1]
Fix UT codes according to updating oslo.context
https://review.openstack.org/#/c/510760/
[2]
Output 'project' key in context's to_dict function
https://review.openstack.org/#/c/507444/
[3]
Block oslo.context 2.19.1
https://review.openstack.org/#/c/510857/




--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
★社名とメールアドレスが変わりました。

NTTテクノクロス株式会社
クラウド&セキュリティ事業部 第二事業ユニット（CS2BU）
本上力丸
TEL.  :045-212-7539
E-mail:honjo.rikim...@po.ntt-tx.co.jp
〒220-0012
  横浜市西区みなとみらい4丁目4番5号
  横浜アイマークプレイス 13階



__
OpenStack Development Mailing 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][docs][contributor-guide] Onboarding Contributor Content Help Wanted

[Mike Perez]

Hey all,

tldr; There's an effort to collect general documentation for new OpenStack
contributors. The content that qualifies as general so far is Git, IRC, account
setup. We are looking for help to write new content at the git repo
openstack/contributor-guide.

No that subject tag is not a mistake. There are two projects recently that I've
been active with that have the word "Contributor" in it.

1) Contributor Portal - The openstack.org/community page update that focuses
   more on guiding potential contributors to areas of interest. This will link
   people to the general documentation set for that category (The Contributor
   Guide)and the project team's specific documentation if any. Everyone gets
   general onboarding contributor documentation for free! In addition it serves
   as a great landing page of resources for existing contributors. [1]

2) Contributor Guide - A sphinx project of where the general documentation
   is stored. [2] I'm waiting on a couple of patches to merge [3][4], but this
   will be published at https://docs.openstack.org/contributors

My goal is to make the Contributor Guide and Contributor Portal available to
all projects for their Onboarding rooms in Sydney [5].

If you're not familiar with this effort, we're creating general documentation
(e.g. IRC, git, account setup, and more) in an effort to keep them up-to-date
and not have outdated silos of this type of documentation. From the PTG
discussion [4] it was agreed that general documentation can live in a separate
repository (i.e. Contributor Guide), but project specific documentation will
continue to live in the development documentation of the respected project.

I'm looking for volunteers to help build our Contributor guide. I think
a good starting point is to look at how we can help keep some content fresh for
things like the Upstream Institute [6]. They have a great layout that we can
build off of from their content page [7].

If anyone is interested in helping with making our onboarding experience
better, please checkout the git repository [8] and lets collaborate on this
content. I'm thingee on freenode and in the #openstack-doc room for these
related discussions.

Shout out to Kendall Nelson, Anne Bertucio, Frank Kloeker, Ildiko Vancsa, Amy
Marrich, Thierry Carrez, Lauren Sell, Jimmy McArthur, Wes Wilson, the
Documentation Core team, and Infra core team for getting this project going!

Thanks!

[1] - http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html
[2] - https://review.openstack.org/#/c/511033/
[3] - https://review.openstack.org/#/c/512865/
[4] - https://review.openstack.org/#/c/512871/
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123206.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html
[7] - https://docs.openstack.org/upstream-training/
[8] - 
https://docs.openstack.org/upstream-training/upstream-training-content.html
[9] - https://git.openstack.org/contributor-guide

-- 
Mike Perez


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] [forum] Schedule Is Available

[Mike Perez]

On 16:43 Oct 16, Mike Perez wrote:
> Hey all,
> 
> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
> the
> schedule posted on the Summit site filtering by forum related sessions:
> 
> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63
> 
> Please reply to give corrections.
> 
> I will be sending emails to listed moderators to verify there will be someone
> physically present at the Forum to moderate the session. Thank you!

Hey all,

I was infomed that making changes to the schedule can cause a cascade of
conflicts at this point. If you are scheduled however at multiple places at
once, please let us know at speakersupp...@openstack.org

Thanks everyone!

-- 
Mike Perez


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] [nova][out-of-tree drivers] Breaking change to ComputeDriver.spawn and friends

[Eric Fried]

Out-of-tree virt driver maintainers, please keep an eye on [1], which
will force you to update the signature of your spawn and rebuild
overrides.  See the commit message for the whys and wherefores, and let
me know if you have any questions.

[1] https://review.openstack.org/511879

Thanks,
Eric Fried (efried)
.

__
OpenStack Development Mailing 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] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

[Matthew Treinish]

On Tue, Oct 10, 2017 at 04:34:29PM -0400, Sean Dague wrote:
> On 10/10/2017 04:22 PM, Dean Troyer wrote:
> > On Tue, Oct 10, 2017 at 1:15 PM, Andrea Frittoli
> >  wrote:
> >> - we will treat +1 from infra-core members on devstack changes in the
> >> ansible bits as +2
> >> - add clarkb to devstack-core, since he's quite aware of the the devstack
> >> codebase
> > 
> > +2 on both of these proposals!
> 
> Agreed +2.
> 

+2 from me too.

-Matt Treinish


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] [designate] Skipping this weeks meeting

[Graham Hayes]

Hi,

I have a conflict this week with a different meeting.

I would suggest we skip this week unless there is someone who can chair
it in my absence?

Thanks,

Graham



signature.asc
Description: OpenPGP digital 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] [all][tc] TC Candidates: what does an OpenStack user look like?

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2017-10-16 18:10:20 -0400:
> On 14/10/17 11:47, Doug Hellmann wrote:
> > Excerpts from Zane Bitter's message of 2017-10-13 15:21:14 -0400:
> >> Replying to myself here, to avoid singling anyone in particular out. I
> >> want to rephrase the question, because people are overwhelmingly either
> >> failing to understand or refusing to answer it in the way I intended it.
> >>
> >> Most of the candidates are essentially saying that the answer is 
> >> 'everyone'.
> >>
> >> I'm glad that we have such a bunch of next-level geniuses running for
> >> the TC that they are able to analyse the needs of all 7 billion people
> >> and evaluate every decision they make against all of them in real time.
> >> Me, I'm just an ordinary guy who can only hold a few things in his head
> >> at once, so I just try to focus on those and collaborate with people who
> >> have different perspectives to make sure that a range of needs are
> >> covered. This is kind of the founding principle of the Open Source
> >> (note: not Free Software) movement, actually. None of us is as smart as
> >> all of us (present company excepted, apparently). So it's good, but
> >> somewhat surprising that y'all are still here, given that you would be
> >> guaranteed insta-billionaires if you went out and started a proprietary
> >> software company.
> >>
> >> All sarcasm aside though, 'everyone' is a BS non-answer. It's the
> >> politician's answer.
> > 
> > Blaming the respondents for answering a imprecisely worded question
> > in a way other than it was intended? We can do better.
> 
> I honestly didn't feel it was an imprecisely worded question - I 
> included an example, and carefully defined things such as "By 'users' 
> here I mean end-users, the actual consumers of OpenStack APIs". 
> Nevertheless, I have no problem admitting that I was wrong. Allowing for 
> that possibility was the reason I rephrased the question.
> 
> > Your original question "Who are _you_ building OpenStack for?" was
> > much more vague than the rephrasing below that specifically asks
> > about advocacy.
> 
> I agree, reading your and Ildiko's and James's responses it's now clear 
> to me that this was the root of the problem. It was too easy to 
> interpret this as the entirety of the question, rather than just a glib 
> way of summing up the actual question immediately preceding it, the 
> paragraph of exposition before that, and the example that followed. I 
> regret muddying the waters by tacking it on the end.
> 
> > Even the rewritten question can be answered
> > legitimately using several different personas by people with a bit
> > of experience.  I have worked at a public cloud provider and two
> > distributors with a wide range of customers, and I use OpenStack
> > clouds myself. I hope that all of that background feeds into my
> > contributions.
> 
> Yes, that's great. I think most people would agree that there's a 
> threshold somewhere between 'several' and 'infinity' beyond which we've 
> crossed over into platitudes though.

Maybe. On the other hand, TC members aren't elected to represent
specific constituencies, so there's something to be said for taking each
case as it comes and considering the users impacted by that case.

> 
> >> Not only because engineering trade-offs are a real thing, and some use
> >> cases will *definitely* be excluded in order to better serve others, but
> >> because the average user doesn't exist. If you design for the 'average'
> >> user then you are designing for nobody, because nobody is the average
> >> user. We shouldn't be designing for 'everybody' (aka nobody in
> >> particular), but for a large variety of somebodies.
> >>
> >> As an example, look at the Keystone discussion that I linked below.
> >> - If you were designing Keystone for an individual user, you'd might
> >> just have one account per tenant.
> >> - If you were designing Keystone for a team deploying semi-autonomous
> >> apps, you might design a way for multiple agents to authenticate to each
> >> tenant.
> >> - If you were designing Keystone for 'everyone', you might have a matrix
> >> of users, tenants and roles - the most generic solution, right? - and
> >> spend half a decade polishing it without ever realising that individual
> >> users don't need it and teams can't use it.
> > 
> > Or you might conclude that the real problem isn't in the identity
> > service data model, but in the services that don't yet have an
> > operation to transfer ownership of resources when a user is
> > deactivated.
> 
> Sure, although note that Keystone itself would have to be one of those 
> services - you'd have to be able to transfer ownership of trusts for it 
> to work.

Sure. I think changing ownership is a new concept across the board.

> 
> Suffice to say that nobody should take my example here as anything more 
> than a rationale for the importance of user-centred design.[1] 

How much "design" do you think the TC is doing as a 

[openstack-dev] [tc] [all] TC Report 42

[Chris Dent]

( with clicky things: https://anticdent.org/tc-report-42.html )


we can't always hold the belief which we believe 5 years ago


After [last week's report](https://anticdent.org/tc-report-41.html) I
got into an [interesting
conversation](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T21:19:17)
about it. The quote above is from that, by flwang1. I thought it was
worth highlighting; OpenStack continues to evolve and grow and what
was once true may be no longer.

[TC
elections](https://governance.openstack.org/election/#queens-tc-candidates)
are in progress. Near the end of last week there was a period where
the candidates were presented with the opportunity to answer questions
from the community. If you can vote and you haven't yet (or even if you
have) there are some good questions and answers:

* [What does and OpenStack user look
  like? Who are you building 
for?](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123524.html)
* [What's something you wish the TC had done something
  about? What should have been 
done?](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123531.html)
* [What's a governance review that was
  
interesting/important/good?](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123533.html)
* [How can we make our community more
  
inclusive?](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123580.html)
* [What will you do if you don't
  
win?](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123639.html)

Voting continues until _Oct 20, 2017 23:45 UTC_. If you are eligible
to vote you should have received an email from `"Kendall Nelson (CIVS
poll supervisor)" ` with a subject of `Poll:
Queens TC Election`. Several people have reported finding theirs in
their spam folder, especially on gmail.

# Other Stuff

There's plenty of other stuff going on.

## Take your manager to the TC day

On Wednesday, Josh Harlow showed up asking if [a meeting between the
TC and managers of engineers committed to
OpenStack](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-11.log.html#t2017-10-11T18:57:38)
might be fruitful. There were mixed reactions, much around "what would
we do with the information gained?" and "how do you make it be
something other than a festival of complaint?"

If we can figure out good answers to those questions, I think it could
be a useful engagement. There's an implicit assumption that there is
straightforward proxying across the several boundaries between the
happenings in the OpenStack community and what's going on within the
confines of an employer. That assumption doesn't seem to be valid, and
even if it is, having some conversations to re-align expectations
(from all sides) could be useful.

## Glare

The ongoing debate related to Glare's [application to be an official
project](https://review.openstack.org/#/c/479285/) stalled today when
the proposer chose to withdraw the application to give more time for
some of the issues to resolve in a more obvious fashion. This is
despite the application having crossed the requisite threshold for
approval. There are some highlights from the discussion that are worth
remembering for when this comes up again:

* Thursday's office hour [revisited some of the
  
issues](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-12.log.html#t2017-10-12T15:04:23).
* [Review comments](https://review.openstack.org/#/c/479285/) that
  represent some of the positions (all on patchset 6):
* "We talk about encouraging innovation and a certain kind of competition
  in the project spaces, but it is clearly not a free-market, when it comes
  down to it we have more of a protectionist view in many areas."
* "I think the Glare team is refocusing on the right things. I would like
  to observe that change for a while to see how it goes before approving."
* The potential overlap with Glance and/or the image API or disruption
  thereof is a concern.
* "lack of focus: storing binary blobs and associated metadata is not a
  goal unto itself"

## Foundation Board Activities

In today's office hour, there were two topics related to the TC's
interaction with the OpenStack Foundation Board. There will be another
joint Board/TC/UC meeting and while [agenda items are
solicited](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-17.log.html#t2017-10-17T09:04:16)
there's general agreement that the meeting in Denver feels like it was
yesterday.

The other topic was about initial discussions around [expanding the
projects](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-17.log.html#t2017-10-17T09:20:29)
hosted by the Foundation to allow not-OpenStack,
but-related-to-OpenStack projects to be in the domain of the
Foundation. Examples include tools that enable NFV, edge 

Re: [openstack-dev] [oslo][blazar][heat] Remove oslotest.mockpatch

[Zane Bitter]

On 16/10/17 09:53, ChangBo Guo wrote:
The oslotest.mockpatch has been deprecated in favor of native fixtures 
in [1] , need remove its usage in python-heatclient, python-blazarclient 
[2][3],  Heat/Blazar team please help review, then we'll merge [4]



[1]https://review.openstack.org/#/c/245199/
[2]https://review.openstack.org/#/c/496120/


I guess this was meant to be a link to 
https://review.openstack.org/#/c/503067/ :)


It turns out there's an identical patch 
https://review.openstack.org/#/c/495533/ that already had one +2, so I 
approved that one.


- ZB


[3]https://review.openstack.org/#/c/496120/
[4] https://review.openstack.org/495534

--
ChangBo Guo(gcb)
Community Director @EasyStack


__
OpenStack Development Mailing 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] [docs][ptls][all] documentation retention policy changes

[Petr Kovar]

On Thu, 28 Sep 2017 12:51:18 -0400
Doug Hellmann  wrote:

> At the Queens PTG in Denver the documentation team members present
> discussed a new retention policy for content published to
> docs.openstack.org. I have a spec up for review to document that
> policy and the steps needed to implement it. This policy will affect
> all projects, now that most of the documentation is managed by
> project teams. Please take a few minutes to review it, or at the
> very least have your documentation team liaison do so.
> 
> https://review.openstack.org/#/c/507629

We've just approved this spec. Thanks Doug for putting this together!

With this spec approved, we'll no longer delete EOL docs and will also
restore (some of the) Mitaka content back to docs.openstack.org/mitaka.

We still need help with updating the Ocata branch and (writing
a spec) and implementing badges to warn users about unsupported content. If
you can help with these, please let us know (and see the thread Flagging
deprecated releases started by Jimmy).

Cheers,
pk

__
OpenStack Development Mailing 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 and traits

[Dmitry Tantsur]

Hi!

Answering to both Eric and John inline.

On 10/16/2017 07:26 PM, John Garbutt wrote:
> On 16 October 2017 at 17:55, Eric Fried  > wrote:
>
> * Adding references to the specs: ironic side [1]; nova side [2] (which
> just merged).
>
> * Since Jay is on vacation, I'll tentatively note his vote by proxy [3]
> that ironic should be the source of truth - i.e. option (a).  I think
> the upshot is that it's easier for Ironic to track and resolve conflicts
> than for the virt driver to do so.
>
>
> As I see it, all of these options have Ironic as the source of truth for Nova.
>
> Driver here is about the Ironic drivers, not Nova virt driver.

This is correct, sorry for confusion.

>
>   > The downside is obvious - with a lot of deploy templates
>
> > available it can be a lot of manual work.
>
> * How does option (b) help with this?
>
>
> The operator defines the configuration templates. The driver could then report
> traits for any configuration templates that it knows it a given node can 
> support.

Yeah, this avoids explicit

  openstack baremetal node trait set  CUSTOM_RAID_5

for many nodes.

>
> But I suspect a node would have to boot up an image to check if a given set of
> RAID or BIOS parameters are valid. Is that correct? I am sure there are way to
> cache things that could help somewhat.

BIOS - no. RAID - well, some drivers do RAID in-band, but I think we can only
leave driver-side validation here to simplify things.

>
> * I suggested a way to maintain the "source" of a trait (operator,
> inspector, etc.) [4] which would help with resolving conflicts.
> However, I agree it would be better to avoid this extra complexity if
> possible.
>
>
> That is basically (b.2).
>
>
> * This is slightly off topic, but it's related and will eventually need
> to be considered: How are you going to know whether a
> UEFI-capable-but-not-enabled node should have its UEFI mode turned on?
> Are you going to parse the traits specified in the flavor?  (This might
> work for Ironic, but will be tough in the general case.)

We have a nova spec approved for passing matches traits to ironic. Ironic then
will use them to figure out. Currently it works the same way with capabilities.

>
> [1] https://review.openstack.org/504531 
> 
>
> Also the other ironic spec: https://review.openstack.org/#/c/504952
>
> [2] https://review.openstack.org/507052 
> 
> [3]
> 
> https://review.openstack.org/#/c/507052/4/specs/queens/approved/ironic-traits.rst@88
> 
> 
> [4]
> 
> https://review.openstack.org/#/c/504531/4/specs/approved/node-traits.rst@196
> 
> 
>
> On 10/16/2017 11:24 AM, Dmitry Tantsur wrote:
>  > Hi all,
>  >
>  > I promised John to dump my thoughts on traits to the ML, so here we go 
> :)
>  >
>  > I see two roles of traits (or kinds of traits) for bare metal:
>  > 1. traits that say what the node can do already (e.g. "the node is
>  > doing UEFI boot")
>  > 2. traits that say what the node can be *configured* to do (e.g. "the
> node can
>  > boot in UEFI mode")
>  >
>  > This seems confusing, but it's actually very useful. Say, I have a 
> flavor
> that
>  > requests UEFI boot via a trait. It will match both the nodes that are
> already in
>  > UEFI mode, as well as nodes that can be put in UEFI mode.
>  >
>  > This idea goes further with deploy templates (new concept we've been 
> thinking
>  > about). A flavor can request something like CUSTOM_RAID_5, and it will
> match the
>  > nodes that already have RAID 5, or, more interestingly, the nodes on 
> which we
>  > can build RAID 5 before deployment. The UEFI example above can be 
> treated
> in a
>  > similar way.
>  >
>  > This ends up with two sources of knowledge about traits in ironic:
>  > 1. Operators setting something they know about hardware ("this node is 
> in
> UEFI
>  > mode"),
>  > 2. Ironic drivers reporting something they
>  >   2.1. know about hardware ("this node is in UEFI mode" - again)
>  >   2.2. can do about hardware ("I can put this node in UEFI mode")
>  >
>  > For case #1 we are planning on a new CRUD API to set/unset traits for 
> a node.
>  > Case #2 is more interesting. We have two options, I think:
>  >
>  > a) Operators still set traits on nodes, drivers are simply validating
> them. E.g.
>  > an operators sets CUSTOM_RAID_5, and the node's RAID interface checks 
> if
> it is
>  > possible to do. The downside is obvious - with a lot of deploy 
> templates
>  > available it can be a lot of manual 

[openstack-dev] [release][ptl] Releases repo frozen

[Sean McGinnis]

Just a heads up that the releases repo is frozen while we work through some
zuul v3 migration issues. Jobs are passing, but some of the important
post-release processing that needs to happen will require a little more
tinkering to get right.

Feel free to propose release patches, but just know that we will not be able to
process any of them until these issues are resolved.

Sorry for any inconvenience.

Sean (smcginnis)


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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Fox, Kevin M]

So, my $0.02.

A supported/recent version of a tool to install an unsupported version of a 
software is not a bad thing.

OpenStack has a bad reputation (somewhat deservedly) for being hard to upgrade. 
This has mostly gotten better over time but there are still a large number of 
older, unsupported deployments at this point.

Sometimes, burning down the cloud isn't an option and sometimes upgrading in 
place isn't an option either, and they are stuck on an unsupported version.

Being able to deploy with a more modern installer the same version of the cloud 
your running in production and shift the load to it (sideways upgrade), but 
then have an upgrade path provided by the tool would be a great thing.

Thanks,
Kevin

From: Michał Jastrzębski [inc...@gmail.com]
Sent: Monday, October 16, 2017 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] 
Proposing changes in stable policy for installers

So my 0.02$

Problem with handling Newton goes beyond deployment tools. Yes, it's
popular to use, but if our dependencies (openstack services
themselves) are unmaintained, so should we. If we say "we support
Newton" in deployment tools, we make kind of promise we can't keep. If
for example there is CVE in Nova that affects Newton, there is nothing
we can do about it and our "support" is meaningless.

Not having LTS kind of model was issue for OpenStack operators
forever, but that's not problem we can solve in deployment tools
(although we are often asked for that because our communities are
largely operators and we're arguably closest projects to operators).

I, for one, think we should keep current stable policy, not make
exception for deployment tools, and address this issue across the
board. What Emilien is describing is real issue that hurts operators.

On 16 October 2017 at 15:38, Emilien Macchi  wrote:
> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  wrote:
>> Emilien Macchi wrote:
>>> [...]
>>> ## Proposal
>>>
>>> Proposal 1: create a new policy that fits for projects like installers.
>>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>>> (open for feedback).
>>> Content can be read here:
>>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>>> please review).
>>>
>>> The idea is really to not touch the current stable policy and create a
>>> new one, more "relax" that suits well for projects like installers.
>>>
>>> Proposal 2: change the current policy and be more relax for projects
>>> like installers.
>>> I haven't worked on this proposal while it was something I was
>>> considering doing first, because I realized it could bring confusion
>>> in which projects actually follow the real stable policy and the ones
>>> who have exceptions.
>>> That's why I thought having a dedicated tag would help to separate them.
>>>
>>> Proposal 3: no change anywhere, projects like installer can't claim
>>> stability etiquette (not my best option in my opinion).
>>>
>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>>> this need), please get involved in the review process.
>>
>> My preference goes to proposal 1, however rather than call it "relaxed"
>> I would make it specific to deployment/lifecycle or cycle-trailing
>> projects.
>>
>> Ideally this policy could get adopted by any such project. The
>> discussion started on the review and it's going well, so let's see where
>> it goes :)
>
> Thierry, when I read your comment on Gerrit I understand you prefer to
> amend the existing policy and just make a note for installers (which
> is I think the option #2 that I proposed). Can you please confirm
> that?
> So far I see option #1 has large consensus here, I'll wait for
> Thierry's answer to continue to work on it.
>
> Thanks for the feedback so far!
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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

Re: [openstack-dev] [docs] Evidence of Success

[Petr Kovar]

Thanks for your feedback, everybody. I made some more edits to the
document and tried to address the remaining comments left in the etherpad.

I think the current revision of the doc provides enough details on
the metrics and goals, so it should be ready to be added to
https://docs.openstack.org/doc-contrib-guide/ as an official project doc.
Let us know if you have more comments. 

Cheers,
pk


On Mon, 09 Oct 2017 16:35:57 -0400
Doug Hellmann  wrote:

> This draft looks really good. I left a few comments on the etherpad.
> 
> Excerpts from Jimmy McArthur's message of 2017-10-05 10:33:48 -0500:
> > Sorry for the Google Docs link btw. That's where Petr and I were 
> > initially collaborating. I've moved this back to the etherpad referenced 
> > in ttps://etherpad.openstack.org/p/docs-i18n-ptg-queens 
> > 
> > 
> > https://etherpad.openstack.org/p/docs-i18n-ptg-queens-mission-statement
> > 
> > > Jimmy McArthur 
> > > October 4, 2017 at 1:18 PM
> > >
> > >
> > >> Emilien Macchi 
> > >> October 4, 2017 at 12:35 PM
> > >>
> > >> The draft is really good! It reflects very well what we said we would
> > >> do at the PTG, way to go.
> > >>
> > >> I think the next steps would be:
> > >> - Definition of Done, or how you consider something achieved (code
> > >> merged, doc published, etc).
> > >> - Metrics: what metrics do you use to measure what you're delivering.
> > > For the DoD and Metrics our understanding of the task was that they 
> > > should be built into the Evidence of Success, though I think we could 
> > > still use some more specific metrics in certain spots.  Emilien, would 
> > > you suggest we define these as separate line items as well?
> > >
> > > Thanks!
> > > Jimmy
> > >> - What do you expect by end of Queens (put some number in metrics is
> > >> probably a good start) - it's already mentioned in your draft vision
> > >> but it might be revisited once you define the 2 previous items.
> > >>
> > >> Good work!
> > >> Jimmy McArthur 
> > >> October 4, 2017 at 10:46 AM
> > >> I've made a bit of progress on the collaborative vision for the Docs 
> > >> team: 
> > >> https://docs.google.com/document/d/1Xy78CnmnKlQ7SbR1XewqgrUdGe7DqnKAGYw_9aj5Ndg/edit#
> > >>  
> > >>
> > >>
> > >> This still needs plenty of work, but I wanted to put out what we have 
> > >> so we can start to get some feedback from other members of the Docs 
> > >> team. The Use Cases section in particular was really vast and hard to 
> > >> cut down into prose without getting too detailed.
> > >>
> > >> Welcome your feedback and input!
> > >>
> > >> Thanks,
> > >> Jimmy
> > >>
> > >>
> > >>
> > >> __
> > >>  
> > >>
> > >> OpenStack Development Mailing 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 
> > > October 4, 2017 at 12:35 PM
> > >
> > > The draft is really good! It reflects very well what we said we would
> > > do at the PTG, way to go.
> > >
> > > I think the next steps would be:
> > > - Definition of Done, or how you consider something achieved (code
> > > merged, doc published, etc).
> > > - Metrics: what metrics do you use to measure what you're delivering.
> > > - What do you expect by end of Queens (put some number in metrics is
> > > probably a good start) - it's already mentioned in your draft vision
> > > but it might be revisited once you define the 2 previous items.
> > >
> > > Good work!
> > > Jimmy McArthur 
> > > October 4, 2017 at 10:46 AM
> > > I've made a bit of progress on the collaborative vision for the Docs 
> > > team: 
> > > https://docs.google.com/document/d/1Xy78CnmnKlQ7SbR1XewqgrUdGe7DqnKAGYw_9aj5Ndg/edit#
> > >  
> > >
> > >
> > > This still needs plenty of work, but I wanted to put out what we have 
> > > so we can start to get some feedback from other members of the Docs 
> > > team. The Use Cases section in particular was really vast and hard to 
> > > cut down into prose without getting too detailed.
> > >
> > > Welcome your feedback and input!
> > >
> > > Thanks,
> > > Jimmy
> > >
> > >
> > >
> > > __
> > >  
> > >
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: 
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > 

Re: [openstack-dev] [forum] Schedule Is Available

[Jimmy McArthur]

Amrith Kumar wrote:

Mike,

Thanks for sending this out. Long lines in descriptions of many events
are not being wrapped, take Rochelle's session "Refstack: OpenStack to
OPNFV, Vertical, Integrated, Interop"at 3:30pm on Wednesday.

Any chance the descriptions could be wrapped?
This is now resolved for all presentations within question. If I missed 
one, please flag it here or send a note to speakersupp...@openstack.org, 
and we'll get it taken care of very quickly.


Thanks!
Jimmy


-amrith



On Mon, Oct 16, 2017 at 7:43 PM, Mike Perez  wrote:

>  Hey all,
>
>  Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
the
>  schedule posted on the Summit site filtering by forum related sessions:
>
>  
https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63
>
>  Please reply to give corrections.
>
>  I will be sending emails to listed moderators to verify there will be someone
>  physically present at the Forum to moderate the session. Thank you!
>
>  --
>  Mike Perez
>
>  __
>  OpenStack Development Mailing 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] containerized undercloud in Queens

[Dan Prince]

On Tue, 2017-10-17 at 11:46 +, milanisko k wrote:
> 
> How about the shared container? Wouldn't it be better not have to
> rely on t-h-t especially if we're "scheduling" (and probably
> configuring) the services as a single logical entity? 

The containers architecture for Pike and Queens is very much oriented
around preserving the way we deployed the services already on
baremetal... but moving them into containers. So for Ironic inspector
we had 2 services (2 systemd scripts) both living in separate
containers. Do the the shared nature of this architecture with regards
to network and host access this works fine.

In the future as we move towards Kubernetes rearchitecting the services
so they work better in containers is totally fine. If the services are
that tightly coupled then why not just have one launch the other? Then
they could live in the single container and have a common launch point.
Seems fine to me, but certainly isn't a requirement to get these up and
running in the current architecture.


> Also would allow us to get rid of iptables and better encapsulate the
> inspector services.

__
OpenStack Development Mailing 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] [masakari]oslo.context 2.19.1 is currently blocked

[Ben Nemec]

Can you add masakari to 
https://bugs.launchpad.net/oslo.context/+bug/1721432 so we don't miss it 
in the process of fixing this problem?  At some point we will be 
releasing a new oslo.context and we need to make sure we get all the 
broken projects fixed before then.


Thanks.

-Ben

On 10/17/2017 04:18 AM, Rikimaru Honjo wrote:

Hello Masakari contributors,

I submitted a patch which fixes masakari UT codes according to 
oslo.context 2.19.1.[1]
Because oslo.context 2.19.1 adds 'project' key in context's to_dict 
function.[2]


But, I realized that the latest global-requirement blocks oslo.context 
2.19.1.[3]

So I abandoned my patch because it is unnecessary.
I think that we can merge "Updated from global requirements" patch now.

[1]
Fix UT codes according to updating oslo.context
https://review.openstack.org/#/c/510760/
[2]
Output 'project' key in context's to_dict function
https://review.openstack.org/#/c/507444/
[3]
Block oslo.context 2.19.1
https://review.openstack.org/#/c/510857/


__
OpenStack Development Mailing 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] [kolla-kubernetes] example of containerize neutron ML2 drivers

[Bin Zhou]

Hi,

At PTG, there were discussion around prototyping per-vendor neutron
drivers (for example ML2 drivers) within containerized neutron
service.
Is there any design decision made? If so, please kindly share it as a
guideline for implementing vender-specific neutron drivers.Thanks a
lot!

Regards,
Bin

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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Jean-Philippe Evrard]

To be as cool as nova, we'll find nicknames until then.
We can probably start with Kevin "Destroy of Clouds" Carter.

On 17 October 2017 at 15:28, Jean-Philippe Evrard
 wrote:
> Hello,
>
> I'd be happy to have a room for OpenStack-Ansible.
>
> I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and
> Amy Marrich(spotz).
>
> Thanks!
>
> On 17 October 2017 at 03:39, Jeffrey Zhang  wrote:
>> I am the speaker. Michal couldn't be Sydney this summit.
>>
>> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson 
>> wrote:
>>>
>>> Added Kolla to my list. Would the speakers be you and Michal?
>>>
>>> -Kendall (diablo_rojo)
>>>
>>>
>>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
>>> wrote:

 Hi Kendall,

 Kolla project would like to have a on-boarding session too.

 thanks.

 On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
 wrote:
>
> Added Nova to my list with Dan, Melanie, and Ed as speakers.
>
> Thanks Matt,
> -Kendall (diablo_rojo)
>
> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
> wrote:
>>
>> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
>> > Wanted to keep this thread towards the top of inboxes for those I
>> > haven't heard from yet.
>> >
>> > About a 1/4 of the way booked, so there are still slots available!
>> >
>> > -Kendall (diablo_rojo)
>>
>> I've tricked the following people into running a Nova on-boarding room:
>>
>> - "Super" Dan Smith 
>> - Melanie "Structured Settlement" Witt 
>> - Ed "Alternate Hosts" Leafe 
>>
>> --
>>
>> 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 Development Mailing 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
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>

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

Re: [openstack-dev] [ptls] Sydney Forum Project Onboarding Rooms

[Miguel Lavalle]

Neutron - Miguel Lavalle - mig...@mlavalle.com

On Mon, Oct 16, 2017 at 9:39 PM, Jeffrey Zhang 
wrote:

> I am the speaker. Michal couldn't be Sydney this summit.
>
> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson 
> wrote:
>
>> Added Kolla to my list. Would the speakers be you and Michal?
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
>> wrote:
>>
>>> Hi Kendall,
>>>
>>> Kolla project would like to have a on-boarding session too.
>>>
>>> thanks.
>>>
>>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
>>> wrote:
>>>
 Added Nova to my list with Dan, Melanie, and Ed as speakers.

 Thanks Matt,
 -Kendall (diablo_rojo)

 On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
 wrote:

> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
> > Wanted to keep this thread towards the top of inboxes for those I
> > haven't heard from yet.
> >
> > About a 1/4 of the way booked, so there are still slots available!
> >
> > -Kendall (diablo_rojo)
>
> I've tricked the following people into running a Nova on-boarding room:
>
> - "Super" Dan Smith 
> - Melanie "Structured Settlement" Witt 
> - Ed "Alternate Hosts" Leafe 
>
> --
>
> Thanks,
>
> Matt
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.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.op
 enstack.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.op
>>> enstack.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: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: 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] [ptls] Sydney Forum Project Onboarding Rooms

[Jean-Philippe Evrard]

Hello,

I'd be happy to have a room for OpenStack-Ansible.

I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and
Amy Marrich(spotz).

Thanks!

On 17 October 2017 at 03:39, Jeffrey Zhang  wrote:
> I am the speaker. Michal couldn't be Sydney this summit.
>
> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson 
> wrote:
>>
>> Added Kolla to my list. Would the speakers be you and Michal?
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
>> wrote:
>>>
>>> Hi Kendall,
>>>
>>> Kolla project would like to have a on-boarding session too.
>>>
>>> thanks.
>>>
>>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
>>> wrote:

 Added Nova to my list with Dan, Melanie, and Ed as speakers.

 Thanks Matt,
 -Kendall (diablo_rojo)

 On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
 wrote:
>
> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
> > Wanted to keep this thread towards the top of inboxes for those I
> > haven't heard from yet.
> >
> > About a 1/4 of the way booked, so there are still slots available!
> >
> > -Kendall (diablo_rojo)
>
> I've tricked the following people into running a Nova on-boarding room:
>
> - "Super" Dan Smith 
> - Melanie "Structured Settlement" Witt 
> - Ed "Alternate Hosts" Leafe 
>
> --
>
> 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 Development Mailing 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
>>
>>
>> __
>> OpenStack Development Mailing 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
>

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

Re: [openstack-dev] [stable][mistral] Asking for stable branch policy exception

[Dougal Matthews]

On 17 October 2017 at 09:19, Renat Akhmerov 
wrote:

> Hi,
>
> We have two patches in Mistral that we need to back port to stable/pike.
> However, they are against of stable branch management policy because they
> slightly change the DB schema. The patches are the following:
>
>1. https://review.openstack.org/#/c/512528/
>2. https://review.openstack.org/#/c/512256/
>
>
> #2 is a critically important fix that fixes a problem of decreasing
> Mistral performance when DB becomes heavy (has lots of execution objects).
> This is a blocker issue for us (Nokia) preventing us using Mistral in
> production. It also seriously optimizes performance in general.
>
> So hereby I'm asking your advice on what we can do in this situation. Can
> we merge these patches if we make sure that we don't break anyone in the
> community? For example, TripleO.
>

As far as I am aware, this wont be a problem for TripleO. These patches are
both additive (new db column and new db index).

The first patch (512528) is only a candidate for backport to avoid breaking
the migration history order, it isn't otherwise needed in Pike. How is this
normally handled in other projects? i.e. we need to backport migration 24
to Pike, but 23 is in master only. I assume this problem has came up before
and been solved, but I can't find any examples.



>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing 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] IBM z/VM CI asks for reporting permission to Nova changes

[Andreas Scheuring]

Hi Laurene, 

at the moment the z/VM CI is posting a +1 even though the job failed. That’s 
because in zuul layout.yaml the job is probably set to "voting: false.” You can 
easily fix this by setting it to “true”.

For example see https://review.openstack.org/#/c/512190/

Regards, 

---
Andreas Scheuring (andreas_s)



> On 12. Oct 2017, at 06:42, Xiao Mei GZ Zheng  wrote:
> 
> Hello,
> 
> I'm requesting reporting permission (non-voting) to Nova changes for the IBM 
> z/VM CI. The wiki is on link [1].
> 
> We designed the CI using nodepool , zuul and Jenkins. The newly uploaded 
> patches will receive an initial +/-1 reports from Jenkins only for the nova 
> project (just comments on patches but not vote on them). Tests completed on 
> the z/VM Driver CI system check-nova pipeline. For more information see[2]. 
> To recheck it, you just submit a comment with only zvm:recheck in the 
> comment. 
> 
> The IBM z/VM CI system has been running for a long time in a stable fashion. 
> We present all test artifacts on a public link [3] to make debugging failed 
> tests easier. You can see environment details, openstack logs and tempest 
> logs.
> 
> * Gerrit Account: zvmosci
> 
> * Gerrit query on patches where the CI commented: [4]
> 
> * Proposal for naming: IBM z/VM CI
> 
> For any questions feel free to reach out to me (Laurene) or to Leon!
> 
> [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_z/VM_CI 
> 
> 
> [2] https://wiki.openstack.org/wiki/ZVMDriver/zVM-CI 
> 
> 
> 
> [3] http://extbasicopstackcilog01.podc.sl.edst.ibm.com/ci_status/ 
> 
> 
> 
> [4] https://review.openstack.org/#/c/410596/ 
> 
> 
> Thanks & Best Regards!
> 
> Laurene(Xiao Mei) Zheng 
> 
> Software developer, CSTL
> IBM China Systems & Technology Lab (CSTL)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[milanisko k]

út 17. 10. 2017 v 13:06 odesílatel Dan Prince  napsal:

> On Tue, 2017-10-17 at 10:06 +, milanisko k wrote:
> >
> > Does it mean dnsmasq was run from a stand-alone container?
>
> Yes. There are separate containers for the ironic-inspector and
> dnsmasq.
>
> >
> > Could you please point me (in the patch probably) to the spot where
> > we configure inspector container to be able to talk to the iptables
> > to filter the DHCP traffic for dnsmasq?
>
> Both services (ironic-inspector and dnsmasq) are using --net=host and
> --privileged. This essentially has them on the same shared host network
> thus the services can interact with the same iptables rules.
>
> >
> > I guess this configuration binds the dnsmasq container to be
> > "scheduled" together with inspector container on the same node
> > (because of the iptables).
>
> Both services are controlled via the same Heat template and as such
> even though they are in separate containers we can guarantee they
> should always get launched on the same machine.
>

How about the shared container? Wouldn't it be better not have to rely on
t-h-t especially if we're "scheduling" (and probably configuring) the
services as a single logical entity? Also would allow us to get rid of
iptables and better encapsulate the inspector services.

--
milan


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

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

[Dan Prince]

On Tue, 2017-10-17 at 10:06 +, milanisko k wrote:
> 
> Does it mean dnsmasq was run from a stand-alone container?

Yes. There are separate containers for the ironic-inspector and
dnsmasq.

> 
> Could you please point me (in the patch probably) to the spot where
> we configure inspector container to be able to talk to the iptables
> to filter the DHCP traffic for dnsmasq?

Both services (ironic-inspector and dnsmasq) are using --net=host and
--privileged. This essentially has them on the same shared host network
thus the services can interact with the same iptables rules.

> 
> I guess this configuration binds the dnsmasq container to be
> "scheduled" together with inspector container on the same node
> (because of the iptables).

Both services are controlled via the same Heat template and as such
even though they are in separate containers we can guarantee they
should always get launched on the same machine.

Dan

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

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

Hi Julia
Yes, you are right on your assumptions here. The missing feature here, is
the ability of Ironic to provide a mechanism to append standard kernel
arguments, when not netbooting. Having a way to append default parameters
to bootloader would be very useful and avoid the need of manual hacks, and
shouldn't be difficult to implement because Ironic is already interacting
with the bootloader.
How could we progress on that? Is some spec needed to provide this feature?

On Mon, Oct 16, 2017 at 9:29 PM, Julia Kreger 
wrote:

> Greetings Yolanda!
>
> I guess I'm slightly not clear. In fact, I may be slightly even more
> confused since we've discussed this directly. Thinking out loud, there are
> two different scenarios of booting from iSCSI.
>
> 1) Human created/assigned/associated LUN off of a SAN which we want a node
> to boot from, and that LUN lives onward as the "storage" for the node.
>
> 2) Cinder facilitated LUN off of $something that we want a node to boot
> from. This largely would be the logic we added this past cycle to support
> either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
> the HBA to boot/attach from specific volumes.
>
> I think your largely bringing up the first case when we speak of booting
> from iSCSI. If not, then we technically haven't reached the point where we
> are explicitly supporting hardware HBA use, but no time like the present!
>
> Since there are many things here, I think we need to make sure we are
> contextually on the same page. If any of this is wrong, please correct me:
>
> * You deploying a partition/filesystem image.
> * Ironic is partitioning and executing the installation of grub.
> * The scenario where your operating requires the boot loader command line
> to be updated with specific arguments.
> * Part of the problem is the ramdisk initialization where it is only
> honors arguments in your specific case.
> * Ironic does not presently provide a mechanism to append standard kernel
> arguments outside of netboot. Example from ages ago that many may remember,
> having to add ``noapic`` in some cases with a SMP kernel is to be used.
>
> I believe it makes sense to have some sort of mechanism to append to the
> default list in this case. There is the ansible deploy driver, but it seems
> like that might be overkill for setting boot loader parameters, and Ironic
> is explicitly executing grub-isntall.
>
> I think the only reason we've resisted in supporting updating the defaults
> file the past is because it would mean explicitly writing data to the grub
> defaults file on the filesystem, I suspect our comfort level with
> supporting that now may be different. In hindsight, considering we
> essentially already support this with netboot but not local boot with a
> partition image, I think we should add support for appending default
> parameters.
>
> Thoughts?
>
> -Julia
>
>
> On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota 
> wrote:
>
>> Hi
>> Recently i've been helping some customers in the boot from ISCSI feature.
>> So far everything was working, but we had a problem when booting the
>> deployment image.
>> It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
>> grub commands. But as the generated deployment image doesn't contain these
>> flags, ISCSI was not booting properly. For other hardware setups, different
>> flags may be needed.
>> The solution was to manually execute a virt-customize on the deployment
>> image to hardcode these parameters.
>> I wonder if we can add some feature in Ironic to support it. We have
>> discussed about kernel parameters several times. But at this time, it
>> affects ISCSI booting. Not having a way in Ironic to customize these
>> parameters forces to manual workarounds.
>> So can we reconsider the proposal to add kernel parameters there? It
>> could be a settable argument (driver_info/kernel_args), and then the IPA
>> could set the parameters properly on the image. Or any other option is
>> welcome.
>> What are your thoughts there?
>>
>> Thanks
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> 
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.comM: +34605641639
>> 
>> 
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Yolanda Robla 

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

[milanisko k]

Hi Dan!

thanks for the testing! I've got couple of questions...


po 16. 10. 2017 v 20:04 odesílatel Dan Prince  napsal:

> On Wed, 2017-10-04 at 15:10 +0200, Dmitry Tantsur wrote:
> > (top-posting, as it is not a direct response to a specific line)
> >
> > This is your friendly reminder that we're not quite near
> > containerized
> > ironic-inspector. The THT for it has probably never been tested at
> > all, and the
> > iptables magic we do may simply not be containers-compatible. Milan
> > would
> > appreciate any help with his ironic-inspector rework.
>
>
> I spent the time today to test our (very old) ironic-inspector patch
> from Pike.
>
> https://review.openstack.org/#/c/457822/
>
> Aside from one tweak I made to run dnsmasq as root (this is how systemd
> runs this process as well) the service seems to be working perfectly.
> Demo recording of what I did below:
>
> https://asciinema.org/a/wGtvZwE65yoasKrRS8NeGMsrH
>
>
Does it mean dnsmasq was run from a stand-alone container?

Could you please point me (in the patch probably) to the spot where we
configure inspector container to be able to talk to the iptables to filter
the DHCP traffic for dnsmasq?

I guess this configuration binds the dnsmasq container to be "scheduled"
together with inspector container on the same node (because of the
iptables).



> Also, just want to re-interate that the t-h-t architecture is also
> capable as a baremetal installation tool. While I would like to see
> inspector containerized if we really need to run it on baremetal this
> architecture would support that fine. It is the same architecture we
> use for the overcloud and as such it supports mixing and matching
> containers alongside baremetal services.


Nice!


>
> If that doesn't make sense let me just say that whatever you plan on
> doing in Queens to Ironic if you plan on supporting that w/ Puppet on
> instack-undercloud I have no doubts about being able to support it in
> the architecture I'm proposing we adopt here... whether we run the
> service on baremetal or in a container.
>

What I'd vote for would be to pack both inspector and its dnsmasq sidekick
into a single container instead, and adopt the dnsmasq filter[1] instead of
the iptables filter. This will make the inspector a self-contained
service/container one could "schedule" where ever they needed.

Cheers,
milan

[1]
https://review.openstack.org/#/q/topic:rebasing_filter+(status:open+OR+status:merged)



>
> Dan
>
> >
> > Dmitry
> >
> > On 10/04/2017 03:00 PM, Dan Prince wrote:
> > > On Tue, 2017-10-03 at 16:03 -0600, Alex Schultz wrote:
> > > > On Tue, Oct 3, 2017 at 2:46 PM, Dan Prince 
> > > > wrote:
> > > > >
> > > > >
> > > > > On Tue, Oct 3, 2017 at 3:50 PM, Alex Schultz  > > > > om>
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Oct 3, 2017 at 11:12 AM, Dan Prince  > > > > > om>
> > > > > > wrote:
> > > > > > > On Mon, 2017-10-02 at 15:20 -0600, Alex Schultz wrote:
> > > > > > > > Hey Dan,
> > > > > > > >
> > > > > > > > Thanks for sending out a note about this. I have a few
> > > > > > > > questions
> > > > > > > > inline.
> > > > > > > >
> > > > > > > > On Mon, Oct 2, 2017 at 6:02 AM, Dan Prince  > > > > > > > t.co
> > > > > > > > m>
> > > > > > > > wrote:
> > > > > > > > > One of the things the TripleO containers team is
> > > > > > > > > planning
> > > > > > > > > on
> > > > > > > > > tackling
> > > > > > > > > in Queens is fully containerizing the undercloud. At
> > > > > > > > > the
> > > > > > > > > PTG we
> > > > > > > > > created
> > > > > > > > > an etherpad [1] that contains a list of features that
> > > > > > > > > need
> > > > > > > > > to be
> > > > > > > > > implemented to fully replace instack-undercloud.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I know we talked about this at the PTG and I was
> > > > > > > > skeptical
> > > > > > > > that this
> > > > > > > > will land in Queens. With the exception of the
> > > > > > > > Container's
> > > > > > > > team
> > > > > > > > wanting this, I'm not sure there is an actual end user
> > > > > > > > who is
> > > > > > > > looking
> > > > > > > > for the feature so I want to make sure we're not just
> > > > > > > > doing
> > > > > > > > more work
> > > > > > > > because we as developers think it's a good idea.
> > > > > > >
> > > > > > > I've heard from several operators that they were actually
> > > > > > > surprised we
> > > > > > > implemented containers in the Overcloud first. Validating a
> > > > > > > new
> > > > > > > deployment framework on a single node Undercloud (for
> > > > > > > operators) before
> > > > > > > overtaking their entire cloud deployment has a lot of merit
> > > > > > > to
> > > > > > > it IMO.
> > > > > > > When you share the same deployment architecture across the
> > > > > > > overcloud/undercloud it puts us in a better position to
> > > > > > > decide
> > > > > > > where to
> > > > > > > expose new 

[openstack-dev] [neutron][classifier] CCF Meeting

[Shaughnessy, David]

Hi everyone.
Reminder that the Common Classification Framework meeting is at 14:00 UTC.
The Agenda can be found here: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#All_Meetings.27_Agendas
Regards.
David.

__
OpenStack Development Mailing 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] [masakari]oslo.context 2.19.1 is currently blocked

[Rikimaru Honjo]

Hello Masakari contributors,

I submitted a patch which fixes masakari UT codes according to oslo.context 
2.19.1.[1]
Because oslo.context 2.19.1 adds 'project' key in context's to_dict function.[2]

But, I realized that the latest global-requirement blocks oslo.context 
2.19.1.[3]
So I abandoned my patch because it is unnecessary.
I think that we can merge "Updated from global requirements" patch now.

[1]
Fix UT codes according to updating oslo.context
https://review.openstack.org/#/c/510760/
[2]
Output 'project' key in context's to_dict function
https://review.openstack.org/#/c/507444/
[3]
Block oslo.context 2.19.1
https://review.openstack.org/#/c/510857/
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp


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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Bogdan Dobrelya]

On 10/17/17 12:50 AM, Michał Jastrzębski wrote:
> So my 0.02$
> 
> Problem with handling Newton goes beyond deployment tools. Yes, it's
> popular to use, but if our dependencies (openstack services
> themselves) are unmaintained, so should we. If we say "we support
> Newton" in deployment tools, we make kind of promise we can't keep. If
> for example there is CVE in Nova that affects Newton, there is nothing
> we can do about it and our "support" is meaningless.
> 
> Not having LTS kind of model was issue for OpenStack operators
> forever, but that's not problem we can solve in deployment tools
> (although we are often asked for that because our communities are
> largely operators and we're arguably closest projects to operators).
> 
> I, for one, think we should keep current stable policy, not make
> exception for deployment tools, and address this issue across the
> board. What Emilien is describing is real issue that hurts operators.

I agree we should keep current stable policy and never backport
features. It adds too much of the maintenance overhead, high risks of
breaking changes and requires a lots of additional testing. So then
deployment tools, if want features backported, should not be holding
that stable policy tag.

> 
> On 16 October 2017 at 15:38, Emilien Macchi  wrote:
>> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  
>> wrote:
>>> Emilien Macchi wrote:
 [...]
 ## Proposal

 Proposal 1: create a new policy that fits for projects like installers.
 I kicked-off something here: https://review.openstack.org/#/c/511968/
 (open for feedback).
 Content can be read here:
 http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
 Tag created here: https://review.openstack.org/#/c/511969/ (same,
 please review).

 The idea is really to not touch the current stable policy and create a
 new one, more "relax" that suits well for projects like installers.

 Proposal 2: change the current policy and be more relax for projects
 like installers.
 I haven't worked on this proposal while it was something I was
 considering doing first, because I realized it could bring confusion
 in which projects actually follow the real stable policy and the ones
 who have exceptions.
 That's why I thought having a dedicated tag would help to separate them.

 Proposal 3: no change anywhere, projects like installer can't claim
 stability etiquette (not my best option in my opinion).

 Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
 TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
 this need), please get involved in the review process.
>>>
>>> My preference goes to proposal 1, however rather than call it "relaxed"
>>> I would make it specific to deployment/lifecycle or cycle-trailing
>>> projects.
>>>
>>> Ideally this policy could get adopted by any such project. The
>>> discussion started on the review and it's going well, so let's see where
>>> it goes :)
>>
>> Thierry, when I read your comment on Gerrit I understand you prefer to
>> amend the existing policy and just make a note for installers (which
>> is I think the option #2 that I proposed). Can you please confirm
>> that?
>> So far I see option #1 has large consensus here, I'll wait for
>> Thierry's answer to continue to work on it.
>>
>> Thanks for the feedback so far!
>> --
>> Emilien Macchi
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

[openstack-dev] [stable][mistral] Asking for stable branch policy exception

[Renat Akhmerov]

Hi,

We have two patches in Mistral that we need to back port to stable/pike. 
However, they are against of stable branch management policy because they 
slightly change the DB schema. The patches are the following:

1. https://review.openstack.org/#/c/512528/
2. https://review.openstack.org/#/c/512256/


#2 is a critically important fix that fixes a problem of decreasing Mistral 
performance when DB becomes heavy (has lots of execution objects). This is a 
blocker issue for us (Nokia) preventing us using Mistral in production. It also 
seriously optimizes performance in general.

So hereby I'm asking your advice on what we can do in this situation. Can we 
merge these patches if we make sure that we don't break anyone in the 
community? For example, TripleO.

Thanks

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Thierry Carrez]

Emilien Macchi wrote:
> 
> Thierry, when I read your comment on Gerrit I understand you prefer to
> amend the existing policy and just make a note for installers (which
> is I think the option #2 that I proposed). Can you please confirm
> that?
> So far I see option #1 has large consensus here, I'll wait for
> Thierry's answer to continue to work on it.

Sorry I wasn't clear.

I started working on tag modifications (to add ACL requirements and make
it more clearly main-service-specific) when I realized it was just
merely pointing to stable policy. Reading your proposed change it
appeared as two variants on the same document... So I figured we could
spare the creation of an additional tag.

I'm fine with either approach really (solution 1 or solution 2). The
important part is to define the variant/other policy in a way that would
work for most deployment teams while benefiting the users interested in
stability (i.e. a good trade-off between getting desirable fixes and
being exposed to unnecessary risk).

-- 
Thierry Carrez (ttx)

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

[openstack-dev] Project Meteos - Machine Learning as a Service in OpenStack

[Digambar Patil]

Hello Everyone,

Meteos is a Machine Learning as a Service in OpenStack.

Meteos allows users to analyze huge amount of data and predict a value by
data mining and machine learning algorithms.

Meteos create a workspace of Machine Learning via sahara spark plugin and
manage some resources and jobs regarding Machine Learning.

We are using OpenStack components like Nova, Sahara(Hadoop/Spark), Swift
etc. We are heavily relying on OpenStack Component because We understand
whatever we build, it should be openstack centric and give other project a
freedom to use the service easily for any other components.

Problem Statement -
1. Currently there are many ML libraries available and if user wants to
develop some applications they have to go to
installation/configuration/integration of component which they have to
manage manually.
2. To use one small API of one library, developer has to install complete
library. 3. 3. Processing primary data on cluster, required another
installation steps and managing analytics clusters is again a pain.
4.Storing and scaling data is an another major problem in data science
today.
5. There are public cloud providers offering ML service but those are very
costly.

*Purpose -*

Meteos Project aims to provide Machine learning APIs to develop ML
algorithms and ML use cases with stack provided by Meteos setup.

This project gives one setup which includes Apache Spark
ML/Tensorflow/Scikit integration Hadoop/Spark and swift and it enables a
platform for developers to use ML APIs to develop ML use cases directly
without taking headache of installation and component integration.

*Planned features for Queens release - *


   - Tensorflow integration - To bring ML and deep learning capabilities in
   OpenStack.
   - SciKit Learn library integration
   - Developing ML use cases using Meteos.
   - Data/batch processing on Hadoop/Spark using OpenStack Sahara project -
   No need to put special effort for setting up analytics stack.
   - Data is stored and scaled automatically on swift.

*Goal - *

   - Users should be able to implement data science problems.
   - Data visualization on Portal.
   - Developer should be able to develop Machine Learning application
   quickly and easily.
   - Data storage, Data processing and Data Storage should be achieved
   effortlessly and effectively.

If you are interested to work/contribute in this Project, please reach out
to me/hiroyuki on #openstack-meteos or reply back to this mail. My irc
nickname is diga.

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

Re: [openstack-dev] The CI issue: “cp: cannot create regular file '/opt/stack/new/bin/etcd': Text file busy

[Chris Smart]

On Tue, 17 Oct 2017, at 14:15, linziw...@itri.org.tw wrote:
> and in the /%24LOG_PATH/logs/devstack-early.txt file,
> it shows
> 2017-10-17 02:49:21.324 | + lib/etcd3:install_etcd3:109:  sudo cp
> /opt/stack/new/devstack/files/etcd-v3.1.10-linux-amd64/etcd
> /opt/stack/new/bin/etcd
> 2017-10-17 02:49:21.330 | cp: cannot create regular file
> '/opt/stack/new/bin/etcd': Text file busy
> 
> Can anyone help me to resolve this issue?
> Why the file is busy???
> 

The file is busy because the etcd binary at /opt/stack/new/bin/etcd is
currently being executed and therefore it cannot be replaced, as it has
an open handler on that file.

You can replicate this locally with a different binary, like this (using
the watch command):

$ cp /usr/bin/watch .
$ ./watch ls &
$ cp /usr/bin/watch .
cp: overwrite './watch'? y
cp: cannot create regular file './watch': Text file busy


Not that this is the right solution, but you can move it and then put
the new file in its place (the etcd will continue to run).

For example:

$ cp /usr/bin/watch .
$ ./watch ls &
$ mv watch watch-old
$ cp /usr/bin/watch .
$ ls watch*
watch  watch-old


So, why is /opt/stack/new/bin/etcd already running on that host?...

-c

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