Wednesday, 2015-10-07

« Tuesday, 2015-10-06 Index Thursday, 2015-10-08 »
*** santoshk has quit IRC00:16
*** sridhar_ram has quit IRC00:25
*** lhcheng_ has quit IRC00:27
*** bobh has joined #tacker00:31
*** prashantD has joined #tacker00:52
bobhtbh:  I saw the exchange with sridhar_ram and I will update my patchset to use VNF00:55
tbhthanks bobh00:57
*** prashantD has quit IRC01:00
*** tbh has quit IRC01:25
*** tbh has joined #tacker01:26
*** tbh has quit IRC01:35
*** elo1 has quit IRC01:52
*** s3wong has quit IRC01:59
*** lhcheng has joined #tacker02:19
*** s3wong has joined #tacker02:40
*** s3wong has quit IRC02:43
*** bobh has quit IRC02:59
*** lhcheng has quit IRC04:09
*** tbh has joined #tacker04:11
*** tbh has quit IRC04:11
*** santoshkumark has joined #tacker04:27
*** lhcheng has joined #tacker04:28
*** elo has joined #tacker04:46
*** s3wong has joined #tacker05:29
*** s3wong has quit IRC05:36
*** tbh has joined #tacker06:36
*** santoshkumark has quit IRC06:38
*** tbh has quit IRC06:58
*** tbh has joined #tacker07:15
*** tbh has quit IRC07:31
*** lhcheng has quit IRC07:42
*** tbh has joined #tacker07:43
*** tbh has quit IRC08:07
*** tbh has joined #tacker08:11
*** mbound has joined #tacker08:18
*** tbh has quit IRC08:32
*** tbh has joined #tacker08:37
*** lhcheng has joined #tacker08:49
*** tbh has quit IRC08:50
*** tbh has joined #tacker08:55
*** tbh has quit IRC09:15
*** tbh has joined #tacker09:15
*** tbh has quit IRC09:34
*** tbh has joined #tacker09:39
*** lhcheng has quit IRC09:52
openstackgerritbharaththiruveedula proposed stackforge/tacker: Modify the datatype of 'value' column  https://review.openstack.org/23108809:58
*** tbh has quit IRC09:59
*** tbh has joined #tacker10:10
*** tbh has quit IRC10:35
*** tbh has joined #tacker10:52
*** tbh has quit IRC11:13
*** tbh has joined #tacker11:26
*** tbh has quit IRC11:31
*** bobh has joined #tacker11:41
*** bobh has quit IRC11:41
*** tbh has joined #tacker11:47
*** bobh has joined #tacker12:08
*** bobh has quit IRC12:10
*** tbh has quit IRC12:39
*** bobh has joined #tacker13:14
*** tbh has joined #tacker13:44
*** tbh_ has joined #tacker13:49
*** tbh has quit IRC13:53
*** trozet has joined #tacker13:53
*** sridhar_ram has joined #tacker14:03
*** bobh_ has joined #tacker14:42
*** bobh has quit IRC14:46
*** bobh_ has quit IRC14:56
*** sridhar_ram has quit IRC14:59
*** tbh_ has quit IRC15:07
*** tbh has joined #tacker15:25
*** tbh has quit IRC15:25
*** tbh has joined #tacker15:25
*** sridhar_ram has joined #tacker15:35
sridhar_ramtbh: ping15:49
*** bobh has joined #tacker15:51
*** bobh_ has joined #tacker15:52
*** bobh has quit IRC15:55
*** sridhar_ram1 has joined #tacker16:03
*** sridhar_ram has quit IRC16:04
*** prashantD has joined #tacker16:05
*** bobh has joined #tacker16:10
*** bobh_ has quit IRC16:13
*** sridhar_ram1 has quit IRC16:14
*** sridhar_ram has joined #tacker16:14
*** bobh has quit IRC16:15
*** bobh has joined #tacker16:22
*** tbh has quit IRC16:23
*** tbh has joined #tacker16:25
tbhsridhar_ram: Hi16:25
*** mbound has quit IRC16:26
*** bobh has quit IRC16:27
sridhar_ramtbh: I'm wondering if we should go w/ sa.String(65535) instead of sa.Text() for the vnf template size16:34
tbhsridhar_ram: okay, but is there any specific reason with string approach16:35
tbhsridhar_ram: because even text max size is 6553516:35
tbhsridhar_ram: it wont allow more than that16:35
sridhar_ramtbh: ah, I didn't knew Text had a maximum..16:36
sridhar_ramtbh: .. I guess we are good.16:36
trozetsridhar_ram: ping?16:36
sridhar_ramtrozet: hi there16:36
trozetsridhar_ram: hi16:37
sridhar_ramtrozet: what's up ?16:37
trozetsridhar_ram: I am about to push the 2nd revision of spec, but had a question about Karthik's comment per classifier matching16:37
tbhI tried with large size file, it is unable to store16:37
tbhstring is also fine for me16:37
trozetsridhar_ram: he mentions we should validate the classifier match criteria with a structure of supported matching tuples16:38
trozetsridhar_ram: is it enough to mention in the spec that we will support and validate the tuples defined by the inet types in https://tools.ietf.org/html/rfc6021. ?16:38
trozetsridhar_ram: or do I need to actually show a table in the spec of supported match criteria16:39
sridhar_ramtbh: if Text has the same max .. I'd suggest we go w/ sa.String(65535) as it makes things explicit16:39
* sridhar_ram looking up rfc602116:39
tbhsridhar_ram: yeah it has same max16:39
tbhwe will go with string then16:40
sridhar_ramtbh: sounds good16:40
sridhar_ramtrozet: let get quickly lookup Karthik's comment16:40
trozetsridhar_ram: np its on line 17216:41
*** zeih has joined #tacker16:41
sridhar_ramtrozet: I'm leaning to towards showing the supported match criteria...16:44
trozetsridhar_ram: ok I will list it out explicitly in the spec16:45
*** lhcheng has joined #tacker16:45
trozetsridhar_ram: let me talk to the ODL team and find out from them exactly what they can support16:45
sridhar_ramtrozet: sounds good...16:45
*** lhcheng has quit IRC16:45
sridhar_ramtrozet: another q...if you few mins..16:46
*** lhcheng has joined #tacker16:46
trozetsridhar_ram: yeah  :) finally a day thats not totally busy16:46
sridhar_ramtrozet: woot ! .. mtgs get cancelled ... stars lines up .. I know how it feels16:47
trozet:)16:47
sridhar_ramtrozet: a bit of noob questions on NSH based SFC .. better to get this out first ;-)16:47
trozetsridhar_ram: sure its all relatively new stuff so fire away16:48
sridhar_ramAre we assuming the name vNIC (neutron-port) will be used for both traffic going in  (from previous vnf in the chain) and coming out (going to the next VNF in the chain)16:48
sridhar_ramfor e.g. a FW VNF would have a two vNICs .. in and out16:49
trozetsridhar_ram: I think that is a correct assumption, if we wanted to support multiple interfaces to a VNF there would have to be changes to ODL SFC16:49
*** bobh has joined #tacker16:50
sridhar_ramI see..16:50
sridhar_ramso we can't support a vFW where traffic goes in using on vNIC and comes out on another ?16:51
*** bobh_ has joined #tacker16:51
*** bobh has quit IRC16:52
trozetsridhar_ram: I dont think so, let me double check16:52
*** tbh has quit IRC16:53
sridhar_ramI guess.. I'm keeping non-NSH VNFs in mind here and how it can be chained..16:53
sridhar_ramwith NSH capable VNFs perhaps one vNIC per SFC enabled VNF is sufficient..  the nsh tag and the direction of the packet would be sufficient for OVS to honor the chain16:55
trozetsridhar_ram: looking at the SFC stuff i dont think you can specify multiple ports with ingress/egress16:57
trozetsridhar_ram: non NSH aware VNFs use an NSH proxy16:57
sridhar_ramODL supports NSH proxy ?16:57
trozetsridhar_ram: I think so16:57
sridhar_ramtrozet: thanks, will poke a bit more on nsh-proxy16:58
sridhar_ramtrozet: enjoy rest of your relatively free day!16:59
trozetsridhar_ram: sure.  thanks.  Look for an update on the spec review later today17:00
sridhar_ramtrozet: will do17:00
*** bobh_ has quit IRC17:01
*** santoshkumark has joined #tacker17:04
*** zeih has quit IRC17:06
*** s3wong has joined #tacker17:13
*** tbh has joined #tacker17:15
*** bobh has joined #tacker17:15
openstackgerritbharaththiruveedula proposed stackforge/tacker: Modify the datatype of 'value' column  https://review.openstack.org/23108817:20
openstackgerritvishwanath jayaraman proposed stackforge/tacker: Fixes vnf create failure even if all parameters are supplied  https://review.openstack.org/23016917:33
openstackgerritvishwanath jayaraman proposed stackforge/tacker: Fixes vnf create failure even if all parameters are supplied  https://review.openstack.org/23016917:38
*** vishwanathj has joined #tacker17:43
*** tbh has quit IRC17:47
santoshkumarkbobh: regarding the comment in bug 1503480 does the testcase sound reasonable..??17:47
openstackbug 1503480 in tacker "Deletion of vnf having issues when doing in between Active-->Dead State" [Undecided,New] https://launchpad.net/bugs/150348017:47
bobhsantoshkumark: I agree that it should not get stuck in PENDING_DELETE but I think the test case raises another issue, which is that we assume the VM is "ACTIVE" when the heat stack is complete, but that is really not a valid assumption17:49
bobhsantoshkumark: technically the VNF should not go "ACTIVE" until monitoring has succeeded at least once, IMHO17:49
bobhsantoshkumark: that implies a "startup" check that validates the application has started successfully (i.e. application is listening on the port(s) it should be listening on)17:50
bobhsantoshkumark: maybe we need PENDING_CREATE -> CREATED (when Heat is done) -> ACTIVE (when monitoring succeeds the first time)17:53
bobhsantoshkumark: but that implies that monitoring is required, which it isn't at the moment, but maybe it should be?17:54
santoshkumarkbobh: comment from sridhar, can you please check bug comments17:54
* bobh checking....17:54
* sridhar_ram walking back to here, catching up...17:55
bobhsantoshkumark: sridhar_ram - monitoring will start as soon as the heat stack goes to COMPLETED, and assuming we don't catch the small interval before the interface goes down, ping will fail and will we respawn17:56
bobhover and over and over again....17:57
sridhar_rambobh: ping doesn't fail immediately.. it waits for upto 5 ping failures before we mark DEAD ?17:57
bobhI can see where we don't want to infinitely respawn, but we also need a leaky bucket so that if we have a limit of "5" respawns and a VNF is up for a month, we don't stop respawning because it hit the arbitrary limit we set17:58
bobhping sends "count" pings (default 5) and if all of them fail (I think) it will respawn immediately17:58
bobhsridhar_ram: not sure what happens if some fail and some succeed - need to look at that case17:58
bobhsridhar_ram: we don't store state for the mon drivers at the moment - they get one chance to report up or down17:59
bobhsantoshkumark: sridhar_ram I like the idea of introducing a delay before the ifdown so that monitoring has the chance to succeed at least once18:00
sridhar_rambobh: for santoshkumark I'd definitely guide him to write a func test that is in-line with mainstream usage and not focus on corner cases18:01
sridhar_ramat least initial testcases...18:01
bobhsridhar_ram: agree18:02
santoshkumarkbobh, sridhar_ram : sure, sleep time should be consistent and should not run into corner cases...let me know how much is reasonable18:02
bobhsridhar_ram: we probably need an option for restart_limit and restart_limit_reset_time to cover some of these issues18:03
santoshkumark'how much time', i mean18:03
sridhar_rambobh: I still remember we had ping report "Unreachable" few times before marking the vdu dead..18:03
bobhsridhar_ram: I'll look at the existing code and see if I missed something18:03
sridhar_ramsantoshkumark: as mentioned it shd be T > boot_wait + some buffer to get ping flowing nicely18:04
bobhsridhar_ram: we don't want the driver to delay too long, and we can't (at the moment) save state, so not sure how we would track across multiple intervals18:04
sridhar_rambobh: ah.. true, that would be bad, given the current state18:04
bobhsantoshkumark: can also specify monitoring_delay in the new implementation and set your delay based on that18:04
santoshkumarkbobh:sure..18:05
sridhar_rambobh: btw, we need to think a bit more on our state transitions..18:06
sridhar_ramhad a discussion recently in the context of mgmt-driver ...18:06
sridhar_ramimagine something like this (thinking out aloud here)...18:06
sridhar_ramPENDING_CREATE --> CONFIGURING (if mgmt-driver is in play) --> ACTIVE --> DEAD (mon-driver is not happy) --> ACTIVE...18:08
*** tbh has joined #tacker18:08
sridhar_ramthere is also more intermediate err states like CONFIGURING_FAILED18:09
sridhar_ramsome of us where wondering if we were trying to overload this one status attr too much .. instead break into two..18:09
bobhsridhar_ram: That looks good - I might add CREATED (Heat stack is done) and if monitoring is being done ACTIVE would be achieved after the monitor has returned successfully once18:09
sridhar_rambobh: that's a good thought.. how about if a VNF doesn't have a mon-driver ?18:11
bobhsridhar_ram: I think it would go from CREATED/CONFIGURING to ACTIVE in that case18:12
sridhar_ramthis state machine needs a diagram :)18:12
bobhdon't they all?18:12
sridhar_ramtrue .. trivials ones we can get by w/ text art18:13
sridhar_ramIn fact we should revisit DEAD into different thing sub-states like HEALING (respawn in progress)18:14
sridhar_ramNova has two attrs .. Status and Task .. the latter points to things like "Spawning "18:15
bobhHeat has "stack status" and "stack_status_reason" - sometimes it's useless information but on failures it's usually critical information18:17
*** prashantD has quit IRC18:18
sridhar_ramHeads up Tackers - tbh's db change fix going to land soon, get ready to run ...18:20
sridhar_ram' tacker-db-manage --config-file /etc/tacker/tacker.conf upgrade head' if you rebase your existing tree to latest master18:21
sridhar_ramFYI , I just documented the current VNF state machine here ... https://docs.google.com/presentation/d/1oDrME3wG1bOfSzrjvXea_KGTzysBJkdQTng74xrun4w/edit?usp=sharing18:39
sridhar_ramdoes it look correct to you ?18:40
openstackgerritMerged stackforge/tacker: Fixes vnf create failure even if all parameters are supplied  https://review.openstack.org/23016918:45
sridhar_ramtbh: looks dsvm-functional gate failed .. http://logs.openstack.org/88/231088/7/check/gate-tacker-dsvm-functional/c283ce9/logs/devstacklog.txt.gz18:47
sridhar_ramtbh: it is reporting "(pymysql.err.InternalError) (1074, u"Column length too big for column 'value' (max = 21845); use BLOB or TEXT instead")18:47
sridhar_ramtbh: looks we need to head back to use TEXT ? :(18:48
* sridhar_ram feels wasted everyones time by rat holing on the column type .. :(18:49
tbhsridhar_ram: actually I don't have setup now18:50
tbhI will check max length of sttring18:50
sridhar_ramtbh: thanks18:52
sridhar_ramtbh: I read mysql internally switch many things to Text given VARCHAR is originally restricted to 256. For eg VARCHAR(500) is internally converted to Text with max=50018:53
sridhar_ramanyway, I'm okay to go back to Text column type18:54
tbhsridhar_ram: I just tried it, it would have been better to say varchar(500) itself18:55
tbhokay I will update the patch18:55
sridhar_ramtbh: what are you going to change it to ?18:55
bobhsridhar_ram: there is a PENDING_UPDATE state that seems to be used in some scenarios though I'm not sure if they are valid or not18:55
tbhsridhar_ram: to text18:56
sridhar_ramtbh: sounds good18:56
sridhar_rambobh: ah.. that is probably from vnf-update cmd18:57
tbhsridhar_ram: so better I will pass sa.TEXT(65535) to be more explicit19:03
tbh?19:03
sridhar_ramtbh: that works19:03
bobhtbh: If that works it's probably a good solution19:03
bobhtbh: we can always increase it later if needed19:03
sridhar_rambobh: added PENDING_UPDATE state .. which comes into play during configuration19:04
sridhar_rambobh: now imagine introducing CONFIGURING, HEALING, etc along with their failure states...!19:05
bobhsridhar_ram: I still have nightmares from the trouble-ticket-resolution state  machine I had to design about 20 years ago....19:06
sridhar_ramthat's why I'm thinking we shd have two "states" ... one that corresponds to VM runtime and another for the stuff the goes inside the VNF (configuration, service health, etc) .. make it two dimensional19:07
bobhsridhar_ram: we spent weeks/months....19:07
bobhalso have to handle multi-vms - so VNF vs VDU19:08
sridhar_rambobh: I see .. I've done my share of voice call-control state machine speghatti sauce as well19:08
sridhar_rambobh: yep... multi-VDU VNF has some loose ends!19:08
bobhme too!  SDL diagrams with message flows - the good old days19:09
sridhar_rambobh: yeah, VoIP used to advanced technology ... high up the R&D stack19:09
sridhar_ramall that quickly turned into nightmare when we wanted to add more smarts ... the old ITU call-flows just faltered..19:10
sridhar_ramthat's when we switch to newer SIP..19:10
sridhar_ram.. good ol' days :)19:11
tbhsridhar_ram: bobh what is the simplest use case we can explain for NFV19:14
bobhtbh: DNS is usually the one we start with19:15
bobhtbh: depends a bit on context - what the NFV discussion is related to19:15
tbhtrying to explain the purpose of NFV  and terms involved in it19:16
tbhwith some example19:16
tbhI thought of explaining with IMS19:17
tbhbobh: but that adds more jargons19:17
bobhtbh: IMS works if the audience is already familiar with it, but otherwise yes, lots of new acronyms19:17
tbhbobh: yeah19:18
bobhtbh: We usually talk about how existing PNFs need specialized hardware and with NFV that goes away and is replaced by common HW that can be shared19:18
bobhtbh: it helps if the audience has experience with an existing application that can be virtualized19:19
tbhbobh: I thought of explaining the router and many switches in an organization19:19
bobhtbh: Maybe vCPE is a good example - replacing your cable TV box with one that is in the cloud19:20
bobhtbh: or a vPBX - anything that you can spin up "on demand" like Parental Controls, etc19:21
tbhbobh: I am not aware of vPBX, I will check with that19:23
*** vishwana_ has joined #tacker19:25
*** vishwanathj has quit IRC19:27
openstackgerritbharaththiruveedula proposed stackforge/tacker: Modify the datatype of 'value' column  https://review.openstack.org/23108819:33
tbhbobh: DNS sounds interesting, is there any link regarding this to share?19:34
bobh#link http://innovarista.org/2014/08/11/nfv-business-case-dns-study/19:35
tbhbobh: I am just reading that :) thanks19:36
tbhneed one more review for the patch again bobh sridhar_ram19:36
* bobh checking..19:36
*** sridhar_ram has quit IRC19:53
*** tbh has quit IRC19:56
*** sridhar_ram has joined #tacker20:02
*** sridhar_ram has quit IRC20:05
*** zeih has joined #tacker20:07
*** zeih has quit IRC20:11
*** bobh has quit IRC20:12
*** sridhar_ram has joined #tacker20:29
openstackgerritSantosh Kodicherla proposed stackforge/tacker: Add tacker functional tests  https://review.openstack.org/23219920:40
openstackgerritSantosh Kodicherla proposed stackforge/tacker: Add tacker functional tests  https://review.openstack.org/23219920:49
openstackgerritSantosh Kodicherla proposed stackforge/tacker: Add tacker functional tests  https://review.openstack.org/23222321:16
openstackgerritSantosh Kodicherla proposed stackforge/tacker: Add tacker functional tests  https://review.openstack.org/23222321:20
openstackgerritTim Rozet proposed stackforge/tacker-specs: Adds Tacker SFC spec  https://review.openstack.org/22800721:26
*** lhcheng has quit IRC21:28
*** lhcheng has joined #tacker21:33
openstackgerritMerged stackforge/tacker: Modify the datatype of 'value' column  https://review.openstack.org/23108821:43
*** trozet has quit IRC22:10
*** sridhar_ram has quit IRC23:21
*** lhcheng has quit IRC23:51
« Tuesday, 2015-10-06 Index Thursday, 2015-10-08 »

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