make field container.image of component to be configurable by parameters

[wonderflow]

Most of our users told us that we need to make container.image of ComponentSchematic to be configurable. The case is that once the component has been created, only image tag need to be upgraded. But we still have to create a new ComponentSchematic spec with a new Application Configuration spec to upgrade an app.

I know in OAM principle, the Component Spec is concerned by the app developer. In that word, image upgrade need to change the Component spec indeed. But in the cases above, the developer use container image as deliverables, the requirement of changing component spec seems a little harsh and give them more burden.

ps: An OCI image usually combined with a repo name and a tag like nginx:v1, the image tag means v1 in the example.

[linfan]

Since the image tag is usual generated by CI (e.g. Jenkins), app developer sometimes really doesn't case about what is the next tag number. While the guy who does the deployment job (usually operators) would know it better 🤠

[wonderflow]

I think this issue is related to https://github.com/oam-dev/spec/issues/350

We have released v1alpha2 and in that version, OAM Component should be an instance which means the image changed in Component can directly affect the App without redeploy AppConfig.