| sridhar_ram | gongysh__: your point is valid... I've been thinking about how to incorporate OpenWRT bit more in Tacker installations ... | 00:00 |
|---|---|---|
| gongysh__ | sridhar_ram, I was there that time, impressive | 00:00 |
| s3wong | sridhar_ram: yep, I saw that as well | 00:00 |
| sridhar_ram | gongysh__: it hurts when people see Tacker only with cirros ! | 00:00 |
| gongysh__ | sridhar_ram, Yes, it has hurt me. | 00:01 |
| sridhar_ram | gongysh__: I wish we can make it easy for folks to try OpenWRT as the basic, minimal thing to try.. | 00:01 |
| s3wong | sridhar_ram: yeah, if we can mix in some other OSS network services, that would be really cool... but I guess that would be something on the roadmap... | 00:01 |
| gongysh__ | but I thought, ha, tacker is so simple, can do work with cirros. but that is not true at all. | 00:01 |
| sridhar_ram | gongysh__: one technical challenge is where to host the qcow2 image of OpenWRT.. we can make people to try that when they test tacker | 00:02 |
| sridhar_ram | gongysh__: any ideas ? | 00:02 |
| gongysh__ | of course, just like cirros, put it into glance. Am I thinking too simple? | 00:03 |
| sridhar_ram | gongysh__: I meant, to host qcow2 in some public place to download | 00:04 |
| sridhar_ram | gongysh__: perhaps we can check w/ the openstack-infra team | 00:05 |
| s3wong | sridhar_ram: back in LBaaSv1 days, the installation menu assume you are running on ubuntu, and simply say 'sudo apt-get install ha-proxy' as step one :-) | 00:06 |
| gongysh__ | yes, if not, we can learn from cirros. | 00:06 |
| s3wong | sridhar_ram: of course that is making something work, not having an OpenStack project deploying service, so very different | 00:07 |
| gongysh__ | sridhar_ram, we can just put it in a github repo. | 00:07 |
| gongysh__ | sridhar_ram, you know any one can open up github repo. | 00:08 |
| gongysh__ | s3wong, LbaaSv1? why still with V1, not V2? | 00:08 |
| gongysh__ | s3wong, sridhar_ram I am also thinking about how to use neutron LbaaS and Fwaas? | 00:10 |
| sridhar_ram | gongysh__: just asked the question to infra guys. github repo might just work! | 00:10 |
| gongysh__ | github repo is the quickest way. :) | 00:11 |
| * gongysh__ away | 00:12 | |
| *** gongysh__ has quit IRC | 00:16 | |
| *** gongysh__ has joined #tacker | 00:18 | |
| * gongysh__ back | 00:19 | |
| s3wong | gongysh__: sorry, out of desk for a moment | 00:19 |
| s3wong | gongysh__: I only knew about LBaaS v1, I haven't been following LBaaS v2 too much, especially now that Octavia is the default | 00:20 |
| sridhar_ram | gongysh__: infra folks are suggesting not to put in github | 00:20 |
| *** lhcheng has quit IRC | 00:20 | |
| *** lhcheng has joined #tacker | 00:21 | |
| gongysh__ | Octavia is VM service way to deal with lbaas. I have not dived in depth there. | 00:21 |
| gongysh__ | s3wong, serviceVM way. | 00:21 |
| s3wong | gongysh__: if so, they would need to have the image stored somewhere... which is our current problem :-) | 00:22 |
| gongysh__ | I am thinking about they should use our API to boot lbaas VNF. | 00:23 |
| s3wong | gongysh__: that was the original intent when we started Tacker... as a common infra for serviceVM | 00:24 |
| s3wong | gongysh__: in fact, dougwig used to follow our channel and progress... but given that after driver decomposition, vendors that require serviceVM management had gone their own way to manage their own serviceVM, that need is no longer strong enough to sustain the project | 00:25 |
| sridhar_ram | quick note, infra guys have a solution for openwrt.. | 00:29 |
| gongysh__ | sridhar_ram, https://github.com/openstack/octavia/blob/master/devstack/settings | 00:29 |
| * s3wong eagerly awaits for infra suggested solution | 00:29 | |
| gongysh__ | octavia is creating the image on-demand with devstack plugin | 00:30 |
| gongysh__ | OCTAVIA_AMP_FLAVOR_ID=${OCTAVIA_AMP_FLAVOR_ID:-"10"} | 00:30 |
| gongysh__ | OCTAVIA_AMP_IMAGE_NAME=${OCTAVIA_AMP_IMAGE_NAME:-"amphora-x64-haproxy"} | 00:30 |
| gongysh__ | OCTAVIA_AMP_IMAGE_FILE=${OCTAVIA_AMP_IMAGE_FILE:-${OCTAVIA_DIR}/diskimage-create/${OCTAVIA_AMP_IMAGE_NAME}.qcow2} | 00:30 |
| sridhar_ram | gongysh__: yes, the solution is close to that.. AFAIK diskimage-builder is typically used to push things to tarballs.openstack.org | 00:32 |
| sridhar_ram | infra guys are suggesting to use the same tool to pull openwrt .. | 00:32 |
| sridhar_ram | but our openwrt had been "touched up" to properly work with openstack.. | 00:33 |
| sridhar_ram | we are using openwrt 12.09 image.. may be the newer openwrt 15.x is bit more openstack friendly | 00:33 |
| sridhar_ram | I'll add an RFE bug to track it so that we don't lose it .. | 00:34 |
| sridhar_ram | gongysh__: thanks for the octavia tip.. | 00:38 |
| gongysh__ | sridhar_ram, my pleasure. | 00:41 |
| sridhar_ram | fyi, created this https://bugs.launchpad.net/tacker/+bug/1517672 | 00:45 |
| openstack | Launchpad bug 1517672 in tacker "Preinstall openwrt images in tacker devstack installation" [Undecided,New] | 00:45 |
| gongysh__ | sridhar_ram, when is the team meeting? | 00:48 |
| gongysh__ | I thought it is one AM in beijing time | 00:48 |
| s3wong | gongysh__: 1700 UTC on Tuesdays | 00:51 |
| gongysh__ | yes, it is 1:00 oclock in the very morning beijing time. | 00:52 |
| gongysh__ | It seems I can only read the meeting log. | 00:53 |
| s3wong | gongysh__: yes, sorry about that... | 00:53 |
| s3wong | you can always ping us on channels (during more "normal" hours) | 00:53 |
| gongysh__ | sure | 00:54 |
| *** gongysh__ has quit IRC | 01:24 | |
| bobh | sridhar_ram: pong | 01:47 |
| *** joonmyung has quit IRC | 01:55 | |
| *** tbh has joined #tacker | 02:11 | |
| *** bobh has quit IRC | 02:15 | |
| *** openstack has joined #tacker | 02:25 | |
| *** lhcheng has joined #tacker | 02:25 | |
| openstackgerrit | Santosh Kodicherla proposed openstack/tacker: Tacker test for multi vdu with monitoring enabled https://review.openstack.org/246738 | 02:27 |
| sridhar_ram | gongysh_: that's an ouch on the mtg time :( | 02:51 |
| sridhar_ram | gongysh_: as we get more folks from APAC region we could consider alternate mtg slots | 02:52 |
| sridhar_ram | tbh: ping | 03:04 |
| tbh | sridhar_ram, Hi | 03:04 |
| sridhar_ram | tbh: is there anything pending for this bug id ? https://bugs.launchpad.net/tacker/+bug/1501079 | 03:04 |
| openstack | Launchpad bug 1501079 in tacker "tacker mgmt-driver support in vnf-create flow" [Medium,In progress] - Assigned to bharaththiruveedula (bharath-ves) | 03:04 |
| sridhar_ram | tbh: can this be closed ? | 03:04 |
| *** s3wong has quit IRC | 03:05 | |
| tbh | sridhar_ram, yup, we can close that | 03:05 |
| sridhar_ram | tbh: that's what I thought ... thanks! | 03:07 |
| *** trozet has quit IRC | 03:07 | |
| tbh | sridhar_ram, I stored openWRT in drive, and using devstack script, I will update to glance. | 03:09 |
| tbh | sridhar_ram, this is the general way I setup with dev env | 03:10 |
| tbh | sridhar_ram, and recently tried openWRT with docker image and configured using tacker | 03:11 |
| *** bobh has joined #tacker | 03:15 | |
| *** bobh has quit IRC | 03:21 | |
| *** prashantD has quit IRC | 03:23 | |
| *** tbh has quit IRC | 03:55 | |
| *** lhcheng has quit IRC | 04:03 | |
| *** prashantD has joined #tacker | 04:25 | |
| *** prashantD has quit IRC | 04:31 | |
| *** prashantD has joined #tacker | 04:33 | |
| *** sridhar_ram has quit IRC | 04:35 | |
| *** lhcheng has joined #tacker | 04:53 | |
| *** gongysh__ has joined #tacker | 05:02 | |
| *** tbh has joined #tacker | 05:24 | |
| *** prashantD has quit IRC | 05:54 | |
| *** lhcheng has quit IRC | 06:35 | |
| *** bobh has joined #tacker | 07:18 | |
| *** bobh has quit IRC | 07:23 | |
| *** amotoki has joined #tacker | 07:56 | |
| *** gongysh__ has quit IRC | 07:57 | |
| *** zeih has joined #tacker | 08:13 | |
| *** santoshk has quit IRC | 08:20 | |
| *** karimb has joined #tacker | 08:23 | |
| *** egonzalez has joined #tacker | 08:26 | |
| *** gperal has joined #tacker | 08:46 | |
| *** mbound has joined #tacker | 08:55 | |
| *** mbound has quit IRC | 08:57 | |
| *** egonzalez has quit IRC | 09:09 | |
| *** karimb has quit IRC | 09:33 | |
| *** karimb has joined #tacker | 09:35 | |
| *** egonzalez has joined #tacker | 09:36 | |
| *** mbound has joined #tacker | 09:40 | |
| *** mbound has quit IRC | 09:49 | |
| *** mbound has joined #tacker | 09:50 | |
| *** amotoki has quit IRC | 09:53 | |
| *** amotoki has joined #tacker | 09:53 | |
| *** mbound has quit IRC | 09:54 | |
| *** amotoki has quit IRC | 09:54 | |
| *** openstackgerrit has quit IRC | 10:01 | |
| *** openstackgerrit has joined #tacker | 10:02 | |
| *** mbound has joined #tacker | 10:18 | |
| *** openstack has joined #tacker | 10:18 | |
| *** masterbound has joined #tacker | 10:18 | |
| *** mbound has quit IRC | 10:22 | |
| *** bobh has joined #tacker | 11:20 | |
| *** bobh has quit IRC | 11:24 | |
| *** egonzalez has quit IRC | 11:27 | |
| *** gperal has quit IRC | 12:47 | |
| *** rickyhai11_ has joined #tacker | 12:48 | |
| rickyhai11_ | Good morning Trozet | 12:48 |
| rickyhai11_ | if you have a chance, please help to look at the issue we discused before | 12:49 |
| rickyhai11_ | thanks you so much and wish you have a great day | 12:49 |
| rickyhai11_ | would be great if you could leave message at here or in github comment | 12:50 |
| *** egonzalez has joined #tacker | 12:56 | |
| *** gperal has joined #tacker | 13:25 | |
| *** gongysh__ has joined #tacker | 14:02 | |
| *** tbh has quit IRC | 14:14 | |
| *** gongysh__ has quit IRC | 14:18 | |
| radez | rickyhai11_: ping, I'm not sure trozet got your message, he should join in the next halfhour or so | 14:30 |
| *** bobh has joined #tacker | 14:33 | |
| *** gongysh__ has joined #tacker | 14:36 | |
| *** trozet has joined #tacker | 14:43 | |
| radez | trozet: rickyhai11_ pinged you earler to ask you to have a look at the issue you discussed | 14:57 |
| trozet | radez: thanks, hi rickyhai11_ | 14:58 |
| *** trozet has quit IRC | 15:17 | |
| *** rickyhai11_ has quit IRC | 15:21 | |
| *** trozet has joined #tacker | 15:29 | |
| *** zeih has quit IRC | 15:49 | |
| *** gperal has quit IRC | 15:50 | |
| *** gongysh__ has quit IRC | 16:23 | |
| *** prashantD has joined #tacker | 16:32 | |
| *** tbh has joined #tacker | 16:40 | |
| egonzalez | Hi, has anyone suffer this issue while creating vnf? | 16:50 |
| egonzalez | raise TypeError("%s can't be decoded" % type(text)) | 16:50 |
| egonzalez | I'm doing manual installation on CentOS with RDO | 16:50 |
| *** sridhar_ram has joined #tacker | 16:53 | |
| sridhar_ram | trozet: ping | 16:57 |
| *** igordcard has joined #tacker | 17:00 | |
| *** s3wong has joined #tacker | 17:03 | |
| s3wong | sridhar_ram: ping? | 17:07 |
| s3wong | sridhar_ram: we are now talking about Tacker on networking-sfc on #openstack-meeting-4 | 17:07 |
| *** masterbound is now known as mbound | 17:08 | |
| *** karimb has quit IRC | 17:16 | |
| *** dandruta has joined #tacker | 17:23 | |
| *** joonmyung has joined #tacker | 17:42 | |
| *** egonzalez has quit IRC | 17:44 | |
| *** s3wong has quit IRC | 17:47 | |
| *** gongysh has quit IRC | 17:56 | |
| *** gongysh has joined #tacker | 17:57 | |
| *** joonmyung has quit IRC | 17:59 | |
| *** mbound has quit IRC | 18:03 | |
| *** lhcheng has joined #tacker | 18:06 | |
| *** lhcheng_ has joined #tacker | 18:08 | |
| *** s3wong has joined #tacker | 18:10 | |
| *** lhcheng has quit IRC | 18:11 | |
| *** santoshkumark has joined #tacker | 18:27 | |
| *** lhcheng_ has quit IRC | 18:41 | |
| *** sripriya has joined #tacker | 18:43 | |
| *** tbh has quit IRC | 18:46 | |
| trozet | hi sridhar_ram | 18:57 |
| *** lhcheng has joined #tacker | 19:22 | |
| sridhar_ram | trozet: hi, I'm back .. | 19:27 |
| sridhar_ram | trozet: we briefly discussed tacker-sfc APIs in today's neutron-sfc meeting .. i thought will quickly run by you some of the discussion points | 19:28 |
| sridhar_ram | bobh: if you've few mins can you look at https://review.openstack.org/#/c/242248/ | 19:28 |
| sridhar_ram | bobh: it looks clean from my side | 19:29 |
| *** dandruta has quit IRC | 19:36 | |
| *** openstackgerrit has quit IRC | 19:46 | |
| *** openstackgerrit has joined #tacker | 19:47 | |
| bobh | sridhar_ram: I just finished up looking at it. My only concern was the extent of the changes that were not documented in the commit message, but it's not worth another patchset | 19:47 |
| sripriya | trozet: ping | 19:58 |
| trozet | hi sripriya | 19:58 |
| sripriya | trozet: i understand you were facing some errors with vnf creation because of the system constraint for the vnf instance flavors | 19:59 |
| trozet | sripriya: yeah it was bc I was out of RAM on my compute host | 19:59 |
| sripriya | trozet: i'm tracking all of the errors related to port: still in use error for vnf creation error | 20:00 |
| sripriya | trozet: was it the same error: port: vdu1 still in use? | 20:00 |
| sridhar_ram | bobh: fair enough.. agree, we need to start nudging patchsets to have proper commit description | 20:00 |
| trozet | sripriya: yeah it complained the port was in use, but if you scrolled up earlier in the log it showed nova scheduler is the one that actually complained first | 20:00 |
| trozet | sridhar_ram: yeah what was the gist of it? did you see my email today? | 20:01 |
| sripriya | trozet: and what was the error from nova scheduler? | 20:01 |
| sripriya | trozet: by any chance do you have the n-cpu logs for the same? | 20:02 |
| trozet | sripriya: I don't have a copy of hte error message, but it was the generic out of resources one | 20:02 |
| sridhar_ram | trozet: I missed your email... just reading it now | 20:02 |
| sripriya | trozet: i see, ok | 20:03 |
| trozet | sripriya: I might have the log | 20:03 |
| sripriya | trozet: thank you | 20:03 |
| sripriya | trozet: that would be great! | 20:03 |
| trozet | sripriya: give me a few min to boot he machine and see | 20:03 |
| sridhar_ram | trozet: the gist is neutron-sfc team wants us to primarily consume their api for sfc needs .. something like tacker-sfc --> n-sfc --> odl-sfc | 20:05 |
| sridhar_ram | trozet: I clarified that is what we have penciled in for a future phase when n-sfc bring in support for odl | 20:05 |
| sridhar_ram | trozet: meanwhile, near term, we will support tacker directly going to odl-sfc | 20:06 |
| sridhar_ram | trozet: the only due diligence we need to do, to save us trouble in the future, it do a bit forward thinking how neutron-sfc --> odl will look and make our existing tacker-sfc api accommodate that | 20:08 |
| sridhar_ram | trozet: we can continue this in the email thread ... | 20:08 |
| trozet | sridhar_ram: yeah ive heard that concern too, neutron guys dont like us bypassing them | 20:09 |
| trozet | sridhar_ram: that would take neutron, networking-odl, and netvirt ODL supporting that | 20:09 |
| santoshkumark | bobh, sridhar_ram apart from http monitor test, there are few other testcases which i renamed i can undo those and do them as part of another commit... | 20:10 |
| trozet | sridhar_ram: but those are just driver level changes, the API for SFC in tacker simply says, tell me which VNFs you want, and the order of the chain | 20:10 |
| sridhar_ram | trozet: yep, but if we do it modularly by using tacker-sfc-drivers .. one for odl-sfc and another for networking-sfc we can accommodate both .. but need a transition plan to cut over | 20:10 |
| trozet | sridhar_ram: sure, but if that is their concern, they should first implement the shim layer between them and ODL, then we make the change after | 20:11 |
| sridhar_ram | trozet: unfortunately all this will be cooking in parallel .. | 20:12 |
| sridhar_ram | trozet: .. that's okay imo | 20:12 |
| trozet | sridhar_ram: are you saying you want it listed in the spec that once neutron/networking-sfc integrates with ODL for SFC, we modify the driver to explicitly use neutron only? | 20:12 |
| sridhar_ram | trozet: .. these APIs will be mark'd experimental (backward compat not guanranteed) so that we are free to iterate / experiment a bit | 20:12 |
| trozet | sridhar_ram: i just want to make it clear that the API is not ODL specific at all, its just the driver | 20:13 |
| sridhar_ram | trozet: atleast we should mention that we consider that option and once neutron-sfc -->odl is available we will cut over to that.. | 20:14 |
| sridhar_ram | *considered | 20:14 |
| sridhar_ram | trozet: understood | 20:14 |
| sridhar_ram | trozet: btw, is the spec and the code in your github are in sync ? | 20:14 |
| trozet | sridhar_ram: so its fine with me if we transition to a neutron only driver that handles the interaction with ODL | 20:14 |
| sridhar_ram | trozet: cool, we are in the same page then | 20:15 |
| openstackgerrit | Merged openstack/tacker: Add tacker http monitor test https://review.openstack.org/242248 | 20:15 |
| trozet | sridhar_ram: no i need to update the spec, will do it either today or tmrw | 20:15 |
| *** igordcard has quit IRC | 20:15 | |
| sridhar_ram | trozet: sounds good... | 20:15 |
| trozet | sridhar_ram: but my point is that since its just the driver thats the cause of concern, all the other code can be pushed and reviewed | 20:15 |
| trozet | sridhar_ram: then we just mark the opendaylight driver as "experimental" | 20:15 |
| trozet | sridhar_ram: until the neutron functionality is there | 20:15 |
| sridhar_ram | trozet: but the concern I've is tacker-sfc API is now mirroring odl-driver sfc... | 20:16 |
| trozet | sridhar_ram: how is that the case? | 20:17 |
| trozet | sridhar_ram: sfc-create --name mychain --chain testVNF1,testVNF2 | 20:17 |
| trozet | sridhar_ram: that doesnt have anything to do with ODL | 20:17 |
| sridhar_ram | trozet: I'm going w/ that is in the spec .. https://review.openstack.org/#/c/228007/3/specs/liberty/tacker-sfc.rst | 20:19 |
| sridhar_ram | trozet: that's why I asked if your code and the spec are in sync | 20:19 |
| trozet | sridhar_ram: ah thats the source of confusion then | 20:20 |
| trozet | sridhar_ram: the code is not the same | 20:20 |
| sridhar_ram | trozet: don't you need to specific sfc_encap and transport_type | 20:20 |
| sridhar_ram | *specify | 20:20 |
| trozet | sridhar_ram: right now the driver assumes vxlan-gpe and encap is NSH | 20:20 |
| trozet | sridhar_ram: since ODL only supports those | 20:20 |
| sridhar_ram | btw, I really like the sfc-create API above (that Dan demo'd last week). That is the clear value of tacker | 20:21 |
| trozet | sridhar_ram: but those would be attributes in the REST call, however the chain is passed as its own attribute | 20:21 |
| trozet | sridhar_ram: let me get you what the rest call really looks like one sec | 20:22 |
| sridhar_ram | trozet: then, may I ask you to update the tacker-sfc spec on where things stand... | 20:22 |
| sridhar_ram | trozet: sure | 20:22 |
| sridhar_ram | trozet: I think we need to re-jig spec a bit .. script the top-half - the API portion and the bottom half - odl-driver portion so that it is clear | 20:23 |
| sridhar_ram | argh... s/script/split/ | 20:24 |
| trozet | sridhar_ram: http://pastebin.com/FqxMGwqR | 20:25 |
| * sridhar_ram looking | 20:25 | |
| sridhar_ram | trozet: looks amzingly simple! few quests.. | 20:27 |
| trozet | sridhar_ram: so i would think we pass specifics to implementation like NSH, or vxlan gpe as part of the attributes optional key/value pair. But the chain definition itself is just the ID of the VNFs in order | 20:27 |
| sridhar_ram | trozet: how do we accommodate VMs w/ different ingress and egress ports ? | 20:27 |
| trozet | sridhar_ram: so from that i would think networking-sfc driver would look up the VNFs, find the ingress egress ports, create port pairs, and define their port-chain | 20:27 |
| bobh | santoshkumark: no worries on this one, I know the history | 20:28 |
| trozet | sridhar_ram: yeah thats one concern I had, can you define the ingress, egress ports in the VNFD? | 20:28 |
| trozet | sridhar_ram: if so then SFC can just query the VNF db for the ports | 20:28 |
| sridhar_ram | trozet: yes, we are thinking to starting using the network interface tags "pkt_in" and "pkt_out" | 20:28 |
| trozet | sridhar_ram: yeah so as long its there, networking-sfc should be able to get that info | 20:29 |
| sridhar_ram | trozet: in fact it gets a bit elaborate .. for VNFs with multiple VDUs (VMs) | 20:29 |
| trozet | sridhar_ram: you mean for load balancing? multiple VMS of the same type? | 20:30 |
| sridhar_ram | trozet: here is an e.g. ... | 20:30 |
| sridhar_ram | trozet: assume a VNF with one control plane VM and multiple dataplane VM | 20:31 |
| sridhar_ram | trozet: all these VMs are "coded" as different VDUs in *one* VNF | 20:31 |
| sridhar_ram | the chain ingress might be in dataplane-VM1-pkt_in-vnic and .. | 20:32 |
| trozet | sridhar_ram: I see | 20:32 |
| sridhar_ram | .. egress might in dataplane-VM2-pkt_out-vnic | 20:32 |
| sridhar_ram | trozet: this is as postulated by ETSI MANO... | 20:32 |
| trozet | sridhar_ram: so then shouldnt that be up to VNFM to track the true ingress and egress? | 20:33 |
| sridhar_ram | yes.. | 20:33 |
| trozet | sridhar_ram: does SFC have to link the per VDU ports together as well? | 20:33 |
| sridhar_ram | it will make some "Connection Points" (ala vnics) as "external facing" to be chain with an SF before that and an SF after it | 20:34 |
| sridhar_ram | trozet: yes.. but I'm okay to keep some initial iteration simple | 20:35 |
| trozet | sridhar_ram: yeah I mean I'm sure there will be changes with load balancing, auto healing, etc | 20:36 |
| sridhar_ram | trozet: yeah.. we can scope it to some demo'able use case... | 20:36 |
| sridhar_ram | trozet: I want to do a 3 VNF chain.. NAT, FW, DPI ! | 20:37 |
| trozet | sridhar_ram: I'll fix the spec and send you an email when i push the patch, but as you saw from the rest, all the call gives really is the VNFs in order, and their symmetry | 20:37 |
| sridhar_ram | each VNF with two ports (in / out) | 20:37 |
| trozet | sridhar_ram: which should be all networking-sfc needs | 20:37 |
| sridhar_ram | trozet: sounds good.. will lookout for the spec.. | 20:38 |
| sridhar_ram | trozet: quick q, is the plan to allow tacker in opnfv-b as post-install still on ? | 20:38 |
| trozet | sridhar_ram: ok thanks, sorry about the confusion with the spec, just been focused so much on getting the demo to work | 20:38 |
| sridhar_ram | trozet: you still it off stable/liberty ? | 20:38 |
| trozet | sridhar_ram: yeah radez has written that puppet module to install tacker...actually brings up another topic hehe | 20:38 |
| trozet | sridhar_ram: yeah | 20:38 |
| trozet | sridhar_ram: so it looks in current neutron code, they dont register the tables on the process start | 20:39 |
| trozet | sridhar_ram: looks like they strictly rely on alembic migration | 20:39 |
| sridhar_ram | trozet: oh, yeah.. on that.. | 20:39 |
| trozet | sridhar_ram: migrations are missing (at least on my last pull on master) for some of the tables for tacker, can we get those updated? | 20:39 |
| sridhar_ram | trozet: I had a discussion w/ the original developer who did the db stuff for tacker | 20:40 |
| trozet | sridhar_ram: then I can create a migration for SFC and sfc classifier | 20:40 |
| sridhar_ram | trozet: we need to move those tables to alembic_migration script as well.. | 20:40 |
| sridhar_ram | trozet: but, it is surprizing why the initial start of tacker-server is not creating the tables for you guys | 20:41 |
| sridhar_ram | trozet: another developer tried tacker in non-devstack and he confirmed tacker-server correctly creating the missing tables | 20:41 |
| trozet | sridhar_ram: its because in our deployment the tacker user doesnt have permission to create the tables | 20:42 |
| sridhar_ram | trozet: ah, I see .. where do you control that ? just curious | 20:42 |
| trozet | sridhar_ram: i think radez can give him permissions as a work around | 20:42 |
| trozet | sridhar_ram: i think its part of the puppet module radez created, it assume it adds the tacker user and gives the regular permissions it woudl for other services | 20:43 |
| trozet | radez: can you comment if im incorrect? | 20:43 |
| * radez reads back | 20:43 | |
| radez | yea a mysql user doesn't have table create parms by default | 20:44 |
| radez | I'm just consumint the puppet code | 20:44 |
| radez | that all the other components use | 20:44 |
| radez | and they don't grant table create to their users | 20:44 |
| radez | so we would have to go out of our way to add table create to the user | 20:44 |
| sridhar_ram | radez: got it | 20:45 |
| radez | which I don't think it good practice in a prod env, but for testing/development screwing around should be a not so terriblely hard thing to do | 20:45 |
| sridhar_ram | trozet: radez: we are spoiled by devstack! | 20:45 |
| radez | so in general I would recommend removing this auto table stuff since noone or atlrease not many are doing it | 20:45 |
| sridhar_ram | I'll take this up on the tacker side to create migration scripts for these tables | 20:46 |
| radez | you've made me a happy man :) | 20:46 |
| radez | that's all I can ask | 20:46 |
| radez | that some migration scripts can exist! | 20:46 |
| sridhar_ram | radez: the feeling is mutual :) | 20:46 |
| radez | haha | 20:46 |
| radez | glad we can collaborate some | 20:46 |
| trozet | sridhar_ram: I think radez or someone mentioned to me yesterday a shirt that said "but it worked in devstack" on it | 20:47 |
| sridhar_ram | trozet: LOL!! | 20:47 |
| radez | haha, yea I think that was in the car someone said that | 20:47 |
| trozet | sridhar_ram: yeah if you get that migration, then I can make another migration for the SFC/sfc classifier tables | 20:47 |
| sridhar_ram | radez: I would've honked that car ;-) | 20:47 |
| radez | trozet: I'm looking forward to jamming tacker into apex as an experimental feature | 20:47 |
| trozet | sounds like we are all on the same page | 20:47 |
| radez | I've been reading about updating stacks and I think we can make tacker an update stack add on | 20:48 |
| sridhar_ram | trozet: agree | 20:48 |
| trozet | sripriya: I'm not seeing it in my logs | 20:50 |
| sripriya | trozet: no worries | 20:52 |
| trozet | sripriya: but what I saw was that port in use error, then when I looked at hte heat log, it showed a nova scheduler failure before that error saying not enough resources | 20:53 |
| sripriya | trozet: port vdu1 still in use is actually from heat that gets pushed to tacker, and we have seen this error from heat when nova compute complains device or resource busy | 20:54 |
| sripriya | trozet: so you say in your case, heat also threw not enough resources error? | 20:55 |
| trozet | sripriya: yes, but it threw that error first then the port in use after | 20:57 |
| trozet | sripriya: i think its because theya re 2 separate resources in heat | 20:57 |
| trozet | sripriya: one for hte nova instance, one for the neutron port | 20:57 |
| trozet | sripriya: the neutron port returns the last failure, so its the one that gets punted to tacker is what im guessing | 20:57 |
| sripriya | trozet: yes, probably as far as i can guess, that may be the reason | 21:02 |
| *** karimb has joined #tacker | 21:28 | |
| *** karimb has quit IRC | 21:28 | |
| *** karimb has joined #tacker | 21:29 | |
| *** karimb_ has joined #tacker | 21:32 | |
| *** karimb has quit IRC | 21:35 | |
| *** karimb_ has quit IRC | 21:40 | |
| openstackgerrit | Santosh Kodicherla proposed openstack/tacker: Tacker test for multi vdu with monitoring enabled https://review.openstack.org/246738 | 21:57 |
| *** santoshk has joined #tacker | 22:01 | |
| *** santoshkumark has quit IRC | 22:04 | |
| *** sridhar_ram1 has joined #tacker | 22:06 | |
| *** sripriya_ has joined #tacker | 22:07 | |
| *** sridhar_ram has quit IRC | 22:07 | |
| *** sripriya has quit IRC | 22:10 | |
| *** karimb has joined #tacker | 22:23 | |
| *** karimb has quit IRC | 22:23 | |
| *** karimb has joined #tacker | 22:24 | |
| *** lhcheng has quit IRC | 22:29 | |
| *** lhcheng has joined #tacker | 22:31 | |
| *** lhcheng has quit IRC | 23:00 | |
| *** sridhar_ram1 has quit IRC | 23:02 | |
| *** sridhar_ram has joined #tacker | 23:04 | |
| *** sripriya__ has joined #tacker | 23:04 | |
| *** bobh has quit IRC | 23:05 | |
| *** sripriya_ has quit IRC | 23:08 | |
| *** lhcheng has joined #tacker | 23:13 | |
| *** karimb has quit IRC | 23:14 | |
| *** karimb has joined #tacker | 23:18 | |
| sridhar_ram | trozet: radez: ping, for a quick question | 23:48 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!