[racktables-users] Re: Subnets to automatically inherit tags
- From: Rob Walker <rwalker@xxxxxxxxxxxxxxxxxxx>
- To: Chris James <chris@xxxxxxxxxxxx>
- Date: Tue, 8 Jul 2014 17:50:06 +0000
On 7/8/14 10:40 AM, Chris James wrote:
> Rob,
>
> Thanks for the reply.
> I am not sure I have ever done an RFE in the bugtracker. I guess I can
> give that a try.
>
> Other answers:
>
> 1) Have not thought about that. For my purposes it would not matter. I
> am thinking in terms of subnets, lets say you have a /20, then 2x 21,
> then 2x 24, then 8x 28. You add a tag to the one of the 24s, all 28s
> under are tagged. If you add a tag to the /20, then everything inherits
> that tag.
It sounds like you are only talking about IP address tags, not tags in
general. I use tags to denote building as well. Only IPv4, or both
IPv4 and IPv6? Maybe the workflow could be that when you create
something that is a child, the UI could have a checkbox that is "inherit
all parent tags". The same would go for adding a tag to a parent, "add
to all children"
> 2) I do not think a tag should be removed that was not created
> implicitly for that sub-net. Again everything smaller than the item
> tagged must inherit.
Yeah, this is where things get interesting and I get confused. For IPv4
addresses and IPv6 addresses, "bigger" and "smaller" makes sense, and I
think I could see how it goes. But for buildings and OSes and disk
chassis and other things like that, maybe it doesn't. Why would you
force this inheritance? Maybe I am giving subnet A, B, C to customer 1,
while subnet D needs to go to customer 2, while the higher level subnet
was already tagged at customer 1. Also, I'm thinking about location
tags, and when I start to use IPv4 /30 networks to go between buildings,
that building tag that started getting inherited is a no-go.
> 3) No change at all.
No change to tags at all. Interesting. I don't know yet what I think
about that. I'll have to let it percolate for a while. My opinions
don't really matter, it's up to the developers, they seem to be pretty
good on this RackTables stuff. :-)
Here's how I would work around if right now if this were my problem.
I'd dig into the RackTables API and figure out how to read the tags of
objects. Then I'd write a report that could be run and say, "Here's
some children that need to have their tags sync'd up with their
parents", and have that run via a cgi on a web page. Check the web page
with nagios, if there's an error, send an email to your networking team
to go click away and get their rules followed.
Rob
>
> Thoughts?
>
> -Chris.
>
> On Tue, Jul 8, 2014 at 10:31 AM, Rob Walker <rwalker@xxxxxxxxxxxxxxxxxxx
> <mailto:rwalker@xxxxxxxxxxxxxxxxxxx>> wrote:
>
> Chris,
>
> I think it's a great idea. I'd like to see it myself. Have you filed
> an RFE for it in the bugtracker?
>
> Since you have thought this through more than I have, maybe you could
> clear up some questions I have about where you think this should go?
>
> 1. Do you think that the children should inherit all of the the tags of
> the parent, or should only some tags be marked as "inheritable"?
>
> 2. When a tag is inherited, do you think it would be added to the child
> as a first class tag on that child object, or would it only be shown
> there? As an example, when I want to remove the tag from one child, but
> not all, would I go to the child and remove that tag? If so, when I
> want to remove a tag that has been inherited to many children, do I have
> to go to each child individually, or just go to the parent and delete
> the relationship from there?
>
> 3. Do you think that this would mean that there are two kinds of tags,
> inherited / inheritable and normal? Or do you think that there would be
> an attribute applied to a tag, called "inheritable / not inheritable"?
> Or no change at all?
>
> Thanks for your insight on this.
>
> Rob
>
>
> On 7/8/14 9:16 AM, Chris James wrote:
> > No one has any thoughts on this?
> >
> > On Wed, Jul 2, 2014 at 9:26 AM, Chris James <chris@xxxxxxxxxxxx
> <mailto:chris@xxxxxxxxxxxx>
> > <mailto:chris@xxxxxxxxxxxx <mailto:chris@xxxxxxxxxxxx>>> wrote:
> >
> > Hey all, I greatly appreciate help in advance.
> >
> > The IPv4 organizational problem:
> > Multiple large subnets
> > Multiple locations
> >
> > The racktables solution:
> > Create a network, lets say a /20, tag with "BLAHBLAH"
> > Create 4 subnets, each a /22 Tag each /22 as Location1,
> Location2, etc.
> > create a /29 within location2 Tag with "Info1"
> > Sometimes forget to also tag with location or blahblah tags (for
> > filtering purposes)
> >
> > Possible to automatically inherit parent tags from the larger
> network?
> >
> >
> > -Chris
> >
> >
> >
> > This e-mail message may contain confidential or legally privileged
> > information and is intended only for the use of the intended
> > recipient(s). Any unauthorized disclosure, dissemination,
> distribution,
> > copying or the taking of any action in reliance on the information
> > herein is prohibited. E-mails are not secure and cannot be
> guaranteed to
> > be error free as they can be intercepted, amended, or contain viruses.
> > Anyone who communicates with us by e-mail is deemed to have accepted
> > these risks. This company is not responsible for errors or
> omissions in
> > this message and denies any responsibility for any damage arising from
> > the use of e-mail. Any opinion and other statement contained in this
> > message and any attachment are solely those of the author and do not
> > necessarily represent those of the company.
>
>
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended
> recipient(s). Any unauthorized disclosure, dissemination, distribution,
> copying or the taking of any action in reliance on the information
> herein is prohibited. E-mails are not secure and cannot be guaranteed to
> be error free as they can be intercepted, amended, or contain viruses.
> Anyone who communicates with us by e-mail is deemed to have accepted
> these risks. This company is not responsible for errors or omissions in
> this message and denies any responsibility for any damage arising from
> the use of e-mail. Any opinion and other statement contained in this
> message and any attachment are solely those of the author and do not
> necessarily represent those of the company.
Other related posts:
