Thursday, 2016-05-19

*** bobh has quit IRC00:07
*** sridhar_ram1 has quit IRC00:28
*** sridhar_ram has joined #openstack-heat-translator00:32
*** bobh has joined #openstack-heat-translator00:33
*** spzala has joined #openstack-heat-translator01:08
*** spzala has quit IRC01:08
*** spzala has joined #openstack-heat-translator01:08
bobhspzala: ping01:14
spzalabobh: hi01:14
bobhspzala: so the folded/literal string handling turns out to be a rabbit hole01:15
spzalalol01:15
bobhspzala: There is a whole section in the YAML spec about keeping/chomping trailing newlines, etc01:15
bobhspzala: The ">-" notation in your second example is actually valid YAML - the YAML translator did not find a newline at the end of the string so it adds the "-" as a chomp indicator01:16
bobhspzala: It seems to be indeterminate whether the yaml.load will keep or discard the trailing newline when it processes the TOSCA input string - in your examples it kept the newline in one case and discarded it in the other01:17
spzalabobh: interesting01:17
bobhspzala: I was hoping to implement it globally so we would not have to look at individual fields to determine whether they should be literal or folded01:17
spzalabobh: if it's valid, that's totally good with me then01:17
bobhspzala: user_data should pretty much always be literal01:18
spzalabobh: sure, other thing I mentioned I think was in one case instead of ">" it translated to "|"01:18
bobhspzala: Right - in that case it kept the trailing newline on the string and then decided it should be literal because of the trailing newline01:19
bobhspzala: but in your second example it stripped the trailing newline01:19
spzalabobh: I see01:19
bobhspzala: I'll be back in a minute - have to put a kid to bed01:19
spzalabobh: hehe, it's same here01:20
spzalabobh: in my case, I will be doing in 15 mins but then need to tell bed time story so it usually takes longer for me.01:20
spzalabobh: tty once you are back.. if I don't respond that means with kiddos.. but in that case will get back to you soon01:21
*** sridhar_ram has quit IRC01:41
bobhspzala: ideally there would be a way to preserve the format indicator from the original TOSCA template and apply it to the translated HOT template, but the yaml parser just loads the string with no record of whether it was literal or folded01:45
bobhspzala: so I'm thinking that if it has internal newlines (ignore trailing newlines) we should make it literal, and if it has no internal newlines and is more than X characters long (80?) it should be folded01:46
openstackgerritBob Haddleton proposed openstack/heat-translator: Implements literal and folded string support  https://review.openstack.org/31715001:52
openstackgerritBob Haddleton proposed openstack/heat-translator: Implements literal and folded string support  https://review.openstack.org/31715001:54
*** bobh has quit IRC01:57
*** vishwanathj has quit IRC02:09
*** bobh has joined #openstack-heat-translator02:35
*** spzala has quit IRC02:43
*** spzala has joined #openstack-heat-translator02:43
*** spzala has quit IRC02:44
*** spzala has joined #openstack-heat-translator02:44
spzalabobh: sure02:48
bobhspzala: the alternative was to handle individual property fields in each hot_* resource file, but that seems really kludgy02:49
spzalabobh: true, since it's all valid yaml I guess we should be fine. Can you please deploy translated template with heat to see it02:50
spzala's not complaining and if it's not then I guess we don't have to worry about02:50
bobhsure - I'll do it tomorrow when I get to work02:51
spzalabobh: I see you patch update, didn't test it but I will be right now to see if I still see ">-" and "|"02:51
spzalabobh: great, thanks!!02:51
bobhspzala: it will be interesting to see if Heat handles the '>-' notation02:51
spzalabobh: yup, I believe it should because it's valid yaml02:52
bobhspzala: me too02:52
spzalabobh: heat eventually will handle it as dict value02:52
spzalabobh: so it's strange, why I only see ">-" it. The test template you have out there doesn't have it02:53
spzalaand you already have it covered in unit test02:53
bobhspzala: yes - very strange - the YAML spec has a set of conditions about how it handles the scalar string objects so it must be hitting one of the special cases02:54
spzalabobh: true02:54
bobhspzala: I ca reproduce the >- but no idea why the testcase doesn't have the same behavior02:54
bobhs/ca/can/02:54
spzalabobh: ahh, interesting and strange. well, if Heat can handle it then we don't have to worry02:55
spzala- just: >02:55
spzala   write some.02:55
spzala   some more.02:55
bobhspzala: I put the >- notation into the tosca input template just to try it and it works as input too02:56
spzalatranslates by yaml as,02:56
spzala  {02:56
spzala    "just": "write some. some more.\n"02:56
spzala  }02:56
bobhspzala: lol02:56
spzala:-) where as,02:57
spzala- just: >-02:57
spzala   write some.02:57
spzala   some more.02:57
spzalashows this02:57
spzala  {02:57
spzala    "just": "write some. some more."02:57
spzala  }02:57
spzalaso it's all about how it handles newline as you said earlier02:58
spzalabobh: cool, that's a good test02:58
*** bobh has quit IRC02:58
*** bobh has joined #openstack-heat-translator02:58
bobhspzala: yep - lots more to learn about yaml02:59
spzalabobh: hehe, true02:59
spzalabobh: calling it a night unless we want to discuss anything otherwise good night :-)03:02
bobhspzala: good night - thanks!03:02
spzalabobh: we can chat in our IRC meeting tomorrow morning03:02
bobhspzala: ttyl03:02
spzalabobh: np, thank you!03:02
spzalabobh: good night! later.03:02
*** spzala has quit IRC03:03
*** bobh has quit IRC03:04
*** tbh has joined #openstack-heat-translator04:22
*** apoorv has joined #openstack-heat-translator05:57
*** sridhar_ram_ has quit IRC08:45
*** tbh has quit IRC09:17
*** sridhar_ram_ has joined #openstack-heat-translator09:56
*** apoorv has quit IRC10:47
*** apoorv has joined #openstack-heat-translator10:53
*** apoorv has quit IRC12:25
*** sridhar_ram_ has quit IRC12:55
*** bobh has joined #openstack-heat-translator13:19
*** tbh has joined #openstack-heat-translator14:57
*** spzala has joined #openstack-heat-translator15:08
*** tbh has quit IRC15:52
*** tbh has joined #openstack-heat-translator15:53
spzalaHello all16:00
bobho/16:00
spzalao/16:00
spzalatopol: tbh: o/16:00
tbho/16:00
spzalawell, let's start :)16:01
spzalabobh: we are almost on top of discussion on https://review.openstack.org/#/c/317150/16:01
spzalabut any update?16:01
*** shangxdy has joined #openstack-heat-translator16:02
spzalatbh: I have added to review the above patch too if you get time16:02
bobhspzala: oops.... forgot to try that this morning - too many distractions16:02
spzalabobh: lol16:02
bobhspzala: I will put it on the list for this afternoon16:02
spzalabobh: no rush at all16:02
tbhspzala, sure, will do that16:02
spzalabobh: cool, thanks16:02
spzalashangxdy: o/16:02
spzalatbh: thanks!16:03
shangxdyHI,spzala,bob and tbh:)16:03
tbhhi shangxdy16:03
bobhshangxdy: o/16:03
spzalaLast week we had some discussion on our priority item of finding a good way to support backward compatibility in tosca-parser and heat-transaltor16:04
spzalabobh: ^16:04
shangxdyIt seems long time to here.16:04
spzalaI had some discussion on oslo channel and with couple other folks16:04
spzalaso couple of things something that we should discuss16:05
shangxdyTosca-parser will be a part of oslo?16:06
spzalait seems like most openstack projects doesn't have a good way to support backward compatibility, usually they release and if it breaks anything they fix it and rerelease16:06
shangxdyo16:06
bobhouch16:06
spzalaI am not fan of that approach at all16:06
spzalabobh: yes16:07
spzalaIt was unexpected but I guess there seems no really good way out there.16:07
bobhspzala: can we use gate jobs to run different version combinations?16:07
spzalaoslo seems first project to going to start some automation for this problem16:08
spzalabobh: I guess so but I was suggested to start with one gate for master first16:08
spzalaassuming if master works fine then latest pypi should go good as well16:08
bobhspzala: makes sense16:09
spzalabobh: so one more thing which is different than what we discussed16:09
spzalashangxdy: no tosca-parser won't be part of oslo,16:09
spzalaI had discussion to know about in general approach in openstack16:09
spzalaso back to original discussion, we initially thought of creating gate job in tosca-parser for heat-translator16:10
shangxdyI think it's ok if the restful api are backward compatibility for most of openstack's other projects , but tosca-parser is different.16:11
spzalawhich can be more productive but it seems like not a practical approach as we may end up with several gate if down the road more projects start using parser and it requires to create gate against all of them16:11
spzalashangxdy: sure16:12
spzalabobh: so I think our best bet is to run heat-translator master with master of tosc-parser16:12
spzalafor which we will create gate in heat-translator for parser16:12
spzalaand if we find anything is breaking we fix it tosca-parser16:13
bobhspzala: today heat-translator master runs against the current tosca-parser official release?16:13
spzalaI found this little anti-productive but I guess it makes sense too that the project that uses a particular projects should do gate job16:13
spzalabobh: yes that's correct16:14
spzalabobh: so we will try to run against tosca-parser master as well and see if that breaks anything in heat-translator16:14
bobhspzala: that sounds like a good solution - it will pick up any errors introduced by tosca-parser changes as soon as they show up16:14
spzaladoes that make sense?16:14
spzalabobh: yes, exactly16:15
shangxdyWhat does "gate job" mean? are there more detailes?16:15
topolo/16:15
spzalatopol: o/16:15
bobhspzala: if there are known incompatibilities that are going to be introduced by tosca-parser the associated heat-translator patch can be coordinated to land at the same time16:15
spzalashangxdy: http://docs.openstack.org/infra/zuul/16:16
spzalabobh: yes, as I was saying it might need us to redo some work in tosca-parser but it's always good that we do it during ongoing development vs. we may need to do the work after release if we find such incompatibilities and rerelease etc..which is not quite ideal16:17
bobhspzala: agreed - anything we can do to limit production breakage is a good thing16:18
spzalashanxdy: pl take a look at the above link, let me know if you have any question.16:18
spzalabobh: yes, absolutely16:18
spzalaso this seems like a good plan to keep parser backward compatible with translator but other question I have is how about keeping translator backward compatible itself?16:19
spzalabobh: I am not sure but once we have work done in translator, you may need to do something similar in tacker for parser or translator if such a need arise16:20
*** vishwanathj has joined #openstack-heat-translator16:20
spzalaif we introduce or modify api in translator master, that can impact tacker or other projects too I guess?16:21
bobhspzala: could be - I've seen some chatter on the ML this week about using upper-constraints.txt in testing requirements, so this might be a candidate for that16:21
bobhwe could run a gate against tosca-parser master + heat-translator master - maybe skip functional tests to limit the duration and impact of the extra gate job16:22
spzalabobh: I see, sure16:22
spzalabobh: yes that's good idea I think16:22
shangxdyspzala, zuul is the component of openstack CI system, is right?16:22
spzalabobh: I guess it's not needed right away16:23
spzalalet's first see how heat-translator does it with parser and then tacker can use those patches?16:23
spzalashangxdy: yes, zuul automates tests for CI16:24
spzalabobh: there is no dependency so tacker can do work anytime16:24
shangxdyMy colleague has just set up a ci system based on openstack.16:26
shangxdyOk16:26
spzalashangxdy: ah, nice16:26
shangxdyBut i still don‘t know what is the relationship between the tosca-parser backward compatibility and the zuul. We are using zuul every commit.16:28
bobhspzala: sounds good16:28
spzalashangxdy: all the projects, not just tosca-parser, uses zuul to enforce testing before merging code change16:29
spzalashangxdy: for tosca-parser BC we were talking about creating a zuul gate to test heat-translator with master of tosca-parser16:29
spzalaso that if it breaks any tests, we can fix it right hen16:30
spzalashangxdy: makes sense?16:30
shangxdyyes,all the openstack project use zuul.16:30
spzalabobh: cool16:30
tbhspzala, that was a nice explanation :)16:30
spzalatbh: hehe, thanks :)16:31
spzalashanxdy: I hope you are good with the zuul question.16:32
spzalaI guess it's time for open discussion :)16:32
spzalaanyone has any other topic for discussion?16:32
spzalashangxdy: tbh: bobh: ^ anything? if there is no topic, I guess we can wrap up meeting. :-)16:34
bobhspzala: sounds good to me :-)16:35
tbhspzala, nothing from my end16:35
spzalabobh: tbh: :-) Thanks!!16:35
shangxdyonly use zuul only? what about jenkins or JJB?16:36
spzalaI will wait for shangxdy: :)16:36
spzalashangxdy: jenkins is already there16:37
spzalashangxdy: no extra set up is required for it16:37
spzalaJenkins is the CI server16:38
shangxdySorry, is there other more details about the solution?16:39
spzalashangxdy: no problem. Well for now solution detail all I have is to create a new gate in translator16:39
spzala:(16:39
spzalaI think we will be using openstack standard practices to create gate and that's pretty much it16:40
shangxdyOk16:42
spzalashangxdy: we will discuss it more as you need it16:43
shangxdyIt seems that i'v got the point, i just misunderstood.16:43
spzalashangxdy: OK, prefect :) and np!16:44
shangxdythanks.16:44
spzalano problem16:44
spzalaAlright everyone, thank you much for joining today!16:44
spzalagood night, good day! talk to you later.16:44
shangxdyGood day to all:)16:45
spzala:) thanks16:46
spzalabye all!16:46
shangxdyBye!16:49
openstackgerritMerged openstack/heat-translator: test heat-translator with master branch of tosca-parser  https://review.openstack.org/31830216:50
*** shangxdy has quit IRC16:53
*** sridhar_ram_ has joined #openstack-heat-translator17:30
*** tbh_ has joined #openstack-heat-translator18:21
*** tbh has quit IRC18:23
*** zaneb has quit IRC18:26
*** zaneb has joined #openstack-heat-translator18:29
*** tbh_ has quit IRC18:31
*** tbh_ has joined #openstack-heat-translator18:34
*** tbh_ has quit IRC18:57
*** sridhar_ram_ has quit IRC19:35
*** rebase has joined #openstack-heat-translator21:08
openstackgerritSahdev Zala proposed openstack/heat-translator: Remove incorrect envlist entry  https://review.openstack.org/31895521:39
*** sridhar_ram has joined #openstack-heat-translator21:39
*** sridhar_ram has quit IRC22:17
*** sridhar_ram has joined #openstack-heat-translator22:20
*** bobh has quit IRC22:37
*** sridhar_ram has quit IRC22:56
*** rebase has quit IRC23:27
openstackgerritSahdev Zala proposed openstack/heat-translator: Update tox entry to reflect full name  https://review.openstack.org/31897723:36

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!