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

[Alan Pevec]

On Tue, Mar 20, 2018 at 12:57 PM, Gabriele Cerami <gcerami at redhat.com> wrote:
> I understand there is a lot of confusion at the moment as we are closing our
> sprint, and pushing our reviews.

Thanks for the reply, let's keep this discussion going on the list.

> I started this thread with the best intentions, but I started it too late.
> We did not formally discuss about this integration in details during our planning
> meeting, and especially after the last reply, I realized that to integrate how
> we would like to, we would have needed to start planning way before.
> We needed to have our full requirements ready, then point out similarities in
> our needs and differences, and plan the changes in the existing to reach the
> level of functionality we needed.

That why the suggestion is to use the process which works well for
openstack-infra,
where every change starts with the spec and is discussed on the list.
I know there is some design done in the TripleO CI trello board, but
IMHO Trello is best used for tracking work and linking to resources
outside, not for writing the full proposal text in the card since it's
missing versioning, voting etc. which you get in Gerrit reviews.

> After David's reply I spent some time trying to reuse part of the existing
> infrastructure playbooks, but it was making too many assumptions that
> turned out to be wrong for us, or would just taken too much work to complete.

Do you have notes about your investigation?
It would be bad to have this effort lost, we definitely want to have
proper generic infra.
RDO Infra backlog is tracked in BZ
https://bugzilla.redhat.com/buglist.cgi?component=Infrastructure&product=RDO
please file bugs there for specific issues you have noticed.

> I tried to see how we could take advantage of the existing logserver, but again
> adapting our custom scripts needed too much time.
> All this while we were also trying to better define *OUR* requirements for the
> sprint especially from a security point of view.
>
> At this point, we can assume that the integration, as I proposed, and envisioned,
> is not happening, certainly not in this sprint. And for various reasons:
> 1) It wasn't formally accepted from both parts. I appreciated the openings from
> David, but we didn't reach any consensus. I didn't hear from anyone except David.
> There was informal acceptance in our team, but we didn't have time to set a roadmap.
> It's not fair to take this thread as roadmap, and ask why we are not following
> this path: our teams never really agreed to do what's written here. To be honest
> I really thought this wasn't the direction we wanted to move to, since there wasn't
> a definitive OK. I thought this was still just a proposal.
> 2) As I stated, this would have required a lot more efforts at least in the
> initial phase. My proposal came at the end of the week reserved to the design
> part of the sprint, because that's when I realized we could have done a lot
> together, but it was opening too many fronts, required a different direction, and
> it was too late to steer the whole sprint.
> 3) There is a lot more to iron out on some topics, like the bastion/jumphost, as
> they are mutually exclusive visions, and our requirements here conflict.
>
> I would really have liked this to happen, but we really need a lot more discussion
> in this thread than actually happened until now, before we can consider this the
> effective path.

I understand the pressure to deliver in the sprint, I'm just concerned
that we are adding more tech debt which will never be revisited.
Could we plan some future sprints dedicated to tech debt removal?

Cheers,
Alan