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

[Openstack] Call for collaboration: "Supporting General Federation for Large-Scale Collaborations" & "3rd Open Research Cloud Congress"

[Martial Michel]

Topics: Federation, Identity, Security, Networking, Data Management


Good Day,

I wanted to bring to our community working on Federation, Identity,
Security, Networking, or Data Management, a couple of collaborations
happening during the November Summit.

"Supporting General Federation for Large-Scale Collaborations", discusses
general federations across multiple administrative domains and would
facilitate a wide variety of collaborations, including areas as diverse as
international "big science" efforts, international disaster response, and
supply chain management, just to name a few.

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20475/
supporting-general-federation-for-large-scale-collaborations?

These types of federated clouds, or inter-clouds, are being pursued by the
NIST/IEEE Joint WG on Federated Cloud:
http://standards.ieee.org/news/2017/intercloud_interoperability_and_
federation.html
http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/
FederatedCloudPWGFC
https://standards.ieee.org/develop/project/2302.html

and the Open Research Cloud organization:
http://www.openresearchcloud.org

The ORC's goal is to support international science collaborations.  The
NIST goal is to "define" federation, build a conceptual model, map-out
federation deployment models, and identify needed areas of
federation-specific standardization.  The IEEE goal is to push these
federation standards through the standardization process.

The "3rd Open Research CloudCongress" is set to take place Nov 8 and Nov 9
as part of the Summit. We are looking forward to the Sydney Congress and
making further progress on the development of the ORC and the ORC
Declaration. Our thanks to NeCTAR and the OpenStack Foundation for
sponsoring and hosting this meeting in Sydney.

Sincerely,

-- Martial Michel
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] Call for collaboration: "Supporting General Federation for Large-Scale Collaborations" & "3rd Open Research Cloud Congress"

[Martial Michel]

Topics: Federation, Identity, Security, Networking, Data Management


Good Day,

I wanted to bring to our community working on Federation, Identity,
Security, Networking, or Data Management, a couple of collaborations
happening during the November Summit.

"Supporting General Federation for Large-Scale Collaborations", discusses
general federations across multiple administrative domains and would
facilitate a wide variety of collaborations, including areas as diverse as
international "big science" efforts, international disaster response, and
supply chain management, just to name a few.

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20475/
supporting-general-federation-for-large-scale-collaborations?

These types of federated clouds, or inter-clouds, are being pursued by the
NIST/IEEE Joint WG on Federated Cloud:
http://standards.ieee.org/news/2017/intercloud_interoperability_and_
federation.html
http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/
FederatedCloudPWGFC
https://standards.ieee.org/develop/project/2302.html

and the Open Research Cloud organization:
http://www.openresearchcloud.org

The ORC's goal is to support international science collaborations.  The
NIST goal is to "define" federation, build a conceptual model, map-out
federation deployment models, and identify needed areas of
federation-specific standardization.  The IEEE goal is to push these
federation standards through the standardization process.

The "3rd Open Research CloudCongress" is set to take place Nov 8 and Nov 9
as part of the Summit. We are looking forward to the Sydney Congress and
making further progress on the development of the ORC and the ORC
Declaration. Our thanks to NeCTAR and the OpenStack Foundation for
sponsoring and hosting this meeting in Sydney.

Sincerely,

-- Martial Michel
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack] 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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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-operators] 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[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

[Openstack-operators] https://www.openstack.org/marketplace/ web changes

[Arkady.Kanevsky]

Danny and team,
What is the process of updating the web page template for detailed "distro" 
information to align with updated project-navigator.
For example, to add AODH, PANKO, Tempest, Rally as projects for distro solution 
offering?
Just looking for a process of requesting/making changes to the web template.
Then we can talk about any additional info that refstack collects for it.

In order to be listed in marketplace you must submit tempest results so it is 
for sure part of the distro/appliance.

Thanks,
Arkady Kanevsky, Ph.D.
Director of SW Development
Dell EMC CPSD
Dell Inc. One Dell Way, MS PS2-91
Round Rock, TX 78682, USA
Phone: 512 723 5264

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-operators] [scientific] Sydney lightning talks session

[Blair Bethwaite]

Hi all,

Once again the Scientific SIG (nee WG) has a dedicated lightning talk
session happening at the Sydney Summit. If have any interesting
OpenStack + Science and/or HPC stories then please through you hat in
the ring at:
https://etherpad.openstack.org/p/sydney-scientific-sig-lightning-talks

-- 
Cheers,
~Blairo

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Regarding devstack service restart

[Gary Kotton]

Please see https://docs.openstack.org/devstack/latest/systemd.html

From: Suraj Davanagere Basavaraj 
Date: Tuesday, October 17, 2017 at 12:24 PM
To: "openstack@lists.openstack.org" 
Subject: [Openstack] Regarding devstack service restart

Hello,

We read in Openstack discussion about service restart in devstack. We got to 
know that services are running in terms of screens. We tried to use the command 
"screen -r" and got the following error,

stack@ubuntu:/home/ubuntu/devstack$ screen -r
Cannot open your terminal '/dev/pts/28' - please check.

Could you please let us know how to view screens to restart devstack service.
Thank you.



Regards
Suraj
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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

Re: [OpenStack-Infra] Nominating new project-config and zuul job cores

[James E. Blair]

Clark Boylan  writes:

> Hello everyone,
>
> I'd like to nominate a few people to be core on our job related config
> repos. Dmsimard, mnaser, and jlk have been doing some great reviews
> particularly around the Zuul v3 transition. In recognition of this work
> I propose that we give them even more responsibility and make them all
> cores on project-config, openstack-zuul-jobs, and zuul-jobs.

Yes, that sounds great!  They've been a big help and totally grok stuff.

Thanks to all!

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nominating new project-config and zuul job cores

[Ian Wienand]

On 10/14/2017 03:25 AM, Clark Boylan wrote:

I'd like to nominate a few people to be core on our job related config
repos. Dmsimard, mnaser, and jlk have been doing some great reviews
particularly around the Zuul v3 transition. In recognition of this work
I propose that we give them even more responsibility and make them all
cores on project-config, openstack-zuul-jobs, and zuul-jobs.

Please chime in with your feedback.


++ nice to see a lively project!

-i

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[Openstack] Regarding devstack service restart

[Suraj Davanagere Basavaraj]

Hello,

We read in Openstack discussion about service restart in devstack. We got
to know that services are running in terms of screens. We tried to use the
command "screen -r" and got the following error,

stack@ubuntu:/home/ubuntu/devstack$ screen -r
Cannot open your terminal '/dev/pts/28' - please check.

Could you please let us know how to view screens to restart devstack
service.
Thank you.



Regards
Suraj
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Request for Mitaka version git repository

[Suraj Davanagere Basavaraj]

Hello John,

Thank you very much. It worked for us.

On Oct 16, 2017 4:47 PM, "John Dickinson"  wrote:

> The "mitaka-eol" tag is available if you must use it. For completeness, I
> must say please use later versions because they are better. The current
> version of Swift (2.15.1) is 100% compatible with the Mitaka release
> (2.7.1); ie clients that work with 2.7.1 will work with any later version,
> and you can upgrade to the latest from 2.7.1 with no user downtime.
>
> (Version numbers pulled from https://wiki.openstack.org/
> wiki/Swift/version_map)
>
> --John
>
>
>
>
> On 16 Oct 2017, at 16:33, Suraj Davanagere Basavaraj wrote:
>
> > Hello,
> >
> > I am Suraj, graduate student in Computer Engineering at San Jose State
> > University.
> >
> > We had developed an encryption application using Swift-All-In-One
> > architecture using stable/mitaka version during Spring 2017 as part of
> our
> > Non-thesis project phase 1.
> >
> > We are required to utilize the mitaka version to continue our project and
> > application cannot be built on other versions of Openstack(like Newton,
> > Ocata). We are unable to locate stable/mitaka branch in the upstream.
> >
> > Can you please let us know if there is an archived version of Openstack
> > stable mitaka available.
> >
> > Thank you.
> >
> >
> >
> > Regards
> > Suraj
> > ___
> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> > Post to : openstack@lists.openstack.org
> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[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] [Mirantis][Fuel-9.0] UI not accessible

[Raja T Nair]

Thanks for the reply, John.

The issue is resolved now. As I told in my previous mail, I had only
completed the installation and fuelmenu setup.
Had not run this script: /usr/sbin/bootstrap_admin_node.sh
Once I completed this step, nginx started listening and now webUI is
accessible.

I used this installation guide, but did not follow it completely, my bad:
https://docs.openstack.org/fuel-docs/latest/userdocs/fuel-install-guide/install/install_install_fuel_master_node.html#install-install-fuel-master-node

Thanks again for the response.

Regards,
Raja.


On 17 October 2017 at 18:40, John Petrini  wrote:

> Is nginx running?
>
> On Tue, Oct 17, 2017 at 8:31 AM, Raja T Nair  wrote:
>
>> Hello All,
>>
>> I downloaded the latest Mirantis Openstack iso from the website and
>> installed it as a virtualbox vm.
>>
>> Installation went through without any issue. the VM can communicate to
>> the outside world using given IP: 10.10.31.2/24
>>
>> But the web UI is not accessible. When I try to access it through a
>> browser, it redirects me to port 8443 , which errors out.
>>
>> I checked in the fuel master node, and port 8443 is not listening there.
>> Is there any more steps to perform after the installation, that brings
>> the webUI up?
>>
>> Can someone please help me troubleshoot this? I am doing fuel based
>> installation for the first time.
>>
>> Regards,
>> Raja.
>> --
>> :^)
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>


-- 
:^)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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-operators] Guest crash and KVM unhandled rdmsr

[George Mihaiescu]

Hi Blair,

We had a few cases of compute nodes hanging with the last log in syslog
being related to "rdmsr", and requiring hard reboots:
 kvm [29216]: vcpu0 unhandled rdmsr: 0x345

The workloads are probably similar to yours (SGE workers doing genomics)
with CPU mode host-passthrough, on top of Ubuntu 16.04 and kernel
4.4.0-96-generic.

I'm not sure the "rdmsr" logs are relevant though, because we see them on
other  compute nodes that have no issues.

Did you find anything that might indicate what the root cause is?

Cheers,
George


On Thu, Oct 12, 2017 at 5:26 PM, Blair Bethwaite 
wrote:

> Hi all,
>
> Has anyone seen guest crashes/freezes associated with KVM unhandled rdmsr
> messages in dmesg on the hypervisor?
>
> We have seen these messages before but never with a strong correlation to
> guest problems. However over the past couple of weeks this is happening
> almost daily with consistent correlation for a set of hosts dedicated to a
> particular HPC workload. So far as I know the workload has not changed, but
> we have just recently moved the hypervisors to Ubuntu Xenial (though they
> were already on the Xenial kernel previously) and done minor guest
> (CentOS7) updates. CPU mode is host-passthrough. Currently trying to figure
> out if the CPU flags in the guest have changed since the host upgrade...
>
> Cheers,
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Artem Panchenko]

Thank you, guys, for your replies and for providing so detailed information!

>We've identified a bug in some of the changes we've landed
http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%
23openstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have
a working fix we should be ready to release v2.

Indeed, that bug sounds like a release blocker and IMHO it definitely can't
go into 2.0.0 (we use a lot of macroses for JJB in the company I work for).
Unfortunately, I don't think I can help contributing or reviewing the code
(I'm not familiar with JJB internals), but I can do some testing of
patches. So feel free to add me to your gerrit CRs if you think you need
that!


Regards,
Artem

2017-10-17 18:20 GMT+03:00 Thanh Ha :

> +1 to that.
>
> My org is very much looking forward to the 2.0.0 release as we refuse to
> use the master stream. I do think work needs to be done to fix the YAML
> parser issue identified in the linked meeting and consider it blocking as
> we use this feature heavily in our own instance.
>
> It's been slow but we are pushing to get 2.0.0 out the door. Definitely if
> you want to help move things along please join the weekly meeting.
>
> Cheers,
> Thanh
>
>
> On Tue, Oct 17, 2017 at 9:39 AM, Darragh Bailey 
> wrote:
>
>> Hi Artem,
>>
>>
>> The delay has been caused by being consumed with other priorities. It's
>> unfortunately, but it happens, of course any help around patch reviews and
>> fixing up the patches in the backlog will help.
>>
>> If you'd like to drop into the irc chat #openstack-jjb on freenode room
>> this Friday 17th @1400 UTC, there will be some discussion about v2 and
>> what's left to be done. http://eavesdrop.openstack.org
>> /#Jenkins_Job_Builder_Team_Meeting
>>
>> We've identified a bug in some of the changes we've landed
>> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23o
>> penstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have
>> a working fix we should be ready to release v2.
>>
>> As I'm heading to a python conference this weekend, I'm hoping there will
>> be a hacking space and I'll try to solve both that bug and the concern
>> around use of a global config object everywhere mentioned in
>> https://etherpad.openstack.org/p/jjb_api_v2.0
>>
>>
>> Fingers crossed we should be able to get the v2 release out in the next
>> month, any help that you can give would be appreciated.
>>
>> Thanks,
>>
>>
>> --
>> Darragh Bailey
>> "Nothing is foolproof to a sufficiently talented fool"
>>
>>
>> On 17 October 2017 at 11:04, Artem Panchenko 
>> wrote:
>>
>>> Hi folks!
>>>
>>> I wonder if there is a road map or some release schedule for
>>> jenkins-job-builder project? Last time it was published on pypi/github more
>>> than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
>>> infra doesn't use Jenkins anymore and doesn't invest into JJB development
>>> (please correct me if I'm wrong). Though, I see that >150 changes have been
>>> merged to master since that time, so the project is still maintained.
>>>
>>> I'll appreciate If someone shares any details about when the next major
>>> version release of JJB is going to happen.
>>>
>>> Thanks in advance!
>>>
>>> ---
>>> Best regards,
>>> Artem Panchenko
>>>
>>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Thanh Ha]

Hi Artem,

The best thing you can probably help us out with right now is to test whats
in the master branch of JJB and try to identify any issues that you run
into and report back to us. This way we can hopefully find additional major
breaking issues (like the YAML parser issue) before a full release goes
out. In the meantime until the YAML parser issue is fixed I've been using
JJB with the YAML parser patch reverted on my own test system.

https://review.openstack.org/333076

Cheers,
Thanh


On Tue, Oct 17, 2017 at 12:13 PM, Artem Panchenko 
wrote:

> Thank you, guys, for your replies and for providing so detailed
> information!
>
> >We've identified a bug in some of the changes we've landed
> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23openstack-
> jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have a working
> fix we should be ready to release v2.
>
> Indeed, that bug sounds like a release blocker and IMHO it definitely
> can't go into 2.0.0 (we use a lot of macroses for JJB in the company I work
> for). Unfortunately, I don't think I can help contributing or reviewing the
> code (I'm not familiar with JJB internals), but I can do some testing of
> patches. So feel free to add me to your gerrit CRs if you think you need
> that!
>
>
> Regards,
> Artem
>
> 2017-10-17 18:20 GMT+03:00 Thanh Ha :
>
>> +1 to that.
>>
>> My org is very much looking forward to the 2.0.0 release as we refuse to
>> use the master stream. I do think work needs to be done to fix the YAML
>> parser issue identified in the linked meeting and consider it blocking as
>> we use this feature heavily in our own instance.
>>
>> It's been slow but we are pushing to get 2.0.0 out the door. Definitely
>> if you want to help move things along please join the weekly meeting.
>>
>> Cheers,
>> Thanh
>>
>>
>> On Tue, Oct 17, 2017 at 9:39 AM, Darragh Bailey 
>> wrote:
>>
>>> Hi Artem,
>>>
>>>
>>> The delay has been caused by being consumed with other priorities. It's
>>> unfortunately, but it happens, of course any help around patch reviews and
>>> fixing up the patches in the backlog will help.
>>>
>>> If you'd like to drop into the irc chat #openstack-jjb on freenode room
>>> this Friday 17th @1400 UTC, there will be some discussion about v2 and
>>> what's left to be done. http://eavesdrop.openstack.org
>>> /#Jenkins_Job_Builder_Team_Meeting
>>>
>>> We've identified a bug in some of the changes we've landed
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23o
>>> penstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have
>>> a working fix we should be ready to release v2.
>>>
>>> As I'm heading to a python conference this weekend, I'm hoping there
>>> will be a hacking space and I'll try to solve both that bug and the concern
>>> around use of a global config object everywhere mentioned in
>>> https://etherpad.openstack.org/p/jjb_api_v2.0
>>>
>>>
>>> Fingers crossed we should be able to get the v2 release out in the next
>>> month, any help that you can give would be appreciated.
>>>
>>> Thanks,
>>>
>>>
>>> --
>>> Darragh Bailey
>>> "Nothing is foolproof to a sufficiently talented fool"
>>>
>>>
>>> On 17 October 2017 at 11:04, Artem Panchenko 
>>> wrote:
>>>
 Hi folks!

 I wonder if there is a road map or some release schedule for
 jenkins-job-builder project? Last time it was published on pypi/github more
 than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
 infra doesn't use Jenkins anymore and doesn't invest into JJB development
 (please correct me if I'm wrong). Though, I see that >150 changes have been
 merged to master since that time, so the project is still maintained.

 I'll appreciate If someone shares any details about when the next major
 version release of JJB is going to happen.

 Thanks in advance!

 ---
 Best regards,
 Artem Panchenko

>>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[Openstack-operators] All Day DevOps

[Melvin Hillsman]

Hi everyone,

 

Apologies for delay in sending this out as I have known about it for some time 
and plan on attending one or two sessions:

 

https://www.alldaydevops.com/

 

What is All Day DevOps?

 

FREE online community responsible for creating the world's largest DevOps 
conference.

 

Over 100, 45-minute sessions across six tracks in all time zones, 
simultaneously:
Continuous Everything
Modern Infrastructure and Monitoring
DevSecOps
Cultural Transformations
DevOps in Government
“Tech Crawl" - where companies will invite you to a sneak peek of what it's 
like to work on DevOps in their organization.
 

All sessions are practitioner-led with a "no vendor pitch" policy strictly 
enforced.

 

You will need to register - https://www.alldaydevops.com/register

 

Watch parties – if you want to attend with others – not in every country 
unfortunately - https://www.alldaydevops.com/vp

 

Here is the schedule - https://www.alldaydevops.com/schedule - again, be sure 
to register!

 

 

-- 

Kind regards,

Melvin Hillsman

mrhills...@gmail.com
mobile: +1 (832) 264-2646

irc: mrhillsman

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack-operators] Ops Meetups Team : meeting minutes 2017-10-17

[Chris Morgan]

Hello Everyone,

  We had a productive Ops Meetups Team meeting today. Minutes below.

Topics discussed include the Sydney Summit, the mid-cycle meet up in Tokyo
in March, upstream LTS releases and whether to colocate future meetups with
OpenStack PTGs. If you have an interest in any of these please join our
weekly meeting at 14:00 UTC on #openstack-operators


Meeting ended Tue Oct 17 14:59:49 2017 UTC. Information about MeetBot at
http://wiki.debian.org/MeetBot . (v 0.1.4)
10:59 AM Minutes:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-17-14.02.html
10:59 AM Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-17-14.02.txt
10:59 AM Log:
http://eavesdrop.openstack.org/meetings/ops_meetup_team/2017/ops_meetup_team.2017-10-17-14.02.log.html

Cheers

Chris
-- 
Chris Morgan 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [thin...@gmail.com: [forum] Schedule Is Available]

[Mike Perez]

- Forwarded message from Mike Perez  -

From: Mike Perez 
To: openstack-...@lists.openstack.org
Date: Mon, 16 Oct 2017 16:43:28 -0700
Subject: [forum] Schedule Is Available

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



- End forwarded message -

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Thanh Ha]

+1 to that.

My org is very much looking forward to the 2.0.0 release as we refuse to
use the master stream. I do think work needs to be done to fix the YAML
parser issue identified in the linked meeting and consider it blocking as
we use this feature heavily in our own instance.

It's been slow but we are pushing to get 2.0.0 out the door. Definitely if
you want to help move things along please join the weekly meeting.

Cheers,
Thanh


On Tue, Oct 17, 2017 at 9:39 AM, Darragh Bailey 
wrote:

> Hi Artem,
>
>
> The delay has been caused by being consumed with other priorities. It's
> unfortunately, but it happens, of course any help around patch reviews and
> fixing up the patches in the backlog will help.
>
> If you'd like to drop into the irc chat #openstack-jjb on freenode room
> this Friday 17th @1400 UTC, there will be some discussion about v2 and
> what's left to be done. http://eavesdrop.openstack.
> org/#Jenkins_Job_Builder_Team_Meeting
>
> We've identified a bug in some of the changes we've landed
> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%
> 23openstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we
> have a working fix we should be ready to release v2.
>
> As I'm heading to a python conference this weekend, I'm hoping there will
> be a hacking space and I'll try to solve both that bug and the concern
> around use of a global config object everywhere mentioned in
> https://etherpad.openstack.org/p/jjb_api_v2.0
>
>
> Fingers crossed we should be able to get the v2 release out in the next
> month, any help that you can give would be appreciated.
>
> Thanks,
>
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
>
> On 17 October 2017 at 11:04, Artem Panchenko 
> wrote:
>
>> Hi folks!
>>
>> I wonder if there is a road map or some release schedule for
>> jenkins-job-builder project? Last time it was published on pypi/github more
>> than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
>> infra doesn't use Jenkins anymore and doesn't invest into JJB development
>> (please correct me if I'm wrong). Though, I see that >150 changes have been
>> merged to master since that time, so the project is still maintained.
>>
>> I'll appreciate If someone shares any details about when the next major
>> version release of JJB is going to happen.
>>
>> Thanks in advance!
>>
>> ---
>> Best regards,
>> Artem Panchenko
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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

[Openstack-operators] Cancelled: reminder: ops meet up team meeting today 14:00 UTC @ Tuesday, 17 October 2017

[Amrith Kumar]

OCT


17









"[Openstack-operators] reminder: ops meet up team meeting today 14:00 UTC" has been cancelled









When

   



Tuesday, 17 October 2017
02:00 PM to 03:00 PM 
 (GMT) Greenwich Mean Time - Dublin / Edinburgh / Lisbon / London 

This event repeats every week on Tuesday.







   

Message



Hello,
  The Ops Meetups Team will meet as usual at 14:00 UTC, or about 50 minutes from now, on #openstack-operators on IRC

Chris

--
Chris Morgan 

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=""
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-







 

   





 This event invitation was sent from   Yahoo Calendar






invite.ics
Description: application/ics
BEGIN:VCALENDAR
PRODID://Yahoo//Calendar//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\
 n\n--\nChris Morgan \n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not 
 edit this section of the description.\n\nView your event at https://www.go
 ogle.com/calendar/event?action=VIEW=N3QyMTRlZ2FyaGgwcjk2cjU0czdqczU3ZX
 Ygb3BlbnN0YWNrLW9wZXJhdG9yc0BsaXN0cy5vcGVuc3RhY2sub3Jn=MjIjYW1yaXRoLmt
 1bWFyQGdtYWlsLmNvbWUyMjg1ZmY5ZGM4ZDVmNjA4N2VjYmJlYWFiOTlmMGM1NDA0OGY2MjE
 tz=America/New_York=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
CLASS:PUBLIC
DTSTART;TZID=Europe/London:20171017T15
DTEND;TZID=Europe/London:20171017T16
PRIORITY:0
SEQUENCE:0
STATUS:CONFIRMED
UID:7t214egarhh0r96r54s7js5...@google.com
DTSTAMP:20171017T132030Z
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=openstack-operators@lists.openstack.org;R
 OLE=REQ_PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:openstack-operators
 @lists.openstack.org
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=amrith.ku...@verizonwireless.com;ROLE=REQ
 _PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:amrith.ku...@vzw.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Chris Morgan;ROLE=REQ_PARTICIPANT;RSVP=TR
 UE;CUTYPE=INDIVIDUAL:mailto:mihali...@gmail.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Pradipta Banerjee;ROLE=REQ_PARTICIPANT;RS
 VP=TRUE:mailto:bprad...@yahoo.com
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU
X-YAHOO-YID:yahoo.calendar.acl.writer
TRANSP:OPAQUE
STATUS:TENTATIVE
X-YAHOO-USER-STATUS:TENTATIVE
X-YAHOO-EVENT-STATUS:BUSY
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19961027T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+
TZNAME:GMT
DTSTART:18471201T00
RDATE:18471201T00
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T02
RDATE:19160521T02
RDATE:19170408T02

[Openstack-operators] Cancelled: reminder: ops meet up team meeting today 14:00 UTC @ Tuesday, 17 October 2017

[Amrith Kumar]

OCT


17









"[Openstack-operators] reminder: ops meet up team meeting today 14:00 UTC" has been cancelled









When

   



Tuesday, 17 October 2017
02:00 PM to 03:00 PM 
 (GMT) Greenwich Mean Time - Dublin / Edinburgh / Lisbon / London 

This event repeats every week on Tuesday.







   

Message



Hello,
  The Ops Meetups Team will meet as usual at 14:00 UTC, or about 50 minutes from now, on #openstack-operators on IRC

Chris

--
Chris Morgan 

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=""
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-







 

   





 This event invitation was sent from   Yahoo Calendar






invite.ics
Description: application/ics
BEGIN:VCALENDAR
PRODID://Yahoo//Calendar//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\
 n\n--\nChris Morgan \n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not 
 edit this section of the description.\n\nView your event at https://www.go
 ogle.com/calendar/event?action=VIEW=N3QyMTRlZ2FyaGgwcjk2cjU0czdqczU3ZX
 Ygb3BlbnN0YWNrLW9wZXJhdG9yc0BsaXN0cy5vcGVuc3RhY2sub3Jn=MjIjYW1yaXRoLmt
 1bWFyQGdtYWlsLmNvbWUyMjg1ZmY5ZGM4ZDVmNjA4N2VjYmJlYWFiOTlmMGM1NDA0OGY2MjE
 tz=America/New_York=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
CLASS:PUBLIC
DTSTART;TZID=Europe/London:20171017T15
DTEND;TZID=Europe/London:20171017T16
PRIORITY:0
SEQUENCE:0
STATUS:CONFIRMED
UID:7t214egarhh0r96r54s7js5...@google.com
DTSTAMP:20171017T132030Z
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=openstack-operators@lists.openstack.org;R
 OLE=REQ_PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:openstack-operators
 @lists.openstack.org
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=amrith.ku...@verizonwireless.com;ROLE=REQ
 _PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:amrith.ku...@vzw.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Chris Morgan;ROLE=REQ_PARTICIPANT;RSVP=TR
 UE;CUTYPE=INDIVIDUAL:mailto:mihali...@gmail.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Fabien Duranti;ROLE=REQ_PARTICIPANT;RSVP=
 TRUE:mailto:fdura...@ymail.com
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU
X-YAHOO-YID:yahoo.calendar.acl.writer
TRANSP:OPAQUE
STATUS:TENTATIVE
X-YAHOO-USER-STATUS:TENTATIVE
X-YAHOO-EVENT-STATUS:BUSY
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19961027T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+
TZNAME:GMT
DTSTART:18471201T00
RDATE:18471201T00
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T02
RDATE:19160521T02
RDATE:19170408T02

[Openstack-operators] Oops!

[Amrith Kumar]

Sorry about that folks!
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Cancelled: reminder: ops meet up team meeting today 14:00 UTC @ Tuesday, 17 October 2017

[Amrith Kumar]

OCT


17









"[Openstack-operators] reminder: ops meet up team meeting today 14:00 UTC" has been cancelled









When

   



Tuesday, 17 October 2017
02:00 PM to 03:00 PM 
 (GMT) Greenwich Mean Time - Dublin / Edinburgh / Lisbon / London 

This event repeats every week on Tuesday.







   

Message



Hello,
  The Ops Meetups Team will meet as usual at 14:00 UTC, or about 50 minutes from now, on #openstack-operators on IRC

Chris

--
Chris Morgan 

-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
Please do not edit this section of the description.

View your event at https://www.google.com/calendar/event?action=""
-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-







 

   





 This event invitation was sent from   Yahoo Calendar






invite.ics
Description: application/ics
BEGIN:VCALENDAR
PRODID://Yahoo//Calendar//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\
 n\n--\nChris Morgan \n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not 
 edit this section of the description.\n\nView your event at https://www.go
 ogle.com/calendar/event?action=VIEW=N3QyMTRlZ2FyaGgwcjk2cjU0czdqczU3ZX
 Ygb3BlbnN0YWNrLW9wZXJhdG9yc0BsaXN0cy5vcGVuc3RhY2sub3Jn=MjIjYW1yaXRoLmt
 1bWFyQGdtYWlsLmNvbWUyMjg1ZmY5ZGM4ZDVmNjA4N2VjYmJlYWFiOTlmMGM1NDA0OGY2MjE
 tz=America/New_York=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
CLASS:PUBLIC
DTSTART;TZID=Europe/London:20171017T15
DTEND;TZID=Europe/London:20171017T16
PRIORITY:0
SEQUENCE:0
STATUS:CONFIRMED
UID:7t214egarhh0r96r54s7js5...@google.com
DTSTAMP:20171017T132030Z
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=openstack-operators@lists.openstack.org;R
 OLE=REQ_PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:openstack-operators
 @lists.openstack.org
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=amrith.ku...@verizonwireless.com;ROLE=REQ
 _PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:amrith.ku...@vzw.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Chris Morgan;ROLE=REQ_PARTICIPANT;RSVP=TR
 UE;CUTYPE=INDIVIDUAL:mailto:mihali...@gmail.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Sunil Patil;ROLE=REQ_PARTICIPANT;RSVP=TRU
 E:mailto:sunb...@yahoo.com
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU
X-YAHOO-YID:yahoo.calendar.acl.writer
TRANSP:OPAQUE
STATUS:TENTATIVE
X-YAHOO-USER-STATUS:TENTATIVE
X-YAHOO-EVENT-STATUS:BUSY
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19961027T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+
TZNAME:GMT
DTSTART:18471201T00
RDATE:18471201T00
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T02
RDATE:19160521T02
RDATE:19170408T02

[Openstack-operators] Canceled event: reminder: ops meet up team meeting ... @ Tue Oct 17, 2017 10am - 11am (EDT) (openstack-operators@lists.openstack.org)

[amrith . kumar]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Atlantic/Reykjavik
X-LIC-LOCATION:Atlantic/Reykjavik
BEGIN:STANDARD
TZOFFSETFROM:+
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART:20171017T14Z
DTEND:20171017T15Z
DTSTAMP:20171017T134810Z
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
UID:7t214egarhh0r96r54s7js5...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am
 rith.ku...@verizonwireless.com;X-NUM-GUESTS=0:mailto:amrith.ku...@vzw.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=op
 enstack-operat...@lists.openstack.org;X-NUM-GUESTS=0:mailto:openstack-opera
 t...@lists.openstack.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ch
 ris Morgan;X-NUM-GUESTS=0:mailto:mihali...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Amrith
  Kumar;X-NUM-GUESTS=0:mailto:amrith.ku...@gmail.com
RECURRENCE-ID:20171017T14Z
CREATED:20171017T132030Z
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\n
 \n--\nChris Morgan 
LAST-MODIFIED:20171017T134809Z
LOCATION:
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Canceled event: reminder: ops meet up team meeting ... @ Weekly from 10am to 11am on Tuesday from Tue Oct 17 to Mon Oct 23 (EDT) (openstack-operators@lists.openstack.org)

[amrith . kumar]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Atlantic/Reykjavik
X-LIC-LOCATION:Atlantic/Reykjavik
BEGIN:STANDARD
TZOFFSETFROM:+
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART:20171017T14Z
DTEND:20171017T15Z
RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20171023T235959Z;BYDAY=TU
DTSTAMP:20171017T134821Z
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
UID:7t214egarhh0r96r54s7js5...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Amrith
  Kumar;X-NUM-GUESTS=0:mailto:amrith.ku...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=op
 enstack-operat...@lists.openstack.org;X-NUM-GUESTS=0:mailto:openstack-opera
 t...@lists.openstack.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am
 rith.ku...@verizonwireless.com;X-NUM-GUESTS=0:mailto:amrith.ku...@vzw.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=Ch
 ris Morgan;X-NUM-GUESTS=0:mailto:mihali...@gmail.com
CREATED:20171017T132030Z
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\n
 \n--\nChris Morgan 
LAST-MODIFIED:20171017T134820Z
LOCATION:
SEQUENCE:0
STATUS:CANCELLED
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Darragh Bailey]

Hi Artem,


The delay has been caused by being consumed with other priorities. It's
unfortunately, but it happens, of course any help around patch reviews and
fixing up the patches in the backlog will help.

If you'd like to drop into the irc chat #openstack-jjb on freenode room
this Friday 17th @1400 UTC, there will be some discussion about v2 and
what's left to be done.
http://eavesdrop.openstack.org/#Jenkins_Job_Builder_Team_Meeting

We've identified a bug in some of the changes we've landed
http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23openstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18,
and once we have a working fix we should be ready to release v2.

As I'm heading to a python conference this weekend, I'm hoping there will
be a hacking space and I'll try to solve both that bug and the concern
around use of a global config object everywhere mentioned in
https://etherpad.openstack.org/p/jjb_api_v2.0


Fingers crossed we should be able to get the v2 release out in the next
month, any help that you can give would be appreciated.

Thanks,


-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"


On 17 October 2017 at 11:04, Artem Panchenko  wrote:

> Hi folks!
>
> I wonder if there is a road map or some release schedule for
> jenkins-job-builder project? Last time it was published on pypi/github more
> than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
> infra doesn't use Jenkins anymore and doesn't invest into JJB development
> (please correct me if I'm wrong). Though, I see that >150 changes have been
> merged to master since that time, so the project is still maintained.
>
> I'll appreciate If someone shares any details about when the next major
> version release of JJB is going to happen.
>
> Thanks in advance!
>
> ---
> Best regards,
> Artem Panchenko
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack] [Mirantis][Fuel-9.0] UI not accessible

[John Petrini]

Is nginx running?

On Tue, Oct 17, 2017 at 8:31 AM, Raja T Nair  wrote:

> Hello All,
>
> I downloaded the latest Mirantis Openstack iso from the website and
> installed it as a virtualbox vm.
>
> Installation went through without any issue. the VM can communicate to the
> outside world using given IP: 10.10.31.2/24
>
> But the web UI is not accessible. When I try to access it through a
> browser, it redirects me to port 8443 , which errors out.
>
> I checked in the fuel master node, and port 8443 is not listening there.
> Is there any more steps to perform after the installation, that brings the
> webUI up?
>
> Can someone please help me troubleshoot this? I am doing fuel based
> installation for the first time.
>
> Regards,
> Raja.
> --
> :^)
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] Invitation: reminder: ops meet up team meeting ... @ Weekly from 10am to 11am on Tuesday (EDT) (openstack-operators@lists.openstack.org)

[Amrith Kumar]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Atlantic/Reykjavik
X-LIC-LOCATION:Atlantic/Reykjavik
BEGIN:STANDARD
TZOFFSETFROM:+
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART:20171017T14Z
DTEND:20171017T15Z
RRULE:FREQ=WEEKLY;BYDAY=TU
DTSTAMP:20171017T132030Z
ORGANIZER;CN=Amrith Kumar:mailto:amrith.ku...@gmail.com
UID:7t214egarhh0r96r54s7js5...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Amrith Kumar;X-NUM-GUESTS=0:mailto:amrith.ku...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=openstack-operators@lists.openstack.org;X-NUM-GUESTS=0:mailto:opens
 tack-operat...@lists.openstack.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=amrith.ku...@verizonwireless.com;X-NUM-GUESTS=0:mailto:amrith.kumar
 @vzw.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Chris Morgan;X-NUM-GUESTS=0:mailto:mihali...@gmail.com
CREATED:20171017T132030Z
DESCRIPTION:Hello\,\n  The Ops Meetups Team will meet as usual at 14:00 UTC
 \, or about 50 minutes from now\, on #openstack-operators on IRC\n\nChris\n
 \n--\nChris Morgan \n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edi
 t this section of the description.\n\nView your event at https://www.google
 .com/calendar/event?action=VIEW=N3QyMTRlZ2FyaGgwcjk2cjU0czdqczU3ZXYgb3B
 lbnN0YWNrLW9wZXJhdG9yc0BsaXN0cy5vcGVuc3RhY2sub3Jn=MjIjYW1yaXRoLmt1bWFyQ
 GdtYWlsLmNvbWUyMjg1ZmY5ZGM4ZDVmNjA4N2VjYmJlYWFiOTlmMGM1NDA0OGY2MjE=Amer
 ica/New_York=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20171017T132030Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[Openstack-operators] reminder: ops meet up team meeting today 14:0
 0 UTC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack-operators] reminder: ops meet up team meeting today 14:00 UTC

[Chris Morgan]

Hello,
  The Ops Meetups Team will meet as usual at 14:00 UTC, or about 50 minutes
from now, on #openstack-operators on IRC

Chris

-- 
Chris Morgan 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] [Mirantis][Fuel-9.0] UI not accessible

[Raja T Nair]

Hello All,

I downloaded the latest Mirantis Openstack iso from the website and
installed it as a virtualbox vm.

Installation went through without any issue. the VM can communicate to the
outside world using given IP: 10.10.31.2/24

But the web UI is not accessible. When I try to access it through a
browser, it redirects me to port 8443 , which errors out.

I checked in the fuel master node, and port 8443 is not listening there.
Is there any more steps to perform after the installation, that brings the
webUI up?

Can someone please help me troubleshoot this? I am doing fuel based
installation for the first time.

Regards,
Raja.
-- 
:^)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[OpenStack-Infra] Remaining connections to gerrit in the third party CI

[guy.kim]

Dear everyone,

I am Guy, one of the operator for our third-party CI.

Recently, we are facing an issue in our CI. Indeed, our CI keeps running and 
reports the results to Gerrit. But there are still some remaining connections 
to Gerrit that are not closed. OpenStack Infra said that it reaches more than 
100 connections (limit number of allowed connections). So when the connection 
is over 100, our CI cannot connect to Gerrit because the IP is blocked due to 
the high number of remaining connections.

We are still checking our servers if one of them keeps dropping SSH connections 
to Gerrit at the port 29418. So far, we haven’t found any servers trying to 
connect to Gerrit.

Besides, our zuul version is 2.5.2. This version has already includes the fix 
for https://storyboard.openstack.org/#!/story/2000923.

Is anyone has faced this issue before? If yes, how did you fix it?

Thank you in advance for your answers.
Best regards,
Guy KIM
-
[itri_CEL_A2]
ITRI ICL
Division for Data Center Systems Software
E-mail : guy@itri.org.tw
Tel: (03)591-3502
Rm 109, 1F, Building 53, 195, Sec 4, Chung Hsing Rd, Chutung,
Hsinchu 31040, Taiwan
-



--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Artem Panchenko]

Hi folks!

I wonder if there is a road map or some release schedule for
jenkins-job-builder project? Last time it was published on pypi/github more
than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
infra doesn't use Jenkins anymore and doesn't invest into JJB development
(please correct me if I'm wrong). Though, I see that >150 changes have been
merged to master since that time, so the project is still maintained.

I'll appreciate If someone shares any details about when the next major
version release of JJB is going to happen.

Thanks in advance!

---
Best regards,
Artem Panchenko
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

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