Open Stack

Hey Josh,

On 5 May 2017 at 06:09, Joshua Harlow <harlowja at fastmail.com> wrote:
> Blair Bethwaite wrote:
>>
>> On 5 May 2017 at 03:26, Joshua Harlow<harlowja at fastmail.com>  wrote:
>>>
>>> Though technically not horrible it does seem like the various openstack
>>> project APIs should provide there own projections of this same data
>>> (without
>>> needing to scape it, send it to hadoop and then do various projections
>>> there).
>>
>>
>> Consistent APIs to query this data (just Nova and Cinder would do),
>> from the same perspective as the respective schedulers see it as
>> opposed to some kind of error prone scraping, would be brilliant. The
>> cell capacity API has some flavor capacity information (we save that
>> for display: https://status.rc.nectar.org.au/capacity/) but, at least
>> in cellsv1, the capacity information is useless if there are any
>> non-toy nova-scheduler constraints in place, e.g., it doesn't know if
>> a host cannot launch a certain flavor.
>>
>
> Neats yours @ https://status.rc.nectar.org.au/ looks better than ours.
>
> Is that whole code, and data pipeline anywhere in the open?

Yep - https://github.com/NeCTAR-RC/langstroth

> Maybe useful to work on a common project(?) while at the same time putting
> pressure on the projects themselves to get the data out of there schedulers
> (in a queryable manner, one that does not result in spinning up *actual*
> instances, volumes..., but instead tells u how many 'spin ups' could be
> possible or if the spin up u requested could be satisfied).

You can talk to Sam about Langstroth stuff but I guess the first thing
would be to identify any Nectar-specific bits and abstract those out
so we can from the same upstream.

Regarding fleshing out the requirement, maybe we can tack something
into one of the free Forum sessions to explore this? I'm not sure
whether / how much of this Cellsv2 might already help us with as I've
heard it is solving some of the simplicity gripes I mentioned earlier.

-- 
Cheers,
~Blairo