On 25/05/17 18:34, Matt Riedemann wrote:
On 5/22/2017 11:01 AM, Zane Bitter wrote:
If the user does a stack update that changes the network from 'auto'
to 'none', or vice-versa.
OK I guess we should make this a side discussion at some point, or hit
me up in IRC, but if you're requesting networ
On 05/26/2017 02:53 AM, Chris Friesen wrote:
On 05/19/2017 04:06 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann
wrote:
I'm confused by this. Creating a server takes a volume ID if you're
booting
from volume, and that's actually preferred (by nova devs) since then
Nova
On 05/19/2017 04:06 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann wrote:
I'm confused by this. Creating a server takes a volume ID if you're booting
from volume, and that's actually preferred (by nova devs) since then Nova
doesn't have to orchestrate the creation of the
On 5/23/2017 10:23 AM, Zane Bitter wrote:
Yes! Everything is much easier if you tell all the users to re-architect
their applications from scratch :) Which, I mean, if you can... great!
Meanwhile here on planet Earth, it's 2017 and 95% of payment card
transactions are still processed using COBO
On 5/22/2017 11:01 AM, Zane Bitter wrote:
If the user does a stack update that changes the network from 'auto' to
'none', or vice-versa.
OK I guess we should make this a side discussion at some point, or hit
me up in IRC, but if you're requesting networks='none' with microversion
>= 2.37 then
On 05/20/2017 10:36 AM, Monty Taylor wrote:
On 05/19/2017 03:13 PM, Monty Taylor wrote:
On 05/19/2017 01:53 PM, Sean Dague wrote:
On 05/19/2017 02:34 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote:
These should be used as ways to experiment with the kinds of interfa
On 22/05/17 22:58, Jay Pipes wrote:
On 05/22/2017 12:01 PM, Zane Bitter wrote:
On 19/05/17 17:59, Matt Riedemann wrote:
I'm not really sure what you're referring to here with 'update' and [1].
Can you expand on that? I know it's a bit of a tangent.
If the user does a stack update that changes
On 05/22/2017 12:01 PM, Zane Bitter wrote:
On 19/05/17 17:59, Matt Riedemann wrote:
I'm not really sure what you're referring to here with 'update' and [1].
Can you expand on that? I know it's a bit of a tangent.
If the user does a stack update that changes the network from 'auto' to
'none',
On 05/21/2017 03:56 PM, Monty Taylor wrote:
On 05/19/2017 05:10 PM, Matt Riedemann wrote:
On 5/19/2017 3:35 PM, Monty Taylor wrote:
Heck - while I'm on floating ips ... if you have some pre-existing
floating ips and you want to boot servers on them and you want to do
that in parallel, you can't
On 19/05/17 17:59, Matt Riedemann wrote:
On 5/19/2017 9:36 AM, Zane Bitter wrote:
The problem is that orchestration done inside APIs is very easy to do
badly in ways that cause lots of downstream pain for users and
external orchestrators. For example, Nova already does some
orchestration: it cr
On 05/19/2017 05:10 PM, Matt Riedemann wrote:
On 5/19/2017 3:35 PM, Monty Taylor wrote:
Heck - while I'm on floating ips ... if you have some pre-existing
floating ips and you want to boot servers on them and you want to do
that in parallel, you can't. You can boot a server with a floating ip
th
On Fri, May 19, 2017 at 02:04:05PM -0400, Sean Dague wrote:
You end up replicating the Ceilometer issue where there was a break down
in getting needs expressed / implemented, and the result was a service
doing heavy polling of other APIs (because that's the only way it could
get the data it neede
On 05/19/2017 04:27 PM, Matt Riedemann wrote:
On 5/19/2017 3:03 PM, Monty Taylor wrote:
On 05/19/2017 01:04 PM, Sean Dague wrote:
On 05/19/2017 01:38 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
wrote:
..., but it seems to me that the logical
extension of that is to
On 05/19/2017 03:13 PM, Monty Taylor wrote:
On 05/19/2017 01:53 PM, Sean Dague wrote:
On 05/19/2017 02:34 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote:
These should be used as ways to experiment with the kinds of interfaces
we want cheaply, then take them back into
On 5/19/2017 3:35 PM, Monty Taylor wrote:
Heck - while I'm on floating ips ... if you have some pre-existing
floating ips and you want to boot servers on them and you want to do
that in parallel, you can't. You can boot a server with a floating ip
that did not pre-exist if you get the port id o
On Fri, May 19, 2017 at 4:01 PM, Matt Riedemann wrote:
> I'm confused by this. Creating a server takes a volume ID if you're booting
> from volume, and that's actually preferred (by nova devs) since then Nova
> doesn't have to orchestrate the creation of the volume in the compute
> service and the
On 5/19/2017 9:36 AM, Zane Bitter wrote:
The problem is that orchestration done inside APIs is very easy to do
badly in ways that cause lots of downstream pain for users and external
orchestrators. For example, Nova already does some orchestration: it
creates a Neutron port for a server if yo
On 5/19/2017 3:03 PM, Monty Taylor wrote:
On 05/19/2017 01:04 PM, Sean Dague wrote:
On 05/19/2017 01:38 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
wrote:
..., but it seems to me that the logical
extension of that is to expose simple orthogonal APIs where the nova
On 5/19/2017 1:04 PM, Sean Dague wrote:
Anyway, this gets pretty meta pretty fast. I agree with Zane saying "I
want my server to build", or "I'd like Nova to build a volume for me"
are very odd things to call PaaS. I think of PaaS as "here is a ruby on
rails app, provision me a db for it, and mak
Started a new Neutron-specific thread so we can get some stuff turned into
improvements in Neutron from this:
http://lists.openstack.org/pipermail/openstack-dev/2017-May/117112.html
On Fri, May 19, 2017 at 1:05 PM, Zane Bitter wrote:
> On 19/05/17 15:06, Kevin Benton wrote:
>
>> Don't even get m
On 5/19/2017 12:38 PM, Dean Troyer wrote:
First and foremost, we need to have the primitive operations that get
composed into the higher-level ones available. Just picking "POST
/server" as an example, we do not have that today. Chris mentions
above the low-level version should take IDs for all
On 05/19/2017 03:05 PM, Zane Bitter wrote:
On 19/05/17 15:06, Kevin Benton wrote:
Don't even get me started on Neutron.[2]
It seems to me the conclusion to that thread was that the majority of
your issues stemmed from the fact that we had poor documentation at the
time. A major component of t
On 05/19/2017 01:53 PM, Sean Dague wrote:
On 05/19/2017 02:34 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote:
These should be used as ways to experiment with the kinds of interfaces
we want cheaply, then take them back into services (which is a more
expensive process
On 19/05/17 15:06, Kevin Benton wrote:
Don't even get me started on Neutron.[2]
It seems to me the conclusion to that thread was that the majority of
your issues stemmed from the fact that we had poor documentation at the
time. A major component of the complaints resulted from you
misunderstan
On 05/19/2017 01:04 PM, Sean Dague wrote:
On 05/19/2017 01:38 PM, Dean Troyer wrote:
On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
wrote:
..., but it seems to me that the logical
extension of that is to expose simple orthogonal APIs where the nova boot
request should only take neutron port i
>Don't even get me started on Neutron.[2]
It seems to me the conclusion to that thread was that the majority of your
issues stemmed from the fact that we had poor documentation at the time. A
major component of the complaints resulted from you misunderstanding the
difference between networks/subn
On 05/19/2017 02:34 PM, Dean Troyer wrote:
> On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote:
>> These should be used as ways to experiment with the kinds of interfaces
>> we want cheaply, then take them back into services (which is a more
>> expensive process involving compatibility stories, de
On Fri, May 19, 2017 at 1:04 PM, Sean Dague wrote:
> These should be used as ways to experiment with the kinds of interfaces
> we want cheaply, then take them back into services (which is a more
> expensive process involving compatibility stories, deeper documentation,
> performance implications,
Excerpts from Clark Boylan's message of 2017-05-19 10:03:23 -0700:
> On Fri, May 19, 2017, at 05:59 AM, Duncan Thomas wrote:
> > On 19 May 2017 at 12:24, Sean Dague wrote:
> >
> > > I do get the concerns of extra logic in Nova, but the decision to break
> > > up the working compute with network a
On 05/19/2017 01:38 PM, Dean Troyer wrote:
> On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
> wrote:
>> ..., but it seems to me that the logical
>> extension of that is to expose simple orthogonal APIs where the nova boot
>> request should only take neutron port ids and cinder volume ids. The ac
On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
wrote:
> ..., but it seems to me that the logical
> extension of that is to expose simple orthogonal APIs where the nova boot
> request should only take neutron port ids and cinder volume ids. The actual
> setup of those ports/volumes would be done
On Fri, May 19, 2017, at 05:59 AM, Duncan Thomas wrote:
> On 19 May 2017 at 12:24, Sean Dague wrote:
>
> > I do get the concerns of extra logic in Nova, but the decision to break
> > up the working compute with network and storage problem space across 3
> > services and APIs doesn't mean we shoul
On 05/19/2017 07:18 AM, Sean Dague wrote:
There was a conversation in the Cell v2 discussion around searchlight
that puts me more firmly in the anti enamel camp. Because of some
complexities around server list, Nova was planning on using Searchlight
to provide an efficient backend.
Q: Who in th
On 18/05/17 20:19, Matt Riedemann wrote:
I just wanted to blurt this out since it hit me a few times at the
summit, and see if I'm misreading the rooms.
For the last few years, Nova has pushed back on adding orchestration to
the compute API, and even define a policy for it since it comes up so
m
On 05/19/2017 09:04 AM, Chris Dent wrote:
> On Fri, 19 May 2017, Duncan Thomas wrote:
>
>> On 19 May 2017 at 12:24, Sean Dague wrote:
>>
>>> I do get the concerns of extra logic in Nova, but the decision to break
>>> up the working compute with network and storage problem space across 3
>>> servi
On Fri, 19 May 2017, Duncan Thomas wrote:
On 19 May 2017 at 12:24, Sean Dague wrote:
I do get the concerns of extra logic in Nova, but the decision to break
up the working compute with network and storage problem space across 3
services and APIs doesn't mean we shouldn't still make it easy to
On 19 May 2017 at 12:24, Sean Dague wrote:
> I do get the concerns of extra logic in Nova, but the decision to break
> up the working compute with network and storage problem space across 3
> services and APIs doesn't mean we shouldn't still make it easy to
> express some pretty basic and common
On 05/18/2017 08:19 PM, Matt Riedemann wrote:
> I just wanted to blurt this out since it hit me a few times at the
> summit, and see if I'm misreading the rooms.
>
> For the last few years, Nova has pushed back on adding orchestration to
> the compute API, and even define a policy for it since it
Matt Riedemann wrote:
> [...]
> Am I missing the point, or is the pendulum really swinging away from
> PaaS layer services which abstract the dirty details of the lower-level
> IaaS APIs? Or was this always something people wanted and I've just
> never made the connection until now?
I feel like th
I just wanted to blurt this out since it hit me a few times at the
summit, and see if I'm misreading the rooms.
For the last few years, Nova has pushed back on adding orchestration to
the compute API, and even define a policy for it since it comes up so
much [1]. The stance is that the compute
40 matches
Mail list logo
