On Tue, Mar 6, 2018 at 10:15 AM, Gabriele Cerami <gcerami@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@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscribe@lists.rdoproject.org