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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
