| *** harlowja has joined #openstack-mistral | 00:06 | |
| *** dprince has quit IRC | 00:16 | |
| *** jaosorior has quit IRC | 00:31 | |
| *** bobh has joined #openstack-mistral | 00:55 | |
| *** bobh has quit IRC | 01:22 | |
| *** bobh has joined #openstack-mistral | 01:30 | |
| *** bobh has quit IRC | 01:32 | |
| *** bobh has joined #openstack-mistral | 01:33 | |
| *** bobh has quit IRC | 01:36 | |
| *** diablo_rojo has joined #openstack-mistral | 01:46 | |
| *** diablo_rojo has quit IRC | 01:48 | |
| *** bobh has joined #openstack-mistral | 01:54 | |
| *** bobh has quit IRC | 02:14 | |
| *** jrist has quit IRC | 02:18 | |
| mfisch | kong: let me ask you something else | 02:23 |
|---|---|---|
| mfisch | is there the concept of a public workbook? | 02:23 |
| kong | mfisch: iirc, mistral doesn't support creating 'public' workbook | 02:25 |
| kong | although is easy to implement | 02:26 |
| mfisch | thats what I tried to tell the trove folks | 02:26 |
| kong | but i suggest to use workflow or action instead | 02:26 |
| mfisch | without that their solution to scheduled DB backups will not work well | 02:26 |
| mfisch | oh odd | 02:26 |
| kong | why not use workflow or action instead of workbook? | 02:26 |
| mfisch | looking again they called this file trove-workbook.yaml but the file is a workflow | 02:26 |
| mfisch | so that I know you can make public | 02:27 |
| kong | yeah | 02:27 |
| kong | workbook is an old thing from my perspective | 02:27 |
| mfisch | I suspect the person I was speaking to knew less about mistral than even I do hence the confusion | 02:27 |
| mfisch | thanks | 02:27 |
| kong | mfisch: np | 02:27 |
| *** jrist has joined #openstack-mistral | 02:32 | |
| *** harlowja has quit IRC | 02:36 | |
| *** gongysh has joined #openstack-mistral | 03:20 | |
| *** sharatss has quit IRC | 03:26 | |
| *** sharatss has joined #openstack-mistral | 03:26 | |
| rakhmerov | mfisch, kong: yes, workbook is kind of an old thing left from the very initial design but it can serve for good | 04:17 |
| rakhmerov | as a container of things with namespacing capabilities | 04:18 |
| rakhmerov | kong: as far as making these things public, I'm not sure why you said it's impossible | 04:19 |
| rakhmerov | all these entities (including workbooks) have the attribute 'scope' which can be 'public' | 04:19 |
| rakhmerov | and in this case it will be accessible publicly from any tenant (if we could deal with that id/name issue) | 04:20 |
| rakhmerov | or you mean something different? | 04:20 |
| rakhmerov | kong, ddeja, d0ugal, sharatss, mgershen: once you have time please take a look at https://review.openstack.org/#/c/420650/ | 04:24 |
| rakhmerov | we need it very much internally | 04:24 |
| rakhmerov | but I tried to come up with as much generic design as I could | 04:24 |
| rakhmerov | kong: please ping me when you're online | 04:50 |
| rakhmerov | I'd like to discuss that spec about regions with you here | 04:50 |
| rakhmerov | I've read all the replies | 04:50 |
| rakhmerov | kong: replied in the comments | 04:59 |
| openstackgerrit | Sharat Sharma proposed openstack/python-mistralclient: Changed the README.rst https://review.openstack.org/421098 | 05:22 |
| *** sharatss has quit IRC | 05:23 | |
| *** sharatss has joined #openstack-mistral | 05:24 | |
| sharatss | rakhmerov: ddeja d0ugal when you have time pls review https://review.openstack.org/#/c/418737/ Its been there for a long time | 05:36 |
| *** ist has joined #openstack-mistral | 05:56 | |
| openstackgerrit | Sharat Sharma proposed openstack/mistral: Enforce style check for assertIsNone https://review.openstack.org/420405 | 05:59 |
| openstackgerrit | Renat Akhmerov proposed openstack/mistral: Add action "std.test_dict" https://review.openstack.org/421686 | 06:26 |
| rakhmerov | sharatss: did you test congress actions somehow? | 06:30 |
| rakhmerov | on a real environment | 06:30 |
| sharatss | rakhmerov: to be honest i am not familiar with congress. It was a requirement from someone to add it | 06:34 |
| rakhmerov | woow | 06:34 |
| sharatss | rakhmerov: that person had no complaints about this code | 06:34 |
| rakhmerov | :) | 06:34 |
| sharatss | rakhmerov: maybe i will test it sometime and then ask for review :) | 06:34 |
| rakhmerov | sharatss: I have no complaints about the code either except... I have no idea if it works | 06:34 |
| rakhmerov | sharatss: indeed, please do | 06:35 |
| rakhmerov | we should have at least your word saying that "yes, I tested 1-2 actions, they work fine" | 06:35 |
| sharatss | rakhmerov: yes. sure. May be by EOD or tomorrow :) | 06:35 |
| rakhmerov | we can't just accept something that we don't know at all if it works or not | 06:35 |
| sharatss | rakhmerov: i understand :) | 06:35 |
| rakhmerov | ok | 06:36 |
| rakhmerov | sharatss: please let's not have such a situation again | 06:37 |
| rakhmerov | when you're committing something you need to make sure you tested it | 06:37 |
| sharatss | rakhmerov: yes | 06:37 |
| rakhmerov | I understand that for some things it is not easy to automate test but at least you need to do it manually on your environment | 06:38 |
| rakhmerov | ok, thanks | 06:38 |
| *** gongysh has quit IRC | 07:00 | |
| *** jrist has quit IRC | 07:11 | |
| *** jrist has joined #openstack-mistral | 07:11 | |
| *** jrist has quit IRC | 07:14 | |
| *** jrist has joined #openstack-mistral | 07:16 | |
| *** shardy has joined #openstack-mistral | 08:12 | |
| *** gongysh has joined #openstack-mistral | 08:14 | |
| *** gongysh has quit IRC | 08:46 | |
| *** jpich has joined #openstack-mistral | 08:52 | |
| *** mgershen has quit IRC | 09:24 | |
| *** mgershen has joined #openstack-mistral | 09:28 | |
| *** gongysh has joined #openstack-mistral | 09:46 | |
| kong | rakhmerov: hi, i'm here | 09:56 |
| kong | rakhmerov: i'm going to propose a release for mistralclient, do you have concern about that? | 09:56 |
| rakhmerov | kong: nope, do it please | 10:01 |
| rakhmerov | give me a few mins, I'll be back | 10:01 |
| rakhmerov | as far as the spec, I replied, you can take a look | 10:01 |
| ddeja | rakhmerov: I'm looking on your change | 10:08 |
| rakhmerov | ddeja: which one? | 10:08 |
| ddeja | rakhmerov: workflow global context spec | 10:08 |
| rakhmerov | ok | 10:08 |
| ddeja | the one you asked a few hours before ;) | 10:08 |
| rakhmerov | yeah, np | 10:08 |
| rakhmerov | we just realized that we need something like this in our product at Nokia | 10:09 |
| rakhmerov | and we don't really see ways to work around that nicely | 10:09 |
| rakhmerov | kong: I'm back | 10:09 |
| * kong is reading huge commit logs for python-mistralclient | 10:11 | |
| *** gongysh has quit IRC | 10:11 | |
| rakhmerov | :) | 10:11 |
| rakhmerov | ok, I'll be around for the next couple of hours, ping me when it's comfortable | 10:11 |
| openstackgerrit | Merged openstack/python-mistralclient: Changed the README.rst https://review.openstack.org/421098 | 10:26 |
| kong | rakhmerov: from my understanding from the code, the '__actions' defined in env is considered as part of action inputs | 10:34 |
| kong | i don't want to mix that with context | 10:34 |
| kong | it's also the reason i removed 'action_context' from action init method | 10:34 |
| kong | like here: https://review.openstack.org/#/c/414694/4/mistral/actions/std_actions.py | 10:35 |
| kong | it was defined as action input, but apparently users should not pass it | 10:36 |
| kong | context thing should be passed in another way | 10:36 |
| rakhmerov | ddeja: replied | 10:43 |
| rakhmerov | good points | 10:43 |
| rakhmerov | kong: looking.. | 10:44 |
| rakhmerov | kong: ok, I'm thinking... Not sure I understand your point on 100% | 10:45 |
| rakhmerov | so, '__actions' just defines default values for action parameters | 10:47 |
| rakhmerov | so that we don't need to repeat same values over and over again | 10:47 |
| rakhmerov | I don't understand why you are saying that you'd mix them with context? | 10:48 |
| rakhmerov | in any case, there has to be some convention about how you process "openstack_context" no matter where it resides | 10:49 |
| rakhmerov | whether in 'input', 'params' or 'env' | 10:49 |
| kong | rakhmerov: yeah | 10:49 |
| rakhmerov | Mistral engine or actions themselves need to know how to process it | 10:49 |
| kong | for openstack actions, the 'context' thing is not included in action parameters | 10:49 |
| kong | think about nova.find() | 10:49 |
| rakhmerov | wait a sec | 10:50 |
| rakhmerov | how that "action_context" is related to this? | 10:50 |
| rakhmerov | it seems to be a completely different thing to me.. | 10:50 |
| rakhmerov | ok, go on | 10:50 |
| kong | you mean the things i did in https://review.openstack.org/#/c/414694/4/mistral/actions/std_actions.py/ | 10:51 |
| kong | ? | 10:51 |
| rakhmerov | yes | 10:51 |
| rakhmerov | it seems to have nothing to do with OpenStack context | 10:51 |
| rakhmerov | it might though but not necessarily | 10:51 |
| kong | because for get openstack related context, i need a flag to help decide if an action needs 'context' or not | 10:52 |
| kong | so i added a method for Action, support_context() | 10:52 |
| kong | which could replace current positional param 'action_context' | 10:52 |
| rakhmerov | no-no, wait a sec | 10:53 |
| rakhmerov | honestly, I didn't look at the impl patches yet | 10:53 |
| rakhmerov | on purpose | 10:53 |
| rakhmerov | I'd like to understand everything about the spec first | 10:53 |
| kong | but yeah, 'action_context' is a another thing | 10:54 |
| kong | please ignore it for now | 10:54 |
| rakhmerov | ok | 10:54 |
| rakhmerov | btw, I don't really like the idea with "__actions" in 'env', I don't know many people using it | 10:55 |
| rakhmerov | it's not really obvious | 10:55 |
| kong | rakhmerov: from the code logic, it defined some action param values | 10:56 |
| rakhmerov | anyway, again: I think your suggestion with 'params' looks OK, I'm just saying that may be we need to move it to 'env' | 10:56 |
| rakhmerov | yes | 10:57 |
| kong | but 'env' will make me thing of the env entity in mistral | 10:57 |
| kong | make me think | 10:57 |
| rakhmerov | yes | 10:57 |
| rakhmerov | what's the issue with it? | 10:57 |
| rakhmerov | OpenStack context, isn't it a part of environment? | 10:58 |
| kong | env entity is used for specifying some key-value, so they could be used for yaql evaluation | 10:58 |
| rakhmerov | the info about a particular OpenStack instance etc. | 10:58 |
| rakhmerov | yes, via env() | 10:58 |
| kong | but openstack context has nothing to do with yaql evaluation | 10:59 |
| rakhmerov | but I mean, semantically 'env' (accessible as env()) is just an environment | 10:59 |
| rakhmerov | you can pass anything you want, besides using '__actions' | 10:59 |
| rakhmerov | kong: it might have something to do with it, why can't I eval a YAQL/Jinja based on OpenStack context? | 11:00 |
| kong | hmm, make sense | 11:00 |
| *** tuan_ has joined #openstack-mistral | 11:00 | |
| rakhmerov | yeah | 11:00 |
| rakhmerov | from my perspective, it's just one of the things that comes to workflow | 11:01 |
| kong | ok, i think we make a consensus | 11:01 |
| rakhmerov | no matter if it's part of input or env | 11:01 |
| kong | btw, we should document 'params' | 11:01 |
| rakhmerov | it's just semantically I think more correct to perceive it as part of 'env' | 11:01 |
| rakhmerov | kong: yes, my fault | 11:01 |
| rakhmerov | sorry for that | 11:01 |
| kong | it's our fault :-) | 11:02 |
| rakhmerov | I actually hate this "params" thing | 11:02 |
| rakhmerov | I'd like to get rid of it but really don't know how | 11:02 |
| kong | yeah, there will be more and more things inside for various purpose | 11:02 |
| rakhmerov | from the very beginning it's been basically "workflow TYPE" specific params | 11:02 |
| rakhmerov | yeah | 11:02 |
| kong | you can only undersatand it only if you read the code | 11:03 |
| rakhmerov | yes, true | 11:03 |
| rakhmerov | it's now used only for "task_name" of reverse workflow | 11:03 |
| rakhmerov | that's why I'd like to keep its usage as narrow as possible | 11:03 |
| rakhmerov | as far as consensus :) | 11:04 |
| kong | rakhmerov: it's very late for me, nee to get sleep. I will submit a new patchset, and review your global context thing tomorrow. | 11:04 |
| rakhmerov | let's make sure we have it :) | 11:04 |
| rakhmerov | ooh, ok | 11:04 |
| rakhmerov | can I just borrow 2 more mins from you? | 11:04 |
| rakhmerov | if you can | 11:04 |
| kong | sure | 11:04 |
| rakhmerov | just looking at your last comment again.. | 11:04 |
| rakhmerov | with an example | 11:04 |
| rakhmerov | can you please explain again the idea of having "action_context" inside 'env' (was in 'params' but seems like we agreed to change) ? | 11:05 |
| rakhmerov | I mean, how precisely it's supposed to work | 11:05 |
| rakhmerov | and be treated | 11:06 |
| rakhmerov | if you prefer to postpone it till tomorrow it's ok, let me know | 11:06 |
| kong | i still need to add a flag in Action class to tell me if an particular action will need context or not. Obviously, for all openstack actions, they all will need. | 11:07 |
| rakhmerov | I'll try to be available earlier tomorrow | 11:07 |
| kong | if action needs context, mistral will get context thing from workflow params | 11:07 |
| rakhmerov | ok | 11:07 |
| rakhmerov | so, this is like an addition to 'action_context', right? | 11:07 |
| rakhmerov | whatever we put under 'action_context' in 'env' will be added into 'action_context' available for actions, right? | 11:08 |
| rakhmerov | because action_context in actions also has execution id, task execution id etc. | 11:08 |
| rakhmerov | many things | 11:08 |
| rakhmerov | btw, we want to change this whole approach of accessing contextual info in actions | 11:09 |
| rakhmerov | as part of Custom Actions API | 11:09 |
| rakhmerov | but seems like it won't be done too soon | 11:09 |
| kong | yeah, you are right for 'action_context' | 11:10 |
| rakhmerov | ok | 11:10 |
| rakhmerov | good to me | 11:10 |
| kong | i will also change 'action_context' to optional param | 11:10 |
| kong | as i mentioned just now | 11:10 |
| kong | we can discuss it in my implentation | 11:11 |
| rakhmerov | ok, let's focus on the spec and then get to impl | 11:11 |
| rakhmerov | ok may, go to bed :) | 11:11 |
| rakhmerov | thanks for your time | 11:11 |
| rakhmerov | ok man.. | 11:11 |
| kong | rakhmerov :-) | 11:11 |
| kong | rakhmerov: see you | 11:12 |
| rakhmerov | kong: the good thing is that many people want this feature | 11:12 |
| rakhmerov | including me | 11:12 |
| kong | rakhmerov: yeah, including me | 11:12 |
| rakhmerov | that's why we're so picky :) | 11:12 |
| rakhmerov | ok, rest | 11:12 |
| * kong really goes to bed | 11:12 | |
| openstackgerrit | Kupai József proposed openstack/mistral: using utcnow instead of now in expiration policy https://review.openstack.org/421842 | 11:28 |
| tuan_ | Hi guys | 11:38 |
| tuan_ | i have just had a small talk with ddeja about after-failure-recovery feature of mistral when RUNNING workflow is stuck inside db | 11:39 |
| tuan_ | we decided to open this discussion here to have more ideas from you guys | 11:39 |
| tuan_ | in production, it is quite a must-have feature for automated solution | 11:40 |
| tuan_ | do you guys have any ideas about it | 11:40 |
| tuan_ | @Renat, @Kong, @ Dougal | 11:40 |
| d0ugal | tuan_: can you give me more context? | 11:42 |
| tuan_ | yeah sure | 11:42 |
| tuan_ | when we run wf | 11:42 |
| tuan_ | its state will be written in db is RUNNING | 11:42 |
| tuan_ | however, meanwhile it is running, something happens like "MySQL is gone away" | 11:43 |
| tuan_ | then this wf is stuck in RUNNING state | 11:43 |
| tuan_ | when MySQL is back again | 11:43 |
| tuan_ | mistral does not take care about the above stuck wf | 11:43 |
| tuan_ | e.g. re-run stuck wf, update state of it to FAILED, etc. | 11:44 |
| *** dprince has joined #openstack-mistral | 11:45 | |
| tuan_ | you guys please let me go out for a smoke, i will be back in 5 mins | 11:45 |
| tuan_ | :) | 11:45 |
| d0ugal | tuan_: I see, makes sense | 11:47 |
| d0ugal | tuan_: so you want a way to restart workflows after critical failures? | 11:47 |
| ddeja | d0ugal: restart, or automatically put in error | 11:56 |
| ddeja | but not make them stuck as RUNNING | 11:56 |
| d0ugal | Moving to error would probably be safer | 11:56 |
| d0ugal | Maybe we even need a new state? | 11:56 |
| ddeja | I've added topic to etherpad https://etherpad.openstack.org/p/mistral-ptg-pike | 11:56 |
| ddeja | d0ugal: IMO error would be OK | 11:56 |
| ddeja | more problamatic is how to notice that there was a failure | 11:57 |
| d0ugal | Indeed. | 11:57 |
| tuan_ | i would vote for ERROR | 11:57 |
| ddeja | and we should do something with workflows in running state | 11:57 |
| d0ugal | tuan_: agreed, automatic restarting would be dangerous. | 11:57 |
| d0ugal | ddeja: could we check for "RUNNING" workflow during startup? | 11:58 |
| d0ugal | although, that requires mistral to be restarted | 11:58 |
| d0ugal | hm | 11:58 |
| tuan_ | but if we have other RUNNING wf | 11:58 |
| tuan_ | we not sure that which one is stuck | 11:58 |
| d0ugal | Indeed, tricky. | 11:59 |
| tuan_ | well | 12:00 |
| ddeja | well, I guess we should have some kind of file lock | 12:00 |
| tuan_ | since wf does not have heartbeat | 12:00 |
| ddeja | and if service start and this file is there | 12:01 |
| ddeja | it means - it is after recovery start | 12:01 |
| ddeja | to first thing after engine start operating, is to put everything in error state, | 12:01 |
| ddeja | s/after/before | 12:01 |
| ddeja | but it would only work if we have one engine | 12:01 |
| ddeja | for multi-eninge env, it gets even more tricky | 12:02 |
| tuan_ | i am sorry ddeja | 12:02 |
| tuan_ | what do you mean multi-engine? | 12:02 |
| ddeja | we should have file-lock-over-network | 12:02 |
| ddeja | tuan_: If you have mistral running on more then one node | 12:02 |
| ddeja | then you have more then one engine running one more than one node | 12:03 |
| tuan_ | ok ddeja | 12:03 |
| tuan_ | got it | 12:03 |
| ddeja | well, we have service groups in mistral | 12:03 |
| ddeja | so if starting engine check if there is file lock AND if he is the first engine in service group | 12:04 |
| ddeja | then we can safely said that he is the only one | 12:04 |
| ddeja | therefore, there sould be no running worjkflows | 12:04 |
| ddeja | therefore, if anything is in running state, then it should be in error | 12:05 |
| ddeja | and after that operation, we start functioning normally | 12:05 |
| * ddeja should write a blueprint about it... | 12:10 | |
| ddeja | rakhmerov: ^^ thoughts? | 12:10 |
| rakhmerov | ddeja: remember we discussed it with you in Austin? | 12:13 |
| rakhmerov | I can immediately say that doing something on start-up is not easy | 12:14 |
| rakhmerov | gently speaking | 12:14 |
| rakhmerov | even if we use service groups etc. there will be contentions between engine instances | 12:15 |
| rakhmerov | we need some locking anyway across nodes | 12:15 |
| rakhmerov | so, tuan_, we've discussed this many times already and it's part of my personal plan to work on this in mid-term perspective | 12:15 |
| rakhmerov | I guess after the PTG | 12:16 |
| rakhmerov | a relatively simple solution IMO would be a small human intervention | 12:16 |
| tuan_ | okay, but Renat, do we have plan to write BP for it | 12:16 |
| tuan_ | or we have already had it | 12:17 |
| tuan_ | ? | 12:17 |
| rakhmerov | there's a BP | 12:17 |
| rakhmerov | I'm thinking about something called "maintenance mode" | 12:17 |
| rakhmerov | when we could explicitly say "I want to switch Mistral into maintenance mode" | 12:17 |
| rakhmerov | it's the info written in DB | 12:17 |
| rakhmerov | in this mode Mistral doesn't start anything new | 12:17 |
| rakhmerov | neither workflows, nor tasks/actions | 12:18 |
| rakhmerov | then we have a choice to say "I want you to put all RUNNING workflows into ERROR state" | 12:18 |
| rakhmerov | or "I want you to re-run all workflows in RUNNING state from where they were left over" | 12:18 |
| rakhmerov | and possibly other things | 12:19 |
| rakhmerov | so the steps to recover would look like: | 12:19 |
| ddeja | rakhmerov: yes, that is something we discuss in Austin | 12:19 |
| rakhmerov | 1. An infrastructure failure happened | 12:19 |
| rakhmerov | 2. We got to know that | 12:19 |
| rakhmerov | 3. We put Mistral into "maintanence mode" | 12:19 |
| rakhmerov | 4. We restart Mistral components, if needed | 12:20 |
| rakhmerov | 5. We tell Mistral to recover running workflows (one way or another) | 12:20 |
| rakhmerov | 6. We switch Mistral back to normal mode | 12:20 |
| rakhmerov | or we could even make a shortcut to do it automatically | 12:21 |
| tuan_ | sorry guys | 12:21 |
| tuan_ | may i have a stupid question | 12:21 |
| rakhmerov | even two :) | 12:21 |
| tuan_ | when wf is stuck in RUNNING | 12:21 |
| tuan_ | :D | 12:21 |
| rakhmerov | ype | 12:21 |
| rakhmerov | yep | 12:21 |
| tuan_ | because of db lost | 12:21 |
| tuan_ | and then db is back again | 12:21 |
| rakhmerov | yes | 12:21 |
| tuan_ | what will happen with engine | 12:21 |
| tuan_ | does it continue with the tasks in db | 12:22 |
| rakhmerov | at least for short outages Mistral should recover on its own | 12:22 |
| tuan_ | and if all the tasks are run well | 12:22 |
| tuan_ | and the wf will be written as SUCCESS | 12:22 |
| tuan_ | ? | 12:22 |
| rakhmerov | by "recover" I mean that it will re-acquire a connection with DB | 12:22 |
| rakhmerov | nope | 12:22 |
| rakhmerov | I'm talking only about recovering the engine itself | 12:22 |
| rakhmerov | it won't do anything to workflows stuck in whatever states | 12:23 |
| rakhmerov | so, ddeja was right, we need to detect that somehow (shouldn't be hard) | 12:23 |
| tuan_ | okay i understand it | 12:23 |
| rakhmerov | tuan_: so, it's planned to do | 12:24 |
| rakhmerov | we're totally aware that we have a gap here | 12:24 |
| rakhmerov | CBND (Israel team) knows about it and agrees to live with that for now | 12:25 |
| tuan_ | okay, got it | 12:25 |
| rakhmerov | I conventionally call this whole thing "Failover" | 12:25 |
| rakhmerov | it's now really not covered in Mistral | 12:25 |
| rakhmerov | essentially, we need to teach Mistral to deal with infrastructural outages | 12:26 |
| rakhmerov | tuan_, d0ugal, ddeja: https://blueprints.launchpad.net/mistral/+spec/mistral-maintenance-mode | 12:28 |
| *** Ravikiran_K has joined #openstack-mistral | 12:29 | |
| *** shardy is now known as shardy_lunch | 12:29 | |
| tuan_ | let me take a look to this BP | 12:31 |
| tuan_ | and may be i will have more stupid questions later | 12:32 |
| tuan_ | so sorry to bother you guys a lot | 12:32 |
| tuan_ | :( | 12:32 |
| ddeja | rakhmerov: oh, I'm even subscribed to that BP | 12:32 |
| rakhmerov | tuan_: bother us any time please | 12:38 |
| rakhmerov | we like it | 12:38 |
| rakhmerov | we enjoy it :) | 12:38 |
| rakhmerov | ddeja: yes, so. I thought about this BP many times, looking forward to getting it done | 12:39 |
| rakhmerov | and I don't think that technically it's very hard to achieve | 12:39 |
| ddeja | with mainteneco mode, yup, it's not really hard | 12:40 |
| ddeja | but it still needs some maunal steps | 12:40 |
| ddeja | I'm thinking if such functionallity can be fully automated | 12:41 |
| rakhmerov | yes, agree | 12:47 |
| rakhmerov | you know, I believe this could be a good first step towards having a fully automated solution | 12:47 |
| ddeja | yeah, sure | 12:48 |
| rakhmerov | right now, until we get into fighting with this, it's not easy to understand how to achieve it | 12:48 |
| rakhmerov | what kind of surprises we'll have | 12:48 |
| ddeja | yup | 12:48 |
| ddeja | there always some :D | 12:48 |
| rakhmerov | that's why I love this work :) | 12:49 |
| rakhmerov | it's unpredictable ) | 12:49 |
| rakhmerov | ddeja: it'd be so cool if you could go to the PTG | 12:52 |
| rakhmerov | we could discuss all of that stuff with you there | 12:52 |
| rakhmerov | I'm humbly hoping you'll be there :) | 12:52 |
| *** jamielennox is now known as jamielennox|away | 12:59 | |
| ddeja | rakhmerov: yes, I wish I could be there | 13:04 |
| *** bobh has joined #openstack-mistral | 13:05 | |
| openstackgerrit | Sharat Sharma proposed openstack/mistral: Add script for unit test coverage job https://review.openstack.org/417881 | 13:07 |
| *** rbrady is now known as rbrady-mtg | 13:12 | |
| *** jamielennox|away is now known as jamielennox | 13:19 | |
| *** shardy_lunch is now known as shardy | 13:21 | |
| *** bobh has quit IRC | 13:24 | |
| *** sharatss has quit IRC | 13:38 | |
| *** sharatss has joined #openstack-mistral | 13:38 | |
| *** catintheroof has joined #openstack-mistral | 13:45 | |
| *** dprince has quit IRC | 13:52 | |
| *** rbrady-mtg is now known as rbrady | 13:56 | |
| *** tuan_ has quit IRC | 14:25 | |
| *** dprince has joined #openstack-mistral | 14:29 | |
| *** shardy has quit IRC | 14:30 | |
| *** shardy has joined #openstack-mistral | 14:31 | |
| *** gongysh has joined #openstack-mistral | 14:54 | |
| *** bobh has joined #openstack-mistral | 15:01 | |
| *** bobh has quit IRC | 15:01 | |
| *** bobh has joined #openstack-mistral | 15:01 | |
| mfisch | rakhmerov: would like to get back to workbooks since I am here now | 15:04 |
| *** jistr is now known as jistr|mtg | 15:05 | |
| ddeja | mfisch: rakhmerov has 9pm in his timezone, so he may be unavailable ;) | 15:09 |
| mfisch | ah these timezones don't work out very well | 15:10 |
| mfisch | I liked his idea that a workbook could be namespaced since this is for trove | 15:10 |
| mfisch | the workbook was trove.create_backup, but I didnt see a way to make it public via the CLI | 15:10 |
| *** openstack has joined #openstack-mistral | 15:19 | |
| *** rbrady has quit IRC | 15:19 | |
| *** szaher has quit IRC | 15:19 | |
| *** jtomasek has quit IRC | 15:19 | |
| *** kong has quit IRC | 15:19 | |
| mfisch | I dont want to have every person in my cloud to run mistral commands, trove scheduled backup should just work out of the box | 15:19 |
| mfisch | so public and global | 15:19 |
| *** rbrady has joined #openstack-mistral | 15:20 | |
| *** rbrady has quit IRC | 15:20 | |
| *** rbrady has joined #openstack-mistral | 15:20 | |
| ddeja | mfisch: I still don't understand what you'd like to achivie... | 15:21 |
| mfisch | trove has a feature called scheduled backups, which relies on a mistral workbook | 15:21 |
| mfisch | I would like to only call mistral workbook-create one time, for the whole region, to make that feature work | 15:22 |
| mfisch | however when I do that now, the workbook is private to a single tenant | 15:22 |
| *** szaher has joined #openstack-mistral | 15:22 | |
| *** jtomasek has joined #openstack-mistral | 15:22 | |
| ddeja | OK I think I start to understand | 15:23 |
| ddeja | but hm... I'm not sure how to solve it | 15:24 |
| ddeja | the only idea is to run it as admin... | 15:24 |
| mfisch | 2 ways that I know of, public workbooks or trove should switch to using a workflow | 15:24 |
| mfisch | which I've pinged tesora about | 15:24 |
| mfisch | I'll see if I can get someoen from that team to discuss it | 15:25 |
| *** kong has joined #openstack-mistral | 15:26 | |
| ddeja | mfisch: OK, and I'll need some background. On the other hand, I'm not sure if you'd like to start discussion again with me, if you have already discussed it with rakhmerov | 15:29 |
| mfisch | He replied to my after I left, its going to be hard to find an overlap with him | 15:30 |
| mfisch | I'm UTC-7 | 15:30 |
| ddeja | mfisch: well, yeah, it would be hard | 15:34 |
| *** jaosorior has joined #openstack-mistral | 15:41 | |
| ddeja | mfisch: OK, I'm willing to help, but Unfortunatelly I'm in UTC+1, so also not a lot of overlaping time | 15:43 |
| ddeja | and I need to know the full context | 15:44 |
| mfisch | I reached out to some trove folks who are UTC-5, slightly better | 15:44 |
| mfisch | when they get time I'll have them lead the convo | 15:44 |
| mfisch | since I dont have their full context either | 15:44 |
| ddeja | OK | 15:45 |
| ddeja | if it is something more complicated you can always send mail tagging it [mistral], we'll look on it | 15:46 |
| *** jistr|mtg is now known as jistr | 15:51 | |
| *** thrash is now known as thrash|biab | 15:51 | |
| *** thrash|biab is now known as thrash | 16:20 | |
| *** weshay is now known as weshay_afk | 16:21 | |
| *** gongysh has quit IRC | 16:23 | |
| *** weshay_afk is now known as weshay_lunch | 16:39 | |
| *** harlowja has joined #openstack-mistral | 16:39 | |
| *** dougshelley66 has joined #openstack-mistral | 17:06 | |
| *** harlowja has quit IRC | 17:33 | |
| *** rbrady is now known as rbrady-afk | 17:43 | |
| *** catintheroof has quit IRC | 17:44 | |
| *** catintheroof has joined #openstack-mistral | 17:44 | |
| *** catintheroof has quit IRC | 17:44 | |
| *** catintheroof has joined #openstack-mistral | 17:45 | |
| *** catintheroof has quit IRC | 17:50 | |
| *** weshay_lunch is now known as weshay | 17:53 | |
| *** sharatss has quit IRC | 18:00 | |
| *** sharatss has joined #openstack-mistral | 18:00 | |
| *** jpich has quit IRC | 18:01 | |
| *** shardy has quit IRC | 18:15 | |
| *** shardy has joined #openstack-mistral | 18:16 | |
| *** shardy is now known as shardy_afk | 18:52 | |
| *** Ravikiran_K has quit IRC | 19:00 | |
| *** rbrady-afk is now known as rbrady | 19:36 | |
| *** sharatss has quit IRC | 20:18 | |
| *** dturner has quit IRC | 20:27 | |
| kong | mfisch: hi, i start to work, if you still have questions, please don't hesitate to ask | 20:45 |
| mfisch | sure | 20:45 |
| mfisch | I will be at the PTG too I may drop by and say hi | 20:45 |
| kong | not sure i will be there, wait for my luck | 21:12 |
| *** jamielennox is now known as jamielennox|away | 21:26 | |
| *** sharatss has joined #openstack-mistral | 21:44 | |
| *** sharatss has quit IRC | 21:49 | |
| *** dprince has quit IRC | 21:59 | |
| *** jamielennox|away is now known as jamielennox | 22:10 | |
| *** jamielennox is now known as jamielennox|away | 22:24 | |
| *** jaosorior has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!