Open Stack

> On Tue, Jul 21, 2020 at 09:30:19AM -0700, Clark Boylan wrote:
> > One specific concern along these lines is we've added https support
> > to the mirrors.
> 
> Another thing I can see coming is kafs support; which requires recent
> kernels but is becoming available in Debian.  Just another area we'll
> probably want to play in that is distro specific.
> 
> > Would RDO expect us to coordinate upstream changes to the mirrors
> > with them?
> 
> Perhaps we should quantify what the bits are we need?
> 
> As I mentioned, I've been shy to move the openafs roles outside
> system-config because they rely on debs/rpms built specifically by us
> to work around no-packages (rpm) or out of date packages (deb).  I
> don't want anyone to think they're generic then we break something
> when we update the packages for our own purposes.
> 
> There isn't really any magic in the the apache setup done in the
> mirror role; it's more or less a straight "install packages put config
> in" role.  That argument cuts both ways -- it's not much for
> system-config to maintain but it's not really much to duplicate
> outside.
> 
> The mirror config I can see us wanting to be in sync with.  I'd be
> happy to move that into a separate role, with a few paramaters to make
> it write out in different locations, etc. instead of lumping it all in
> with the server setup?
> 
> Is that a compromise position between keeping centos servers in
> system-config and making things reusable?  Are there other roles of
> concern?
> 

This could work. Besides the kerberos-client and openafs-client roles (which should be relatively straightforward to replicate if needed), that would be all we need to keep the configuration in sync.

Regards,
Javier

> -i
> 
> 
>