| *** vipul-away is now known as vipul | 00:16 | |
| *** harlowja has quit IRC | 00:16 | |
| openstackgerrit | A change was merged to openstack/trove: Add a hook for backup processes to check if successful. https://review.openstack.org/55311 | 00:17 |
|---|---|---|
| *** grapex has quit IRC | 00:22 | |
| *** grapex has joined #openstack-trove | 00:22 | |
| *** demorris has joined #openstack-trove | 00:24 | |
| *** demorris has quit IRC | 00:25 | |
| *** grapex has quit IRC | 00:27 | |
| *** matsuhashi has joined #openstack-trove | 00:29 | |
| *** coolsvap has quit IRC | 00:30 | |
| *** ashestakov has quit IRC | 00:35 | |
| *** matsuhashi has quit IRC | 00:48 | |
| *** matsuhashi has joined #openstack-trove | 00:49 | |
| *** matsuhashi has quit IRC | 00:53 | |
| *** jcooley_ has quit IRC | 00:55 | |
| *** jcooley_ has joined #openstack-trove | 00:55 | |
| *** yogesh has joined #openstack-trove | 00:55 | |
| *** jcooley_ has quit IRC | 01:00 | |
| *** amcrn has quit IRC | 01:05 | |
| *** matsuhashi has joined #openstack-trove | 01:08 | |
| *** haomaiwang has joined #openstack-trove | 01:08 | |
| *** nosnos has joined #openstack-trove | 01:09 | |
| *** yidclare has quit IRC | 01:13 | |
| *** shakayumi has joined #openstack-trove | 01:20 | |
| *** adrian_otto has quit IRC | 01:20 | |
| *** yogesh has quit IRC | 01:33 | |
| *** yogesh has joined #openstack-trove | 01:33 | |
| *** matsuhashi has quit IRC | 01:34 | |
| *** matsuhashi has joined #openstack-trove | 01:35 | |
| *** yogesh has quit IRC | 01:38 | |
| *** matsuhashi has quit IRC | 01:40 | |
| *** matsuhashi has joined #openstack-trove | 01:43 | |
| *** harlowja has joined #openstack-trove | 01:51 | |
| *** jcooley_ has joined #openstack-trove | 01:54 | |
| *** Barker has joined #openstack-trove | 01:56 | |
| *** shakayumi has quit IRC | 02:06 | |
| *** demorris has joined #openstack-trove | 02:09 | |
| *** erkules_ has joined #openstack-trove | 02:17 | |
| *** erkules has quit IRC | 02:19 | |
| *** david-lyle has quit IRC | 02:30 | |
| *** david-lyle has joined #openstack-trove | 02:31 | |
| *** haomaiwang has quit IRC | 03:18 | |
| *** Barker has quit IRC | 03:23 | |
| *** Barker has joined #openstack-trove | 03:26 | |
| *** Barker has quit IRC | 03:28 | |
| *** Barker has joined #openstack-trove | 03:31 | |
| *** matsuhashi has quit IRC | 03:31 | |
| *** matsuhashi has joined #openstack-trove | 03:31 | |
| *** matsuhashi has quit IRC | 03:36 | |
| *** Barker has quit IRC | 03:38 | |
| *** matsuhashi has joined #openstack-trove | 03:41 | |
| openstackgerrit | A change was merged to openstack/trove: Add support of datastore types https://review.openstack.org/47934 | 03:47 |
| hub_cap | victory ^^ | 03:54 |
| *** jcooley_ has quit IRC | 03:57 | |
| *** shalini has quit IRC | 04:00 | |
| *** coolsvap has joined #openstack-trove | 04:16 | |
| *** jcooley_ has joined #openstack-trove | 04:33 | |
| *** jcooley_ has quit IRC | 04:38 | |
| *** SushilKM__ has joined #openstack-trove | 04:49 | |
| *** SushilKM__ has quit IRC | 04:56 | |
| *** demorris has quit IRC | 05:08 | |
| *** jcooley_ has joined #openstack-trove | 05:14 | |
| *** jcooley_ has quit IRC | 05:19 | |
| *** tanisdl has quit IRC | 05:33 | |
| *** coolsvap has quit IRC | 05:39 | |
| *** harlowja has quit IRC | 05:52 | |
| *** vipul has quit IRC | 05:56 | |
| *** vipul has joined #openstack-trove | 05:56 | |
| *** coolsvap has joined #openstack-trove | 05:58 | |
| *** matsuhashi has quit IRC | 06:08 | |
| *** yogesh has joined #openstack-trove | 06:08 | |
| *** matsuhashi has joined #openstack-trove | 06:08 | |
| *** ashestakov has joined #openstack-trove | 06:09 | |
| *** matsuhashi has quit IRC | 06:13 | |
| *** yogesh has quit IRC | 06:16 | |
| *** yogesh has joined #openstack-trove | 06:17 | |
| *** yogesh has quit IRC | 06:17 | |
| *** yogesh has joined #openstack-trove | 06:18 | |
| *** jcooley_ has joined #openstack-trove | 06:21 | |
| *** jcooley_ has quit IRC | 06:24 | |
| *** nosnos_ has joined #openstack-trove | 06:25 | |
| *** nosnos has quit IRC | 06:29 | |
| *** matsuhashi has joined #openstack-trove | 06:29 | |
| *** vipul is now known as vipul-away | 06:34 | |
| *** yogesh has quit IRC | 06:35 | |
| *** jcooley_ has joined #openstack-trove | 06:35 | |
| *** yogesh has joined #openstack-trove | 06:35 | |
| *** ashestakov has quit IRC | 06:38 | |
| *** yogesh has quit IRC | 06:40 | |
| *** adrian_otto has joined #openstack-trove | 06:42 | |
| *** yogesh has joined #openstack-trove | 06:42 | |
| *** adrian_otto has quit IRC | 06:48 | |
| *** adrian_otto has joined #openstack-trove | 06:49 | |
| *** jcooley_ has quit IRC | 06:51 | |
| *** jcooley_ has joined #openstack-trove | 07:03 | |
| *** nosnos_ has quit IRC | 07:05 | |
| *** nosnos has joined #openstack-trove | 07:05 | |
| *** vipul-away is now known as vipul | 07:07 | |
| *** yogesh has quit IRC | 07:09 | |
| *** yogesh has joined #openstack-trove | 07:09 | |
| *** jcooley_ has quit IRC | 07:10 | |
| *** yogesh_ has joined #openstack-trove | 07:13 | |
| *** isviridov_ has joined #openstack-trove | 07:15 | |
| *** yogesh has quit IRC | 07:16 | |
| *** denis_makogon has joined #openstack-trove | 07:21 | |
| *** matsuhashi has quit IRC | 07:22 | |
| *** matsuhashi has joined #openstack-trove | 07:23 | |
| *** matsuhas_ has joined #openstack-trove | 07:30 | |
| *** matsuhashi has quit IRC | 07:34 | |
| *** erkules_ is now known as erkules | 08:04 | |
| *** ashestakov has joined #openstack-trove | 08:06 | |
| *** ashestakov has quit IRC | 08:06 | |
| *** jcooley_ has joined #openstack-trove | 08:11 | |
| *** matsuhas_ has quit IRC | 08:18 | |
| *** matsuhashi has joined #openstack-trove | 08:19 | |
| *** isviridov_ has quit IRC | 08:22 | |
| *** matsuhashi has quit IRC | 08:24 | |
| *** matsuhashi has joined #openstack-trove | 08:31 | |
| *** denis_makogon has quit IRC | 08:43 | |
| *** jcooley_ has quit IRC | 08:45 | |
| *** haomaiwang has joined #openstack-trove | 08:45 | |
| *** haomaiwang has quit IRC | 08:52 | |
| *** yogesh_ has quit IRC | 09:00 | |
| *** yogesh has joined #openstack-trove | 09:00 | |
| *** yogesh has quit IRC | 09:02 | |
| *** yogeshmehra has joined #openstack-trove | 09:04 | |
| *** haomaiwang has joined #openstack-trove | 09:14 | |
| *** ashestakov has joined #openstack-trove | 09:25 | |
| *** yogeshmehra has quit IRC | 09:29 | |
| *** ashestakov has quit IRC | 09:29 | |
| *** jcooley_ has joined #openstack-trove | 09:41 | |
| *** jcooley_ has quit IRC | 09:47 | |
| *** kevinconway_ has joined #openstack-trove | 09:52 | |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow secure/insecure sql query logging https://review.openstack.org/57408 | 09:56 |
| *** ikhudoshyn has quit IRC | 09:57 | |
| *** SushilKM__ has joined #openstack-trove | 10:03 | |
| *** matsuhashi has quit IRC | 10:14 | |
| *** adrian_otto has quit IRC | 10:27 | |
| *** SnowDust has joined #openstack-trove | 10:28 | |
| *** ikhudoshyn has joined #openstack-trove | 10:32 | |
| *** ashestakov has joined #openstack-trove | 10:32 | |
| *** ashestakov has quit IRC | 10:33 | |
| dmakogon_ | SnowDust, ping | 10:40 |
| *** dmakogon_ is now known as denis_makogon | 10:41 | |
| SnowDust | hello dmakogon_ | 10:41 |
| SnowDust | hi denis_makogon | 10:41 |
| denis_makogon | SnowDust, have you abandon your draft review ? | 10:41 |
| SnowDust | the pluggable extentions ? | 10:41 |
| SnowDust | extensions? | 10:41 |
| denis_makogon | SnowDust, no | 10:41 |
| SnowDust | then ? | 10:41 |
| denis_makogon | SnowDust, templates | 10:41 |
| SnowDust | lemme see | 10:42 |
| denis_makogon | https://review.openstack.org/#/c/51836/ | 10:42 |
| *** jcooley_ has joined #openstack-trove | 10:43 | |
| SnowDust | denis_makogon: done | 10:46 |
| SnowDust | thx ! | 10:46 |
| denis_makogon | SnowDust, thanks | 10:46 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow secure/insecure sql query logging https://review.openstack.org/57408 | 10:52 |
| *** coolsvap has quit IRC | 10:57 | |
| *** jcooley_ has quit IRC | 11:17 | |
| openstackgerrit | Sushil Kumar proposed a change to openstack/trove: Remove radmin credentials from create_heat_client https://review.openstack.org/56373 | 11:34 |
| *** SushilKM__ has quit IRC | 11:41 | |
| *** nosnos_ has joined #openstack-trove | 12:09 | |
| *** nosnos has quit IRC | 12:12 | |
| *** jcooley_ has joined #openstack-trove | 12:13 | |
| *** nosnos_ has quit IRC | 12:14 | |
| *** jcooley_ has quit IRC | 12:19 | |
| *** kevinconway_ has quit IRC | 12:43 | |
| *** pdmars has joined #openstack-trove | 12:45 | |
| *** SnowDust has quit IRC | 13:14 | |
| *** jcooley_ has joined #openstack-trove | 13:15 | |
| *** SushilKM__ has joined #openstack-trove | 13:29 | |
| *** jcru has joined #openstack-trove | 13:47 | |
| *** jcooley_ has quit IRC | 13:49 | |
| *** demorris has joined #openstack-trove | 13:56 | |
| *** PradeepChandani has quit IRC | 14:30 | |
| *** shivamshukla has quit IRC | 14:31 | |
| *** Barker has joined #openstack-trove | 14:31 | |
| *** PradeepChandani has joined #openstack-trove | 14:33 | |
| *** shivamshukla has joined #openstack-trove | 14:35 | |
| *** robertmy_ has joined #openstack-trove | 14:44 | |
| *** amytron has joined #openstack-trove | 14:50 | |
| *** adrian_otto has joined #openstack-trove | 14:51 | |
| *** radez_g0n3 is now known as radez | 14:58 | |
| *** grapex has joined #openstack-trove | 15:03 | |
| *** grapex has quit IRC | 15:03 | |
| *** grapex has joined #openstack-trove | 15:04 | |
| *** amytron has quit IRC | 15:06 | |
| *** amytron has joined #openstack-trove | 15:06 | |
| *** SushilKM__ has quit IRC | 15:11 | |
| *** Barker has quit IRC | 15:17 | |
| *** coolsvap has joined #openstack-trove | 15:17 | |
| *** robertmy_ has quit IRC | 15:22 | |
| *** robertmyers has joined #openstack-trove | 15:22 | |
| *** cweid has joined #openstack-trove | 15:24 | |
| *** tanisdl has joined #openstack-trove | 15:36 | |
| *** datsun180b has joined #openstack-trove | 15:39 | |
| *** rnirmal has joined #openstack-trove | 15:41 | |
| *** jcooley_ has joined #openstack-trove | 16:04 | |
| *** plodronio has joined #openstack-trove | 16:09 | |
| *** yidclare has joined #openstack-trove | 16:11 | |
| *** jmontemayor has joined #openstack-trove | 16:12 | |
| *** adrian_otto has quit IRC | 16:20 | |
| *** TheRealBill has joined #openstack-trove | 16:20 | |
| *** jcooley_ has quit IRC | 16:22 | |
| *** coolsvap has quit IRC | 16:29 | |
| *** PradeepChandani has quit IRC | 16:40 | |
| *** shivamshukla has quit IRC | 16:41 | |
| openstackgerrit | Illia Khudoshyn proposed a change to openstack/trove: Initial support for single instance MongoDB support https://review.openstack.org/50597 | 16:41 |
| *** shivamshukla has joined #openstack-trove | 16:42 | |
| *** ashestakov has joined #openstack-trove | 16:43 | |
| openstackgerrit | Andrey Shestakov proposed a change to openstack/trove: Documentation for datastore types https://review.openstack.org/54921 | 16:43 |
| *** coolsvap has joined #openstack-trove | 16:48 | |
| *** coolsvap has quit IRC | 16:49 | |
| *** coolsvap has joined #openstack-trove | 16:52 | |
| *** jcooley_ has joined #openstack-trove | 16:53 | |
| *** plodronio has quit IRC | 16:54 | |
| *** cweid has quit IRC | 16:57 | |
| *** radez is now known as radez_g0n3 | 17:01 | |
| *** adrian_otto has joined #openstack-trove | 17:02 | |
| *** jmontemayor has quit IRC | 17:03 | |
| *** jmontemayor has joined #openstack-trove | 17:06 | |
| *** tanisdl has quit IRC | 17:07 | |
| *** jcooley_ has quit IRC | 17:10 | |
| *** SushilKM__ has joined #openstack-trove | 17:20 | |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Conductor proxies host db access for guests https://review.openstack.org/45116 | 17:39 |
| datsun180b | putting "merge conflict resolution" on my resume | 17:41 |
| *** isviridov_ has joined #openstack-trove | 17:58 | |
| *** isviridov_ has quit IRC | 18:00 | |
| hub_cap | *new* meeting time | 18:01 |
| *** harlowja has joined #openstack-trove | 18:02 | |
| *** yogesh has joined #openstack-trove | 18:02 | |
| *** SushilKM__ has quit IRC | 18:03 | |
| redthrux | denis_makogon: around? ikhudoshyn? isviridov? meeting time | 18:04 |
| *** adrian_otto has quit IRC | 18:14 | |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Adding designate dns support to trove https://review.openstack.org/54412 | 18:15 |
| *** isviridov_ has joined #openstack-trove | 18:15 | |
| juice | Trove Watchdog "We've got you covered" | 18:21 |
| hub_cap | Whats that urine smell? Security... | 18:22 |
| *** SushilKM__ has joined #openstack-trove | 18:25 | |
| juice | Whahahaha | 18:25 |
| *** jasonb365 has joined #openstack-trove | 18:28 | |
| *** yidclare has quit IRC | 18:29 | |
| *** amcrn has joined #openstack-trove | 18:33 | |
| hub_cap | speak | 18:37 |
| hub_cap | here | 18:37 |
| hub_cap | now | 18:37 |
| hub_cap | 10:37 AM vipul demorris: So maybe a PATCH on instance is what we need to implement | 18:38 |
| demorris | so I think that it is key that we expose the ability to allow users to self upgrade | 18:38 |
| hub_cap | ok cu guys.. ther is a break in the rain so im bookin in :) | 18:38 |
| kevinconway | demorris: if it's only minor patches and security updates why make that a user accessible thing? | 18:38 |
| grapex | demorris: Won't that make them go blind? | 18:38 |
| kevinconway | isn't that more on the service provider? | 18:38 |
| SlickNik | later hub_cap | 18:38 |
| vipul | sounds like a modification to Instance resource should do it | 18:38 |
| redthrux | LOL grapex | 18:38 |
| demorris | so it could be... | 18:38 |
| demorris | that is where maintenance windows came in to the discussion | 18:39 |
| demorris | if it is the provider | 18:39 |
| demorris | you have to have a way to allow the user to specify when such and update would occur because it is disruptive | 18:39 |
| kevinconway | demorris: so you need some way to prevent API calls for a time? | 18:39 |
| demorris | a restart must occur in the case of MySQL | 18:39 |
| amcrn | most cloud providers will release a new version of a package, and allow users to opt-in if they so choose (with strong wording suggesting that it's brand new and relatively not battle tested), only forcing an automatic migration many days/weeks/months later | 18:39 |
| redthrux | demorris - lets ask ourselves What Does Amazon Do | 18:39 |
| kevinconway | redthrux: +1 | 18:40 |
| demorris | redthrux: lets not do that :) | 18:40 |
| *** jcru has quit IRC | 18:40 | |
| *** isviridov_ has quit IRC | 18:40 | |
| *** SushilKM__ has quit IRC | 18:40 | |
| demorris | amazon is a bit brutal with this stuff | 18:40 |
| demorris | i mean, they send you eviction notices... | 18:40 |
| redthrux | +1 on brutal | 18:40 |
| demorris | not something i ncecessarily wanting to replicate that | 18:40 |
| SlickNik | amcrn: I tend to agree with that. I can see users opting-in or not, depending on what they're using the said instance for. | 18:41 |
| demorris | so amazon has maintenance windows | 18:41 |
| demorris | in practice this is not a bad idea | 18:41 |
| demorris | they know that things need to be kept updated | 18:41 |
| *** NehaV has joined #openstack-trove | 18:41 | |
| vipul | how about we start with a user-initiated call first.. that gets someone from 5.5.10 -> 5.5.11 | 18:41 |
| SlickNik | I'd be much more risk-averse to opting in for an instance running my production server, than say for an instance that I'm using for testing my deployments. | 18:41 |
| demorris | so they let the user choose a window when those things could be applied | 18:41 |
| vipul | that can always be rolled into an automated thing base on a window | 18:41 |
| demorris | I like the idea of starting with allowing a user to choose to update first | 18:42 |
| demorris | and coupling that with some way to allow the provider to manage instances that need to be updated | 18:42 |
| demorris | there will be security holes in DBMS's that you will then force updates on users | 18:42 |
| kevinconway | demorris: even if it requires a restart? | 18:43 |
| demorris | yes | 18:43 |
| vipul | Sure, i think that's fair -- the user can be notified, and an admin can initiate the update on their behalf | 18:43 |
| datsun180b | well shoot, conductor failed after my rebase | 18:43 |
| demorris | hence the concept of a maintenance window - a period of time when updates could be applied with some disruption (the provider would define what that means) | 18:43 |
| datsun180b | back to the drawing board | 18:43 |
| SlickNik | demorris: Is what's driving this primarily a security thing (version old.1 has a vulnerability that needs to be patched) or a convenience thing (version new.2 has a feature that users might want)? | 18:44 |
| demorris | not just security | 18:44 |
| demorris | could be a feature, could be a general bug fix | 18:44 |
| demorris | performance improvement | 18:44 |
| demorris | these things are not static, they are constantly being updated…more so on newer revisions like 5.6 | 18:45 |
| demorris | in Trove, I propose that we expose a way for users to 1) self manage updates 2) a framework for providers to manage updates on behalf of the user | 18:45 |
| demorris | that's it at a high level | 18:46 |
| demorris | for use case 1, you have different paths | 18:46 |
| demorris | some users don't care what version it is, they just want to be on the latest | 18:46 |
| demorris | others might care what version they are on, and "may" want to select a specific version | 18:46 |
| demorris | I envision the API exposing several pieces of data to enable this. 1) are updates available (true/false) 2) current version 3) available versions | 18:47 |
| demorris | and any other meta-data we have about those versions such as what is included in them (security fix, bug fix, etc.) | 18:48 |
| kevinconway | demorris: doesn't the datastore/type api already cover that? | 18:48 |
| kevinconway | in terms of letting you know what versions there are | 18:49 |
| vipul | kevinconway: +1 i think most of these are derivable | 18:49 |
| amcrn | kevinconway: somewhat, you can list versions and types, and i believe it will also tell you what the default version is for each type, but it will not tell you what's the "latest" | 18:49 |
| amcrn | assuming monotonically increasing version schemes however, that's derivable | 18:49 |
| kevinconway | amcrn: did the available_date stuff not make it in? | 18:49 |
| amcrn | nope | 18:49 |
| demorris | I care less about where this exists, if it exists in versions / types, great, or if it just a modification to it to support it, great as well | 18:50 |
| demorris | even if it did, it would take some level of work to package it up | 18:50 |
| kevinconway | demorris: package it up? | 18:50 |
| demorris | is it right to just give the API user current and available versions and force them to diff it? | 18:51 |
| demorris | rather than just tell them true|false if a new version is available? | 18:51 |
| kevinconway | the API isn't meant to be directly consumed. it's for building applications. The application should tell you. | 18:51 |
| kevinconway | so the client or GUI | 18:51 |
| demorris | kevinconway: I don't get that statment | 18:52 |
| demorris | the API is directly consumed by many different users | 18:52 |
| amcrn | you'll need more than latest, you'll need the concept of "certified" because the latest version might be available for use, but the recommended/supported/certified version is a major version below | 18:52 |
| amcrn | or some permutation thereof | 18:52 |
| kevinconway | demorris: i'm saying this might be something we can put into the trove-client | 18:52 |
| SlickNik | so another question: even if the list of versions is available in the datastore api, an upgrade is not always possible from one version to another. How do we surface which version upgrades we do support, and which ones we don't? | 18:53 |
| demorris | SlickNik: imho that needs to be left up to the operator | 18:53 |
| amcrn | +1 | 18:54 |
| kevinconway | SlickNik: i think the provider is in control over which versions are available through the version/type api | 18:54 |
| demorris | but you are right that you would need some rough policies to define what is possible in your deployment | 18:54 |
| SlickNik | kevinconway: Yes, but I might want to make a mysql 6 available for new instances when it comes out; and yet an upgrade from mysql 5.1 to 6 might not be possible. | 18:56 |
| kevinconway | SlickNik: i think those have to be separate data stores. or we have to talk about major upgrades. right now we're just on minors | 18:56 |
| demorris | so am I right in assuming that there is general agreement that my 2 use cases proposed are valid and belong in Trove in some capacity? | 18:56 |
| kevinconway | 5.1.1 to 5.1.2 or 5.2.0 | 18:56 |
| amcrn | i think we'll need to amend the datastore tables to have the concept of "upgrade_from" and "upgrade_to" | 18:56 |
| demorris | implementation details to be worked out of course... | 18:56 |
| demorris | just want to make sure we have agreement on the proposed use cases we are solving for | 18:57 |
| *** konetzed has joined #openstack-trove | 18:57 | |
| kevinconway | demorris: your major concern in all this is downtime for the owner of the db right? | 18:57 |
| demorris | I'll repost - demorris: in Trove, I propose that we expose a way for users to 1) self manage updates 2) a framework for providers to manage updates on behalf of the user | 18:58 |
| amcrn | in that chronological order, i agree | 18:58 |
| demorris | yes, updates and upgrades are disruptive | 18:58 |
| demorris | amcrn: okay cool | 18:58 |
| demorris | and we can break use case 1 down further | 18:58 |
| demorris | lets get synced on terminology | 18:59 |
| amcrn | have to bounce to a meeting, will read chatlog once i return | 19:00 |
| demorris | specifically on versioning…major.minor.[build[.revision]] | 19:00 |
| *** amcrn is now known as [a]mcrn | 19:00 | |
| konetzed | demorris: that only works for project following gnu version control | 19:00 |
| demorris | okay, well work with me here, what other versioning types are there? | 19:01 |
| kevinconway | semantic versioning | 19:01 |
| demorris | for the various DBMS's | 19:01 |
| kevinconway | major.minor.patch | 19:01 |
| konetzed | kevinconway: thats still following gnu | 19:01 |
| kevinconway | well we can use mysql as an exception | 19:01 |
| konetzed | im talking more about like solaris style that openstack uses | 19:02 |
| kevinconway | 5.5 is a major rev up from 5.1 | 19:02 |
| demorris | at least major.minor is the same | 19:02 |
| konetzed | kevinconway: its still following gnu rules, there it nothing that says minor revs have to be compatable | 19:03 |
| kevinconway | konetzed: there is in semantic versioning | 19:03 |
| kevinconway | minors can't be backwards incompatible | 19:03 |
| kevinconway | only majors | 19:03 |
| demorris | does MySQL consider 5.X to be major? | 19:03 |
| konetzed | doing like 2013.1 is a complete break from gnu | 19:03 |
| kevinconway | does gnu really allow for backwards incompatible minors? or is it only within a window of X minors? | 19:04 |
| konetzed | i dont know or care, i was talking about just breaking from x.y.z | 19:04 |
| kevinconway | demorris: i would consider it major if they have incompatible changes | 19:04 |
| kevinconway | meaning schema changes are required to do the update | 19:04 |
| kevinconway | or major commands change | 19:05 |
| konetzed | demorris: i made things confusing and this got out of hand | 19:05 |
| *** rnirmal has quit IRC | 19:06 | |
| demorris | konetzed: a little :) | 19:06 |
| konetzed | what i was trying to get at is you were talking about gnu versioning, how the packages are versioned really doesnt matter | 19:06 |
| kevinconway | what i'm trying to point out is that major and minor updates can't be inferred from the version number | 19:06 |
| kevinconway | major/minor in terms of impact that is | 19:06 |
| demorris | yeah, I think it is going to come down to specific policies for each DBMS and how they are handled | 19:06 |
| konetzed | demorris: i dont think you really do | 19:07 |
| demorris | each one will potentially treat it different;y | 19:07 |
| konetzed | in the end it only matters to the packaging system your using | 19:07 |
| konetzed | and how your software lifecycle is | 19:07 |
| konetzed | if your using openstack versioning | 19:07 |
| konetzed | "2013.1" it doesnt matter as long as the package manager your using has the correct information to know its a update | 19:08 |
| demorris | i see | 19:08 |
| kevinconway | konetzed: we're not really worried about the package managers | 19:08 |
| konetzed | kevinconway: i have no clue what your worried about | 19:08 |
| konetzed | i know in the end how the system will deal with it | 19:08 |
| kevinconway | we're talking about updating trove databases | 19:08 |
| demorris | I care more about the user experience of a user managing their updates and the provider managing them on behalf of the user | 19:09 |
| konetzed | the trove database or customer instances? | 19:09 |
| kevinconway | instances | 19:09 |
| demorris | we nee dot be able to communicate when updates are available, and what is supported, be it major or minor only | 19:09 |
| konetzed | then unless your going to rebuild the package mangers on the instances you care about the package mangers | 19:09 |
| demorris | the system needs to supper that and potentially handle rules/policies on what is allowed differently across types (MySQL vs Cassandra vs. PostgreSQL) | 19:10 |
| konetzed | demorris: I think you make it flexable enough so that you can import the correct strings in your self | 19:10 |
| konetzed | because depending on how someone does their packages it could not follow any standards | 19:11 |
| konetzed | someone could decide to give them all codenames to show up, be a pain to sync up with an opensource project but there is nothing stopping someone | 19:11 |
| demorris | yeah | 19:12 |
| kevinconway | konetzed: we just merged the datastore type and version stuff so what shows up to the user is what we put in it | 19:12 |
| demorris | i need to run | 19:12 |
| demorris | good discussion, hoping someone will pick this up | 19:12 |
| demorris | don't all jump at once :) | 19:12 |
| konetzed | kevinconway: i propose all mysql versions now be used in code names, because well im a hoster and thats what i want | 19:12 |
| konetzed | kevinconway: so i just made up my own versioning | 19:12 |
| kevinconway | konetzed: i'm not sure we're having the same conversation | 19:13 |
| konetzed | what i am saying is stop worring about the versioning its doing and build a system that can be told | 19:13 |
| konetzed | you have mysql version fuzzy and zebra is a nupdate | 19:13 |
| konetzed | an update | 19:13 |
| kevinconway | konetzed: we doo | 19:13 |
| konetzed | then why do you care what versioning they are using? | 19:13 |
| kevinconway | the question is how to present an available upgrade to users | 19:13 |
| kevinconway | and when they can perform updates that cause downtime | 19:14 |
| kevinconway | demorris: brought up versioning schemes | 19:14 |
| kevinconway | i was saying they can't be trusted to determine what is major or minor in terms of impact to product or effort to update | 19:14 |
| konetzed | i think that has to be controled by the manager of the system | 19:15 |
| kevinconway | as the provider we would be in control over how versions are presented to users | 19:15 |
| konetzed | yeas | 19:15 |
| konetzed | yes | 19:15 |
| kevinconway | question is how to tell them a newer version is available | 19:15 |
| konetzed | sorry i have really bad lag today | 19:15 |
| kevinconway | or how to let them initiate the update | 19:16 |
| konetzed | i think you just go you have "blah" and "foo" is out | 19:16 |
| kevinconway | well, major impact updates might require a lot more than just "package-manager update mydb" | 19:16 |
| kevinconway | so you couldn't go from mysql 4.0 to 5.5 without pain | 19:17 |
| konetzed | and to me thats up to the provider to decide | 19:17 |
| konetzed | its probably not a good idea to update minor revs of mysql w/o having a whole process in place | 19:17 |
| kevinconway | so let's start with this example | 19:18 |
| kevinconway | i'm a provider who offers mysql 5.1 | 19:18 |
| kevinconway | i want to allow my customers the option to update to 5.5 | 19:19 |
| kevinconway | there are backwards incompatible changes between those two versions | 19:19 |
| *** jcru has joined #openstack-trove | 19:19 | |
| kevinconway | i'm not even sure you can "package-manager update" for that | 19:19 |
| kevinconway | i just think there's a whole lot more to doing an update than running a package manager | 19:21 |
| kevinconway | the db configs change, the schema options change, the db api changes | 19:21 |
| konetzed | kevinconway: i get what your sayign but that would probably be a way more complicated change then just updating mysql anyways | 19:22 |
| konetzed | now you could have a rule engine that says if you want to go from 5.1 to 5.6 you must dump db, upgrade | 19:22 |
| konetzed | do full restore | 19:22 |
| kevinconway | right, so there is a distinction between minor impact and major impact updates | 19:23 |
| kevinconway | major impact updates probably require a backup and restore | 19:23 |
| kevinconway | so demorris question was how do we present to users the option to perform minor impact updates that may still require downtime | 19:23 |
| konetzed | kevinconway: i guess i was saying you need a way of saying that but not tying it to major minor | 19:26 |
| *** Barker has joined #openstack-trove | 19:33 | |
| *** adrian_otto has joined #openstack-trove | 19:37 | |
| *** adrian_otto has quit IRC | 19:37 | |
| *** adrian_otto has joined #openstack-trove | 19:43 | |
| *** ashestakov has quit IRC | 19:44 | |
| *** adrian_otto has quit IRC | 19:54 | |
| *** adrian_otto has joined #openstack-trove | 19:57 | |
| *** Barker has quit IRC | 19:59 | |
| *** yogesh has quit IRC | 20:01 | |
| *** yogesh has joined #openstack-trove | 20:02 | |
| *** plodronio has joined #openstack-trove | 20:02 | |
| *** tanisdl has joined #openstack-trove | 20:04 | |
| *** yogesh has quit IRC | 20:06 | |
| *** [a]mcrn is now known as amcrn | 20:06 | |
| *** jasonb365 has quit IRC | 20:07 | |
| *** Barker has joined #openstack-trove | 20:14 | |
| *** adrian_otto has quit IRC | 20:15 | |
| vipul | who knows heat? | 20:15 |
| vipul | question about auth tokens - is it possible to have heat present the original token to other components such as Nova | 20:16 |
| *** adrian_otto has joined #openstack-trove | 20:16 | |
| *** NehaV has quit IRC | 20:16 | |
| vipul | or does Heat have to always generate a new token and have some sort of Trust configured | 20:16 |
| *** jasonb365 has joined #openstack-trove | 20:19 | |
| *** vipul is now known as vipul-away | 20:19 | |
| *** vipul-away is now known as vipul | 20:19 | |
| *** NehaV has joined #openstack-trove | 20:30 | |
| *** adrian_otto has quit IRC | 20:32 | |
| *** jasonb365 has quit IRC | 20:32 | |
| *** jasonb365 has joined #openstack-trove | 20:39 | |
| amcrn | kevinconway konetzed demorris: going back to the version upgrade discussion, wouldn't https://gist.github.com/amcrn/dfd493200fcdfdb61a23 suffice? | 20:45 |
| *** vipul is now known as vipul-away | 20:48 | |
| *** ashestakov has joined #openstack-trove | 20:48 | |
| *** Barker has quit IRC | 20:51 | |
| *** vipul-away is now known as vipul | 20:51 | |
| *** yogesh has joined #openstack-trove | 20:52 | |
| *** cweid has joined #openstack-trove | 20:53 | |
| demorris | amcrn: how would the user determine if an upgrade was available? | 20:55 |
| demorris | actually, given that this is trove-manage, I assume this to solve use case 2, where the Trove operator does it, not the end user | 20:56 |
| demorris | so this does not solve use case 1, but I like it for the second use case | 20:56 |
| konetzed | amcrn: i think this works fine but it would be nice if it was a little more dynamic | 20:57 |
| *** Barker has joined #openstack-trove | 20:57 | |
| konetzed | there is no point in storing the upgrade info somwhere when you could just query for version the instance has and the current version of that update stream | 20:57 |
| konetzed | amcrn: unless i have something wrong with this something would have to constantly be updating those relationships to make sure the data wasnt out of date | 20:58 |
| demorris | konetzed: which relationships? | 20:58 |
| amcrn | well, this is merely the bookeeping table that determines whether one version is upgradeable to another, and what class/manager is responsible for the logic | 20:58 |
| amcrn | how this information is surfaced to the user, that's another story | 20:59 |
| demorris | yep | 20:59 |
| *** jasonb365_ has joined #openstack-trove | 20:59 | |
| konetzed | demorris: in amcrn example your managing relationships using foreignkeys to a version table, as soon as you published a new version you would have to update the relationships | 20:59 |
| amcrn | this is the backbone to support user-initiated upgrades, and provider-initiated upgrades, and automated upgrades | 20:59 |
| demorris | I like the manager approach because then the manager can be tasked with handling both minor, major, etc. upgrades on a per type basis | 21:00 |
| konetzed | amcrn: so your just saying all this is a mapping saying x is upgradable to y | 21:00 |
| *** jasonb365 has quit IRC | 21:00 | |
| *** jasonb365_ is now known as jasonb365 | 21:00 | |
| demorris | konetzed: yeah I understand it to be you want to upgrade from x to y and the manager would enforce if that is possible and how it does it | 21:00 |
| amcrn | "as soon as you published a new version you would have to update the relationships" => i consider this a feature, not a detractor | 21:01 |
| *** yidclare has joined #openstack-trove | 21:01 | |
| konetzed | demorris: ok i think thats was my problem i thought this was like the version an instance had to what it could be upgraded to | 21:01 |
| konetzed | amcrn: ^^^^^ | 21:01 |
| amcrn | oh | 21:01 |
| konetzed | this is saying if your running mysql 5.1.1 you could upgrade to 5.1.2 | 21:02 |
| amcrn | correct, this would be the global table of truth of which versions are allowed to upgrade to what | 21:02 |
| konetzed | and there could be entries for each of the versions higher than 5.1.1 that followed that upgrade path | 21:02 |
| konetzed | amcrn: yes then your correct having to build the relationships by hand would be a feature not a detractor, sorry for my confusion | 21:03 |
| amcrn | no worries, my gist is fairly barebones, i could have prefaced it a bit better | 21:03 |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Conductor proxies host db access for guests https://review.openstack.org/45116 | 21:03 |
| konetzed | amcrn: I like this because it completely ignores the the versioning of the packages, it is completely up to the provider to set those strings | 21:04 |
| amcrn | yep :) | 21:04 |
| amcrn | we tend to avoid upgrades in certain environments, whereas in others we let users play fast and loose with fate, so this level of configurability will work nicely for us | 21:05 |
| konetzed | and with this model you could actually have differnt upgrade versions active | 21:05 |
| konetzed | amcrn: i think i missed something what is "upgrade_manager"? | 21:07 |
| amcrn | it's a logical mapping between a key and a class name | 21:07 |
| amcrn | the pattern exists already at https://github.com/openstack/trove/blob/1cceaa11dfc4d4ae6cd68da61e0c71fc6180a515/trove/guestagent/dbaas.py#L36-L39 | 21:07 |
| amcrn | the general idea is to protect against a refactoring breaking your datamodel | 21:07 |
| datsun180b | wtf unit tests | 21:08 |
| konetzed | interesting, so this could be extened to handle cases of upgrading from mysql 5.1 to 5.5 which could require complex steps outside of normal package manager updates | 21:09 |
| amcrn | so in this particular scenario, upgrade_manager could be "mysql-5.5.x-to-mysql-5.6.x", which in the code you'd have a dict of "mysql-5.5.x-to-mysql-5.6.x' => trove…..something.upgrade.Manager | 21:09 |
| konetzed | amcrn: ^^^^ | 21:09 |
| konetzed | lol | 21:09 |
| *** NehaV has quit IRC | 21:09 | |
| konetzed | amcrn: sounds perfect IMO | 21:09 |
| konetzed | the idea at least | 21:09 |
| amcrn | ah shucks | 21:10 |
| * amcrn kicks a rock and blushes | 21:10 | |
| konetzed | amcrn: i wonder if there could be another field added, like something about risk | 21:10 |
| amcrn | 100% with you on that | 21:10 |
| konetzed | no risk in going from mysql 5.1.1 to 5.1.2 but high risk going for 5.1.1 to 5.6.1 | 21:11 |
| demorris | I'd like to see us add more meta-data to the the available versions as well | 21:11 |
| demorris | so that when you do upgrade you can see what was actually in it | 21:11 |
| konetzed | demorris: maybe a json blob to be stored with required and optional attributes | 21:11 |
| amcrn | i'm still pondering how to assess risk, how to message whether a package might be beta, whether it's supported (by the provider), etc. | 21:11 |
| demorris | perhaps that could just be a link to some package manifest | 21:11 |
| demorris | amcrn: I had a model for this in the original types/versions BP | 21:12 |
| konetzed | like a cve only not | 21:12 |
| demorris | rather than just active/inactive | 21:12 |
| amcrn | demorris: link? | 21:12 |
| demorris | there was a state field, and the idea was to have SUPPORTED, DEPRECATED, BETA, etc. | 21:12 |
| konetzed | demorris: amcrn what about adding a external url link so a provider if they wanted could include a cve type information | 21:12 |
| demorris | amcrn: it may have been clobbered in the changes to the current spec of types.. | 21:13 |
| demorris | let me see if I can dig it up | 21:13 |
| konetzed | that could hold all the metadata you wanted along with lists of feature/bug/security for that update | 21:13 |
| amcrn | konetzed: interesting, that's a clever idea | 21:13 |
| konetzed | i hate refering to it as a CVE but i figure everyone knows what those are | 21:14 |
| amcrn | i like the decoupling of the information from the actual database, because the folks writing the release notes don't need to be added to ACLs | 21:14 |
| konetzed | that is nice | 21:16 |
| amcrn | very awesome idea the more i think about it | 21:17 |
| *** jmontemayor has quit IRC | 21:17 | |
| *** NehaV has joined #openstack-trove | 21:18 | |
| amcrn | demorris: in terms of state (at least along the lines of SUPPORTED, DEPRECATED, etc.), i think there are two places where this has value. (1) is that a version itself can have a state, and (2) the migration path can have a state | 21:19 |
| demorris | yeah that makes sense | 21:19 |
| demorris | what about also if you want to put types into production but don't want to expose them to users yet? | 21:19 |
| demorris | is there a way to have hidden types? | 21:20 |
| *** vipul is now known as vipul-away | 21:20 | |
| *** vipul-away is now known as vipul | 21:20 | |
| *** jasonb365 has quit IRC | 21:20 | |
| amcrn | well, you can protect against the upgrade by not inserting a row into datastore_upgrade, but to be able to hide the version completely, all that's available right now is the ACTIVE in datastore_versions | 21:20 |
| amcrn | which isn't quite the same, because i'm imaging you'd want HIDDEN to technically be "active" in the sense it can be used by anyone, it's just hidden from Horizon + API for non-admin roles, yes? | 21:21 |
| amcrn | imaging = imagining* | 21:21 |
| *** jasonb365 has joined #openstack-trove | 21:21 | |
| demorris | yeah, I was talking more just about the base types / versions support moreso than the upgrade process | 21:21 |
| demorris | amcrn: correct, basically, they are there in the system, accessible only of you know about them and can access them | 21:21 |
| amcrn | i like it, makes sense to me | 21:21 |
| demorris | I guess another fieled would need to be added to the database to support that | 21:22 |
| demorris | "hidden" - false by default | 21:22 |
| amcrn | that would likely be helpful in scenarios in which you want to deprecate an old version, but you have an extremely valuable client that you've made an exception for | 21:23 |
| demorris | I like the thoughts here... | 21:23 |
| demorris | yeah | 21:23 |
| demorris | good discussion, I need to run... | 21:24 |
| amcrn | take it easy | 21:24 |
| demorris | who is going to run with this? | 21:24 |
| amcrn | i'll update the gist, and push it to the mailing list? | 21:24 |
| demorris | just want to make sure someone wants to pick it up, my usefulness stops at ideas… :) | 21:24 |
| demorris | yeah, sounds like a good plan | 21:25 |
| demorris | get discussion going on ML | 21:25 |
| demorris | talk to y'all soon | 21:25 |
| demorris | later | 21:25 |
| *** adrian_otto has joined #openstack-trove | 21:34 | |
| *** adrian_otto has quit IRC | 21:34 | |
| *** coolsvap has quit IRC | 21:37 | |
| *** demorris has quit IRC | 21:41 | |
| *** plodronio has quit IRC | 21:45 | |
| *** jasonb365 has quit IRC | 21:48 | |
| *** NehaV has quit IRC | 21:50 | |
| *** plodronio has joined #openstack-trove | 21:52 | |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Conductor proxies host db access for guests https://review.openstack.org/45116 | 21:53 |
| datsun180b | these unit-tests are being goofy | 22:00 |
| datsun180b | testr is caching something | 22:01 |
| cp16net | tox does not work for me because i end up being rate limited | 22:03 |
| cp16net | because the instance doesnt get out of build... | 22:03 |
| datsun180b | and for some reason testr wants my password, what is going on there | 22:05 |
| datsun180b | and i just had a failure locally because TWO random UUID4s COLLIDED. | 22:06 |
| cp16net | i notcied something about that as well | 22:06 |
| cp16net | when i ran through the first time | 22:06 |
| datsun180b | i swear something's being cached and i think it has to do with the db | 22:06 |
| *** pdmars has quit IRC | 22:06 | |
| cp16net | i just reverted to master and running the same test there | 22:06 |
| cp16net | wondering if something slipped through | 22:07 |
| datsun180b | i swear something's being cached with a timer attached | 22:07 |
| cp16net | datsun180b: maybes it wants your password to `sudo get_me_a_sandwich` | 22:08 |
| cp16net | :)( | 22:08 |
| datsun180b | Something is busted in my unit tests and I don't know why. All of a sudden I'm not allowed to create DBBackup entries, but only in one test, and not consistently | 22:12 |
| datsun180b | and no idea about this "service was not discovered" business | 22:12 |
| datsun180b | https://gist.github.com/ed-/e04d6bf6c4c910b12d30 what | 22:14 |
| amcrn | it looks like a teardown isn't cleaning up | 22:17 |
| *** NehaV has joined #openstack-trove | 22:17 | |
| cp16net | oh nos | 22:17 |
| cp16net | even master has the same issue | 22:17 |
| amcrn | the thing is, this might have been going on for awhile, but we might have not noticed due to tox being broken for a week+ due to the dependency issue | 22:18 |
| datsun180b | i thought these unit tests were supposed to start green-field every time | 22:25 |
| datsun180b | if they're reusing resource between runs we should stop that | 22:25 |
| datsun180b | i'm just rerunning tox -epy26 on trove over and over again and not getting consistent results | 22:26 |
| *** yogesh has quit IRC | 22:34 | |
| datsun180b | cp16net: did you say master has the same problem as my gist? | 22:39 |
| *** yogesh has joined #openstack-trove | 22:39 | |
| *** yogesh has quit IRC | 22:41 | |
| *** yogesh_ has joined #openstack-trove | 22:46 | |
| *** NehaV has quit IRC | 22:46 | |
| *** ashestakov has quit IRC | 22:47 | |
| datsun180b | fffffff | 22:47 |
| cp16net | datsun180b: i ddidnt see that issue but the rate limit issue i saw before | 22:53 |
| datsun180b | I'm getting the same problems in fresh code too | 22:54 |
| datsun180b | "UnboundLocalError: local variable 'mysqld_bin' referenced before assignment" OH BOY | 22:54 |
| esmute | yeah datsun180b. Im getting the same | 22:56 |
| esmute | with fresh code | 22:57 |
| datsun180b | fixing that and rerunning seems to be okay | 22:57 |
| esmute | wondering how it got past our gate | 22:57 |
| datsun180b | try https://gist.github.com/ed-/1f14b6b2a802d01e2989 this esmute | 22:57 |
| datsun180b | I'm getting other goofy testr problems, and to make things weirder, the results change if I do "sudo ls" before I rerun the tox tests | 23:00 |
| *** robertmyers has quit IRC | 23:00 | |
| datsun180b | something is asking for my root password during the testr tests | 23:00 |
| esmute | These are the testr errors im getting | 23:05 |
| esmute | https://gist.github.com/kokhang/7572827 | 23:05 |
| *** yogesh_ has quit IRC | 23:06 | |
| *** yogesh has joined #openstack-trove | 23:06 | |
| *** yogesh has quit IRC | 23:06 | |
| datsun180b | YES! you're getting the not discovered problem too | 23:06 |
| datsun180b | vindication! | 23:06 |
| clarkb | one of those looks like an unquoted string | 23:10 |
| *** Barker has quit IRC | 23:10 | |
| datsun180b | clarkb: where do you see that? | 23:16 |
| clarkb | datsun180b: https://gist.github.com/kokhang/7572827 line 9, but now I see it is actually a variable that didn't get a value assigned to it | 23:17 |
| datsun180b | gotcha, yeah. i have a fix for that one, i should just submit it | 23:18 |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Add default case for mysqld_bin https://review.openstack.org/57555 | 23:19 |
| esmute | datsun180b: I added the path where mysql lives in the candidate list. https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/mysql/service.py#L42 | 23:19 |
| esmute | Since im running tox in a macbook, the location of my mysql is different than the one in the candidate list | 23:20 |
| datsun180b | i'm on a mac too, i think i like your fix better | 23:20 |
| SlickNik | Was just talking to esmute about this. Seems silly to have a "candidate list". | 23:20 |
| esmute | It was SlickNik who recommended after i went to bug him | 23:21 |
| SlickNik | As mysql could be installed in quite a few different locations, depending on os / architecture... | 23:21 |
| openstackgerrit | Tim Simpson proposed a change to openstack/trove: Fixing typos in _create_server_volume. https://review.openstack.org/57556 | 23:22 |
| esmute | But im still getting the second error | 23:22 |
| esmute | https://gist.github.com/kokhang/7572827 | 23:22 |
| grapex | SlickNik vipul hub_cap: Please fast track this- some recent commits broke things at Rax: https://review.openstack.org/#/c/57556/ | 23:22 |
| datsun180b | so am i after addressing the mysqld_bin thing | 23:22 |
| *** kevinconway has quit IRC | 23:22 | |
| SlickNik | grapex: wow. | 23:24 |
| grapex | SlickNik: Found it in fake mode in a few seconds by changing the test conf. | 23:25 |
| grapex | We should consider adding a few more permeatations of the test conf to the tox runs, since the fake mode integration tests run in seven seconds and are perfect adept at finding stuff like this. | 23:25 |
| grapex | We could have another run that disabled volume support entirely. | 23:25 |
| grapex | SlickNik: Actually, do you guys still use that flag? | 23:26 |
| esmute | it is trying to stop a mysql instance that doesnt exist in my environment | 23:27 |
| SlickNik | Yes, we run with volume support disabled. | 23:27 |
| grapex | SlickNik: Well, for seven more seconds a tox run we could determine if anything in that path failed. | 23:27 |
| SlickNik | I think that's totally worth it. | 23:28 |
| esmute | SlickNik: +1 | 23:28 |
| grapex | SlickNik: I'll look into whipping up a pull request for it then. | 23:28 |
| SlickNik | grazie. And thanks for finding this... | 23:28 |
| *** datsun180b has quit IRC | 23:29 | |
| grapex | SlickNik: No problem. You can also show your gratitude by instantly approving it. :) | 23:29 |
| SlickNik | Am just doing that. :) | 23:29 |
| SlickNik | <3 <3 | 23:30 |
| grapex | SlickNik: Thanks! | 23:30 |
| hub_cap | grapex: what, u want that code to work?!?! | 23:30 |
| SlickNik | lol | 23:31 |
| SlickNik | too much to ask? | 23:31 |
| hub_cap | i am back from my treacherous, waterlogged trip to sfo | 23:31 |
| SlickNik | waterlogged? | 23:31 |
| SlickNik | did you swim? | 23:31 |
| hub_cap | my feet swam SlickNik | 23:32 |
| hub_cap | they held me up as i walked across the water | 23:32 |
| hub_cap | it was nasty this am, but we need the rain so i cant complain | 23:33 |
| hub_cap | maybe the 52% of the state thats not on fire will turn green again | 23:33 |
| esmute | i can picture mysql kayaking down that crooked street in San Francisco | 23:33 |
| esmute | *myself* | 23:33 |
| hub_cap | ok that makes way more sense | 23:33 |
| SlickNik | mysql is a dolphin, it needs no kayak... | 23:33 |
| openstackgerrit | A change was merged to openstack/trove: Fixing typos in _create_server_volume. https://review.openstack.org/57556 | 23:33 |
| esmute | damn autocomplete feature by my fingers | 23:34 |
| hub_cap | i tried to take my wifes family down lombard, but my niece wasnt feeling well and puked on the way up so we canned the idea | 23:34 |
| * hub_cap was sad | 23:34 | |
| esmute | hub_cap: That must have been so embarrassing for her. That place is full of tourists | 23:35 |
| hub_cap | heh ya it was in the car in a bag | 23:35 |
| hub_cap | good times | 23:35 |
| esmute | ahh ok.. inside the car.. | 23:36 |
| hub_cap | ya even better! | 23:36 |
| esmute | i feel bad for people living in those houses. They probably take a good 15 minutes to get out or come home with all the tourists there | 23:37 |
| * hub_cap does a little dance, its review time | 23:37 | |
| hub_cap | does anyone know if datsun solved his woes in review 45116 | 23:40 |
| hub_cap | SlickNik: where is your hubot fork living? id like to add a "give me a link / info to review X" | 23:41 |
| hub_cap | esmute: i bet they dont drive :) | 23:41 |
| hub_cap | does anyone know if datsun solved his woes w/ review 45116 | 23:43 |
| hub_cap | lol i wrote that 2x ^ ^ | 23:46 |
| hub_cap | does anyone know if datsun solved his woes wrt review 45116 | 23:46 |
| SlickNik | hub_cap: it's in one of my repos on github. | 23:54 |
| SlickNik | one sec | 23:54 |
| SlickNik | https://github.com/SlickNik/extrovert | 23:55 |
| hub_cap | sweet SlickNik thx | 23:55 |
| hub_cap | he seems to be gone though | 23:55 |
| SlickNik | If you push the changes to it, I can do an update to the bot. | 23:56 |
| SlickNik | oh, I can check on him | 23:56 |
| *** extrovert has joined #openstack-trove | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!