| *** shangxdy has joined #openstack-heat-translator | 01:15 | |
| *** shangxdy has quit IRC | 02:00 | |
| *** shangxdy has joined #openstack-heat-translator | 02:00 | |
| *** shangxdy has quit IRC | 02:09 | |
| *** shangxdy has joined #openstack-heat-translator | 02:09 | |
| *** shangxdy has quit IRC | 03:42 | |
| *** shangxdy has joined #openstack-heat-translator | 03:55 | |
| *** shangxdy has quit IRC | 04:02 | |
| *** shangxdy has joined #openstack-heat-translator | 04:04 | |
| *** shangxdy has quit IRC | 04:14 | |
| *** shangxdy has joined #openstack-heat-translator | 04:45 | |
| *** openstackgerrit has joined #openstack-heat-translator | 04:51 | |
| openstackgerrit | gongysh proposed openstack/heat-translator: support address property from tosca https://review.openstack.org/406705 | 04:51 |
|---|---|---|
| *** shangxdy has quit IRC | 05:00 | |
| *** shangxdy has joined #openstack-heat-translator | 05:41 | |
| *** shangxdy has quit IRC | 05:59 | |
| *** shangxdy has joined #openstack-heat-translator | 06:00 | |
| *** tbh has joined #openstack-heat-translator | 07:11 | |
| *** openstackgerrit has quit IRC | 08:03 | |
| *** tbh has quit IRC | 09:12 | |
| *** shangxdy has quit IRC | 10:50 | |
| *** tbh has joined #openstack-heat-translator | 10:57 | |
| *** tbh has quit IRC | 11:23 | |
| *** tbh has joined #openstack-heat-translator | 11:24 | |
| *** tbh has quit IRC | 12:18 | |
| *** shangxdy has joined #openstack-heat-translator | 12:23 | |
| *** tbh has joined #openstack-heat-translator | 12:30 | |
| *** bobh has joined #openstack-heat-translator | 12:48 | |
| *** bobh has quit IRC | 12:48 | |
| *** bobh has joined #openstack-heat-translator | 12:48 | |
| *** uck has joined #openstack-heat-translator | 13:50 | |
| *** uck has quit IRC | 14:19 | |
| *** spzala has joined #openstack-heat-translator | 14:27 | |
| *** bobh has quit IRC | 14:35 | |
| *** bobh has joined #openstack-heat-translator | 14:42 | |
| *** bobh has quit IRC | 14:52 | |
| *** bobh has joined #openstack-heat-translator | 15:00 | |
| shangxdy | Hi, spzala | 15:02 |
| shangxdy | Please take a look at the patch 367499, thanks. | 15:03 |
| spzala | shangxdy: Hi | 15:08 |
| spzala | shangxdy: yes, that's what I am working on right now :-) | 15:08 |
| spzala | shangxdy: thanks for your clarification that's helpful | 15:09 |
| shangxdy | thanks:) | 15:14 |
| shangxdy | I'am working on the output validation now, after that the capability and requirement need to be validated too. | 15:16 |
| spzala | shangxdy: :) np, thank you! How long can you stay on IRC today? | 15:22 |
| shangxdy | I'll go to bed:) | 15:22 |
| spzala | shangxdy: :) oh you are ready to go to bed | 15:23 |
| spzala | shangxdy: OK, I have some questions I think but trying to refer couple more things | 15:24 |
| spzala | shangxdy: I guess the best way is I send you email | 15:24 |
| spzala | shangxdy: I need 10-15 mins before I ask you question | 15:25 |
| shangxdy | yeah, if you have any suggestion, send mail to me add comments under the patch. | 15:25 |
| shangxdy | Oh, it's ok, i can wait now:) | 15:26 |
| spzala | shangxdy: :) OK thank you so much | 15:26 |
| shangxdy | You're welcome。 | 15:27 |
| spzala | shangxdy: ok, there are few things. I def agree with you on inputs requirement as stated in spec | 15:35 |
| spzala | shangxdy: and we both know that it's confusing out there something we talked in a meeting in the past too | 15:36 |
| *** bobh has quit IRC | 15:36 | |
| spzala | shanxdy: so under the 'Example 16' in the spec link you sent | 15: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 |
| spzala | I guess that's the probably the only place where it's mentioned right? | 15:37 |
| shangxdy | Yes, i think so. | 15:38 |
| spzala | shangxdy: cool. So in the same example though, you can see " user: { get_input: db_user }" | 15:39 |
| shangxdy | But i have a doubt about the outputs, in my opinion, a subtemplate can define more outputs than the node type has attribtes. | 15:40 |
| spzala | where property name 'user' is not same as input name 'db_user' | 15:40 |
| spzala | shangxdy: yup agree. let's try to touch every points related to sub mappings one by one | 15:40 |
| spzala | shangxdy: so first let's finish input part | 15:41 |
| shangxdy | ok | 15:41 |
| shangxdy | about 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 |
| shangxdy | So there is not relationship between db_user and user. | 15:42 |
| spzala | that's true .. and that's because "tosca.nodes.Database" has a property called "user" | 15:43 |
| shangxdy | and i think that the definition is not complete.much is omitted for brevity. | 15:43 |
| spzala | so 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 |
| spzala | that's true...examples are not complete so that's what creates confusion | 15:44 |
| spzala | please feel free to not agree with my analysis of incompleted examples because that's how we will reach to a conclusion today :) | 15:45 |
| spzala | about incomplete part, the 'properties' for "user" part is clear here | 15:45 |
| spzala | right? | 15:45 |
| spzala | and 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 |
| spzala | user: { get_input: X } is valid | 15:46 |
| spzala | no, so as I said "db_user" can be "X" that's OK too right? | 15:47 |
| shangxdy | It can be X, but it is a additional input which has no relationship with node type. | 15:48 |
| shangxdy | you can take a look at example 18. | 15:48 |
| spzala | no, no even the db_user has no relationship with node type | 15:48 |
| spzala | because the definition of tosca.nodes.Database is interested in "user" | 15:49 |
| spzala | so that means "user" can | 15:49 |
| spzala | can not be "X" | 15:49 |
| spzala | sure we will look at another example but let's finish this first | 15:49 |
| spzala | we 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 |
| shangxdy | If user can be X in input section, how can we instantiated the template? | 15:50 |
| spzala | same way as input name is "db_user" | 15:50 |
| shangxdy | In example 18, the input name match the property completly. | 15:51 |
| spzala | what I am saying is in this example "db_user" is an arbitrary name | 15:51 |
| spzala | I agree for example 18 but what I am saying is let's first finish this example 16 :) | 15:51 |
| spzala | trust me, I am with you and trying to understand the things together .. | 15:52 |
| shangxdy | i known what's your meaning. | 15:52 |
| spzala | you and I need to agree on things .. I could be wrong and that's totally fine | 15:52 |
| spzala | but at the end it will be nice that we both are agree on sub mappings concept and implementation | 15:53 |
| spzala | so that's why it's important that we both go with certain understanding that might not mentioned in spec explicitly | 15:53 |
| spzala | so in example 16, db_user can be anything X, Y or Z as long as an input name | 15:54 |
| spzala | you agree with me on that? | 15:54 |
| shangxdy | yes, i agree. | 15:54 |
| spzala | we will go to example 18 and discuss that again | 15:55 |
| spzala | OK, 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 |
| spzala | In cases, where properties (and attributes) can not be resolved it's important that 'input names must be same as properties name" | 15:57 |
| shangxdy | In 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 defintion | 15:58 |
| shangxdy | yes, it's sure. | 15:58 |
| spzala | in example 16, what TOSCA says is "a tosca.nodes.Database" type can be substituted by node template "database" because it fulfills needs type definition | 15:59 |
| spzala | thx, so far so sounds good right? | 16:00 |
| spzala | let's go further then :) | 16:00 |
| shangxdy | But it doesn't resolve the parameterization by properties of substituted node. | 16:02 |
| shangxdy | I think this is the point too. | 16:03 |
| spzala | shangxdy: hmmm.. sorry I didn't understand that | 16:03 |
| spzala | for example 16 right? | 16:03 |
| shangxdy | yes, example 16. | 16:03 |
| spzala | OK can you elaborate your question please? | 16:05 |
| spzala | because in that case example is wrong right? | 16:05 |
| shangxdy | If a input can't use to parameterize a template, the input doesn't need to exist. | 16:06 |
| spzala | well in this case input did get use | 16:08 |
| spzala | input value of "db_user" is what set to "user" property which is mandatory for Database node | 16:08 |
| spzala | isn't that true? | 16:08 |
| shangxdy | yes | 16:10 |
| spzala | but I agree with you it's all confusing :) .. but so you are okay there? | 16:11 |
| spzala | I 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 16 | 16:11 |
| spzala | ? | 16:11 |
| shangxdy | i see | 16:12 |
| spzala | OK so good to go further right? | 16:14 |
| shangxdy | ok | 16:15 |
| spzala | OK 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.Database | 16:18 |
| spzala | properties: | 16:18 |
| spzala | provider: IBM | 16:18 |
| spzala | substitution_mappings: | 16:18 |
| spzala | node_type: mydb | 16:19 |
| spzala | let's in example 16 we want to create a custom type called "mydb" which is derived from Database node | 16:19 |
| spzala | but it also has it's own property of provider of dbms or something .. just as an example | 16:20 |
| shangxdy | ok，please go ahead. | 16:20 |
| *** bobh has joined #openstack-heat-translator | 16:22 | |
| spzala | ok, so let's think the template is used from another service template called xzy.yaml | 16:22 |
| spzala | which imports the template created in example 16 with custom type of mydb | 16: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 |
| shangxdy | I'am listening... | 16:25 |
| spzala | to 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 property | 16:25 |
| spzala | so to me there are two ways to fulfill the need of substitution_mappings node, | 16:26 |
| spzala | 1. by property name - if an exact property name is provided the sub_mappings can resolve it | 16:27 |
| spzala | 2. if a value is passed to it via input name then the input name must be same as property name | 16:27 |
| shangxdy | for 1, what's the exact property name? provider? | 16:29 |
| shangxdy | what about your input definition? | 16:31 |
| *** xuhaiwei_ has quit IRC | 16:31 | |
| spzala | that's true | 16:33 |
| spzala | substitution_mappings: | 16:35 |
| spzala | node_type: tosca.nodes.mydb | 16:35 |
| spzala | properties: | 16:35 |
| spzala | provider: {get_input: provider} | 16:35 |
| shangxdy | mydb is only a node type, not a node tempalte how about the input section? | 16:35 |
| spzala | the second one is | 16:35 |
| spzala | if the sub mapping is used as above then that's where input name is mandatory | 16:35 |
| shangxdy | I don't think so, in substitution mapping, there is not any property defined. | 16:36 |
| spzala | you can | 16:36 |
| spzala | just our example doesn't have it | 16:36 |
| spzala | Example 19 in spec | 16:37 |
| spzala | substitution_mappings: | 16:37 |
| spzala | node_type: example.TransactionSubsystem | 16:37 |
| spzala | capabilities: | 16:37 |
| spzala | message_receiver: [ app, message_receiver ] | 16:37 |
| spzala | requirements: | 16:37 |
| spzala | database_endpoint: [ app, database ] | 16:37 |
| spzala | you can add properties section similar to capabilities, reqs sections | 16:37 |
| shangxdy | in spec, 3.8.2 Grammar for substitution mappings | 16:37 |
| spzala | that's a good pointer | 16:38 |
| shangxdy | only capabilities, requirements and node type in substitution mappings. | 16:39 |
| spzala | and in that case I guess if spec restricts to only cap and req | 16:39 |
| spzala | I had some discussion with Thomas few months back on it when we both thought properties can be used in sub mappings | 16:40 |
| spzala | but if spec is restricting it, I will go with spec | 16:40 |
| shangxdy | Currently, the spec is restricting it. | 16:41 |
| spzala | but in this case, you can think of input names as mandatory if not provided in the properties of where it's being called | 16:41 |
| spzala | so same example as above, | 16:41 |
| spzala | 1. you have service template which is not providing property name of what's required by substitution_mappings | 16:43 |
| spzala | node_templates: | 16:44 |
| spzala | database: | 16:44 |
| spzala | type: tosca.nodes.Database | 16:44 |
| spzala | properties: | 16:44 |
| spzala | user: { get_input: db_user } | 16:44 |
| spzala | # other properties omitted for brevity | 16:44 |
| spzala | requirements: | 16:44 |
| spzala | - host: dbms | 16:44 |
| spzala | in example 16 | 16:44 |
| spzala | where this template was imported in another service template and used for substitute mappings but without providing property 'user' | 16:45 |
| spzala | i guess for properties that are optional in type definition | 16:45 |
| spzala | to be specific, if the substitution_mappings template is resolving something with "get_input" | 16:46 |
| spzala | then have input name mandatory as property name | 16:46 |
| spzala | if susbstitution_mappings not using "get_input" then it's not mandatory | 16:47 |
| spzala | but it only is that way when sub_mappings template is used in another template | 16:47 |
| spzala | but per example 16 where everything is within a single template what matters is property name | 16:48 |
| spzala | not input name | 16:48 |
| spzala | and so in your example I guess we can let input names be mandatory and makes sense? | 16:49 |
| shangxdy | in fact, we can map the input name to the property if they are not the same by get_input. | 16:50 |
| spzala | hmm... what do you mean? | 16:51 |
| shangxdy | But i think it's not necessary and it's indirect. | 16:51 |
| spzala | shangxdy: sure, then let's keep it simple | 16:51 |
| spzala | I have just one comment to your patch | 16:52 |
| spzala | please take a look | 16:52 |
| spzala | we need to make that correction | 16:52 |
| shangxdy | Could you raise a issue to TOSCA standard team? | 16:52 |
| shangxdy | ok, i will | 16:53 |
| spzala | sorry, issue related to my comment? | 16:54 |
| spzala | thanks on fixing, for output validation we will go with same approach as input validation | 16:55 |
| shangxdy | issue related to example 16, which is confusing. | 16:56 |
| spzala | well, example 16 is correct but yes I will bring it up to the next TC meeting | 16:58 |
| shangxdy | about the patch, i'll delete the requirements in test yaml file. | 16:58 |
| spzala | shangxdy: yep that's good enough | 16:59 |
| *** uck has joined #openstack-heat-translator | 17:00 | |
| spzala | shanxdy: sorry keep you awake till late night but this was a good discussion, thanks again for staying up :) | 17:00 |
| shangxdy | it doesn't matter：） | 17:01 |
| spzala | :) | 17:02 |
| spzala | thanks | 17:02 |
| shangxdy | any other discussions？ | 17:03 |
| spzala | no, nothing more for today :-) | 17:04 |
| spzala | I should let you go sleep :) | 17:04 |
| shangxdy | ok, i'll go to bed now:) | 17:04 |
| shangxdy | bye, good day! | 17:04 |
| spzala | :) OK, thx. Good night!! | 17:04 |
| spzala | Wǎn'ān | 17:05 |
| spzala | :) | 17:05 |
| spzala | hope that's right | 17:05 |
| *** uck has quit IRC | 17:05 | |
| spzala | bye! | 17:05 |
| *** uck has joined #openstack-heat-translator | 17:06 | |
| *** shangxdy has left #openstack-heat-translator | 17:11 | |
| *** bobh has quit IRC | 17:23 | |
| *** openstackgerrit has joined #openstack-heat-translator | 17:33 | |
| openstackgerrit | bharaththiruveedula proposed openstack/heat-translator: Adds support for SoftwareDeploymentGroup in HT https://review.openstack.org/407104 | 17:33 |
| *** bobh has joined #openstack-heat-translator | 18:18 | |
| *** openstackstatus has joined #openstack-heat-translator | 18:54 | |
| *** ChanServ sets mode: +v openstackstatus | 18:54 | |
| tbh | spzala, when you find time, can you please review https://review.openstack.org/407104 ? | 18:57 |
| *** tbh has quit IRC | 18:59 | |
| spzala | tbh: yup | 19:01 |
| *** tbh has joined #openstack-heat-translator | 19:41 | |
| *** bobh has quit IRC | 19:50 | |
| *** uck has quit IRC | 20:05 | |
| *** uck has joined #openstack-heat-translator | 21:05 | |
| *** uck has quit IRC | 21:10 | |
| *** spzala has quit IRC | 21:14 | |
| *** tbh has quit IRC | 21:28 | |
| *** bobh has joined #openstack-heat-translator | 21:52 | |
| *** uck has joined #openstack-heat-translator | 22:05 | |
| *** bobh has quit IRC | 22:16 | |
| *** bobh has joined #openstack-heat-translator | 22:34 | |
| *** spzala has joined #openstack-heat-translator | 23:15 | |
| *** spzala has quit IRC | 23:20 | |
| *** spzala has joined #openstack-heat-translator | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!