Thanks, Zane for putting this up.
It's a great service to expose infrastructure to application, and a
potential cross-community works as well.
>
> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and let's collect a list of volunteers
> to
On 6/7/2018 5:48 PM, Matt Riedemann wrote:
On 6/7/2018 3:25 PM, Kendall Nelson wrote:
I know it doesn't fit the shiny user facing docket that was discussed
at the Forum, but I do think its time we make migration official in
some capacity as a release goal or some other way. Having migrated
There is now a blueprint [1] and draft spec [2]. Reviews welcomed.
[1] https://blueprints.launchpad.net/nova/+spec/reshape-provider-tree
[2] https://review.openstack.org/#/c/572583/
On 06/04/2018 06:00 PM, Eric Fried wrote:
> There has been much discussion. We've gotten to a point of an
Dan Smith wrote on 06/08/2018 08:46:01 AM:
> From: Dan Smith
> To: melanie witt
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> ,
openstack-operat...@lists.openstack.org
> Date: 06/08/2018 08:48 AM
> Subject: Re: [openstack-dev] [nova] increasing the number of allowed
Kendall Nelson 於 2018年6月8日 週五 上午4:26寫道：
>
> I think that these two goals definitely fit the criteria we discussed in
Vancouver during the S Release Goal Forum Session. I know Storyboard
Migration was also mentioned after I had to dip out to another session so I
wanted to follow up on that.
>
+1.
Sean McGinnis 於 2018年6月5日 週二 上午2:07寫道：
>
> Python 3 First
> ==
>
> One of the things brought up in the session was picking things that bring
> excitement and are obvious benefits to deployers and users of OpenStack
> services. While this one is maybe not as immediately obvious, I
IMO, the goal is that we try to encourage the good, not to get in the way
to those who can't reach that goal.
A tag is a good way to encourage, but it also not a fair way for those
projects who barely got enough core member to review (Think about those
projects got less than four active cores).
> Some ideas that have been discussed so far include:
FYI, these are already in my order of preference.
> A) Selecting a new, higher maximum that still yields reasonable
> performance on a single compute host (64 or 128, for example). Pros:
> helps prevent the potential for poor performance on a
Hi,
Answering inline.
Best,
Erno "jokke" Kuvaja
On Thu, Jun 7, 2018 at 11:49 AM, Csatari, Gergely (Nokia -
HU/Budapest) wrote:
> Hi,
>
>
>
> I did some work ont he figures and realised, that I have some questions
> related to the alternative options:
>
>
>
> Multiple backends option:
>
> What
Hi,
Going inline.
From: Waines, Greg [mailto:greg.wai...@windriver.com]
Sent: Thursday, June 7, 2018 2:24 PM
I had some additional questions/comments on the Image Synchronization Options (
https://wiki.openstack.org/wiki/Image_handling_in_edge_environment ):
One Glance with multiple backends
Responses in-lined below,
Greg.
From: "Csatari, Gergely (Nokia - HU/Budapest)"
Date: Friday, June 8, 2018 at 3:39 AM
To: Greg Waines ,
"openstack-dev@lists.openstack.org" ,
"edge-comput...@lists.openstack.org"
Subject: RE: [Edge-computing] [edge][glance][mixmatch]: Wiki of the possible
On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote:
> On 6/7/2018 12:56 PM, melanie witt wrote:
> > Recently, we've received interest about increasing the maximum number of
> > allowed volumes to attach to a single instance > 26. The limit of 26 is
> > because of a historical
Matt Riedemann 於 2018年6月8日 週五 上午6:49寫道：
> I haven't used it much, but it would be really nice if someone could
> record a modern 'how to storyboard' video for just basic usage/flows
> since most people are used to launchpad by now so dealing with an
> entirely new task tracker is not trivial (or
On Fri, Jun 8, 2018 at 3:35 AM, Matt Riedemann wrote:
> I've started an etherpad [1] to identify the compute API microversion gaps
> in python-openstackclient.
>
> It's a small start right now so I would appreciate some help on this, even
> just a few people looking at a couple of these per day
On 6/8/2018 1:03 PM, Jay S Bryant wrote:
Helps if I include the link to the video:
https://www.openstack.org/videos/boston-2017/storyboard-101-survival-guide-to-the-great-migration
Hope that helps.
Yeah I linked to that in my original email - that's about the migration,
not usage. I want
Hey everyone,
Please see https://wiki.openstack.org/wiki/Governance/
Foundation/UserCommittee for UC meeting info and add additional agenda
items if needed.
--
Kind regards,
Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
On 6/7/2018 5:48 PM, Matt Riedemann wrote:
On 6/7/2018 3:25 PM, Kendall Nelson wrote:
I know it doesn't fit the shiny user facing docket that was discussed
at the Forum, but I do think its time we make migration official in
some capacity as a release goal or some other way. Having migrated
Hi I'm building integration with Vitrage webhook and looking for some
clarification on what ID to use for matching a webhook notification to
the specific alarm from the alarm list. In the sample alarm list
response, there is an 'id' field and a 'vitrage_id' field [1], where
as in the sample
On 08/06/18 02:40, Rico Lin wrote:
Thanks, Zane for putting this up.
It's a great service to expose infrastructure to application, and a
potential cross-community works as well.
>
> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and
Hi I'm building integration with Vitrage webhook and looking for some
clarification on the timestamp precision to expect.
In the sample webhook payload found in doc the resource and the alarm
shows different time stamp precisions:
I've been slowly working on building out and adding to the documentation
about how to do things, but I can make that my top priority so that you all
have a little more guidance. I'll try to get some patches out in the next
week or so.
Storyboard seems complicated but I think most of the mental
Zane Bitter 於 2018年6月9日 週六 上午9:20寫道：
>
> IIUC you're talking about a Heat resource that calls out to a service
> broker using the Open Service Broker API? (Basically acting like the
> Kubernetes Service Catalog.) That would be cool, as it would allow us to
> orchestrate services written for
22 matches
Mail list logo
