[rdo-dev] RDO infra/TripleO-CI teams integration level on infrastructure

[Wesley Hayutin]

On Tue, Mar 6, 2018 at 10:15 AM, Gabriele Cerami <gcerami at redhat.com> 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
> dev at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscribe at lists.rdoproject.org
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20180306/8af12e86/attachment.html>