Open Stack

Jeremy Stanley <fungi at yuggoth.org> writes:

> On 2017-05-25 00:33:10 +0000 (+0000), Tristan Cacqueray wrote:
>> On May 24, 2017 11:04 pm, James E. Blair wrote:
>> [...]
>> >How does that sound?
>> 
>> Thinking about further connections support, could this also works
>> for a (theorical) mail based patch cross dependency?

Zuul's driver API has 3 separate, but relevant, concepts:

Source: the canonical git repo for a project along with a place to fetch
  any proposed changes and metadata.
Trigger: something that tells Zuul to enqueue a change.
Reporter: some place that Zuul reports results.

In v3, the three are completely separate.  Theoretically we could write
a driver which implemented the source interface against LKML.  It would
need a git repo (so I assume we would point it at one of the ones at
kernel.org).  Fetching the patch and git-am'ing it should be
straightforward.  Implementing the methods that determine whether a
change is still "open" or whether it has "merged" might be a little less
straightforward in this case (especially since the patch doesn't have a
git sha that we can search for in the tree).

The source driver would assume a 1:1 relationship with the changes (ie
lkml.org/diff/...) and a single git repo.  That strays a bit from how
kernel development is done, in that there are a lot of git repos on
kernel.org, and the changes may be designated for any of them (in the
example above, "Please apply this to the samsung tree").  So we're not
going to completely match the Linux kernel workflow without some further
changes.  But we're surprisingly close to being able to do something.

> I can imagine wanting something like:
>
>     Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1
>
> ...where zuul will git am what it finds there.
>
>> What's the logic to match the Depends-On syntax to a connection
>> driver?

I expect it will be that we ask every driver in turn whether it handles
this url, and the driver examines the hostname to see if it matches what
it is configured for.  If so, the Zuul will ask the driver for the
change.

> This brings up an additional question: how far can we stretch the
> concept of a connection driver, and does it always need to be
> something we can report back on in some way? Maybe we want to test a
> Gerrit change or GutHub PR which requires a patch from the LKML (as
> above) when rebuilding the kernel for a guest, but we don't ever
> expect to report back to the LKML about anything. Would having a
> generic HTTP(S) driver for things like this make sense?

Because triggers and reporters are separate from sources, we can
definitely configure them separately, and configure the system not to
report back to LKML.

Because we need a git repo to back changes (ie, to what do we apply that
diff?), a generic HTTP(S) driver won't be sufficient.  But the rest of
what you suggest is fairly close to possible with the caveats above.

Perhaps we should consider (in the future, after we get this thing out
the door) extending the Depends-On syntax like:

  Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1 applied to
      https://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/

In another post, Sean suggests allowing arbitrary text after the
identifier.  This is probably compatible with that, inasmuch as we can
start by allowing arbitrary text, and then reclaim "applied to" as a
keyword phrase later.

-Jim