composer-cli has a poor user experience

[msehnout]

There have been 2 reported complaints about the composer-cli usability:

1. Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1900659
2. Blueprint migration from lorax to osbuild does not produce errors on unknown customizations because we don't use https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields in our parser.

Real world example:

[fedora@ip-172-31-39-140 ~]$ sudo composer-cli compose start --size 12000 rpmci-runner-with-cloudinit ami rpmci-runner-20G provider.conf 

Compose 1bffda7a-ee0c-4b80-a711-171620ba62cc added to the queue
[fedora@ip-172-31-39-140 ~]$ 
[fedora@ip-172-31-39-140 ~]$ sudo composer-cli compose info 1bffda7a-ee0c-4b80-a711-171620ba62cc
1bffda7a-ee0c-4b80-a711-171620ba62cc FAILED   rpmci-runner-with-cloudinit 0.0.1 ami              12582912000
Packages:
2020-11-26 10:31:06,493: 'version'

I'm reporting this issue here because I think that osbuild organization should take the ownership of composer-cli and possibly use the golang client we already have in /internal/client.

[teg]

Agreed. Thoughts on this @bcl ?

[atodorov]

The referenced BZ number looks like an easy fix on the composer-cli side and there is existing test suite which can easily handle the described scenario.

Blueprint migration from lorax to osbuild does not produce errors on unknown customizations

This sounds like a separate issue from what I can understand. If that's the case it needs to be recorded and tracked separately.

I'm reporting this issue here because I think that osbuild organization should take the ownership of composer-cli

This will cause some disruption of the existing CI but is definitely doable and makes sense.

and possibly use the golang client we already have in /internal/cli

This is a completely different ball game and QE objects to that! It needs to be vetted via the appropriate channels and make sure the internal cli client is adequately tested and matches functionality in existing composer-cli, etc. This is a lot more work than it looks like on the surface.

[msehnout]

@atodorov you are right, I mixed two issues into one, but given that I don't know either of them is a priority for us, I thought it would make a case for overtaking composer-cli under osbuild organization.

I, of course, understand that a complete rewrite will come with regressions for some users so I see the reason to object, but suppose this is something we would like to do in a long run. Do you have a suggestion for best path forward? Would it be possible to hook QE tests for composer-cli to osbuild-composer repo?

[atodorov]

Do you have a suggestion for best path forward?

For both splitting up the composer-cli component from the lorax repo and/or complete replacement with a different cli client (which means rebase/obsolete of the existing RPM) you should start with a formal RHBZ request so we can plan for deadlines, priority and resources.

Would it be possible to hook QE tests for composer-cli to osbuild-composer repo?

Everything is possible, it's source code after all. The cli test suite is bash script + beakerlib so it is fairly portable. That said the devil is always in the implementation details and the issues that we discover along the way.

[msehnout]

One more related BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1915353

[msehnout]

@bcl is working on this