| *** spzala has quit IRC | 00:00 | |
| *** vahidh_ has quit IRC | 00:35 | |
| *** vahidh has joined #openstack-heat-translator | 00:35 | |
| *** vahidh has quit IRC | 00:40 | |
| *** spzala has joined #openstack-heat-translator | 00:55 | |
| *** spzala has quit IRC | 01:00 | |
| *** sridhar_ram has quit IRC | 01:17 | |
| *** bobh has joined #openstack-heat-translator | 01:50 | |
| *** bobh has quit IRC | 01:50 | |
| *** spzala has joined #openstack-heat-translator | 01:58 | |
| *** spzala has quit IRC | 02:02 | |
| *** bobh has joined #openstack-heat-translator | 02:07 | |
| *** bobh has quit IRC | 02:13 | |
| *** openstackgerrit has quit IRC | 02:15 | |
| *** sridhar_ram has joined #openstack-heat-translator | 02:19 | |
| *** spzala has joined #openstack-heat-translator | 02:21 | |
| *** openstackgerrit has joined #openstack-heat-translator | 02:24 | |
| *** spzala has quit IRC | 02:29 | |
| *** bobh has joined #openstack-heat-translator | 02:47 | |
| *** bobh has quit IRC | 02:52 | |
| openstackgerrit | Merged openstack/heat-translator: Updated from global requirements https://review.openstack.org/278671 | 04:00 |
|---|---|---|
| *** sridhar_ram has quit IRC | 05:08 | |
| *** vahidh has joined #openstack-heat-translator | 05:21 | |
| *** vahidh has quit IRC | 05:25 | |
| *** tbh has joined #openstack-heat-translator | 06:50 | |
| *** vishwanathj has quit IRC | 07:00 | |
| *** openstackgerrit has quit IRC | 08:47 | |
| *** openstackgerrit_ has joined #openstack-heat-translator | 08:47 | |
| *** openstackgerrit_ is now known as openstackgerrit | 08:48 | |
| *** ig0r_ has joined #openstack-heat-translator | 12:12 | |
| *** tbh has quit IRC | 12:35 | |
| *** bobh has joined #openstack-heat-translator | 13:21 | |
| *** bobh has quit IRC | 13:25 | |
| *** bobh has joined #openstack-heat-translator | 14:19 | |
| *** spzala has joined #openstack-heat-translator | 14:21 | |
| *** ig0r_ has quit IRC | 15:21 | |
| openstackgerrit | Mathieu Velten proposed openstack/heat-translator: Merge interfaces between the node template, its type and its type hierarchy. https://review.openstack.org/269537 | 15:41 |
| *** vahidh has joined #openstack-heat-translator | 15:48 | |
| *** madhavi has joined #openstack-heat-translator | 15:50 | |
| madhavi | ----------------------/*--------------------------------------------++ | 15:56 |
| *** Meena_ has joined #openstack-heat-translator | 15:57 | |
| spzala | hi all | 16:00 |
| spzala | I am on call .. please give me a minute | 16:00 |
| *** Meena_ has quit IRC | 16:01 | |
| *** Meena_ has joined #openstack-heat-translator | 16:01 | |
| *** mvelten has joined #openstack-heat-translator | 16:04 | |
| spzala | o/ | 16:04 |
| spzala | topol: bobh: there? | 16:04 |
| spzala | mvelten: thanks for joining | 16:05 |
| bobh | o/ | 16:05 |
| spzala | Meena_: madhavi: hi | 16:05 |
| spzala | is srinivas joining? | 16:05 |
| Meena_ | Hi | 16:05 |
| madhavi | hi | 16:05 |
| topol | o/ | 16:05 |
| mvelten | hi there | 16:05 |
| spzala | so I have couple of things to discuss and get everyone's opinion | 16:06 |
| spzala | first, handling key_name https://bugs.launchpad.net/heat-translator/+bug/1544237 | 16:06 |
| openstack | Launchpad bug 1544237 in Heat Translator "Handle key_name parameter in translated template" [Medium,New] - Assigned to Bob Haddleton (bob-haddleton) | 16:06 |
| spzala | please look at it and see anyone has any comments with the approach we are taking. bobh is working on it | 16:07 |
| *** Meena__ has joined #openstack-heat-translator | 16:07 | |
| bobh | spzala: My plan is to use a general solution that copies all properties into the object | 16:07 |
| spzala | bobh: I was just talking to mvelten over phone and he is fine with the changes .. we are good but wanted to bring to everyone's attention | 16:07 |
| spzala | bobh: all propperties? well, let's see as you upload changes, that will give better idea. Also, you may want to look at the second discussion I wanted to have today | 16:08 |
| bobh | spzala: ok | 16:08 |
| spzala | second one is, handling parameters - today we force user to provide parameters if default value is not set in template | 16:09 |
| spzala | and we update template accordingly with actual values of parameters | 16:09 |
| *** Meena_ has quit IRC | 16:09 | |
| madhavi | srinivas is busy ..he might not join... | 16:09 |
| spzala | but we have requirements for couple things as I tried briefing here https://blueprints.launchpad.net/heat-translator/+spec/handle-cli-user-input | 16:10 |
| spzala | madhavi: thx for checking, np we will touch base via emails | 16:10 |
| spzala | also mvelten is working on https://review.openstack.org/#/c/269747/ | 16:11 |
| spzala | so basically what we want to do is: | 16:11 |
| spzala | 1. make parameters optionals, if provided validate it and in the translated template do not set actual value but use 'get_param: {x:y}" | 16:11 |
| spzala | so that user can have opportunity to provide parameters at the deployment time with Heat if they wish to | 16:12 |
| spzala | bobh: any comments on that? | 16:12 |
| bobh | spzala: it looks good to me - makes sense to support both scenarios | 16:12 |
| spzala | bobh: if not right away, please let me know once you can think about it | 16:13 |
| mvelten | if provided set it as default in the parameter description | 16:13 |
| spzala | bobh: yup | 16:13 |
| mvelten | just to be clear :) | 16:13 |
| spzala | mvelten: true, that way user of translator don't think providing parameters was waste | 16:13 |
| bobh | mvelten: so provided parameters override defaults, and can then be overridden again at deployment time? | 16:13 |
| spzala | mvelten: :) thanks | 16:13 |
| mvelten | exactly | 16:14 |
| bobh | +1 | 16:14 |
| spzala | so one problem here is, | 16:14 |
| spzala | handling parameters that may (mostly in real life) require from user for OS and HOST capabilities of TOSCA Compute | 16:14 |
| mvelten | the "set default to provided value" is already present, my patch changes hardcoding to get_param, no we have to handle the special cases of key_name ans stuff related to flavor/image | 16:15 |
| spzala | Heat has nothing to do with those parameters | 16:15 |
| bobh | mvelten: Is there a reason key_name needs to be a special case? | 16:15 |
| spzala | mvelten: yup those special cases | 16:15 |
| spzala | bobh: yes, it's special compare to other parameters because TOSCA doesn't have a concept of key | 16:16 |
| spzala | bobh: so TOSCA template won't have 'inputs' section with key_name | 16:16 |
| mvelten | the key_name can use a get_param, but it means that we are actually adding a parameter. Currently we never do that | 16:16 |
| bobh | spzala: We (Tacker) are deriving an object from Compute and then adding properties that Heat supports, like key_name | 16:16 |
| spzala | bobh: that's what we will be doing with your patch on key_name (we are doing it today but it's hard coded as you know) | 16:17 |
| bobh | spzala: yes | 16:17 |
| spzala | bobh: so when user provide key_name (something we need to have a unique name input key that we recognize as a key name, I believe) | 16:18 |
| spzala | we either create a new entry in parameters section and set key_name:get_param{} or | 16:19 |
| spzala | just create an entry for all Nova Server with key_name:<user provided value> | 16:19 |
| spzala | I guess second approach is cleaner and we don't mess with adding a new input | 16:19 |
| bobh | spzala: so does that require the user to provide a key for all Servers? | 16:20 |
| spzala | but that limits user to provide key_name at the translation time only vs providing at deployment time but that should be OK | 16:20 |
| spzala | bobh: hmmm.. that's good question .. so far with local testing I use single key only. Is it common to have scenario you mentioned? | 16:21 |
| bobh | spzala: depends on whether the user is storing the HOT template for deployment later or multiple times | 16:21 |
| mvelten | moreover the key is actually not mandatory, so if not specified in the input parameters of the translator we can just skip it | 16:21 |
| bobh | spzala: in our scenarios (NFV) we almost never use keys | 16:21 |
| spzala | mvelten: yes, agree .. that's the reason for bobh: patch on key_name | 16:21 |
| spzala | bobh: :-) OK, so then for now let's just not worry about multiple keys | 16:22 |
| spzala | bobh: that's how we have today, and no one complain yet .. so let's just go with single key expectation | 16:22 |
| spzala | and set that for Nova Server entries | 16:22 |
| bobh | spzala: I was thinking of the possibility that someone would translate they template and then deploy it multiple times using a different key for each deployment | 16:22 |
| spzala | bobh: mvelten: makes sense? | 16:22 |
| bobh | does this make "key_name" a reserved word when it shows up in inputs/parameters? | 16:23 |
| spzala | we have documentation of how we are handling key_name today, and we will document our new approach there | 16:23 |
| spzala | bobh: yep, we need to | 16:23 |
| spzala | bobh: to recognize the key | 16:23 |
| bobh | spzala: ok | 16:24 |
| spzala | cool | 16:25 |
| spzala | mvelten: sounds good? | 16:25 |
| mvelten | yes | 16:25 |
| spzala | bobh: mvelten: thx. I have a BP opened to use heat client for validating our translated template but as you know today (and we will continue it) | 16:26 |
| bobh | spzala: just to make sure I understand - in a Simple Profile template, specifying key_name in the inputs will cause the key_name property to be added to (all?) Compute nodes | 16:26 |
| spzala | bobh: well, no, I meant to say 'key_name' as reserved parameter to be expected as parameter. Since TOSCA doesn't have such concept and TOSCA can be used outside Heat, | 16:27 |
| spzala | it's up to user, if they have provided such a key name in advance in TOSCA template then we can use it accordinly | 16:28 |
| bobh | spzala: ok, just wanted to clarify - so the template itself will have no key_name reference required, but if you pass it a parameter it will be handled | 16:28 |
| spzala | bobh: yes | 16:28 |
| bobh | spzala: got it | 16:28 |
| spzala | bobh: cool, thx | 16:29 |
| spzala | bobh: mvelten: so I was saying that today we have hot_*.yaml templates that we expect as translation output for our testing, as you create such templates please please test it with Heat | 16:29 |
| spzala | :-) you might already, but if not please do so | 16:29 |
| bobh | spzala: will do | 16:30 |
| spzala | bobh: thanks | 16:30 |
| spzala | Meena_: I had the same question to you to your patch on policies :-) | 16:30 |
| mvelten | I can validate, testing them right now is a bit tricky our Heat is not cooperative with userdata: SOFTWARE_CONFIG | 16:31 |
| Meena__ | yes sahdev | 16:31 |
| spzala | Meena_: to make sure that they are deployable | 16:31 |
| spzala | mvelten: ahh, I see | 16:31 |
| mvelten | but i need to fix that so I should be able to fully test in some time | 16:31 |
| Meena__ | i tried with heat but ony the affinity case | 16:31 |
| bobh | mvelten: should user_data default be removed too? | 16:31 |
| spzala | mvelten: OK, I will try to run your templates. Yup, if you can have it in your environment that would be great and make patch merging quick | 16:32 |
| spzala | bobh: I guess so, that's needed to not to force user to create key | 16:32 |
| spzala | bobh: as part of the key_name fix right? | 16:33 |
| bobh | spzala: I can remove it at the same time. It might affect the SoftwareConfig and SoftwareDeployment resources | 16:33 |
| spzala | Meena_: cool :) OK, but you will be doing any new templates so that's great | 16:33 |
| mvelten | bobh: no we can't I think, if we do we need to pass everything through the cloudinit metadata using a MultipartMime something (I have examples in Magnum) | 16:33 |
| bobh | spzala: I need to check to see if user_data gets inserted anywhere, and if it does maybe user_data_format should be inserted only in those cases? | 16:34 |
| mvelten | If you try a SoftwareDeploy with userdata: RAW it rejects it | 16:34 |
| mvelten | oh sorry i was talking about user_data_format :) | 16:34 |
| spzala | bobh: Ohhhh | 16:35 |
| spzala | bobh: sorry I read it as key_name default | 16:35 |
| bobh | mvelten: so can we insert it only in that case? Also there is the possibility that the user might want to specify a specific user_data_format | 16:35 |
| spzala | bobh: No, please don't remove it | 16:35 |
| bobh | spzala: sorry about that | 16:35 |
| spzala | spzala: user data is good to have as default | 16:35 |
| spzala | bobh: ^ | 16:35 |
| bobh | spzala: I think it's another area that will need to be looked at as templates get more complex | 16:35 |
| spzala | bobh: that doesn't hurt anything I guess, and all TOSCA templates are based on softwareconfig | 16:36 |
| *** madhavi has quit IRC | 16:36 | |
| spzala | bobh: yup, let's look at it separately | 16:36 |
| bobh | spzala: ok - we'll see if we run into any issues | 16:36 |
| spzala | mvelten: thanks for your findings | 16:36 |
| spzala | bobh: yup | 16:36 |
| Meena__ | spzala: I have a question to ask | 16:37 |
| spzala | Meena_: sure | 16:37 |
| Meena__ | In placement policy, we are not passing the affinity or anti affinity rule in tosca parser | 16:38 |
| Meena__ | But I think that should be provided by the user | 16:38 |
| spzala | Meena_: hmmm.. sorry not on top of my head, policy may need to change little (something I can bring to TOSCA TC) as we implement | 16:39 |
| Meena__ | oh ok | 16:40 |
| spzala | Meena_: can we take it offline please? | 16:40 |
| Meena__ | sure | 16:40 |
| spzala | Meena_: cool, thanks | 16:40 |
| spzala | I don't have anything specific | 16:40 |
| spzala | Open discussion now - anyone has anything to discuss ? | 16:41 |
| Meena__ | Nothing from my side | 16:41 |
| bobh | spzala: nothing here | 16:41 |
| spzala | Meena_: bobh: cool | 16:41 |
| spzala | mvelten: anything else? | 16:42 |
| mvelten | nop fine for me :) | 16:42 |
| spzala | :) OK, thanks | 16:42 |
| *** sridhar_ram has joined #openstack-heat-translator | 16:42 | |
| bobh | spzala: one thing I just thought | 16:43 |
| spzala | well, great discussion all and very productive.. thank you so much and bye for now | 16:43 |
| spzala | bobh: sure | 16:43 |
| bobh | spzala: I need to add heat-translator to the global-requirements.txt for use in Tacker | 16:43 |
| spzala | Meena_: it must be late for you, feel free to drop if you want | 16:43 |
| Meena__ | fine bye | 16:43 |
| bobh | spzala: is that something you want to handle or should I make the change? Not sure whether to wait for 0.4.0 or not | 16:43 |
| spzala | Meena_: thanks. Bye! | 16:43 |
| *** Meena__ has left #openstack-heat-translator | 16:44 | |
| spzala | bobh: nope, I think that's just tracker specific change. | 16:44 |
| bobh | ok - just wanted to check since it's global Infra requirements | 16:44 |
| spzala | bobh: yup, sure | 16:45 |
| bobh | spzala: I'll include you as a reviewer just so you're aware | 16:45 |
| spzala | bobh: you may need to make changes once we have 0.4.0 out | 16:45 |
| bobh | spzala: that's why I think I will wait - I need 0.4.0 anyway | 16:45 |
| spzala | spzala: since certain thing in parser will need 0.4.0 of translator | 16:45 |
| spzala | bobh: sure, that's good too.. I thought if you want to go ahead with 0.3.0 or greater in requirement that will work for requirement side changes | 16:46 |
| bobh | spzala: still debating :-) | 16:46 |
| spzala | bobh: heat-translator is usually around 2-3 weeks cycle after parser release so I m hoping to have 0.4.0 of translator in 2 weeks | 16:47 |
| spzala | bobh: :-) | 16:47 |
| spzala | bobh: aren't you having tosca-parser specific req too? | 16:47 |
| bobh | spzala: thanks - there are a couple of things I need to get into that release so I'll try to get them in ASAP | 16:47 |
| bobh | spzala: yes - we needed 0.4.0 for that too | 16:47 |
| bobh | spzala: I am doing the work in stages in Tacker so we can review the tosca-parser changes first, then add in the heat-translator changes when 0.4.0 is available | 16:48 |
| spzala | bobh: sure, no worries.. I can always wait little more before pypi to get in something important | 16:48 |
| bobh | spzala: thanks! | 16:48 |
| spzala | bobh: sure | 16:48 |
| spzala | bobh: you are welcome! | 16:48 |
| spzala | alright then, have a nice rest of the day/evening :-) and talk to you later! thanks again all! | 16:49 |
| bobh | bye | 16:50 |
| spzala | bobh: bye | 16:50 |
| *** vishwanathj has joined #openstack-heat-translator | 16:57 | |
| openstackgerrit | Mathieu Velten proposed openstack/heat-translator: Merge interfaces between the node template, its type and its type hierarchy. https://review.openstack.org/269537 | 17:09 |
| openstackgerrit | Mathieu Velten proposed openstack/heat-translator: Interpret get_artifact in inputs handling https://review.openstack.org/276686 | 17:31 |
| *** vishwana_ has joined #openstack-heat-translator | 19:00 | |
| *** vishwanathj has quit IRC | 19:03 | |
| *** sridhar_ram1 has joined #openstack-heat-translator | 19:55 | |
| *** sridhar_ram has quit IRC | 19:56 | |
| *** spzala has quit IRC | 20:49 | |
| *** vishwanathj has joined #openstack-heat-translator | 21:13 | |
| *** vishwana_ has quit IRC | 21:15 | |
| *** spzala has joined #openstack-heat-translator | 21:19 | |
| *** spzala has quit IRC | 21:19 | |
| *** sridhar_ram1 is now known as sridhar_ram | 22:00 | |
| *** sridhar_ram has quit IRC | 23:00 | |
| *** vishwanathj has quit IRC | 23:08 | |
| openstackgerrit | Merged openstack/heat-translator: Merge interfaces between the node template, its type and its type hierarchy. https://review.openstack.org/269537 | 23:14 |
| *** bobh has quit IRC | 23:29 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!