Monday, 2016-02-08

*** amotoki has joined #tacker00:16
*** arturt_ has quit IRC00:42
*** arturt_ has joined #tacker00:43
*** bobh has joined #tacker00:43
*** arturt_ has quit IRC00:44
*** bobh has quit IRC00:56
*** arturt_ has joined #tacker01:02
*** bobh has joined #tacker01:10
*** arturt_ has quit IRC01:12
*** arturt_ has joined #tacker01:13
*** arturt_ has joined #tacker01:23
*** arturt_ has quit IRC01:24
openstackgerritOpenStack Proposal Bot proposed openstack/tacker: Updated from global requirements  https://review.openstack.org/27713502:44
openstackgerritbharaththiruveedula proposed openstack/tacker-specs: Automatic resource creation for Tacker  https://review.openstack.org/25029102:50
*** arturt_ has joined #tacker03:12
*** arturt_ has quit IRC03:33
*** arturt_ has joined #tacker03:34
*** bobh has quit IRC03:50
*** arturt_ has quit IRC03:57
*** amotoki has quit IRC04:13
*** arturt_ has joined #tacker04:22
*** arturt_ has quit IRC04:26
*** amotoki has joined #tacker04:27
*** amotoki has quit IRC04:39
*** amotoki has joined #tacker04:40
*** amotoki has quit IRC04:56
*** amotoki has joined #tacker05:11
*** arturt_ has joined #tacker05:22
*** arturt_ has quit IRC05:32
*** arturt_ has joined #tacker05:35
*** arturt_ has quit IRC05:42
*** arturt_ has joined #tacker05:53
*** yfujioka has joined #tacker05:54
*** lhcheng has quit IRC05:55
*** arturt_ has quit IRC06:02
*** amotoki_ has joined #tacker06:08
*** amotoki has quit IRC06:11
openstackgerritMerged openstack/tacker: Updated from global requirements  https://review.openstack.org/27713506:26
openstackgerritMerged openstack/tacker-horizon: Updated from global requirements  https://review.openstack.org/27713206:26
*** lhcheng has joined #tacker07:01
*** arturt_ has joined #tacker07:03
*** arturt_ has quit IRC07:08
*** dkushwaha has quit IRC07:43
*** zeih_ has joined #tacker07:48
*** arturt_ has joined #tacker08:04
*** arturt_ has quit IRC08:11
*** dharmendra has joined #tacker08:44
*** amotoki_ has quit IRC08:55
*** openstackgerrit has quit IRC09:02
*** openstackgerrit has joined #tacker09:03
*** arturt_ has joined #tacker09:07
*** mbound has joined #tacker09:09
*** zeih_ has quit IRC09:13
*** arturt_ has quit IRC09:13
*** dharmendra has quit IRC09:13
*** amotoki has joined #tacker09:14
*** mbound has quit IRC09:15
*** dharmendra has joined #tacker09:18
*** mbound has joined #tacker09:21
*** zeih_ has joined #tacker09:27
*** amotoki has quit IRC09:32
*** dharmendra has quit IRC09:42
*** dkushwaha has joined #tacker10:04
*** arturt_ has joined #tacker10:09
*** arturt_ has quit IRC10:14
openstackgerritdharmendra kushwaha proposed openstack/tacker-horizon: Rename the methods  https://review.openstack.org/27733410:46
*** lhcheng has quit IRC10:59
*** arturt_ has joined #tacker11:10
*** arturt_ has quit IRC11:15
*** zeih_ has quit IRC11:36
*** zeih_ has joined #tacker11:42
*** arturt_ has joined #tacker12:11
*** amotoki has joined #tacker12:13
*** arturt_ has quit IRC12:15
*** amotoki has quit IRC12:35
*** amotoki has joined #tacker12:58
*** arturt_ has joined #tacker13:11
*** bobh has joined #tacker13:14
*** amotoki has quit IRC13:15
*** arturt_ has quit IRC13:15
*** bobh has quit IRC13:19
*** mbound has quit IRC14:01
*** mbound has joined #tacker14:09
*** arturt_ has joined #tacker14:12
*** arturt_ has quit IRC14:16
*** sridhar_ram has joined #tacker14:52
*** egonzalez has joined #tacker15:03
*** arturt_ has joined #tacker15:13
*** zeih_ has quit IRC15:17
*** arturt_ has quit IRC15:18
*** bobh has joined #tacker15:20
*** amotoki has joined #tacker15:24
*** egonzalez has quit IRC15:28
*** egonzalez has joined #tacker15:31
*** mbound has quit IRC15:42
*** amotoki has quit IRC15:46
*** mbound has joined #tacker15:49
*** egonzalez has quit IRC15:52
*** egonzalez has joined #tacker15:53
*** sridhar_ram has quit IRC15:58
*** arturt_ has joined #tacker16:14
*** gubouvier has quit IRC16:14
*** arturt_ has quit IRC16:18
*** arturt_ has joined #tacker16:20
*** prashantD has joined #tacker16:40
*** egonzalez has quit IRC16:44
*** gubouvier has joined #tacker16:46
*** uck has joined #tacker16:54
*** gubouvier has quit IRC17:00
*** arturt_ has quit IRC17:03
*** lhcheng has joined #tacker17:17
*** lhcheng_ has joined #tacker17:21
*** lhcheng has quit IRC17:23
*** mbound has quit IRC17:25
*** mbound has joined #tacker17:48
*** mbound has quit IRC17:51
*** sridhar_ram has joined #tacker17:53
*** sripriya_ has joined #tacker17:58
*** uck has quit IRC18:14
*** s3wong has joined #tacker19:13
*** uck has joined #tacker19:15
*** uck has quit IRC19:19
sripriya_sridhar_ram: ping19:32
*** mbound has joined #tacker20:24
sridhar_ramsripriya_: pong20:35
sripriya_sridhar_ram: had a question regarding vim being stateful20:36
sripriya_sridhar_ram: goign forward, i guess it will be useful for us to maintain the vim's state as reachable or unreachable20:37
sripriya_sridhar_ram: for sfc or vnf monitoring20:37
sripriya_sridhar_ram: do you think we need to be including a 'status' column for the vim? this is also in reference to one of the comments20:38
sridhar_ramsripriya_: I'd say, at this point in our dev cycle, these things are quickly becoming nice-to-have IMO20:38
sridhar_ramsripriya_: It all depends on the effort estimation ? I'd suggest these as follow on RFEs for now20:39
sripriya_sridhar_ram: sounds good for RFE, the other question i had was exposing vim commands to user,  even though it is a "register vim" operation we do, i guess we need to implement something similar on the client for user commands20:40
sripriya_sridhar_ram: such as vim_register, vim_delete, vim_update20:40
sripriya_sridhar_ram: the rest apis in the back end still being create_vim, delete_vim, etc, :-)20:41
sridhar_ramsripriya_: absolutely ... we need CLI commands20:41
sripriya_sridhar_ram: ok20:42
sridhar_ramtrue .. however nothing stops you to code your handler functions for a POST on /vim resource to be called "register_vim"20:43
sripriya_ofcourse, we can have any 'blah_vim' to be called but we usually want to associate POST to a create operation, just to be consistent with the REST nomenclature20:45
sridhar_ramsripriya_: at that point it becomes a pure semantics discussion :)20:52
*** mbound has quit IRC20:53
*** uck has joined #tacker21:18
*** uck has quit IRC21:22
sridhar_rambobh: ping21:47
*** santoshk has joined #tacker21:52
bobhsridhar_ram: hello21:59
sridhar_rambobh: I'm considering to put tosca-parser integration discussion in tomorrow's weekly mtg.. will you be there ?22:00
*** prashantD has quit IRC22:00
bobhsridhar_ram: yes - as far as I know anyway22:00
sridhar_rambobh: thanks...22:01
sridhar_rambobh: another qq.. I'm browsing the heat-translator code a bit..22:02
sridhar_rambobh: https://github.com/openstack/heat-translator/tree/master/translator/hot22:02
sridhar_rambobh: is this the area that is relevant for us ?22:02
bobhsridhar_ram: yes - that's pretty much the only translation they support22:02
sridhar_rambobh: okay... the tosca side discussions are going in circles :(22:03
bobhsridhar_ram: I wish I could say I was surprised....22:03
*** prashantD has joined #tacker22:03
sridhar_rambobh: at this point it is  unclear how much of simple-profile work will be leveraged for nfv...22:04
bobhsridhar_ram: why would they want to start from scratch?22:04
sridhar_rambobh: I'm trying to give a sense of urgency...it is still a WIP22:04
bobhsridhar_ram: I'm not interested in re-inventing the wheel22:04
sridhar_rambobh: no, it is not much start from scratch.. it was anyway at a beginning point .. the nfv nodes are just nodes hanging off my themselves22:05
sridhar_ram*by themselves22:05
bobhsridhar_ram: exactly - not of much use in that form - better to build on top of what Simple Profile already has, and take advantage of heat-translator22:06
sridhar_rambobh: in fact, we, with tacker, forcing them to make some concrete steps (like VDU <-- Compute)22:06
sridhar_rambobh: that's where I've a question..22:06
sridhar_rambobh: ... if it turns out NFV nodes are custom node that "smells" like existing Simple profile nodes..22:07
sridhar_rambobh: .. how easy it is cut&paste existing code in heat-translator to also do nfv-heat-translator22:07
sridhar_ramimagine ... creating a clone of https://github.com/openstack/heat-translator/blob/master/translator/hot/tosca/tosca_compute.py into something like https://github.com/openstack/heat-translator/blob/master/translator/hot/tosca/tosca_vdu.py22:08
sridhar_ramtacker developers can pitch in for these NFV node types in heat-translator project22:09
bobhsridhar_ram: easy enough, but what is the advantage?22:09
sridhar_rambobh: it give the modelers some friend hand to design NFV node types without being restricted to what is cooking in Simple Profile22:10
* sridhar_ram argh...22:10
sridhar_ramit gives the modelers some *free* hand o design NFV node types without being restricted to what is cooking in Simple Profile22:10
bobhseems like a lot of extra work for very little gain - there are good reasons to fork, this doesn't seem like one of them - personal opinion anyway22:11
sridhar_ramjust a trade off .. basing off simple profile comes with a cost (slowness due to dependency)22:11
sridhar_ramsame here .. I don't have a hard preference..22:11
bobhBecause they are so fast and nimble on the NFV side....22:11
sridhar_ramfor me anything that can give things fast .. I would go22:12
sridhar_ramexactly22:12
bobhthey can make whatever changes they want in the derived objects and then push them upstream - should be no reason to wait on Simple Profile22:12
sridhar_ramthe risk with that approach (for modelers) is if they end up representing the same "attribute" in both but they are called differently in each of these profiles..22:13
bobhand so for the sake of a potential duplicate attribute they duplicate everything else - only an architect/modeler would make sense of that22:14
openstackgerritSripriya Seetharam proposed openstack/tacker-specs: Multisite VIM support for Tacker  https://review.openstack.org/24908522:16
openstackgerritSripriya Seetharam proposed openstack/tacker-specs: Multisite VIM support for Tacker  https://review.openstack.org/24908522:18
sridhar_rambobh: in heat-translator tosca_compute.py code .. it is actually calling nova for flavor create.. ouch22:19
sridhar_rambobh: I thought heat-translator is a library: tosca-in -> heat-trans --> hot-template out22:19
bobhit's a library and a stand-alone script, and soon to be a front-end to heat so it can deploy after parsing22:20
sripriya_bobh: s3wong: sridhar_ram: uploaded a new version of multisite spec, appreciate your review/comments22:20
s3wongsripriya_: sure. Thanks22:20
sridhar_rambobh: front-end meaning, plans to add to Horizon UI ?22:21
bobhsridhar_ram: heat-translator calls nova to retrieve existing flavors - it does not create new ones22:21
bobhsridhar_ram: not sure what the plan is, I know they are adding a "deploy" option so presumably you can call it from a script or as a library and have it do the heat deployment for you after the parsing22:21
sridhar_rambobh: again, looking at tosca_compute most of the code in there, like best_flavor, best_image, etc.. are not applicable for us22:26
bobhsridhar_ram: agreed - but that only kicks in if you specify os/host capabilities, so it wouldn't apply if we specify the properties for flavor/image22:27
sridhar_rambobh: wondering if we are better off doing our own ToscaTemplate to HOT22:27
sridhar_rambobh: another major factor for me to say this is MultiSite22:28
bobhsridhar_ram: easy enough to post-process what they return to us for now22:28
sridhar_rambobh: if we are specifying the flavor and image not much being leveraged out of tosca_compute code...it seems 90% of the code in that file is related to that22:30
sridhar_ram.. back to MultiSite.. my point is each remote site might running a different versions of Heat engine..22:31
sridhar_ram.. Kilo, Liberty, etc..22:31
sridhar_ramwe might need to translate slightly differently depending on the target HOT engine template version22:32
*** lhcheng has joined #tacker22:32
*** lhcheng_ has quit IRC22:32
bobhI don't think heat-translator supports different template versions yet, so at that point you are into new territory anyway22:33
sridhar_rambobh: frankly bit torn in this area.. I wish we can take this heat-translator in our hands (in tacker) for the next few cycles.. once things settle we can push it back into heat-translator22:34
bobhsridhar_ram: your call.  I just want to get it working first22:35
sridhar_rambobh: will think a bit more .. we can continue the discussion in tomorrow's mtg22:36
*** lhcheng has quit IRC22:37
*** lhcheng has joined #tacker22:38
sridhar_rambobh: btw, make sense to get it working first .. thats first order of business :)22:41
bobhsridhar_ram: :-)  I have the first part working - can load TOSCA VNFDs.  The second part needs some changes in heat-translator that will come in 0.4.0 in a couple of weeks22:42
sridhar_rambobh: Cool.. I'm still quite existing to see proper tosca templates in tacker with the first part .... just want to be cautious to not to get tied deep in this 2nd part. Ideally if there is library-util portion of heat-translator that we can leverage and create our own tosca_vdu.py, tosca_vl.py, etc.. in tacker code we can move fast.22:46
sridhar_rams/existing/exciting/22:46
sridhar_rammy fingers are already warming up for all the typos for tomorrow's irc meeting22:46
bobh:-)22:47
*** lhcheng has quit IRC23:03
*** lhcheng has joined #tacker23:03
*** arturt_ has joined #tacker23:18
*** uck has joined #tacker23:20
*** uck has quit IRC23:25
*** bobh has quit IRC23:31
*** arturt_ has quit IRC23:34
*** arturt_ has joined #tacker23:34
*** arturt_ has quit IRC23:52
*** arturt_ has joined #tacker23:59

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