| *** EinstCra_ has quit IRC | 00:31 | |
| *** reldan has quit IRC | 01:16 | |
| *** daemontool has quit IRC | 04:02 | |
| *** samuelBartel has joined #openstack-freezer | 07:56 | |
| *** reldan has joined #openstack-freezer | 08:51 | |
| vannif | morning | 09:08 |
|---|---|---|
| vannif | yes, I'd really like to. But not before next week. | 09:09 |
| *** reldan has quit IRC | 09:32 | |
| *** reldan has joined #openstack-freezer | 10:09 | |
| slashme | daemontool: Did we take a decision on : python-freezerclient versus integration in python-openstackclient | 10:12 |
| m3m0_ | slashme we should focus on the python-freezerclient first and the integrate it with python-openstackclient, | 10:34 |
| slashme | Perfect | 10:34 |
| m3m0_ | so we can start integrating our on code first | 10:34 |
| slashme | +1 on that | 10:34 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Refactoring of mysql, msserver and mongo code. https://review.openstack.org/280602 | 11:00 |
| *** reldan has quit IRC | 11:11 | |
| *** reldan has joined #openstack-freezer | 12:07 | |
| dmellado | +1 on that | 12:48 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Refactoring of mysql, msserver and mongo code. https://review.openstack.org/280602 | 13:18 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Refactoring of mysql, msserver and mongo code. https://review.openstack.org/280602 | 13:41 |
| *** EinstCrazy has joined #openstack-freezer | 13:42 | |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Refactoring of mysql, msserver and mongo code. https://review.openstack.org/280602 | 14:14 |
| *** EinstCra_ has joined #openstack-freezer | 14:25 | |
| *** EinstCrazy has quit IRC | 14:28 | |
| openstackgerrit | Memo Garcia proposed openstack/freezer-web-ui: Liberty guidelines for freezer web ui https://review.openstack.org/280745 | 14:56 |
| *** EinstCra_ has quit IRC | 15:04 | |
| *** EinstCrazy has joined #openstack-freezer | 15:04 | |
| *** EinstCrazy has quit IRC | 15:12 | |
| *** EinstCrazy has joined #openstack-freezer | 15:14 | |
| *** EinstCrazy has quit IRC | 15:25 | |
| *** EinstCrazy has joined #openstack-freezer | 15:39 | |
| *** dschroeder has joined #openstack-freezer | 16:05 | |
| *** EinstCrazy has quit IRC | 16:15 | |
| *** EinstCrazy has joined #openstack-freezer | 16:16 | |
| *** EinstCrazy has quit IRC | 16:20 | |
| *** jonaspf has joined #openstack-freezer | 16:25 | |
| *** reldan has quit IRC | 16:31 | |
| *** reldan has joined #openstack-freezer | 16:31 | |
| *** reldan has quit IRC | 16:42 | |
| openstackgerrit | Memo Garcia proposed openstack/freezer-web-ui: Actions for a job no longer shows irrelevant actions for specific cases https://review.openstack.org/280811 | 16:43 |
| *** reldan has joined #openstack-freezer | 16:51 | |
| *** reldan has quit IRC | 17:02 | |
| *** reldan has joined #openstack-freezer | 17:07 | |
| *** samuelBartel has quit IRC | 17:13 | |
| *** reldan has quit IRC | 18:00 | |
| slashme | Guy we have a big bug: | 19:08 |
| slashme | When the freezer-scheduler is restarted, it will stop executing scheduled jobs. | 19:08 |
| slashme | It will just output things like 2016-02-16 18:38:17,677 root WARNING Job 799802f09c074545aee04129a56ab7dd already has scheduled status, skipping | 19:09 |
| *** reldan has joined #openstack-freezer | 19:13 | |
| *** daemontool has joined #openstack-freezer | 19:14 | |
| *** daemontool_ has joined #openstack-freezer | 19:17 | |
| *** daemontool has quit IRC | 19:19 | |
| slashme | I think we need to rework the way we manage the scheduling. The solution used by mistral seems smarted. I'll do some checking and I'll explain during the next freezer-meeting. | 19:23 |
| slashme | Bug report : https://bugs.launchpad.net/freezer/+bug/1546269 | 19:28 |
| openstack | Launchpad bug 1546269 in Freezer "When restarted, the freezer-scheduler stops executing scheduled jobs." [Undecided,New] | 19:28 |
| daemontool_ | slashme, ok | 19:29 |
| daemontool_ | slashme, does it require an architectural change? | 19:31 |
| daemontool_ | vannif, any thought? ^^ | 19:33 |
| slashme | I'm not sure it is the solution yet (but I think so). It would require a small data change (adding a field to the scheduling info). Basicaly that solution relies on the usage of a "next_execution_date" field, which is a very simple and reliable scheduling mechanism. | 19:36 |
| daemontool_ | ok | 19:36 |
| vannif | architectural change no. unless we decouple the scheduling from the scheduler :) | 19:37 |
| vannif | I mean. the scheduler now has its own internal execution timers | 19:38 |
| daemontool_ | ok | 19:39 |
| vannif | that is needed for the consistent point in time backups | 19:39 |
| vannif | given that the scheduler have datetime synchronized, of course | 19:40 |
| daemontool_ | vannif, are you working on that bug? | 19:40 |
| vannif | *schedulers | 19:40 |
| vannif | we're still discussing | 19:40 |
| daemontool_ | ah ok | 19:40 |
| vannif | basically, any scheduler has an internal "next execution date" which will trigger the action. at the moment this is managed by the apscheduler | 19:41 |
| slashme | FYI: https://github.com/openstack/mistral/blob/master/mistral/services/periodic.py | 19:42 |
| slashme | https://github.com/openstack/mistral/blob/master/mistral/services/triggers.py | 19:42 |
| vannif | the error comes from the fact that the scheduler and the status of the job are separate. in fact any job should not even bear the status "scheduled". the job is "enable". if it's also scheduled depends if the scheduler is running or not | 19:42 |
| daemontool_ | ok, but that bug is quite critical for job scheduling | 19:43 |
| vannif | what if the scheduler crasches ? the job status in the api will become invalid | 19:43 |
| daemontool_ | would be good to understand why | 19:43 |
| daemontool_ | at the next schedule interval should be executed | 19:44 |
| vannif | that bug is given by the behavior of the scheduler. when it starts, it schedules any job except those in a stop status (or stop request) and those which are already "scheduled" | 19:44 |
| daemontool_ | ok | 19:44 |
| daemontool_ | what happen if that is a recurrent execution? | 19:45 |
| vannif | so. if you have a scheduler running its jobs will be "scheduled". if you stop the scheduler and you start it again, it will ignore all previous jobs because thay are "scheduled" | 19:45 |
| vannif | that would not be a tremendous issue if the jobs could be restarted. I'm investigating if that's possible | 19:45 |
| daemontool_ | do we need to have a scheduling timeout then? | 19:45 |
| vannif | scheduling timeout ? | 19:46 |
| daemontool_ | so the job start | 19:46 |
| daemontool_ | sorry | 19:46 |
| daemontool_ | the scheduler is running | 19:46 |
| daemontool_ | and the jobs are scheduled, but not executed yet | 19:47 |
| daemontool_ | the scheduler crash | 19:47 |
| daemontool_ | will the job status stay in scheduled for ever? | 19:47 |
| vannif | well, how do you set the timeout interval ? the API should investigate the scheduling information. but that doesn't work for "running" jobs, unless you use a "wathdog" strategy: refresh the status of a scheduled/running job often, otherwise its status gets reset | 20:04 |
| daemontool_ | when the status get reset? | 20:06 |
| daemontool_ | is something that is happening now or it was a thought? | 20:06 |
| daemontool_ | it was a thought ok :) | 20:07 |
| daemontool_ | ok | 20:07 |
| daemontool_ | got it | 20:07 |
| vannif | yes :) | 20:07 |
| daemontool_ | so going back to my question? | 20:07 |
| daemontool_ | the status will keep staying in scheduled state for ever? | 20:08 |
| daemontool_ | right now I mean | 20:09 |
| vannif | yes. only the scheduler actively changes it. if the scheduler is dead, the jobs will not change status | 20:09 |
| daemontool_ | two scheduler at the same time on the same node cannot run, right? | 20:10 |
| daemontool_ | so if the current scheduler that is running, is not executing the jobs with status scheduled | 20:12 |
| daemontool_ | for that node | 20:13 |
| daemontool_ | the same scheduler can change the status of that job on the API and/or execute them | 20:14 |
| *** reldan has quit IRC | 20:14 | |
| *** reldan has joined #openstack-freezer | 20:18 | |
| *** daemontool__ has joined #openstack-freezer | 21:17 | |
| *** daemontool_ has quit IRC | 21:20 | |
| *** daemontool has joined #openstack-freezer | 21:38 | |
| *** daemontool__ has quit IRC | 21:42 | |
| *** reldan has quit IRC | 21:54 | |
| *** daemontool has quit IRC | 22:05 | |
| *** daemontool has joined #openstack-freezer | 22:48 | |
| *** DuncanT_ has joined #openstack-freezer | 23:30 | |
| *** m3m0 has joined #openstack-freezer | 23:34 | |
| *** m3m0_ has quit IRC | 23:37 | |
| *** DuncanT has quit IRC | 23:37 | |
| *** DuncanT_ is now known as DuncanT | 23:43 | |
| *** yangyapeng has joined #openstack-freezer | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!