Upstreaming downstream Google BMC repositories

Tue Jan 12 08:13:30 AEDT 2021

Unfortunately we don't have a great policy on any of this.  Hopefully it
is something we can come up with a better definition on in the near
future.

On Thu, Jan 07, 2021 at 01:20:00PM -0800, Ed Tanous wrote:
> On Thu, Jan 7, 2021 at 10:26 AM Paul Menzel <pmenzel at molgen.mpg.de> wrote:
> > Am 07.01.21 um 18:33 schrieb Benjamin Fair:
> > > On Thu, 7 Jan 2021 at 00:09, Paul Menzel <pmenzel at molgen.mpg.de> wrote:
> > >> Am 07.01.21 um 02:49 schrieb Brandon Kim:
> > >>
> > >>> We're exploring ways of upstreaming some of the downstream repositories
> > >>> from Google to openbmc/* .
> > >>>
> > >>> Half, if not most of the downstream repositories are C++ daemons that are
> > >>> specific to Google so we didn't want to create a bunch of new
> > >>> openbmc/<repo> that no one would use.

Just out of curiousity, if they're not going to be useful to anyone
except Google, what is the utility of getting them into an openbmc repo?
(There are reasons but I don't want to put words in your mouths)

> > >>> An idea that Ed gave me was having something like openbmc/google-misc
> > >>> repository for all these repositories and if there are any that seem useful
> > >>> to others, we can break it out into a different, separate repository in
> > >>> openbmc/* layer.
> > >>>
> > >>> Please let me know if this seems like a good idea and I'm open to other
> > >>> suggestions!

I really dislike dumping-ground repositories.  If we're going to allow
company-specific "misc" repositories, I would really like a policy that
they may *only* be referenced from that company's meta-layer.  If anyone
has any use in that code it really should be broken out into its own
repository with a proper maintenance structure.

> > >> Thank you very much for putting in the effort to make these repositories
> > >> public.
> > >>
> > >> Using the openbmc/google-misc approach, how would the git history
> > >> (commit log) be handled?
> > >>
> > >> Personally, I would prefer having small repositories as git makes that
> > >> very easy to handle. Also it might save you time, as you do not have to
> > >> think about what to do with the git history, and do not have to merge it.
> > >
> > > We would most likely squash the history together, in case there's
> > > something confidential or private in the earlier commits.
> >
> > Understood. If that could be avoided, and only the confidential stuff
> > removed, that would be great, as the git history gives a lot of insight
> > into design decisions.
> 
> It should be noted, there isn't really much git history to speak of
> for the things we're looking at pushing.  

How was any code of significance developed without a git history?  It is
unfortunate we're going to lose all of this because of how often I tend
to dig through 'git-blame' to understand the "why" on code.

> Some examples of things that would go in this repository.
> 1. The google public keys/certs.  I would hope that non-google systems
> are using their own root certificates.
> 2. Disabling of ssh login flows.  This is done in a very specific way
> that requires interfacing with out of network components and protocols
> that are specific to our systems.  I'd be surprised if anyone found
> this useful.
> 3. In-band telemetry code implementing interfaces for interfacing to
> google infrastructure.  These haven't been built yet, but will likely
> be a translation from the public facing APIs (Dbus/redfish/ipmi) to
> interface them to google infrastructure.  it's unlikely anyone else
> would use this.

These make me more curious on the value of opening them.

> > > Many small repos would be easy to handle for us, but OpenBMC may not
> > > want to have lots of small Google-specific repos in their org as this
> > > may make it more cumbersome for others to find the relevant repos that
> > > they're interested in.
> >
> > Understood. On the other, with small repositories, they can only use the
> > parts they need.

I'm more comfortable with others utilizing this code if it is in a small
repo like "google-ssh-cert".  As others find it valuable we can rename
the repo.

> See above, if there are pieces that people want to use on non-google
> systems, they don't belong in meta-google.  With that said, your
> statement is incorrect, recipes are not required to be 1:1 with
> repositories.  Multiple recipes can point at subfolders of the same
> repository, allowing you to "use the parts they need" by simply adding
> recipes.  With that said, this is not the intent, and I would much
> rather move code to a more common layer (meta-phosphor for example)
> rather than have non google systems including meta-google in their
> bblayers.conf.
> 
> >
> > > There's also overhead for the project maintainers to create the
> > > relevant groups and permissions for each new repo.
> > Please note, that Without knowing the contents of the repositories and
> > the size, this is all just my opinion. If the OpenBMC “admins“ can
> > easily create several repositories, I’d prefer that route.
> 
> Today creating new repos is non-trivial, and IMO we already have too
> many of them, which is causing a lot of thrash.  I'd really like to
> see us start consolidating some of these (see my patches to
> consolidate all the meta-layers into openbmc/openbmc with the owners
> plugin)

What do you mean by "thrash"?  Ideally it should be cheap to create a
repository.  If there is significant overhead to create a repository
with the current infrastructure we should document those challenges and
look to improve them.

I don't have any issue with consolidation of the meta-layers because
those are effectively all built together anyhow.  Right now I'm not in
favor of consolidation of code repositories and we've even talked about
splitting out some pieces (EM and fru-device come to mind to me).  Can
you quantify what the advantage of a big[ger] multi-function repositories
are?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210111/8e47a78b/attachment.sig>