From: Duncan Thomas
> On 18 May 2017 at 22:26, Rochelle Grober <rochelle.gro...@huawei.com>
> wrote:
> > If you're going to use --distance, then you should have specific values
> (standard definitions) rather than operator defined:
> > And for that matter, is there something better than distance? Collocated
> maybe?
> >
> > colocated={local, rack, row, module, dc} Keep the standard definitions
> > that are already in use in/across data centers
>
> There's at least 'chasis' that some people would want to add (blade based
> stuff) and I'm not sure what standard 'module' is... The trouble with standard
> definitions is that your standards rarely match the next guy's standards, and
> since some of these are entirely irrelevant to many storage topologies,
> you're likely going to need an API to discover what is relevant to a specific
> system anyway.
Dang. Missed the chassis. Yeah. So, module/pod/container is the fly/crane in
the container already built to add onto your larger DC. But, I think the key
is that if we came up with a reasonable list, based on what Ops know and use,
then each operator can choose to use what is relevant to her and ignore the
others. More can be added by request. But the key is that it is a limited set
with a definition of each term.
I also agree that storage doesn't neatly fit into a distance relationship. It
can be everywhere and slow, local and slow, some distance and fast, etc.
Actually, the more I think about this, this may be part of the placement
conundrum. Does this/how does this map to terms and decisions made in the
placement subproject?
--Rocky
>
> --
> Duncan Thomas
>
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
