| *** raulduke has joined #openstack-trove | 00:05 | |
| *** amytron has joined #openstack-trove | 00:05 | |
| *** matsuhashi has joined #openstack-trove | 00:18 | |
| *** ramashri has joined #openstack-trove | 00:21 | |
| *** eguz has quit IRC | 00:28 | |
| openstackgerrit | A change was merged to openstack/trove: Pop instead of get for timeout kwarg https://review.openstack.org/80677 | 00:36 |
|---|---|---|
| *** eghobo has joined #openstack-trove | 00:39 | |
| *** eghobo has quit IRC | 00:39 | |
| *** demorris has joined #openstack-trove | 00:57 | |
| *** jcru has joined #openstack-trove | 01:03 | |
| *** jcru has quit IRC | 01:03 | |
| *** demorris has quit IRC | 01:17 | |
| *** nosnos has joined #openstack-trove | 01:30 | |
| *** michael-yu has joined #openstack-trove | 01:35 | |
| *** michael-yu has quit IRC | 02:00 | |
| *** michael-yu has joined #openstack-trove | 02:00 | |
| *** michael-yu has quit IRC | 02:20 | |
| *** michael-yu has joined #openstack-trove | 02:26 | |
| *** chandan_kumar has joined #openstack-trove | 02:29 | |
| *** michael-yu has quit IRC | 02:41 | |
| *** matsuhashi has quit IRC | 02:47 | |
| *** robertmyers has joined #openstack-trove | 02:54 | |
| *** coolsvap has joined #openstack-trove | 02:56 | |
| *** michael-yu has joined #openstack-trove | 02:57 | |
| *** achampion has joined #openstack-trove | 02:59 | |
| *** robertmyers has quit IRC | 02:59 | |
| *** achampio1 has quit IRC | 03:01 | |
| *** nosnos has quit IRC | 03:02 | |
| *** matsuhashi has joined #openstack-trove | 03:04 | |
| *** achampio1 has joined #openstack-trove | 03:05 | |
| *** achampion has quit IRC | 03:06 | |
| *** michael-yu has quit IRC | 03:08 | |
| *** eghobo has joined #openstack-trove | 03:15 | |
| *** nosnos has joined #openstack-trove | 03:20 | |
| *** matsuhashi has quit IRC | 03:29 | |
| *** chandan_kumar has joined #openstack-trove | 03:30 | |
| *** haomai___ has quit IRC | 03:30 | |
| *** chandan_kumar has quit IRC | 03:31 | |
| *** chandan_kumar has joined #openstack-trove | 03:31 | |
| *** chandan_kumar has quit IRC | 03:48 | |
| *** eghobo has quit IRC | 03:49 | |
| *** eghobo has joined #openstack-trove | 03:49 | |
| *** nosnos has quit IRC | 03:51 | |
| *** chandan_kumar has joined #openstack-trove | 04:08 | |
| *** michael-yu has joined #openstack-trove | 04:27 | |
| *** michael-yu has quit IRC | 04:28 | |
| *** michael-yu has joined #openstack-trove | 04:31 | |
| *** michael-yu has quit IRC | 04:32 | |
| *** eghobo has quit IRC | 04:38 | |
| *** eghobo has joined #openstack-trove | 04:39 | |
| *** michael-yu has joined #openstack-trove | 04:48 | |
| *** eguz has joined #openstack-trove | 04:50 | |
| *** eghobo has quit IRC | 04:50 | |
| *** michael-yu has quit IRC | 04:51 | |
| *** michael-yu has joined #openstack-trove | 04:53 | |
| *** michael-yu has quit IRC | 04:53 | |
| *** shivam has joined #openstack-trove | 04:54 | |
| *** michael-yu has joined #openstack-trove | 05:02 | |
| *** chandan_kumar has quit IRC | 05:02 | |
| *** michael-yu has quit IRC | 05:06 | |
| *** saju_m has joined #openstack-trove | 05:13 | |
| *** chandan_kumar has joined #openstack-trove | 05:27 | |
| *** lifeless has quit IRC | 05:30 | |
| openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Partially implements guest agent upgrade strategy https://review.openstack.org/85225 | 05:30 |
| *** lifeless has joined #openstack-trove | 05:31 | |
| *** michael-yu has joined #openstack-trove | 05:39 | |
| *** michael-yu has quit IRC | 05:40 | |
| *** amytron has quit IRC | 06:04 | |
| *** michael-yu has joined #openstack-trove | 06:04 | |
| *** michael-yu has quit IRC | 06:10 | |
| *** michael-yu has joined #openstack-trove | 06:23 | |
| openstackgerrit | Jenkins proposed a change to openstack/trove: Imported Translations from Transifex https://review.openstack.org/82721 | 06:24 |
| *** michael-yu has quit IRC | 06:24 | |
| *** michael-yu has joined #openstack-trove | 06:30 | |
| *** rwsu has joined #openstack-trove | 06:35 | |
| *** saju_m has quit IRC | 06:41 | |
| *** saju_m has joined #openstack-trove | 06:54 | |
| *** michael-yu has quit IRC | 06:56 | |
| *** michael-yu has joined #openstack-trove | 07:01 | |
| *** chandan_kumar has quit IRC | 07:02 | |
| *** michael-yu has quit IRC | 07:14 | |
| *** michael-yu has joined #openstack-trove | 07:15 | |
| *** michael-yu has quit IRC | 07:19 | |
| *** eguz has quit IRC | 07:22 | |
| *** sgotliv has joined #openstack-trove | 08:32 | |
| *** matsuhashi has joined #openstack-trove | 08:35 | |
| *** nosnos has joined #openstack-trove | 08:40 | |
| *** dmitryme has joined #openstack-trove | 08:43 | |
| sgotliv | dmakogon_, ping | 08:45 |
| *** dmakogon_ is now known as denis_makogon | 08:57 | |
| denis_makogon | sgotliv, 'sup | 08:57 |
| *** SnowDust has joined #openstack-trove | 09:17 | |
| *** saju_m has quit IRC | 09:27 | |
| *** SnowDust has quit IRC | 09:56 | |
| *** dmitryme has quit IRC | 10:03 | |
| *** raulduke has quit IRC | 10:03 | |
| *** SnowDust has joined #openstack-trove | 10:08 | |
| *** matsuhashi has quit IRC | 10:16 | |
| *** matsuhashi has joined #openstack-trove | 10:16 | |
| *** matsuhashi has quit IRC | 10:20 | |
| *** IvanZ has joined #openstack-trove | 10:27 | |
| *** coolsvap has quit IRC | 10:27 | |
| openstackgerrit | shivam shukla proposed a change to openstack/trove: Tests for heat based instance workflow https://review.openstack.org/66499 | 10:29 |
| *** saju_m has joined #openstack-trove | 10:32 | |
| *** saju_m has quit IRC | 10:49 | |
| *** dmitryme has joined #openstack-trove | 11:19 | |
| *** saju_m has joined #openstack-trove | 11:24 | |
| *** matsuhashi has joined #openstack-trove | 11:26 | |
| *** matsuhashi has quit IRC | 11:49 | |
| *** matsuhashi has joined #openstack-trove | 11:50 | |
| *** matsuhas_ has joined #openstack-trove | 11:53 | |
| *** matsuhashi has quit IRC | 11:54 | |
| *** nosnos has quit IRC | 11:59 | |
| *** demorris has joined #openstack-trove | 12:06 | |
| *** dmitryme has quit IRC | 12:07 | |
| *** pdmars has joined #openstack-trove | 12:10 | |
| *** pdmars has quit IRC | 12:10 | |
| *** pdmars has joined #openstack-trove | 12:11 | |
| *** zigo has quit IRC | 12:26 | |
| *** achampio1 has quit IRC | 12:27 | |
| *** demorris has quit IRC | 12:35 | |
| *** SnowDust has quit IRC | 12:39 | |
| *** dmitryme has joined #openstack-trove | 12:41 | |
| openstackgerrit | Sergey Gotliv proposed a change to openstack/trove: Make --repo-path an optional argument for db_recreate https://review.openstack.org/85700 | 12:47 |
| *** IvanZ_ has joined #openstack-trove | 12:54 | |
| *** IvanZ has quit IRC | 12:55 | |
| *** sgotliv has quit IRC | 12:57 | |
| *** IvanZ_ has quit IRC | 12:58 | |
| *** IvanZ has joined #openstack-trove | 12:59 | |
| *** freyes_ has joined #openstack-trove | 13:02 | |
| *** IvanZ has quit IRC | 13:04 | |
| *** radez_g0` is now known as radez | 13:05 | |
| *** IvanZ has joined #openstack-trove | 13:05 | |
| *** sgotliv has joined #openstack-trove | 13:06 | |
| *** rustlebee is now known as russellb | 13:08 | |
| *** sgotliv has quit IRC | 13:12 | |
| *** sgotliv has joined #openstack-trove | 13:12 | |
| *** grapex has joined #openstack-trove | 13:15 | |
| *** grapex has quit IRC | 13:16 | |
| *** grapex has joined #openstack-trove | 13:17 | |
| *** achampion has joined #openstack-trove | 13:22 | |
| *** freyes_ has quit IRC | 13:25 | |
| *** matsuhas_ has quit IRC | 13:27 | |
| *** dmitryme has quit IRC | 13:27 | |
| *** matsuhashi has joined #openstack-trove | 13:28 | |
| *** matsuhas_ has joined #openstack-trove | 13:31 | |
| *** matsuhashi has quit IRC | 13:32 | |
| *** kevinconway has joined #openstack-trove | 13:32 | |
| *** jcru has joined #openstack-trove | 13:33 | |
| *** matsuhas_ has quit IRC | 13:34 | |
| *** Barker has joined #openstack-trove | 13:41 | |
| *** demorris has joined #openstack-trove | 13:50 | |
| *** pdmars has quit IRC | 14:16 | |
| *** pdmars has joined #openstack-trove | 14:17 | |
| *** pdmars has quit IRC | 14:17 | |
| *** pdmars has joined #openstack-trove | 14:18 | |
| *** pdmars has quit IRC | 14:20 | |
| *** pdmars has joined #openstack-trove | 14:21 | |
| *** pdmars has quit IRC | 14:22 | |
| *** jasonb365 has joined #openstack-trove | 14:22 | |
| *** pdmars has joined #openstack-trove | 14:22 | |
| *** shivamshukla has joined #openstack-trove | 14:28 | |
| *** amytron has joined #openstack-trove | 14:32 | |
| *** mattgriffin has joined #openstack-trove | 14:32 | |
| *** iccha has joined #openstack-trove | 14:44 | |
| *** jmontemayor has joined #openstack-trove | 14:45 | |
| *** saju_m has quit IRC | 14:50 | |
| *** robertmyers has joined #openstack-trove | 14:52 | |
| *** shivamshukla has quit IRC | 14:55 | |
| *** demorris has quit IRC | 15:00 | |
| *** sbfox has joined #openstack-trove | 15:01 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/trove: Remove dependencies on pep8, pyflakes and flake8 https://review.openstack.org/67138 | 15:03 |
| *** jasonb365 has quit IRC | 15:03 | |
| *** thedodd has joined #openstack-trove | 15:05 | |
| *** ramashri has quit IRC | 15:19 | |
| *** mattgriffin has quit IRC | 15:19 | |
| *** mattgriffin has joined #openstack-trove | 15:19 | |
| *** shivamshukla has joined #openstack-trove | 15:27 | |
| *** pdmars has quit IRC | 15:29 | |
| *** pdmars has joined #openstack-trove | 15:29 | |
| *** demorris has joined #openstack-trove | 15:31 | |
| *** pdmars has quit IRC | 15:32 | |
| *** pdmars has joined #openstack-trove | 15:32 | |
| *** pdmars has quit IRC | 15:33 | |
| *** pdmars has joined #openstack-trove | 15:33 | |
| *** pdmars has quit IRC | 15:34 | |
| *** pdmars has joined #openstack-trove | 15:35 | |
| *** pdmars has quit IRC | 15:35 | |
| *** pdmars has joined #openstack-trove | 15:36 | |
| *** pdmars has quit IRC | 15:37 | |
| *** pdmars has joined #openstack-trove | 15:37 | |
| *** pdmars has quit IRC | 15:38 | |
| *** pdmars has joined #openstack-trove | 15:39 | |
| *** pdmars has quit IRC | 15:40 | |
| *** pdmars has joined #openstack-trove | 15:41 | |
| *** pdmars has quit IRC | 15:41 | |
| *** pdmars has joined #openstack-trove | 15:42 | |
| *** pdmars has quit IRC | 15:42 | |
| *** shivamshukla has quit IRC | 15:43 | |
| *** shivamshukla has joined #openstack-trove | 15:43 | |
| *** pdmars has joined #openstack-trove | 15:43 | |
| *** shivamshukla has quit IRC | 15:48 | |
| *** michael-yu has joined #openstack-trove | 15:49 | |
| sgotliv | denis_makogon, ping | 15:53 |
| *** ramashri has joined #openstack-trove | 15:53 | |
| *** eghobo has joined #openstack-trove | 15:54 | |
| *** sgotliv has quit IRC | 16:00 | |
| *** demorris has quit IRC | 16:04 | |
| *** ramashri_ has joined #openstack-trove | 16:06 | |
| *** ramashri has quit IRC | 16:06 | |
| *** demorris has joined #openstack-trove | 16:07 | |
| *** jmontemayor_ has joined #openstack-trove | 16:11 | |
| *** jmontemayor has quit IRC | 16:11 | |
| *** jmontemayor_ has quit IRC | 16:12 | |
| *** saju_m has joined #openstack-trove | 16:12 | |
| *** jmontemayor has joined #openstack-trove | 16:12 | |
| *** michael-yu has quit IRC | 16:22 | |
| *** zigo has joined #openstack-trove | 16:28 | |
| *** robertmyers has quit IRC | 16:29 | |
| *** dmitryme has joined #openstack-trove | 16:29 | |
| *** sbfox has quit IRC | 16:31 | |
| *** robertmyers has joined #openstack-trove | 16:32 | |
| *** zigo has quit IRC | 16:33 | |
| *** zigo has joined #openstack-trove | 16:34 | |
| *** saju_m has quit IRC | 16:35 | |
| *** zigo has quit IRC | 16:41 | |
| *** grapex has quit IRC | 16:43 | |
| *** demorris has quit IRC | 16:43 | |
| *** grapex has joined #openstack-trove | 16:43 | |
| *** demorris has joined #openstack-trove | 16:44 | |
| *** denis_makogon_ has joined #openstack-trove | 16:45 | |
| *** zigo has joined #openstack-trove | 16:46 | |
| *** sbfox has joined #openstack-trove | 16:47 | |
| *** sbfox has quit IRC | 16:47 | |
| *** denis_makogon has quit IRC | 16:47 | |
| *** denis_makogon_ is now known as denis_makogon | 16:47 | |
| *** sbfox has joined #openstack-trove | 16:47 | |
| *** dmakogon_ has joined #openstack-trove | 16:47 | |
| *** IvanZ_ has joined #openstack-trove | 16:49 | |
| *** ViswaV has joined #openstack-trove | 16:49 | |
| *** IvanZ has quit IRC | 16:49 | |
| *** IvanZ_ is now known as IvanZ | 16:49 | |
| denis_makogon | SlickNik, ping | 16:49 |
| *** yidclare has joined #openstack-trove | 16:52 | |
| *** michael-yu has joined #openstack-trove | 16:53 | |
| *** harlowja has joined #openstack-trove | 16:56 | |
| *** jmontemayor has quit IRC | 16:58 | |
| *** shivamshukla has joined #openstack-trove | 17:05 | |
| SlickNik | denis_makogon: what's up? | 17:08 |
| *** amcrn has joined #openstack-trove | 17:13 | |
| *** IvanZ has quit IRC | 17:17 | |
| *** sbfox has quit IRC | 17:20 | |
| *** demorris has quit IRC | 17:23 | |
| SlickNik | Just a reminder that we're planning on having the blue-print meeting in about 25 minutes. | 17:32 |
| SlickNik | Agenda: https://wiki.openstack.org/wiki/Meetings/TroveMeeting | 17:32 |
| *** sbfox has joined #openstack-trove | 17:33 | |
| *** yogesh has joined #openstack-trove | 17:33 | |
| SlickNik | denis_makogon: ping | 17:37 |
| SlickNik | https://bugs.launchpad.net/trove/+bug/1302787 | 17:37 |
| denis_makogon | SlickNik, i saw this bug and mark it as New, because there's no such type as Wishlist | 17:38 |
| SlickNik | Let's not mark something someone's working on from "In Progress" to "New". | 17:39 |
| denis_makogon | done, status reverted | 17:40 |
| SlickNik | That could give the wrong impression, and we'd be stepping on each other's toes. | 17:40 |
| SlickNik | Thanks! | 17:40 |
| SlickNik | Also, imho it really is a bug. We are part of OpenStack, and we should try and align with other projects as much as we can. | 17:42 |
| SlickNik | Whether it's the install, testing framework, docs or client. | 17:42 |
| denis_makogon | don't know, 'cuz there's no standards for the shell ouptuts, probably, yet | 17:43 |
| denis_makogon | pretty table is the only required requirement | 17:45 |
| *** sbfox has quit IRC | 17:46 | |
| SlickNik | I don't think that's the only requirement. Our old client used prettytable, but as part of our graduation we had to do a rewrite to better align with other OpenStack clients. (for. example, the way we did things like token management was different, and we needed to fix this as part of the client re-write). | 17:47 |
| *** freyes_ has joined #openstack-trove | 17:49 | |
| denis_makogon | i still think this is the part of the wishlist, and not the _real_ bug, i guess such change deserves the BP instead of the bug-report, and should be discussed with other projects | 17:51 |
| denis_makogon | i do believe that not the all clients do what nova does | 17:52 |
| *** radez is now known as radez_g0n3 | 17:54 | |
| *** Barker has quit IRC | 17:54 | |
| *** Barker has joined #openstack-trove | 17:56 | |
| SlickNik | denis_makogon: If that's the case; it's probably more tactful to have a quick IRC conversation with peterstac to point out that different clients do things differently. | 17:58 |
| *** Barker has quit IRC | 17:59 | |
| denis_makogon | SlickNik, we can do that after meeting | 17:59 |
| SlickNik | Let's get this bp meeting started. | 17:59 |
| denis_makogon | o/ | 17:59 |
| peterstac | denis_makogon: Sure, however most CLI's have a 'similar' format (if not exactly the same), which I thought we should emulate | 18:00 |
| peterstac | denis_makogon: But I'm open to discussing it | 18:01 |
| denis_makogon | peterstac, of course, i think we could start from the writing the policy for such cases, like oslo bp for API-clients | 18:01 |
| *** saurabhs has joined #openstack-trove | 18:01 | |
| SlickNik | Let's give folks a couple of mins to show up. | 18:01 |
| denis_makogon | peterstac, if you planning to do this for all clients, i'm up for that | 18:01 |
| grapex | o/ | 18:02 |
| esmute | o/ | 18:02 |
| denis_makogon | SlickNik, you're on charge, commander Kirk | 18:02 |
| cp16net | i'm lurking | 18:03 |
| SlickNik | hub_cap will be MIA today; amcrn / vipul around? | 18:03 |
| amcrn | SlickNik: alive | 18:04 |
| grapex | SlickNik: senoritas | 18:04 |
| kevinconway | hub_cap: joined a band? ba-dum-ch | 18:04 |
| SlickNik | #link https://blueprints.launchpad.net/trove/+spec/point-in-time-recovery | 18:04 |
| grapex | lol, I just realized that looks the same as the Spanish word | 18:04 |
| denis_makogon | it's mine | 18:04 |
| grapex | I mean he has "senioritis" | 18:04 |
| denis_makogon | grapex, same =) | 18:05 |
| SlickNik | Oh, that makes so much more sense now. | 18:05 |
| SlickNik | (senioritis) | 18:05 |
| denis_makogon | can i speak ? | 18:05 |
| SlickNik | go for it | 18:06 |
| SlickNik | Your bp, your floor. | 18:06 |
| denis_makogon | the justification: user should be able to perform recovery process when he wants it, without provisioning new instance with given restore reference | 18:06 |
| denis_makogon | benefits: applying the backup at already running instance, without provisioning new (and hurting users quotas) | 18:07 |
| denis_makogon | i made some reseach and proposed this feature with name "point in time recovery" | 18:08 |
| SlickNik | So denis_makogon my concern with this is that it really isn't implementing "Point in Time" recovery. | 18:08 |
| *** shivam_ has joined #openstack-trove | 18:08 | |
| cp16net | thats what i was thinking as well SlickNik | 18:08 |
| denis_makogon | please suggest the appropriate name | 18:08 |
| robertmyers | Also does this destroy all the data on the instance? | 18:09 |
| grapex | SlickNik: Seconded- normally Point in Time recovery means you can restore a database to how it was at some given exact point in time in the past | 18:09 |
| denis_makogon | i'm open for discussion | 18:09 |
| grapex | robertmyers: That's my second concern | 18:09 |
| SlickNik | This is more like restore a backup to a currently running instance. | 18:09 |
| grapex | I think this may be dangerous | 18:09 |
| robertmyers | what happens on a failure to restore? | 18:09 |
| robertmyers | dead instance? | 18:09 |
| denis_makogon | robertmyers, yes | 18:09 |
| robertmyers | boo | 18:09 |
| grapex | robertmyers: You better hope the original backup worked. :) | 18:09 |
| cp16net | those are the 2 big questions i see as well when i read over this | 18:09 |
| kevinconway | under what circumstances would you need to restore in place versus restore in new instance? | 18:10 |
| grapex | denis_makogon: What if we instead did this feature by creating a new Trove instance, restoring, and then only on success deleting the old one and switching out the DNS name or ip address? | 18:10 |
| robertmyers | denis_makogon: That is the reason we made restores go to a new instance | 18:10 |
| cp16net | but it seems like it would not if you were starting this running instance over from scratch if you even tried to restore the data from the backup | 18:10 |
| robertmyers | customers don't like their data deleted | 18:10 |
| amcrn | kevinconway: the only scenario i can think of is if you've done poor capacity planning and have no "new" instances of the flavor you desire (which is an awful reason to justify this behavior) | 18:11 |
| denis_makogon | robertmyers, if you are restoring some data you expect that it's gonna be totally replaced | 18:11 |
| kevinconway | amcrn: if you are restoring, doesn't that imply something is broken in the current instance | 18:11 |
| kevinconway | why not delete it and free up the space? | 18:11 |
| amcrn | kevinconway: don't know, was trying to cook up a hypothetical, i agree with you. | 18:12 |
| robertmyers | denis_makogon: I get that but an api shouldn't fail in a destroyed state | 18:12 |
| *** demorris has joined #openstack-trove | 18:12 | |
| robertmyers | it needs to be safe | 18:12 |
| *** shivamshukla has quit IRC | 18:12 | |
| denis_makogon | robertmyers, i agree | 18:12 |
| robertmyers | restore to a new volume or disk | 18:12 |
| denis_makogon | robertmyers, the flow for your case looks like, we backuping the actual data and apply the backup to instance, if recovering gone failed, we revert the change | 18:13 |
| robertmyers | maybe, but what if they don't have enought disk space? | 18:13 |
| denis_makogon | robertmyers, volumes and their backuping is totally different feature | 18:14 |
| robertmyers | I'm just talking about the data | 18:14 |
| robertmyers | forget volumes | 18:14 |
| denis_makogon | robertmyers, we could add checks, if FS fits to backup | 18:14 |
| robertmyers | this is the reason we setup restores on a new instance only | 18:15 |
| denis_makogon | if it has enough space for it | 18:15 |
| robertmyers | the customer can delete after it works | 18:15 |
| robertmyers | it is too complicated | 18:15 |
| denis_makogon | i could add the validation of API layer | 18:15 |
| denis_makogon | it seems not | 18:15 |
| cp16net | its the cloud its meant to be "thrown" away right? | 18:15 |
| robertmyers | but it is complicated | 18:15 |
| robertmyers | plus you introduce two apis to restore | 18:16 |
| robertmyers | that is confusing | 18:16 |
| denis_makogon | the bottlenecks: size of FS and size of backup | 18:16 |
| denis_makogon | robertmyers, actually not | 18:16 |
| denis_makogon | robertmyers, recovery is not the restore | 18:16 |
| robertmyers | denis_makogon: how so? | 18:16 |
| robertmyers | that is two | 18:16 |
| denis_makogon | one already exists | 18:16 |
| robertmyers | just a different name | 18:16 |
| robertmyers | same thing | 18:17 |
| cp16net | maybe its just a different type of restore? | 18:17 |
| denis_makogon | they have different flow | 18:17 |
| denis_makogon | cp16net, yes | 18:17 |
| robertmyers | denis_makogon: I get that, but it is doing the same thing in the end | 18:17 |
| cp16net | like we have different types of backups | 18:17 |
| robertmyers | so that is two ways to restore | 18:17 |
| robertmyers | from the API | 18:17 |
| SlickNik | denis_makogon: let me put it this way. What scenario does this enable, that you wouldn't already be able to do with restoring to a new instance? | 18:18 |
| cp16net | the only difference in the end is the instance that the restore happens on | 18:18 |
| robertmyers | so now we'd have to support 2 restore methods for every datastore | 18:18 |
| denis_makogon | robertmyers, but proposed by me, doesn't expects to create new VM | 18:18 |
| amcrn | +1 to SlickNik's question | 18:18 |
| robertmyers | denis_makogon: that is a technicallity | 18:18 |
| denis_makogon | SlickNik, this feature allows to apply backup to already running instance | 18:19 |
| robertmyers | we still have to maintain two different code paths | 18:19 |
| esmute | if it is to not impact custoers' quota, i think it is far easier to tell them to up their quota... you get more money from them too :-) | 18:19 |
| esp | I like grapex’s earlier thought regarding switching dns name / floating ip on the current restore | 18:19 |
| amcrn | denis_makogon: he's asking what the benefit of recovering to an existing instance is (as compared to a new instance) in a cloud environment? | 18:19 |
| SlickNik | denis_makogon: I get the trees; trying to understand the forest. | 18:19 |
| grapex | esp: I like my idea too. :) Though even that will be very complicated and so far the benefits don't seem to be worth the cost. | 18:19 |
| esp | I think we got that to work well, the end result would want the bp is trying to do | 18:19 |
| denis_makogon | amcrn, gives an ability to avoid quotas | 18:20 |
| *** khyati_ has joined #openstack-trove | 18:20 | |
| robertmyers | denis_makogon: I don't know if that justifies all the extra code | 18:20 |
| robertmyers | and the confusion of two apis | 18:20 |
| grapex | robertmyers: +1 | 18:20 |
| SlickNik | denis_makogon: delete current (bad) instance; restore to new instance. Where is the quota issue? | 18:20 |
| amcrn | a quota is elastic, it can be temporarily increased for a tenant given the circumstances | 18:21 |
| amcrn | SlickNik: you might want to keep the instance around for remediation/introspection | 18:21 |
| esp | amcrn: +1 I always think that too, but then get shot down :) | 18:21 |
| SlickNik | amcrn: Sure, but if you restored on top of it, you wouldn't have it running either. | 18:21 |
| denis_makogon | robertmyers, billing is one of the cases, suppose i had one server and several backup of it, i want to restore it to yesterday's backup, and i am not able to do restoring, because it envolves the quotas usage, i don't want to see down-times] | 18:22 |
| robertmyers | why are the quotas set so low that this is a huge problem? | 18:22 |
| cp16net | amcrn: yeah you would want to keep it around especially if it breaks for some reason | 18:22 |
| amcrn | i think you're misunderstanding what i meant by "keep it around" | 18:22 |
| amcrn | i meant that there's a window between having it known by OpenStack and the operator taking it out of the plane | 18:22 |
| robertmyers | denis_makogon: how small are your quotas? | 18:22 |
| denis_makogon | robertmyers, public cloud, you bought cheep account | 18:22 |
| robertmyers | 2 instances | 18:22 |
| robertmyers | your fault | 18:23 |
| robertmyers | not the api | 18:23 |
| SlickNik | So the way I see it, this bp has points to address: | 18:23 |
| SlickNik | - For something to be "point in time" recovery, you should be able to recover to any point in time (with reasonable limits on granularity). This doesn't enable that. | 18:23 |
| SlickNik | - This currently doesn't enable anything new over restoring to a new instance (and additionally has the issue that we may overwrite valid data by mistake, making it dangerous). | 18:23 |
| denis_makogon | robertmyers, this is not the good point of view to feature, same can be told about the replication, it's your fault, that you had not automated scripts that create replicate set | 18:24 |
| amcrn | +1 SlickNik | 18:24 |
| robertmyers | denis_makogon: I'm just saying we can't code to fix an issue for a small subset of users | 18:24 |
| robertmyers | if you are unwilling to pay for more you need to think about how you are using the service | 18:25 |
| SlickNik | Okay, let's move on to the next bp | 18:26 |
| SlickNik | Data volume snapshot [denis_makogon] | 18:26 |
| SlickNik | #link https://blueprints.launchpad.net/trove/+spec/volume-snapshot | 18:26 |
| openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Partially implements guest agent upgrade strategy https://review.openstack.org/85225 | 18:27 |
| esp | ^ sorry :) | 18:27 |
| denis_makogon | SlickNik, according to Trove wiki pages, this feature was discussed when backups came | 18:27 |
| denis_makogon | basically it's another way to do backups, avoiding versioning, datastore-affection | 18:28 |
| *** sgotliv has joined #openstack-trove | 18:28 | |
| SlickNik | denis_makogon: Yes, the issue we faced at that point was that you could not ensure that your mysql backup data was consistent if you just made a volume snapshot. | 18:28 |
| denis_makogon | but it doesn't fits to current backup implementation | 18:28 |
| robertmyers | denis_makogon: how does this not fit in the current backup implementation? | 18:29 |
| *** sgotliv_ has joined #openstack-trove | 18:29 | |
| robertmyers | it seems like it could just be a different runner | 18:30 |
| denis_makogon | robertmyers, backups are based upon strategies, which lives at guest vm | 18:30 |
| robertmyers | instead of a command it runs cinder snapshot | 18:30 |
| amcrn | +1 robertmyers | 18:30 |
| denis_makogon | robertmyers, volume backuping cannot be performed at guest side | 18:30 |
| robertmyers | why not? | 18:30 |
| robertmyers | we use the swift api on the guest | 18:31 |
| cp16net | the guest knows how to connect to swift to push the data | 18:31 |
| robertmyers | the cinder api should work | 18:31 |
| denis_makogon | so, its valid to do that ? | 18:31 |
| cp16net | its the same tokens right? | 18:31 |
| robertmyers | sure | 18:31 |
| denis_makogon | so, that's look easier, i guess | 18:31 |
| robertmyers | I would at least try it first | 18:31 |
| amcrn | denis_makogon: plus it blends better with the capabilities feature | 18:31 |
| denis_makogon | amcrn, agreed | 18:32 |
| cp16net | amrith: true because deployers may not want to support that | 18:32 |
| dougshelley66 | what about SlickNik's question about consistency? | 18:32 |
| robertmyers | the guest is going to need to stop the db first | 18:32 |
| peterstac | But that doesn't address what SlickNik said - it wouldn't guarantee database consistency | 18:32 |
| robertmyers | then do snapshow | 18:32 |
| peterstac | ah, that would work | 18:32 |
| robertmyers | snapshot | 18:32 |
| robertmyers | put the db in readonly mode | 18:32 |
| *** radez_g0n3 is now known as radez | 18:33 | |
| denis_makogon | first flush the data in the memory to hard drive, then snapshot the volume | 18:33 |
| robertmyers | then re-enable writes after the dump | 18:33 |
| robertmyers | yup | 18:33 |
| denis_makogon | robertmyers, correct | 18:33 |
| robertmyers | that is basically what percona extrabackup does | 18:33 |
| SlickNik | yes, r/o mode / stopped db would solve the consistency issues. | 18:33 |
| denis_makogon | nice =) | 18:34 |
| robertmyers | it is the only safe way to do a snapshot | 18:34 |
| dougshelley66 | ok | 18:34 |
| denis_makogon | so, i think consistency question is closed, i suppose | 18:34 |
| SlickNik | Another thing I'm worried about with the bp is API bloat. | 18:34 |
| grapex | SlickNik: +1 | 18:34 |
| denis_makogon | SlickNik, API will be skipped | 18:34 |
| robertmyers | just a new backup type? | 18:35 |
| denis_makogon | yes | 18:35 |
| robertmyers | +1 | 18:35 |
| denis_makogon | and only | 18:35 |
| robertmyers | only one? | 18:35 |
| grapex | I think it should use the existing backup API, though it is a bit different since the database will be shut off | 18:35 |
| denis_makogon | it looks more easier and doesn't pollutes the API routes | 18:35 |
| SlickNik | okay, denis_makogon can you take this feedback and update the BP? | 18:35 |
| *** jmontemayor has joined #openstack-trove | 18:35 | |
| denis_makogon | SlickNik, of course | 18:35 |
| denis_makogon | SlickNik, can i start the implementation ? | 18:36 |
| SlickNik | denis_makogon: That's up to you, but I wouldn't start it until the bp is approved design is finalized. | 18:36 |
| denis_makogon | SlickNik, get it | 18:37 |
| SlickNik | Let's move on. | 18:37 |
| denis_makogon | #action re-write the BP | 18:37 |
| SlickNik | So there are 2 related bps next | 18:37 |
| SlickNik | Networking [denis_makogon] | 18:38 |
| SlickNik | Neutron Network Support [annashen] | 18:38 |
| denis_makogon | #link https://blueprints.launchpad.net/trove/+spec/network-manager-spec | 18:38 |
| SlickNik | #link https://blueprints.launchpad.net/trove/+spec/neutron-support | 18:38 |
| denis_makogon | mine BP describes the need of the network manager class, since we have to ways to manage network attributes | 18:39 |
| denis_makogon | like SGs, floating IPs | 18:39 |
| denis_makogon | now we have flow based upon nova-network | 18:39 |
| *** sbfox has joined #openstack-trove | 18:40 | |
| denis_makogon | i suggest to re-write it to be more flexible | 18:40 |
| SlickNik | Yes, denis_makogon I don't think the second one can be done without a network manager interface. | 18:40 |
| SlickNik | So to me it seems overlapping. | 18:40 |
| denis_makogon | implementation will cover the nova-network flow | 18:40 |
| denis_makogon | SlickNik, annashen_ will take the neutron stuff | 18:41 |
| SlickNik | denis_makogon: Did you get a chance to connect with annashen_ about it? | 18:41 |
| denis_makogon | SlickNik, my BP describes the actual sub-task of the annashen_ BP | 18:41 |
| denis_makogon | SlickNik, unfortunately, no, but i do belive that we can co-work over that | 18:41 |
| denis_makogon | SlickNik, mine implementation will come asap | 18:42 |
| denis_makogon | SlickNik, after, of course, BP gets approved | 18:42 |
| annashen_ | denis: i would like to sync with you sometime before wed | 18:42 |
| annashen_ | wendesday | 18:42 |
| annashen_ | dn* | 18:43 |
| SlickNik | If it's a sub-task, I'm confused why there are 2 separate bps. | 18:43 |
| annashen_ | excuse my typo | 18:43 |
| denis_makogon | annashen_, lets first our BPs get's approved | 18:43 |
| denis_makogon | SlickNik, because they can be done in parallel | 18:43 |
| robertmyers | well, it still could be one BP and multiple reviews | 18:43 |
| cp16net | yeah it seems like its 1 feature in the end | 18:43 |
| robertmyers | dependent review | 18:44 |
| robertmyers | cause the first just splits it up into the ability to use both | 18:44 |
| SlickNik | It feels like the neutron changes are dependent on the network manager interface; | 18:44 |
| robertmyers | then the second implements it | 18:44 |
| SlickNik | I don't think they can be done in parallel. | 18:44 |
| SlickNik | (well to a certain extent) | 18:45 |
| grapex | SlickNik: I agree- I'd almost rather implement network manager first, then make it possible to use both later | 18:45 |
| grapex | it may,possibly, take longer, but there's a higher chance we'll avoid bugs | 18:45 |
| robertmyers | grapex: +1 | 18:45 |
| grapex | since the initial work will just focus on one implementation (with a mind for the future) | 18:45 |
| denis_makogon | SlickNik, if network integface can be proposed and merged soon, tasks could be done in parallel | 18:45 |
| peterstac | I don't think it would take longer, since we still need to support nova-networking | 18:46 |
| grapex | SlickNik: After thinking about it for a bit, I'd like to change my "I'd almost rather" to "we should really, really, really" in the statement above | 18:46 |
| denis_makogon | peterstac, and we would support in for like two more releases from the point when nova-network dropped | 18:46 |
| SlickNik | denis_makogon: What would the network manager look like? | 18:47 |
| SlickNik | denis_makogon: How would it support netron and nova-networking? | 18:47 |
| denis_makogon | SlickNik, abstract class with methods that required by current flow | 18:47 |
| SlickNik | denis_makogon: This page seems light on the details https://wiki.openstack.org/wiki/Trove/NetworkAttributesManagement | 18:47 |
| juice | denis_makagon: I would drop attributes from the description | 18:48 |
| juice | this is really the network manager for Trove | 18:49 |
| denis_makogon | juice, of course | 18:49 |
| juice | slicknik: agreed - it would be nice to know what the interface for the network manager would like like | 18:49 |
| juice | and the underlying purpose of the api | 18:49 |
| denis_makogon | juice, it would look like java interface, nothing else | 18:50 |
| robertmyers | java? | 18:50 |
| denis_makogon | robertmyers, as the example | 18:50 |
| juice | denis_makagon: i meant what the abstract functions would be | 18:50 |
| denis_makogon | juice, same, as i said few lines ago | 18:51 |
| vgnbkr | denis_makogon: I would like to see a bp that outlines which functionality would be abstracted, and how it would affect each of the APIs and the cli clients. | 18:51 |
| kevinconway | i agree. java is bad. let's not use contracts of any kind. | 18:51 |
| kevinconway | use only dictionaries and lambdas | 18:51 |
| denis_makogon | vgnbkr, it would not affect API at all | 18:51 |
| denis_makogon | vgnbkr, it's the inner refactoring | 18:51 |
| *** saju_m has joined #openstack-trove | 18:51 | |
| SlickNik | denis_makogon: Unless we've got an interface in mind, how do we know it'd work for both nova-network and neutron? | 18:51 |
| esmute | kevinconway: Java8 has lambdas now | 18:51 |
| grapex | kevinconway: Says you! All my personal projects are done in Ada. | 18:51 |
| denis_makogon | SlickNik, it's based on config value | 18:52 |
| kevinconway | grapex: do you program airplanes as a hobby? | 18:52 |
| denis_makogon | SlickNik, that defines which manager is used | 18:52 |
| grapex | kevinconway: No, car boats that turn into planes | 18:52 |
| grapex | SlickNik: I agree | 18:52 |
| grapex | I think trying to do it two ways before we add the major work from Anna's blueprint is a mistake | 18:52 |
| grapex | It's getting the cart ahead of the horse | 18:52 |
| vgnbkr | Sorry, I didn't mean just the REST API - maybe I'm not using the terminology right - but I would want to understand which functionality would change, and how it would be selected. | 18:53 |
| vgnbkr | denis_makogon: If it is selected by config values, that should be reflected in the bp. | 18:53 |
| denis_makogon | vgnbkr, take a look at wiki page | 18:53 |
| denis_makogon | vgnbkr, i described how it'll work | 18:53 |
| vgnbkr | I did look at the wiki page - that's why I made the comment. | 18:53 |
| denis_makogon | vgnbkr, https://wiki.openstack.org/wiki/Trove/NetworkAttributesManagement#Configuration | 18:53 |
| SlickNik | grapex: +1. I think that we need to figure out what the neutron requirements are. | 18:54 |
| openstackgerrit | Kaleb Pomeroy proposed a change to openstack/trove: Implements datastore capabilities https://review.openstack.org/83503 | 18:54 |
| amrith | guys and gals ... given how long this discussion is going on now, it is safe to say that there are many issues that have been raised about this proposal and we should figure out how to address those before a YES decision can be made. At this time, I implore core to consider a NOT NOW vote. | 18:54 |
| amrith | the motion is on the floor, do I have a second? | 18:55 |
| SlickNik | seconded | 18:55 |
| amcrn | tres'd | 18:55 |
| grapex | Aye | 18:55 |
| amrith | I propose an immediate vote on the motion | 18:55 |
| kevinconway | amrith: this is no place for robertmyers rules | 18:55 |
| robertmyers | kevinconway: +1 | 18:55 |
| amrith | third edition, robertmyers rules | 18:55 |
| juice | amrith: agreed without more information but I think it's pointed in the right direction | 18:55 |
| *** sbfox has quit IRC | 18:56 | |
| SlickNik | Let's move on to | 18:56 |
| SlickNik | Cross-region backups [esmute] | 18:56 |
| SlickNik | •https://blueprints.launchpad.net/trove/+spec/cross-region-backup-migration | 18:56 |
| amrith | thanks | 18:56 |
| esmute | ha.. as if we dont have enough with backups already | 18:56 |
| esmute | this one is about making backups accessible cross-region.. | 18:56 |
| esmute | to be able to restore from a backup in a different region | 18:57 |
| robertmyers | broken link? | 18:57 |
| grapex | esmute: Your link on the agenda is wrong. :( | 18:57 |
| amcrn | https://wiki.openstack.org/wiki/Cross-region-backup-availability | 18:57 |
| esmute | https://wiki.openstack.org/wiki/Cross-region-backup-availability | 18:57 |
| SlickNik | Thanks amcrn | 18:57 |
| cp16net | yeah its broken | 18:57 |
| esmute | the idea is that /backup will take a location reference (instead of a instance ID) and create a backup. | 18:58 |
| esmute | that will validate the location, create a backup record in the DB, and copy the backup from the the source region to the trove region | 18:59 |
| *** sgotliv_ has quit IRC | 18:59 | |
| robertmyers | esmute: should it not just be region and we use the service catalog to find the swift url? | 18:59 |
| amcrn | esmute: asking the user to provide an endpoint vs. a region (and/or az) doesn't align with the abstractions in other apis. thoughts? | 18:59 |
| *** sbfox has joined #openstack-trove | 18:59 | |
| amcrn | crafty robertmyers beating me to the punch | 18:59 |
| amcrn | ;) | 18:59 |
| esmute | it is assumed that the storage (swift) is accessible cross-region and that the auth token works for both regions | 18:59 |
| robertmyers | that is the job of teh service catalog | 19:00 |
| openstackgerrit | Daniel Salinas proposed a change to openstack/trove: Add instance metadata functionality to trove https://review.openstack.org/82123 | 19:00 |
| grapex | amcrn robertmyers: I agree, and I think if they provided the region it would be easier for us. But I do think the API as presented might be easier from a user's perspective | 19:00 |
| amcrn | grapex: until the endpoint changes | 19:00 |
| esmute | the backup already shows location. | 19:00 |
| robertmyers | which we should be using instead of the hard coded SWIFT_URL in the config file | 19:00 |
| grapex | amcrn: Actually, yeah you're right. | 19:00 |
| cp16net | so you have to provide the full uri to the backup file in the API? | 19:01 |
| esmute | how do we specify the backup object? | 19:01 |
| *** thedodd has quit IRC | 19:01 | |
| amcrn | esmute: the user would have to specify a region (and/or az) as fields in the payload, or the backup_id would need a namespacing prefix | 19:01 |
| SlickNik | esmute: What robertmyers and amcrn are proposing is that instead of location: <URL> you'd have something like backup-id: <id>, region: <region>. We could then construct the swift URL from the backup-id and region. | 19:02 |
| *** mattgriffin has quit IRC | 19:02 | |
| robertmyers | SlickNik: yes | 19:02 |
| amcrn | SlickNik: that, or backup_id: "<region>:<az>:<id>" | 19:02 |
| cp16net | SlickNik: that sounds way better | 19:02 |
| esmute | thanks for the clarification SlickNik | 19:02 |
| esmute | yeah.. that could work too. | 19:03 |
| SlickNik | amcrn: yes, that would work too. | 19:03 |
| esmute | ok ill update the BP with that | 19:03 |
| esmute | one other quesitons | 19:03 |
| *** thedodd has joined #openstack-trove | 19:03 | |
| SlickNik | Thinking out loud here. Do we ever have a case for BYOB (bring your own backup?) | 19:04 |
| esmute | so i am thinking of leveraging the streaming fuctions (save/read) to copy backups from one region to another | 19:04 |
| grapex | SlickNik: Possibly- but I think that's for another blueprint | 19:04 |
| SlickNik | grapex: fair enough. | 19:04 |
| grapex | Hey everyone, the Rax guys have a meeting at this moment | 19:04 |
| amrith | esmute: when you said "how do we specify backup object" were you inquiring about the location of the file where the backup would land, or the object in the database that would be backed up? | 19:04 |
| robertmyers | SlickNik: maybe but not with encryption and checksums | 19:04 |
| robertmyers | security yo | 19:04 |
| grapex | I vote +1 on esmute's blueprint if the changes amcrn and robermyers suggested are taken into account | 19:04 |
| esmute | amrith: the former | 19:04 |
| amrith | esmute: thx | 19:04 |
| amcrn | SlickNik robertmyers esmute grapex amrith : fwiw, the decision on how to handle region/az (field vs. namespace vs. ?) for this will have large ramifications on how clustering is handled, so the decision should be made with great care. | 19:04 |
| *** jcru has quit IRC | 19:04 | |
| amrith | I'm assuming the former is entire instance | 19:04 |
| amrith | sorry: later | 19:05 |
| esmute | will creating a greenthread to handle the streaming acceptable? | 19:05 |
| amrith | backup would be of full instance | 19:05 |
| amcrn | (since you'd want the apis to be consistent) | 19:05 |
| SlickNik | +1 to esmute's bp after the changes as well. | 19:05 |
| grapex | With some more consideration given to amcrn's concern | 19:05 |
| grapex | End of meeting? | 19:05 |
| SlickNik | Yup, that's all we have time for. | 19:06 |
| SlickNik | We'll have to roll over the next bps to the start of the next meeting. | 19:06 |
| SlickNik | Thanks all! | 19:06 |
| grapex | Thanks SlickNik! | 19:06 |
| cp16net | ok | 19:06 |
| robertmyers | thanks! | 19:06 |
| amcrn | cp16net: since you're here, a quick comment on the config description before i run to lunch: if there's a way to keep it i18n'able, that'd probably be best. | 19:06 |
| denis_makogon | one question, is my BP about recovery was rejected, right ? | 19:07 |
| *** jcru has joined #openstack-trove | 19:08 | |
| SlickNik | "So the way I see it, this bp has points to address: | 19:08 |
| SlickNik | - For something to be "point in time" recovery, you should be able to recover to any point in time (with reasonable limits on granularity). This doesn't enable that. | 19:08 |
| SlickNik | - This currently doesn't enable anything new over restoring to a new instance (and additionally has the issue that we may overwrite valid data by mistake, making it dangerous)." | 19:08 |
| *** kevinconway has quit IRC | 19:08 | |
| *** eguz has joined #openstack-trove | 19:09 | |
| SlickNik | Those 2 points need to be addressed to consider it, denis_makogon. | 19:09 |
| cp16net | amcrn: yeah i think thats something that we might need | 19:09 |
| cp16net | amcrn: not sure how we normally do that sort of thing tho | 19:10 |
| esp | denis_makogon: you might want to reference the feature in AWS regarding “point in time recovery” although the wording is confusing in the context of trove | 19:10 |
| amcrn | cp16net: with _() it's doable, so if these strings were defined in a py, it'd work, but that's pretty nasty. | 19:10 |
| cp16net | amcrn: well that wont work with data in the DB | 19:11 |
| amcrn | right | 19:11 |
| cp16net | thats on hardcoded strings in the log message | 19:11 |
| amcrn | i don't have any solutions for you, the thought just came to mind while seeing all of these doc translations fly by | 19:11 |
| amcrn | ;) | 19:11 |
| amcrn | there might be a precedent in another project, not sure | 19:11 |
| cp16net | and i REALLY dotn want all those strings in some magic python file | 19:11 |
| cp16net | that seems like a bad idea | 19:11 |
| cp16net | yeah i'm not sure if there is somethign that has been done like this | 19:12 |
| amcrn | cp16net: we'll just ship trove with a free mobile copy of duolingo | 19:12 |
| *** eghobo has quit IRC | 19:12 | |
| amcrn | cp16net: then rake in the affiliate fees and retire to the bahamas | 19:12 |
| cp16net | it seems more like trying to change the name or descrtpions of config params | 19:12 |
| cp16net | when they are stored in the db | 19:12 |
| cp16net | lol | 19:13 |
| cp16net | :-P | 19:13 |
| amcrn | :D | 19:13 |
| *** eghobo has joined #openstack-trove | 19:13 | |
| amcrn | alright, lunch, bbl. | 19:13 |
| cp16net | alright peace out | 19:13 |
| cp16net | i was hopful that we could talk about my bps :( | 19:14 |
| *** eguz has quit IRC | 19:15 | |
| SlickNik | cp16net: sorry we couldn't get to them. :( | 19:19 |
| SlickNik | They'll be on top for the next meeting, though. | 19:19 |
| *** mattgriffin has joined #openstack-trove | 19:19 | |
| cp16net | so thats next week or for wed? | 19:19 |
| SlickNik | Next week at the latest. But I'm not opposed to talking about it during open-discussion of the Wed meeting if time permits. Do you have a preference? | 19:22 |
| cp16net | well i think 1 of my BP is something that should not be a controversial change | 19:22 |
| cp16net | (trove-manage) | 19:23 |
| cp16net | the conf descriptions could be a bit more of a convo | 19:23 |
| *** kevinconway has joined #openstack-trove | 19:27 | |
| openstackgerrit | Khyati Sheth proposed a change to openstack/trove: Implement Mongodb config groups https://review.openstack.org/85795 | 19:28 |
| *** thedodd has quit IRC | 19:29 | |
| *** thedodd has joined #openstack-trove | 19:31 | |
| *** thedodd has quit IRC | 19:31 | |
| *** thedodd has joined #openstack-trove | 19:33 | |
| *** sbfox has quit IRC | 19:34 | |
| *** ViswaV has quit IRC | 19:35 | |
| *** doddstack has joined #openstack-trove | 19:38 | |
| *** thedodd has quit IRC | 19:40 | |
| *** freyes_ has quit IRC | 19:42 | |
| *** ramashri_ has quit IRC | 19:43 | |
| *** jcru_ has joined #openstack-trove | 19:43 | |
| *** jcru has quit IRC | 19:44 | |
| *** michael-yu has quit IRC | 19:54 | |
| openstackgerrit | Kaleb Pomeroy proposed a change to openstack/trove: Implements datastore capabilities https://review.openstack.org/83503 | 19:58 |
| *** jcru_ has quit IRC | 20:02 | |
| *** jcru has joined #openstack-trove | 20:02 | |
| *** harlowja has quit IRC | 20:03 | |
| *** erik508 has joined #openstack-trove | 20:06 | |
| *** grapex has quit IRC | 20:08 | |
| *** parstac_pete_ has joined #openstack-trove | 20:09 | |
| *** russellb_ has joined #openstack-trove | 20:09 | |
| *** russellb has quit IRC | 20:10 | |
| *** erik508_ has quit IRC | 20:10 | |
| *** peterstac has quit IRC | 20:10 | |
| *** russellb_ is now known as russellb | 20:10 | |
| *** parstac_pete_ is now known as peterstac | 20:10 | |
| *** Barker has joined #openstack-trove | 20:10 | |
| *** Barker has quit IRC | 20:10 | |
| *** ViswaV has joined #openstack-trove | 20:12 | |
| *** ViswaV_ has joined #openstack-trove | 20:13 | |
| *** ViswaV has quit IRC | 20:13 | |
| *** ViswaV has joined #openstack-trove | 20:14 | |
| *** ViswaV_ has quit IRC | 20:14 | |
| *** grapex has joined #openstack-trove | 20:15 | |
| *** Barker has joined #openstack-trove | 20:16 | |
| *** harlowja has joined #openstack-trove | 20:19 | |
| *** jmontemayor has quit IRC | 20:20 | |
| *** michael-yu has joined #openstack-trove | 20:25 | |
| *** amcrn has quit IRC | 20:28 | |
| *** freyes_ has joined #openstack-trove | 20:28 | |
| *** ramashri has joined #openstack-trove | 20:31 | |
| *** michael-yu has quit IRC | 20:32 | |
| *** ramashri_ has joined #openstack-trove | 20:32 | |
| *** michael-yu has joined #openstack-trove | 20:33 | |
| *** amcrn has joined #openstack-trove | 20:33 | |
| *** ramashri has quit IRC | 20:35 | |
| *** ViswaV has quit IRC | 20:37 | |
| *** demorris has quit IRC | 20:39 | |
| *** saju_m has quit IRC | 20:41 | |
| *** ViswaV has joined #openstack-trove | 20:50 | |
| *** ViswaV_ has joined #openstack-trove | 20:51 | |
| *** ViswaV has quit IRC | 20:51 | |
| esmute | hub_cap, amcrn, SlickNik, vipul, grapex: When you guys have time, can you quickly review https://review.openstack.org/#/c/81379/? Just want to get the percona int-test passing. | 20:52 |
| *** freyes_ has quit IRC | 20:53 | |
| juice | hub_cap, amcrn, grapex, slicknik, vipul - pardon me if I'm out of line but I was thinking this weekend...this blueprint review thing has been going pretty good. The next step, I think is to have a triaged list of blueprints to focus - like a top 3. Both the reviewer and the reviewees focus on those blueprints and those blueprints alone. The reviews get submitted, 2 of the 5 reviewers review it along with the +1'ers. The reviewee has a | 20:59 |
| juice | responsibility to turn those changes around within x days (or risk losing their spot) and the reviewers have a responsibility to approve/correct within a day. Basically get some laser focus on fewer reviewers but get them reviewed in a shorter period | 20:59 |
| grapex | juice: I like it | 21:00 |
| grapex | I am worried at just three we won't be able to look at enough though- seems like there's a big back log at the moment- but we should start there | 21:00 |
| hub_cap | juice: ++ | 21:01 |
| SlickNik | juice: excellent idea | 21:01 |
| juice | grapex: the idea is to keep it small and maybe if the flow is working, expand it to a bigger number | 21:04 |
| *** denis_makogon has quit IRC | 21:05 | |
| juice | the other idea is people know where they stand with their reviews and the expectation is clear. you core reviewer guys get to say "Not today" or "your's isn't in the spotlight right now" but when it is in the "spotlight" you better be dancing :) | 21:05 |
| SlickNik | Was chatting with dougshelley66 regarding this also, and were thinking about a couple of other things that we can do better regarding bps. | 21:06 |
| SlickNik | 1: Pick 4 bps and time-box discussion to ~12-13 mins per bp. | 21:06 |
| SlickNik | 2: At the end of the discussion have a motion to vote with some fixed choices (Approved; Approved with minor edits; Major edits needed before requeue; More discussion time needed - move to next week; Not Approved) | 21:06 |
| SlickNik | Was going to put some information together in a wiki page. | 21:07 |
| juice | slicknik: though my suggestion was more on the actual reviews themselves. I think the monday bp review is pretty good given that it's just started. | 21:08 |
| juice | but when rubber meets the road and patches come it I think some process improvement can be made there | 21:09 |
| peterstac | Quick question: Is there a reason why our CLI treats flavors as int's, whereas nova manages them as UUID's ? | 21:10 |
| cp16net | SlickNik: yeah that would be nice to time box things and then know if your stuff was going to be brought up or not | 21:11 |
| peterstac | (reason I'm asking is that if you add a flavor with letters in it, our CLI chokes on it) | 21:11 |
| peterstac | (wanted to make sure that we should handle UUID's as well before entering a bug) | 21:12 |
| cp16net | peterstac: flavors have uuids? | 21:12 |
| cp16net | i dont recall see that before | 21:12 |
| cp16net | i know images use uuids | 21:12 |
| hub_cap | yes its a bug peterstac | 21:12 |
| hub_cap | its well known, trove only had a int validation before we went all uuid on flavors | 21:13 |
| peterstac | Well, they're int's in the list, but under the cover they're UUID's | 21:13 |
| hub_cap | like waaaay legacy | 21:13 |
| peterstac | ok, I'll enter a bug then, thx | 21:13 |
| hub_cap | are they not getting rid of tha? or allowing to use non int | 21:13 |
| hub_cap | peterstac: plz search first, its been a well known trove bug for like 2 yrs | 21:13 |
| cp16net | hmmm we would have had to deal with it sooner if devstack was creating something with that i guess... | 21:13 |
| *** dmitryme has quit IRC | 21:13 | |
| hub_cap | problem is, we _fix_ the api, we break the contract | 21:14 |
| hub_cap | sad trombone | 21:14 |
| peterstac | They allow non-int - in fact if you create a flavor with 'auto' as the id, it will create a UUID for you | 21:14 |
| cp16net | OH......... | 21:15 |
| * hub_cap sees a light go off above cp16net | 21:15 | |
| peterstac | ubuntu@ubuntu:/opt/stack/python-troveclient$ nova --os-username admin --os-password 3de4922d8b6ac5a1aad9 flavor-create peter auto 512 20 3 | 21:15 |
| peterstac | +--------------------------------------+-------+-----------+------+-----------+------+-------+-------------+-----------+ | 21:15 |
| peterstac | | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | | 21:15 |
| peterstac | +--------------------------------------+-------+-----------+------+-----------+------+-------+-------------+-----------+ | 21:15 |
| peterstac | | 3f5b6eef-32c8-42ed-935f-aae44f1dfcf5 | peter | 512 | 20 | 0 | | 3 | 1.0 | True | | 21:15 |
| peterstac | +--------------------------------------+-------+-----------+------+-----------+------+-------+-------------+-----------+ | 21:15 |
| cp16net | hub_cap: haha yup | 21:15 |
| openstackgerrit | Jenkins proposed a change to openstack/python-troveclient: Updated from global requirements https://review.openstack.org/79646 | 21:16 |
| hub_cap | peterstac: plz send us multilines like that in a gist | 21:16 |
| hub_cap | it hurts my eyes to see that in my txt window | 21:17 |
| hub_cap | and frankly i can guarantee my screen is smaller than yours, and im devoting a very small part of it to irssi anyway ;) | 21:17 |
| cp16net | oh boy i have your password now.. :-P | 21:17 |
| hub_cap | lol cp16net | 21:17 |
| openstackgerrit | Jenkins proposed a change to openstack/trove: Updated from global requirements https://review.openstack.org/85844 | 21:17 |
| peterstac | cp16net: for today at least :) | 21:18 |
| cp16net | harh har har | 21:18 |
| cp16net | Bender: C'mon, it's just like making love. Y'know, left, down, rotate sixty-two degrees, engage rotors... | 21:18 |
| hub_cap | we all have his pretty table | 21:19 |
| peterstac | Looks like it's already entered: #1226259 | 21:19 |
| hub_cap | man i wish we had the bot that would spew out the whole url fo rthat | 21:19 |
| peterstac | hub_cap: gist it is (next time) sorry! | 21:19 |
| *** achampion has quit IRC | 21:19 | |
| hub_cap | peterstac: <3<3 | 21:20 |
| *** sbfox has joined #openstack-trove | 21:23 | |
| *** sbfox has quit IRC | 21:24 | |
| *** sbfox has joined #openstack-trove | 21:24 | |
| openstackgerrit | Jenkins proposed a change to openstack/python-troveclient: Updated from global requirements https://review.openstack.org/79646 | 21:27 |
| cp16net | hub_cap: ++ to the openstack bot | 21:31 |
| *** harlowja is now known as harlowja_away | 21:31 | |
| hub_cap | someone just needs to ask infra im sure | 21:31 |
| cp16net | yeah i bet its just a review away of being added here | 21:32 |
| *** harlowja_away is now known as harlowja | 21:35 | |
| *** yogesh has quit IRC | 21:37 | |
| hub_cap | yup | 21:40 |
| *** Barker has quit IRC | 21:48 | |
| *** sgotliv has quit IRC | 21:53 | |
| *** pdmars has quit IRC | 22:01 | |
| *** michael-yu has quit IRC | 22:04 | |
| *** ramashri_ has quit IRC | 22:06 | |
| *** robertmyers has quit IRC | 22:06 | |
| *** ramashri has joined #openstack-trove | 22:06 | |
| *** amcrn has quit IRC | 22:08 | |
| *** amcrn has joined #openstack-trove | 22:12 | |
| *** cweid has joined #openstack-trove | 22:14 | |
| *** ramashri has quit IRC | 22:14 | |
| *** ramashri_ has joined #openstack-trove | 22:14 | |
| *** achampion has joined #openstack-trove | 22:20 | |
| *** amytron has quit IRC | 22:31 | |
| *** demorris has joined #openstack-trove | 22:35 | |
| *** demorris has quit IRC | 22:41 | |
| *** Barker has joined #openstack-trove | 22:50 | |
| *** Barker has quit IRC | 22:54 | |
| *** jcru has quit IRC | 22:56 | |
| *** mattgriffin has quit IRC | 22:59 | |
| *** eguz has joined #openstack-trove | 23:03 | |
| *** eghobo has quit IRC | 23:08 | |
| *** doddstack has quit IRC | 23:16 | |
| *** saurabhs has quit IRC | 23:22 | |
| *** grapex has quit IRC | 23:25 | |
| *** jamielennox has joined #openstack-trove | 23:26 | |
| jamielennox | hey guys - can i get some core to look at (+A) https://review.openstack.org/#/c/83270/ it's a -1 line fix that's been open for a while now | 23:26 |
| *** kevinconway has quit IRC | 23:28 | |
| *** amcrn has quit IRC | 23:33 | |
| *** Barker has joined #openstack-trove | 23:43 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!