[openstack-dev] [cinder]ceph rbd replication group support

[王俊]

Hi:
I have a question about rbd replication group, I want to know the plan or 
roadmap about it? Anybody work on it?
Blueprint: 
https://blueprints.launchpad.net/cinder/+spec/ceph-rbd-replication-group-support

Thanks


保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！

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

Re: [openstack-dev] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

[Renat Akhmerov]

Hi,


@Ken, I understand your considerations. I get that. I’m only asking not to 
remove it *for now*. And yes, if you think it should be discouraged from using 
it’s totally fine. But practically, it’s been the only reliable option for 
Mistral so far that may be our fault, I have to admit, because we weren’t able 
to make it work well with other executor types but we’ll try to fix that.

By the way, I was playing with different options yesterday and it seems like 
that setting the executor to “threading” and the “executor_thread_pool_size” 
property to 1 behaves the same way as “blocking”. So may be that’s an option 
for us too, even if “blocking” is completely removed. But I would still be in 
favour of having some extra time to prove that with thorough testing.

@Ben, including the executor via setup.cfg also looks OK to me. I see no issues 
with this approach.


Thanks

Renat Akhmerov
@Nokia
On 18 Oct 2018, 23:35 +0700, Ben Nemec , wrote:
>
>
> On 10/18/18 9:59 AM, Ken Giusti wrote:
> > Hi Renat,
> >
> > The biggest issue with the blocking executor (IMHO) is that it blocks
> > the protocol I/O while  RPC processing is in progress.  This increases
> > the likelihood that protocol processing will not get done in a timely
> > manner and things start to fail in weird ways.  These failures are
> > timing related and are typically hard to reproduce or root-cause.   This
> > isn't something we can fix as blocking is the nature of the executor.
> >
> > If we are to leave it in we'd really want to discourage its use.
>
> Since it appears the actual executor code lives in futurist, would it be
> possible to remove the entrypoint for blocking from oslo.messaging and
> have mistral just pull it in with their setup.cfg? Seems like they
> should be able to add something like:
>
> oslo.messaging.executors =
> blocking = futurist:SynchronousExecutor
>
> to their setup.cfg to keep it available to them even if we drop it from
> oslo.messaging itself. That seems like a good way to strongly discourage
> use of it while still making it available to projects that are really
> sure they want it.
>
> >
> > However I'm ok with leaving it available if the policy for using
> > blocking is 'use at your own risk', meaning that bug reports may have to
> > be marked 'won't fix' if we have reason to believe that blocking is at
> > fault.  That implies removing 'blocking' as the default executor value
> > in the API and having applications explicitly choose it.  And we keep
> > the deprecation warning.
> >
> > We could perhaps implement time duration checks around the executor
> > callout and log a warning if the executor blocked for an extended amount
> > of time (extended=TBD).
> >
> > Other opinions so we can come to a consensus?
> >
> >
> > On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov  > > wrote:
> >
> > Hi Oslo Team,
> >
> > Can we retain “blocking” executor for now in Oslo Messaging?
> >
> >
> > Some background..
> >
> > For a while we had to use Oslo Messaging with “blocking” executor in
> > Mistral because of incompatibility of MySQL driver with green
> > threads when choosing “eventlet” executor. Under certain conditions
> > we would get deadlocks between green threads. Some time ago we
> > switched to using PyMysql driver which is eventlet friendly and did
> > a number of tests that showed that we could safely switch to
> > “eventlet” executor (with that driver) so we introduced a new option
> > in Mistral where we could choose an executor in Oslo Messaging. The
> > corresponding bug is [1].
> >
> > The issue is that we recently found that not everything actually
> > works as expected when using combination PyMysql + “eventlet”
> > executor. We also tried “threading” executor and the system *seems*
> > to work with it but surprisingly performance is much worse.
> >
> > Given all of that we’d like to ask Oslo Team not to remove
> > “blocking” executor for now completely, if that’s possible. We have
> > a strong motivation to switch to “eventlet” for other reasons
> > (parallelism => better performance etc.) but seems like we need some
> > time to make it smoothly.
> >
> >
> > [1] https://bugs.launchpad.net/mistral/+bug/1696469
> >
> >
> > Thanks
> >
> > Renat Akhmerov
> > @Nokia
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > --
> > Ken Giusti  (kgiu...@gmail.com )
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailm

[openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

[Boxiang Zhu]

Hi folks,
When I use the LVM backend to create the volume, then attach it to a vm. I 
can migrate the volume(in-use) from one host to another. The nova libvirt will 
call the 'rebase' to finish it. But if using ceph backend, it raises exception 
'Swap only supports host devices'. So now it does not support to migrate 
volume(in-use). Does anyone do this work now? Or Is there any way to let me 
migrate volume(in-use) with ceph backend?


Cheers,
Boxiang

__
OpenStack Development Mailing 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] [zun][zun-ui] How to get "host" attribute for image

[Hongbin Lu]

Shu,

It looks the 'host' field was added to the DB table but not exposed via
REST API by mistake. See if this patch fixes the issue:
https://review.openstack.org/#/c/611753/ .

Best regards,
Hongbin

On Thu, Oct 18, 2018 at 10:50 PM Shu M.  wrote:

> Hi folks,
>
> I found the following commit to show "host" attribute for image.
>
>
> https://github.com/openstack/zun/commit/72eac7c8f281de64054dfa07e3f31369c5a251f0
>
> But I could not get the "host" for image with zun-show.
>
> I think image-list and image-show need to show "host" for admin, so I'd
> like to add "host" for image into zun-ui.
> Please let me know how to show "host" attribute.
> __
> OpenStack Development Mailing 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] [zun][zun-ui] How to get "host" attribute for image

[Shu M.]

Hi folks,

I found the following commit to show "host" attribute for image.

https://github.com/openstack/zun/commit/72eac7c8f281de64054dfa07e3f31369c5a251f0

But I could not get the "host" for image with zun-show.

I think image-list and image-show need to show "host" for admin, so I'd
like to add "host" for image into zun-ui.
Please let me know how to show "host" attribute.
__
OpenStack Development Mailing 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] [Searchlight] Workshop at the Korea User Group monthly meetup tonight

[Trinh Nguyen]

Hi all,

I will have a small session at the OpenStack Korea User Group monthly
meetup (October 2018) tonight. Stop by if you're around the Gangnam (Seoul,
South Korea) area :)

   - *Location:* TOZ Gangnam Tower, near to Gangnam station (near to exit
   2, https://goo.gl/maps/CVYDpgYdF5J2 or http://naver.me/5W7E2LQY)
   - *Event's detail:* https://festa.io/events/118
   - *Time*: 19:00~22:00 (UTC+9)

My session will be from 21:10 ~ 21:40 (UTC+9)

Bests,


-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
OpenStack Development Mailing 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] 答复: [senlin] Meeting cancelled for this week

[liu.xuefeng1]

ok.



原始邮件



发件人：DucTruong;
收件人：openstack-dev@lists.openstack.org;
日期：2018-10-19 01:08:18
主题：[openstack-dev] [senlin] Meeting cancelled for this week


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

Everyone,




I’m canceling the Senlin meeting this week because I’m unavailable.




We will resume at the scheduled time next week. 




Duc (dtruong)__
OpenStack Development Mailing 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] [drivers] Cancelling drivers meeting on October 19th

[Miguel Lavalle]

Dear Neutron team,

We don't have triaged RFEs to be discussed during the drivers meeting on
October 19th. So let's skip that meeting and we will resume normally on the
26th.

Best regards

Miguel
__
OpenStack Development Mailing 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-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Jim Rollenhagen]

On Thu, Oct 18, 2018 at 4:45 PM John Fulton  wrote:

> On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen 
> wrote:
> >
> > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur 
> wrote:
> >>
> >> Hi all,
> >>
> >> Sorry for chiming in really late in this topic, but I think $subj is
> worth
> >> discussing until we settle harder on the potentially confusing
> terminology.
> >>
> >> I think the difference between "Edge" and "Far Edge" is too vague to
> use these
> >> terms in practice. Think about the "edge" metaphor itself: something
> rarely has
> >> several layers of edges. A knife has an edge, there are no far edges. I
> imagine
> >> zooming in and seeing more edges at the edge, and then it's quite cool
> indeed,
> >> but is it really a useful metaphor for those who never used a strong
> microscope? :)
> >>
> >> I think in the trivial sense "Far Edge" is a tautology, and should be
> avoided.
> >> As a weak proof of my words, I already see a lot of smart people
> confusing these
> >> two and actually use Central/Edge where they mean Edge/Far Edge. I
> suggest we
> >> adopt a different terminology, even if it less consistent with typical
> marketing
> >> term around the "Edge" movement.
> >
> >
> > FWIW, we created rough definitions of "edge" and "far edge" during the
> edge WG session in Denver.
> > It's mostly based on latency to the end user, though we also talked
> about quantities of compute resources, if someone can find the pictures.
>
> Perhaps these are the pictures Jim was referring to?
>
> https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0#


That's it, thank you!

// jim


>
>
> I'm involved in some TripleO work called the split control plane:
>
> https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html
>
> After the PTG I saw that the split control plane was compatible with
> the type of deployment discussed at the edge WG session in Denver and
> described the compatibility at:
>
> https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane
>
> > See the picture and table here:
> https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview
> >
> >> Now, I don't have really great suggestions. Something that came up in
> TripleO
> >> discussions [1] is Core/Hub/Edge, which I think reflects the idea
> better.
> >
> >
> > I'm also fine with these names, as they do describe the concepts well. :)
> >
> > // jim
>
> I'm fine with these terms too. In split control plane there's a
> deployment method for deploying a central site and then deploying
> remote sites independently. That deployment method could be used to
> deploy  Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack
> N. Deploy a Hub using stack N+1 and then deploy an Edge using stack
> N+2 etc.
>
>   John
>
> >>
> >> I'd be very interested to hear your ideas.
> >>
> >> Dmitry
> >>
> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp
> >>
> >> ___
> >> openstack-sigs mailing list
> >> openstack-s...@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> >
> >
> __
> > OpenStack Development Mailing 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] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[John Fulton]

On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen  
wrote:
>
> On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur  wrote:
>>
>> Hi all,
>>
>> Sorry for chiming in really late in this topic, but I think $subj is worth
>> discussing until we settle harder on the potentially confusing terminology.
>>
>> I think the difference between "Edge" and "Far Edge" is too vague to use 
>> these
>> terms in practice. Think about the "edge" metaphor itself: something rarely 
>> has
>> several layers of edges. A knife has an edge, there are no far edges. I 
>> imagine
>> zooming in and seeing more edges at the edge, and then it's quite cool 
>> indeed,
>> but is it really a useful metaphor for those who never used a strong 
>> microscope? :)
>>
>> I think in the trivial sense "Far Edge" is a tautology, and should be 
>> avoided.
>> As a weak proof of my words, I already see a lot of smart people confusing 
>> these
>> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we
>> adopt a different terminology, even if it less consistent with typical 
>> marketing
>> term around the "Edge" movement.
>
>
> FWIW, we created rough definitions of "edge" and "far edge" during the edge 
> WG session in Denver.
> It's mostly based on latency to the end user, though we also talked about 
> quantities of compute resources, if someone can find the pictures.

Perhaps these are the pictures Jim was referring to?
 
https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0#

I'm involved in some TripleO work called the split control plane:
  
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html

After the PTG I saw that the split control plane was compatible with
the type of deployment discussed at the edge WG session in Denver and
described the compatibility at:
  
https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane

> See the picture and table here: 
> https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview
>
>> Now, I don't have really great suggestions. Something that came up in TripleO
>> discussions [1] is Core/Hub/Edge, which I think reflects the idea better.
>
>
> I'm also fine with these names, as they do describe the concepts well. :)
>
> // jim

I'm fine with these terms too. In split control plane there's a
deployment method for deploying a central site and then deploying
remote sites independently. That deployment method could be used to
deploy  Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack
N. Deploy a Hub using stack N+1 and then deploy an Edge using stack
N+2 etc.

  John

>>
>> I'd be very interested to hear your ideas.
>>
>> Dmitry
>>
>> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp
>>
>> ___
>> openstack-sigs mailing list
>> openstack-s...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
> __
> OpenStack Development Mailing 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] [Openstack-sigs] [all] Naming the T release of OpenStack

[Slawomir Kaplonski]

> Wiadomość napisana przez Remo Mattei  w dniu 18.10.2018, o godz. 
> 19:08:
> 
> Michal, that will never work it’s 11 characters long

Shorter could be Openstack Trouble ;)
> 
> 
>  
> 
>> On Oct 18, 2018, at 09:43, Eric Fried  wrote:
>> 
>> Sorry, I'm opposed to this idea.
>> 
>> I admit I don't understand the political framework, nor have I read the
>> governing documents beyond [1], but that document makes it clear that
>> this is supposed to be a community-wide vote.  Is it really legal for
>> the TC (or whoever has merge rights on [2]) to merge a patch that gives
>> that same body the power to take the decision out of the hands of the
>> community? So it's really an oligarchy that gives its constituency the
>> illusion of democracy until something comes up that it feels like not
>> having a vote on? The fact that it's something relatively "unimportant"
>> (this time) is not a comfort.
>> 
>> Not that I think the TC would necessarily move forward with [2] in the
>> face of substantial opposition from non-TC "cores" or whatever.
>> 
>> I will vote enthusiastically for "Train". But a vote it should be.
>> 
>> -efried
>> 
>> [1] https://governance.openstack.org/tc/reference/release-naming.html
>> [2] https://review.openstack.org/#/c/611511/
>> 
>> On 10/18/2018 10:52 AM, arkady.kanev...@dell.com wrote:
>>> +1 for the poll.
>>> 
>>> Let’s follow well established process.
>>> 
>>> If we want to add Train as one of the options for the name I am OK with it.
>>> 
>>>  
>>> 
>>> *From:* Jonathan Mills 
>>> *Sent:* Thursday, October 18, 2018 10:49 AM
>>> *To:* openstack-s...@lists.openstack.org
>>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
>>> 
>>>  
>>> 
>>> [EXTERNAL EMAIL]
>>> Please report any suspicious attachments, links, or requests for
>>> sensitive information.
>>> 
>>> +1 for just having a poll
>>> 
>>>  
>>> 
>>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry >> > wrote:
>>> 
>>>I'm fine with Train but I'm also fine with just adding it to the
>>>list and voting on it. It will win.
>>> 
>>> 
>>> 
>>>Also, for those not familiar with the debian/ubuntu command "sl",
>>>now is the time to become so.
>>> 
>>> 
>>> 
>>>apt install sl
>>> 
>>>sl -Flea #ftw
>>> 
>>> 
>>> 
>>>On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
>>>mailto:t...@bakeyournoodle.com>> wrote:
>>> 
>>>Hello all,
>>>As per [1] the nomination period for names for the T release
>>>have
>>>now closed (actually 3 days ago sorry).  The nominated names and any
>>>qualifying remarks can be seen at2].
>>> 
>>>Proposed Names
>>> * Tarryall
>>> * Teakettle
>>> * Teller
>>> * Telluride
>>> * Thomas
>>> * Thornton
>>> * Tiger
>>> * Tincup
>>> * Timnath
>>> * Timber
>>> * Tiny Town
>>> * Torreys
>>> * Trail
>>> * Trinidad
>>> * Treasure
>>> * Troublesome
>>> * Trussville
>>> * Turret
>>> * Tyrone
>>> 
>>>Proposed Names that do not meet the criteria
>>> * Train
>>> 
>>>However I'd like to suggest we skip the CIVS poll and select
>>>'Train' as
>>>the release name by TC resolution[3].  My think for this is
>>> 
>>> * It's fun and celebrates a humorous moment in our community
>>> * As a developer I've heard the T release called Train for quite
>>>   sometime, and was used often at the PTG[4].
>>> * As the *next* PTG is also in Colorado we can still choose a
>>>   geographic based name for U[5]
>>> * If train causes a problem for trademark reasons then we can
>>>always
>>>   run the poll
>>> 
>>>I'll leave[3] for marked -W for a week for discussion to happen
>>>before the
>>>TC can consider / vote on it.
>>> 
>>>Yours Tony.
>>> 
>>>[1]
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>>>[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>>>[3]
>>>
>>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>>>[4] https://twitter.com/vkmc/status/1040321043959754752
>>>[5]
>>>https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>>>
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>http:/

Re: [openstack-dev] [Openstack-sigs] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Erlon Cruz]

Theres also this document with very detailed information:

https://docs.google.com/spreadsheets/d/18ZtWC75BNCwFqLfFpCGGJ9uPVBvUXX0xuXP1yYG0NDA/edit#gid=0

Erlon

Em qui, 18 de out de 2018 às 10:30, Jay S Bryant 
escreveu:

>
>
> On 10/18/2018 7:21 AM, Sean McGinnis wrote:
> > On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:
> >> On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:
> >>> As you may know, unfortunately, Horizon doesn't support all features
> >>> provided by APIs. That's why we created feature gaps list [1].
> >>>
> >>> I'd got a lot of great conversations with projects teams during the PTG
> >>> and we tried to figure out what should be done prioritize these tasks.
> >>> It's really helpful for Horizon to get feedback from other teams to
> >>> understand what features should be implemented next.
> >>>
> >>> While I'm filling launchpad with new bugs and blueprints for [1], it
> >>> would be good to review this list again and find some volunteers to
> >>> decrease feature gaps.
> >>>
> >>> [1] https://etherpad.openstack.org/p/horizon-feature-gap
> >>>
> >>> Thanks everybody for any of your contributions to Horizon.
> >> +openstack-sigs
> >> +openstack-operators
> >>
> >> I've left some notes for nova. This looks very similar to the compute
> API
> >> OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what
> to
> >> really work on without some user/operator feedback - maybe we can get
> the
> >> user work group involved in trying to help prioritize what people really
> >> want that is missing from horizon, at least for compute?
> >>
> >> [1]
> https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt
> > I also have a cinderclient OSC gap analysis I've started working on. It
> might
> > be useful to add a Horizon column to this list too.
> >
> > https://ethercalc.openstack.org/cinderclient-osc-gap
> I had forgotten that we had this.  I have added it to the persistent
> links at the top of our meeting agenda page so we have it for future
> reference.  Did the same for the Horizon Feature Gaps.  Think it would
> be good to heave those somewhere that we see them and are reminded about
> them.
>
> Thanks!
> Jay
> > Sean
> >
> >
> __
> > OpenStack Development Mailing 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] [all] Naming the T release of OpenStack

[Ed Leafe]

On Oct 18, 2018, at 11:43 AM, Michał Dulko  wrote:
> 
> I'm totally supportive for OpenStack Train, but got to say that
> OpenStack Troublesome is a wonderful name as well. :)

Yeah, I’m sure that the marketing people won’t have a problem vetting that 
name. :)

-- Ed Leafe






__
OpenStack Development Mailing 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] [senlin] Meeting cancelled for this week

[Duc Truong]

Everyone,

I’m canceling the Senlin meeting this week because I’m unavailable.

We will resume at the scheduled time next week.

Duc (dtruong)
__
OpenStack Development Mailing 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] TripleO CI Summary: Sprint 20

[Rafael Folco]

Oops. Missing footer info.

[1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-20-193
[2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint20.1

On Thu, Oct 18, 2018 at 2:05 PM Rafael Folco  wrote:

> Greetings,
>
> The TripleO CI team has just completed Sprint 20 (Sep-27 thru Oct-17).
> The following is a summary of completed work during this sprint cycle:
>
>-
>
>Bootstrapped upstream standalone job on Fedora 28.
>-
>
>Migrated RDO jobs in Software Factory to native Zuul v3.
>-
>
>Refactored Tempest tooling (python-tempestconf).
>-
>
>Made possible the use of zuul inventory variables from the job to the
>quickstart workflow
>-
>
>Build-test-packages role is now using zuul variables to gather
>information on the changes alongside the old ZUUL_CHANGES method, which is
>now deprecated and will be removed in the future.
>-
>
>Translated bash variables into ansible as part of the ZuulV3 migration
>work.
>- Enabled stackviz on openstack/openstack-ansible-os_tempest role.
>-
>
>Enabled projects to override tempest tests via zuul variables in the
>job definition.
>
>
> The sprint task board for CI team has moved from Trello to Taiga [1]. The
> Ruck and Rover notes for this sprint has been tracked in the etherpad [2].
>
> The planned work for the next sprint focuses in running the upstream
> standalone job in Fedora 28 and continuing part of the work done in Sprint
> 20, including python-tempestconf refactoring, and enabling stackviz.
>
> The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm) and
> Rafael Folco (rfolco). Please direct questions or queries to them regarding
> CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix
> on their nick.
>
> Thanks,
> Folco
>
> --
> Rafael Folco
> Senior Software Engineer
>


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

Re: [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack

[Remo Mattei]

Michal, that will never work it’s 11 characters long


 

> On Oct 18, 2018, at 09:43, Eric Fried  wrote:
> 
> Sorry, I'm opposed to this idea.
> 
> I admit I don't understand the political framework, nor have I read the
> governing documents beyond [1], but that document makes it clear that
> this is supposed to be a community-wide vote.  Is it really legal for
> the TC (or whoever has merge rights on [2]) to merge a patch that gives
> that same body the power to take the decision out of the hands of the
> community? So it's really an oligarchy that gives its constituency the
> illusion of democracy until something comes up that it feels like not
> having a vote on? The fact that it's something relatively "unimportant"
> (this time) is not a comfort.
> 
> Not that I think the TC would necessarily move forward with [2] in the
> face of substantial opposition from non-TC "cores" or whatever.
> 
> I will vote enthusiastically for "Train". But a vote it should be.
> 
> -efried
> 
> [1] https://governance.openstack.org/tc/reference/release-naming.html 
> 
> [2] https://review.openstack.org/#/c/611511/ 
> 
> 
> On 10/18/2018 10:52 AM, arkady.kanev...@dell.com 
>  wrote:
>> +1 for the poll.
>> 
>> Let’s follow well established process.
>> 
>> If we want to add Train as one of the options for the name I am OK with it.
>> 
>>  
>> 
>> *From:* Jonathan Mills 
>> *Sent:* Thursday, October 18, 2018 10:49 AM
>> *To:* openstack-s...@lists.openstack.org
>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
>> 
>>  
>> 
>> [EXTERNAL EMAIL]
>> Please report any suspicious attachments, links, or requests for
>> sensitive information.
>> 
>> +1 for just having a poll
>> 
>>  
>> 
>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry > >> wrote:
>> 
>>I'm fine with Train but I'm also fine with just adding it to the
>>list and voting on it. It will win.
>> 
>> 
>> 
>>Also, for those not familiar with the debian/ubuntu command "sl",
>>now is the time to become so.
>> 
>> 
>> 
>>apt install sl
>> 
>>sl -Flea #ftw
>> 
>> 
>> 
>>On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
>>mailto:t...@bakeyournoodle.com> 
>> >> wrote:
>> 
>>Hello all,
>>As per [1] the nomination period for names for the T release
>>have
>>now closed (actually 3 days ago sorry).  The nominated names and any
>>qualifying remarks can be seen at2].
>> 
>>Proposed Names
>> * Tarryall
>> * Teakettle
>> * Teller
>> * Telluride
>> * Thomas
>> * Thornton
>> * Tiger
>> * Tincup
>> * Timnath
>> * Timber
>> * Tiny Town
>> * Torreys
>> * Trail
>> * Trinidad
>> * Treasure
>> * Troublesome
>> * Trussville
>> * Turret
>> * Tyrone
>> 
>>Proposed Names that do not meet the criteria
>> * Train
>> 
>>However I'd like to suggest we skip the CIVS poll and select
>>'Train' as
>>the release name by TC resolution[3].  My think for this is
>> 
>> * It's fun and celebrates a humorous moment in our community
>> * As a developer I've heard the T release called Train for quite
>>   sometime, and was used often at the PTG[4].
>> * As the *next* PTG is also in Colorado we can still choose a
>>   geographic based name for U[5]
>> * If train causes a problem for trademark reasons then we can
>>always
>>   run the poll
>> 
>>I'll leave[3] for marked -W for a week for discussion to happen
>>before the
>>TC can consider / vote on it.
>> 
>>Yours Tony.
>> 
>>[1]
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>>[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>>[3]
>>
>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>>[4] https://twitter.com/vkmc/status/1040321043959754752
>>[5]
>>https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z 
>> 
>>
>> > >
>>___
>>openstack-sigs mailing list
>>openstack-s...@lists.openstack.org 
>> 
>>> >
>>http://lists.openstack.org/cgi-

[openstack-dev] [tripleo] TripleO CI Summary: Sprint 20

[Rafael Folco]

Greetings,

The TripleO CI team has just completed Sprint 20 (Sep-27 thru Oct-17).
The following is a summary of completed work during this sprint cycle:

   -

   Bootstrapped upstream standalone job on Fedora 28.
   -

   Migrated RDO jobs in Software Factory to native Zuul v3.
   -

   Refactored Tempest tooling (python-tempestconf).
   -

   Made possible the use of zuul inventory variables from the job to the
   quickstart workflow
   -

   Build-test-packages role is now using zuul variables to gather
   information on the changes alongside the old ZUUL_CHANGES method, which is
   now deprecated and will be removed in the future.
   -

   Translated bash variables into ansible as part of the ZuulV3 migration
   work.
   - Enabled stackviz on openstack/openstack-ansible-os_tempest role.
   -

   Enabled projects to override tempest tests via zuul variables in the job
   definition.


The sprint task board for CI team has moved from Trello to Taiga [1]. The
Ruck and Rover notes for this sprint has been tracked in the etherpad [2].

The planned work for the next sprint focuses in running the upstream
standalone job in Fedora 28 and continuing part of the work done in Sprint
20, including python-tempestconf refactoring, and enabling stackviz.

The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm) and Rafael
Folco (rfolco). Please direct questions or queries to them regarding CI
status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on
their nick.

Thanks,
Folco

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

Re: [openstack-dev] [Openstack-sigs] [all] Naming the T release of OpenStack

[Eric Fried]

Sorry, I'm opposed to this idea.

I admit I don't understand the political framework, nor have I read the
governing documents beyond [1], but that document makes it clear that
this is supposed to be a community-wide vote.  Is it really legal for
the TC (or whoever has merge rights on [2]) to merge a patch that gives
that same body the power to take the decision out of the hands of the
community? So it's really an oligarchy that gives its constituency the
illusion of democracy until something comes up that it feels like not
having a vote on? The fact that it's something relatively "unimportant"
(this time) is not a comfort.

Not that I think the TC would necessarily move forward with [2] in the
face of substantial opposition from non-TC "cores" or whatever.

I will vote enthusiastically for "Train". But a vote it should be.

-efried

[1] https://governance.openstack.org/tc/reference/release-naming.html
[2] https://review.openstack.org/#/c/611511/

On 10/18/2018 10:52 AM, arkady.kanev...@dell.com wrote:
> +1 for the poll.
> 
> Let’s follow well established process.
> 
> If we want to add Train as one of the options for the name I am OK with it.
> 
>  
> 
> *From:* Jonathan Mills 
> *Sent:* Thursday, October 18, 2018 10:49 AM
> *To:* openstack-s...@lists.openstack.org
> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
> 
>  
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for
> sensitive information.
> 
> +1 for just having a poll
> 
>  
> 
> On Thu, Oct 18, 2018 at 11:39 AM David Medberry  > wrote:
> 
> I'm fine with Train but I'm also fine with just adding it to the
> list and voting on it. It will win.
> 
>  
> 
> Also, for those not familiar with the debian/ubuntu command "sl",
> now is the time to become so.
> 
>  
> 
> apt install sl
> 
> sl -Flea #ftw
> 
>  
> 
> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
> mailto:t...@bakeyournoodle.com>> wrote:
> 
> Hello all,
>     As per [1] the nomination period for names for the T release
> have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
> 
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
> 
> Proposed Names that do not meet the criteria
>  * Train
> 
> However I'd like to suggest we skip the CIVS poll and select
> 'Train' as
> the release name by TC resolution[3].  My think for this is
> 
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>    sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>    geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can
> always
>    run the poll
> 
> I'll leave[3] for marked -W for a week for discussion to happen
> before the
> TC can consider / vote on it.
> 
> Yours Tony.
> 
> [1]
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3]
> 
> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5]
> https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
> 
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 
> 
> 
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
ht

Re: [openstack-dev] [all] Naming the T release of OpenStack

[Michał Dulko]

On Thu, 2018-10-18 at 17:35 +1100, Tony Breeds wrote:
> Hello all,
> As per [1] the nomination period for names for the T release have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
> 
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
> 
> Proposed Names that do not meet the criteria
>  * Train
> 
> However I'd like to suggest we skip the CIVS poll and select 'Train' as
> the release name by TC resolution[3].  My think for this is 
> 
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can always
>run the poll
> 
> I'll leave[3] for marked -W for a week for discussion to happen before the
> TC can consider / vote on it.

I'm totally supportive for OpenStack Train, but got to say that
OpenStack Troublesome is a wonderful name as well. :)

> Yours Tony.
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


__
OpenStack Development Mailing 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][oslo][messaging] Removing “blocking” executor from oslo.messaging

[Ben Nemec]

On 10/18/18 9:59 AM, Ken Giusti wrote:

Hi Renat,

The biggest issue with the blocking executor (IMHO) is that it blocks 
the protocol I/O while  RPC processing is in progress.  This increases 
the likelihood that protocol processing will not get done in a timely 
manner and things start to fail in weird ways.  These failures are 
timing related and are typically hard to reproduce or root-cause.   This 
isn't something we can fix as blocking is the nature of the executor.


If we are to leave it in we'd really want to discourage its use.


Since it appears the actual executor code lives in futurist, would it be 
possible to remove the entrypoint for blocking from oslo.messaging and 
have mistral just pull it in with their setup.cfg? Seems like they 
should be able to add something like:


oslo.messaging.executors =
  blocking = futurist:SynchronousExecutor

to their setup.cfg to keep it available to them even if we drop it from 
oslo.messaging itself. That seems like a good way to strongly discourage 
use of it while still making it available to projects that are really 
sure they want it.




However I'm ok with leaving it available if the policy for using 
blocking is 'use at your own risk', meaning that bug reports may have to 
be marked 'won't fix' if we have reason to believe that blocking is at 
fault.  That implies removing 'blocking' as the default executor value 
in the API and having applications explicitly choose it.  And we keep 
the deprecation warning.


We could perhaps implement time duration checks around the executor 
callout and log a warning if the executor blocked for an extended amount 
of time (extended=TBD).


Other opinions so we can come to a consensus?


On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov > wrote:


Hi Oslo Team,

Can we retain “blocking” executor for now in Oslo Messaging?


Some background..

For a while we had to use Oslo Messaging with “blocking” executor in
Mistral because of incompatibility of MySQL driver with green
threads when choosing “eventlet” executor. Under certain conditions
we would get deadlocks between green threads. Some time ago we
switched to using PyMysql driver which is eventlet friendly and did
a number of tests that showed that we could safely switch to
“eventlet” executor (with that driver) so we introduced a new option
in Mistral where we could choose an executor in Oslo Messaging. The
corresponding bug is [1].

The issue is that we recently found that not everything actually
works as expected when using combination PyMysql + “eventlet”
executor. We also tried “threading” executor and the system *seems*
to work with it but surprisingly performance is much worse.

Given all of that we’d like to ask Oslo Team not to remove
“blocking” executor for now completely, if that’s possible. We have
a strong motivation to switch to “eventlet” for other reasons
(parallelism => better performance etc.) but seems like we need some
time to make it smoothly.


[1] https://bugs.launchpad.net/mistral/+bug/1696469


Thanks

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Ken Giusti  (kgiu...@gmail.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



__
OpenStack Development Mailing 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-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Jim Rollenhagen]

On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur  wrote:

> Hi all,
>
> Sorry for chiming in really late in this topic, but I think $subj is worth
> discussing until we settle harder on the potentially confusing terminology.
>
> I think the difference between "Edge" and "Far Edge" is too vague to use
> these
> terms in practice. Think about the "edge" metaphor itself: something
> rarely has
> several layers of edges. A knife has an edge, there are no far edges. I
> imagine
> zooming in and seeing more edges at the edge, and then it's quite cool
> indeed,
> but is it really a useful metaphor for those who never used a strong
> microscope? :)
>
> I think in the trivial sense "Far Edge" is a tautology, and should be
> avoided.
> As a weak proof of my words, I already see a lot of smart people confusing
> these
> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest
> we
> adopt a different terminology, even if it less consistent with typical
> marketing
> term around the "Edge" movement.
>

FWIW, we created rough definitions of "edge" and "far edge" during the edge
WG session in Denver.
It's mostly based on latency to the end user, though we also talked about
quantities of compute resources, if someone can find the pictures.
See the picture and table here:
https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview


>
> Now, I don't have really great suggestions. Something that came up in
> TripleO
> discussions [1] is Core/Hub/Edge, which I think reflects the idea better.
>

I'm also fine with these names, as they do describe the concepts well. :)

// jim


> I'd be very interested to hear your ideas.
>
> Dmitry
>
> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
OpenStack Development Mailing 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-sigs] [all] Naming the T release of OpenStack

[David Medberry]

and any talks I give in Denver (Forum, Ops, Main) will include "sl". It's
handy in a variety of ways.

On Thu, Oct 18, 2018 at 9:39 AM David Medberry 
wrote:

> I'm fine with Train but I'm also fine with just adding it to the list and
> voting on it. It will win.
>
> Also, for those not familiar with the debian/ubuntu command "sl", now is
> the time to become so.
>
> apt install sl
> sl -Flea #ftw
>
> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds 
> wrote:
>
>> Hello all,
>> As per [1] the nomination period for names for the T release have
>> now closed (actually 3 days ago sorry).  The nominated names and any
>> qualifying remarks can be seen at2].
>>
>> Proposed Names
>>  * Tarryall
>>  * Teakettle
>>  * Teller
>>  * Telluride
>>  * Thomas
>>  * Thornton
>>  * Tiger
>>  * Tincup
>>  * Timnath
>>  * Timber
>>  * Tiny Town
>>  * Torreys
>>  * Trail
>>  * Trinidad
>>  * Treasure
>>  * Troublesome
>>  * Trussville
>>  * Turret
>>  * Tyrone
>>
>> Proposed Names that do not meet the criteria
>>  * Train
>>
>> However I'd like to suggest we skip the CIVS poll and select 'Train' as
>> the release name by TC resolution[3].  My think for this is
>>
>>  * It's fun and celebrates a humorous moment in our community
>>  * As a developer I've heard the T release called Train for quite
>>sometime, and was used often at the PTG[4].
>>  * As the *next* PTG is also in Colorado we can still choose a
>>geographic based name for U[5]
>>  * If train causes a problem for trademark reasons then we can always
>>run the poll
>>
>> I'll leave[3] for marked -W for a week for discussion to happen before the
>> TC can consider / vote on it.
>>
>> Yours Tony.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>> [3]
>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>> [4] https://twitter.com/vkmc/status/1040321043959754752
>> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>> ___
>> openstack-sigs mailing list
>> openstack-s...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>
__
OpenStack Development Mailing 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-sigs] [all] Naming the T release of OpenStack

[David Medberry]

I'm fine with Train but I'm also fine with just adding it to the list and
voting on it. It will win.

Also, for those not familiar with the debian/ubuntu command "sl", now is
the time to become so.

apt install sl
sl -Flea #ftw

On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds 
wrote:

> Hello all,
> As per [1] the nomination period for names for the T release have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
>
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
>
> Proposed Names that do not meet the criteria
>  * Train
>
> However I'd like to suggest we skip the CIVS poll and select 'Train' as
> the release name by TC resolution[3].  My think for this is
>
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can always
>run the poll
>
> I'll leave[3] for marked -W for a week for discussion to happen before the
> TC can consider / vote on it.
>
> Yours Tony.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3]
> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
OpenStack Development Mailing 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] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Jay Pipes]

On 10/18/2018 10:23 AM, Dmitry Tantsur wrote:

Hi all,

Sorry for chiming in really late in this topic, but I think $subj is 
worth discussing until we settle harder on the potentially confusing 
terminology.


I think the difference between "Edge" and "Far Edge" is too vague to use 
these terms in practice. Think about the "edge" metaphor itself: 
something rarely has several layers of edges. A knife has an edge, there 
are no far edges. I imagine zooming in and seeing more edges at the 
edge, and then it's quite cool indeed, but is it really a useful 
metaphor for those who never used a strong microscope? :)


I think in the trivial sense "Far Edge" is a tautology, and should be 
avoided. As a weak proof of my words, I already see a lot of smart 
people confusing these two and actually use Central/Edge where they mean 
Edge/Far Edge. I suggest we adopt a different terminology, even if it 
less consistent with typical marketing term around the "Edge" movement.


Now, I don't have really great suggestions. Something that came up in 
TripleO discussions [1] is Core/Hub/Edge, which I think reflects the 
idea better.


I'd be very interested to hear your ideas.


"The Edge" and "Lunatic Fringe".

There, problem solved.

-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

[openstack-dev] [tc][all] TC office hours is started now on #openstack-tc

[Ghanshyam Mann]

Hi All, 

TC office hour is started on #openstack-tc channel. Feel free to reach to us 
for anything you want discuss/input/feedback/help from TC.  

-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] [mistral][oslo][messaging] Removing “blocking” executor from oslo.messaging

[Ken Giusti]

Hi Renat,

The biggest issue with the blocking executor (IMHO) is that it blocks the
protocol I/O while  RPC processing is in progress.  This increases the
likelihood that protocol processing will not get done in a timely manner
and things start to fail in weird ways.  These failures are timing related
and are typically hard to reproduce or root-cause.   This isn't something
we can fix as blocking is the nature of the executor.

If we are to leave it in we'd really want to discourage its use.

However I'm ok with leaving it available if the policy for using blocking
is 'use at your own risk', meaning that bug reports may have to be marked
'won't fix' if we have reason to believe that blocking is at fault.  That
implies removing 'blocking' as the default executor value in the API and
having applications explicitly choose it.  And we keep the deprecation
warning.

We could perhaps implement time duration checks around the executor callout
and log a warning if the executor blocked for an extended amount of time
(extended=TBD).

Other opinions so we can come to a consensus?


On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov 
wrote:

> Hi Oslo Team,
>
> Can we retain “blocking” executor for now in Oslo Messaging?
>
>
> Some background..
>
> For a while we had to use Oslo Messaging with “blocking” executor in
> Mistral because of incompatibility of MySQL driver with green threads when
> choosing “eventlet” executor. Under certain conditions we would get
> deadlocks between green threads. Some time ago we switched to using PyMysql
> driver which is eventlet friendly and did a number of tests that showed
> that we could safely switch to “eventlet” executor (with that driver) so we
> introduced a new option in Mistral where we could choose an executor in
> Oslo Messaging. The corresponding bug is [1].
>
> The issue is that we recently found that not everything actually works as
> expected when using combination PyMysql + “eventlet” executor. We also
> tried “threading” executor and the system *seems* to work with it but
> surprisingly performance is much worse.
>
> Given all of that we’d like to ask Oslo Team not to remove “blocking”
> executor for now completely, if that’s possible. We have a strong
> motivation to switch to “eventlet” for other reasons (parallelism => better
> performance etc.) but seems like we need some time to make it smoothly.
>
>
> [1] https://bugs.launchpad.net/mistral/+bug/1696469
>
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Ken Giusti  (kgiu...@gmail.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] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Bogdan Dobrelya]

On 10/18/18 4:33 PM, arkady.kanev...@dell.com wrote:

Love  the idea to have clearer terminology.
Suggest we let telco folks to suggest terminology to use.
This is not a 3 level hierarchy but much more.
There are several layers of aggregation from local to metro, to  regional, to 
DC. And potential multiple layers in each.

-Original Message-
From: Dmitry Tantsur 
Sent: Thursday, October 18, 2018 9:23 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-s...@lists.openstack.org
Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and 
"Far Edge"


[EXTERNAL EMAIL]
Please report any suspicious attachments, links, or requests for sensitive 
information.


Hi all,

Sorry for chiming in really late in this topic, but I think $subj is worth
discussing until we settle harder on the potentially confusing terminology.

I think the difference between "Edge" and "Far Edge" is too vague to use these
terms in practice. Think about the "edge" metaphor itself: something rarely has
several layers of edges. A knife has an edge, there are no far edges. I imagine
zooming in and seeing more edges at the edge, and then it's quite cool indeed,
but is it really a useful metaphor for those who never used a strong 
microscope? :)

I think in the trivial sense "Far Edge" is a tautology, and should be avoided.
As a weak proof of my words, I already see a lot of smart people confusing these
two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we
adopt a different terminology, even if it less consistent with typical marketing
term around the "Edge" movement.

Now, I don't have really great suggestions. Something that came up in TripleO
discussions [1] is Core/Hub/Edge, which I think reflects the idea better.

I'd be very interested to hear your ideas.


Similarly to NUMA distance is equal to the shortest path between the 
NUMA nodes, we could think of edges as facets and Edge distance as the 
shortest path between edge sites, counting from the central Edge 
(distance 0), or central Edges, if we have those decentralized and there 
is no a single central Edge?




Dmitry

[1] https://etherpad.openstack.org/p/tripleo-edge-mvp

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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Arkady.Kanevsky]

Love  the idea to have clearer terminology.
Suggest we let telco folks to suggest terminology to use.
This is not a 3 level hierarchy but much more.
There are several layers of aggregation from local to metro, to  regional, to 
DC. And potential multiple layers in each.

-Original Message-
From: Dmitry Tantsur  
Sent: Thursday, October 18, 2018 9:23 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-s...@lists.openstack.org
Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" 
and "Far Edge"


[EXTERNAL EMAIL] 
Please report any suspicious attachments, links, or requests for sensitive 
information.


Hi all,

Sorry for chiming in really late in this topic, but I think $subj is worth 
discussing until we settle harder on the potentially confusing terminology.

I think the difference between "Edge" and "Far Edge" is too vague to use these 
terms in practice. Think about the "edge" metaphor itself: something rarely has 
several layers of edges. A knife has an edge, there are no far edges. I imagine 
zooming in and seeing more edges at the edge, and then it's quite cool indeed, 
but is it really a useful metaphor for those who never used a strong 
microscope? :)

I think in the trivial sense "Far Edge" is a tautology, and should be avoided. 
As a weak proof of my words, I already see a lot of smart people confusing 
these 
two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we 
adopt a different terminology, even if it less consistent with typical 
marketing 
term around the "Edge" movement.

Now, I don't have really great suggestions. Something that came up in TripleO 
discussions [1] is Core/Hub/Edge, which I think reflects the idea better.

I'd be very interested to hear your ideas.

Dmitry

[1] https://etherpad.openstack.org/p/tripleo-edge-mvp

___
openstack-sigs mailing list
openstack-s...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
__
OpenStack Development Mailing 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] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge"

[Dmitry Tantsur]

Hi all,

Sorry for chiming in really late in this topic, but I think $subj is worth 
discussing until we settle harder on the potentially confusing terminology.


I think the difference between "Edge" and "Far Edge" is too vague to use these 
terms in practice. Think about the "edge" metaphor itself: something rarely has 
several layers of edges. A knife has an edge, there are no far edges. I imagine 
zooming in and seeing more edges at the edge, and then it's quite cool indeed, 
but is it really a useful metaphor for those who never used a strong microscope? :)


I think in the trivial sense "Far Edge" is a tautology, and should be avoided. 
As a weak proof of my words, I already see a lot of smart people confusing these 
two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we 
adopt a different terminology, even if it less consistent with typical marketing 
term around the "Edge" movement.


Now, I don't have really great suggestions. Something that came up in TripleO 
discussions [1] is Core/Hub/Edge, which I think reflects the idea better.


I'd be very interested to hear your ideas.

Dmitry

[1] https://etherpad.openstack.org/p/tripleo-edge-mvp

__
OpenStack Development Mailing 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] Naming the T release of OpenStack

[Jeremy Stanley]

On 2018-10-18 08:35:21 -0500 (-0500), Jay S Bryant wrote:
[...]
> When OpenStack developers think Denver, we think Trains.  :-)
[...]

As, presumably, do many OpenStack operators now since the Ops
Mid-Cycle event was co-located with the most recent PTG.
-- 
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] [all] Naming the T release of OpenStack

[Neil Jerram]

On Thu, Oct 18, 2018 at 2:35 PM Jay S Bryant  wrote:
>
>
>
> On 10/18/2018 8:29 AM, Neil Jerram wrote:
>
> FWIW, I've have no clue if this is serious or not, or what 'Train' refers 
> to...
>
> Neil,
>
> The two Project Team Gathering events in Denver were held at a hotel next to 
> the train line from downtown to the airport.  The crossing signals there had 
> some sort of malfunction in the past causing them to not stop the cars when a 
> train was coming properly.  As a result the trains were required to blow 
> their horns when passing through that area.  Obviously staying in a hotel, by 
> trains that are blowing their horns 24/7 was less than ideal.  As a result, 
> many jokes popped up about Denver and trains.
>
> When OpenStack developers think Denver, we think Trains.  :-)
>
> Jay

:-) Thanks!
Neil

__
OpenStack Development Mailing 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] Naming the T release of OpenStack

[Jay S Bryant]

On 10/18/2018 8:29 AM, Neil Jerram wrote:
FWIW, I've have no clue if this is serious or not, or what 'Train' 
refers to...



Neil,

The two Project Team Gathering events in Denver were held at a hotel 
next to the train line from downtown to the airport.  The crossing 
signals there had some sort of malfunction in the past causing them to 
not stop the cars when a train was coming properly.  As a result the 
trains were required to blow their horns when passing through that 
area.  Obviously staying in a hotel, by trains that are blowing their 
horns 24/7 was less than ideal.  As a result, many jokes popped up about 
Denver and trains.


When OpenStack developers think Denver, we think Trains.  :-)

Jay


On Thu, Oct 18, 2018 at 2:25 PM Jay S Bryant > wrote:


On 10/18/2018 1:35 AM, Tony Breeds wrote:


Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll

+2 +W  Great names proposed above but based on other discussions
with people I think the community would be happy with the Train
name.  Plus if people ask about it, it gives us an opportunity to
share a story that gives insight into the community we are.  :-) 
Thanks for proposing that path Tony!

Jay

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.


[1]http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2]https://wiki.openstack.org/wiki/Release_Naming/T_Proposals

[3]https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4]https://twitter.com/vkmc/status/1040321043959754752
[5]https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z



__
OpenStack Development Mailing 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] [Openstack-sigs] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Jay S Bryant]

On 10/18/2018 7:21 AM, Sean McGinnis wrote:

On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:

On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:

As you may know, unfortunately, Horizon doesn't support all features
provided by APIs. That's why we created feature gaps list [1].

I'd got a lot of great conversations with projects teams during the PTG
and we tried to figure out what should be done prioritize these tasks.
It's really helpful for Horizon to get feedback from other teams to
understand what features should be implemented next.

While I'm filling launchpad with new bugs and blueprints for [1], it
would be good to review this list again and find some volunteers to
decrease feature gaps.

[1] https://etherpad.openstack.org/p/horizon-feature-gap

Thanks everybody for any of your contributions to Horizon.

+openstack-sigs
+openstack-operators

I've left some notes for nova. This looks very similar to the compute API
OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to
really work on without some user/operator feedback - maybe we can get the
user work group involved in trying to help prioritize what people really
want that is missing from horizon, at least for compute?

[1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc

--

Thanks,

Matt

I also have a cinderclient OSC gap analysis I've started working on. It might
be useful to add a Horizon column to this list too.

https://ethercalc.openstack.org/cinderclient-osc-gap
I had forgotten that we had this.  I have added it to the persistent 
links at the top of our meeting agenda page so we have it for future 
reference.  Did the same for the Horizon Feature Gaps.  Think it would 
be good to heave those somewhere that we see them and are reminded about 
them.


Thanks!
Jay

Sean

__
OpenStack Development Mailing 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] Naming the T release of OpenStack

[Neil Jerram]

FWIW, I've have no clue if this is serious or not, or what 'Train' refers
to...


On Thu, Oct 18, 2018 at 2:25 PM Jay S Bryant  wrote:

> On 10/18/2018 1:35 AM, Tony Breeds wrote:
>
> Hello all,
> As per [1] the nomination period for names for the T release have
> now closed (actually 3 days ago sorry).  The nominated names and any
> qualifying remarks can be seen at2].
>
> Proposed Names
>  * Tarryall
>  * Teakettle
>  * Teller
>  * Telluride
>  * Thomas
>  * Thornton
>  * Tiger
>  * Tincup
>  * Timnath
>  * Timber
>  * Tiny Town
>  * Torreys
>  * Trail
>  * Trinidad
>  * Treasure
>  * Troublesome
>  * Trussville
>  * Turret
>  * Tyrone
>
> Proposed Names that do not meet the criteria
>  * Train
>
> However I'd like to suggest we skip the CIVS poll and select 'Train' as
> the release name by TC resolution[3].  My think for this is
>
>  * It's fun and celebrates a humorous moment in our community
>  * As a developer I've heard the T release called Train for quite
>sometime, and was used often at the PTG[4].
>  * As the *next* PTG is also in Colorado we can still choose a
>geographic based name for U[5]
>  * If train causes a problem for trademark reasons then we can always
>run the poll
>
> +2 +W  Great names proposed above but based on other discussions with
> people I think the community would be happy with the Train name.  Plus if
> people ask about it, it gives us an opportunity to share a story that gives
> insight into the community we are.  :-)  Thanks for proposing that path
> Tony!
>
> Jay
>
>
> I'll leave[3] for marked -W for a week for discussion to happen before the
> TC can consider / vote on it.
>
> Yours Tony.
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
> [3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
> [4] https://twitter.com/vkmc/status/1040321043959754752
> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [all] Naming the T release of OpenStack

[Jay S Bryant]

On 10/18/2018 1:35 AM, Tony Breeds wrote:


Hello all,
 As per [1] the nomination period for names for the T release have
now closed (actually 3 days ago sorry).  The nominated names and any
qualifying remarks can be seen at2].

Proposed Names
  * Tarryall
  * Teakettle
  * Teller
  * Telluride
  * Thomas
  * Thornton
  * Tiger
  * Tincup
  * Timnath
  * Timber
  * Tiny Town
  * Torreys
  * Trail
  * Trinidad
  * Treasure
  * Troublesome
  * Trussville
  * Turret
  * Tyrone

Proposed Names that do not meet the criteria
  * Train

However I'd like to suggest we skip the CIVS poll and select 'Train' as
the release name by TC resolution[3].  My think for this is

  * It's fun and celebrates a humorous moment in our community
  * As a developer I've heard the T release called Train for quite
sometime, and was used often at the PTG[4].
  * As the *next* PTG is also in Colorado we can still choose a
geographic based name for U[5]
  * If train causes a problem for trademark reasons then we can always
run the poll
+2 +W  Great names proposed above but based on other discussions with 
people I think the community would be happy with the Train name.  Plus 
if people ask about it, it gives us an opportunity to share a story that 
gives insight into the community we are.  :-) Thanks for proposing that 
path Tony!


Jay

I'll leave[3] for marked -W for a week for discussion to happen before the
TC can consider / vote on it.

Yours Tony.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
[3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
[4] https://twitter.com/vkmc/status/1040321043959754752
[5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z


__
OpenStack Development Mailing 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] [release] Release countdown for week R-24 and R-23, October 22 - November 2

[Sean McGinnis]

Development Focus
-

Team focus should be on spec approval and implementation for priority features.

General Information
---

Projects that have been following the cycle-with-milestone release model will
be switched over to cycle-with-rc soon [0]. Just a reminder that although the
changes mean milestones are no long required, projects are free to still
request one if they feel there is a need.

Projects following cycle-with-intermediary with libraries have hopefully seen
the mailing list thread on changes there [1]. Projects with libraries following
this release model that have unreleased commits are encouraged to request a
release for those. But under the new plan, the release team will propose
releases for those projects if there has not been one requested before the
milestone.

PTLs and/or release liaisons - a reminder that we would love to have you around
during our weekly meeting [2]. It would also be very helpful if you would
linger in the #openstack-release channel during deadline weeks.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135088.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html
[2] http://eavesdrop.openstack.org/#Release_Team_Meeting

Upcoming Deadlines & Dates
--

Stein-1 milestone: October 25  (R-24 week)
Forum at OpenStack Summit in Berlin: November 13-15

--
Sean McGinnis (smcginnis)

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

Re: [openstack-dev] [requirements][vitrage][infra] SQLAlchemy-Utils version 0.33.6 breaks Vitrage gate

[Jeremy Stanley]

On 2018-10-18 14:57:23 +0200 (+0200), Andreas Jaeger wrote:
> On 18/10/2018 14.15, Ifat Afek wrote:
> > Hi,
> > 
> > In the last three days Vitrage gate is broken due to the new requirement
> > of SQLAlchemy-Utils==0.33.6.
> > We get the following error [1]:
> > 
> > [...] >
> > Can we move back to version 0.33.5? or is there another solution?
> 
> We discussed that on #openstack-infra, and fixed it each day - and then it
> appeared again.
> 
> https://review.openstack.org/611444 is the proposed fix for that - the
> issues comes from the fact that we build wheels if there are none available
> and had a race in it.
> 
> I hope an admin can delete the broken file again and it works again tomorrow
> - if not, best to speak up quickly on #openstack-infra,

It's been deleted (again) and the suspected fix approved so
hopefully it won't recur.
-- 
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] [requirements][vitrage][infra] SQLAlchemy-Utils version 0.33.6 breaks Vitrage gate

[Andreas Jaeger]

On 18/10/2018 14.15, Ifat Afek wrote:

Hi,

In the last three days Vitrage gate is broken due to the new requirement 
of SQLAlchemy-Utils==0.33.6.

We get the following error [1]:

[...] >
Can we move back to version 0.33.5? or is there another solution?


We discussed that on #openstack-infra, and fixed it each day - and then 
it appeared again.


https://review.openstack.org/611444 is the proposed fix for that - the 
issues comes from the fact that we build wheels if there are none 
available and had a race in it.


I hope an admin can delete the broken file again and it works again 
tomorrow - if not, best to speak up quickly on #openstack-infra,


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

Re: [openstack-dev] [tripleo][ui][tempest][oooq] Refreshing plugins from git

[Bogdan Dobrelya]

On 10/18/18 2:17 AM, Honza Pokorny wrote:

Hello folks,

I'm working on the automated ui testing blueprint[1], and I think we
need to change the way we ship our tempest tests.

Here is where things stand at the moment:

* We have a kolla image for tempest
* This image contains the tempest rpm, and the openstack-tempest-all rpm
* The openstack-tempest-all package in turn contains all of the
   openstack tempest plugins
* Each of the plugins is shipped as an rpm

So, in order for a new test in tempest-tripleo-ui to appear in CI we
have to go through at least the following tests:

* New tempest-tripleo-ui rpm
* New openstack-tempest-all rpm
* New tempest kolla image

This could easily take a week, if not more.

What I would like to build is something like the following:

* Add an option to the tempest-setup.sh script in tripleo-quickstart to
   refresh all tempest plugins from git before running any tests
* Optionally specify a zuul change for any of the plugins being
   refreshed
* Hook up the test job to patches in tripleo-ui (which tests in
   tempest-tripleo-ui are testing) so that I can run a fix and its test
   in a single CI job

This would allow the tripleo-ui team to develop code and tests at the
same time, and prevent breakage before a patch is even merged.

Here are a few questions:

* Do you think this is a good idea?


This reminds the update_containers case, but relaxed the next level of
updating from sources instead of rpm. Given that we already have that 
update_containers thing, the idea seems acceptable for CI use only. 
Although I'd prefer to see the packages and the tempest container (and 
all that update_containers affects) rebuilt in the same CI job run instead.


Though I'm not sure for having different paths for "new test in 
tempest-tripleo-ui" getting into container: executed in CI vs executed 
via TripleO UI? I think the path it takes should always be the same. But 
please excuse me if I got the case wrong.


[0] https://goo.gl/5bCWRX


* Could we accomplish this by some other, simple mechanism?

Any helpful suggestions, corrections, and feedback are much appreciated.

Thanks

Honza Pokorny

[1]: https://blueprints.launchpad.net/tripleo/+spec/automated-ui-testing

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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [Openstack-sigs] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps

[Sean McGinnis]

On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote:
> On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote:
> > 
> > As you may know, unfortunately, Horizon doesn't support all features
> > provided by APIs. That's why we created feature gaps list [1].
> > 
> > I'd got a lot of great conversations with projects teams during the PTG
> > and we tried to figure out what should be done prioritize these tasks.
> > It's really helpful for Horizon to get feedback from other teams to
> > understand what features should be implemented next.
> > 
> > While I'm filling launchpad with new bugs and blueprints for [1], it
> > would be good to review this list again and find some volunteers to
> > decrease feature gaps.
> > 
> > [1] https://etherpad.openstack.org/p/horizon-feature-gap
> > 
> > Thanks everybody for any of your contributions to Horizon.
> 
> +openstack-sigs
> +openstack-operators
> 
> I've left some notes for nova. This looks very similar to the compute API
> OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to
> really work on without some user/operator feedback - maybe we can get the
> user work group involved in trying to help prioritize what people really
> want that is missing from horizon, at least for compute?
> 
> [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
> 
> -- 
> 
> Thanks,
> 
> Matt

I also have a cinderclient OSC gap analysis I've started working on. It might
be useful to add a Horizon column to this list too.

https://ethercalc.openstack.org/cinderclient-osc-gap

Sean

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

[openstack-dev] [requirements][vitrage] SQLAlchemy-Utils version 0.33.6 breaks Vitrage gate

[Ifat Afek]

Hi,

In the last three days Vitrage gate is broken due to the new
requirement of SQLAlchemy-Utils==0.33.6.

We get the following error [1]:

2018-10-18 09:21:13.946

| Collecting SQLAlchemy-Utils===0.33.6 (from -c
/opt/stack/new/requirements/upper-constraints.txt (line 31))

2018-10-18 09:21:14.070

|   Downloading
http://mirror.mtl01.inap.openstack.org/wheel/ubuntu-16.04-x86_64/sqlalchemy-utils/SQLAlchemy_Utils-0.33.6-py2.py3-none-any.whl
(88kB)

2018-10-18 09:21:14.105

| Exception:

2018-10-18 09:21:14.105

| Traceback (most recent call last):

2018-10-18 09:21:14.105

|   File "/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line
215, in main

2018-10-18 09:21:14.105

| status = self.run(options, args)

2018-10-18 09:21:14.105

|   File "/usr/local/lib/python2.7/dist-packages/pip/commands/install.py",
line 335, in run

2018-10-18 09:21:14.105

| wb.build(autobuilding=True)

2018-10-18 09:21:14.105

|   File "/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749,
in build

2018-10-18 09:21:14.105

| self.requirement_set.prepare_files(self.finder)

2018-10-18 09:21:14.105

|   File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line
380, in prepare_files

2018-10-18 09:21:14.105

| ignore_dependencies=self.ignore_dependencies))

2018-10-18 09:21:14.105

|   File "/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line
620, in _prepare_file

2018-10-18 09:21:14.105

| session=self.session, hashes=hashes)

2018-10-18 09:21:14.106

|   File "/usr/local/lib/python2.7/dist-packages/pip/download.py", line
821, in unpack_url

2018-10-18 09:21:14.106

| hashes=hashes

2018-10-18 09:21:14.106

|   File "/usr/local/lib/python2.7/dist-packages/pip/download.py", line
663, in unpack_http_url

2018-10-18 09:21:14.106

| unpack_file(from_path, location, content_type, link)

2018-10-18 09:21:14.106

|   File "/usr/local/lib/python2.7/dist-packages/pip/utils/__init__.py",
line 599, in unpack_file

2018-10-18 09:21:14.106

| flatten=not filename.endswith('.whl')

2018-10-18 09:21:14.106

|   File "/usr/local/lib/python2.7/dist-packages/pip/utils/__init__.py",
line 484, in unzip_file

2018-10-18 09:21:14.106

| zip = zipfile.ZipFile(zipfp, allowZip64=True)

2018-10-18 0

[openstack-dev] [nova] API updates week 18-42

[Ghanshyam Mann]

Hi All, 

Please find the Nova API highlights of this week. 

Weekly Office Hour: 
=== 

What we discussed this week: 
- Discussed about API extensions works. 
- Discussed on 2 new bugs which needs more log for further debugging. added bug 
comments. 

Planned Features : 
== 
Below are the API related features for Stein. Ref - 
https://etherpad.openstack.org/p/stein-nova-subteam-tracking (feel free to add 
API item there if you are working or found any). NOTE: sequence order are not 
the priority, they are listed as per their start date. 

1. API Extensions merge work 
- https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein 
- 
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-stein+status:open
 
- Weekly Progress: last patch has +2 and other has +A and on gate. 

2. Handling a down cell 
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell 
- 
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
 
- Weekly Progress: tssurya has updated the patches on this. can we get this in 
runway ?

3. Servers Ips non-unique network names : 
- 
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
 
- Spec Merged 
- 
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
 
- Weekly Progress: No progress. 

4. Volume multiattach enhancements: 
- https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements 
- 
https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged)
 
- Weekly Progress: No progress. 

5. Boot instance specific storage backend 
- 
https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-backend
 
- 
https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-backend+(status:open+OR+status:merged)
 
- Weekly Progress: COMPLETED

6. Add API ref guideline for body text (takashin) 
- https://review.openstack.org/#/c/605628/ 
- Weekly Progress: Reviewed most of the patches. 

Specs: 
7. Detach and attach boot volumes 
- 
https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged)
 
- Weekly Progress: under review. Kevin has updated the spec with review comment 
fix. 

8. Nova API policy updates 
https://blueprints.launchpad.net/nova/+spec/granular-api-policy 
Spec: https://review.openstack.org/#/c/547850/ 
- Weekly Progress: No progress in this. first concentrating on its dependency 
on 'consistent policy name' - https://review.openstack.org/#/c/606214/ 

9. Nova API cleanup 
https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup 
Spec: https://review.openstack.org/#/c/603969/ 
- Weekly Progress: No progress on this. I will update this with all cleanup in 
next week. 

10. Support deleting data volume when destroy instance(Brin Zhang) 
- https://review.openstack.org/#/c/580336/ 
- Weekly Progress: No Progress. 

Bugs: 
 
This week Bug Progress: 
https://etherpad.openstack.org/p/nova-api-weekly-bug-report 

Critical: 0->0 
High importance: 2->1 
By Status: 
New: 4->2
Confirmed/Triage: 32-> 32 
In-progress: 35->36 
Incomplete: 3->5 
= 
Total: 74->75 

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those 
are not in above list. Tag such bugs so that we can keep our eyes. 

-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] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

[Dmitry Tantsur]

On 10/17/18 5:59 PM, Joshua Harlow wrote:

Dmitry Tantsur wrote:

On 10/10/18 7:41 PM, Greg Hill wrote:

I've been out of the openstack loop for a few years, so I hope this
reaches the right folks.

Josh Harlow (original author of taskflow and related libraries) and I
have been discussing the option of moving taskflow out of the
openstack umbrella recently. This move would likely also include the
futurist and automaton libraries that are primarily used by taskflow.


Just for completeness: futurist and automaton are also heavily relied on
by ironic without using taskflow.


When did futurist get used??? nice :)

(I knew automaton was, but maybe I knew futurist was to and I forgot, lol).


I'm pretty sure you did, it happened back in Mitaka :)






The idea would be to just host them on github and use the regular
Github features for Issues, PRs, wiki, etc, in the hopes that this
would spur more development. Taskflow hasn't had any substantial
contributions in several years and it doesn't really seem that the
current openstack devs have a vested interest in moving it forward. I
would like to move it forward, but I don't have an interest in being
bound by the openstack workflow (this is why the project stagnated as
core reviewers were pulled on to other projects and couldn't keep up
with the review backlog, so contributions ground to a halt).

I guess I'm putting it forward to the larger community. Does anyone
have any objections to us doing this? Are there any non-obvious
technicalities that might make such a transition difficult? Who would
need to be made aware so they could adjust their own workflows?

Or would it be preferable to just fork and rename the project so
openstack can continue to use the current taskflow version without
worry of us breaking features?

Greg


__

OpenStack Development Mailing 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 Development Mailing 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][oslo][messaging] Removing “blocking” executor from oslo.messaging

[Renat Akhmerov]

Hi Oslo Team,

Can we retain “blocking” executor for now in Oslo Messaging?


Some background..

For a while we had to use Oslo Messaging with “blocking” executor in Mistral 
because of incompatibility of MySQL driver with green threads when choosing 
“eventlet” executor. Under certain conditions we would get deadlocks between 
green threads. Some time ago we switched to using PyMysql driver which is 
eventlet friendly and did a number of tests that showed that we could safely 
switch to “eventlet” executor (with that driver) so we introduced a new option 
in Mistral where we could choose an executor in Oslo Messaging. The 
corresponding bug is [1].

The issue is that we recently found that not everything actually works as 
expected when using combination PyMysql + “eventlet” executor. We also tried 
“threading” executor and the system seems to work with it but surprisingly 
performance is much worse.

Given all of that we’d like to ask Oslo Team not to remove “blocking” executor 
for now completely, if that’s possible. We have a strong motivation to switch 
to “eventlet” for other reasons (parallelism => better performance etc.) but 
seems like we need some time to make it smoothly.


[1] https://bugs.launchpad.net/mistral/+bug/1696469


Thanks

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