Re: [openstack-dev] Bumping eventlet to 0.24.1

[Matthew Thode]

On 18-08-23 09:50:13, Matthew Thode wrote:
> This is your warning, if you have concerns please comment in
> https://review.openstack.org/589382 .  cross tests pass, so that's a
> good sign... atm this is only for stein.
> 

I pushed the big red button.

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi Dmitry,

Thanks your reply. Absolutely you are a sdk expert.

> This is a good first step, but if I get it right it does not specify
which
> response corresponds to which request.

You got it. I think it depends on how to use the API schemas.
We could define some rules to make sure which response corresponds to which
request.
For example, by order. Maybe you can give some other suggestions.
Also, this is not fresh concept, we can find the choice definition in xsd
[1].
By the way, firstly we can sort out OpenStack API schemas ,
and handle these schemas to the developers and the users,
and let them to choose how to use it.

[1] https://www.w3schools.com/xml/el_choice.asp

Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 7:01 PM Dmitry Tantsur  wrote:

> Hi,
>
> On 08/29/2018 08:36 AM, Edison Xiang wrote:
> > Hi team,
> >
> > As we know, Open API 3.0 was released on July, 2017, it is about one
> year ago.
> > Open API 3.0 support some new features like anyof, oneof and allof than
> Open API
> > 2.0(Swagger 2.0).
> > Now OpenStack projects do not support Open API.
> > Also I found some old emails in the Mail List about supporting Open API
> 2.0 in
> > OpenStack.
> >
> > Some limitations are mentioned in the Mail List for OpenStack API:
> > 1. The POST */action APIs.
> >  These APIs are exist in lots of projects like nova, cinder.
> >  These APIs have the same URI but the responses will be different
> when the
> > request is different.
> > 2. Micro versions.
> >  These are controller via headers, which are sometimes used to
> describe
> > behavioral changes in an API, not just request/response schema changes.
> >
> > About the first limitation, we can find the solution in the Open API 3.0.
> > The example [2] shows that we can define different request/response in
> the same
> > URI by anyof feature in Open API 3.0.
>
> This is a good first step, but if I get it right it does not specify which
> response corresponds to which request.
>
> >
> > About the micro versions problem, I think it is not a limitation related
> a
> > special API Standard.
> > We can list all micro versions API schema files in one directory like
> nova/V2,
>
> I don't think this approach will scale if you plan to generate anything
> based on
> these schemes. If you generate client code from separate schema files,
> you'll
> essentially end up with dozens of major versions.
>
> > or we can list the schema changes between micro versions as tempest
> project did [3].
>
> ++
>
> >
> > Based on Open API 3.0, it can bring lots of benefits for OpenStack
> Community and
> > does not impact the current features the Community has.
> > For example, we can automatically generate API documents, different
> language
> > Clients(SDK) maybe for different micro versions,
>
>  From my experience with writing an SDK, I don't believe generating a
> complete
> SDK from API schemes is useful. Maybe generating low-level protocol code
> to base
> an SDK on, but even that may be easier to do by hand.
>
> Dmitry
>
> > and generate cloud tool adapters for OpenStack, like ansible module,
> terraform
> > providers and so on.
> > Also we can make an API UI to provide an online and visible API search,
> API
> > Calling for every OpenStack API.
> > 3rd party developers can also do some self-defined development.
> >
> > [1] https://github.com/OAI/OpenAPI-Specification
> > [2]
> >
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> > [3]
> >
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> >
> > Best Regards,
> > Edison Xiang
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

[Renat Akhmerov]

I’m also in favour of backporting it because it solves a real production 
problem.

Thanks

Renat Akhmerov
@Nokia
On 5 Sep 2018, 16:55 +0700, Dougal Matthews , wrote:
> > On 5 September 2018 at 10:52, Dougal Matthews  wrote:
> > > > (Note: I added [release] to the email subject, as I think that will 
> > > > make it visible to the right folks.)
> >
> > Darn. It should have been [stable]. I have added that now. Sorry for the 
> > noise.
> >
> __
> OpenStack Development Mailing 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] [tempest][CI][nova compute] Skipping non-compute-driver tests

[Chen CH Ji]

I see the patch is still ongoing status and do you have a follow up
plan/discussion for that? we are maintaining 2 CIs (z/VM and KVM on z)
so skip non-compute related cases will be a good for 3rd part CI .. thanks

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:   09/04/2018 09:35 PM
Subject:[openstack-dev] [tempest][CI][nova compute] Skipping
non-compute-driver tests



Folks-

 The other day, I posted an experimental patch [1] with an
effectively
empty ComputeDriver (just enough to make n-cpu actually start) to see
how much of our CI would pass. The theory being that any tests that
still pass are tests that don't touch our compute driver, and are
therefore not useful to run in our CI environment. Because anything that
doesn't touch our code should already be well covered by generic
dsvm-tempest CIs. The results [2] show that 707 tests still pass.

 So I'm wondering whether there might be a way to mark tests as
being
"compute driver-specific" such that we could switch off all the other
ones [3] via a one-line conf setting. Because surely this has potential
to save a lot of CI resource not just for us but for other driver
vendors, in tree and out.

Thanks,
efried

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

[2]
http://184.172.12.213/66/599066/5/check/nova-powervm-out-of-tree-pvm/a1b42d5/powervm_os_ci.html.gz

[3] I get that there's still value in running all those tests. But it
could be done like once every 10 or 50 or 100 runs instead of every time.

__
OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

[Abhishek Kekane]

Hi Rico,

We will discuss this during PTG, however meantime you can add
WSGI_MODE=mod_wsgi in local.conf for testing purpose.

Thanks & Best Regards,

Abhishek Kekane

On Thu, Sep 6, 2018 at 9:21 AM, Rico Lin  wrote:

> Since we all use devstack as the test environment, I can see it's required
> that we allow this scenario works for devstack in the gateway. Do you got
> any plan to fix [1] in short future?:)
>
> [1]  https://review.openstack.org/#/c/545483/
>
> On Thu, Sep 6, 2018 at 11:00 AM Brian Rosmaita 
> wrote:
>
>>
>>
>> On Wed, Sep 5, 2018 at 11:12 AM Rico Lin 
>> wrote:
>>
>>>
>>> On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita <
>>> rosmaita.foss...@gmail.com> wrote:
>>>
>>> Since Queens, Glance has had a 'web-download' import method that takes a
 URL [0].  It's enabled by default, but operators do have the ability to
 turn it off.  (There's an API call to see what methods are enabled in a
 particular cloud.)  Operators also have the ability to restrict what URLs
 are acceptable [1], but that's probably a good thing.

 In short, Glance does have the ability to do what you need since
 Queens, but there's no guarantee that it will be available in all clouds
 and for all URLs.  If you foresee that as a problem, it would be a good
 idea to get together with the Glance team at the PTG to discuss this
 issue.  Please add it as a topic to the Glance PTG planning etherpad [3] as
 soon as you can.

>>> Cool! Thank Brian.
>>> Sounds like something we can use, just one small question in my mind. In
>>> order to use `web-download` in image resource, we need to create an empty
>>> image than use import to upload that imge. I have try that scenrio by
>>> myself now (I'm not really diving into detail yet) by:
>>> 1. create an empty image(like `openstack image create --container-format
>>> bare --disk-format qcow2 img_name`)
>>> 2. and than import image  (like `glance image-import --import-method
>>> web-download --uri https://download.cirros-cloud.
>>> net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
>>> But that image stuck in queued after first step.
>>> dose this scenario supported by glance? Or where did I do wrong?
>>>
>>
>> That scenario should work, unless you are running glance under uwsgi, in
>> which case the task engine (used to import the image) does not run.  You
>> can tell that's the problem if as an admin user you use the command 'glance
>> task-list'.  You should see a task of type 'api_image_import' with status
>> 'pending'.  (You can do 'glance task-show ' to see the details of
>> the task.)
>>
>> If you are using devstack, you can apply this patch before you call
>> stack.sh: https://review.openstack.org/#/c/545483/  .  It will allow
>> everything except Glance to run under uwsgi.
>>
>>
>>>
>>>

 [0] https://developer.openstack.org/api-ref/image/
 v2/index.html#interoperable-image-import
 [1] https://docs.openstack.org/glance/latest/admin/
 interoperable-image-import.html#configuring-the-web-download-method
 [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning

>>>
>>> --
>>> May The Force of OpenStack Be With You,
>>>
>>> *Rico Lin*irc: ricolin
>>>
>>> 
>>> __
>>> OpenStack Development Mailing 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
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

[Rico Lin]

Since we all use devstack as the test environment, I can see it's required
that we allow this scenario works for devstack in the gateway. Do you got
any plan to fix [1] in short future?:)

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

On Thu, Sep 6, 2018 at 11:00 AM Brian Rosmaita 
wrote:

>
>
> On Wed, Sep 5, 2018 at 11:12 AM Rico Lin 
> wrote:
>
>>
>> On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
>> wrote:
>>
>> Since Queens, Glance has had a 'web-download' import method that takes a
>>> URL [0].  It's enabled by default, but operators do have the ability to
>>> turn it off.  (There's an API call to see what methods are enabled in a
>>> particular cloud.)  Operators also have the ability to restrict what URLs
>>> are acceptable [1], but that's probably a good thing.
>>>
>>> In short, Glance does have the ability to do what you need since Queens,
>>> but there's no guarantee that it will be available in all clouds and for
>>> all URLs.  If you foresee that as a problem, it would be a good idea to get
>>> together with the Glance team at the PTG to discuss this issue.  Please add
>>> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>>>
>> Cool! Thank Brian.
>> Sounds like something we can use, just one small question in my mind. In
>> order to use `web-download` in image resource, we need to create an empty
>> image than use import to upload that imge. I have try that scenrio by
>> myself now (I'm not really diving into detail yet) by:
>> 1. create an empty image(like `openstack image create --container-format
>> bare --disk-format qcow2 img_name`)
>> 2. and than import image  (like `glance image-import --import-method
>> web-download --uri
>> https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
>> But that image stuck in queued after first step.
>> dose this scenario supported by glance? Or where did I do wrong?
>>
>
> That scenario should work, unless you are running glance under uwsgi, in
> which case the task engine (used to import the image) does not run.  You
> can tell that's the problem if as an admin user you use the command 'glance
> task-list'.  You should see a task of type 'api_image_import' with status
> 'pending'.  (You can do 'glance task-show ' to see the details of
> the task.)
>
> If you are using devstack, you can apply this patch before you call
> stack.sh: https://review.openstack.org/#/c/545483/  .  It will allow
> everything except Glance to run under uwsgi.
>
>
>>
>>
>>>
>>> [0]
>>> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
>>> [1]
>>> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
>>> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>>>
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>> *Rico Lin*irc: ricolin
>>
>> __
>> OpenStack Development Mailing 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
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [heat][glance] Heat image resource support issue

[Brian Rosmaita]

On Wed, Sep 5, 2018 at 11:12 AM Rico Lin  wrote:

>
> On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
> wrote:
>
> Since Queens, Glance has had a 'web-download' import method that takes a
>> URL [0].  It's enabled by default, but operators do have the ability to
>> turn it off.  (There's an API call to see what methods are enabled in a
>> particular cloud.)  Operators also have the ability to restrict what URLs
>> are acceptable [1], but that's probably a good thing.
>>
>> In short, Glance does have the ability to do what you need since Queens,
>> but there's no guarantee that it will be available in all clouds and for
>> all URLs.  If you foresee that as a problem, it would be a good idea to get
>> together with the Glance team at the PTG to discuss this issue.  Please add
>> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>>
> Cool! Thank Brian.
> Sounds like something we can use, just one small question in my mind. In
> order to use `web-download` in image resource, we need to create an empty
> image than use import to upload that imge. I have try that scenrio by
> myself now (I'm not really diving into detail yet) by:
> 1. create an empty image(like `openstack image create --container-format
> bare --disk-format qcow2 img_name`)
> 2. and than import image  (like `glance image-import --import-method
> web-download --uri
> https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
> But that image stuck in queued after first step.
> dose this scenario supported by glance? Or where did I do wrong?
>

That scenario should work, unless you are running glance under uwsgi, in
which case the task engine (used to import the image) does not run.  You
can tell that's the problem if as an admin user you use the command 'glance
task-list'.  You should see a task of type 'api_image_import' with status
'pending'.  (You can do 'glance task-show ' to see the details of
the task.)

If you are using devstack, you can apply this patch before you call
stack.sh: https://review.openstack.org/#/c/545483/  .  It will allow
everything except Glance to run under uwsgi.


>
>
>>
>> [0]
>> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
>> [1]
>> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
>> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
> __
> OpenStack Development Mailing 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] [storyboard] [I18n] Can Storyboard web pages be translatable to multiple languages?

[Ian Y. Choi]

Hello,

I wanna ask whether https://storyboard.openstack.org/ web pages can be
translatable to multiple languages
(e.g., Chinese, Japanese, Korean, German, French, Spanish, ...) or not.

I have thought such idea on my mind from some time period ago, and I
think now would be a good timing
for raising this question since it seems that more project repositories
are migrating to Storyboard,
and internationalization of Storyboard is one of criteria for I18n team
to decide to migrate to Storyboard
(FYI: discussion on I18n team - [1]).

From my very brief investigation, it seems that adding I18n support on
html pages like [2],
extracting translation source strings to pot files, syncing with Zanata
[3] with powerful infra support [4]
would make Storyboard translatable with translating to multiple
languages by I18n team.

Am I understanding correctly and can I18n team get help on such effort?


With many thanks,

/Ian

[1]
http://lists.openstack.org/pipermail/openstack-i18n/2018-September/003307.html
[2]
http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/src/app/stories/template/list.html#n26
[3] http://translate.openstack.org/
[4] https://docs.openstack.org/i18n/latest/infra.html


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

Re: [openstack-dev] [nova][cinder] about unified limits

[Jaze Lee]

On Stein only one service?
Is there some methods to move this more fast?
Lance Bragstad  于2018年9月5日周三 下午9:29写道：
>
> Not yet. Keystone worked through a bunch of usability improvements with the 
> unified limits API last release and created the oslo.limit library. We have a 
> patch or two left to land in oslo.limit before projects can really start 
> using unified limits [0].
>
> We're hoping to get this working with at least one resource in another 
> service (nova, cinder, etc...) in Stein.
>
> [0] 
> https://review.openstack.org/#/q/status:open+project:openstack/oslo.limit+branch:master+topic:limit_init
>
> On Wed, Sep 5, 2018 at 5:20 AM Jaze Lee  wrote:
>>
>> Hello,
>> Does nova and cinder  use keystone's unified limits api to do quota job?
>> If not, is there a plan to do this?
>> 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



-- 
谦谦君子

__
OpenStack Development Mailing 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] [cyborg]Denver PTG arrangements

[Zhipeng Huang]

Hi Team,

As we discussed at yesterday's team meeting, please find our schedule for
PTG at https://etherpad.openstack.org/p/cyborg-ptg-stein , team dinner
information also available :)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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] [congress] no IRC meeting 9/14 during PTG week

[Eric K]

Let's resume on 9/21. Thanks!



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

[openstack-dev] [Tacker] vPTG Topics gathering

[Dharmendra Kushwaha]

Hi all,

We are planning to have our one-day virtual PTG meetup for Stein during 
20th-21th September.
I have created etherpad link [1]  for the same. Please put your discussion 
topics on that. 
Please do it by Saturday, 8th September, so that I will fix the schedule 
accordingly.

[1]: https://etherpad.openstack.org/p/Tacker-PTG-Stein

Thanks & Regards
Dharmendra Kushwaha


__
OpenStack Development Mailing 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] 6 days left for the Forum Brainstorming Period...

[Jimmy McArthur]

Hello All!

The Forum Brainstorming session ends September 11 and the topic 
submission phase begins September 12.  Thank you to all of the projects 
that have created a wiki and begun the Brainstorming Phase.


I'd like to encourage projects that have not yet created an etherpad to 
do so at https://wiki.openstack.org/wiki/Forum/Berlin2018  This is an 
opportunity to get feedback, vet ideas, and garner support from the 
community on your ideas.  Don't rely only on a PTL to make the agenda... 
step on up and place the items you consider important front and center :)


If you have questions or concerns about the process, please don't 
hesitate to reach out.


Cheers,
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

Re: [openstack-dev] [election][tc] TC Candidacy

[Tony Breeds]

On Thu, Sep 06, 2018 at 09:24:39AM +1000, Tony Breeds wrote:

> Hi JP,
>I don't see a review in openstack/election from you.  Are you able to
> upload one befoer the deadline?
> 
> Please see: 
> https://governance.openstack.org/election/#how-to-submit-a-candidacy
> for more information.

I really should have checked my email for merged changes before
sending this sorry all.  

Yours Tony.


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

[openstack-dev] [election] [tc] TC candidacy

[Zhipeng Huang]

Hi all,

I ran for TC in the last cycle and I guess you can find out more
information on the candidacy patch [0], so I won't copy and paste that long
article here again :)

I found that most of my statement for my last ran is still valid today
[0][1]. I want to build strong cross-community collaboration, best
practices for project level governance and more innovations for OpenStack.

Hopefully second time is a charm and I could bring something fresh and
diverse thinking to the group :)

[0] https://review.openstack.org/#/c/600279/
[1] https://hannibalhuang.github.io/2018/04/16/i-didn't-build-it/
-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing 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][election] Last day for TC nominations

[Tony Breeds]

Hi folks,
A quick reminder that we are in the last hours for TC
candidate announcements. Nominations are open until Sep 06, 2018 23:45
UTC.

If you want to stand for TC, don't delay, follow the
instructions at [1] to make sure the community knows your
intentions.

Make sure your nomination has been submitted to the
openstack/election repository and approved by election officials.

Thank you,

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy


Yours Tony.


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] [all]-ish : Updates required for readthedocs publishers

[Ian Wienand]

On 09/06/2018 02:10 AM, Doug Hellmann wrote:

Those instructions and the ones linked at
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
say to "generate a web hook URL".


I think you got the correct answers, thanks Dmitry.  Note it is also
illustrated at

 https://imgur.com/a/Pp4LH31

Thanks

-i

__
OpenStack Development Mailing 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] [election][tc] TC Candidacy

[Tony Breeds]

On Wed, Sep 05, 2018 at 01:04:09PM +0200, jean-phili...@evrard.me wrote:
> Hello everyone,
> 
> I am hereby announcing my candidacy for a position on the OpenStack Technical 
> Committee (TC).

Hi JP,
   I don't see a review in openstack/election from you.  Are you able to
upload one befoer the deadline?

Please see: https://governance.openstack.org/election/#how-to-submit-a-candidacy
for more information.

Yours Tony.


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

[openstack-dev] [all][tc] Last Hours for TC Nominations

[Kendall Nelson]

Hello All,

A quick reminder that we are in the last hours for TC candidate
announcements. Nominations are open until September 06, 2018 23:45 UTC.

If you want to stand for TC, don't delay, follow the instructions at [1] to
make sure the community knows your intentions.

Make sure your nomination has been submitted to the openstack/election
repository and approved by election officials.

Voters should also begin thinking about questions they want to ask
candidates during the campaigning period that begins as soon as nominations
end.

Thank you,

- The Election Officials

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
__
OpenStack Development Mailing 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] [glance][keystone][nova][ironic][tripleo][edge][airship] Edge related joint sessions at the PTG next week

[Alan Bishop]

On Wed, Sep 5, 2018 at 5:41 PM Ildiko Vancsa 
wrote:

> Hi,
>
> The PTG is approaching quickly and as we are planning a couple of joint
> sessions on edge computing with a couple of OpenStack project teams I would
> like to give a quick summary of the plans.
>
> We have the Edge Computing Group meeting all day Tuesday in Ballroom A[1]
> from 9am MDT. The group is planning a use cases and requirements discussion
> in the morning and collaborative sessions with Glance, Keystone, Nova,
> Airship, TripleO and StarlingX throughout the day. Furthermore people from
> the group will participate in the relevant session on the Ironic agenda on
> Thursday.
>

Thanks, Ildiko!

I highly encourage members from other storage communities such as cinder
and manila to consider attending (I will be).

Alan


> For the full agenda and session topics please see the following etherpad:
> https://etherpad.openstack.org/p/EdgeComputingGroupPTG4
>
> The StarlingX project is meeting all day Wednesday in Winter Park[1]
> starting at 9am MDT. Their topics include discussions on initial governance
> and release planning and further technical topics concerning architecture,
> build and deployment. The StarlingX team will participate in the
> cross-project sessions on Tuesday listed on the Edge Group etherpad for
> cross-project discussions.
>
> For the full agenda of StarlingX sessions please see the following
> etherpad: https://etherpad.openstack.org/p/stx-PTG-agenda
>
> Both groups are planning to provide remote participation option for their
> sessions, the information will be provided on the etherpads above before
> the sessions start.
>
> Please let me know if you have any questions.
>
> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
>
> [1] https://web14.openstack.org/assets/ptg/Denver-map.pdf
>
>
>
> __
> OpenStack Development Mailing 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] [E] [tripleo] quickstart for humans

[Wesley Hayutin]

On Wed, Sep 5, 2018 at 5:08 PM Wesley Hayutin  wrote:

> On Wed, Sep 5, 2018 at 3:55 PM Gordon, Kent <
> kent.gor...@verizonwireless.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Honza Pokorny [mailto:ho...@redhat.com]
>> > Sent: Thursday, August 30, 2018 9:28 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > 
>> > Subject: [E] [openstack-dev] [tripleo] quickstart for humans
>> >
>> > Hello!
>> >
>> > Over the last few months, it seems that tripleo-quickstart has evolved
>> into a
>> > CI tool.  It's primarily used by computers, and not humans.
>> > tripleo-quickstart is a helpful set of ansible playbooks, and a
>> collection of
>> > feature sets.  However, it's become less useful for setting up
>> development
>> > environments by humans.  For example, devmode.sh was recently
>> > deprecated without a user-friendly replacement. Moreover, during some
>> > informal irc conversations in #oooq, some developers even mentioned the
>> > plan to merge tripleo-quickstart and tripleo-ci.
>> >
>> > I think it would be beneficial to create a set of defaults for
>> tripleo-quickstart
>> > that can be used to spin up new environments; a set of defaults for
>> humans.
>> > This can either be a well-maintained script in tripleo-quickstart
>> itself, or a
>> > brand new project, e.g.
>> > tripleo-quickstart-humans.  The number of settings, knobs, and flags
>> should
>> > be kept to a minimum.
>> >
>> > This would accomplish two goals:
>> >
>> > 1.  It would bring uniformity to the team.  Each environment is
>> > installed the same way.  When something goes wrong, we can
>> > eliminate differences in setup when debugging.  This should save a
>> > lot of time.
>> >
>> > 2.  Quicker and more reliable environment setup.  If the set of defaults
>> > is used by many people, it should container fewer bugs because more
>> > people using something should translate into more bug reports, and
>> > more bug fixes.
>> >
>> > These thoughts are coming from the context of tripleo-ui development.  I
>> > need an environment in order to develop, but I don't necessarily always
>> care
>> > about how it's installed.  I want something that works for most
>> scenarios.
>> >
>> > What do you think?  Does this make sense?  Does something like this
>> already
>> > exist?
>> >
>> > Thanks for listening!
>> >
>> > Honza
>>
>> What is the recommended way to bring up a small POC of TripleO outside of
>> CI?
>>
>> Documentation suggests using quickstart
>>
>>
>> https://docs.openstack.org/tripleo-docs/latest/install/introduction/architecture.html
>>
>> "For development or proof of concept (PoC) environments, Quickstart can
>> also be used."
>>
>> Quickstart.sh outside of CI has been broken for a while.
>> It requires zuul cloner to work.
>>
>> https://bugs.launchpad.net/tripleo/+bug/1754498
>>
>>
> The issue described in bug [1] was caused by pip requirement install
> errors being swallowed up and not written to the console.
> TripleO-QuickStart-Extras was not pip installed due to previous errors, and
> that would cause quickstart-extras.yml to not be installed.
>
> The root cause of the failures is that pip install dependencies are not
> working as expected or in the same way without a http proxy  server.  This
> bug [1] should be closed, a RFE bug to ensure things work w/ a http proxy
> server should be opened.
>
> Please let me know if your work proves otherwise.
> Thank you!
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1754498
>
>
>
I just launched an install with the following.

export WD=/var/tmp/test; ./quickstart.sh  --no-clone --release
tripleo-ci/master  --tags all --clean  --teardown all  -w $WD
whayutin-testbox

Where whayutin-testbox is my remote testbox, everything is working well atm
however there may be an issue w/ the bmc [1]

[1] https://bugs.launchpad.net/tripleo/+bug/1790969


>
>
>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> Wes Hayutin
>
> Associate MANAGER
>
> Red Hat
>
> 
>
> whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay
> 
>
> View my calendar and check my availability for meetings HERE
> 
>
-- 

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
OpenStack Development Mailing List (not for usage questi

Re: [openstack-dev] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

[Ildiko Vancsa]

Hi,

I mentioned a non-official project on the call we had this week for IoT (bare 
metal) management, called IoTronic. It is developed in connection to a Smart 
Cities use case, the name of the project is Stack4Things under the #SmartME 
umbrella project, mostly revolving around Single-Board Computers (Raspberrys, 
Arduinos, etc) as full-blown (far) edge nodes.

IoTronic at this point is interoperating/integrated with 
Horizon/Keystone/Neutron.

You can find information on the following link about the umbrella projects and 
IoTronic:

Latest talk about Stack4Things/IoTronic, at the (Vancouver) Summit (includes 
link to video):
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21201/an-edge-computing-case-study-for-monasca-smart-city-ai-powered-surveillance-and-monitoring

Official Stack4Things page (updates in progress, with high-level documentation, 
papers, etc)
http://stack4things.unime.it/

#SmartME Smart City (Messina) portal
http://smartme.unime.it/

#SmartME Open Data portal
http://smartme-data.unime.it 

OpenStack Infra-hosted repos for IoTronic
http://git.openstack.org/cgit/openstack/iotronic
http://git.openstack.org/cgit/openstack/iotronic-lightning-rod 
http://git.openstack.org/cgit/openstack/iotronic-ui
http://git.openstack.org/cgit/openstack/python-iotronicclient

Thanks,
Ildikó


> On 2018. Aug 31., at 6:50, Emilien Macchi  wrote:
> 
> On Fri, Aug 31, 2018 at 4:42 AM Dmitry Tantsur  wrote:
> This is about a call a week before the PTG, not the PTG itself. You're still 
> very welcome to join!
> 
> It's good too! Our TripleO IRC meeting is at 14 UTC.
> 
> Thanks,
> -- 
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [charms] Propose Felipe Reyes for OpenStack Charmers team

[Billy Olsen]

Hi,

I'd like to propose Felipe Reyes to join the OpenStack Charmers team as
a core member. Over the past couple of years Felipe has contributed
numerous patches and reviews to the OpenStack charms [0]. His experience
and knowledge of the charms used in OpenStack and the usage of Juju make
him a great candidate.

[0] -
https://review.openstack.org/#/q/owner:%22Felipe+Reyes+%253Cfelipe.reyes%2540canonical.com%253E%22

Thanks,

Billy Olsen

__
OpenStack Development Mailing 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] [glance][keystone][nova][ironic][tripleo][edge][airship] Edge related joint sessions at the PTG next week

[Ildiko Vancsa]

Hi,

The PTG is approaching quickly and as we are planning a couple of joint 
sessions on edge computing with a couple of OpenStack project teams I would 
like to give a quick summary of the plans.

We have the Edge Computing Group meeting all day Tuesday in Ballroom A[1] from 
9am MDT. The group is planning a use cases and requirements discussion in the 
morning and collaborative sessions with Glance, Keystone, Nova, Airship, 
TripleO and StarlingX throughout the day. Furthermore people from the group 
will participate in the relevant session on the Ironic agenda on Thursday.

For the full agenda and session topics please see the following etherpad: 
https://etherpad.openstack.org/p/EdgeComputingGroupPTG4

The StarlingX project is meeting all day Wednesday in Winter Park[1] starting 
at 9am MDT. Their topics include discussions on initial governance and release 
planning and further technical topics concerning architecture, build and 
deployment. The StarlingX team will participate in the cross-project sessions 
on Tuesday listed on the Edge Group etherpad for cross-project discussions.

For the full agenda of StarlingX sessions please see the following etherpad: 
https://etherpad.openstack.org/p/stx-PTG-agenda

Both groups are planning to provide remote participation option for their 
sessions, the information will be provided on the etherpads above before the 
sessions start.

Please let me know if you have any questions.

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

[1] https://web14.openstack.org/assets/ptg/Denver-map.pdf



__
OpenStack Development Mailing 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] [E] [tripleo] quickstart for humans

[Wesley Hayutin]

On Wed, Sep 5, 2018 at 3:55 PM Gordon, Kent 
wrote:

>
>
> > -Original Message-
> > From: Honza Pokorny [mailto:ho...@redhat.com]
> > Sent: Thursday, August 30, 2018 9:28 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: [E] [openstack-dev] [tripleo] quickstart for humans
> >
> > Hello!
> >
> > Over the last few months, it seems that tripleo-quickstart has evolved
> into a
> > CI tool.  It's primarily used by computers, and not humans.
> > tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of
> > feature sets.  However, it's become less useful for setting up
> development
> > environments by humans.  For example, devmode.sh was recently
> > deprecated without a user-friendly replacement. Moreover, during some
> > informal irc conversations in #oooq, some developers even mentioned the
> > plan to merge tripleo-quickstart and tripleo-ci.
> >
> > I think it would be beneficial to create a set of defaults for
> tripleo-quickstart
> > that can be used to spin up new environments; a set of defaults for
> humans.
> > This can either be a well-maintained script in tripleo-quickstart
> itself, or a
> > brand new project, e.g.
> > tripleo-quickstart-humans.  The number of settings, knobs, and flags
> should
> > be kept to a minimum.
> >
> > This would accomplish two goals:
> >
> > 1.  It would bring uniformity to the team.  Each environment is
> > installed the same way.  When something goes wrong, we can
> > eliminate differences in setup when debugging.  This should save a
> > lot of time.
> >
> > 2.  Quicker and more reliable environment setup.  If the set of defaults
> > is used by many people, it should container fewer bugs because more
> > people using something should translate into more bug reports, and
> > more bug fixes.
> >
> > These thoughts are coming from the context of tripleo-ui development.  I
> > need an environment in order to develop, but I don't necessarily always
> care
> > about how it's installed.  I want something that works for most
> scenarios.
> >
> > What do you think?  Does this make sense?  Does something like this
> already
> > exist?
> >
> > Thanks for listening!
> >
> > Honza
>
> What is the recommended way to bring up a small POC of TripleO outside of
> CI?
>
> Documentation suggests using quickstart
>
>
> https://docs.openstack.org/tripleo-docs/latest/install/introduction/architecture.html
>
> "For development or proof of concept (PoC) environments, Quickstart can
> also be used."
>
> Quickstart.sh outside of CI has been broken for a while.
> It requires zuul cloner to work.
>
> https://bugs.launchpad.net/tripleo/+bug/1754498
>
>
The issue described in bug [1] was caused by pip requirement install errors
being swallowed up and not written to the console.
TripleO-QuickStart-Extras was not pip installed due to previous errors, and
that would cause quickstart-extras.yml to not be installed.

The root cause of the failures is that pip install dependencies are not
working as expected or in the same way without a http proxy  server.  This
bug [1] should be closed, a RFE bug to ensure things work w/ a http proxy
server should be opened.

Please let me know if your work proves otherwise.
Thank you!

[1] https://bugs.launchpad.net/tripleo/+bug/1754498





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

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
OpenStack Development Mailing 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] [E] [tripleo] quickstart for humans

[Gordon, Kent]

> -Original Message-
> From: Honza Pokorny [mailto:ho...@redhat.com]
> Sent: Thursday, August 30, 2018 9:28 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [E] [openstack-dev] [tripleo] quickstart for humans
> 
> Hello!
> 
> Over the last few months, it seems that tripleo-quickstart has evolved into a
> CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a collection of
> feature sets.  However, it's become less useful for setting up development
> environments by humans.  For example, devmode.sh was recently
> deprecated without a user-friendly replacement. Moreover, during some
> informal irc conversations in #oooq, some developers even mentioned the
> plan to merge tripleo-quickstart and tripleo-ci.
> 
> I think it would be beneficial to create a set of defaults for 
> tripleo-quickstart
> that can be used to spin up new environments; a set of defaults for humans.
> This can either be a well-maintained script in tripleo-quickstart itself, or a
> brand new project, e.g.
> tripleo-quickstart-humans.  The number of settings, knobs, and flags should
> be kept to a minimum.
> 
> This would accomplish two goals:
> 
> 1.  It would bring uniformity to the team.  Each environment is
> installed the same way.  When something goes wrong, we can
> eliminate differences in setup when debugging.  This should save a
> lot of time.
> 
> 2.  Quicker and more reliable environment setup.  If the set of defaults
> is used by many people, it should container fewer bugs because more
> people using something should translate into more bug reports, and
> more bug fixes.
> 
> These thoughts are coming from the context of tripleo-ui development.  I
> need an environment in order to develop, but I don't necessarily always care
> about how it's installed.  I want something that works for most scenarios.
> 
> What do you think?  Does this make sense?  Does something like this already
> exist?
> 
> Thanks for listening!
> 
> Honza

What is the recommended way to bring up a small POC of TripleO outside of CI?

Documentation suggests using quickstart 

https://docs.openstack.org/tripleo-docs/latest/install/introduction/architecture.html

"For development or proof of concept (PoC) environments, Quickstart can also be 
used."

Quickstart.sh outside of CI has been broken for a while.
It requires zuul cloner to work.

https://bugs.launchpad.net/tripleo/+bug/1754498
 


__
OpenStack Development Mailing 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] [election] [tc] TC candidacy

[Samuel Cassiba]

Hello everybody,

I am announcing my candidacy to be a member of the OpenStack Technical
Committee (TC).

I have been involved in open source since I was a brash youth on the
Internet in the late 1990s, which amounts to over half my life at this
point. I am a self-taught individual, cutting my teeth on BSDs of the
period. I operated in that area for a number of years, becoming a
'shadow' maintainer under various pseudonyms. As time progressed, I
became comfortable attributing my work to my personal identity. o/

My direct involvement with OpenStack began during the Folsom release, as
an operator and deployer. I focused my efforts on automation, eventually
falling in with a crowd that likes puns and cooking references. In my
professional life, I have served as developer, operator, user, and
architect, which extends back to the birthplace of OpenStack.

I am a founding member of Chef OpenStack[0], where I have dutifully
served as PTL for five releases. My community involvement also extends
outside the OpenStack ecosystem, where I serve as a member of Sous
Chefs[1], a group dedicated to the long-term care of critical Chef
community resources.

Though my hands-on experience goes back several releases, I still view
things from the outside-looking-in perspective. Having the outsider
lens is crucial in the long-term for any consensus-driven group,
regardless of that consensus.

Regardless of the election outcome, this is me taking steps to having a
larger involvement in the overall conversations that drive so much of
our daily lives. At the end of the day, we're all just groups of people
trying to do our jobs. I view this as an opportunity to give back to a
community that has given me so much.

Thank you for your attention and consideration,
Samuel Cassiba (scas)

[0] https://docs.openstack.org/openstack-chef/latest/
[1] https://sous-chefs.org/

__
OpenStack Development Mailing 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] No weekly meeting on Thursday September 13

[melanie witt]

On Tue, 4 Sep 2018 20:36:45 -0500, Matt Riedemann wrote:

On 9/4/2018 4:13 PM, melanie witt wrote:

The next meeting will be on Thursday September 20 at 1400 UTC [1].

I'm assuming we're going to have a meeting*this*  week though, right?


Yes, sorry if I worded that in a confusing way. We have a meeting 
tomorrow September 6 at 1400 UTC, we will _not_ meet during PTG week on 
Thursday September 13, and then we resume meeting on Thursday September 
20 at 1400 UTC.


-melanie




__
OpenStack Development Mailing 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] [election] [tc] TC Candidacy

[Kristi Nikolla]

Hi all,

I’m stepping out of the comfort zone and submitting my candidacy for a seat on
the OpenStack Technical Committee.

I’m a software architect at the Mass Open Cloud[0], a collaboration between
the five major universities of the Boston area to create and operate a
public cloud based on the Open Cloud eXchange model[1]. I’ve been involved
with OpenStack for the past three years as a user, operator and developer.
My main area of focus is in identity and federation. I’m a core reviewer for
the Keystone project and the lead for MixMatch[2][3][4], which aims to enable
resource federation among multiple OpenStack deployments.

I believe my affiliation with academia and research will bring a different
voice to the technical committee from a mostly underrepresented group.
Furthermore, my experience with federation and operating a cloud with a
diverse set of offerings not limited to OpenStack, but including other
important pieces of a cloud provider’s toolbox will prove really valuable,
especially with the vision dilemmas that OpenStack is facing today.

I’m really excited to have the opportunity to take part in the discussion with
regards to the technical vision for OpenStack. Regardless of election outcome,
this is the first step towards a larger involvement from me in the important
discussions (no more shying away from the important mailing list threads.)

I have a lot yet to learn, and consider it a big privilege to be surrounded by
so many kind people who have mentored me and continue to mentor me while I
walk and stumble. I strongly believe in servant leadership, and I will devote
myself in helping the community and mentoring the next wave of OpenStack
contributors. I have found OpenStack to be one of the most welcoming online
communities, and am very proud to be a part of this big family and for a
chance to give back.

Thank you for your time and attention,
Kristi Nikolla (knikolla)

[0]. https://massopen.cloud
[1]. http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf
[2]. https://mixmatch.readthedocs.io
[3]. https://github.com/openstack/mixmatch
[4]. https://youtu.be/O0euqskJJ_8



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] quickstart for humans

[Wesley Hayutin]

On Fri, Aug 31, 2018 at 7:12 AM Steven Hardy  wrote:

> On Thu, Aug 30, 2018 at 3:28 PM, Honza Pokorny  wrote:
> > Hello!
> >
> > Over the last few months, it seems that tripleo-quickstart has evolved
> > into a CI tool.  It's primarily used by computers, and not humans.
> > tripleo-quickstart is a helpful set of ansible playbooks, and a
> > collection of feature sets.  However, it's become less useful for
> > setting up development environments by humans.  For example, devmode.sh
> > was recently deprecated without a user-friendly replacement. Moreover,
> > during some informal irc conversations in #oooq, some developers even
> > mentioned the plan to merge tripleo-quickstart and tripleo-ci.
>
> I was recently directed to the reproducer-quickstart.sh script that's
> written in the logs directory for all oooq CI jobs - does that help as
> a replacement for the previous devmode interface?
>
> Not that familiar with it myself but it seems to target many of the
> use-cases you mention e.g uniform reproducer for issues, potentially
> quicker way to replicate CI results?
>
> Steve
>
>
Thanks Honza and Steve for sharing.
Steve is correctly pointing out that reproducer scripts [1] are the
upgraded version of what was known as devmode.  There are two main goals we
are trying to achieve as a CI team with regards reproducing CI.

A.  Ensure that a developer can reproduce what is executed upstream step by
step as closely as is possible to deliver a 1:1 matching result
B.  Ensure the reliability of the local run is as close to the reliability
of the upstream check job as possible.

The older devmode scripts did a rather poor job at both A and B, where the
reproducer_script will actually execute the upstream CI workflow once an
environment is provisioned.  The results should be identical as long as
there are no yum, or other network related issues.

CI is a very opinionated realm of work, a point that Jirka makes quite
well.  We have to focus on goals that are clearly defined.  The long term
goal is make TripleO very easy to use and deploy, not just make
tripleo-quickstart easy to use.

The TripleO CI team is happy to help Honza or Jason stand up a tripleo job
against the tripleo-ui repo.  At which point you should have something
testing your changes and the scripts and tools to reproduce that job.  I
never like to see an upstream repo w/o any real CI running against it.

Thanks


[1]
https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html


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

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
OpenStack Development Mailing 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] [placement] extraction (technical) update

[Dan Smith]

> I think there was a period in time where the nova_api database was created
> where entires would try to get pulled out from the original nova database and
> then checking nova_api if it doesn't exist afterwards (or vice versa).  One
> of the cases that this was done to deal with was for things like instance 
> types
> or flavours.
>
> I don't know the exact details but I know that older instance types exist in
> the nova db and the newer ones are sitting in nova_api.  Something along
> those lines?

Yep, we've moved entire databases before in nova with minimal disruption
to the users. Not just flavors, but several pieces of data came out of
the "main" database and into the api database transparently. It's
doable, but with placement being split to a separate
project/repo/whatever, there's not really any option for being graceful
about it in this case.

> At this point, I'm thinking turn off placement, setup the new one, do
> the migration
> of the placement-specific tables (this can be a straightforward documented 
> task
> OR it would be awesome if it was a placement command (something along
> the lines of `placement-manage db import_from_nova`) which would import all
> the right things
>
> The idea of having a command would be *extremely* useful for deployment tools
> in automating the process and it also allows the placement team to selectively
> decide what they want to onboard?

Well, it's pretty cut-and-dried as all the tables in nova-api are either
for nova or placement, so there's not much confusion about what belongs.

I'm not sure that doing this import in python is really the most
efficient way. I agree a placement-manage command would be ideal from an
"easy button" point of view, but I think a couple lines of bash that
call mysqldump are likely to vastly outperform us doing it natively in
python. We could script exec()s of those commands from python, but.. I
think I'd rather just see that as a shell script that people can easily
alter/test on their own.

Just curious, but in your case would the service catalog entry change at
all? If you stand up the new placement in the exact same spot, it
shouldn't, but I imagine some people will have the catalog entry change
slightly (even if just because of a VIP or port change). Am I
remembering correctly that the catalog can get cached in various places
such that much of nova would need a restart to notice?

--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] [all]-ish : Updates required for readthedocs publishers

[Dmitry Tantsur]

On 09/05/2018 06:10 PM, Doug Hellmann wrote:

Excerpts from Ian Wienand's message of 2018-09-05 18:53:10 +1000:

Hello,

If you're interested in the projects mentioned below, you may have
noticed a new, failing, non-voting job
"your-readthedocs-job-requires-attention".  Spoiler alert: your
readthedocs job requires attention.  It's easy to miss because
publishing happens in the post pipeline and people don't often look
at the results of these jobs.

Please see the prior email on this

  http://lists.openstack.org/pipermail/openstack-dev/2018-August/132836.html


Those instructions and the ones linked at
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
say to "generate a web hook URL". RTD offers me 4 types of webhooks
(github, bitbucket, gitlab, generic). Which type do we need for our
CI? "generic"?


The generic one.



What is the "ID" of the webhook? The number at the end of the URL, or
the token associated with it?


The number, like here: 
https://github.com/openstack/metalsmith/blob/master/.zuul.yaml#L157




Doug



for what to do (if you read the failing job logs, it also points you
to this).

I (or #openstack-infra) can help, but only once the openstackci user
is given permissions to the RTD project by its current owner.

Thanks,

-i

The following projects have this job now:

openstack-infra/gear
openstack/airship-armada
openstack/almanach
openstack/ansible-role-bindep
openstack/ansible-role-cloud-launcher
openstack/ansible-role-diskimage-builder
openstack/ansible-role-cloud-fedmsg
openstack/ansible-role-cloud-gearman
openstack/ansible-role-jenkins-job-builder
openstack/ansible-role-logrotate
openstack/ansible-role-ngix
openstack/ansible-role-nodepool
openstack/ansible-role-openstacksdk
openstack/ansible-role-shade
openstack/ansible-role-ssh
openstack/ansible-role-sudoers
openstack/ansible-role-virtualenv
openstack/ansible-role-zookeeper
openstack/ansible-role-zuul
openstack/ara
openstack/bareon
openstack/bareon-allocator
openstack/bareon-api
openstack/bareon-ironic
openstack/browbeat
openstack/downpour
openstack/fuel-ccp
openstack/fuel-ccp-installer
openstack/fuel-noop-fixtures
openstack/ironic-staging-drivers
openstack/k8s-docker-suite-app-murano
openstack/kloudbuster
openstack/nerd-reviewer
openstack/networking-dpm
openstack/nova-dpm
openstack/ooi
openstack/os-faults
openstack/packetary
openstack/packetary-specs
openstack/performa
openstack/poppy
openstack/python-almanachclient
openstack/python-jenkins
openstack/rally
openstack/solar
openstack/sqlalchemy-migrate
openstack/stackalytics
openstack/surveil
openstack/swauth
openstack/turbo-hipster
openstack/virtualpdu
openstack/vmtp
openstack/windmill
openstack/yaql



__
OpenStack Development Mailing 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] [all]-ish : Updates required for readthedocs publishers

[Doug Hellmann]

Excerpts from Ian Wienand's message of 2018-09-05 18:53:10 +1000:
> Hello,
> 
> If you're interested in the projects mentioned below, you may have
> noticed a new, failing, non-voting job
> "your-readthedocs-job-requires-attention".  Spoiler alert: your
> readthedocs job requires attention.  It's easy to miss because
> publishing happens in the post pipeline and people don't often look
> at the results of these jobs.
> 
> Please see the prior email on this
> 
>  http://lists.openstack.org/pipermail/openstack-dev/2018-August/132836.html

Those instructions and the ones linked at
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
say to "generate a web hook URL". RTD offers me 4 types of webhooks
(github, bitbucket, gitlab, generic). Which type do we need for our
CI? "generic"?

What is the "ID" of the webhook? The number at the end of the URL, or
the token associated with it?

Doug

> 
> for what to do (if you read the failing job logs, it also points you
> to this).
> 
> I (or #openstack-infra) can help, but only once the openstackci user
> is given permissions to the RTD project by its current owner.
> 
> Thanks,
> 
> -i
> 
> The following projects have this job now:
> 
> openstack-infra/gear
> openstack/airship-armada
> openstack/almanach
> openstack/ansible-role-bindep
> openstack/ansible-role-cloud-launcher
> openstack/ansible-role-diskimage-builder
> openstack/ansible-role-cloud-fedmsg
> openstack/ansible-role-cloud-gearman
> openstack/ansible-role-jenkins-job-builder
> openstack/ansible-role-logrotate
> openstack/ansible-role-ngix
> openstack/ansible-role-nodepool
> openstack/ansible-role-openstacksdk
> openstack/ansible-role-shade
> openstack/ansible-role-ssh
> openstack/ansible-role-sudoers
> openstack/ansible-role-virtualenv
> openstack/ansible-role-zookeeper
> openstack/ansible-role-zuul
> openstack/ara
> openstack/bareon
> openstack/bareon-allocator
> openstack/bareon-api
> openstack/bareon-ironic
> openstack/browbeat
> openstack/downpour
> openstack/fuel-ccp
> openstack/fuel-ccp-installer
> openstack/fuel-noop-fixtures
> openstack/ironic-staging-drivers
> openstack/k8s-docker-suite-app-murano
> openstack/kloudbuster
> openstack/nerd-reviewer
> openstack/networking-dpm
> openstack/nova-dpm
> openstack/ooi
> openstack/os-faults
> openstack/packetary
> openstack/packetary-specs
> openstack/performa
> openstack/poppy
> openstack/python-almanachclient
> openstack/python-jenkins
> openstack/rally
> openstack/solar
> openstack/sqlalchemy-migrate
> openstack/stackalytics
> openstack/surveil
> openstack/swauth
> openstack/turbo-hipster
> openstack/virtualpdu
> openstack/vmtp
> openstack/windmill
> openstack/yaql
> 

__
OpenStack Development Mailing 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] [election] [tc] thank you

[Amy Marrich]

Emilien,

Thank you so much for all you've done as part of the TC and continue todo
within the community!

Amy (spotz)

On Wed, Sep 5, 2018 at 8:03 AM, Anita Kuno  wrote:

> On 2018-09-05 04:01 AM, Thierry Carrez wrote:
>
>> Emilien Macchi wrote:
>>
>
> I personally feel like some rotation needs to happen
>>>
>>
> A very honourable sentiment, Emilien. I'm so grateful to have spent time
> working with your very generous spirit.
>
> To more such work in the future, Anita
>
>
>
> __
> OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Matthew Thode]

On 18-09-05 17:50:59, thomas.mo...@orange.com wrote:
> Mathew,
> 
> networking-odl has now been removed from the requirements of
> networking-bgpvpn [1], on master, so networking-odl could be removed from
> requirements.
> 
> This is not the case on stable branches, though.
> 
> -Thomas
> 
> [1] https://review.openstack.org/#/c/599422/
> 
> On 05/09/2018 17:03, Matthew Thode wrote:
> > On 18-08-31 19:52:09, Matthew Thode wrote:
> > > The requirements project has a co-installability test for the various
> > > projects, networking-odl being included.
> > > 
> > > Because of the way the dependancy on ceilometer is done it is blocking
> > > all reviews and updates to the requirements project.
> > > 
> > > http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
> > > 
> > > If networking-odl is not meant to be used as a library I'd recommend
> > > it's removal from networking-bgpvpn (it's test-requirements.txt file).
> > > Once that is done networking-odl can be removed from global-requirements
> > > and we won't be blocked anymore.
> > > 
> > > As a side note, fungi noticed that when you branched you are still
> > > installing ceilometer from master.  Also, the ceilometer team
> > > doesnt wish it to be used as a library either (like networking-odl
> > > doesn't wish to be used as a library).
> > > 
> > The requirements team has gone ahead and made a aweful hack to get gate
> > unwedged.  The commit message is a very good summary of our reasoning
> > why it has to be this way for now.  My comment explains our plan going
> > forward (there will be a revert prepared as soon as this merges for
> > instance).
> > 
> > step 1. merge this
> > step 2. look into and possibly fix our tooling (why was the gitref addition 
> > not rejected by gate)
> > step 3. fix networking-odl (release ceilometer)
> > step 4. unmerge this
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

Yep, we discussed doing that (and it's still an option).  We decided to
do something a bit more verbose though and have a plan.  Just need to
get ceilometer to release to pypi...

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] better name for placement

[Jay Pipes]

On 09/05/2018 11:48 AM, Jeremy Stanley wrote:

On 2018-09-05 17:01:49 +0200 (+0200), Thomas Goirand wrote:
[...]

In a distro, no 2 package can hold the same file. That's
forbidden. This has nothing to do if someone has to "import
placemement" or not.

Just saying this, but *not* that we should rename (I didn't spot
any conflict yet and I understand the pain it would induce). This
command returns nothing:

apt-file search placement | grep python3/dist-packages/placement


Well, also since the Placement maintainers have expressed that they
aren't interested in making Python API contracts for it to be usable
as an importable library, there's probably no need to install its
modules into the global Python search path anyway. They could just
go into a private module path on the filesystem instead as long as
the placement service/entrypoint wrapper knows where to find them,
right?


Yep.

-jay

__
OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[thomas.morin]

Mathew,

networking-odl has now been removed from the requirements of 
networking-bgpvpn [1], on master, so networking-odl could be removed 
from requirements.


This is not the case on stable branches, though.

-Thomas

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

On 05/09/2018 17:03, Matthew Thode wrote:

On 18-08-31 19:52:09, Matthew Thode wrote:

The requirements project has a co-installability test for the various
projects, networking-odl being included.

Because of the way the dependancy on ceilometer is done it is blocking
all reviews and updates to the requirements project.

http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505

If networking-odl is not meant to be used as a library I'd recommend
it's removal from networking-bgpvpn (it's test-requirements.txt file).
Once that is done networking-odl can be removed from global-requirements
and we won't be blocked anymore.

As a side note, fungi noticed that when you branched you are still
installing ceilometer from master.  Also, the ceilometer team
doesnt wish it to be used as a library either (like networking-odl
doesn't wish to be used as a library).


The requirements team has gone ahead and made a aweful hack to get gate
unwedged.  The commit message is a very good summary of our reasoning
why it has to be this way for now.  My comment explains our plan going
forward (there will be a revert prepared as soon as this merges for
instance).

step 1. merge this
step 2. look into and possibly fix our tooling (why was the gitref addition not 
rejected by gate)
step 3. fix networking-odl (release ceilometer)
step 4. unmerge this


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


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
OpenStack Development Mailing 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] better name for placement

[Jeremy Stanley]

On 2018-09-05 17:01:49 +0200 (+0200), Thomas Goirand wrote:
[...]
> In a distro, no 2 package can hold the same file. That's
> forbidden. This has nothing to do if someone has to "import
> placemement" or not.
> 
> Just saying this, but *not* that we should rename (I didn't spot
> any conflict yet and I understand the pain it would induce). This
> command returns nothing:
> 
> apt-file search placement | grep python3/dist-packages/placement

Well, also since the Placement maintainers have expressed that they
aren't interested in making Python API contracts for it to be usable
as an importable library, there's probably no need to install its
modules into the global Python search path anyway. They could just
go into a private module path on the filesystem instead as long as
the placement service/entrypoint wrapper knows where to find them,
right?
-- 
Jeremy Stanley


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] [nova] [placement] extraction (technical) update

[Matt Riedemann]

On 9/5/2018 10:03 AM, Mohammed Naser wrote:

On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann  wrote:

On 9/5/2018 8:47 AM, Mohammed Naser wrote:

Could placement not do what happened for a while when the nova_api
database was created?

Can you be more specific? I'm having a brain fart here and not
remembering what you are referring to with respect to the nova_api DB.

I think there was a period in time where the nova_api database was created
where entires would try to get pulled out from the original nova database and
then checking nova_api if it doesn't exist afterwards (or vice versa).  One
of the cases that this was done to deal with was for things like instance types
or flavours.

I don't know the exact details but I know that older instance types exist in
the nova db and the newer ones are sitting in nova_api.  Something along
those lines?


Yeah that more about supporting online data migrations *within* nova 
where new records were created in the API DB and old records would be 
looked up in both the API DB and then if not found there, in the cell 
(traditional nova DB). But you'd also be running the "nova-manage db 
online_data_migrations" CLI to force the migration of the records from 
the cell DB to the API DB.


With Placement split out of nova, we can't really do that. You could 
point placement at the nova_api DB so it can pull existing records, but 
it would continue to create new records in the nova_api DB rather than 
the placement DB and at some point you have to make that data migration.
Maybe you were thinking something like have temporary fallback code in 
placement such that if a record isn't found in the placement database, 
it queries a configured nova_api database? That'd be a ton of work at 
this point, and if it was something we were going to do, we should have 
agreed on that in YVR several months ago, definitely pre-extraction.





I say this because I know that moving the database is a huge task for
us, considering how big it can be in certain cases for us, and it
means control plane outage too

I'm pretty sure you were in the room in YVR when we talked about how
operators were going to do the database migration and were mostly OK
with what was discussed, which was a lot will just copy and take the
downtime (I think CERN said around 10 minutes for them, but they aren't
a public cloud either), but others might do something more sophisticated
and nova shouldn't try to pick the best fit for all.

If we're provided the list of tables used by placement, we could considerably
make the downtime smaller because we don't have to pull in the other huge
tables like instances/build requests/etc


There are no instances records in the API DB, maybe you mean 
instance_mappings? But yes I get the point.




What happens if things like server deletes happen while the placement service
is down?


The DELETE /allocations/{consumer_id} requests from nova to placement 
will fail with some keystoneauth1 exception, but because of our old 
friend @safe_connect we likely won't fail the server delete because we 
squash the exception from KSA:


https://github.com/openstack/nova/blob/0f102089dd0b27c7d35f0cbba87332414032c0a4/nova/scheduler/client/report.py#L2069

However, you'd still have allocations in placement against resource 
providers (compute nodes) for instances that no longer exist, which 
means you're available capacity for scheduling new requests is 
diminished until those bogus allocations are purged from placement, 
which will take some scripting.


In other words, not good things.




I'm definitely interested in what you do plan to do for the database
migration to minimize downtime.

At this point, I'm thinking turn off placement, setup the new one, do
the migration
of the placement-specific tables (this can be a straightforward documented task
OR it would be awesome if it was a placement command (something along
the lines of `placement-manage db import_from_nova`) which would import all
the right things


You wouldn't also stop nova-api while doing this? Otherwise you're going 
to get into the data/resource tracking mess described above which will 
require some post-migration cleanup scripting.




The idea of having a command would be*extremely*  useful for deployment tools
in automating the process and it also allows the placement team to selectively
decide what they want to onboard?

Just throwing ideas here.




--

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

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Rico Lin]

On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
wrote:

Since Queens, Glance has had a 'web-download' import method that takes a
> URL [0].  It's enabled by default, but operators do have the ability to
> turn it off.  (There's an API call to see what methods are enabled in a
> particular cloud.)  Operators also have the ability to restrict what URLs
> are acceptable [1], but that's probably a good thing.
>
> In short, Glance does have the ability to do what you need since Queens,
> but there's no guarantee that it will be available in all clouds and for
> all URLs.  If you foresee that as a problem, it would be a good idea to get
> together with the Glance team at the PTG to discuss this issue.  Please add
> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>
Cool! Thank Brian.
Sounds like something we can use, just one small question in my mind. In
order to use `web-download` in image resource, we need to create an empty
image than use import to upload that imge. I have try that scenrio by
myself now (I'm not really diving into detail yet) by:
1. create an empty image(like `openstack image create --container-format
bare --disk-format qcow2 img_name`)
2. and than import image  (like `glance image-import --import-method
web-download --uri
https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
But that image stuck in queued after first step.
dose this scenario supported by glance? Or where did I do wrong?


>
> [0]
> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
> [1]
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] [placement] extraction (technical) update

[Mohammed Naser]

On Wed, Sep 5, 2018 at 10:57 AM Matt Riedemann  wrote:
>
> On 9/5/2018 8:47 AM, Mohammed Naser wrote:
> > Could placement not do what happened for a while when the nova_api
> > database was created?
>
> Can you be more specific? I'm having a brain fart here and not
> remembering what you are referring to with respect to the nova_api DB.

I think there was a period in time where the nova_api database was created
where entires would try to get pulled out from the original nova database and
then checking nova_api if it doesn't exist afterwards (or vice versa).  One
of the cases that this was done to deal with was for things like instance types
or flavours.

I don't know the exact details but I know that older instance types exist in
the nova db and the newer ones are sitting in nova_api.  Something along
those lines?

> >
> > I say this because I know that moving the database is a huge task for
> > us, considering how big it can be in certain cases for us, and it
> > means control plane outage too
>
> I'm pretty sure you were in the room in YVR when we talked about how
> operators were going to do the database migration and were mostly OK
> with what was discussed, which was a lot will just copy and take the
> downtime (I think CERN said around 10 minutes for them, but they aren't
> a public cloud either), but others might do something more sophisticated
> and nova shouldn't try to pick the best fit for all.

If we're provided the list of tables used by placement, we could considerably
make the downtime smaller because we don't have to pull in the other huge
tables like instances/build requests/etc

What happens if things like server deletes happen while the placement service
is down?

> I'm definitely interested in what you do plan to do for the database
> migration to minimize downtime.

At this point, I'm thinking turn off placement, setup the new one, do
the migration
of the placement-specific tables (this can be a straightforward documented task
OR it would be awesome if it was a placement command (something along
the lines of `placement-manage db import_from_nova`) which would import all
the right things

The idea of having a command would be *extremely* useful for deployment tools
in automating the process and it also allows the placement team to selectively
decide what they want to onboard?

Just throwing ideas here.

> +openstack-operators ML since this is an operators discussion now.
>
> --
>
> Thanks,
>
> Matt



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [election] [tc] thank you

[Anita Kuno]

On 2018-09-05 04:01 AM, Thierry Carrez wrote:

Emilien Macchi wrote:



I personally feel like some rotation needs to happen


A very honourable sentiment, Emilien. I'm so grateful to have spent time 
working with your very generous spirit.


To more such work in the future, Anita


__
OpenStack Development Mailing 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Matthew Thode]

On 18-08-31 19:52:09, Matthew Thode wrote:
> The requirements project has a co-installability test for the various
> projects, networking-odl being included.
> 
> Because of the way the dependancy on ceilometer is done it is blocking
> all reviews and updates to the requirements project.
> 
> http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505
> 
> If networking-odl is not meant to be used as a library I'd recommend
> it's removal from networking-bgpvpn (it's test-requirements.txt file).
> Once that is done networking-odl can be removed from global-requirements
> and we won't be blocked anymore.
> 
> As a side note, fungi noticed that when you branched you are still
> installing ceilometer from master.  Also, the ceilometer team
> doesnt wish it to be used as a library either (like networking-odl
> doesn't wish to be used as a library).
> 

The requirements team has gone ahead and made a aweful hack to get gate
unwedged.  The commit message is a very good summary of our reasoning
why it has to be this way for now.  My comment explains our plan going
forward (there will be a revert prepared as soon as this merges for
instance).

step 1. merge this
step 2. look into and possibly fix our tooling (why was the gitref addition not 
rejected by gate)
step 3. fix networking-odl (release ceilometer)
step 4. unmerge this

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] better name for placement

[Thomas Goirand]

On 09/04/2018 06:25 PM, Jay Pipes wrote:
> On 09/04/2018 12:17 PM, Doug Hellmann wrote:
>> Excerpts from Jay Pipes's message of 2018-09-04 12:08:41 -0400:
>>> On 09/04/2018 11:44 AM, Doug Hellmann wrote:
 Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
> On Tue, 4 Sep 2018, Jay Pipes wrote:
>
>> Is there a reason we couldn't have openstack-placement be the
>> package name?
>
> I would hope we'd be able to do that, and probably should do that.
> 'openstack-placement' seems a find pypi package name for a think
> from which you do 'import placement' to do some openstack stuff,
> yeah?

 That's still a pretty generic name for the top-level import, but I
 think
 the only real risk is that the placement service couldn't be installed
 at the same time as another package owned by someone else that used
 that
 top-level name. I'm not sure how much of a risk that really is.
>>>
>>> You mean if there was another Python package that used the package name
>>> "placement"?
>>>
>>> The alternative would be to make the top-level package something like
>>> os_placement instead?
> 
> Either one works for me. Though I'm pretty sure that it isn't necessary.
> The reason it isn't necessary is because the stuff in the top-level
> placement package isn't meant to be imported by anything at all.

In a distro, no 2 package can hold the same file. That's forbidden. This
has nothing to do if someone has to "import placemement" or not.

Just saying this, but *not* that we should rename (I didn't spot any
conflict yet and I understand the pain it would induce). This command
returns nothing:

apt-file search placement | grep python3/dist-packages/placement

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing 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] [placement] extraction (technical) update

[Matt Riedemann]

On 9/5/2018 8:47 AM, Mohammed Naser wrote:

Could placement not do what happened for a while when the nova_api
database was created?


Can you be more specific? I'm having a brain fart here and not 
remembering what you are referring to with respect to the nova_api DB.




I say this because I know that moving the database is a huge task for
us, considering how big it can be in certain cases for us, and it
means control plane outage too


I'm pretty sure you were in the room in YVR when we talked about how 
operators were going to do the database migration and were mostly OK 
with what was discussed, which was a lot will just copy and take the 
downtime (I think CERN said around 10 minutes for them, but they aren't 
a public cloud either), but others might do something more sophisticated 
and nova shouldn't try to pick the best fit for all.


I'm definitely interested in what you do plan to do for the database 
migration to minimize downtime.


+openstack-operators ML since this is an operators discussion now.

--

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

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

[Mohammed Naser]

Hi Andy:

I made a metal note of replying to this but I never got a chance to :(

It was great working with you, you're always welcome back anytime! :)

Thanks,
Mohammed


On Mon, Sep 3, 2018 at 3:32 AM Hugh Saunders  wrote:
>
> Thanks for all your hard work on OSA Andy :)
>
> On Thu, 30 Aug 2018 at 18:41 Andy McCrae  wrote:
>>
>> Now that Rocky is all but ready it seems like a good time! Since changing 
>> roles I've not been able to keep up enough focus on reviews and other 
>> obligations - so I think it's time to step aside as a core reviewer.
>>
>> I want to say thanks to everybody in the community, I'm really proud to see 
>> the work we've done and how the OSA team has grown. I've learned a tonne 
>> from all of you - it's definitely been a great experience.
>>
>> Thanks,
>> Andy
>> __
>> OpenStack Development Mailing 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



--
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Sylvain Bauza]

On Wed, Sep 5, 2018 at 3:56 PM, Matt Riedemann  wrote:

> On 9/5/2018 8:39 AM, Dan Smith wrote:
>
>> Why not?
>>
>
> Because of the versions table as noted earlier. Up until this point no one
> had mentioned that but it would be an issue.
>
>
>> I think the safest/cleanest thing to do here is renumber placement-related
>> migrations from 1, and provide a script or procedure to dump just the
>> placement-related tables from the nova_api database to the new one (not
>> including the sqlalchemy-migrate versions table).
>>
>
> I'm OK with squashing/trimming/resetting the version to 1. What was not
> mentioned earlier in this thread was (1) an acknowledgement that we'd need
> to drop the versions table to reset the version in the new database and (2)
> any ideas about providing scripts to help with the DB migration.
>
> I think it's safe too. Operators could just migrate the tables by using a
read-only slave connection to a new DB and then using this script that
would drop the non-needed tables.
For people wanting to migrate tables, I think having placement versions
being different is not a problem given the tables are the same.

-Sylvain

-- 
>
> 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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Matt Riedemann]

On 9/5/2018 8:39 AM, Dan Smith wrote:

Why not?


Because of the versions table as noted earlier. Up until this point no 
one had mentioned that but it would be an issue.




I think the safest/cleanest thing to do here is renumber placement-related
migrations from 1, and provide a script or procedure to dump just the
placement-related tables from the nova_api database to the new one (not
including the sqlalchemy-migrate versions table).


I'm OK with squashing/trimming/resetting the version to 1. What was not 
mentioned earlier in this thread was (1) an acknowledgement that we'd 
need to drop the versions table to reset the version in the new database 
and (2) any ideas about providing scripts to help with the DB migration.


--

Thanks,

Matt

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

[openstack-dev] [api] microversion-parse core updates

[Chris Dent]

After some discussion with other cores I've made some adjustments to
the core team on microversion-parse [1]

* added dtantsur (welcome!)
* removed sdague

In case you're not aware, microversion-parse is middleware and
utilities for managing microversions in openstack service apis.

[1] https://pypi.org/project/microversion_parse/
http://git.openstack.org/cgit/openstack/microversion-parse

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [placement] extraction (technical) update

[Mohammed Naser]

Could placement not do what happened for a while when the nova_api
database was created?

I say this because I know that moving the database is a huge task for
us, considering how big it can be in certain cases for us, and it
means control plane outage too
On Wed, Sep 5, 2018 at 9:39 AM Dan Smith  wrote:
>
> >> Yes, we should definitely trim the placement DB migrations to only
> >> things relevant to placement. And we can use this opportunity to get
> >> rid of cruft too and squash all of the placement migrations together
> >> to start at migration 1 for the placement repo. If anyone can think
> >> of a problem with doing that, please shout it out.
>
> I agree, FWIW.
>
> > Umm, nova-manage db sync creates entries in a sqlalchemy-migrate
> > versions table, something like that, to track per database what the
> > latest migration sync version has been.
> >
> > Based on that, and the fact I thought our DB extraction policy was to
> > mostly tell operators to copy the nova_api database and throw it
> > elsewhere in a placement database, then the migrate versions table is
> > going to be saying you're at 061 and you can't start new migrations
> > from 1 at that point, unless you wipe out that versions table after
> > you copy the API DB.
>
> They can do this, sure. However, either we'll need migrations to delete
> all the nova-api-related tables, or they will need to trim them
> manually. If we do the former, then everyone who ever installs placement
> from scratch will go through the early history of nova-api only to have
> that removed. Or we trim those off the front, but we have to keep the
> collapsing migrations until we compact again, etc.
>
> The thing I'm more worried about is operators being surprised by this
> change (since it's happening suddenly in the middle of a release),
> noticing some split, and then realizing that if they just point the
> placement db connection at nova_api everything seems to work. That's
> going to go really bad when things start to diverge.
>
> > I could be wrong, but just copying the database, squashing/trimming
> > the migration scripts and resetting the version to 1, and assuming
> > things are going to be hunky dory doesn't sound like it will work to
> > me.
>
> Why not?
>
> I think the safest/cleanest thing to do here is renumber placement-related
> migrations from 1, and provide a script or procedure to dump just the
> placement-related tables from the nova_api database to the new one (not
> including the sqlalchemy-migrate versions table).
>
> --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



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [openstack-dev] [election] [tc] thank you

[Doug Hellmann]

Excerpts from Emilien Macchi's message of 2018-09-04 22:11:41 -0400:
> After 2 years at the TC, I feel lucky enough to have been part of this
> group where I hope that my modest contributions helped to make OpenStack a
> bit better.
> I've learnt so many things and worked with a talented group where it's not
> easy every day, but we have made and will continue to progress in the
> future.
> I personally feel like some rotation needs to happen, therefore I won't run
> the current election.
> 
> I don't plan to leave or anything, I just wanted to say "merci" to the
> community who gave me a chance to be part of this team.

Thank you, Emilien. I've always appreciated having your perspective
and assistance on the TC.

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

[openstack-dev] [sahara] No meeting on Sep 6th and Sep 13th

[Telles Nobrega]

Hi folks,

as we approach the PTG and we will have enough time to talk over problems
face to face I'm canceling our team meeting this week and next week as well.

See you in Denver.
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing 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] [placement] extraction (technical) update

[Dan Smith]

>> Yes, we should definitely trim the placement DB migrations to only
>> things relevant to placement. And we can use this opportunity to get
>> rid of cruft too and squash all of the placement migrations together
>> to start at migration 1 for the placement repo. If anyone can think
>> of a problem with doing that, please shout it out.

I agree, FWIW.

> Umm, nova-manage db sync creates entries in a sqlalchemy-migrate
> versions table, something like that, to track per database what the
> latest migration sync version has been.
>
> Based on that, and the fact I thought our DB extraction policy was to
> mostly tell operators to copy the nova_api database and throw it
> elsewhere in a placement database, then the migrate versions table is
> going to be saying you're at 061 and you can't start new migrations
> from 1 at that point, unless you wipe out that versions table after
> you copy the API DB.

They can do this, sure. However, either we'll need migrations to delete
all the nova-api-related tables, or they will need to trim them
manually. If we do the former, then everyone who ever installs placement
from scratch will go through the early history of nova-api only to have
that removed. Or we trim those off the front, but we have to keep the
collapsing migrations until we compact again, etc.

The thing I'm more worried about is operators being surprised by this
change (since it's happening suddenly in the middle of a release),
noticing some split, and then realizing that if they just point the
placement db connection at nova_api everything seems to work. That's
going to go really bad when things start to diverge.

> I could be wrong, but just copying the database, squashing/trimming
> the migration scripts and resetting the version to 1, and assuming
> things are going to be hunky dory doesn't sound like it will work to
> me.

Why not?

I think the safest/cleanest thing to do here is renumber placement-related
migrations from 1, and provide a script or procedure to dump just the
placement-related tables from the nova_api database to the new one (not
including the sqlalchemy-migrate versions table).

--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-dev] kolla 7.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/kolla/

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

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

https://git.openstack.org/cgit/openstack/kolla/log/?h=stable/rocky

Release notes for kolla can be found at:

https://docs.openstack.org/releasenotes/kolla/




__
OpenStack Development Mailing 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][cinder] about unified limits

[Lance Bragstad]

Not yet. Keystone worked through a bunch of usability improvements with the
unified limits API last release and created the oslo.limit library. We have
a patch or two left to land in oslo.limit before projects can really start
using unified limits [0].

We're hoping to get this working with at least one resource in another
service (nova, cinder, etc...) in Stein.

[0]
https://review.openstack.org/#/q/status:open+project:openstack/oslo.limit+branch:master+topic:limit_init

On Wed, Sep 5, 2018 at 5:20 AM Jaze Lee  wrote:

> Hello,
> Does nova and cinder  use keystone's unified limits api to do quota
> job?
> If not, is there a plan to do this?
> 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] [election] [tc] thank you

[Jeremy Stanley]

On 2018-09-04 22:11:41 -0400 (-0400), Emilien Macchi wrote:
> After 2 years at the TC, I feel lucky enough to have been part of this
> group where I hope that my modest contributions helped to make OpenStack a
> bit better.
[...]

I think they have. I've always valued your input, and hope you
continue providing it whether or not you're serving on the TC.
Thanks, really!
-- 
Jeremy Stanley


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] [heat][glance] Heat image resource support issue

[Brian Rosmaita]

On Thu, Aug 30, 2018 at 5:55 AM Rico Lin  wrote:

> Hi Glance team
>

Hi Rico, sorry about the delay in answering your email.


> Glance V1 image API been deprecated for a long while, and V2 has been used
> widely. Heat image resource would like to change to use V2 as well, but
> there is an unsolved issue, which blocks us from adopting V2. Right now, to
> image create require Heat to download the image to Heat service and
> re-upload it to Glance. This behavior causes heat service a great burden
> which in a heat team discussion (years ago), we decide to deprecated V1
> Image resource in Heat and will add V2  image resource once this is
> resolved.
> So I have been wondering if there's some workaround for this issue? Or if
> glance can support accept URL as image import (and then reuse client lib
> to download to glance side)? Or if anyone got a better solution for this?
>

Since Queens, Glance has had a 'web-download' import method that takes a
URL [0].  It's enabled by default, but operators do have the ability to
turn it off.  (There's an API call to see what methods are enabled in a
particular cloud.)  Operators also have the ability to restrict what URLs
are acceptable [1], but that's probably a good thing.

In short, Glance does have the ability to do what you need since Queens,
but there's no guarantee that it will be available in all clouds and for
all URLs.  If you foresee that as a problem, it would be a good idea to get
together with the Glance team at the PTG to discuss this issue.  Please add
it as a topic to the Glance PTG planning etherpad [3] as soon as you can.

cheers,
brian

[0]
https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
[1]
https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
[3] https://etherpad.openstack.org/p/stein-ptg-glance-planning


>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing 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] [election] [tc] thank you

[Mohammed Naser]

Émilien:

I think you’re one of the role models of our community.  Your leadership has 
helped make it easier for me to become more involved from leading a project to 
joining the TC. 

Thank you again!

Regards,
Mohammed 

Sent from my iPhone

> On Sep 4, 2018, at 10:11 PM, Emilien Macchi  wrote:
> 
> After 2 years at the TC, I feel lucky enough to have been part of this group 
> where I hope that my modest contributions helped to make OpenStack a bit 
> better.
> I've learnt so many things and worked with a talented group where it's not 
> easy every day, but we have made and will continue to progress in the future.
> I personally feel like some rotation needs to happen, therefore I won't run 
> the current election.
> 
> I don't plan to leave or anything, I just wanted to say "merci" to the 
> community who gave me a chance to be part of this team.
> -- 
> Emilien Macchi
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Retiring openstack-infra/odsreg and openstack-infra/puppet-odsreg

[Andreas Jaeger]

On 2018-09-05 09:40, Thierry Carrez wrote:
> Andreas Jaeger wrote:
>> Puppet-odsreg is unused nowadays and it seems that odsreg is unused as
>> well. I'll propose changes to retire them with topic "retire-odsreg",
> 
> So... we actually still used odsreg until recently for Forum
> submissions. The Berlin Forum is the first one where we won't use it, so
> I feel it's a bit too early to retire that codebase. If the current plan
> (which is to reuse the CFP app from the website) does not work, we'd
> certainly welcome having a plan B.
> 
> If you REALLY want it gone NOW I guess we could just push it to GitHub
> and keep it there until we are 100% sure we won't need it anymore, but
> that sounds a bit silly.
> 

OK, I'll retire puppet-odsreg only for now - please tell us once odsreg
can be retired as well,

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


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

[openstack-dev] [election][tc] TC Candidacy

[jean-philippe]

Hello everyone,

I am hereby announcing my candidacy for a position on the OpenStack Technical 
Committee (TC).

I believe that Open Source software is not only about code, but also a way to 
bring
people together in order to find a solution to business problems.

Many people find me an easy person to talk with, due to my open mindset and my 
"facilitator"
spirit.

Those qualities helped me build solutions in the past. I hope they will be 
helpful to the TC: While OpenStack is becoming more mature everyday, it is 
facing (and will face)
new challenges in terms of community, or identity.

I have been following the OpenStack ecosystem since Kilo.
I went through multiple companies and multiple hats (A cloud end-user, an 
OpenStack advocate in meetups
and at FOSDEM, a product owner of the cloud strategy, architect of a community 
cloud, a deployer,
a developer, a team lead), which gives me a unique view on OpenStack and other
adjacent communities. I am now working full time on OpenStack for SUSE,
focusing on deployment tooling.

That growing involvement inspires me to be a TC candidate. I would like to help 
shape what
the future of OpenStack could be.

Even if my experience spans quite a few cycles, I consider myself as an
OpenStack newcomer. I like to see things with fresh eyes, and I do not hesitate 
to question
the status quo. It usually gives me a different perspective to explore new 
conversations
or find new solutions.

I also think this freshness makes me very approachable to new community members,
new users, or external communities. Listening to those inputs is very important 
to me:
good software can only exist with proper requirements!

I would like to focus my time at the TC with a general simplification of 
OpenStack.
Simplification would first *reduce the barrier of entry for new contributors*,
make community goals more easily reachable, and help connecting adjacent
communities. In this matter, I consider the technical 'python3-first' project 
will open
the door to many positive improvements and simplifications, but setting up a 
good
knowledge transfer platform and best practices/recommendations for projects
could be a positive improvement.

Talking about best practices and simplification, I would like to help PTLs at
their duties, as I consider TC members should be more supportive of the day to 
day
work of the PTL and projects. I would love to see the TC as provider of 
toolkits helping
maintain and grow the community of each of the official projects.
These could be the tools that projects do not have time to develop and grow.
The code would be common to OpenStack, and therefore reducing the overall 
complexity of
projects which were carrying those tools, the same way as the Release or 
OpenStack-Infra
team are providing tools for the community.

I have a few other ideas for simplifications but instead of carrying on, I 
would prefer
hearing from you, and hearing from your ideas. So, please, contact me!

Long story short: I would like to be there to help shaping the community 
together, with your help.
Thank you for your consideration,

Jean-Philippe Evrard (evrardjp)


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

[openstack-dev] [nova][cinder] about unified limits

[Jaze Lee]

Hello,
Does nova and cinder  use keystone's unified limits api to do quota job?
If not, is there a plan to do this?
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

Re: [openstack-dev] [mistral] [release] [stable] Cherry-pick migration to stable/rocky

[Dougal Matthews]

On 5 September 2018 at 10:52, Dougal Matthews  wrote:

> (Note: I added [release] to the email subject, as I think that will make
> it visible to the right folks.)
>

Darn. It should have been [stable]. I have added that now. Sorry for the
noise.
__
OpenStack Development Mailing 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] [mistral][release] Cherry-pick migration to stable/rocky

[Dougal Matthews]

On 5 September 2018 at 10:31, Pierre Gaxatte 
wrote:

> Hello,
>
> Related change: https://review.openstack.org/#/c/599606
>
> I'd like to push this to stable/rocky because this bug affects me in
> production and I'd like to be able to upgrade to rocky to fix this. I
> understand that new migrations should not be added to a stable branch
> and Renat Akhmerov advised me to ask here to make an exception.
>
> Now for some context on this bug:
>
> The `auth_context` in `delayed_calls_v2` holds the entire catalog
> provided by the client to run actions and currently it can hold 64kB on
> mysql (JsonDictType => TEXT field).
>
> Some of our customers have a large catalog because we expose many
> regions to them and a region weighs around 5kB in our catalog (many
> services, long URL for the endpoints...).
> So above around 10 regions presented to a project the catalog cannot be
> held in the `auth_context` field and no execution can be performed in
> mistral from this project.
>
> The change fixes that simply by increasing the maximum size of the field.
>
> So I'm seeking approval from the stable branch team to merge this change.
>
> Thanks,
> Pierre
>

Thanks for sending this email.

I am happy for the change to be backported, given the Rocky release is just
out the door the changes are minimal and easy to apply. The impact is also
high enough as it resolves problems for real production environments.

We should add a release note to the backport, but I am happy for this to be
added as a follow up (before we make the next Rocky release).

(Note: I added [release] to the email subject, as I think that will make it
visible to the right folks.)

Cheers
__
OpenStack Development Mailing 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] [mistral] Cherry-pick migration to stable/rocky

[Pierre Gaxatte]

Hello,

Related change: https://review.openstack.org/#/c/599606

I'd like to push this to stable/rocky because this bug affects me in
production and I'd like to be able to upgrade to rocky to fix this. I
understand that new migrations should not be added to a stable branch
and Renat Akhmerov advised me to ask here to make an exception.

Now for some context on this bug:

The `auth_context` in `delayed_calls_v2` holds the entire catalog
provided by the client to run actions and currently it can hold 64kB on
mysql (JsonDictType => TEXT field).

Some of our customers have a large catalog because we expose many
regions to them and a region weighs around 5kB in our catalog (many
services, long URL for the endpoints...).
So above around 10 regions presented to a project the catalog cannot be
held in the `auth_context` field and no execution can be performed in
mistral from this project.

The change fixes that simply by increasing the maximum size of the field.

So I'm seeking approval from the stable branch team to merge this change.

Thanks,
Pierre

__
OpenStack Development Mailing 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]-ish : Updates required for readthedocs publishers

[Dmitry Tantsur]

On 09/05/2018 10:53 AM, Ian Wienand wrote:

Hello,

If you're interested in the projects mentioned below, you may have
noticed a new, failing, non-voting job
"your-readthedocs-job-requires-attention".  Spoiler alert: your
readthedocs job requires attention.  It's easy to miss because
publishing happens in the post pipeline and people don't often look
at the results of these jobs.

Please see the prior email on this

  http://lists.openstack.org/pipermail/openstack-dev/2018-August/132836.html

for what to do (if you read the failing job logs, it also points you
to this).

I (or #openstack-infra) can help, but only once the openstackci user
is given permissions to the RTD project by its current owner.

Thanks,

-i

The following projects have this job now:

openstack-infra/gear
openstack/airship-armada
openstack/almanach
openstack/ansible-role-bindep
openstack/ansible-role-cloud-launcher
openstack/ansible-role-diskimage-builder
openstack/ansible-role-cloud-fedmsg
openstack/ansible-role-cloud-gearman
openstack/ansible-role-jenkins-job-builder
openstack/ansible-role-logrotate
openstack/ansible-role-ngix
openstack/ansible-role-nodepool
openstack/ansible-role-openstacksdk
openstack/ansible-role-shade
openstack/ansible-role-ssh
openstack/ansible-role-sudoers
openstack/ansible-role-virtualenv
openstack/ansible-role-zookeeper
openstack/ansible-role-zuul
openstack/ara
openstack/bareon
openstack/bareon-allocator
openstack/bareon-api
openstack/bareon-ironic
openstack/browbeat
openstack/downpour
openstack/fuel-ccp
openstack/fuel-ccp-installer
openstack/fuel-noop-fixtures
openstack/ironic-staging-drivers


I'm pretty sure we updated this in Rocky. Is it here because of stable branches? 
I can propose a backport if so.



openstack/k8s-docker-suite-app-murano
openstack/kloudbuster
openstack/nerd-reviewer
openstack/networking-dpm
openstack/nova-dpm
openstack/ooi
openstack/os-faults
openstack/packetary
openstack/packetary-specs
openstack/performa
openstack/poppy
openstack/python-almanachclient
openstack/python-jenkins
openstack/rally
openstack/solar
openstack/sqlalchemy-migrate
openstack/stackalytics
openstack/surveil
openstack/swauth
openstack/turbo-hipster
openstack/virtualpdu
openstack/vmtp
openstack/windmill
openstack/yaql

__
OpenStack Development Mailing 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] [all]-ish : Updates required for readthedocs publishers

[Ian Wienand]

Hello,

If you're interested in the projects mentioned below, you may have
noticed a new, failing, non-voting job
"your-readthedocs-job-requires-attention".  Spoiler alert: your
readthedocs job requires attention.  It's easy to miss because
publishing happens in the post pipeline and people don't often look
at the results of these jobs.

Please see the prior email on this

 http://lists.openstack.org/pipermail/openstack-dev/2018-August/132836.html

for what to do (if you read the failing job logs, it also points you
to this).

I (or #openstack-infra) can help, but only once the openstackci user
is given permissions to the RTD project by its current owner.

Thanks,

-i

The following projects have this job now:

openstack-infra/gear
openstack/airship-armada
openstack/almanach
openstack/ansible-role-bindep
openstack/ansible-role-cloud-launcher
openstack/ansible-role-diskimage-builder
openstack/ansible-role-cloud-fedmsg
openstack/ansible-role-cloud-gearman
openstack/ansible-role-jenkins-job-builder
openstack/ansible-role-logrotate
openstack/ansible-role-ngix
openstack/ansible-role-nodepool
openstack/ansible-role-openstacksdk
openstack/ansible-role-shade
openstack/ansible-role-ssh
openstack/ansible-role-sudoers
openstack/ansible-role-virtualenv
openstack/ansible-role-zookeeper
openstack/ansible-role-zuul
openstack/ara
openstack/bareon
openstack/bareon-allocator
openstack/bareon-api
openstack/bareon-ironic
openstack/browbeat
openstack/downpour
openstack/fuel-ccp
openstack/fuel-ccp-installer
openstack/fuel-noop-fixtures
openstack/ironic-staging-drivers
openstack/k8s-docker-suite-app-murano
openstack/kloudbuster
openstack/nerd-reviewer
openstack/networking-dpm
openstack/nova-dpm
openstack/ooi
openstack/os-faults
openstack/packetary
openstack/packetary-specs
openstack/performa
openstack/poppy
openstack/python-almanachclient
openstack/python-jenkins
openstack/rally
openstack/solar
openstack/sqlalchemy-migrate
openstack/stackalytics
openstack/surveil
openstack/swauth
openstack/turbo-hipster
openstack/virtualpdu
openstack/vmtp
openstack/windmill
openstack/yaql

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

[openstack-dev] Neutron CI meeting on Tuesday 11.09

[Slawomir Kaplonski]

Hi,

Due to PTG in Denver CI meeting on Tuesday 11.09 is cancelled.
Next one will be at 18.09

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
OpenStack Development Mailing 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] No Neutron QoS meeting on Tuesday 11.09

[Slawomir Kaplonski]

Hi,

Due to PTG in Denver QoS meeting on Tuesday 11.09 is cancelled.
Next one will be at 25.09

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
OpenStack Development Mailing 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] [QA] [all] QA Stein PTG Planning

[Ghanshyam Mann]

Hi All,

As we are close to PTG, I have prepared the QA Stein PTG Schedule -
https://ethercalc.openstack.org/Stein-PTG-QA-Schedule 

Detail of each sessions can be found in this etherpad -
https://etherpad.openstack.org/p/qa-stein-ptg 

This time we will have QA Help Hour for 1 day only which is on Monday and next 
3 days for specific topic discussion and code sprint. 
We still have space for more sessions or topic if any of you would like to add. 
If so please write those to etherpad with your irc name.
Sessions Scheduled is flexible and we can reschedule based on request but do 
let me know before 7th Sept.

If anyone cannot travel to PTG and would like to attend remotely, do let me 
know i can plan something for remote participation. 

-gmann





__
OpenStack Development Mailing 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] [election] [tc] thank you

[Tobias Urdin]

Emilien,

You've been an inspiration to the community and to me personally!
Thanks for helping making OpenStack better in all aspects.

Best regards
Tobias

On 09/05/2018 04:15 AM, Emilien Macchi wrote:
After 2 years at the TC, I feel lucky enough to have been part of this 
group where I hope that my modest contributions helped to make 
OpenStack a bit better.
I've learnt so many things and worked with a talented group where it's 
not easy every day, but we have made and will continue to progress in 
the future.
I personally feel like some rotation needs to happen, therefore I 
won't run the current election.


I don't plan to leave or anything, I just wanted to say "merci" to the 
community who gave me a chance to be part of this team.

--
Emilien Macchi


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

Re: [openstack-dev] [election] [tc] thank you

[Thierry Carrez]

Emilien Macchi wrote:
After 2 years at the TC, I feel lucky enough to have been part of this 
group where I hope that my modest contributions helped to make OpenStack 
a bit better.
I've learnt so many things and worked with a talented group where it's 
not easy every day, but we have made and will continue to progress in 
the future.
I personally feel like some rotation needs to happen, therefore I won't 
run the current election.


I don't plan to leave or anything, I just wanted to say "merci" to the 
community who gave me a chance to be part of this team.


Thanks for your service, Emilien! Your quality input on both technical 
and social aspects of the TC activity helped us move forward over those 
past 2 years. Please consider serving again in the future!


--
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

Re: [openstack-dev] [TC][Searchlight] Searchlight project missing from the OpenStack website

[Trinh Nguyen]

Hi Thierry,

Thanks. I saw it :)


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Wed, Sep 5, 2018 at 4:51 PM Thierry Carrez  wrote:

> Trinh Nguyen wrote:
> > I'm not sure if I missed something but Searchlight is not listed in the
> > Software section of the OpenStack website [1]. Is it because Searchlight
> > has missed the Rocky cycle?
>
> Searchlight appears in "Shared services" at the bottom of:
>
>
> https://www.openstack.org/software/project-navigator/openstack-components#openstack-services
>
> Regards,
>
> --
> 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 Development Mailing 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][Searchlight] Searchlight project missing from the OpenStack website

[Thierry Carrez]

Trinh Nguyen wrote:
I'm not sure if I missed something but Searchlight is not listed in the 
Software section of the OpenStack website [1]. Is it because Searchlight 
has missed the Rocky cycle?


Searchlight appears in "Shared services" at the bottom of:

https://www.openstack.org/software/project-navigator/openstack-components#openstack-services

Regards,

--
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

Re: [openstack-dev] Retiring openstack-infra/odsreg and openstack-infra/puppet-odsreg

[Thierry Carrez]

Andreas Jaeger wrote:
Puppet-odsreg is unused nowadays and it seems that odsreg is unused as 
well. I'll propose changes to retire them with topic "retire-odsreg",


So... we actually still used odsreg until recently for Forum 
submissions. The Berlin Forum is the first one where we won't use it, so 
I feel it's a bit too early to retire that codebase. If the current plan 
(which is to reuse the CFP app from the website) does not work, we'd 
certainly welcome having a plan B.


If you REALLY want it gone NOW I guess we could just push it to GitHub 
and keep it there until we are 100% sure we won't need it anymore, but 
that sounds a bit silly.


--
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] [QA] Rocky Retrospective Etherpad

[Ghanshyam Mann]

Hi All,

I have started an etherpad for a Rocky cycle retrospective for QA -
https://etherpad.openstack.org/p/qa-rocky-retrospective

This will be discussed in PTG on Tuesday 9.30-10.00 AM, so please add your
feedback/comment before that.

Everyone is welcome to add the feedback which help us to improve the
required things in next cycle.

-gmann







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