Looking at the conductor code it still to me provides a low level database API
that succumbs to the same races as a the old db access did. Get calls followed
by some response followed by some python code followed by some rpc update
followed by more code is still susceptible to consistency & frag
o:harlo...@yahoo-inc.com]
>> Sent: 17 July 2013 14:57
>> To: OpenStack Development Mailing List
>> Cc: OpenStack Development Mailing List
>> Subject: Re: [openstack-dev] Moving task flow to conductor - concern about
>> scale
>>
>> Hi Phil,
>>
>&g
This seems to me to be a good example where a library "problem" is leaking into
the openstack architecture right? That is IMHO a bad path to go down.
I like to think of a world where this isn't a problem and design the correct
solution there instead and fix the eventlet problem instead. Other la
On Fri, Jul 19, 2013 at 4:36 PM, Joshua Harlow wrote:
> This seems to me to be a good example where a library "problem" is leaking
> into the openstack architecture right? That is IMHO a bad path to go down.
>
> I like to think of a world where this isn't a problem and design the correct
> solut
On 19 July 2013 22:55, Day, Phil wrote:
> Hi Josh,
>
> My idea's really pretty simple - make "DB proxy" and "Task workflow" separate
> services, and allow people to co-locate them if they want to.
+1, for all the reasons discussed in this thread. I was weirded out
when I saw non-DB-proxy work be
> Nova-conductor is the gateway to the database for nova-compute
> processes. So permitting a single nova-conductor process would
> effectively serialize all database queries during instance creation,
> deletion, periodic instance refreshes, etc.
FWIW, I don't think anyone is suggesting a single
On Fri, Jul 19, 2013 at 10:15 AM, Dan Smith wrote:
>
> > So rather than asking "what doesn't work / might not work in the
> > future" I think the question should be "aside from them both being
> > things that could be described as a conductor - what's the
> > architectural reason for wanting to ha
> -Original Message-
> From: Dan Smith [mailto:d...@danplanet.com]
> Sent: 19 July 2013 15:15
> To: OpenStack Development Mailing List
> Cc: Day, Phil
> Subject: Re: [openstack-dev] Moving task flow to conductor - concern about
> scale
>
> > There's noth
On Jul 19, 2013 9:57 AM, "Day, Phil" wrote:
>
> > -Original Message-
> > From: Dan Smith [mailto:d...@danplanet.com]
> > Sent: 19 July 2013 15:15
> > To: OpenStack Development Mailing List
> > Cc: Day, Phil
> > Subject: Re: [openstack-d
> I had assumed that some of the task management state would exist
> in memory. Is it all going to exist in the database?
Well, our state is tracked in the database now, so.. yeah. There's a
desire, of course, to make the state transitions as
idempotent/restartable as possible, which may mean driv
On Fri, Jul 19, 2013 at 11:06 AM, Dan Smith wrote:
> FWIW, I don't think anyone is suggesting a single conductor, and
> especially not a single database proxy.
This is a critical detail that I missed. Re-reading Phil's original email,
I see you're debating the ratio of nova-conductor DB proxies t
> There's nothing I've seen so far that causes me alarm, but then
> again we're in the very early stages and haven't moved anything
> really complex.
The migrations (live, cold, and resize) are moving there now. These are
some of the more complex stateful operations I would expect conductor
to ma
17 July 2013 14:57
> To: OpenStack Development Mailing List
> Cc: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Moving task flow to conductor - concern about
> scale
>
> Hi Phil,
>
> I understand and appreciate your concern and I think everyone is trying to
&g
> -Original Message-
> From: Dan Smith [mailto:d...@danplanet.com]
> Sent: 16 July 2013 14:51
> To: OpenStack Development Mailing List
> Cc: Day, Phil
> Subject: Re: [openstack-dev] Moving task flow to conductor - concern about
> scale
>
> > In the original c
Hi Phil,
I understand and appreciate your concern and I think everyone is trying to keep
that in mind. It still appears to me to be to early in this refactoring and
task restructuring effort to tell where it may "end up". I think that's also
good news since we can get these kinds of ideas (com
> In the original context of using Conductor as a database proxy then
> the number of conductor instances is directly related to the number
> of compute hosts I need them to serve.
Just a point of note, as far as I know, the plan has always been to
establish conductor as a thing that sits between
Hi Folks,
Reviewing some the changes to move control flows into conductor made me wonder
about an issue that I haven't seen discussed so far (apologies if it was and
I've missed it):
In the original context of using Conductor as a database proxy then the number
of conductor instances is direct
17 matches
Mail list logo
