Excerpts from Zane Bitter's message of 2016-11-21 15:12:45 -0500:
> On 18/11/16 16:47, Clint Byrum wrote:
> > Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> > I know Monty said this, but I want to say it again: gRPC is just HTTP/2
>
On 11/21/2016 03:36 PM, Zane Bitter wrote:
> On 18/11/16 16:56, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for orchestration. How would I go about e.g.
On 11/21/2016 03:25 PM, Kevin Benton wrote:
>>I'm not saying that you have to supply any IP addresses to the pool.
> Just that only the wilfully contrary should call the internet anything
> other than "internet", and that we should ensure this *in code* instead
> of just hoping that everyone will
On 2016-11-21 15:12:45 -0500 (-0500), Zane Bitter wrote:
[...]
> (Also, the point of floating IPs with access to only the control plane is
> not so instances can access the control plane; it's so that the control
> plane can access the instances without everyone on the internet - or
> whatever
On Tue, Nov 22, 2016 at 9:36 AM, Zane Bitter wrote:
> On 18/11/16 16:56, Clint Byrum wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for
On 18/11/16 16:56, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
So, say that I want to create my servers in Heat so that I can use Heat
software deployments for orchestration. How would I go about e.g. making
sure that the servers are always connected to
>I'm not saying that you have to supply any IP addresses to the pool. Just
that only the wilfully contrary should call the internet anything other
than "internet", and that we should ensure this *in code* instead of just
hoping that everyone will coincidentally choose the same thing (spoiler:
they
On 18/11/16 16:47, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
On 15/11/16 09:56, Monty Taylor wrote:
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people
On 11/18/2016 04:56 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>> On 17/11/16 19:01, Monty Taylor wrote:
>>> On 11/17/2016 05:24 PM, Zane Bitter wrote:
On 15/11/16 09:56, Monty Taylor wrote:
> Hey everybody!
>
> At this past
Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> On 15/11/16 09:56, Monty Taylor wrote:
> > Hey everybody!
> >
> > At this past OpenStack Summit the results of the Interop Challenge were
> > shown on stage. It was pretty awesome - 17 different people from 17
> > different clouds
Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
> On 17/11/16 19:01, Monty Taylor wrote:
> > On 11/17/2016 05:24 PM, Zane Bitter wrote:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> >>> Hey everybody!
> >>>
> >>> At this past OpenStack Summit the results of the Interop Challenge
On 17/11/16 19:01, Monty Taylor wrote:
On 11/17/2016 05:24 PM, Zane Bitter wrote:
On 15/11/16 09:56, Monty Taylor wrote:
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds
On 11/17/2016 05:24 PM, Zane Bitter wrote:
> On 15/11/16 09:56, Monty Taylor wrote:
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17 different people from 17
>> different clouds ran the same workload. And
On 15/11/16 09:56, Monty Taylor wrote:
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!
However, one of the reasons it worked is
around Shade locally will be enough?
Best Regards
Chaoyi Huang (joehuang)
From: Monty Taylor [mord...@inaugust.com]
Sent: 16 November 2016 23:58
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] oaktree - a friendly end-user oriented API
On Wed, Nov 16, 2016 at 9:34 AM, Monty Taylor wrote:
> (there are parts of this that are hand-wavey - but how does it sound in
> general?)
That sounds basically good because that noise I heard last night must
have been you sneaking in and stealing those steps from my white
<openstack-dev@lists.openstack.org>
Date: 11/15/2016 08:42 PM
Subject: Re: [openstack-dev] oaktree - a friendly end-user oriented API
layer - anybody want to help?
On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes <jaypi...@gmail.com> wrote:
Awesome start, Monty :) Comments inlin
On 11/16/2016 09:34 AM, Monty Taylor wrote:
> On 11/15/2016 11:26 PM, joehuang wrote:
>>> Glance Image Uploads and Swift Object Uploads (and downloads). Having
>>> those two data operations go through an API proxy seems inefficient.
>>> However, having them not in the API seems like a bad user
On 11/15/2016 07:16 PM, Jay Pipes wrote:
> Awesome start, Monty :) Comments inline.
Yay - thanks Jay!
> On 11/15/2016 09:56 AM, Monty Taylor wrote:
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17
On 11/15/2016 11:26 PM, joehuang wrote:
>> Glance Image Uploads and Swift Object Uploads (and downloads). Having
>> those two data operations go through an API proxy seems inefficient.
>> However, having them not in the API seems like a bad user experience.
>> Perhaps if we take advantage of the
...@inaugust.com]
Sent: 15 November 2016 22:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] oaktree - a friendly end-user oriented API layer -
anybody want to help?
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown
usage questions)
Subject: [openstack-dev] oaktree - a friendly end-user oriented API layer -
anybody want to help?
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same
On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes wrote:
> Awesome start, Monty :) Comments inline.
>
> On 11/15/2016 09:56 AM, Monty Taylor wrote:
>
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty
Awesome start, Monty :) Comments inline.
On 11/15/2016 09:56 AM, Monty Taylor wrote:
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!
On Tue, Nov 15, 2016 at 8:56 AM, Monty Taylor wrote:
> The auth story. The native/default auth for gRPC is oauth. It has the
> ability for pluggable auth, but that would raise the barrier for new
> languages. I'd love it if we can come up with a story that involves
> making
Great idea, I just ran into a similar issue when investigating the
following Kubernetes issue[1], and the OpenStack provider. They are running
into similar issues around networking and what a "public" network
address is, which is exactly what Shade had to deal with, in the public
clouds that we
Hey everybody!
At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!
However, one of the reasons it worked is because they all used the
Ansible modules we
27 matches
Mail list logo