Open Stack

On Mon, Jan 19, 2015 at 01:24:19PM +0000, Steven Hardy wrote:
> On Mon, Jan 19, 2015 at 07:29:42PM +0800, Qiming Teng wrote:
> > On Mon, Jan 19, 2015 at 09:49:08AM +0000, Steven Hardy wrote:
> > > On Sun, Jan 18, 2015 at 08:41:46PM +0800, Qiming Teng wrote:
> > > > Dear all,
> > > > One question we constantly get from Heat users is about the support
> > > > status of resource types. Some users are not well informed of this
> > > > information so that is something we can improve.
> > > > 
> > > > Though some resource types are already labelled with support status,
> > > > there are quite some of them not identified yet. Helps are needed to
> > > > complete the list.
> > > 
> > > Identifying any resources which were added in either Juno or Kilo which
> > > aren't tagged appropriately seems worthwhile, but all other resources
> > > should exist in any non EOL verion of heat, so is the effort justified in,
> > > for example, saying "supported since grizzly"?
> > 
> > Honestly speaking, I don't think we need to backtrace all the way to the
> > day when worldwar II ended. The questions we got are mostly about the
> > support status of resource types in Icehouse and Juno. What have been
> > added? Which are deprecating/deprecated? So, I tend to agree that saying
> > just 'supported since 2013.2' would suffice.
> 
> Ok, I'm not clear what there is to do here then, as AFAIK all resources
> added during Juno and Kilo should be tagged already (if they're not, please
> raise a bug).

The question is not about those resource types which have got version
tags. The question is about whether or how to tag all other resource
types. Sorry if I didn't make the question clear.

> > > A more important ommission IMO was that we didn't expose the properties
> > > schema tags for new properties added to existing resources - I fixed that
> > > on Friday:
> > > 
> > > https://review.openstack.org/#/c/147434/1
> > 
> > Documenting the support status is important for sure, but I'm concerning
> > that most users are just brave/confident enough to start with trying the
> > command line. They even don't know there are docs. They start with
> > simple templates and then experiment with each resource type they feel
> > interested in.
> 
> I find this comment a little confusing given that the whole reason for this
> thread is documenting support status ;)

Right, documenting support status is important. The only difference I
see is on 'how'. The reason we provide resource-type-show,
resource-type-template commands are all about helping users get
themselves familiarized with the resource types. My understanding is
that command line help has its advantage. Maybe I am misunderstanding
something here.

> That said, if users don't know there are docs, that's a serious problem, we
> should add links somewhere obvious, like heat-templates in a README, if
> that's where their simple templates are coming from, or maybe even add it
> to the error response they see when we reject a template due to an unknown
> resource type.

Well, at one extreme, we are expecting users to read all docs (including
READMEs) before using the tool, at the other we are encouraging
'trial-and-err' exercises. One example comes to my mind is the README
file we placed there for users to understand how to build an image to
use softwareconfig/softwaredeployment. It is a good document people
always neglected.

Regards,
  Qiming

> Steve
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>