| openstackgerrit | Fabrizio Fresco proposed openstack/freezer: Blueprint specs for DR in freezer https://review.openstack.org/278242 | 00:35 |
|---|---|---|
| *** reldan has quit IRC | 00:37 | |
| *** dschroeder has quit IRC | 00:44 | |
| *** damia_pi has joined #openstack-freezer | 01:11 | |
| *** reldan has joined #openstack-freezer | 01:13 | |
| *** damia_pi has quit IRC | 01:16 | |
| *** reldan has quit IRC | 01:46 | |
| *** damia_pi has joined #openstack-freezer | 01:49 | |
| *** damia_pi has quit IRC | 01:51 | |
| *** daemontool has quit IRC | 02:11 | |
| *** openstackgerrit has quit IRC | 02:15 | |
| *** daemontool has joined #openstack-freezer | 02:23 | |
| *** openstackgerrit has joined #openstack-freezer | 02:24 | |
| *** daemontool has quit IRC | 03:08 | |
| *** openstackgerrit has quit IRC | 08:47 | |
| *** openstackgerrit_ has joined #openstack-freezer | 08:47 | |
| *** openstackgerrit_ is now known as openstackgerrit | 08:48 | |
| *** reldan has joined #openstack-freezer | 08:58 | |
| *** reldan has quit IRC | 09:34 | |
| *** reldan has joined #openstack-freezer | 10:09 | |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix freezer for py3 compatibility https://review.openstack.org/278346 | 10:20 |
| dmellado | hey guys, what's the deal finally with py34 gate? | 10:52 |
| dmellado | it's blocking a couple of patches | 10:52 |
| dmellado | could you merge the fix? | 10:53 |
| reldan | dmellado: There is a lot of changes | 11:01 |
| reldan | dmellado: And I’m not sure that I have fixed everything | 11:02 |
| *** daemontool has joined #openstack-freezer | 11:21 | |
| m3m0_ | daemoontool pong | 11:24 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix freezer for py3 compatibility https://review.openstack.org/278346 | 11:26 |
| *** reldan has quit IRC | 11:46 | |
| openstackgerrit | Memo Garcia proposed openstack/freezer: Add SSL support for freezer https://review.openstack.org/278367 | 11:51 |
| *** reldan has joined #openstack-freezer | 12:05 | |
| *** ig0r_ has joined #openstack-freezer | 12:12 | |
| *** daemontool has quit IRC | 12:39 | |
| *** daemontool has joined #openstack-freezer | 12:40 | |
| openstackgerrit | Pierre Mathieu proposed openstack/freezer: Swift client does not stringify object names anymore on get_object() https://review.openstack.org/279027 | 12:41 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix freezer for py3 compatibility https://review.openstack.org/278346 | 12:42 |
| daemontool | Morning | 12:44 |
| *** daemontool_ has joined #openstack-freezer | 12:49 | |
| *** daemontool__ has joined #openstack-freezer | 12:49 | |
| *** daemontool has quit IRC | 12:51 | |
| daemontool__ | slashme, re: https://review.openstack.org/279027 what do you think if we ask to the swift team why that behaviour changed? | 12:54 |
| *** daemontool_ has quit IRC | 12:54 | |
| daemontool__ | the fix is good, but now we are converting all the blocks from data to str | 12:55 |
| daemontool__ | if we restore hundreds of GB it can have some impact | 12:55 |
| slashme | No we are not | 12:56 |
| slashme | Backup objects have a __repr__ method ! | 12:56 |
| daemontool__ | I think the type os that object before was data | 12:56 |
| daemontool__ | now is str | 12:56 |
| daemontool__ | aren't we converting from data to str? | 12:57 |
| slashme | No | 12:57 |
| daemontool__ | what type is that block before converting to str? | 12:57 |
| slashme | When you call str() on a backup object is calls the __repr__() method of that backup object that returns a string like "<self.hostname_backup_name>_<timestamp>_<level>" | 12:58 |
| slashme | The swift client get_object() method expects a string for the name of the object | 12:59 |
| daemontool__ | ah ok | 12:59 |
| daemontool__ | that's the name of the object we retrieve | 12:59 |
| daemontool__ | ty | 12:59 |
| daemontool__ | sorry | 13:00 |
| slashme | Before 2.7.0 it seems that they were calling str() on anything passed as the object name. Which is not the behaviour anymore. | 13:00 |
| daemontool__ | okok | 13:00 |
| daemontool__ | I wonder if they know that | 13:02 |
| *** Slashme_ has joined #openstack-freezer | 13:16 | |
| *** Slashme_ has quit IRC | 13:22 | |
| *** daemontool__ has quit IRC | 13:23 | |
| *** daemontool__ has joined #openstack-freezer | 13:35 | |
| *** daemontool_ has joined #openstack-freezer | 13:42 | |
| *** daemontool__ has quit IRC | 13:46 | |
| *** daemontool_ is now known as daemontool | 13:56 | |
| daemontool | please add your topics to the meeting agenda https://etherpad.openstack.org/p/freezer_meetings | 13:56 |
| daemontool | remember today the meeting happen at 2 pm UTC | 13:56 |
| daemontool | as per http://eavesdrop.openstack.org/#Freezer_Meeting | 13:56 |
| daemontool | according your GMT TZ the meeting should happen in ~3 min, right? | 13:57 |
| *** ddieterly has joined #openstack-freezer | 13:59 | |
| m3m0_ | yep | 14:00 |
| daemontool | the meeting will start in 2 min, m3m0_ you chair? | 14:02 |
| m3m0_ | let's move to the #openstack-meeting-alt channel please | 14:02 |
| daemontool | yes | 14:02 |
| m3m0_ | frescof_ are you here? | 14:05 |
| daemontool | vannif, szaher_ slashme ping please join the meeting at #openstack-meeting-alt | 14:09 |
| vannif | pong | 14:09 |
| slashme | pong | 14:13 |
| openstackgerrit | Pierre Mathieu proposed openstack/freezer: Swift client does not stringify object names anymore on get_object() https://review.openstack.org/279027 | 14:17 |
| szaher_ | pong | 14:18 |
| openstackgerrit | Eldar Nugaev proposed openstack/freezer: Fix freezer for py3 compatibility https://review.openstack.org/278346 | 14:19 |
| daemontool | frescof_, are you around? | 15:00 |
| daemontool | let's discuss about the DR please, it's a hot topic | 15:02 |
| slashme | First question abut the DR | 15:03 |
| daemontool | can we do 5 minutes break first? | 15:04 |
| daemontool | so we have also frescof_ on this | 15:04 |
| daemontool | and I can go drink something | 15:04 |
| m3m0_ | sure :) | 15:04 |
| daemontool | ty | 15:04 |
| slashme | Is the gerrit change the right place to express disagrement. I think it is, because I have the feeling that when this is merged and part of the specs, then it means we will commit to it. | 15:05 |
| slashme | So for big blueprints like this one, I'd like to see a majority of core agreeing before merging. Because this impacts the globality of the software and its developper. | 15:06 |
| slashme | Definity two persons agreeing is not enough to merge this kind of blueprints. | 15:07 |
| *** fabriziof has joined #openstack-freezer | 15:08 | |
| daemontool | ok I'm here | 15:09 |
| daemontool | slashme, I think gerrit is OK to express disagreements | 15:10 |
| daemontool | slashme, ok, what should it be? | 15:13 |
| daemontool | like 40%? 50%? | 15:13 |
| slashme | I don't know. We need to decide about percentage and if non-core can vote. | 15:14 |
| daemontool | non core can provide feedback | 15:14 |
| slashme | Maybe there is OpenStack Guidelines. | 15:14 |
| daemontool | everybody can vote | 15:14 |
| daemontool | but I think is at least 40% of core agree | 15:14 |
| daemontool | we can do it | 15:14 |
| daemontool | but there's also the balance between community and companies | 15:15 |
| slashme | With a current count of 7 cores, this would mean we need 3 approval to merge a blueprint ? | 15:16 |
| daemontool | I don't know | 15:18 |
| m3m0_ | it's better if we merged if half + 1 agree | 15:18 |
| daemontool | even half | 15:18 |
| daemontool | is ok | 15:18 |
| daemontool | anyway | 15:19 |
| daemontool | let's talk about the issue | 15:19 |
| daemontool | then we see the disagreements | 15:19 |
| slashme | Okay. We should agree on that at some point. I'm not trying to start a war | 15:19 |
| daemontool | ok so let's say we need 4 | 15:20 |
| daemontool | I'd like to understand the disagreements | 15:20 |
| daemontool | what are the issues_ | 15:20 |
| daemontool | ? | 15:20 |
| daemontool | and what are the benefists? | 15:21 |
| *** ig0r_ has quit IRC | 15:21 | |
| slashme | First, let's say the truth. This is not an implementation blueprint. This is a blueprint to merge an internal HP project called Osha into Freezer. | 15:21 |
| daemontool | ok | 15:22 |
| daemontool | so we have the implementation already | 15:22 |
| daemontool | ? | 15:22 |
| fabriziof | hi | 15:22 |
| fabriziof | yes of the goal 1 | 15:22 |
| daemontool | hi fabriziof | 15:22 |
| slashme | Then. There is nothing common about these two projects. | 15:22 |
| daemontool | what is the problem that osha is trying to solve? | 15:23 |
| slashme | VM high availability | 15:23 |
| fabriziof | nope | 15:24 |
| fabriziof | vm high availability is a complete different thing | 15:24 |
| daemontool | just that? | 15:24 |
| szaher_ | guys I think we need to define what freezer is and what is the scope of freezer and then let's see if this bp or Osha is relative or not | 15:24 |
| daemontool | ok | 15:24 |
| fabriziof | radically different | 15:24 |
| m3m0_ | agree szaher_ | 15:24 |
| daemontool | szaher_, I think the freezer scope is well define d at this point | 15:24 |
| szaher_ | if it's relative let's work on it and include it in freezer if not let's just ignore this | 15:24 |
| *** ddieterly has quit IRC | 15:24 | |
| daemontool | we do backup restore and dr in openstack | 15:25 |
| daemontool | that's our scope | 15:25 |
| szaher_ | daemontool I mean let's go back and check not to put one now off-course it's set long time ago :D | 15:25 |
| m3m0_ | for context... https://review.openstack.org/#/c/278242 | 15:25 |
| daemontool | ok | 15:25 |
| daemontool | fabriziof, what are you proposing with that bp in short? | 15:26 |
| epheo | hi there | 15:27 |
| daemontool | Hi epheo :) | 15:27 |
| slashme | My opinion is very simple. I love both projects, but they share not components. | 15:27 |
| epheo | Funny issue btw :) | 15:28 |
| epheo | Usually (99%) people are struggling separating projects not merging them, hahaha | 15:28 |
| daemontool | :) | 15:28 |
| daemontool | from the bp | 15:28 |
| daemontool | I understand | 15:28 |
| daemontool | a dr feature is being proposed | 15:28 |
| daemontool | so the point is, if would be the case to create a new project for that | 15:29 |
| daemontool | or include it in freezer right? | 15:29 |
| fabriziof | imho dr is a wide definition | 15:29 |
| epheo | Yes, what do you call DR ? | 15:29 |
| daemontool | well we have to start y something | 15:29 |
| fabriziof | that can start from loosing 1 physical node | 15:30 |
| daemontool | :) | 15:30 |
| fabriziof | to a rack | 15:30 |
| daemontool | to a dc | 15:30 |
| fabriziof | to a dc | 15:30 |
| daemontool | etc etc | 15:30 |
| fabriziof | or a continent | 15:30 |
| fabriziof | or a planet :) | 15:30 |
| epheo | lost plannet | 15:30 |
| m3m0_ | but the scope of this bp involves lots more of components that: a) the scope is not for freezer b) there are tools that already does that | 15:31 |
| fabriziof | so to start approaching to solve the problem, there are various kind of approaches | 15:31 |
| fabriziof | with different costs and time of restoring the service | 15:32 |
| *** daemontool_ has joined #openstack-freezer | 15:32 | |
| m3m0_ | so make sense to develop a platform that integrate all of those components first rather than putting all in freezer | 15:32 |
| daemontool_ | sorry got disconnected | 15:32 |
| fabriziof | backup/restore is probably the cheapest one | 15:33 |
| daemontool_ | I think, a project in openstack, solve a common set of problems | 15:33 |
| daemontool_ | for what I understand | 15:33 |
| daemontool_ | things like heartbeat | 15:33 |
| fabriziof | but need a long time | 15:33 |
| daemontool_ | ha | 15:33 |
| daemontool_ | and so on | 15:34 |
| daemontool_ | we do not do that | 15:34 |
| slashme | My point is: DR using Backup/restore and DR using what you propose in your blueprint share no common parts. | 15:34 |
| *** daemontool has quit IRC | 15:34 | |
| fabriziof | backup/restore is not usually considered a DR solution | 15:34 |
| slashme | So merging them into the same project does not make sense. | 15:35 |
| daemontool_ | we do need to merge things | 15:35 |
| fabriziof | @slashme you are repeting yourself | 15:35 |
| daemontool_ | we can have the tooling to resolve specific problems | 15:35 |
| fabriziof | we can read | 15:35 |
| fabriziof | and understand at first shot | 15:35 |
| daemontool_ | fabriziof, hang on please | 15:36 |
| daemontool_ | so | 15:36 |
| epheo | But without arguing on what Freezer should or shouldn't do, OpenStack is trying as much as possible to respect KISS | 15:36 |
| epheo | The guys frmo Nova are separating the scheduler | 15:36 |
| epheo | Most of the projects are spliting | 15:36 |
| daemontool_ | epheo, I see that | 15:36 |
| epheo | Make no sense to merge 2 together | 15:36 |
| daemontool_ | look at neutron | 15:36 |
| daemontool_ | project like lbaas | 15:37 |
| fabriziof | osha don't exist | 15:37 |
| daemontool_ | vpnass | 15:37 |
| daemontool_ | etc etc | 15:37 |
| epheo | Even if that make sense on Freezer feature pov | 15:37 |
| daemontool_ | are individual tools | 15:37 |
| epheo | Just my 2cents | 15:37 |
| daemontool_ | to solve specific problems | 15:37 |
| epheo | :) | 15:37 |
| daemontool_ | but under the same project | 15:37 |
| fabriziof | the architecture of what the bp is proposing | 15:37 |
| daemontool_ | because they solve the same common set of issues | 15:37 |
| fabriziof | feet the freezer architecture perfectly | 15:37 |
| fabriziof | feet=fit | 15:38 |
| daemontool_ | my point is that we can have | 15:38 |
| daemontool_ | dedicated tolling | 15:38 |
| daemontool_ | with shared services | 15:38 |
| epheo | Compute HA matching backup restore? (finnaly I have hope finding the loved one :) :) ) | 15:38 |
| daemontool_ | within the same project | 15:39 |
| daemontool_ | and that dedicated tolling | 15:39 |
| slashme | daemontool_: shared services | 15:39 |
| daemontool_ | can have a completely dedicated purpose | 15:39 |
| daemontool_ | yes like shared db, shared api, shared webui | 15:39 |
| daemontool_ | like neutron subprojects | 15:40 |
| fabriziof | shared agent | 15:40 |
| daemontool_ | they are independent tools | 15:40 |
| daemontool_ | shared agent I don't know | 15:41 |
| daemontool_ | probably shared scheduler make more sense | 15:41 |
| daemontool_ | or same python-freezerclient | 15:41 |
| fabriziof | why not ? | 15:41 |
| fabriziof | ah sorry.... used wrong term | 15:41 |
| daemontool_ | what did you mean? | 15:41 |
| daemontool_ | the scheduler? | 15:42 |
| fabriziof | yep | 15:42 |
| daemontool_ | so we can have like a dedicated repo | 15:42 |
| daemontool_ | something like freezer-dr | 15:42 |
| daemontool_ | but one sec | 15:42 |
| daemontool_ | what do you guys think? | 15:42 |
| slashme | Let's see where things would interact | 15:43 |
| slashme | Freezer-web-ui: Okay, that's easy | 15:43 |
| slashme | Then what ? | 15:44 |
| daemontool_ | the api framework I think can eb shared | 15:44 |
| fabriziof | the scheduler is polling over the api, and can send information on the hypervisor | 15:44 |
| fabriziof | almost for free | 15:44 |
| daemontool_ | fabriziof, I think we have to write a dedicated agent for dr | 15:44 |
| daemontool_ | liek freezer-dr-agent | 15:44 |
| daemontool_ | something like that | 15:44 |
| daemontool_ | the scheduler can be reused for sure | 15:45 |
| daemontool_ | is abstracted enough | 15:45 |
| daemontool_ | the api | 15:45 |
| fabriziof | agree 100% on that | 15:45 |
| daemontool_ | would be a dedicated endpoint | 15:45 |
| daemontool_ | called | 15:45 |
| daemontool_ | disaster_recovery | 15:45 |
| daemontool_ | or dr | 15:45 |
| daemontool_ | I don't know | 15:45 |
| daemontool_ | I'm just thinking loud | 15:46 |
| daemontool_ | slashme, what should be the independent components from your point of view? | 15:46 |
| daemontool_ | the agent for sure has nothing to do | 15:46 |
| fabriziof | yep the agent has noting to do | 15:46 |
| slashme | Even the api. What is the point of sharing it if we are not using any common endpoint. | 15:47 |
| daemontool_ | well we share the infrastructure | 15:47 |
| daemontool_ | and framework behind | 15:47 |
| slashme | So do we share infra with keystone and swift | 15:47 |
| daemontool_ | nope because with those services we are not sharing | 15:47 |
| daemontool_ | a common set of problems | 15:47 |
| daemontool_ | but we use the keystonemiddleware | 15:48 |
| daemontool_ | in our api | 15:48 |
| daemontool_ | slashme, so the agent is independent | 15:48 |
| daemontool_ | the repo is independent | 15:49 |
| daemontool_ | the api endpoint is independent | 15:49 |
| daemontool_ | what is shared | 15:49 |
| daemontool_ | the web ui | 15:49 |
| daemontool_ | the api framework | 15:49 |
| daemontool_ | the scheduler | 15:49 |
| daemontool_ | the python-freezerclient | 15:49 |
| daemontool_ | I think over time we'll find more features to share | 15:50 |
| daemontool_ | think about the dr applied to tenants | 15:50 |
| daemontool_ | like dr as a services | 15:50 |
| *** epheo has quit IRC | 15:51 | |
| daemontool_ | it has things in common with the tenant backup we are doing | 15:51 |
| fabriziof | that was my idea | 15:51 |
| daemontool_ | fabriziof, that should be written in the bp | 15:51 |
| daemontool_ | I think | 15:51 |
| daemontool_ | at least for clarity | 15:51 |
| fabriziof | and comparing thhe split proposed for nova, that is a 5 year old project with hundred of developer | 15:52 |
| fabriziof | with freezer that is very young with a very small number of contributor, is wrong | 15:52 |
| slashme | The whole infra of freezer has been though to manage Backup and Restore. Nothing is ready to integrate this kind of completly different fonctionality. | 15:52 |
| slashme | tenant backup is still just a new very complex backup mode. | 15:53 |
| *** epheo_ has joined #openstack-freezer | 15:53 | |
| slashme | Evacuation / Fencing / monitoring / Notification are completly different topics. | 15:53 |
| daemontool_ | well we use the other services api | 15:54 |
| epheo_ | If you need to re-use some code and share classes or fct between both project the correct way of doing it is to have it as a dependency, | 15:54 |
| daemontool_ | we are not going to implement that | 15:54 |
| daemontool_ | epheo_, ++ | 15:54 |
| daemontool_ | as a module dependency | 15:54 |
| daemontool_ | like for impi I think ironic should be used | 15:55 |
| daemontool_ | I think there's a big gap in openstack for this | 15:55 |
| slashme | Don't get me wrong, I think you are both very good engineer, and that szaher_ (who wrote a POC implementing the failover part of that blueprint) is a fantastic dev. It's just that I think this is not in the best interest of the freezer project. | 15:55 |
| fabriziof | ironic should be leveraged, if present | 15:55 |
| fabriziof | as much as possible | 15:56 |
| daemontool_ | slashme, I think we are disagreeing | 15:56 |
| fabriziof | @slashme it's really challenging to not get you wrong | 15:56 |
| daemontool_ | if this is a set of problem we are proposing to solve or not | 15:56 |
| slashme | We will need to complexify the core of freezer (Backup/restore) to much to integrate those new functionnality. | 15:57 |
| daemontool_ | is this is a set of solutinos we provide | 15:58 |
| daemontool_ | then the implementation is just a way to achieve the goal | 15:58 |
| daemontool_ | slashme, I think | 15:58 |
| daemontool_ | we have a separate repo | 15:58 |
| daemontool_ | separate agent | 15:58 |
| fabriziof | I thinks those features should be in a separate module | 15:58 |
| daemontool_ | a and a dedicated api endpoint within our framework | 15:58 |
| daemontool_ | things can go in parallel | 15:58 |
| fabriziof | that get loaded if enabled | 15:58 |
| daemontool_ | at least to start | 15:58 |
| daemontool_ | then if at some point | 15:59 |
| daemontool_ | the dr thing | 15:59 |
| daemontool_ | became to big | 15:59 |
| daemontool_ | we can split | 15:59 |
| fabriziof | adding very little if not no complexity at all to actual code | 15:59 |
| daemontool_ | but there are benefits | 15:59 |
| daemontool_ | fabriziof, does hp would allocate some resources for this? | 15:59 |
| *** Felips has joined #openstack-freezer | 16:00 | |
| fabriziof | yes, I got the foundings | 16:00 |
| daemontool_ | fundings :) | 16:00 |
| fabriziof | yes sorry, the $$ | 16:01 |
| daemontool_ | well if a company allcoate resources, there's an opportunity | 16:01 |
| daemontool_ | slashme, epheo_ what would be the conditions | 16:01 |
| daemontool_ | from you to have this working? | 16:01 |
| openstackgerrit | Memo Garcia proposed openstack/freezer: Add SSL support for freezer https://review.openstack.org/278367 | 16:01 |
| daemontool_ | or no conditions at all it is not possible at all? | 16:02 |
| *** epheo has joined #openstack-freezer | 16:02 | |
| daemontool_ | I can't read nothing | 16:08 |
| slashme | Just curious here: what would be the interactions with the API ? | 16:08 |
| slashme | What kind of data would the new agent share with the new endpoints of the API ? | 16:08 |
| *** epheo has quit IRC | 16:09 | |
| fabriziof | the status of the hypervisor | 16:09 |
| daemontool_ | fabriziof, explain that a bit more please | 16:09 |
| fabriziof | the scheduler can gather easily the status of kvm/libvirt on the hypervisor | 16:10 |
| daemontool_ | fabriziof, shouldn't we get that from the nova api? | 16:10 |
| fabriziof | and even take actions in front of a specific action (like the freezer jobs for backup) | 16:10 |
| *** epheo has joined #openstack-freezer | 16:11 | |
| daemontool_ | I think the whole scheme of the job scheduler can eb reused | 16:11 |
| fabriziof | nova depends on rabbit, for example | 16:11 |
| daemontool_ | that's a shared service | 16:11 |
| daemontool_ | that's one reason why they splitted | 16:11 |
| fabriziof | and we want do reduce the false positives as much as possible | 16:11 |
| daemontool_ | slashme, epheo do you want to think about it couple of days more to set your conditions to minimize the risks you see on this? | 16:12 |
| fabriziof | but we should leverage nova as much as possible anyway | 16:12 |
| daemontool_ | is that reasonable? | 16:12 |
| fabriziof | the workflow of the "monitoring" part, should be: nova, freezer-scheduler, third party monitoring tools (ex. monasca) | 16:13 |
| epheo | fabriziof: You know my opinion about leveraging nova for something as critical as instance lifcycle | 16:14 |
| epheo | Or monasca/nagios/etc (but this is a separate topic) | 16:14 |
| slashme | In the end, I'll accept any decision, as long as the persons that are going to have to develop this kind of bp are involved in the decision process. | 16:14 |
| daemontool_ | epheo, that is good | 16:14 |
| fabriziof | epheo: yes, but I still don't agree | 16:14 |
| daemontool_ | I think with that consideration we can make the solution more resiliant | 16:15 |
| daemontool_ | slashme, appreciate a lot that, I'd like also that we clearly say the issues we see | 16:15 |
| daemontool_ | so we can address them | 16:15 |
| *** dschroeder has joined #openstack-freezer | 16:16 | |
| *** epheo_ has quit IRC | 16:16 | |
| fabriziof | epheo: but I respect your opinion, and I'm still open to change my mind | 16:16 |
| daemontool_ | if you guys share your thoughts, we can | 16:16 |
| daemontool_ | provide our inputs | 16:16 |
| daemontool_ | otherwise is difficult | 16:16 |
| daemontool_ | to what you disagree fabriziof and epheo ? | 16:17 |
| fabriziof | nova is the core component of OS, and we are doing OS native things | 16:17 |
| fabriziof | leveraging as much as possible what OS provide | 16:17 |
| daemontool_ | so epheo says we should go directly on the hypervisor without the api? | 16:18 |
| daemontool_ | the nova api I mean? | 16:18 |
| daemontool_ | or what? | 16:18 |
| fabriziof | sayd that, if nova is not perfect, it's not a good enough justification to not using that | 16:18 |
| daemontool_ | fabriziof, I agree with that, but we need to find a mechanism | 16:18 |
| daemontool_ | that works even is nova is not available | 16:18 |
| daemontool_ | that's always is our primary purpose | 16:19 |
| daemontool_ | so we could fall back and talk directly to the hypervisor | 16:19 |
| daemontool_ | if the nova api are not avail | 16:19 |
| daemontool_ | or keystone | 16:19 |
| daemontool_ | something like that? | 16:19 |
| fabriziof | daemontool_: it's what I sayd before, use more mechanism to decrease nova glitches | 16:19 |
| epheo | daemontool_: My opinion is just that Nova isn't (and will most probably never be) relevent enough to provide decision on instance lifecycle. It return close to random values regarding the compute state. | 16:19 |
| epheo | Monitoring tools as Monasca can be a bit better but that still mean that the life and death of our instance depends on the status of the monitoring tool. | 16:19 |
| daemontool_ | epheo, well yes, I agree | 16:20 |
| daemontool_ | we need to use those services tho | 16:20 |
| daemontool_ | at least at first instance | 16:20 |
| daemontool_ | then fall back to more direct method | 16:20 |
| daemontool_ | is that fails | 16:20 |
| daemontool_ | and open bugs to the services | 16:20 |
| daemontool_ | if we see inconsistent things | 16:20 |
| daemontool_ | epheo, so you say the | 16:21 |
| daemontool_ | dr mechanism | 16:21 |
| daemontool_ | wouldn't be reliable | 16:21 |
| daemontool_ | because of the unreliability of nova and monasca basically | 16:21 |
| epheo | IMHO we should assume that the compute is down by default until it prove the opposite. A way of doing it can be to have a couple of (idealy kernel level) checks that write in a watchdog directly in the compute. If it don't we migrate, Osha API will ensure the fencing to stay coherent and proceed to the evacuate | 16:22 |
| epheo | Relying on any other (outside) component may or may not be relevent. The problem beiing that we can't know for sure | 16:23 |
| daemontool_ | fabriziof, don't you agree with that as complementary approach also? | 16:23 |
| fabriziof | epheo: that would have a hardware requirement | 16:24 |
| daemontool_ | well let's deep think how to do it | 16:24 |
| fabriziof | so, imho, this should be one of the "monitoring" method | 16:24 |
| daemontool_ | I think epheo point is reasonable | 16:24 |
| fabriziof | not the only one | 16:24 |
| fabriziof | as I always shared with epheo | 16:24 |
| daemontool_ | how do we ensure the information retrieved from the api are consistent | 16:24 |
| daemontool_ | ok | 16:25 |
| daemontool_ | fabriziof, please also add that to the bp | 16:25 |
| daemontool_ | as potential issue | 16:25 |
| epheo | fabriziof: totally agree, if customer are ok to rely on their monitoring tools we should be able to do it as well | 16:25 |
| daemontool_ | and possible solution | 16:25 |
| fabriziof | same thing is ipmi, it's hardware requirement, and my proposal is to be as independent as possible from requirements | 16:26 |
| daemontool_ | slashme, from your comment I've read before, I understand the dev needs to be actively involved in the solution definition | 16:26 |
| epheo | Hopefully szaher_ didi a very good job and the whole architecture of Osha is modular | 16:26 |
| daemontool_ | as far as I can understand, in freezer we work with that model, but if that is not true, please remark it | 16:26 |
| daemontool_ | slashme, ^^ | 16:26 |
| slashme | It has always been the case, I not saying anything like that. | 16:27 |
| daemontool_ | ok, I'm saying it because I believe on it | 16:27 |
| * fabriziof too | 16:28 | |
| daemontool_ | so, fabriziof we need to define the limits between the the backup and the dr | 16:28 |
| daemontool_ | fromthis conversation | 16:28 |
| daemontool_ | writing down to the bp the shared and independent components | 16:29 |
| slashme | Trying to get a view on how the architecture would look like: | 16:29 |
| slashme | - A shared freezer-ui with two tabs: "backup/restore" and "datacenter HA" | 16:29 |
| slashme | - A shared freezer-api with diffent set of endpoints | 16:29 |
| slashme | - A shared db to store different kind of informations | 16:29 |
| slashme | - A shared scheduler | 16:29 |
| slashme | - Different agents being called by that scheduler. | 16:29 |
| slashme | That new agent would take care of the new functionnalities: Evacuation, Fencing, Monitoring, Notification. | 16:29 |
| slashme | Taking into account that the freezer-scheduler and freezer-api couple is just a JSON exchange machine. | 16:30 |
| fabriziof | wait slashme | 16:30 |
| fabriziof | you mean that: Evacuation, Fencing, Monitoring, Notification | 16:31 |
| fabriziof | should be done in the "client" side ? | 16:31 |
| daemontool_ | I think that should be done by the dr-agent | 16:32 |
| daemontool_ | when you can place it where you want | 16:32 |
| slashme | Yup | 16:32 |
| daemontool_ | s/when/then/ | 16:32 |
| daemontool_ | client site please forget it confuse people in respect the python-freezerclient | 16:32 |
| fabriziof | ok, let's say where the scheduler is | 16:33 |
| slashme | The scheduler is just used to : dialog with the api / execute agents | 16:34 |
| slashme | It does not take actions on its own | 16:34 |
| daemontool_ | ++ | 16:34 |
| fabriziof | I sayd: where the scheduler is | 16:35 |
| fabriziof | not: in the scheduler | 16:35 |
| daemontool_ | ok so we agree basically | 16:35 |
| daemontool_ | ? | 16:35 |
| fabriziof | dunno | 16:35 |
| daemontool_ | I think so | 16:35 |
| fabriziof | I think that those actions should be taken where the api are | 16:36 |
| daemontool_ | fabriziof, do you want that the dr-agent talk with the other than freezer services api? or you want the scheduler to do that? | 16:36 |
| daemontool_ | I think the dr-agent should do it | 16:36 |
| daemontool_ | and the dr-agent is executed by the scheduler | 16:36 |
| daemontool_ | did I got it well? | 16:37 |
| slashme | API DON'T TAKE ACTIONS | 16:37 |
| epheo | But still, what's the benefit of having only one project to achieve this goal ? | 16:37 |
| epheo | This isn't the Linux way... And we're already leveraging oslo and os.common as shared lib. | 16:37 |
| epheo | Keep It Simple Stupid is the only way to have readable / easy to contribute / and maintainable software. | 16:37 |
| fabriziof | ok, we are speaking different languages | 16:37 |
| fabriziof | <fabriziof> I think that those actions should be taken where the api are | 16:38 |
| epheo | Look at Nero for example, dead because of too much functionalities. In people mind freezer = backup. I believe we should have something else for DR | 16:38 |
| daemontool_ | fabriziof, I think the dr-agent should be placed anyware | 16:38 |
| daemontool_ | not necessarly on the api node | 16:38 |
| fabriziof | daemontool_: agree | 16:38 |
| daemontool_ | it should be node indepentent as long it can communicate with the api | 16:38 |
| daemontool_ | slashme, was it that what you were saying previously? | 16:39 |
| fabriziof | but I don't agree on having that where the scheduler is | 16:39 |
| daemontool_ | ok so that isn't | 16:39 |
| daemontool_ | I got it wrong | 16:39 |
| fabriziof | because we are evaquating failed nodes | 16:39 |
| fabriziof | and I dunno how a node can evacuate himself after a failure :( | 16:39 |
| daemontool_ | ok | 16:39 |
| * fabriziof is feeling stupid | 16:39 | |
| daemontool_ | but the dr-agent is executed by the freezer-scheduler, right? | 16:40 |
| fabriziof | yes | 16:40 |
| daemontool_ | ok | 16:40 |
| daemontool_ | ok | 16:41 |
| fabriziof | but that agent, as I sayd before, can be useful to take actions | 16:41 |
| fabriziof | not that is the place where to execute the evacuation or the fencing | 16:41 |
| fabriziof | for example | 16:41 |
| fabriziof | but your opinion is appreciated | 16:42 |
| daemontool_ | fabriziof, shouldn't be that distributed? | 16:43 |
| fabriziof | I can be wrong | 16:43 |
| daemontool_ | like one scheduler and one dr-agent per compute node? | 16:43 |
| fabriziof | yes | 16:43 |
| daemontool_ | for compute service | 16:43 |
| fabriziof | yes | 16:43 |
| daemontool_ | so if we loose a compute node | 16:43 |
| daemontool_ | we have the others | 16:43 |
| daemontool_ | then we need to manage concurrency | 16:43 |
| slashme | So one scheduler and one dr-agent per compute node for the monitoring side | 16:43 |
| daemontool_ | but I think we can manage that using the freezer-api | 16:44 |
| daemontool_ | and that is for compute service, | 16:44 |
| fabriziof | slashme: yep, let's say one of the monitoring piece | 16:44 |
| daemontool_ | same apply for block storage service | 16:44 |
| slashme | Then one scheduler and one dr-agent per api for migrations/fencing/notification ? | 16:44 |
| fabriziof | slashme: yep | 16:44 |
| fabriziof | hmmmmmm | 16:44 |
| fabriziof | yep | 16:45 |
| epheo | I like the idea of the agent on the compute :) Only itself can really know what's going on. | 16:45 |
| fabriziof | epheo: ++ | 16:45 |
| daemontool_ | why the scheduler/dr-agent also per api? | 16:45 |
| daemontool_ | only on the compute nodes wouldn't be enough? | 16:45 |
| daemontool_ | doing monitoring/migra/fencing//notification | 16:46 |
| daemontool_ | ? | 16:46 |
| fabriziof | that's one of the reasons the architecture I thought fit very well with the freezer one | 16:46 |
| slashme | Compute nodes can't be used to trigger migrations/fencing/notification | 16:46 |
| epheo | Then we have the problem fabriziof explain, if it's dead it will not be able to evacuate | 16:46 |
| slashme | They would't have network access to the right resourses | 16:46 |
| daemontool_ | nope | 16:46 |
| daemontool_ | because we have the other dr-agent | 16:46 |
| daemontool_ | on the compute nodes | 16:46 |
| fabriziof | slashme: ++ | 16:46 |
| epheo | And that's why we need to assume that its dead, until the agent proove otherwise | 16:46 |
| fabriziof | this is the kind of conversation I like | 16:46 |
| fabriziof | costructive | 16:46 |
| daemontool_ | so | 16:47 |
| daemontool_ | the scheduler/dr-agent | 16:47 |
| daemontool_ | monitor only the compute node | 16:47 |
| daemontool_ | where is running | 16:47 |
| daemontool_ | and not also the others? | 16:47 |
| fabriziof | go on guys | 16:47 |
| daemontool_ | I have to go to eat | 16:47 |
| daemontool_ | in 5 min | 16:47 |
| daemontool_ | ok | 16:48 |
| daemontool_ | have to go, fabrizio please the only thing make sure | 16:48 |
| daemontool_ | all the perspectives are reported in the bp please | 16:48 |
| daemontool_ | with issues and possible solutions | 16:48 |
| fabriziof | once that bp is approved, or close too | 16:49 |
| daemontool_ | nope, | 16:49 |
| daemontool_ | this is part of the bp | 16:49 |
| fabriziof | we can work togather on an architectural detailed design | 16:49 |
| daemontool_ | this is | 16:49 |
| daemontool_ | the architectural detailed design | 16:49 |
| daemontool_ | part of that bp | 16:49 |
| daemontool_ | let's do it know | 16:49 |
| daemontool_ | then let's share with the community | 16:50 |
| daemontool_ | get the feedback | 16:50 |
| daemontool_ | merge, start with the implementation | 16:50 |
| fabriziof | I think that that part deserve a dedicated bp | 16:50 |
| daemontool_ | why? | 16:50 |
| daemontool_ | let's do evrything now | 16:50 |
| fabriziof | because it's complex enough | 16:50 |
| daemontool_ | why do we need to have 2 bp | 16:50 |
| fabriziof | because I think we need more than 2 :) | 16:50 |
| daemontool_ | we just need to add | 16:51 |
| daemontool_ | this considerations | 16:51 |
| daemontool_ | from this meeting | 16:51 |
| daemontool_ | to that bp | 16:51 |
| daemontool_ | ask for feedback and start with the implementation | 16:51 |
| fabriziof | o,, if you think so | 16:51 |
| daemontool_ | then we split | 16:51 |
| daemontool_ | many commits in gerrit | 16:51 |
| fabriziof | s/,,/k/ | 16:51 |
| slashme | Even if I'm participating, I'm still against the whole idea for the same reason as before (there is no usefull re-usage of the freezer infra). Maybe we will merge this, but that will be against my will. | 16:51 |
| daemontool_ | slashme, even following the scheme that you reported before? | 16:52 |
| daemontool_ | set the limits | 16:52 |
| slashme | Yes. Because I still think it does not make sense. | 16:52 |
| slashme | This is an opensource project. I'm just expressing my opinion. | 16:53 |
| daemontool_ | sure | 16:53 |
| daemontool_ | :) | 16:53 |
| daemontool_ | have to go for food | 16:53 |
| daemontool_ | later | 16:53 |
| daemontool_ | please find an agreement | 16:53 |
| slashme | Bon appetit. See you later | 16:53 |
| fabriziof | brb need some smoke | 16:53 |
| epheo | same | 16:55 |
| *** daemontool_ has quit IRC | 16:57 | |
| *** samuelBartel has joined #openstack-freezer | 17:01 | |
| fabriziof | slashme: it's not very clear why you say: there is no usefull re-usage of the freezer infra | 17:18 |
| fabriziof | since we reuse most of the actual freezer infra | 17:18 |
| *** samuelBartel has quit IRC | 17:33 | |
| epheo | fabriziof: Because if the goal is to re-use an API / Agent / Scheduler architecture... all the OpenStack projects should merge into one. | 17:37 |
| epheo | But which make sense is a common shared lib (oslo). | 17:37 |
| m3m0_ | daemontool_ https://blueprints.launchpad.net/freezer/+spec/last-poll-date-from-scheduler | 17:51 |
| fabriziof | epheo: ok but then we need to remove DR from freezer | 17:59 |
| fabriziof | because backup/restore is not DR | 17:59 |
| fabriziof | at all | 17:59 |
| fabriziof | if we want to do DR, imho, that one is a great way of doing it | 18:00 |
| fabriziof | same thing can be: | 18:01 |
| fabriziof | file backup | 18:01 |
| fabriziof | cinder backup | 18:01 |
| fabriziof | nova backup | 18:01 |
| fabriziof | let's start splitting freezer that way so | 18:01 |
| fabriziof | because those have REALLY nothing in common | 18:02 |
| fabriziof | they don't even need an angent | 18:03 |
| m3m0_ | we can change the labeling in the UI to be Backup and Restore rather than DR | 18:08 |
| fabriziof | ok | 18:09 |
| fabriziof | and split freezer | 18:09 |
| *** EmilDi_ has quit IRC | 18:18 | |
| epheo | Or "Backup and Restore and Disaster Recovery and Compute High Availability" :) (I should stop jokking before you kill me) | 18:22 |
| *** reldan has quit IRC | 18:30 | |
| *** daemontool has joined #openstack-freezer | 18:54 | |
| *** reldan has joined #openstack-freezer | 18:59 | |
| daemontool | reldan, how are we doing with https://review.openstack.org/#/c/278346/ ? | 19:12 |
| reldan | daemontool: i have fixed a lot of staff - I hope it will be ready tomorrow | 19:14 |
| daemontool | I can keep working on it today | 19:15 |
| daemontool | here is just 14:45 | 19:15 |
| daemontool | tomorrow is the last day for m3 release | 19:15 |
| daemontool | reldan, is it ok if I'll keep working on it? | 19:25 |
| reldan | daemontool: yes sure! | 19:25 |
| daemontool | ok ty | 19:25 |
| reldan | I will be glad ) | 19:25 |
| daemontool | please be my guest! haha | 19:26 |
| daemontool | ok | 19:26 |
| *** fabriziof has quit IRC | 19:35 | |
| daemontool | reldan, | 19:57 |
| daemontool | are you there? | 19:57 |
| daemontool | I think to solve the issue we need to move all the functional tests in a dedicated directory | 19:58 |
| daemontool | the integration tests does not work if we do not have a devstack instance running | 19:58 |
| daemontool | those are the tests to execute with devstack | 19:59 |
| reldan | daemontool: I don’t know actually. But it should pass a bigger part of tests now | 19:59 |
| daemontool | ok | 20:00 |
| daemontool | if you remove the integration directory | 20:00 |
| reldan | if you have time you can try to fix these tests https://review.openstack.org/#/c/278346/10/tests/test_scheduler_daemon.py | 20:00 |
| daemontool | everything works correctly | 20:00 |
| daemontool | vannif, | 20:00 |
| daemontool | ping | 20:00 |
| daemontool | afaik vannif did the integration tests | 20:00 |
| reldan | and these https://review.openstack.org/#/c/278346/10/tests/test_lvm.py | 20:00 |
| daemontool | assuming a devstack instance was there | 20:00 |
| daemontool | if I remove the tests/integration dir | 20:00 |
| daemontool | nothing fails from your current patchset | 20:01 |
| daemontool | it works | 20:01 |
| reldan | great! | 20:01 |
| reldan | we can remove test/integration for now | 20:01 |
| reldan | and I will fix it tomorrow | 20:01 |
| reldan | just to unblock other commits | 20:02 |
| daemontool | yes | 20:04 |
| daemontool | I'm doing some tests | 20:04 |
| daemontool | and upload a new patchset | 20:04 |
| reldan | deal! | 20:06 |
| *** daemontool_ has joined #openstack-freezer | 20:53 | |
| *** daemontool has quit IRC | 20:55 | |
| daemontool_ | reldan, ping | 21:33 |
| daemontool_ | I'm doing something like this | 21:33 |
| daemontool_ | https://github.com/openstack/python-novaclient/blob/master/tox.ini | 21:33 |
| daemontool_ | with a directory tree like this | 21:33 |
| daemontool_ | https://github.com/openstack/python-novaclient/tree/master/novaclient/tests | 21:34 |
| daemontool_ | but if I use that settings | 21:34 |
| daemontool_ | out tests are not execute | 21:34 |
| daemontool_ | executed | 21:34 |
| daemontool_ | with tox | 21:34 |
| daemontool_ | but they are execute with python setup.py testr --coverage | 21:34 |
| daemontool_ | ah, I think I've solved | 21:35 |
| daemontool_ | yep... | 21:42 |
| openstackgerrit | Fausto Marzi proposed openstack/freezer: Fix freezer for py3 compatibility https://review.openstack.org/278346 | 21:52 |
| *** daemontool_ has quit IRC | 21:56 | |
| *** daemontool has joined #openstack-freezer | 22:34 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!