[Devtools] [Container-tools] Prepackaged OpenShift template with CDK

[Hardy Ferentschik]

Hi,

> >Another thing is that we still have builders for Python, Ruby and Perl showing up. Maybe
> >not such a bad thing, but it was not in the list we initially defined. The reason for this is
> >that we import the RHEL 7 image stream un-modified. I think we really need to take control
> >over this and hand-roll our own streams and templates.
> 
> We had thought about whether to include the different image streams and
> decided in-favor of them because we want to facilitate developers
> create/run/experiment applications in the OpenShift with different runtime.

Sure, in fact the Ruby, Perl and Python look good, the names reflect different versions of
these languages. A user can decide which builder to use, depending on his
preferred version of the language. But why add 'latest' here?  

> IMO It is fine to ship a limited set of working examples as part of CDK but
> it is also very important that developers should be able to develop
> applications on top of OpenShift shipped through CDK and for that to happen
> we need the image streams for programming languages (e.g. Ruby, nodejs,
> Python, PHP), Wildfly, mysql, mongodb etc to be available.

I think I am more concerned about the XPaaS ones. The naming is not consistent. Why is the
builder image called jboss-eap64-openshift and why can I see two version of it (1.1 and 1.2).
As a user, which one do I choose? Note, these are builder images which is not made explicit
in the name. If you are lucky you notice the different icon at the end.
The the EAP app template is called 'eap64-mysql-persistent-s2i', also not a good name.
And while on it, why no prefix 'jboss'?

Do you see where I am coming from? I am not saying that this is not going to work, I am
just saying we are not sending clear messages. We potentially confuse the user.
For everything we do, we should not only think about: "Does it work?", we should also
put our users glasses on and think:"How is a user who does not work day in day out
with this stuff going to perceive this".

I believe we have also an upstream issue here on how various parts of the organisation
package and deliver image streams and templates. Until we have a way to improve
upstream, I think our best option is to handroll these resources for the CDK.
Providing a consistent set of builder images and templates with easy to understand names.
Here is an opportunity for the CDK to shine and add some actual more value to the user, by
sorting out the chaos around resources which exits atm.

--Hardy


> 
> >
> >That said, I am not sure whether there is still time to do much about the imported resources.
> >Maybe we just need to fly with what we have, even though imo it is a bit confusing to the users.
> >
> >At least the EAP issue should be investigated though.
> >
> >--Hardy
> >
> >
> >
> >
> >----- End forwarded message -----
> >
> >
> >_______________________________________________
> >Devtools mailing list
> >Devtools at redhat.com
> >https://www.redhat.com/mailman/listinfo/devtools
> 

> _______________________________________________
> Devtools mailing list
> Devtools at redhat.com
> https://www.redhat.com/mailman/listinfo/devtools

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/devtools/attachments/20160406/cce018a2/attachment.sig>