RackTablesUserGuide - Revision history

Adoom42: /* Physical Objects */

2015-06-11T02:42:14Z

Physical Objects

Sgroat at 19:43, 22 April 2015

2015-04-22T19:43:00Z

Sgroat: /* Reversing Rack Numbering */

2015-04-22T19:40:04Z

Reversing Rack Numbering

Sgroat: /* Reversing Rack Numbering */

2015-04-22T19:38:46Z

Reversing Rack Numbering

Sgroat: /* Rackspace */

2015-04-22T19:37:54Z

Rackspace

Mcastanien: /* Example Scenarios */

2013-08-29T01:30:17Z

Example Scenarios

Grin: snmp sync

2012-10-25T06:49:33Z

snmp sync

Adoom42: /* Port and links */

2012-08-19T17:28:23Z

Port and links

Andriyanov: /* Automatic tags */

2012-08-09T16:04:37Z

Automatic tags

Infrastation: - temporal feature

2012-02-18T08:20:53Z

- temporal feature

@@ Line 83: / Line 83: @@
 == Physical Objects ==
-New object types include Network chassis and Server chassis.
+Object types include Network chassis and Server chassis.
 Common container scenarios:
@@ Line 91: / Line 91: @@
 When mousing over the container object's name in the rackspace area, the hover displays a list of all contained objects.  Only immediate children are listed, grand-children, great-grand-children, etc. are not.
 == Virtual Objects ==

@@ Line 53: / Line 53: @@
 === Reversing Rack Numbering ===
-Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a [[RackCode]] expression and can be a tag "{tag}" or "true" or "false" for global configuration.
+Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a [[#RackCode|RackCode]] expression and can be a tag "{tag}" or "true" or "false" for global configuration.
 == Rack problems tab ==

@@ Line 53: / Line 53: @@
 === Reversing Rack Numbering ===
-Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a [RackCode] expression and can be a tag "{tag}" or "true" or "false" for global configuration.
+Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a [[RackCode]] expression and can be a tag "{tag}" or "true" or "false" for global configuration.
 == Rack problems tab ==

@@ Line 53: / Line 53: @@
 === Reversing Rack Numbering ===
-Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a RackCode expression and can be a tag "{tag}" or "true" or "false" for global configuration.
+Rack numbering can be reversed through the global configuration parameter REVERSED_RACKS_LISTSRC available at Configuration->User interface. This value is a [RackCode] expression and can be a tag "{tag}" or "true" or "false" for global configuration.
 == Rack problems tab ==

@@ Line 51: / Line 51: @@
 == Rack design tab ==
 Rack design defines the physical layout of a rack cabinet. Most common reason to use the tab is absence of back rails, although any other design can be defined. In this tab you can change mounting atoms' state between 'free' and 'absent'. A selected checkbox means atom presence.
 == Rack problems tab ==

@@ Line 137: / Line 137: @@
 ** ProdAppServer1 (VM)
 ** ProdAppServer2 (VM)
 ----

← Older revision		Revision as of 06:49, 25 October 2012
Line 60:		Line 60:

	The feature allows matching description of each IP address of the current IP subnet with DNS PTR record, resolved online. !RackTables highlights each address accordingly to its current description and DNS data; however, it is a rough estimation if each particular description is correct or not. It is left up to the user to decide, if DNS data, as more accurate, should be imported into DB.		The feature allows matching description of each IP address of the current IP subnet with DNS PTR record, resolved online. !RackTables highlights each address accordingly to its current description and DNS data; however, it is a rough estimation if each particular description is correct or not. It is left up to the user to decide, if DNS data, as more accurate, should be imported into DB.
		+	----
		+
		+	= SNMP Sync =
		+	It is possible to initialise switch port and system data through SNMP on freshly created objects. If the switch model is known for RackTables (either as a part of the distribution or through [[RackTablesDevelGuide#SNMP_sync\|local admin magic]]) and accessible through SNMP then by using the SNMP Sync tab Racktables try to connect the switch by version1, version2c or version3 protocol, using the user provided community (and/or authentication data) for access (the community can be set in general configuration) and fills the port data, firmware version etc.
		+
		+	The host used first looked up in the FQDN field, then if empty in the first IP adderess assigned to the object.
	----		----

@@ Line 1: / Line 1: @@
 = Port and links =
-A port or physical interface is a small thingy on your box you can connect a cable to.
+A port or physical interface is part of an object which you can connect a cable to. Each port can have a local name, that is how this port is visible from the OS point of view. For a Linux system that will be eth0, eth1, etc. Visible label is what is physically written on the port.
-Depending on the manufacturer you may observe labels as "1", "2", etc or something else.
+Depending on the manufacturer you may observe labels as "1", "2", etc. or something else. Port type is an essential property that allows port connections to be properly arranged. It lets you know that you won't be able to connect optical and copper ports together with one cable. Some ports have an L2 address. It's helpful to populate those, as you may find it handy to find ports by L2 addresses while investigating your STP tree.
-Reserving a port is simply adding a comment to it, thus preventing it to be linked.
+Reserving a port is simply adding a comment to it, thus preventing it to be linked. A good reservation can be "Reserved for a field engineer laptop". Linking ports is creating a connection between them. That is plugging a cable to them. Only ports with compatible types can be linked. Say, RJ-45/100-Base TX can be linked to RJ-45/1000-Base TX, but can't be linked to LC/100-BASE FX. In many cases you'll need to add a bunch of ports from a switch. In this case there is a text area and a format selector. Just choose your device and format, paste the output to the textarea and click "Parse output" button. Also, you need to choose which port type is to be used, since it's not possible to guess that from the output.
 ----

@@ Line 160: / Line 160: @@
 == Automatic tags ==
-Autotags aren't shown by default, this may be changed on the "user interface" config page. Below is the list of currently used autotags.
+Autotags aren't shown by default, this may be changed on the "user interface" config page. Below is the list of currently used autotags (as for 0.20.0).
 ;$page_something
 : Always set; "something" is the name of the current page.
@@ Line 170: / Line 171: @@
 ;$any_op
 : Set, if any operation is being processes. Having this autotag in a deny rule '''should''' (not finished yet) block all modifications to the database.
 ;$userid_000
 : Numerical user ID of the current user account, if the account exists in the local database.
 ;$username_somename
 : Username of the current user.
 ;$any_object
 : Always present in all views for objects (isn't it equivalent to $page_object?).
@@ Line 182: / Line 211: @@
 ;$cn_somename
 : '''If''' an object has such a common name "somename", which makes the above string be a valid tag name, this autotag is added to the context.
 ;$any_file
 : Set, when current focus is a file.
 ;$fileid_000
 : Holds file ID, if the current focus is a file.
 ;$any_rsp
-: set for all RS pools (which is now the same as $any_ipv4rsp, and will change only after IPv6 implementation)
+: set for all RS pools (which is the same as $any_ipv4rsp)
 ;$any_ipv4rsp
-: set for IPv4 RS pools
+: set for all RS pools (RS pools can contain both IPv4 and IPv6 addresses)
 ;$ipv4rspid_000
 : set to RS pool ID
-;$any_vs
+;$unused
-: set for any virtual service (likewise, there is no current IPv6 implementation)
+: set for such RS poold which do not have any Virtual Service-Load Balancer links
-;$any_ipv4vs
-: set for any IPv4 VS
+=== Operation-specific tags ===
 ;$fromvlan_NNNN
 : Set, when a port is being removed from VLAN with the given VLAN ID (by means of LiveVLANs or 802.1Q ports feature).

← Older revision		Revision as of 08:20, 18 February 2012
Line 222:		Line 222:
	;$vlan_NNNN		;$vlan_NNNN
	: Likewise, when a port is being either added OR removed, equivalent to "{$fromvlan_NNNN} or {$tovlan_NNNN}" RackCode expression.		: Likewise, when a port is being either added OR removed, equivalent to "{$fromvlan_NNNN} or {$tovlan_NNNN}" RackCode expression.
−
−	~~= Temporal feature (frozen) =~~
−	~~One of new feature arriving us Temporal feature or as sometimes called Time machine.~~
−
−	The idea is to make almost all things (Racks, RackObjects, Ports, Links, IP Addresses, etc.) have complete history of changes. We will call those "things" just "objects". Then, if someone wants to see what was an object before, he or she would have just "rewind" the history and see what was happening some time ago. It's somewhat like Time Machine thingy in MacOS X Leopard.
−
−	~~== Revisions ==~~
−
−	Because of most of the objects are "connected" to each other, for example, a server is mounted into a rack, it's impossible to "rewind" just one object and examine it without rewinding other objects, as it may happen, that connected objects wouldn't even exist back in time. To deal with that, we will not focus on every object version, rather than that we'll have a common timeline and every change of every object would get us a step further on this timeline.
−
−	When we say "every object", we don't actually mean "every". In fact, some objects are not "versionized" this way. User accounts are not versionized, and that's done on purpose. More interestingly, for versionized objects, not every properties are versionized. Sometimes we don't care about history of some properties. But anyways, back to the point...
−
−	So, let's say that every single change of any versionized object moves us forward on the timeline. We'll call those steps "revisions". Revision is a number that represents a point on the timeline. When revision increases we can be sure that something has changed. And, almost anytime, if revision is increased by one, only one object has changed. That's true with one exception. Revision number 0 can have many objects. It's the initial state, and if you are upgrading from previous version, you'll see a lot of objects sitting in that revision.
−
−	~~== Operations ==~~
−
−	Sometimes, a user with a single mouseclick can change multiple objects. For example, if he remounts a server, multiple objects will be changed. To group those changes into one, operations are used. Operation is a group of revisions and only one operation is created by one button click. Operations have numbers too. Mostly, users will deal with operations and user interface represent operations rather than revisions. So for a normal user, operations are quite atomic.
−
−	~~== Milestones ==~~
−
−	Milestones are groups of operations. They are used to finalize a set of operations. A user can set a milestone on the latest operation, like saying "Ok, i've done this work, my repository is in correct state now". Milestones can have comments, and in fact, users should write good comments when they set milestones.
−
−	The suggested practice is the following: User makes some series of changes, then he goes to the history page, reviews what is done, does more changes if necessary and sets a milestone with a good comment, explaining what was done and why. Later on, users can look at the list of the milestones and review changes done.
−
−	~~== User interface ==~~
−
−	~~One major addition to user interface is the temporal panel. It provides functionality for traveling history back and forth. Here it is.~~
−
−	~~[[Image:temporalPanel.png]]~~
−
−	~~The buttons are:~~
−
−	~~'''1'''. Brings you back to one operation. If there is no operation before the current one (i.e. you are in the beginning of the history), it's disabled.~~
−
−	~~'''2'''. Brings you to the closest previous milestone. Again, may be disabled.~~
−
−	'''3'''. Shows the number of the current operation. If the current operation is the last one, i.e. the "head" of the history, this will be a bit greenish. If not in the head, it will be white. Like on this picture.
−
−	~~[[Image:temporalPanel2.png]]~~
−
−	~~'''4'''. If no milestone is registered at the current operation, it will be empty. If one is set, you'll see its number.~~
−
−	~~[[Image:temporalPanel3.png]]~~
−
−	~~'''5'''. Brings you to the closest next milestone.~~
−
−	~~'''6'''. Brings you to the next operation.~~
−
−	~~'''7'''. When in head, shows you the number of operations (say, changes) since the last milestone. Also brings you to the history of all changes since the last milestone if you click on it.~~
−	~~When not in head, it will show the button that will bring you to the head, if clicked.~~
−
−	~~[[Image:temporalPanel1.png]]~~