Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

composer-cli has a poor user experience #1105

Closed
msehnout opened this issue Nov 25, 2020 · 6 comments
Closed

composer-cli has a poor user experience #1105

msehnout opened this issue Nov 25, 2020 · 6 comments

Comments

@msehnout
Copy link
Contributor

msehnout commented Nov 25, 2020

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
Copy link
Member

teg commented Nov 25, 2020

Agreed. Thoughts on this @bcl ?

@atodorov
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor Author

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

@msehnout
Copy link
Contributor Author

msehnout commented Feb 3, 2021

@bcl is working on this

@msehnout msehnout closed this as completed Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants