On Wed, 15 Jan 2014 11:11:51 -0700 Tim Flink <tflink@xxxxxxxxxx> wrote: > The one thing that isn't part of that diagram is some sort of > lockbox-ish host for managing and monitoring the clients. I'm still > not sure how we want to configure all that (we had talked about > putting everything but the clients in the infra playbook on lockbox01 > and managing the clients with a different playbook on a different > host but none of that has been done), though but I suspect that is > one of the _simpler_ parts of the setup. Could be yeah. I am planning on making a lockbox01.qa after our conversation the other day... ...snip.... > > Could we just do it with a private libvirt network on the qa > > virthosts? ie, pick 172.31.17.0 and put them all in that and setup a > > bastion host as their gateway that does NAT for them out to the > > stuff they need. Or would NAT not work for this? They would still > > physically be on the qa network tho, so I guess we could try and > > request a real seperate one from RHIT. > > I'm not sure I understand this completely. Would this allow the > various "special" hosts (beaker server and bastion host in > particular) to connect to the clients without adding the step of > "connect to virthostX" before being able to ssh into the clients? Sure, they would just use the bridge on the virthosts to send their private network stuff around, but it would be traveling on the same physical network as the 10.5.124.x qa network. > NAT should work for everything other than communication with the > beaker server and bastion hosts. Right. > Another option might be to use ebtables. I haven't investigated this > fully yet but it sounds like it would allow the use of qa network IPs > but restrict the traffic running through the bridged network on the > virthosts - effectively creating a restricted network without needing > any physical changes. Of course, that would only work with VM clients > but that's all we're planning for at the moment. Yeah, that was essentially what I was suggesting above actually. ;) > > There was also talk about redoing a lot of our network setup a while > > back, but not sure where that went. The thought was to completely > > seperate Fedora from anything else (which would be great), but would > > require rework on a bunch of things. Once it's done however, we > > could not have to care as much about adding new private nets, etc. > > That sounds like it would end up in a good place for isolating the > clients but it also sounds like a lot of work. On the other hand, this > "lull" between actively working on releases might be a "less bad" time > to do major changes like that but I'll refrain from commenting more on > it since I'd likely not be the one doing all the work. Yeah. Lots of other things in the mix and it's also something that would have to weigh on RHIT networking folks more, so we will see. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
