Send Netdot-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-devel digest..."
Today's Topics:
1. [Netdot - Feature #803] Rack management ([email protected])
2. Re: [Netdot - Feature #803] Rack management (Karl Putland)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Jan 2015 15:02:35 -0800
From: [email protected]
Subject: [Netdot-devel] [Netdot - Feature #803] Rack management
To: [email protected], [email protected], [email protected]
Cc: [email protected], [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Issue #803 has been updated by Anton Berezin.
Carlos Vicente wrote:
> An alternative to the site->floor->room->closet->rack hierarchy is to store
> all of these objects in a single "location" table, in combination with a
> "location_type" table.
> But it has the following problems:
>
> * Code changes touching many tables and UI components
> * There are fields that are only particular to certain tables. For example:
> ** Site has address, city, zip code, etc.
> ** Rack has numbering_direction, ru_size.
> ** etc.
In my view, the generic "location tree" approach is very appealing.
The particularity of certain fields can be solved with a couple
more tables:
<pre>
location_option_spec
--------------------
id
location_type_id
name
description
location_option
---------------
id
location_id
location_option_spec_id
value
</pre>
This collapses all possible extra fields for a location
type into a flat datastructure (with a single datatype
for the "value" column, most likely a sufficiently large
varchar). This will make it harder to implement searching
for options of a particular type only ("find all sites
in city A"), if such functionality is desired.
Both location_type and location_option_spec should be
pre-populated with sensible defaults. It is an open question
whether a UI for manipulating these structural "meta-tables"
is needed at all, at least at first.
Another question is whether the location hierarchy should
be constrained. For example, it would appear that without
any constraints it will be possible to define a site that is
located_in a rack, which does not make sense.
On the other hand, it is not clear how strict this hierarchy
should be. For instance, I would imagine that it should
be possible for a closet to be located_in a site, skipping
the intermediary levels altogether if desired by the user.
Such constraints can be implemented in one of four ways:
1) Add a column "parent_location_type_id" to "location_type".
Posit that the hierarchy is strict (that is, if parent for
a rack is a closet, the rack cannot be placed under a site,
or a room, or anything else).
2) Add a column "parent_location_type_id" to "location_type".
Posit that the hierarchy is relaxed (that is, a rack can be
placed under its specified parent type or under parent's parent,
or under parent's parent's parent and so on).
3) Add columns "parent_location_type_id" and "strict_parent" to
"location_type". This is a combination of (1) and (2).
4) Add another table
<pre>
location_type_hierarchy
-----------------------
id
parent_id
child_id
</pre>
This would allow full specification of what can be located_in what.
What do you think?
----------------------------------------
Feature #803: Rack management
https://osl.uoregon.edu/redmine/issues/803#change-3266
Author: Robin Johansson
Status: New
Priority: High
Assignee: Carlos Vicente
Category: DeviceManagement
Target version: 1.1.0
Resolution:
Would be useful if it was posble to manage rackspace in netdot, similar to what
racktables offer.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://osl.uoregon.edu/redmine/my/account
------------------------------
Message: 2
Date: Tue, 6 Jan 2015 16:11:26 -0700
From: Karl Putland <[email protected]>
Subject: Re: [Netdot-devel] [Netdot - Feature #803] Rack management
To: [email protected]
Cc: [email protected], netdot-devel
<[email protected]>, [email protected], Carlos Vicente
<[email protected]>
Message-ID:
<ca+exwswdi_wshnd6cubozbxijbx0ki-0wk+ocky0vqx3o-4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I would include a parent_location FK so that you could create arbitrary
hierarchies.
--Karl
Karl Putland
Senior Engineer
*SimpleSignal*
Anywhere: 303-242-8608
<http://www.simplesignal.com/explainer_video.php>
On Tue, Jan 6, 2015 at 4:02 PM, <[email protected]> wrote:
>
> Issue #803 has been updated by Anton Berezin.
>
>
> Carlos Vicente wrote:
> > An alternative to the site->floor->room->closet->rack hierarchy is to
> store all of these objects in a single "location" table, in combination
> with a "location_type" table.
>
> > But it has the following problems:
> >
> > * Code changes touching many tables and UI components
> > * There are fields that are only particular to certain tables. For
> example:
> > ** Site has address, city, zip code, etc.
> > ** Rack has numbering_direction, ru_size.
> > ** etc.
>
> In my view, the generic "location tree" approach is very appealing.
>
> The particularity of certain fields can be solved with a couple
> more tables:
>
> <pre>
> location_option_spec
> --------------------
> id
> location_type_id
> name
> description
>
> location_option
> ---------------
> id
> location_id
> location_option_spec_id
> value
> </pre>
>
> This collapses all possible extra fields for a location
> type into a flat datastructure (with a single datatype
> for the "value" column, most likely a sufficiently large
> varchar). This will make it harder to implement searching
> for options of a particular type only ("find all sites
> in city A"), if such functionality is desired.
>
> Both location_type and location_option_spec should be
> pre-populated with sensible defaults. It is an open question
> whether a UI for manipulating these structural "meta-tables"
> is needed at all, at least at first.
>
> Another question is whether the location hierarchy should
> be constrained. For example, it would appear that without
> any constraints it will be possible to define a site that is
> located_in a rack, which does not make sense.
> On the other hand, it is not clear how strict this hierarchy
> should be. For instance, I would imagine that it should
> be possible for a closet to be located_in a site, skipping
> the intermediary levels altogether if desired by the user.
>
> Such constraints can be implemented in one of four ways:
>
> 1) Add a column "parent_location_type_id" to "location_type".
> Posit that the hierarchy is strict (that is, if parent for
> a rack is a closet, the rack cannot be placed under a site,
> or a room, or anything else).
>
> 2) Add a column "parent_location_type_id" to "location_type".
> Posit that the hierarchy is relaxed (that is, a rack can be
> placed under its specified parent type or under parent's parent,
> or under parent's parent's parent and so on).
>
> 3) Add columns "parent_location_type_id" and "strict_parent" to
> "location_type". This is a combination of (1) and (2).
>
> 4) Add another table
>
> <pre>
> location_type_hierarchy
> -----------------------
> id
> parent_id
> child_id
> </pre>
>
> This would allow full specification of what can be located_in what.
>
> What do you think?
>
> ----------------------------------------
> Feature #803: Rack management
> https://osl.uoregon.edu/redmine/issues/803#change-3266
>
> Author: Robin Johansson
> Status: New
> Priority: High
> Assignee: Carlos Vicente
> Category: DeviceManagement
> Target version: 1.1.0
> Resolution:
>
>
> Would be useful if it was posble to manage rackspace in netdot, similar to
> what racktables offer.
>
>
> --
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> http://osl.uoregon.edu/redmine/my/account
> _______________________________________________
> Netdot-devel mailing list
> [email protected]
> https://osl.uoregon.edu/mailman/listinfo/netdot-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://osl.uoregon.edu/pipermail/netdot-devel/attachments/20150106/3e6c5be6/attachment-0001.html
------------------------------
_______________________________________________
Netdot-devel mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-devel
End of Netdot-devel Digest, Vol 94, Issue 6
*******************************************
