On Tue, Mar 6, 2018 at 10:15 AM, Gabriele Cerami <[email protected]> wrote:
> Hi, > > TripleO CI team had a design session yesterday on the tasks for the > current sprint, which is addressing infra. > There are some open questions left, because we had important roles in > the team unavailable, and because we had to create and reprioritize some > of the cards yesterday, due to design decisions. > I think the questions involve the rdo infra people, especially the > second. But in general, I'd like to understand what level of > integration we want between the two groups regarding all the things > related to infrastructure servers. > > 1) We spoke about bastion host. We forgot to create a card for it during > planning, and yesterday we failed to agree on the scope of the task. > Bastion host is a precise security element, with certain rules which have > to be respected for it to be useful. The bastion host is the single > access point to all the other servers on the infrastructure, it's the > only one possessing a public ip, and that means that *EVERYTHING* needs > It would make more sense to me to have any of the dashboard or web servers have a public ip but everything else locked down, even ssh if needed. I don't think we should try to run webservices via a reverse proxy on that bastion. The bastion *should* be used for instances that we *do* need to log into. > to get through it: logs exposure, web pages access (sova included), ssh > access. Implementing it will take more time, also because we have to > understand for example if sova will work behind a reverse proxy > without modifications. > The card tracking the bastion is here > https://trello.com/c/xuRVmCDr/622-setup-teardown-tooling-bastion-host > So the question is: is the bastion host in scope, or we have something > different in mind when we talked about it ? > We also more or less agreed that the bastion host will be present only > on the infra tenant, not on the nodepool tenant, in which it would > serve to bastion only the te-broker. So the te-broker will be > completely exposed, and it will have a public ip > > 2) We understood that we need a common set of roles that will set up > common aspect of every server in infra: credentials, networks, > continuous deployment setup. The role will store a file with keys for > example, and this file will be used to setup all the other servers (or > only the bastion host) > This task is tracked here, but we had to reprioritize the card, as this > is the common ground to all the other "server setup" cards. > https://trello.com/c/BxUTetSu/612-tooling-to-setup-networks- > keys-etc-in-openstack-nodepool-and-tripleo-infra-tenant > While beginning working on this card, yesterday I asked a question to > dmsimard, and it showed me the common roles that are already in place to > setup RDO infra servers. These common roles cover 70-80% of this card > already. > The question is: what level of integration we want to achieve between > our two groups ? Can we modify these roles to be a bit more generic so > they can be used in setting up our infrastructure too ? Can we for > example modify the log server to accept logs from remote journald in our > servers, so we can already use the log server to expose our promotion > logs ? > I would certainly hope so. We already agree that rdo infra team needs to > have access to our server in case of need, it makes only sense that we > use something they are already familiar with. > My implementation will be probably very very very similar to what I see > in rdo-infra repository anyway. > > Thanks for any feedback > _______________________________________________ > dev mailing list > [email protected] > http://lists.rdoproject.org/mailman/listinfo/dev > > To unsubscribe: [email protected] > > >
_______________________________________________ dev mailing list [email protected] http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: [email protected]
