Just pinging on this. I think stano is blocked waiting for an ack
from a koji-devel and (possibly) fedora-releng here.
On Tue, May 09, 2017 at 01:45:55PM +0200, Stanislav Ochotnicky wrote:
On Fri 05 May 2017 07:23:18 PM CEST Ralph Bean
<rbean(a)redhat.com> wrote:
> On Mon, Apr 24, 2017 at 05:06:47PM +0200, Stanislav Ochotnicky wrote:
>> On Mon 24 Apr 2017 04:56:05 PM CEST Jan Kaluža <jkaluza(a)redhat.com>
wrote:
>> > On 04/24/2017 04:20 PM, Stanislav Ochotnicky wrote:
>> >> On Mon 24 Apr 2017 03:25:48 PM CEST Ralph Bean <rbean(a)redhat.com>
wrote:
>> >>> On Mon, Apr 24, 2017 at 01:51:39PM +0200, Stanislav Ochotnicky
wrote:
>> >>>> This is the first stab and what the mbs CG metadata output
might look like:
>> >>>>
https://paste.fedoraproject.org/paste/5ix-EZVVRkmqpSvCQKOw715M1UNdIGYhyRL...
>> >>>
>> >>> Just to clarify - in the "build" entry here, this is a
build of the
>> >>> "nginx module". The "version" (which is 1) and
the "release" (which is
>> >>> 2) are in koji terms, not MBS terms.
>> >>>
>> >>> The mapping between MBS and koji terms should look something like:
>> >>>
>> >>> MBS -> Koji
>> >>> ---------------
>> >>> name -> name
>> >>> stream -> version
>> >>> version -> release
>> >>>
>> >>> The only kicker I can see at the moment is the datatype of
stream(MBS)
>> >>> versus version(Koji). The MBS stream is a string (master, or f26,
or
>> >>> whatever). The Koji version... does it have to be an integer?
>> >>
>> >> Well the version even for rpms is a string. Usually semantic
versioning
>> >> style thing - but not necessarily. Of course if you use something lime
>> >> rpmdev-vercmp on these mbs builds EVRs it might make things weird.
I.e.:
>> >> rpmdev-vercmp master-20 version2-10
>> >> master-20 < version2-10
>> >>
>> >> But I think that's OK.
>> >>
>> >> One thing however - can stream contain dash? Because version string
>> >> cannot. I'd be tempted to just replace it with underscore hoping
there
>> >> won't be both :-)
>> >
>> > We currently set the the dist-git branch as a stream value. From MBS
>> > point of view, there is no problem with dash in a stream name and I
>> > presume there will dashes in a stream name if we don't decide you
cannot
>> > use dash in dist-git branch name for modules. I would not like to
>> > restrict that if there is no real reason to do that.
>> >
>> > How much user-visible will the content generator data be? Can for
>> > example user search for module in Koji by typing its
>> > name-stream-version? In that case, I would start thinking about
>> > restricting the branch so it does not contain dash, because people will
>> > not replace dash with underscore when searching Koji.
>>
>> Well this part of content generator is very visible - it's part of the
>> build NVR after all. So things like API calls getBuild(nvr) would be
>> affected by it. And the NVR will need to be input as part of shipping
>> update in Bodhi for example.
>>
>> I would guess people *will* use dash in the stream name unless they are
>> prevented from doing it?
>
> From discussion in IRC today (paraphrasing others):
>
> We can use a new "build type" for this ("module"). With a new
build
> type (btype) we can:
>
> - store the original MBS name-stream-version in koji as extra information,
preserving dashes
> - while the build has a koji-reformatted name-version-release with dashes converted
to underscores.
>
> There is precedent for this in the way Maven GAV is mapped to NVR.
>
> In the CG metadata provided by MBS, btype specific data goes into
> extra->typeinfo->BTYPENAME for build and archive and this how koji
> knows the btype. So, the MBS would need to define the mapping from NSV
> to NVR (hyphens become underscores, etc.) and use the mapped NVR to
> identify the build. The original, unmodified NSV would be recorded in
> the "extra" field of the build.
>
> (Archives can only have one btype. builds btypes must match their
> component archives. btype info can technically be {})
>
> Is that sufficient to solve this mapping problem? Are there any other
> outstanding questions you need resolved, stano?
>
> (Sorry for this getting splintered across multiple lists...)
So:
* I'll change "modulemd" btype for the build to just "module"
* I can do the tweak for n-v-r dashes fairly easily (i.e. convert - to _
in the version/stream field) and provide an mbs stream/version metadata
in the extra/typeinfo/module space
* As mentioned above - the output archives need the type too. Right now
the "type" is "module" and there's an empty typeinfo for it.
Should
we use some generic type (i.e. "archive" or whatever makes sense) and
just provide the "extra/typeinfo" piece? This is a little confusing
since OSBS doesn't seem to be currently using this structure so I had
no example to base from and the docs[1] are not making it
clear. Basically the above is based on experimentation based on
errors I was getting from koji when I was importing. I'd appreciate
someone from koji folks to have a look and tell me whether I can
likely simplify/adjust something.
Sorry about the fpaste expiring. I didn't realize the TTL is so short
there. I uploaded the latest version example updated with changes
proposed here:
https://fedorapeople.org/~sochotni/mbs-content-generator.json
If the above content generator example seems OK I can do the final
tweaks pretty quickly. I'd appreciate an ACK on the format from koji
devs before I go ahead with that tweak though.