Re: [openstack-dev] [Heat] Support status of Heat resource types
On Mon, Jan 19, 2015 at 09:49:08AM +, 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. 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. Can you clarify the nature of the questions you're constantly getting from users, so we can ensure we're fixing the right thing to solve their problem? Steve +--+++ | name | support_status | since | +--+++ | AWS::AutoScaling::AutoScalingGroup || 2014.1 | | AWS::AutoScaling::LaunchConfiguration||| | AWS::AutoScaling::ScalingPolicy ||| | AWS::CloudFormation::Stack ||| | AWS::CloudFormation::WaitCondition || 2014.1 | | AWS::CloudFormation::WaitConditionHandle || 2014.1 | | AWS::CloudWatch::Alarm ||| | AWS::EC2::EIP||| | AWS::EC2::EIPAssociation ||| | AWS::EC2::Instance ||| | AWS::EC2::InternetGateway||| | AWS::EC2::NetworkInterface ||| | AWS::EC2::RouteTable || 2014.1 | | AWS::EC2::SecurityGroup ||| | AWS::EC2::Subnet ||| | AWS::EC2::SubnetRouteTableAssociation||| | AWS::EC2::VPC||| | AWS::EC2::VPCGatewayAttachment ||| | AWS::EC2::Volume ||| | AWS::EC2::VolumeAttachment ||| | AWS::ElasticLoadBalancing::LoadBalancer ||| | AWS::IAM::AccessKey ||| | AWS::IAM::User ||| | AWS::RDS::DBInstance ||| | AWS::S3::Bucket ||| | My::TestResource ||| | OS::Ceilometer::Alarm||| | OS::Ceilometer::CombinationAlarm || 2014.1 | | OS::Cinder::Volume ||| | OS::Cinder::VolumeAttachment ||| | OS::Glance::Image|| 2014.2 | | OS::Heat::AccessPolicy ||| | OS::Heat::AutoScalingGroup || 2014.1 | | OS::Heat::CloudConfig|| 2014.1 | | OS::Heat::HARestarter| DEPRECATED || | OS::Heat::InstanceGroup ||| | OS::Heat::MultipartMime || 2014.1 | | OS::Heat::RandomString || 2014.1 | | OS::Heat::ResourceGroup || 2014.1 | | OS::Heat::ScalingPolicy ||| | OS::Heat::SoftwareComponent || 2014.2 | |
Re: [openstack-dev] [Heat] Support status of Heat resource types
On Mon, Jan 19, 2015 at 07:29:42PM +0800, Qiming Teng wrote: On Mon, Jan 19, 2015 at 09:49:08AM +, 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). 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 ;) 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. 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
Re: [openstack-dev] [Heat] Support status of Heat resource types
On Mon, Jan 19, 2015 at 01:24:19PM +, 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 +, 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
Re: [openstack-dev] [Heat] Support status of Heat resource types
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? 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 Can you clarify the nature of the questions you're constantly getting from users, so we can ensure we're fixing the right thing to solve their problem? Steve +--+++ | name | support_status | since | +--+++ | AWS::AutoScaling::AutoScalingGroup || 2014.1 | | AWS::AutoScaling::LaunchConfiguration||| | AWS::AutoScaling::ScalingPolicy ||| | AWS::CloudFormation::Stack ||| | AWS::CloudFormation::WaitCondition || 2014.1 | | AWS::CloudFormation::WaitConditionHandle || 2014.1 | | AWS::CloudWatch::Alarm ||| | AWS::EC2::EIP||| | AWS::EC2::EIPAssociation ||| | AWS::EC2::Instance ||| | AWS::EC2::InternetGateway||| | AWS::EC2::NetworkInterface ||| | AWS::EC2::RouteTable || 2014.1 | | AWS::EC2::SecurityGroup ||| | AWS::EC2::Subnet ||| | AWS::EC2::SubnetRouteTableAssociation||| | AWS::EC2::VPC||| | AWS::EC2::VPCGatewayAttachment ||| | AWS::EC2::Volume ||| | AWS::EC2::VolumeAttachment ||| | AWS::ElasticLoadBalancing::LoadBalancer ||| | AWS::IAM::AccessKey ||| | AWS::IAM::User ||| | AWS::RDS::DBInstance ||| | AWS::S3::Bucket ||| | My::TestResource ||| | OS::Ceilometer::Alarm||| | OS::Ceilometer::CombinationAlarm || 2014.1 | | OS::Cinder::Volume ||| | OS::Cinder::VolumeAttachment ||| | OS::Glance::Image|| 2014.2 | | OS::Heat::AccessPolicy ||| | OS::Heat::AutoScalingGroup || 2014.1 | | OS::Heat::CloudConfig|| 2014.1 | | OS::Heat::HARestarter| DEPRECATED || | OS::Heat::InstanceGroup ||| | OS::Heat::MultipartMime || 2014.1 | | OS::Heat::RandomString || 2014.1 | | OS::Heat::ResourceGroup || 2014.1 | | OS::Heat::ScalingPolicy ||| | OS::Heat::SoftwareComponent || 2014.2 | | OS::Heat::SoftwareConfig || 2014.1 | | OS::Heat::SoftwareDeployment || 2014.1 | | OS::Heat::SoftwareDeployments|| 2014.2 | | OS::Heat::Stack ||| | OS::Heat::StructuredConfig || 2014.1 | | OS::Heat::StructuredDeployment || 2014.1 | | OS::Heat::StructuredDeployments || 2014.2 | | OS::Heat::SwiftSignal|| 2014.2 | | OS::Heat::SwiftSignalHandle || 2014.2 | | OS::Heat::UpdateWaitConditionHandle || 2014.1 | | OS::Heat::WaitCondition ||
Re: [openstack-dev] [Heat] Support status of Heat resource types
On Sun, Jan 18, 2015 at 10:41 PM, Qiming Teng teng...@linux.vnet.ibm.com 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. I think the only why to figure these out is using the git history. This is going to be tedious work:-( -Angus +--+++ | name | support_status | since | +--+++ | AWS::AutoScaling::AutoScalingGroup || 2014.1 | | AWS::AutoScaling::LaunchConfiguration||| | AWS::AutoScaling::ScalingPolicy ||| | AWS::CloudFormation::Stack ||| | AWS::CloudFormation::WaitCondition || 2014.1 | | AWS::CloudFormation::WaitConditionHandle || 2014.1 | | AWS::CloudWatch::Alarm ||| | AWS::EC2::EIP||| | AWS::EC2::EIPAssociation ||| | AWS::EC2::Instance ||| | AWS::EC2::InternetGateway||| | AWS::EC2::NetworkInterface ||| | AWS::EC2::RouteTable || 2014.1 | | AWS::EC2::SecurityGroup ||| | AWS::EC2::Subnet ||| | AWS::EC2::SubnetRouteTableAssociation||| | AWS::EC2::VPC||| | AWS::EC2::VPCGatewayAttachment ||| | AWS::EC2::Volume ||| | AWS::EC2::VolumeAttachment ||| | AWS::ElasticLoadBalancing::LoadBalancer ||| | AWS::IAM::AccessKey ||| | AWS::IAM::User ||| | AWS::RDS::DBInstance ||| | AWS::S3::Bucket ||| | My::TestResource ||| | OS::Ceilometer::Alarm||| | OS::Ceilometer::CombinationAlarm || 2014.1 | | OS::Cinder::Volume ||| | OS::Cinder::VolumeAttachment ||| | OS::Glance::Image|| 2014.2 | | OS::Heat::AccessPolicy ||| | OS::Heat::AutoScalingGroup || 2014.1 | | OS::Heat::CloudConfig|| 2014.1 | | OS::Heat::HARestarter| DEPRECATED || | OS::Heat::InstanceGroup ||| | OS::Heat::MultipartMime || 2014.1 | | OS::Heat::RandomString || 2014.1 | | OS::Heat::ResourceGroup || 2014.1 | | OS::Heat::ScalingPolicy ||| | OS::Heat::SoftwareComponent || 2014.2 | | OS::Heat::SoftwareConfig || 2014.1 | | OS::Heat::SoftwareDeployment || 2014.1 | | OS::Heat::SoftwareDeployments|| 2014.2 | | OS::Heat::Stack ||| | OS::Heat::StructuredConfig || 2014.1 | | OS::Heat::StructuredDeployment || 2014.1 | | OS::Heat::StructuredDeployments || 2014.2 | | OS::Heat::SwiftSignal|| 2014.2 | | OS::Heat::SwiftSignalHandle || 2014.2 | | OS::Heat::UpdateWaitConditionHandle || 2014.1 | | OS::Heat::WaitCondition || 2014.2 | | OS::Heat::WaitConditionHandle|| 2014.2 | | OS::Neutron::Firewall||| | OS::Neutron::FirewallPolicy ||| | OS::Neutron::FirewallRule||| | OS::Neutron::FloatingIP ||| | OS::Neutron::FloatingIPAssociation ||| | OS::Neutron::HealthMonitor |
