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