| openstackgerrit | Lingxian Kong proposed openstack/python-mistralclient: Support ID for workflow operations in CLI https://review.openstack.org/260755 | 00:46 |
|---|---|---|
| *** gyee has quit IRC | 01:28 | |
| *** lkannan has quit IRC | 01:59 | |
| *** lkannan has joined #openstack-mistral | 02:01 | |
| *** bobh has joined #openstack-mistral | 04:44 | |
| *** bobh has quit IRC | 05:45 | |
| *** bobh has joined #openstack-mistral | 05:49 | |
| openstackgerrit | Lingxian Kong proposed openstack/python-mistralclient: Support ID for workflow operations in CLI https://review.openstack.org/260755 | 05:54 |
| *** bobh has quit IRC | 06:14 | |
| *** melisha has quit IRC | 06:22 | |
| *** melisha has joined #openstack-mistral | 06:22 | |
| *** [1]melisha has joined #openstack-mistral | 07:26 | |
| *** melisha has quit IRC | 07:26 | |
| *** [1]melisha is now known as melisha | 07:26 | |
| openstackgerrit | Liat Fried proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen * Added “Run Action” screen to each row which allows of a specific action execution run. https://review.openstack.org/259971 | 07:28 |
| *** [1]melisha has joined #openstack-mistral | 07:33 | |
| *** [2]melisha has joined #openstack-mistral | 07:37 | |
| *** melisha has quit IRC | 07:37 | |
| *** [2]melisha is now known as melisha | 07:37 | |
| *** [1]melisha has quit IRC | 07:40 | |
| openstackgerrit | Liat Fried proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen https://review.openstack.org/259971 | 07:55 |
| *** openstackgerrit has quit IRC | 08:47 | |
| *** openstackgerrit has joined #openstack-mistral | 08:47 | |
| LimorStotland | Hi guess i have a question... anyone of you run ansible playbook from mistral? | 09:52 |
| *** zhenguo has quit IRC | 10:01 | |
| openstackgerrit | Chaozhe Chen proposed openstack/mistral: devstack/plugin.sh: stop using deprecated option group for rabbit https://review.openstack.org/260938 | 10:21 |
| *** [1]melisha has joined #openstack-mistral | 11:02 | |
| *** melisha has quit IRC | 11:03 | |
| *** [1]melisha is now known as melisha | 11:03 | |
| openstackgerrit | Liat Fried proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen * Added “Run Action” screen to each row which allows of a specific action execution run. https://review.openstack.org/259971 | 12:07 |
| openstackgerrit | Gal Margalit proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen * Added “Run Action” screen to each row which allows of a specific action execution run. https://review.openstack.org/259971 | 12:14 |
| openstackgerrit | Gal Margalit proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen * Added “Run Action” screen to each row which allows of a specific action execution run. https://review.openstack.org/259971 | 12:16 |
| *** openstackgerrit has quit IRC | 12:17 | |
| *** openstackgerrit has joined #openstack-mistral | 12:18 | |
| openstackgerrit | Liat Fried proposed openstack/mistral-dashboard: Mistral-dashboard: Actions screen https://review.openstack.org/259971 | 12:18 |
| *** zhenguo has joined #openstack-mistral | 12:24 | |
| nmakhotkin | hi, LimorStotland! | 12:31 |
| LimorStotland | Hi nmakhotkin | 12:31 |
| nmakhotkin | no, I haven't tried that | 12:31 |
| *** tdurakov has joined #openstack-mistral | 12:37 | |
| tdurakov | hi folks | 12:37 |
| _gryf | hi tdurakov | 12:37 |
| rakhmerov | tdurakov, _gryf | 12:38 |
| rakhmerov | yes | 12:38 |
| rakhmerov | so, Roman, we just talked to Timofei about whether he needs to use Mistral for VM evacuation and why | 12:38 |
| rakhmerov | and we'd like to know your perspective on that | 12:38 |
| rakhmerov | what are the reasons you decided to use Mistral? | 12:39 |
| tdurakov | _gryf,yep, could you provide some usecases where we need mistral | 12:39 |
| _gryf | Ok | 12:39 |
| _gryf | first of all there was at least 3 different approaches, that I've been involved regarding automatic evacuation | 12:40 |
| _gryf | maybe let me start from the beginning | 12:40 |
| tdurakov | yes, please | 12:40 |
| _gryf | as you probably know, there is an enterprise gap in openstack regarding instance availability, which we are attempt to fill | 12:42 |
| rakhmerov | yep | 12:42 |
| rakhmerov | maybe we should sync first on what you VM evacuation is | 12:42 |
| rakhmerov | so that we understand it the same way | 12:42 |
| _gryf | oh | 12:42 |
| _gryf | ok | 12:42 |
| _gryf | so for me, automatic evacuation is a way, to detect and perform instance (vm - if you please) rebuild on other compute node (a physical host) | 12:43 |
| _gryf | I intentionally use the "rebuild" word | 12:44 |
| _gryf | since this is a post mortem process | 12:44 |
| _gryf | so it would be performed in situation, where there is no way to reach the instance, and we have to assume that it is dead | 12:45 |
| rakhmerov | ok | 12:45 |
| _gryf | this one is a bit tricky, since in some circumstances it is not easy to state that instance is dead or not | 12:46 |
| _gryf | for example - there might be situations, that nova compute is not responding | 12:46 |
| tdurakov | _gryf, what about cases when load on host is increased, so it's possible to move instance without rebuild? | 12:47 |
| _gryf | which might happen by network issues, software malfunction, and so on | 12:47 |
| _gryf | tdurakov, yup | 12:47 |
| _gryf | it is called live migration | 12:47 |
| tdurakov | yep | 12:47 |
| _gryf | but it's completely different story :) | 12:47 |
| tdurakov | ok, let's focus first on rebuild then | 12:48 |
| _gryf | ok | 12:48 |
| _gryf | there couple of known approaches reagrding automatic evac | 12:49 |
| _gryf | you can find kind of summary there: https://etherpad.openstack.org/p/automatic-evacuation | 12:49 |
| rakhmerov | ok | 12:51 |
| _gryf | there is an initiative from #openstack-ha people to bring all of the together and choose one as a reference solution for instance ha | 12:51 |
| * tdurakov stated to read etherpad/masakari/etc. | 12:52 | |
| _gryf | as ypu can see, lots of the solution is based on the cluster manager - namely pacemaker | 12:52 |
| _gryf | which would be the source of truth, regarding the state of the hosts, on which instances are run | 12:53 |
| rakhmerov | yep, so as far as I understand | 12:54 |
| _gryf | becasue of pacemaker abilities, we can say in 100% sure, that host, from which we are doing evacuation is really down. | 12:54 |
| rakhmerov | yes | 12:55 |
| rakhmerov | as far as I understand the question is the following | 12:55 |
| rakhmerov | is evacuation really a long running (heavy) process? | 12:55 |
| rakhmerov | so that we need to automate it with Mistral | 12:55 |
| _gryf | let me put it that way | 12:55 |
| rakhmerov | because if it's just a couple of API calls then it doesn't make sense probably to use Mistral | 12:56 |
| rakhmerov | ok | 12:56 |
| _gryf | evacuation of single vm is dependent of what kind of vm are we going to resurrect | 12:56 |
| rakhmerov | tdurakov just expressed an opinion that using Mistral might be overengineering | 12:56 |
| _gryf | the bigger vm, it might take couple of minutes | 12:56 |
| rakhmerov | ok | 12:57 |
| _gryf | right | 12:57 |
| _gryf | we can just fire nova evacuate --on-shared-host vm_name | 12:57 |
| _gryf | and forget | 12:57 |
| _gryf | the truth is | 12:58 |
| _gryf | we cannot | 12:58 |
| _gryf | since if we really like our vm, we have to be sure, that certain vm will be up and running | 12:58 |
| rakhmerov | hm.. not sure I understand | 12:59 |
| _gryf | nova client doesn't gives us such certainty | 12:59 |
| rakhmerov | tdurakov: does it make sense to you? | 12:59 |
| rakhmerov | ok, how does that command work? | 12:59 |
| rakhmerov | could you explain very briefly | 12:59 |
| rakhmerov | ? | 12:59 |
| _gryf | yup | 12:59 |
| tdurakov | yep, this make sence | 13:00 |
| rakhmerov | good :) | 13:00 |
| _gryf | you can use it just like I already described (evacuate a single vm). command will gives you only the ack, that nova client just sent the request to the nova api | 13:00 |
| _gryf | and return an ack | 13:00 |
| rakhmerov | ooh, I see what you mean now | 13:01 |
| rakhmerov | ok | 13:01 |
| _gryf | that's it. it will not monitor anything regarding the rebuilding process | 13:01 |
| _gryf | moreover | 13:01 |
| _gryf | you can just execute the command within all the host, which you want to evacuate machines from | 13:01 |
| _gryf | and this is tricky | 13:02 |
| _gryf | since the functionality is currently implemented on… client side | 13:02 |
| tdurakov | so, it's gonna be not fire and forget, but track the process, right? | 13:02 |
| _gryf | so, nova client will sequentailly send a req to the nova api | 13:02 |
| _gryf | actually - no :) | 13:02 |
| _gryf | this is all the same | 13:03 |
| rakhmerov | and nova client is not HA | 13:03 |
| _gryf | but another threat it bring up - what if nova client dies in that process? | 13:03 |
| rakhmerov | yeah-yeah, this makes sense | 13:04 |
| rakhmerov | I actually didn't realize so far that it works this way | 13:04 |
| rakhmerov | that it's implemented on a client | 13:04 |
| rakhmerov | 1 | 13:04 |
| rakhmerov | (sorry) | 13:04 |
| _gryf | right | 13:04 |
| LimorStotland | Hi can anyone pleas review ? https://review.openstack.org/#/c/259762/ Thanks | 13:05 |
| rakhmerov | LimorStotland: ok | 13:05 |
| _gryf | there might be another scenario, like what if compute dies during the rebuilding - even in single vm evac nova client will be unaware of this | 13:05 |
| tdurakov | _gryf, one point here | 13:06 |
| tdurakov | if compute dies during rebuild, what should be done next? | 13:06 |
| _gryf | that's why another HA enabled service for executing task is needed, which is aware of the state of the tasks and might perform another action | 13:06 |
| _gryf | tdurakov, it depends :) | 13:07 |
| _gryf | tdurakov, for a VMs which have to be up and running, evacuation should be performed again | 13:08 |
| _gryf | so it will up and running eventually | 13:08 |
| rakhmerov | LimorStotland: can you please a couple of formatting issues? | 13:09 |
| rakhmerov | other than that looks ok | 13:09 |
| rakhmerov | I left my comments | 13:09 |
| LimorStotland | ok thanks rakhmerov | 13:09 |
| tdurakov | _gryf, guess, I got the point:) | 13:09 |
| rakhmerov | ok, if we try to summarize: | 13:10 |
| _gryf | and this task IMO Mistral is perfectly matched - it might be configured to perform tasks (including the task, which would monitor the process of evacuation) and perform an action depending on result | 13:10 |
| tdurakov | let's set up meeting next week, say Monday, need time to read all etherpad/links to be on the same page | 13:11 |
| _gryf | tdurakov, you can also read the irc meeting logs for high availability | 13:11 |
| tdurakov | yep, good point! | 13:12 |
| _gryf | i'll put the links here | 13:12 |
| rakhmerov | my summary: even though there's an API call in nova for this there can be a lot of issues happening so we need to monitor the process and make sure it will be completed. If we want to evacuate multiple VMs it's a problem because it's implemented on a client side and client can't be HA | 13:12 |
| _gryf | rakhmerov, the problem with HA of client is also true for evacuating single VM | 13:13 |
| rakhmerov | yes, got it | 13:13 |
| rakhmerov | because it only sends a signal to start evacuation | 13:13 |
| _gryf | right | 13:13 |
| rakhmerov | w/o providing a guarantee that it will be completed | 13:13 |
| _gryf | correct | 13:13 |
| tdurakov | yep, we need to have more control over the process | 13:13 |
| rakhmerov | _gryf: I'm actually a little bit confused. Where are you based of? | 13:14 |
| rakhmerov | Poland? | 13:14 |
| rakhmerov | or US | 13:14 |
| _gryf | rakhmerov, yes | 13:14 |
| _gryf | it's Poland | 13:14 |
| rakhmerov | ooh, I thought it was US | 13:14 |
| rakhmerov | gotcha | 13:14 |
| _gryf | :) | 13:14 |
| rakhmerov | _gryf: could you please suggest a couple of time slots for the next Monday? | 13:15 |
| rakhmerov | I'm not sure I can participate because I'll be on a trip but I'll do my best | 13:15 |
| rakhmerov | or Tue | 13:16 |
| _gryf | rakhmerov, anything will do from 9:00am UTC | 13:16 |
| rakhmerov | Tue would work better for me | 13:16 |
| rakhmerov | ok, from noon msk | 13:17 |
| _gryf | rakhmerov, I'll be able to participate from Mon-Thu | 13:17 |
| tdurakov | rakhmerov, maybe Tue then? | 13:17 |
| rakhmerov | yes | 13:17 |
| rakhmerov | I'll send an invite in a min | 13:17 |
| tdurakov | cool | 13:18 |
| _gryf | wait, Monday to Thursday | 13:18 |
| _gryf | so whenever you guys can in that period :) | 13:18 |
| rakhmerov | just sent an invite | 13:20 |
| tdurakov | yep, thanks a lot, _gryf | 13:20 |
| rakhmerov | please let me know if it works | 13:20 |
| _gryf | rakhmerov, 10am UTC? | 13:21 |
| _gryf | 10:30 UTC, got it | 13:22 |
| rakhmerov | yes | 13:22 |
| rakhmerov | ) | 13:22 |
| _gryf | rakhmerov, could you also add ddeja for this meeting? | 13:22 |
| rakhmerov | yes, give me his email please? | 13:24 |
| rakhmerov | _gryf: ^ | 13:25 |
| _gryf | rakhmerov, already did :) checkout the query msg :) | 13:25 |
| rakhmerov | got it | 13:27 |
| rakhmerov | thanks | 13:27 |
| _gryf | ok. so we all set. | 13:27 |
| openstackgerrit | Limor Stotland proposed openstack/mistral: If task fails on timeout - there is no clear message of failure https://review.openstack.org/259762 | 13:28 |
| openstackgerrit | Limor Stotland proposed openstack/mistral: If task fails on timeout - there is no clear message of failure https://review.openstack.org/259762 | 13:29 |
| *** dprince has joined #openstack-mistral | 13:30 | |
| _gryf | tdurakov, here are HA meetings logs - might be useful: http://eavesdrop.openstack.org/meetings/ha/2015/ | 13:36 |
| _gryf | tdurakov, and the first (missing) one: http://eavesdrop.openstack.org/meetings/ha__automated_recovery_from_hypervisor_failure/2015/ha__automated_recovery_from_hypervisor_failure.2015-11-16-09.00.html | 13:36 |
| tdurakov | _gryf, ok, will read them | 13:37 |
| _gryf | cool :) | 13:37 |
| *** bobh has joined #openstack-mistral | 13:43 | |
| *** bobh has quit IRC | 13:47 | |
| lane_kong | ooh, i have read a good story of vm HA using mistral :-) | 13:56 |
| *** bradjones has quit IRC | 14:16 | |
| *** bobh has joined #openstack-mistral | 14:46 | |
| *** bobh has quit IRC | 14:53 | |
| *** zhenguo has quit IRC | 14:56 | |
| *** dprince has quit IRC | 15:33 | |
| *** dprince has joined #openstack-mistral | 15:35 | |
| *** melisha has quit IRC | 15:49 | |
| *** melisha has joined #openstack-mistral | 15:51 | |
| *** bobh_ has joined #openstack-mistral | 16:17 | |
| openstackgerrit | Merged openstack/mistral-dashboard: UI: Task screen auto refresh https://review.openstack.org/259935 | 16:26 |
| *** bobh has joined #openstack-mistral | 16:28 | |
| *** bobh_ has quit IRC | 16:31 | |
| *** bobh has quit IRC | 16:39 | |
| openstackgerrit | Merged openstack/mistral: If task fails on timeout - there is no clear message of failure https://review.openstack.org/259762 | 16:56 |
| *** bobh has joined #openstack-mistral | 17:46 | |
| *** bobh has quit IRC | 17:48 | |
| *** Ephur has joined #openstack-mistral | 19:36 | |
| *** tonytan4ever has joined #openstack-mistral | 19:46 | |
| *** dprince has quit IRC | 21:30 | |
| *** bobh has joined #openstack-mistral | 21:41 | |
| *** openstack has joined #openstack-mistral | 22:22 | |
| *** openstack has joined #openstack-mistral | 22:37 | |
| *** bobh has quit IRC | 23:01 | |
| *** Ephur has quit IRC | 23:02 | |
| *** bobh has joined #openstack-mistral | 23:06 | |
| *** tonytan4ever has quit IRC | 23:18 | |
| *** tonytan4ever has joined #openstack-mistral | 23:19 | |
| *** tonytan4ever has quit IRC | 23:20 | |
| *** bobh has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!