1:03 p.m.
I wanted to share a portion of a conversation with folks here, and ask
for some help.
To summarize, it's confusing to people who are not part of the process
(and often for people who are) where all of the pieces of the RDO
process live, what they do, how they talk to one another, and so on.
Because of how RDO has evolved, and interacted with other parties
(Fedora, CentOS, upstream OpenStack, Trystack, and now the rpm-packaging
upstream project, and probably other things I'm forgetting) it can feel,
sometimes, that there's some magic involved.
I'd like to bring more clarity to this with some docs, some diagrams,
and whatever else we need to do, both to bring more transparency to the
process, and to help people who are trying to get involved, find their
way. I could definitely use your help in making that happen.
--Rich
-------- Forwarded Message --------
On 09/18/2015 05:49 AM, Rich Bowen wrote:
>>> * One of the criticisms against RDO at the moment is the lack of real
>>> transparency and confusion as to the infrastructure and systems that
>>> power it.
I'm curious where you're seeing this criticism, as I haven't seen it at
all. I'll take this as an action item to thoroughly document the
infrastructure and systems that power RDO, but I was completely unaware
that this was a concern.
It's been mentioned to me by operators that I've spoken to at Meetups
and the like. It's more of a casual observation from users who are more
interested in contributing and being a part of RDO.
If you look at Fedora as an example, all the infrastructure is exposed,
they have things like bohdi and koji that allow you to directly see and
"touch" the entire process used to ship Fedora. You can very easily
follow the process code goes through the whole system to get out the
door (and the documentation of how it all works is very good).
While all the pieces of RDO are open (I think), there is no unified
documentation that shows you a birds eye view of how it all works. We
have tools like delorean and rdopkg which aim to make things easier for
people (and they do), and you often follow the documentation to do what
you need to do, without understanding why. How does code upstream get
into RDO? Following the packging docs it looks like it touches github,
fedora, delorean, and other pieces.
Things like Delorean and the CI parts often have no links off the main
rdo website (or if they do, they are buried in a page somewhere). We
have pieces running on OS1, we have pieces running on Trystack, we have
pieces living inside fedorapeople (?), we have pieces in Centos/CBS, I'm
still not entirely sure where the main site itself is running so if
anyone wants to actually try and understand the infrastructure (and in
particular, what infrastructure impacts RDO) it's a mystery.
Even something as simple as this
https://apps.fedoraproject.org/
To have links to all the parts of the RDO that exist currently, would be
a massive help.
<snip>
Note Rich this is not a slight against yourself and the fantastic work
you have done for RDO, I think this is more because the RDO project has
had to grow, change and adapt so quickly, everything is moving at
breakneck speed so it's hard for people not involved to keep up.
2:55 p.m.
2015-09-21 20:03 GMT+02:00 Rich Bowen <rbowen(a)redhat.com>:
I wanted to share a portion of a conversation with folks here, and
ask for
some help.
To summarize, it's confusing to people who are not part of the process (and
often for people who are) where all of the pieces of the RDO process live,
what they do, how they talk to one another, and so on. Because of how RDO
has evolved, and interacted with other parties (Fedora, CentOS, upstream
OpenStack, Trystack, and now the rpm-packaging upstream project, and
probably other things I'm forgetting) it can feel, sometimes, that there's
some magic involved.
I'd like to bring more clarity to this with some docs, some diagrams, and
whatever else we need to do, both to bring more transparency to the process,
and to help people who are trying to get involved, find their way. I could
definitely use your help in making that happen.
--Rich
Thanks Rich for bringing that topic and what follows will be my own
PoV, not my employer's.
First, until recently RDO had little to no external contributors,
making opening the infrastructure and process a lower priority against
making RDO a truly usable distro.
Now, that RDO reached some maturity, openness is now on the top of the
queue, a dedicated team (RDO Engineering) has been creating early 2015
to work full-time on RDO.
RDO Engineering is one of the few team with Perry Myers organization
that has *no* internal meeting/call, everything we do is in the
*open*. Most of our decisions are discussed in this list or during our
packaging meetings.
I'd like to thank Alan (RDO Eng. team lead), Alvaro (RDO Eng, manager)
and Perry (dept manager) to enforce that. And you Rich to ensure that
RDO community grows healthily.
Sorry for disclosing corporate secrets: any internal discussion
concerning RDO ends up with someone reminding us that *NO, DON'T DO
THAT, BRING THE DISCUSSION ON RDO LIST OR RDO PUBLIC CHANNEL!!!!*
---
RDO Engineering has done a tremendous effort to open our
infrastructure, our main build system is CentOS CBS (primarily
maintained by alphacc from CERN!), anyone can submit packaging changes
through gerrithub.
All our tooling has been opened (delorean, rdopkg etc.), our trello is
open, our bug tracker too. We're starting to see a RDO Team that is a
superset of RDO Eng. made by non-redhatters, and redhatters from
different teams or dept.
At my level, I spend a significant amount of my time to mentor RDO
contributors (and regardless of their affiliation). One of my goals is
that most of the governance and effective stewardship of RDO belongs
to the RDO Community becomes possible. We could create a governance
body made up of non-redhatters but if they can't manage the
infrastructure or enforce their decisions, it would be shallow.
-----
Is that enough? the answer is NO
We need to define our processes, so that people won't get confused and
lower as much as possible the entry barrier.
Our current infrastructure is still a patchwork:
* builders are scattered between Fedora Koji, CBS, copr
* no single accounting/access control system
* lack of automation
* CI has yet to be opened.
=> That makes it to hard to grant access to external contributors as
we don't have control over our infrastructure. And we can't grant
finer-grained accesses, which does not help in granting more people
access to our infrastructure.
Especially when CI and more generally infrastructure is not reliable
and we're missing a lot of safety checks.
We've been working into consolidating our infrastructure (Cf. the
fedora thread), and have a dedicated person to work full-time on RDO
CI so we could open it. it'll get better. As our platform will be
stabilizing, we'll be able to welcome more contributors and grant them
more access. Even myself don't have access to everything and
sometimes, it's frustrating not being able to fix trivial things.
As someone who saw Fedora's evolution over the years, and who
co-founded CentOS Cloud SIG, it takes time to build a truly open
community. Currently RDO is not that much different from early Fedora
Core. We have yet to build our infra and define our processes but
we're on the path to be a fully open community.
Our priority is to stabilize our foundations (including
infrastructure), strive to lower the contribution barrier, keep the
decision process transparent and open.
Regards,
H.
PS: I like having my team meeting on a public irc channel, and that I
don't need connecting corporate VPN to do my main job, that my team is
not limited to Red Hat folks, don't take that away from me!
-------- Forwarded Message --------
On 09/18/2015 05:49 AM, Rich Bowen wrote:
>
>
>
>>>> * One of the criticisms against RDO at the moment is the lack of real
>>>> transparency and confusion as to the infrastructure and systems that
>>>> power it.
>
>
>
> I'm curious where you're seeing this criticism, as I haven't seen it at
> all. I'll take this as an action item to thoroughly document the
> infrastructure and systems that power RDO, but I was completely unaware
> that this was a concern.
>
>
>
It's been mentioned to me by operators that I've spoken to at Meetups
and the like. It's more of a casual observation from users who are more
interested in contributing and being a part of RDO.
If you look at Fedora as an example, all the infrastructure is exposed,
they have things like bohdi and koji that allow you to directly see and
"touch" the entire process used to ship Fedora. You can very easily
follow the process code goes through the whole system to get out the
door (and the documentation of how it all works is very good).
While all the pieces of RDO are open (I think), there is no unified
documentation that shows you a birds eye view of how it all works. We
have tools like delorean and rdopkg which aim to make things easier for
people (and they do), and you often follow the documentation to do what
you need to do, without understanding why. How does code upstream get
into RDO? Following the packging docs it looks like it touches github,
fedora, delorean, and other pieces.
Things like Delorean and the CI parts often have no links off the main
rdo website (or if they do, they are buried in a page somewhere). We
have pieces running on OS1, we have pieces running on Trystack, we have
pieces living inside fedorapeople (?), we have pieces in Centos/CBS, I'm
still not entirely sure where the main site itself is running so if
anyone wants to actually try and understand the infrastructure (and in
particular, what infrastructure impacts RDO) it's a mystery.
Even something as simple as this
https://apps.fedoraproject.org/
To have links to all the parts of the RDO that exist currently, would be
a massive help.
<snip>
Note Rich this is not a slight against yourself and the fantastic work
you have done for RDO, I think this is more because the RDO project has
had to grow, change and adapt so quickly, everything is moving at
breakneck speed so it's hard for people not involved to keep up.
_______________________________________________
Rdo-list mailing list
Rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
2:28 p.m.
On Mon, Sep 21, 2015 at 1:55 PM, Haïkel <hguemar(a)fedoraproject.org> wrote:
We've been working into consolidating our infrastructure (Cf.
the
fedora thread), and have a dedicated person to work full-time on RDO
CI so we could open it.
Hi Haïkel,
Who is that person who's working full-time on RDO CI?
I had some questions a while back about the setup on OpenShift:
https://www.redhat.com/archives/rdo-list/2015-June/msg00156.html
- Ken
2:49 a.m.
> We've been working into consolidating our infrastructure
(Cf. the
> fedora thread), and have a dedicated person to work full-time on RDO
> CI so we could open it.
Hi Haïkel,
Who is that person who's working full-time on RDO CI?
I had some questions a while back about the setup on OpenShift:
https://www.redhat.com/archives/rdo-list/2015-June/msg00156.html
David works now on RDO CI, but prod-rdojenkins predates him and was set up
by Wes so he could answer that question.
Cheers,
Alan
3128
days inactive
3140
days old
3 comments
4 participants
participants (4)
-
Alan Pevec -
Haïkel -
Ken Dreyer -
Rich Bowen