Monday, 2016-06-27

« Sunday, 2016-06-26 Index Tuesday, 2016-06-28 »
*** bobh has joined #tacker01:05
*** bobh has quit IRC01:17
*** amotoki has joined #tacker01:34
*** bobh has joined #tacker02:33
*** bobh has quit IRC02:35
*** bobh has joined #tacker02:36
*** gongysh has joined #tacker02:37
*** bobh has quit IRC02:37
*** amit213 has joined #tacker02:39
yifeihi guys, when I deployed tacker mitaka manually, two errors happened as below, 1."TRACE tacker.common.config ImportError: Plugin 'vnfm' not found."   2. "TRACE tacker.service RuntimeError: Unable to load tacker from configuration file /usr/local/etc/tacker/api-paste.ini."02:51
yifeianybody can help me ? thank you02:52
yifeiI myself found the problem here, in /usr/lib/python2.7/dist-packages/pkg_resources/__init__.py02:54
yifei    def resolve(self):02:54
yifei        """02:54
yifei        Resolve the entry point from its module and attrs.02:54
yifei        """02:54
yifei        print ("yifei EntryPoint1 %s" % (self.module_name))02:54
yifei        module = __import__(self.module_name, fromlist=['__name__'], level=0)02:54
yifei        print ("yifei EntryPoint2 %s" % (module))02:54
yifei        try:02:54
yifei            print ("yifei EntryPoint3")02:54
yifei            return functools.reduce(getattr, self.attrs, module)02:54
yifei        except AttributeError as exc:02:54
yifei            raise ImportError(str(exc))02:54
yifeicannot __import__ tacker.vm.plugin02:55
*** tbh has joined #tacker03:28
openstackgerritwei zhang proposed openstack/tacker: Correct some misspell words  https://review.openstack.org/33428203:40
*** KanagarajM has joined #tacker03:56
openstackgerritKawaguchi Kentaro proposed openstack/python-tackerclient: Remove the mask password logic in vim list and vim show  https://review.openstack.org/32688404:00
*** sripriya has joined #tacker04:05
*** links has joined #tacker04:15
*** bobh has joined #tacker04:16
*** anshukch_ has joined #tacker04:24
*** anshukch has quit IRC04:24
*** amotoki has quit IRC04:27
*** amotoki has joined #tacker04:36
*** bobh has quit IRC04:39
*** amotoki has quit IRC04:44
*** janki has joined #tacker04:46
*** amit213 has quit IRC04:46
*** bobh has joined #tacker04:50
*** bobh has quit IRC04:54
*** bobh has joined #tacker04:57
*** tbh has quit IRC04:59
*** amotoki has joined #tacker05:02
*** bobh has quit IRC05:02
*** anshukch_ has quit IRC05:07
*** anshukch has joined #tacker05:08
*** sripriya has quit IRC05:11
*** tbh has joined #tacker05:18
*** sripriya has joined #tacker05:25
*** neel has joined #tacker05:39
*** santoshk has joined #tacker05:43
*** diga has joined #tacker05:47
openstackgerritSripriya Seetharam proposed openstack/tacker: Introduce uniqueness constraint on resource names  https://review.openstack.org/32975905:49
*** sripriya has quit IRC05:50
*** tbh has quit IRC05:55
*** bobh has joined #tacker05:59
*** tbh has joined #tacker05:59
*** bobh has quit IRC06:05
*** amotoki has quit IRC06:10
*** anshukch has quit IRC06:11
*** amotoki has joined #tacker06:13
*** zeih has joined #tacker06:41
*** tbh has quit IRC06:53
*** anshukch has joined #tacker06:55
*** amotoki has quit IRC06:58
*** bobh has joined #tacker07:01
*** Ravikiran_K has joined #tacker07:04
*** bobh has quit IRC07:05
*** amotoki has joined #tacker07:22
*** vishnoianil has joined #tacker07:27
*** amotoki has quit IRC07:28
*** dmk0202 has joined #tacker07:31
openstackgerritNeeldhwaj Pathak proposed openstack/python-tackerclient: Introduce tacker vnfd-template-validate command.  https://review.openstack.org/33385307:35
*** amotoki has joined #tacker07:39
openstackgerritNeeldhwaj Pathak proposed openstack/python-tackerclient: Introduce tacker vnfd-template-validate command.  https://review.openstack.org/33385307:40
*** santoshk has quit IRC07:55
*** tbh has joined #tacker07:56
*** bobh has joined #tacker08:02
*** Qiming has quit IRC08:03
*** Qiming has joined #tacker08:06
*** bobh has quit IRC08:07
*** tbh has quit IRC08:08
*** tbh has joined #tacker08:09
*** neel has quit IRC08:14
*** tbh has quit IRC08:29
*** anshukch has quit IRC08:35
*** zeih has quit IRC08:47
*** neel has joined #tacker08:50
*** bobh has joined #tacker09:03
*** bobh has quit IRC09:07
*** zeih has joined #tacker09:10
*** zeih has quit IRC09:11
*** zeih has joined #tacker09:11
*** Homeway has joined #tacker09:12
*** zeih has quit IRC09:16
*** Homeway has quit IRC09:24
*** amotoki has quit IRC09:24
*** amotoki has joined #tacker09:25
*** amotoki has quit IRC09:25
openstackgerritdharmendra kushwaha proposed openstack/tacker: WIP: Tosca template for nsd.  https://review.openstack.org/33437009:33
*** zeih has joined #tacker09:38
*** zeih has quit IRC09:43
*** anshukch has joined #tacker09:45
openstackgerritKanagaraj Manickam proposed openstack/tacker-specs: VNF manual and auto scaling  https://review.openstack.org/31857709:53
*** zeih has joined #tacker10:05
*** amotoki has joined #tacker10:06
*** KanagarajM has quit IRC10:08
*** zeih has quit IRC10:11
*** anshukch has quit IRC10:16
*** anshukch has joined #tacker10:16
*** zeih has joined #tacker10:33
*** zeih has quit IRC10:37
*** zeih has joined #tacker10:38
*** links has quit IRC10:43
*** anshukch_ has joined #tacker10:50
*** neel has quit IRC10:51
*** anshukch has quit IRC10:52
*** links has joined #tacker10:55
*** anshukch_ has quit IRC11:03
*** KanagarajM has joined #tacker11:03
KanagarajMgongysh, hi11:04
gongyshKanagarajM, hi11:04
*** neel has joined #tacker11:04
KanagarajMgongysh, trying to figure out the reason for the line https://github.com/openstack/tacker/blob/master/test-requirements.txt#L711:04
*** bobh has joined #tacker11:04
KanagarajMgongysh, and you have added it recently, kindly help :)11:05
gongyshKanagarajM, I don't think it is recently.11:06
gongyshKanagarajM, does it cause problem?11:07
KanagarajMgongysh, instead of adding as simple client name, why its full url ?11:07
*** bobh has quit IRC11:09
gongyshKanagarajM, good question. I think we can use simple client name.11:09
KanagarajMgongysh, but it seems tackerclient is not part of the global requirements. still11:10
KanagarajMgongysh, so we need to add it there first and i guess, its work arrounded in test-requirements.txt by using the complete url, its my assumption !11:10
sridhar_ramgongysh: KanagarajM: yes, it is sitting on my plate to make a tackerclient release off master, add it to g-r and remove that line in test-requirements.txt11:12
gongyshKanagarajM, If we use simple name, we need to do it in global requrirement way.11:12
KanagarajMsridhar_ram, hi, sure.11:13
KanagarajMgongysh, yes11:13
sridhar_ramdiga: welcome to Tacker!11:13
sridhar_ramdiga: there will be a Tacker midcycle meetup soon... please plan to attend as you can find possible areas to work / write BPs..11:14
*** anshukch has joined #tacker11:18
KanagarajMsridhar_ram, I have optimized the CLI and REST API for scaling based on the past discussions. when you find time, kindly have a look, now i see a good shape of them :)11:18
KanagarajMsridhar_ram, ^^ https://review.openstack.org/31857711:19
sridhar_ramKanagarajM: will soon, it is time to wrap up, i agree :)11:22
KanagarajMsridhar_ram, yes. thanks :)11:24
digasridhar_ram: Hi11:25
digasridhar_ram: Thank you11:25
digasridhar_ram: sure11:25
digasridhar_ram: I am setting up my dev env with latest devstack, I will start with bugs11:26
sridhar_ramdiga: good11:30
digasridhar_ram: :)11:34
*** KanagarajM has quit IRC11:34
*** anshukch has quit IRC11:49
*** neel has quit IRC12:01
*** bobh has joined #tacker12:05
*** amotoki has quit IRC12:08
*** amotoki has joined #tacker12:09
*** bobh has quit IRC12:10
*** diga has quit IRC12:11
*** amotoki has quit IRC12:39
*** chfrgiiun has joined #tacker12:40
*** anshukch has joined #tacker12:41
openstackgerritAlexandru Tudose proposed openstack/tacker: Remove unused references: pywin32 and wmi from tacker/hooks.py  https://review.openstack.org/33445812:49
*** uck has joined #tacker12:51
chfrgiiunhello contributors friends. can anyone tell me the driver list (router, firewall, vpn) the tacker support?12:51
*** bobh has joined #tacker13:06
*** bobh has quit IRC13:10
*** trozet has joined #tacker13:12
openstackgerritTim Rozet proposed openstack/tacker: Adds VNFFG Exceptions to NFVO Extension  https://review.openstack.org/33447313:15
*** aasmith has joined #tacker13:16
*** anshukch_ has joined #tacker13:45
*** anshukch has quit IRC13:45
*** amotoki has joined #tacker13:53
*** gongysh has quit IRC13:53
*** bobh has joined #tacker14:00
*** diga has joined #tacker14:00
*** uck has quit IRC14:00
*** janki has quit IRC14:02
*** amotoki has quit IRC14:05
*** amotoki has joined #tacker14:10
*** amotoki has quit IRC14:11
*** aasmith has quit IRC14:25
*** aasmith has joined #tacker14:26
*** Ravikiran_K has quit IRC14:35
*** Poorna has joined #tacker14:41
*** amit213 has joined #tacker14:43
*** anshukch_ has quit IRC14:49
*** anshukch has joined #tacker14:49
PoornaTest14:56
*** amotoki has joined #tacker14:57
PoornaI had a question about creation of VNFs via Tacker14:59
PoornaIs there a way to correlate the VNF instance with instances of the VDUs that were spawned by openstack ?15:01
*** gongysh has joined #tacker15:22
*** anshukch has quit IRC15:25
*** zeih has quit IRC15:27
*** diga has quit IRC15:27
*** zeih has joined #tacker15:28
*** anshukch has joined #tacker15:29
*** dmk0202 has quit IRC15:30
*** zeih has quit IRC15:32
openstackgerritgongysh proposed openstack/tacker: Use importutils and service from oslo  https://review.openstack.org/32745815:42
*** janki has joined #tacker15:45
*** links has quit IRC15:52
*** uck has joined #tacker15:54
*** gongysh has quit IRC16:22
*** amotoki has quit IRC16:37
*** gongysh has joined #tacker16:42
*** aasmith has quit IRC16:42
*** Ravikiran_K has joined #tacker16:44
*** amit213 has quit IRC16:46
openstackgerritTim Rozet proposed openstack/tacker: Adds VNFFG attributes to NFVO Extension  https://review.openstack.org/33321616:48
openstackgerritTim Rozet proposed openstack/tacker: Adds VNFFG Exceptions to NFVO Extension  https://review.openstack.org/33447316:54
*** aasmith has joined #tacker16:58
*** anshukch has quit IRC17:02
*** anshukch has joined #tacker17:02
*** uck has quit IRC17:02
openstackgerritJanki Chhatbar proposed openstack/python-tackerclient: VNFD Legacy template deprecatoin warning  https://review.openstack.org/33457317:13
openstackgerritJanki Chhatbar proposed openstack/python-tackerclient: VNFD legacy template deprecation warning  https://review.openstack.org/33458117:28
openstackgerritJanki Chhatbar proposed openstack/python-tackerclient: VNFD legacy template deprecation warning  https://review.openstack.org/33458117:30
*** amotoki has joined #tacker17:37
*** sripriya has joined #tacker17:38
sridhar_ramchfrgiiun: hi there.. can you clarify what you mean by driver list ? Tacker is Generic-VNFM (G-VNFM) and it doesn't have any specific code related to actual VNF type (vpn, router, firewall, etc).17:39
sridhar_ramchfrgiiun: there are mgmt-drivers to configure VNFs spawned by Tacker....17:39
sridhar_ramchfrgiiun: again, those are VNF specific, could be for router VNF, Firewall VNF, DPI, etc17:39
*** amotoki has quit IRC17:42
sridhar_ramPoorna: there is a way, a bit indirect at this time, to do that correlation you are looking for...17:42
sridhar_ramPoorna: using vnf-show command you can get the heat stack-id used to spawn VMs17:43
chfrgiiunhello sridhar_ram, thanks for the answer. You know where to find example of mgmt-drivers?17:45
*** uck has joined #tacker17:45
sridhar_ramchfrgiiun: there is one for openwrt, here at .. https://github.com/openstack/tacker/tree/master/tacker/vm/mgmt_drivers17:46
sridhar_ramPoorna: .. using the stack-id, and heat resource-list you can get the list of VMs spawned for a VNF...17:47
chfrgiiunThank you sridhar_ram :)17:48
sridhar_ramPoorna: btw, we are discussion an option to show more details using 'tacker vnf-show --details' flag.. perhaps this could be an enhancement we can consider for tacker... if you think this is useful, please write an RFE bug in https://bugs.launchpad.net/tacker17:49
jankisridhar_ram: I am working on creating VNFFG CRUD commands on client side17:50
jankiShould I create a new folder for VNFFG and add the function files there or add the files in existing folder?17:51
sridhar_ramjanki: let me look up17:52
sridhar_ramjanki: it shd go under nfvo https://github.com/openstack/python-tackerclient/tree/master/tackerclient/tacker/v1_0/nfvo17:53
sridhar_ramjanki: btw, did you coordinate with trozet so that there is no overlap w/ that he is doing...17:54
*** s3wong has joined #tacker17:54
*** gongysh has quit IRC17:55
jankisridhar_ram: yes, I talked with trozet. I would be helping on client/Horizon implementation17:55
*** sripriya has quit IRC17:59
*** prashantD has joined #tacker18:05
*** janki has quit IRC18:13
*** zeih has joined #tacker18:14
*** sripriya has joined #tacker18:21
*** janki has joined #tacker18:33
*** janki has quit IRC18:37
*** zeih has quit IRC18:59
*** santoshk has joined #tacker19:01
*** amit213 has joined #tacker19:04
*** sripriya_ has joined #tacker19:14
*** sripriya has quit IRC19:15
*** sripriya_ is now known as sripriya19:15
sridhar_ramjanki: great, thx for pursuing this !19:16
*** zeih has joined #tacker19:27
*** anshukch_ has joined #tacker19:32
*** anshukch has quit IRC19:32
*** zeih has quit IRC19:32
*** amotoki has joined #tacker19:39
*** amotoki has quit IRC19:44
*** aasmith has quit IRC19:51
*** aasmith has joined #tacker19:53
*** sripriya has quit IRC20:17
*** sripriya has joined #tacker20:35
*** aasmith has quit IRC20:40
s3wongtrozet: ping20:42
trozets3wong: hi20:42
s3wongtrozet: how was your trip to Berlin?20:42
s3wongtrozet: everything went well?20:42
trozets3wong: yeah it was good. Pretty tired by the end :)20:42
s3wongtrozet: I am taking over from LouisF for networking-sfc driver for Tacker VNFFG20:43
trozets3wong: oh ok20:43
s3wongtrozet: while trying to get started, I realize we don't have a driver interface specified from VNFFG plugin to its drivers20:43
trozets3wong: yeah its not specified I guess20:44
s3wongtrozet: what kind of parameters are you going to pass to the driver, for example, in creating nap20:45
s3wongnfp20:45
s3wongtrozet: my take is obviously the driver layer is the one translate whatever the plugin passes into Neutron port20:45
s3wongtrozet: I had been investigating what could be done to get Neutron port from heat stack20:46
trozets3wong: well we need to pass classifier, list of VNFs/ports, symmetrical, and attributes of those ports like NSH, etc20:46
trozets3wong: should the vnffg plugin query the VNFM to find out the ports? and pass them to the driver20:46
s3wongtrozet: what port structure are you going to pass?20:46
s3wongtrozet: not really --- imagine a case where we aren't using OpenStack as VIM20:46
s3wongtrozet: then we may not be talking about Neutron port, right?20:46
trozets3wong: sridhar_ram had talked about coming up with a way to query VNFM for information like its port ID20:47
trozets3wong: then VNFM uses its driver (in this case heat) to figure it out20:47
trozetso keep it generic so it works across VIMs20:47
s3wongtrozet: agreed that it should be a query to VNFM20:47
s3wongtrozet: networking-sfc driver should NOT be using HeatClient, for sure20:47
s3wongtrozet: though the need for Neutron port to form a port chain is very specific to networking-sfc, so it should resolve that20:48
s3wongtrozet: in the context of networking-sfc, we can --- for example --- use NeutronClient20:48
trozets3wong: hmm20:48
s3wongtrozet: VNFM can pass a dictionary back, or some form of flexible structure with some fixed key field20:49
trozets3wong: i think its appropriate for the plugin to query vnfm and build a structure of ports with attributes to send to the driver20:49
s3wongtrozet: but what if I have --- just as an example --- Kubernetes (whatever lifecycle management there) as a VNFM, and use flannel as the chain driver?20:50
s3wongtrozet: then at the driver layer, passing Neutron port would be meaningless20:51
trozets3wong: for example [ { id: <port uuid>, encap: 'vxlan_gpe', nsh_aware: true}, ... ]20:51
s3wongtrozet: although the concept of 'port' may be OK --- I would imagine everyone has that, unless you are dealing with app level abstraction20:51
trozets3wong: wouldnt VNFM still have a port id?20:51
trozetin the kubernetes case20:51
s3wongtrozet: who knows?  :-)20:51
s3wongtrozet: I believe in VNFM, the specification is 'network interface'20:52
trozeti think port id is OK, since we are accepting there is always a port20:52
trozetbased on ETSI specs and definition of connection points20:52
s3wongtrozet: the Heat template, OTOH, has 'port' reference20:52
s3wongtrozet: is that true? So ETSI explicitly calls out a 'port'?20:53
trozets3wong: im thinking of tosca20:55
trozets3wong: let me check the etsi spec though20:55
s3wongtrozet: so if you are resolving port-id at plugin layer, your mechanism of doing so would be via querying VNFM?20:56
s3wongtrozet: do we have to implement that too? Or is sripriya  or someone else going to?20:56
trozetThis may be for example a virtual port, a virtual NIC20:57
trozetaddress, a physical port, a physical NIC address or the20:57
trozetendpoint of an IP VPN enabling network connectivity.20:57
trozets3wong: CP^20:57
trozets3wong: yeah that was the idea...would be a new implementation20:57
s3wongtrozet: so this is good --- I tend to agree that at VNFFG level, you are dealing with CP20:57
s3wongtrozet: so that would be CP -> port translation from VNFM?20:58
s3wong(or at least some sort of network-intf-id)20:58
trozets3wong: yeah20:58
s3wongtrozet: just curious, did you look into how to get Neutron port uuid from Heat resources?21:00
trozets3wong: so would you think the driver would be invoked by a single method call "create_vnffg" or should we break it up into a "create_sfc" and "create_classifier" call21:00
trozets3wong: yeah if you look at the VNF heat stack it lists the neutron port21:00
s3wongtrozet: separate --- as it is possible for a single driver to invoke two different modules to go chain and classifier21:01
s3wongtrozet: cool! Easier than I thought21:01
trozets3wong: ok makes sense21:01
s3wongtrozet: networking-sfc deliberately separate the classifier related APIs from chain related APIs for the same reason21:02
trozets3wong: I pushed up a couple patches that are small21:02
trozets3wong: just attributes and exceptions21:02
s3wongtrozet: for backend network driver, it is conceivable that classifier and chain would be serviced by different backend drivers21:02
trozets3wong: trying to keep the patches as small as possible21:02
s3wongtrozet: that is the right idea21:02
s3wongtrozet: I am going to make mine DependsOn yours (with driver interface)21:02
trozets3wong: ok i'm fine if you come up with something you expect to be the interface21:03
trozetand we can tweak it later when we converge21:03
sridhar_rams3wong: it will be good to formalize this interface...21:03
s3wongtrozet: OK, sounds good21:03
sridhar_rams3wong: vnffg_abstract_driver.py21:04
sridhar_rams3wong: and have one implementation using vnffg_networking_sfc_driver.py ?21:04
s3wongsridhar_ram: yes, agreed. Formalizing would be good --- need to contract to agree on interface before we can fully parallelize21:04
s3wongsridhar_ram: sounds about right21:04
sridhar_rams3wong: cool, i know the devil is in the detail... looks you and trozet are on top of it :)21:05
s3wongtrozet: OK --- that's what I will start with then, assuming the VNFFG plugin would invoke driver with some form of network-intf-id21:06
s3wongtrozet: also, that means in case user only specify the VNF, the plugin layer would select a specific interface, right?21:07
trozets3wong: i think it would be an ordered list of dicts, the dict has the port id along with encap info and nsh support21:07
s3wongtrozet: OK21:07
sripriyatrozet: s3wong: fetching the interface details is done in the Heat infra driver and this call would be invoked by vnffg plugin? is my understanding right?21:10
s3wongsripriya: I would imagine VNFFG would invoke some API exposed by VNFM21:10
sripriyas3wong: right21:10
s3wongsripriya: VNFFG should NOT assume Heat, and should never use the HeatClient21:11
sripriyas3wong: yes, it is more on the VNFM plugin level21:11
s3wongsripriya: +121:11
s3wongsripriya: since it seems like trozet wants to do that translation at the VNFFG plugin level, you should let him now what the interface is once it becomes available. Thanks!21:12
sripriyas3wong: probably get_vnf_details should be exposed from vnfm plugin which internally invokes the appropriate driver to fetch the interface info.21:12
sridhar_ram+1, but the payload will have VIM specific details ? like neutron port IDs ?21:12
s3wongsripriya: sounds good --- I think it is OK to be more abstract than "get_port" --- it is perfectly fine for VNFFG plugin to parse the 'detail' and look for what it wants21:13
sridhar_ramapologies, if this was already mentioned in the chat above21:13
sridhar_ram*clarified in the chat above21:13
openstackgerritMerged openstack/tacker-horizon: Updated from global requirements  https://review.openstack.org/33370821:13
sripriyasridhar_ram: not sure what you mean by VIM level details?21:14
s3wongsridhar_ram: VNFFG is not multi-VIM aware, right?21:14
openstackgerritMerged openstack/tacker: Updated from global requirements  https://review.openstack.org/33370721:14
trozets3wong: i think VNFFG should be able to reference the connection point name21:15
sridhar_ramsripriya: neutron port IDs are VIM specific (openstack specific)... if I use VMware, it might be some other uuid..21:15
s3wongtrozet: then you will do lookup base on connection port name?21:15
s3wongsridhar_ram: precisely! That was the gist of my discussion above with trozet21:16
sripriyasridhar_ram: yes21:16
openstackgerritMerged openstack/python-tackerclient: Updated from global requirements  https://review.openstack.org/33370021:16
s3wongsridhar_ram: I was under the impression that at the networking-sfc driver level is when I would resolve some high-level construct into Neutron port21:16
sridhar_rams3wong: VNFFG should be multi-vim aware... in fact, all features should be .. atleast the features need to degrade gracefully depending on the target VIM's capabilities21:16
*** uck has quit IRC21:17
*** anshukch_ has quit IRC21:17
trozets3wong: yeah will need to parse it in VNFFG plugin after i get all the info from VNFM about the VNF21:17
*** chfrgiiun has quit IRC21:17
s3wongsridhar_ram: but trozet suggests that 'port' or even more abstractly 'network-interface' should be common across all VIMs21:17
sripriyasridhar_ram: the detail response should be abstract enough to generalize to hide vim specific syntax, etc.21:17
sridhar_rams3wong: what happens if the target VIM happen to be VMware or AWS..21:18
sridhar_ramsripriya: yes, that is one way of solving this...21:18
s3wongsridhar_ram: yep, that was my point (I used Kubernetes above) --- Neutron port is very specific to networking-sfc21:18
s3wongsridhar_ram: although technically UUID is just a string, so it could be anything :-)21:19
trozets3wong: port != neutron port21:19
sripriyasridhar_ram: s3wong: but again, the port information request is happening in the vnffg plugin level and not in the sfc-driver21:19
trozetsripriya: yeah that's what we concluded on21:20
sridhar_ramlets imagine a call you were referring to above, get_vnf_details() API in VNFM..21:20
s3wongtrozet: I am more afraid that something doesn't even have a 'port' concept --- AWS actually doesn't, it is a network interface with IP address21:20
trozetsripriya: but you aren't writing that api to query VNFM for that info right?  I should write it? or...21:20
trozets3wong: isnt that a port :)21:20
sripriyas3wong: trozet: i have the same question as above21:20
sridhar_ramdoes it return concrete VIM specific identifiers that the caller can send to another component21:20
sridhar_ram?21:20
trozetsridhar_ram: no21:21
s3wongsripriya: so that question encompasses just VNFFG --- if the VNFM also has 'port' abstraction, then it is safe for VNFFG to assume one or more 'port's from a VNF21:21
sridhar_rams3wong: AWS does have a concept of network ports21:21
s3wongsridhar_ram: OK --- as does libnetwork for Docker :-)21:22
s3wongsridhar_ram: vNIC in vSphere has an UUID too, I suppose?21:22
trozetsridhar_ram: i think this is just semantics - to me interface/port are the same thing21:22
sripriyas3wong: sridhar_ram: ack21:22
trozetsridhar_ram: in the ETSI spec, connection point is the definition we can agree on :)21:23
trozetso i need the "connection point instance ID"21:23
trozethehe21:23
s3wongtrozet: of course this is a matter of abstraction --- during my GBP days, there is no 'port', just 'endpoint' :-)  so it is hard to say :-)21:23
sridhar_ramtrozet: dumb question, as it stands.. who retrieves the neutron-port IDs ? i.e CP -> neutron-port id mapping ?21:23
trozetVNFM should do it21:23
s3wongtrozet: +121:24
trozethes the one correlating VNF to VNFD after all21:24
sridhar_ramtrozet: okay, that sounds correct21:24
sridhar_ramtrozet: i imaging some sort of get_vnf_details() api will be exposed by VNFM ?21:24
s3wongsridhar_ram: my discussion with trozet has more to do with who (VNFFG plugin or the actual driver) should make the VNFM call to retrieve that info21:24
sridhar_rams3wong: i've the same question and wondering which way you guys are leaning towards21:25
s3wongsridhar_ram: with sripriya chipping me --- it occurs to me that the info is encapsulated by VNFM plugin, and therefore needs to be VIM agnostic --- as such, I am perfectly fine with VNFFG plugin making that query to pass the resulting info to drivers21:26
s3wong* chipping in21:26
trozetsridhar_ram: VNFFG plugin asks VNFM for info about a VNF, info should include mapping of CP names to IDs, attributes like NSH aware, etc, VNFFG plugin then creates a data structure ordered list of the CP's and their attributes, and passes it to the driver to create_sfc21:26
sridhar_rams3wong: fair enough21:27
sridhar_ramtrozet: thanks, so the response dict will have IDs --> neutron IDs ?21:27
s3wongtrozet: so great, we have reached a consensus!!!21:27
sripriyasridhar_ram: whatever the infra driver will send back as IDs to the vnfm plugin21:28
s3wongsripriya: +121:28
sridhar_ramsripriya: ack.. make sense21:28
trozetsridhar_ram: CP: CP instance ID21:28
* trozet refrains from using port/interface/neutron ;)21:29
s3wongtrozet: :-)21:29
sripriya:-)21:29
sridhar_ramtrozet: I see... keep it abstract21:29
sridhar_ram*keeping21:29
s3wongtrozet, sripriya., sridhar_ram: Thanks! This discussion makes it easier for me to get things moving. Thanks!21:30
trozets3wong: yeah it does.   I will cc you on every patch I post so we stay in sync21:31
s3wongtrozet: Thanks!21:31
sridhar_ramthanks folks for putting up w/ me!21:31
sripriyas3wong: thanks for bringing up this discussion21:31
s3wong* group hug  :-)21:32
sridhar_ramLOL21:32
*** sripriya has quit IRC21:36
*** bobh has quit IRC22:08
sridhar_ramtrozet: s3wong: can you please join tomorrow's tacker weekly call to have a discussion on these layers please ? It will help rest of the Tacker team to understand the flow and provide inputs...22:15
sridhar_ramtrozet: s3wong: btw, i tried to capture the flow in this ascii diagram - http://paste.openstack.org/show/523666/22:15
*** uck has joined #tacker22:17
*** sripriya has joined #tacker22:22
*** uck has quit IRC22:23
*** uck has joined #tacker22:40
*** shaikapsar has joined #tacker22:42
s3wongsridhar_ram: sorry, was in a meeting23:04
sridhar_rams3wong: np23:04
s3wongsridhar_ram: sure. Will attend tomorrow (always planned to anyway :-)  ); the diagram captures our discussion above well23:05
sridhar_rams3wong: gr8, thanks!23:05
sripriyadkushwaha: ping23:20
*** sripriya has quit IRC23:25
*** uck has quit IRC23:30
*** haiwei has joined #tacker23:39
*** amotoki has joined #tacker23:41
*** amotoki has quit IRC23:45
*** sripriya has joined #tacker23:50
dkushwahasripriya, hi23:56
sripriyadkushwaha: hello, left a comment on the paramiko patch to drop the polling, kindly take a look at it and let me know for any concerns. we can try to merge soon.23:57
dkushwahasripriya, checking23:58
« Sunday, 2016-06-26 Index Tuesday, 2016-06-28 »

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