nova-orchestration team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

Hi Sandy,

Thanks for the writeup. I have a few clarification questions first:

* deployment model of schedulers: should I consider the diablo release
only support a single scheduler instance? In the next release we can
deploy multiple of them in a stateless way and the way they avoid
concurrency issues is to use the CapacityCache table with DB row
locks?

* nova list performance: do we have some numbers to support that the
performance is an issue? My experience with query performance at 100k
rows with the right indexes built is not that bad. Also my first
impression is that you are maintaining a materialized view
(de-normalized pre-computed table). That means that it's information
is available for elsewhere in the db. But later you mentioned that you
need notifier to update state when new instances are created. That
sounds like new information that didn't exist in the db. Did I
mis-understand this?

* trusted zone: what is the information you want to leak from a child
zone to a parent zone? Who will be on the receiving end at the parent?

Thanks,

Yun

On Thu, Dec 1, 2011 at 6:53 AM, Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx> wrote:
> Hi y'all,
>
> Attached are some notes from the whiteboard noodling myself, comstud and anotherjesse did last week:
> http://wiki.openstack.org/EssexSchedulerImprovements
>
> It addresses some tactical problems we're facing and, hopefully, sets up a pattern for further improvements and hooks for things like orchestration.
>
> Look forward to your feedback!
>
> Cheers,
> Sandy
>
> --
> Mailing list: https://launchpad.net/~nova-orchestration
> Post to     : nova-orchestration@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova-orchestration
> More help   : https://help.launchpad.net/ListHelp