| *** manishg has quit IRC | 00:24 | |
| *** manishg has joined #openstack-lbaas | 00:28 | |
| *** Kiall has quit IRC | 00:47 | |
| *** Kiall has joined #openstack-lbaas | 00:49 | |
| *** manishg has quit IRC | 00:50 | |
| *** manishg has joined #openstack-lbaas | 00:56 | |
| *** manishg has quit IRC | 01:01 | |
| *** manishg has joined #openstack-lbaas | 01:06 | |
| *** mixos has joined #openstack-lbaas | 01:19 | |
| *** mixos has quit IRC | 01:25 | |
| *** manishg has quit IRC | 01:26 | |
| *** bana_k has quit IRC | 01:29 | |
| *** manishg has joined #openstack-lbaas | 01:57 | |
| *** manishg has quit IRC | 02:49 | |
| *** ducttape_ has joined #openstack-lbaas | 02:49 | |
| *** ducttape_ has quit IRC | 03:09 | |
| *** ducttape_ has joined #openstack-lbaas | 03:35 | |
| *** ducttape_ has quit IRC | 03:38 | |
| *** armax has joined #openstack-lbaas | 04:26 | |
| *** armax_ has joined #openstack-lbaas | 04:30 | |
| *** armax has quit IRC | 04:31 | |
| *** armax_ is now known as armax | 04:31 | |
| *** blogan_ has joined #openstack-lbaas | 04:54 | |
| *** manishg has joined #openstack-lbaas | 05:19 | |
| *** armax has quit IRC | 05:40 | |
| *** manishg has quit IRC | 05:45 | |
| *** manishg has joined #openstack-lbaas | 05:48 | |
| *** mixos has joined #openstack-lbaas | 05:57 | |
| *** manishg has quit IRC | 06:40 | |
| *** manishg has joined #openstack-lbaas | 06:52 | |
| *** manishg has quit IRC | 06:52 | |
| openstackgerrit | Brandon Logan proposed openstack/octavia: Get Me A Load Balancer Controller https://review.openstack.org/257013 | 07:01 |
|---|---|---|
| *** mixos has quit IRC | 07:01 | |
| *** blogan_ has quit IRC | 07:07 | |
| *** manishg has joined #openstack-lbaas | 07:15 | |
| *** manishg has quit IRC | 07:27 | |
| *** manishg has joined #openstack-lbaas | 07:28 | |
| *** manishg has quit IRC | 07:33 | |
| *** nmagnezi has joined #openstack-lbaas | 07:43 | |
| *** manishg has joined #openstack-lbaas | 07:58 | |
| *** manishg has quit IRC | 08:15 | |
| *** mhickey has joined #openstack-lbaas | 08:30 | |
| *** yamamoto has joined #openstack-lbaas | 08:56 | |
| *** mhickey has quit IRC | 09:02 | |
| *** yamamoto has quit IRC | 09:50 | |
| *** yamamoto has joined #openstack-lbaas | 09:54 | |
| *** yamamoto has quit IRC | 09:59 | |
| *** yamamoto has joined #openstack-lbaas | 10:03 | |
| *** yamamoto has quit IRC | 10:15 | |
| *** xgerman has quit IRC | 10:26 | |
| *** sballe has quit IRC | 10:29 | |
| *** ramishra_ has quit IRC | 10:32 | |
| *** ctracey has quit IRC | 10:32 | |
| *** rcernin has joined #openstack-lbaas | 10:35 | |
| *** dougwig has quit IRC | 10:36 | |
| *** ramishra_ has joined #openstack-lbaas | 10:44 | |
| *** dougwig has joined #openstack-lbaas | 10:45 | |
| *** ctracey has joined #openstack-lbaas | 10:49 | |
| *** sballe has joined #openstack-lbaas | 10:49 | |
| *** xgerman has joined #openstack-lbaas | 10:51 | |
| *** ig0r__ has joined #openstack-lbaas | 11:03 | |
| *** ig0r_ has quit IRC | 11:05 | |
| openstackgerrit | Kobi Samoray proposed openstack/neutron-lbaas: (WIP) Add support X-Forwarded-For header https://review.openstack.org/255963 | 11:24 |
| *** rcernin has quit IRC | 11:34 | |
| *** kobis1 has quit IRC | 12:04 | |
| *** nmagnezi has quit IRC | 12:40 | |
| *** ducttape_ has joined #openstack-lbaas | 12:57 | |
| *** ducttape_ has quit IRC | 13:05 | |
| *** rcernin has joined #openstack-lbaas | 13:14 | |
| *** ducttape_ has joined #openstack-lbaas | 13:21 | |
| *** ducttape_ has quit IRC | 13:25 | |
| *** ducttape_ has joined #openstack-lbaas | 13:58 | |
| *** yamamoto has joined #openstack-lbaas | 14:03 | |
| *** ducttape_ has quit IRC | 14:11 | |
| *** nmagnezi has joined #openstack-lbaas | 14:14 | |
| *** ducttape_ has joined #openstack-lbaas | 14:39 | |
| *** yamamoto has quit IRC | 14:42 | |
| *** kobis has joined #openstack-lbaas | 14:44 | |
| *** ducttape_ has quit IRC | 14:44 | |
| *** yamamoto has joined #openstack-lbaas | 14:46 | |
| *** manishg has joined #openstack-lbaas | 14:52 | |
| *** ducttape_ has joined #openstack-lbaas | 14:56 | |
| *** kobis has quit IRC | 14:57 | |
| *** kobis has joined #openstack-lbaas | 14:57 | |
| *** kobis has quit IRC | 15:04 | |
| *** manishg has quit IRC | 15:10 | |
| *** ducttape_ has quit IRC | 15:22 | |
| *** ducttape_ has joined #openstack-lbaas | 15:22 | |
| *** manishg has joined #openstack-lbaas | 15:32 | |
| *** ducttape_ has quit IRC | 15:37 | |
| *** ducttape_ has joined #openstack-lbaas | 15:44 | |
| *** ducttape_ has quit IRC | 15:44 | |
| *** kobis has joined #openstack-lbaas | 15:45 | |
| *** ducttape_ has joined #openstack-lbaas | 15:46 | |
| *** kobis1 has joined #openstack-lbaas | 15:48 | |
| *** kobis has quit IRC | 15:49 | |
| *** kobis1 has quit IRC | 15:50 | |
| *** manishg has quit IRC | 15:51 | |
| *** kobis has joined #openstack-lbaas | 15:52 | |
| *** yamamoto has quit IRC | 16:00 | |
| *** yamamoto has joined #openstack-lbaas | 16:02 | |
| *** yamamoto has quit IRC | 16:03 | |
| *** ducttape_ has quit IRC | 16:14 | |
| *** ducttape_ has joined #openstack-lbaas | 16:18 | |
| *** kobis has quit IRC | 16:22 | |
| *** ducttape_ has quit IRC | 16:23 | |
| *** mixos has joined #openstack-lbaas | 16:28 | |
| *** mixos has quit IRC | 16:48 | |
| *** armax has joined #openstack-lbaas | 16:56 | |
| *** ianbrown has quit IRC | 17:18 | |
| *** ducttape_ has joined #openstack-lbaas | 17:19 | |
| *** armax has quit IRC | 17:22 | |
| *** ducttape_ has quit IRC | 17:25 | |
| *** armax has joined #openstack-lbaas | 17:28 | |
| *** armax has quit IRC | 17:33 | |
| *** rcernin has quit IRC | 17:36 | |
| *** manishg has joined #openstack-lbaas | 17:39 | |
| *** mixos has joined #openstack-lbaas | 17:53 | |
| *** dougwig has quit IRC | 18:06 | |
| *** bradjones has quit IRC | 18:06 | |
| *** dougwig has joined #openstack-lbaas | 18:06 | |
| *** whydidyoustealmy has joined #openstack-lbaas | 18:08 | |
| *** ctracey_ has joined #openstack-lbaas | 18:10 | |
| *** ig0r_ has joined #openstack-lbaas | 18:11 | |
| *** ramishra__ has joined #openstack-lbaas | 18:11 | |
| *** bradjones has joined #openstack-lbaas | 18:11 | |
| *** bradjones has quit IRC | 18:11 | |
| *** bradjones has joined #openstack-lbaas | 18:11 | |
| *** ctracey has quit IRC | 18:13 | |
| *** ramishra_ has quit IRC | 18:13 | |
| *** barra204 has quit IRC | 18:13 | |
| *** openstackgerrit has quit IRC | 18:13 | |
| *** ig0r__ has quit IRC | 18:13 | |
| *** ramishra__ is now known as ramishra_ | 18:14 | |
| *** ctracey_ is now known as ctracey | 18:14 | |
| *** rcernin has joined #openstack-lbaas | 18:16 | |
| *** manishg has quit IRC | 18:30 | |
| *** rcernin has quit IRC | 18:39 | |
| *** manishg has joined #openstack-lbaas | 18:41 | |
| *** manishg has quit IRC | 18:43 | |
| *** manishg has joined #openstack-lbaas | 18:44 | |
| *** mixos has quit IRC | 18:47 | |
| *** dnovosel is now known as dnovosel__ | 18:48 | |
| *** kobis has joined #openstack-lbaas | 18:51 | |
| *** mixos has joined #openstack-lbaas | 18:54 | |
| ptoohill | I think im going to redo the graph/decider flow to just do a if check... | 19:12 |
| ptoohill | That or duplicate all the flows with slight tweakings so i can sorta reuse things | 19:12 |
| ptoohill | any objections? Reuse of the flows are impossible, and even more so no, i dont see a use for them if we have to duplicate everything | 19:14 |
| ptoohill | now* | 19:14 |
| *** mixos has quit IRC | 19:16 | |
| ptoohill | I wish i would have looked at that review more before it got merged | 19:17 |
| *** manishg has quit IRC | 19:18 | |
| *** ducttape_ has joined #openstack-lbaas | 19:22 | |
| *** ducttape_ has quit IRC | 19:26 | |
| *** kobis has quit IRC | 19:31 | |
| *** crc32|znc has quit IRC | 19:33 | |
| *** jorgem[away] has quit IRC | 19:33 | |
| *** HenryG has quit IRC | 19:33 | |
| *** clduser has quit IRC | 19:33 | |
| *** dnovosel__ has quit IRC | 19:33 | |
| *** albertom has quit IRC | 19:34 | |
| *** kfox1111 has quit IRC | 19:34 | |
| *** blogan has quit IRC | 19:34 | |
| *** kbyrne has quit IRC | 19:34 | |
| *** ptoohill has quit IRC | 19:34 | |
| *** crc32|znc has joined #openstack-lbaas | 19:34 | |
| *** clduser has joined #openstack-lbaas | 19:34 | |
| *** HenryG has joined #openstack-lbaas | 19:34 | |
| *** jorgem[away] has joined #openstack-lbaas | 19:34 | |
| *** dnovosel__ has joined #openstack-lbaas | 19:34 | |
| *** albertom has joined #openstack-lbaas | 19:34 | |
| *** kfox1111 has joined #openstack-lbaas | 19:34 | |
| *** blogan has joined #openstack-lbaas | 19:34 | |
| *** kbyrne has joined #openstack-lbaas | 19:34 | |
| *** ptoohill has joined #openstack-lbaas | 19:34 | |
| johnsom | ptoohill which flow are you talking about? | 20:01 |
| johnsom | ptoohill FYI, you might want to look at the active/standby failover flow code. I have been working with the taskflow team and we now have fully functional deciders, especially for subflows. failover is the first to use this. At some point I need to go back and simplify the other flows and make them all into one flow again now that the bug is fixed. | 20:13 |
| ptoohill | johnsom: I need to be able to pass data in to the graph flow, this is not allowed. Ill take a look, but for my workflow, ive bashed my brains trying several different solutions, nothing is working the way i would think it should | 20:26 |
| *** armax has joined #openstack-lbaas | 20:26 | |
| *** rcernin has joined #openstack-lbaas | 20:26 | |
| ptoohill | get_amphora_for_lb_subflow, thats the flow that is the gateway to the rest of the build | 20:26 |
| ptoohill | i cant pass data to it because its not part of the providers. Ill take a look at the fail over, but i think my workflow is a bit different | 20:27 |
| johnsom | You can pass data into flows using the storage engine. It's how we pass data task to task or inject data into the initial flow | 20:27 |
| *** nmagnezi has quit IRC | 20:27 | |
| johnsom | Check out this patch: https://review.openstack.org/#/c/253724/ | 20:28 |
| ptoohill | Yea, but i have subflows that do not store to the engine, i get 'invalid providers' | 20:28 |
| johnsom | Ok, that is odd. I pass a lot of data in and out of the subflows | 20:29 |
| ptoohill | So, for my example, i build list of network id/port ids, then attempt to pass it along so the amps will get built as such. This is not allowed with graph flow | 20:29 |
| johnsom | Are you trying to use a pre-release Taskflow? I know when we were working on the bug fix it was broken for a bit as it was trying to get data from the wrong branch of the decider | 20:30 |
| ptoohill | This is a mess, im going to just cut losses right now, because if i have to re-refactor when your stuff gets in this is going to be a nightmare | 20:30 |
| ptoohill | im not utilizing the decider, maybe thats my problem i dont understand this | 20:30 |
| ptoohill | i wanted to reuse the active-standby code but be able to pass in the network configs | 20:31 |
| ptoohill | it yells that my data isnt from a proper provider | 20:31 |
| johnsom | You can definitely pass data along in the graph flows. Graph flows are just different as you have to explicitely link each task | 20:31 |
| ptoohill | thats the problem... | 20:31 |
| ptoohill | so i need to add these random tasks that would let my task, and allow the graph flow to be generic | 20:32 |
| ptoohill | let my task work* | 20:32 |
| ptoohill | this isnt working | 20:32 |
| ptoohill | So, that means i need to duplicate the workflow and call the ones with specific flows | 20:32 |
| johnsom | Should work. Is it the decider with subflow that is complaining? | 20:32 |
| ptoohill | This is incredibly difficult to work with | 20:32 |
| ptoohill | get_amphora_for_lb_subflow | 20:32 |
| ptoohill | networkids is populated here, but it wont even compile because im trying to pass data in that isnt part of the providers | 20:33 |
| ptoohill | i guess i just dont understand the mess | 20:33 |
| ptoohill | so youre saying i need to link it | 20:33 |
| ptoohill | though i did do that and got the same message, possible because i added several | 20:33 |
| johnsom | Do you have code up I can look at? | 20:33 |
| ptoohill | can you have many link to one? i didnt see that as part of the method def | 20:34 |
| ptoohill | i have the patch up where i realized things werent going to work, everything else is local and messy, id hate to push it up | 20:34 |
| johnsom | Ok. I'm not 100% following so let me ask some questions (if you have time, it is Sunday, if you want to pick it up tomorrow we can do that too). | 20:35 |
| ptoohill | I told my boss i would have this done today, so i have time :/ | 20:35 |
| johnsom | So you have some data you want to pass through the flow. Is the data produced in a task (i.e. a provides) or need to be passed into a flow at the start? | 20:36 |
| ptoohill | Its provided from a flow called prior to the decider | 20:37 |
| ptoohill | which is another issue itself | 20:37 |
| ptoohill | I cant call the flows, making them a subflow because they need an arg | 20:37 |
| ptoohill | but thats another issue that can be worked around, its really ugly, but it works | 20:38 |
| johnsom | Ok, that is fine. So in a task, before the deciders you have a task that has a provides, i.e. | 20:38 |
| johnsom | https://github.com/openstack/octavia/blob/master/octavia/controller/worker/tasks/database_tasks.py#L49 | 20:38 |
| johnsom | CreateAmphoraInDB returns the amphora.id, which | 20:38 |
| ptoohill | essentially, im calling another flow that calls two tasks, but yes | 20:39 |
| johnsom | Is called like this: https://github.com/openstack/octavia/blob/master/octavia/controller/worker/flows/amphora_flows.py#L48 | 20:40 |
| ptoohill | well yes | 20:40 |
| ptoohill | a task is called from a flow? | 20:41 |
| johnsom | So that line says, run this task, take it's return and store it as whatever constants.AMPHORA_ID string is. | 20:41 |
| ptoohill | im following the basic steps of taskflow, thats not the problem | 20:41 |
| *** rcernin has quit IRC | 20:41 | |
| ptoohill | yes | 20:41 |
| ptoohill | im not following here, it seems like youre unsure i even have the flows set up right | 20:41 |
| johnsom | Ok, I was just trying to give an example of storing data from a task, into a flow. | 20:41 |
| ptoohill | yea, im past all that, ive had this all working before | 20:42 |
| ptoohill | ive fought with taskflow for several months now | 20:42 |
| johnsom | Well, I'm not sure where the problem is, so I was starting at the beginning. Sometimes that sparks ideas, etc. | 20:42 |
| ptoohill | fair enough | 20:42 |
| ptoohill | The problem is the graph flow doesnt like data thats not part of its providers | 20:42 |
| ptoohill | so you CANNOT pass data from another task unless its part of that flow already | 20:43 |
| ptoohill | another flow* | 20:43 |
| johnsom | Ok. The next thing is if you need to pass a stored item into a task as a different name, you use rebind to change the name of a stored item for a specific task | 20:43 |
| ptoohill | not about renaming or anything like that either | 20:43 |
| ptoohill | its a limitation of taskflow | 20:43 |
| ptoohill | i cannot reuse this the way i need to. The only solution is to build similar flows all the way down the line with my tweaks | 20:44 |
| johnsom | Correct on if one flow stores data, another flow cannot access it. The storage is only shared inside one flow and it's subflows | 20:44 |
| ptoohill | you would think so right? | 20:44 |
| ptoohill | i thought so too | 20:44 |
| ptoohill | and tried it several ways you would have thought it would work | 20:44 |
| ptoohill | try this | 20:44 |
| ptoohill | sample of my controller worker work-around to get past some of the other taskflow issues | 20:45 |
| ptoohill | https://gist.github.com/the2hill/9a6bec20346e4ae5812d | 20:45 |
| ptoohill | can ignore the last two, but notice my 'pre' flow, that populates data for network config stuff | 20:45 |
| ptoohill | then when i try to call the rest of the flow it wont work, the graph flow complains | 20:46 |
| johnsom | Looking. Also, take a look at this bug we just fixed last week and see if that relates: https://bugs.launchpad.net/taskflow/+bug/1479466 | 20:46 |
| openstack | Launchpad bug 1479466 in taskflow "The needs to treat subflows as standalone entity" [Undecided,New] | 20:46 |
| ptoohill | really it complains on load | 20:46 |
| ptoohill | that is part of it | 20:46 |
| johnsom | Ok, give me a minute | 20:46 |
| ptoohill | but they said they wont fix it because thats the way its supposed to be | 20:46 |
| ptoohill | well, they said they could look into it | 20:46 |
| ptoohill | but | 20:46 |
| ptoohill | but that is indeed whats causing me issues | 20:47 |
| ptoohill | and theres no 'clean' way around it | 20:47 |
| johnsom | What, the bug? No, we fixed it last week. It's up for review right now | 20:47 |
| ptoohill | maybe im thinking of another | 20:47 |
| ptoohill | the one that was in comment, checking | 20:47 |
| *** rcernin has joined #openstack-lbaas | 20:48 | |
| ptoohill | ok, so then maybe i just need to update taskflow and itll let me pass other data in? | 20:48 |
| ptoohill | https://bugs.launchpad.net/taskflow/+bug/1479466 This bug was fixed? | 20:48 |
| openstack | Launchpad bug 1479466 in taskflow "The needs to treat subflows as standalone entity" [Undecided,New] | 20:48 |
| johnsom | Ok, wait a second. So this code is four, separate flows.... | 20:48 |
| ptoohill | yea, as a work around for other mess... | 20:49 |
| johnsom | Yeah, Josh, Min, and I have been working on it for the last two weeks. | 20:49 |
| ptoohill | its the same problem though | 20:49 |
| ptoohill | and prior to active-standby it worked | 20:49 |
| johnsom | So, four flows is bad. We really only want one flow so it reverts correctly. | 20:49 |
| ptoohill | so its not merged | 20:49 |
| ptoohill | lol.... | 20:49 |
| ptoohill | well, if this was easier to work with then that would be the case.. | 20:49 |
| ptoohill | i only have it like this because it doesnt want to work other ways | 20:50 |
| ptoohill | and ive since changed this up, that was just example to help you get idea of my problem | 20:50 |
| ptoohill | The problem right now, is that the graph flow wont take data from a flow outside of its providers | 20:50 |
| johnsom | Yeah, the way this code is, you have store = A, flow one get A as it's store, works with it, chnages it. Flow b gets store A, but all of those previous changes are lost, it is using the initial definition of store. | 20:52 |
| ptoohill | So, unless what you guys were working on actually solves my issues, i need to duplicate the flows with my tweaks. That resolves have multiple flows being called and i can reuse them between other flows | 20:52 |
| ptoohill | yea, that was another issue youre right, but not the problem i was trying to explain | 20:53 |
| johnsom | So, what you need is one flow, add these flows as sub-flows to that one flow. | 20:53 |
| ptoohill | I think taskflow is going to get me to quit my job and go back to welding | 20:53 |
| ptoohill | thats still not the problem, i guess im not explaining it correctly. Thanks for the help though johnsom | 20:53 |
| johnsom | I'm really sorry you are frustrated. It is rough to get into, but the more I use it the more I understand the value. | 20:54 |
| ptoohill | i still dont see value in this mess. ive dealt with it for several months and its only getting harder to deal with and read | 20:54 |
| *** armax has quit IRC | 20:55 | |
| ptoohill | and i cant get it to do what i need without duplicating everything.. so to me its useless | 20:55 |
| johnsom | Well, I'm happy to spend the time and help. I think we are getting to the problem. | 21:00 |
| johnsom | If there are deciders in the flow, it is quite possible you hit the bug where there is a main flow, deciders, goes down branch a, comes back to main flow and it "IGNORES" the rest of the main flow. That is what we just fixed. | 21:01 |
| johnsom | It made the failover flow much cleaner after we got that fixed. | 21:02 |
| ptoohill | My issue is that im trying to call the deciders flow with information not populated inside of the linked flows | 21:02 |
| ptoohill | it doesnt like that, and i dont think theres a way around it | 21:02 |
| johnsom | You can store AMP in the main flow, go down a decider into branch A, and access AMP inside branch A | 21:03 |
| ptoohill | so, that means i need to recreate flows up to and a little past the deciders flows with my other flows to populate the proper data | 21:03 |
| ptoohill | with the fixes youve made? | 21:03 |
| johnsom | That worked without the fixes | 21:03 |
| ptoohill | Then this isnt the same thing | 21:03 |
| johnsom | That works with 1.25 taskflow | 21:03 |
| ptoohill | unless i have old taskflow | 21:04 |
| ptoohill | im on 1.25 | 21:04 |
| johnsom | Check, you really want 1.25. If you are getting the "IGNORES" in debug, that is where you will need our fix | 21:04 |
| ptoohill | The issue im seeing is i try to call the create lb flow, which calls the decider flow and all that. But prior to calling the creat_lb i populated network data | 21:05 |
| ptoohill | once it gets to the decider it tells me network_ids doesnt belong to the one of two provider that were possible | 21:06 |
| ptoohill | the only way ive gotten this to work is add those flows where i called them before, to actually call them further down the chain. This isnt what i need | 21:06 |
| ptoohill | so i cant have a 'pre' flow that gathers data and then calls the create workflow | 21:07 |
| ptoohill | and i need this | 21:07 |
| johnsom | That works | 21:07 |
| johnsom | I have done it. Should I try to right a small sample app? | 21:08 |
| ptoohill | sure, ill undo some of the workaround ive done and push that up too | 21:08 |
| ptoohill | because that doesnt work for me | 21:08 |
| ptoohill | im about to go to kids bball game though, ill be on a bit later | 21:08 |
| johnsom | Ok, let me give a go, I will post a gist in this channel. Will that work or would e-mail be better for you? | 21:09 |
| ptoohill | maybe its because network ids is used in the flow further down and the error message i was getting was because of a conflict | 21:09 |
| ptoohill | i have bouncer, ill see scroll back | 21:09 |
| johnsom | Yeah, the rebind thing gets me when I forget to use it. Ok, I will write a sample app and post a gist here | 21:10 |
| johnsom | Enjoy bball | 21:10 |
| ptoohill | but i need to use network_ids though | 21:10 |
| ptoohill | i cant rebind that | 21:10 |
| ptoohill | it needs to be netowrk_ids so the other flows picks it up | 21:10 |
| ptoohill | or i have the same issues about having to duplicate things | 21:10 |
| johnsom | rebind just renames objects for task reuse issues that have name conflicts | 21:11 |
| ptoohill | yea | 21:11 |
| ptoohill | so that means if i get past the decider error, i have to rework the other flows to take my rebound arg? | 21:12 |
| ptoohill | im trying to reuse thigns here | 21:12 |
| johnsom | Nope, you shouldn't have to change the flows | 21:12 |
| ptoohill | so if i rebind network_ids to net_ids, the flows looking for network_ids is still going to pick it up? | 21:13 |
| ptoohill | thats how that works? | 21:13 |
| *** gomarivera has joined #openstack-lbaas | 21:13 | |
| johnsom | nope, you would only rebind if you have network_ids, but the subflow or tasks expect net_ids. | 21:13 |
| ptoohill | .. | 21:13 |
| *** armax has joined #openstack-lbaas | 21:14 | |
| johnsom | Otherwise if they are all looking for network_ids you are good, they will all pull it correct from the storage | 21:14 |
| ptoohill | then rebind wont solve my decider problem | 21:14 |
| ptoohill | yea, that was what i was thinking, so this wouldnt solve my issue | 21:14 |
| ptoohill | fun stuff | 21:14 |
| ptoohill | i have to head out, when i get back ill undo some of the stuff and put it back to show the issue im having | 21:15 |
| johnsom | Ok, I will have some sample code too | 21:16 |
| *** ducttape_ has joined #openstack-lbaas | 21:23 | |
| *** ducttape_ has quit IRC | 21:27 | |
| *** elarson_ is now known as elarson | 21:36 | |
| *** manishg has joined #openstack-lbaas | 21:45 | |
| *** ianbrown has joined #openstack-lbaas | 21:55 | |
| *** ianbrown has quit IRC | 21:58 | |
| *** manishg has quit IRC | 21:58 | |
| johnsom | ptoohill https://gist.github.com/johnsom/4878395e92a82e8c11a6 | 22:00 |
| johnsom | See if I understood what you are trying to do. | 22:01 |
| *** ianbrown has joined #openstack-lbaas | 22:13 | |
| *** rcernin has quit IRC | 22:30 | |
| *** ducttape_ has joined #openstack-lbaas | 22:45 | |
| *** ducttape_ has quit IRC | 22:47 | |
| *** armax has quit IRC | 22:58 | |
| *** yuanying has joined #openstack-lbaas | 23:00 | |
| *** yuanying has quit IRC | 23:00 | |
| ptoohill | johnsom: This is just showing two flows and no data is being taken from before the decider and used after the decider | 23:32 |
| ptoohill | This is doing exactly whats already there | 23:33 |
| ptoohill | in our code | 23:33 |
| ptoohill | well i see store task now | 23:33 |
| ptoohill | so i have to return a random name, then rebind it to the name thats used elsewhere for this to work? | 23:34 |
| ptoohill | or do i need to do, in all the flows that i shouldnt need to touch, to rebind? this isnt making sense | 23:35 |
| ptoohill | So, i have quite a mess here, im pretty deep into reworking things. Ill try to explain it again | 23:43 |
| ptoohill | Attempting to reuse the create_load_balancer flow | 23:43 |
| ptoohill | I have a flow prior to this that makes the create_lb a subflow essentially, within the first flow i create data, the next flow inline is the create_lb flow, that flow then calls the create_amp graph flow, the graphflow complains that the data i sent is not part of its providers | 23:44 |
| ptoohill | So your solution would be me duplicating the flows to add in what i need | 23:44 |
| ptoohill | since i cant call the individual flows from the controller and i need to reuse them i dont see another way to do it besides replicating. The example you pasted wont work for my case | 23:45 |
| ptoohill | unless this example means i just need to rebind network_ids to network_ids and itll magically work | 23:48 |
| ptoohill | but that still means that would have to be done everywhere and is just as bad, but i really dont think this is the case | 23:49 |
| *** rsanchez87 has joined #openstack-lbaas | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!