search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

Operator SDK migrate bundle proposal #64

Closed jmrodri closed 3 years ago

jmrodri commented 3 years ago

Signed-off-by: jesus m. rodriguez jmrodri@gmail.com

kevinrizza commented 3 years ago

I'm assuming it's intentional, but this kep has a lot of similarities with the alpha bundle generate commands that are in opm: https://github.com/operator-framework/operator-registry/blob/master/cmd/opm/alpha/bundle/generate.go

tlwu2013 commented 3 years ago

I'm assuming it's intentional, but this kep has a lot of similarities with the alpha bundle generate commands that are in opm: https://github.com/operator-framework/operator-registry/blob/master/cmd/opm/alpha/bundle/generate.go

Right. This is intended to be more friendly to SDK users so they can directly use SDK to convert packagemanifest to bundle format + using this as a medium to introduce opm to SDK users if they have other more advanced catalog management use cases.

kevinrizza commented 3 years ago

Right. This is intended to be more friendly to SDK users so they can directly use SDK to convert packagemanifest to bundle format + using this as a medium to introduce opm to SDK users if they have other more advanced catalog management use cases.

Sure but all those opm alpha bundle commands were intentionally hidden from end users because we were just testing the APIs that we were exposing for the sdk to intentionally consume. So my assumption is that there should be some parity here with what opm actually wanted to provide for bundle creation and migration. We actively don't want our users to use those commands (which is why they're hidden) but some folks have latched onto them because there's no alternative in the SDK. Is that not the plan?

tlwu2013 commented 3 years ago

Right. This is intended to be more friendly to SDK users so they can directly use SDK to convert packagemanifest to bundle format + using this as a medium to introduce opm to SDK users if they have other more advanced catalog management use cases.

Sure but all those opm alpha bundle commands were intentionally hidden from end users because we were just testing the APIs that we were exposing for the sdk to intentionally consume. So my assumption is that there should be some parity here with what opm actually wanted to provide for bundle creation and migration. We actively don't want our users to use those commands (which is why they're hidden) but some folks have latched onto them because there's no alternative in the SDK. Is that not the plan?

Right, we are not going to prompt users to any opm alpha commands. This SDK migrate bundle subcommand will be the end-user facing command.

estroz commented 3 years ago

@jmrodri @tlwu2013 wdyt about deprecating packagemanifests features, ex. <run|generate> packagemanifests, as part of this proposal?

tlwu2013 commented 3 years ago

@jmrodri @tlwu2013 wdyt about deprecating packagemanifests features, ex. <run|generate> packagemanifests, as part of this proposal?

@estroz @jmrodri Sounds good to me. We could also add the deprecation warning messages to those packagemanifests commands. Like the idea of deprecating packagemanifests features so folks are more aware of the push for bundle migration. 👍🏼👍🏼

jmrodri commented 3 years ago

@estroz okay, I think I addressed all your comments.