<div dir="ltr">Hi everyone,<div><br></div><div>Wanted to ping this thread to see if there were more concerns on creating an openbmc/google-misc repository.</div><div><br></div><div>Thanks!</div><div>Brandon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 1:51 PM Ed Tanous <<a href="mailto:ed@tanous.net">ed@tanous.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jan 11, 2021 at 1:14 PM Patrick Williams <<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>> wrote:<br>
><br>
> Unfortunately we don't have a great policy on any of this.  Hopefully it<br>
> is something we can come up with a better definition on in the near<br>
> future.<br>
><br>
> On Thu, Jan 07, 2021 at 01:20:00PM -0800, Ed Tanous wrote:<br>
> > On Thu, Jan 7, 2021 at 10:26 AM Paul Menzel <<a href="mailto:pmenzel@molgen.mpg.de" target="_blank">pmenzel@molgen.mpg.de</a>> wrote:<br>
> > > Am 07.01.21 um 18:33 schrieb Benjamin Fair:<br>
> > > > On Thu, 7 Jan 2021 at 00:09, Paul Menzel <<a href="mailto:pmenzel@molgen.mpg.de" target="_blank">pmenzel@molgen.mpg.de</a>> wrote:<br>
> > > >> Am 07.01.21 um 02:49 schrieb Brandon Kim:<br>
> > > >><br>
> > > >>> We're exploring ways of upstreaming some of the downstream repositories<br>
> > > >>> from Google to openbmc/* .<br>
> > > >>><br>
> > > >>> Half, if not most of the downstream repositories are C++ daemons that are<br>
> > > >>> specific to Google so we didn't want to create a bunch of new<br>
> > > >>> openbmc/<repo> that no one would use.<br>
><br>
> Just out of curiousity, if they're not going to be useful to anyone<br>
> except Google, what is the utility of getting them into an openbmc repo?<br>
> (There are reasons but I don't want to put words in your mouths)<br>
<br>
A slight clarification: the theory is they're not useful unless you're<br>
building a machine that intends to live within the Google<br>
infrastructure (similar to zaius, or q71l).  The meta layer _is_<br>
useful outside of google, with companies that design and build the<br>
aforementioned platforms.  Having the specific tweaks made available<br>
in the public means that the companies we work with can build 1:1 the<br>
image that we're operating with, report bugs against it more publicly,<br>
and we can share more code in the open, without resorting to<br>
public/private forks of OpenBMC for our own purposes which have their<br>
own problems as has been proven in the past.<br>
<br>
The other hope is that if we're wrong, and something within that repo<br>
is useful outside of google (seems likely it might happen for<br>
something), it's available with a public license and whoever finds it<br>
useful can simply move it to a common repo where others can use it,<br>
with minimal fuss, or asking us to upstream something we've built in<br>
the past.<br>
<br>
><br>
> > > >>> An idea that Ed gave me was having something like openbmc/google-misc<br>
> > > >>> repository for all these repositories and if there are any that seem useful<br>
> > > >>> to others, we can break it out into a different, separate repository in<br>
> > > >>> openbmc/* layer.<br>
> > > >>><br>
> > > >>> Please let me know if this seems like a good idea and I'm open to other<br>
> > > >>> suggestions!<br>
><br>
> I really dislike dumping-ground repositories.  If we're going to allow<br>
> company-specific "misc" repositories, I would really like a policy that<br>
> they may *only* be referenced from that company's meta-layer.<br>
<br>
That sounds completely reasonable, and in-line with our intent.<br>
<br>
>  If anyone<br>
> has any use in that code it really should be broken out into its own<br>
> repository with a proper maintenance structure.<br>
<br>
 +1.<br>
<br>
><br>
> > > >> Thank you very much for putting in the effort to make these repositories<br>
> > > >> public.<br>
> > > >><br>
> > > >> Using the openbmc/google-misc approach, how would the git history<br>
> > > >> (commit log) be handled?<br>
> > > >><br>
> > > >> Personally, I would prefer having small repositories as git makes that<br>
> > > >> very easy to handle. Also it might save you time, as you do not have to<br>
> > > >> think about what to do with the git history, and do not have to merge it.<br>
> > > ><br>
> > > > We would most likely squash the history together, in case there's<br>
> > > > something confidential or private in the earlier commits.<br>
> > ><br>
> > > Understood. If that could be avoided, and only the confidential stuff<br>
> > > removed, that would be great, as the git history gives a lot of insight<br>
> > > into design decisions.<br>
> ><br>
> > It should be noted, there isn't really much git history to speak of<br>
> > for the things we're looking at pushing.<br>
><br>
> How was any code of significance developed without a git history?  It is<br>
> unfortunate we're going to lose all of this because of how often I tend<br>
> to dig through 'git-blame' to understand the "why" on code.<br>
<br>
A lot of the commits aren't really "openbmc worthy" in that they're<br>
not signed off, have no tested statement, might have > 72 character<br>
lines ect.  They definitely do have a git history, and if the<br>
preference is that we push it with the messy history, we can certainly<br>
do it.  I don't have a strong opinion here other than not wanting to<br>
rewrite and retest every commit we've had to these things.<br>
<br>
><br>
> > Some examples of things that would go in this repository.<br>
> > 1. The google public keys/certs.  I would hope that non-google systems<br>
> > are using their own root certificates.<br>
> > 2. Disabling of ssh login flows.  This is done in a very specific way<br>
> > that requires interfacing with out of network components and protocols<br>
> > that are specific to our systems.  I'd be surprised if anyone found<br>
> > this useful.<br>
> > 3. In-band telemetry code implementing interfaces for interfacing to<br>
> > google infrastructure.  These haven't been built yet, but will likely<br>
> > be a translation from the public facing APIs (Dbus/redfish/ipmi) to<br>
> > interface them to google infrastructure.  it's unlikely anyone else<br>
> > would use this.<br>
><br>
> These make me more curious on the value of opening them.<br>
><br>
> > > > Many small repos would be easy to handle for us, but OpenBMC may not<br>
> > > > want to have lots of small Google-specific repos in their org as this<br>
> > > > may make it more cumbersome for others to find the relevant repos that<br>
> > > > they're interested in.<br>
> > ><br>
> > > Understood. On the other, with small repositories, they can only use the<br>
> > > parts they need.<br>
><br>
> I'm more comfortable with others utilizing this code if it is in a small<br>
> repo like "google-ssh-cert".  As others find it valuable we can rename<br>
> the repo.<br>
<br>
Right now the process to create new repositories takes a very long<br>
time, and requires interaction with core maintainers for<br>
CI/gerrit/github/user groups setup.  That model doesn't scale beyond<br>
what we have today if things like certs for every company needs its<br>
own repository.  I don't see a way to make it scale to the "new repo<br>
for everything" model, unless you had some ideas there.<br>
<br>
In other tracks I've had good luck simply extracting the history from<br>
a subfolder, and pushing that to a new repo when things needed to be<br>
split out.<br>
<br>
><br>
> > See above, if there are pieces that people want to use on non-google<br>
> > systems, they don't belong in meta-google.  With that said, your<br>
> > statement is incorrect, recipes are not required to be 1:1 with<br>
> > repositories.  Multiple recipes can point at subfolders of the same<br>
> > repository, allowing you to "use the parts they need" by simply adding<br>
> > recipes.  With that said, this is not the intent, and I would much<br>
> > rather move code to a more common layer (meta-phosphor for example)<br>
> > rather than have non google systems including meta-google in their<br>
> > bblayers.conf.<br>
> ><br>
> > ><br>
> > > > There's also overhead for the project maintainers to create the<br>
> > > > relevant groups and permissions for each new repo.<br>
> > > Please note, that Without knowing the contents of the repositories and<br>
> > > the size, this is all just my opinion. If the OpenBMC “admins“ can<br>
> > > easily create several repositories, I’d prefer that route.<br>
> ><br>
> > Today creating new repos is non-trivial, and IMO we already have too<br>
> > many of them, which is causing a lot of thrash.  I'd really like to<br>
> > see us start consolidating some of these (see my patches to<br>
> > consolidate all the meta-layers into openbmc/openbmc with the owners<br>
> > plugin)<br>
><br>
> What do you mean by "thrash"?  Ideally it should be cheap to create a<br>
> repository.<br>
<br>
Ideally, yes, but we're not there today, and I don't see a path to get us there.<br>
<br>
>  If there is significant overhead to create a repository<br>
> with the current infrastructure we should document those challenges and<br>
> look to improve them.<br>
<br>
The biggest challenge is that a large percentage of the work needs to<br>
be done by relatively few people (those with core permissions), and<br>
they have their own things to get done, and  rightfully aren't able to<br>
prioritize creating new repos/permissions/other stuff.  This topic<br>
alone is probably worth an email thread, as it's worth trying to<br>
tackle;  I'll try to get that written up.<br>
<br>
><br>
> I don't have any issue with consolidation of the meta-layers because<br>
> those are effectively all built together anyhow.  Right now I'm not in<br>
> favor of consolidation of code repositories and we've even talked about<br>
> splitting out some pieces (EM and fru-device come to mind to me).<br>
<br>
We talked about splitting those up?  I'd be a little worried about<br>
that, as they're pretty intertwined in their dbus interfaces.<br>
<br>
We're currently having the problem where nearly any new feature in<br>
dbus-sensors needs a commit to entity-manager to add a new schema, and<br>
that's non-obvious, and requires a commit done in lockstep to get code<br>
through.  I had actually considered the other day doing the opposite,<br>
and proposing merging entity-manager and dbus-sensors, but that's a<br>
different discussion.<br>
<br>
>  Can<br>
> you quantify what the advantage of a big[ger] multi-function repositories<br>
> are?<br>
<br>
The biggest advantage is time-to-create new repositories and the<br>
significant reduction in autobump-like recipe changes that need to be<br>
made to keep everything in lockstep.<br>
<br>
><br>
> --<br>
> Patrick Williams<br>
</blockquote></div>