Monday, 2016-12-05

*** shangxdy has joined #openstack-heat-translator01:15
*** shangxdy has quit IRC02:00
*** shangxdy has joined #openstack-heat-translator02:00
*** shangxdy has quit IRC02:09
*** shangxdy has joined #openstack-heat-translator02:09
*** shangxdy has quit IRC03:42
*** shangxdy has joined #openstack-heat-translator03:55
*** shangxdy has quit IRC04:02
*** shangxdy has joined #openstack-heat-translator04:04
*** shangxdy has quit IRC04:14
*** shangxdy has joined #openstack-heat-translator04:45
*** openstackgerrit has joined #openstack-heat-translator04:51
openstackgerritgongysh proposed openstack/heat-translator: support address property from tosca
*** shangxdy has quit IRC05:00
*** shangxdy has joined #openstack-heat-translator05:41
*** shangxdy has quit IRC05:59
*** shangxdy has joined #openstack-heat-translator06:00
*** tbh has joined #openstack-heat-translator07:11
*** openstackgerrit has quit IRC08:03
*** tbh has quit IRC09:12
*** shangxdy has quit IRC10:50
*** tbh has joined #openstack-heat-translator10:57
*** tbh has quit IRC11:23
*** tbh has joined #openstack-heat-translator11:24
*** tbh has quit IRC12:18
*** shangxdy has joined #openstack-heat-translator12:23
*** tbh has joined #openstack-heat-translator12:30
*** bobh has joined #openstack-heat-translator12:48
*** bobh has quit IRC12:48
*** bobh has joined #openstack-heat-translator12:48
*** uck has joined #openstack-heat-translator13:50
*** uck has quit IRC14:19
*** spzala has joined #openstack-heat-translator14:27
*** bobh has quit IRC14:35
*** bobh has joined #openstack-heat-translator14:42
*** bobh has quit IRC14:52
*** bobh has joined #openstack-heat-translator15:00
shangxdyHi, spzala15:02
shangxdyPlease take a look at the patch 367499, thanks.15:03
spzalashangxdy: Hi15:08
spzalashangxdy: yes, that's what I am working on right now :-)15:08
spzalashangxdy: thanks for your clarification that's helpful15:09
shangxdyI'am working on the output validation now, after that the capability and requirement need to be validated too.15:16
spzalashangxdy: :) np, thank you! How long can you stay on IRC today?15:22
shangxdyI'll go to bed:)15:22
spzalashangxdy: :) oh you are ready to go to bed15:23
spzalashangxdy: OK, I have some questions I think but trying to refer couple more things15:24
spzalashangxdy: I guess the best way is I send you email15:24
spzalashangxdy: I need 10-15 mins before I ask you question15:25
shangxdyyeah, if you have any suggestion, send mail to me add comments under the patch.15:25
shangxdyOh, it's ok, i can wait now:)15:26
spzalashangxdy: :) OK thank you so much15:26
shangxdyYou're welcome。15:27
spzalashangxdy: ok, there are few things. I def agree with you on inputs requirement as stated in spec15:35
spzalashangxdy: and we both know that it's confusing out there something we talked in a meeting in the past too15:36
*** bobh has quit IRC15:36
spzalashanxdy: so under the 'Example 16' in the spec link you sent15:36
spzala"Further note that no mappings for properties or attributes of the substituted node are defined. Instead, the inputs and outputs defined by the topology template have to match the properties and attributes or the substituted node. If there are more inputs than the substituted node has properties, default values must be defined for those inputs, since no values can be assigned through properties in a substitution case."15:36
spzalaI guess that's the probably the only place where it's mentioned right?15:37
shangxdyYes, i think so.15:38
spzalashangxdy: cool. So in the same example though, you can see "      user: { get_input: db_user }"15:39
shangxdyBut i have a doubt about the outputs, in my opinion, a subtemplate can define more outputs than the node type has attribtes.15:40
spzalawhere property name 'user' is not same as input name 'db_user'15:40
spzalashangxdy: yup agree. let's try to touch every points related to sub mappings one by one15:40
spzalashangxdy: so first let's finish input part15:41
shangxdyabout db_user and user, it already said that "Further note that no mappings for properties or attributes of the substituted node are defined."15:41
shangxdySo there is not relationship between db_user and user.15:42
spzalathat's true .. and that's because "tosca.nodes.Database" has a property called "user"15:43
shangxdyand i think that the definition is not complete.much is omitted for brevity.15:43
spzalaso what happens here in this example is the sub mappings is interested in the "user" property which is being fulfilled "user: { get_input: db_user}15:44
spzalathat's true...examples are not complete so that's what creates confusion15:44
spzalaplease feel free to not agree with my analysis of incompleted examples because that's how we will reach to a conclusion today :)15:45
spzalaabout incomplete part, the 'properties' for "user" part is clear here15:45
spzalaand if inputs: sections has "X" in stead of "db_user" then,15:46
shangxdy"user: { get_input: db_user}“, this is a coincidence i think.15:46
spzalauser: { get_input: X } is valid15:46
spzalano, so as I said "db_user" can be "X" that's OK too right?15:47
shangxdyIt can be X, but it is a additional input which has no relationship with node type.15:48
shangxdyyou can take a look at example 18.15:48
spzalano, no even the db_user has no relationship with node type15:48
spzalabecause the definition of tosca.nodes.Database is interested in "user"15:49
spzalaso that means "user" can15:49
spzalacan not be "X"15:49
spzalasure we will look at another example but let's finish this first15:49
spzalawe need to make sure that whether this example is right or wrong - i guess that will help us with overall picture if you agree with me there?15:50
shangxdyIf user can be X in input section, how can we instantiated the template?15:50
spzalasame way as input name is "db_user"15:50
shangxdyIn example 18, the input name match the property completly.15:51
spzalawhat I am saying is in this example "db_user" is an arbitrary name15:51
spzalaI agree for example 18 but what I am saying is let's first finish this example 16 :)15:51
spzalatrust me, I am with you and trying to understand the things together ..15:52
shangxdyi known what's your meaning.15:52
spzalayou and I need to agree on things .. I could be wrong and that's totally fine15:52
spzalabut at the end it will be nice that we both are agree on sub mappings concept and implementation15:53
spzalaso that's why it's important that we both go with certain understanding that might not mentioned in spec explicitly15:53
spzalaso in example 16, db_user can be anything X, Y or Z as long as an input name15:54
spzalayou agree with me on that?15:54
shangxdyyes, i agree.15:54
spzalawe will go to example 18 and discuss that again15:55
spzalaOK, cool because that's how I see that too. So again, for our reference as we go further in examples 18 and others, what's important to sub mappings is "to resolve properties and attributes name as it's defined in the definition"15:55
spzalaIn cases, where properties (and attributes) can not be resolved it's important that 'input names must be same as properties name"15:57
shangxdyIn this scenario of example 16, it means that we will analyze the nodetemplate definition in order to the mapping between inputs and properties?15:57
spzala"node type definition" that's what important analyzer - so the nodetemplate must meet the node type defintion15:58
shangxdyyes, it's sure.15:58
spzalain example 16, what TOSCA says is "a tosca.nodes.Database" type can be substituted by node template "database" because it fulfills needs type definition15:59
spzalathx, so far so sounds good right?16:00
spzalalet's go further then :)16:00
shangxdyBut it doesn't resolve the parameterization by properties of substituted node.16:02
shangxdyI think this is the point too.16:03
spzalashangxdy: hmmm.. sorry I didn't understand that16:03
spzalafor example 16 right?16:03
shangxdyyes, example 16.16:03
spzalaOK can you elaborate your question please?16:05
spzalabecause in that case example is wrong right?16:05
shangxdyIf a input can't use to parameterize a template, the input doesn't need to exist.16:06
spzalawell in this case input did get use16:08
spzalainput value of  "db_user" is what set to "user" property which is mandatory for Database node16:08
spzalaisn't that true?16:08
spzalabut I agree with you it's all confusing :) .. but so you are okay there?16:11
spzalaI am coming to the point (per my understanding) of where input names are mandatory to be same as property name if we are okay with example 1616:11
shangxdyi see16:12
spzalaOK so good to go further right?16:14
spzalaOK so let's think of a similar example to 'quingsubsystem'16:18
spzala  node_type:16:18
spzala    mydb:16:18
spzala      derived_from: tosca.nodes.Database16:18
spzala      properties:16:18
spzala        provider: IBM16:18
spzala  substitution_mappings:16:18
spzala    node_type: mydb16:19
spzalalet's in example 16 we want to create a custom type called "mydb" which is derived from Database node16:19
spzalabut it also has it's own property of provider of dbms or something .. just as an example16:20
shangxdyok,please go ahead.16:20
*** bobh has joined #openstack-heat-translator16:22
spzalaok, so let's think the template is used from another service template called xzy.yaml16:22
spzalawhich imports the template created in example 16 with custom type of mydb16:23
spzala(i guess regardless of custom type I am using here, the best way to understand the need for input name is using sub mapping via another template)16:24
shangxdyI'am listening...16:25
spzalato me service template have to have input called 'provider' so that the sub mapping node (imported template) can get the passed input to resolve the need of it's property16:25
spzalaso to me there are two ways to fulfill the need of substitution_mappings node,16:26
spzala1. by property name - if an exact property name is provided the sub_mappings can resolve it16:27
spzala2. if a value is passed to it via input name then the input name must be same as property name16:27
shangxdyfor 1, what's the exact property name? provider?16:29
shangxdywhat about your input definition?16:31
*** xuhaiwei_ has quit IRC16:31
spzalathat's true16:33
spzala  substitution_mappings:16:35
spzala    node_type: tosca.nodes.mydb16:35
spzala    properties:16:35
spzala      provider: {get_input: provider}16:35
shangxdymydb is only a node type, not a node tempalte how about the input section?16:35
spzalathe second one is16:35
spzalaif the sub mapping is used as above then that's where input name is mandatory16:35
shangxdyI don't think so, in substitution mapping, there is not any property defined.16:36
spzalayou can16:36
spzalajust our example doesn't have it16:36
spzalaExample 19 in spec16:37
spzala substitution_mappings:16:37
spzala    node_type: example.TransactionSubsystem16:37
spzala    capabilities:16:37
spzala      message_receiver: [ app, message_receiver ]16:37
spzala    requirements:16:37
spzala      database_endpoint: [ app, database ]16:37
spzalayou can add properties section similar to capabilities, reqs sections16:37
shangxdyin spec, 3.8.2 Grammar for substitution mappings16:37
spzalathat's a good pointer16:38
shangxdyonly capabilities, requirements and node type in substitution mappings.16:39
spzalaand in that case I guess if spec restricts to only cap and req16:39
spzalaI had some discussion with Thomas few months back on it when we both thought properties can be used in sub mappings16:40
spzalabut if spec is restricting it, I will go with spec16:40
shangxdyCurrently, the spec is restricting it.16:41
spzalabut in this case, you can think of input names as mandatory if not provided in the properties of where it's being called16:41
spzalaso same example as above,16:41
spzala1. you have service template which is not providing property name of what's required by substitution_mappings16:43
spzala  node_templates:16:44
spzala    database:16:44
spzala      type: tosca.nodes.Database16:44
spzala      properties:16:44
spzala        user: { get_input: db_user }16:44
spzala        # other properties omitted for brevity16:44
spzala      requirements:16:44
spzala        - host: dbms16:44
spzalain example 1616:44
spzalawhere this template was imported in another service template and used for substitute mappings but without providing property 'user'16:45
spzalai guess for properties that are optional in type definition16:45
spzalato be specific, if the substitution_mappings template is resolving something with "get_input"16:46
spzalathen have input name mandatory as property name16:46
spzalaif susbstitution_mappings not using "get_input" then it's not mandatory16:47
spzalabut it only is that way when sub_mappings template is used in another template16:47
spzalabut per example 16 where everything is within a single template what matters is property name16:48
spzalanot input name16:48
spzalaand so in your example I guess we can let input names be mandatory and makes sense?16:49
shangxdyin fact, we can map the input name to the property if they are not the same by get_input.16:50
spzalahmm... what do you mean?16:51
shangxdyBut i think it's not necessary and it's indirect.16:51
spzalashangxdy: sure, then let's keep it simple16:51
spzalaI have just one comment to your patch16:52
spzalaplease take a look16:52
spzalawe need to make that correction16:52
shangxdyCould you raise a issue to TOSCA standard team?16:52
shangxdyok, i will16:53
spzalasorry, issue related to my comment?16:54
spzalathanks on fixing, for output validation we will go with same approach as input validation16:55
shangxdyissue related to example 16, which is confusing.16:56
spzalawell, example 16 is correct but yes I will bring it up to the next TC meeting16:58
shangxdyabout the patch, i'll delete the requirements in test yaml file.16:58
spzalashangxdy: yep that's good enough16:59
*** uck has joined #openstack-heat-translator17:00
spzalashanxdy: sorry keep you awake till late night but this was a good discussion, thanks again for staying up :)17:00
shangxdyit doesn't matter:)17:01
shangxdyany other discussions?17:03
spzalano, nothing more for today :-)17:04
spzalaI should let you go sleep :)17:04
shangxdyok, i'll go to bed now:)17:04
shangxdybye, good day!17:04
spzala:) OK, thx. Good night!!17:04
spzalahope that's right17:05
*** uck has quit IRC17:05
*** uck has joined #openstack-heat-translator17:06
*** shangxdy has left #openstack-heat-translator17:11
*** bobh has quit IRC17:23
*** openstackgerrit has joined #openstack-heat-translator17:33
openstackgerritbharaththiruveedula proposed openstack/heat-translator: Adds support for SoftwareDeploymentGroup in HT
*** bobh has joined #openstack-heat-translator18:18
*** openstackstatus has joined #openstack-heat-translator18:54
*** ChanServ sets mode: +v openstackstatus18:54
tbhspzala, when you find time, can you please review ?18:57
*** tbh has quit IRC18:59
spzalatbh: yup19:01
*** tbh has joined #openstack-heat-translator19:41
*** bobh has quit IRC19:50
*** uck has quit IRC20:05
*** uck has joined #openstack-heat-translator21:05
*** uck has quit IRC21:10
*** spzala has quit IRC21:14
*** tbh has quit IRC21:28
*** bobh has joined #openstack-heat-translator21:52
*** uck has joined #openstack-heat-translator22:05
*** bobh has quit IRC22:16
*** bobh has joined #openstack-heat-translator22:34
*** spzala has joined #openstack-heat-translator23:15
*** spzala has quit IRC23:20
*** spzala has joined #openstack-heat-translator23:47

Generated by 2.14.0 by Marius Gedminas - find it at!