| *** matsuhashi has joined #openstack-trove | 00:02 | |
| *** mmcdaris has quit IRC | 00:11 | |
| *** matsuhashi has quit IRC | 00:14 | |
| *** matsuhashi has joined #openstack-trove | 00:15 | |
| *** matsuhashi has quit IRC | 00:15 | |
| *** matsuhashi has joined #openstack-trove | 00:15 | |
| *** robertmyers has quit IRC | 00:18 | |
| *** matsuhashi has quit IRC | 00:29 | |
| *** matsuhashi has joined #openstack-trove | 00:29 | |
| *** matsuhashi has quit IRC | 00:34 | |
| *** matsuhashi has joined #openstack-trove | 01:11 | |
| *** nosnos has joined #openstack-trove | 01:24 | |
| *** matsuhashi has quit IRC | 01:24 | |
| *** matsuhashi has joined #openstack-trove | 01:25 | |
| *** haomaiwang has quit IRC | 01:28 | |
| *** matsuhas_ has joined #openstack-trove | 01:29 | |
| *** matsuhashi has quit IRC | 01:32 | |
| *** matsuhas_ has quit IRC | 01:37 | |
| *** matsuhashi has joined #openstack-trove | 01:38 | |
| *** matsuhas_ has joined #openstack-trove | 01:45 | |
| *** matsuhashi has quit IRC | 01:48 | |
| *** erkules_ has joined #openstack-trove | 02:19 | |
| *** erkules has quit IRC | 02:22 | |
| *** adrian_otto has joined #openstack-trove | 02:40 | |
| *** adrian_otto has quit IRC | 03:02 | |
| *** coolsvap has joined #openstack-trove | 03:42 | |
| *** krow has joined #openstack-trove | 03:43 | |
| *** matsuhas_ has quit IRC | 03:46 | |
| *** matsuhashi has joined #openstack-trove | 03:47 | |
| *** matsuhashi has quit IRC | 03:51 | |
| *** krow has quit IRC | 04:01 | |
| *** matsuhashi has joined #openstack-trove | 04:20 | |
| *** krow has joined #openstack-trove | 04:35 | |
| *** matsuhashi has quit IRC | 04:42 | |
| *** matsuhashi has joined #openstack-trove | 04:42 | |
| *** adrian_otto has joined #openstack-trove | 04:54 | |
| *** yogeshmehra has joined #openstack-trove | 05:05 | |
| *** adrian_otto has quit IRC | 05:09 | |
| *** yogeshmehra has quit IRC | 05:29 | |
| *** yogeshmehra has joined #openstack-trove | 05:30 | |
| *** krow has quit IRC | 05:35 | |
| *** nosnos_ has joined #openstack-trove | 05:36 | |
| *** nosnos has quit IRC | 05:36 | |
| *** krow has joined #openstack-trove | 05:41 | |
| *** yogeshmehra has quit IRC | 05:43 | |
| *** yogeshmehra has joined #openstack-trove | 05:57 | |
| *** yogeshmehra has quit IRC | 06:28 | |
| *** adrian_otto has joined #openstack-trove | 06:32 | |
| *** adrian_otto has quit IRC | 06:42 | |
| *** ashestakov has joined #openstack-trove | 06:42 | |
| *** krow1 has joined #openstack-trove | 06:47 | |
| *** krow1 has quit IRC | 06:48 | |
| *** yogeshmehra has joined #openstack-trove | 06:50 | |
| *** krow has quit IRC | 06:50 | |
| *** krow has joined #openstack-trove | 06:50 | |
| *** krow1 has joined #openstack-trove | 06:52 | |
| *** matsuhashi has quit IRC | 06:54 | |
| *** krow has quit IRC | 06:55 | |
| *** matsuhashi has joined #openstack-trove | 06:56 | |
| *** nosnos_ has quit IRC | 06:56 | |
| *** nosnos has joined #openstack-trove | 06:56 | |
| *** ashestakov has quit IRC | 06:58 | |
| *** krow1 has quit IRC | 07:05 | |
| *** krow has joined #openstack-trove | 07:10 | |
| *** krow1 has joined #openstack-trove | 07:16 | |
| *** krow has quit IRC | 07:19 | |
| *** krow has joined #openstack-trove | 07:31 | |
| *** krow1 has quit IRC | 07:34 | |
| *** yogeshmehra has quit IRC | 07:41 | |
| *** yogesh has joined #openstack-trove | 07:43 | |
| *** krow1 has joined #openstack-trove | 07:45 | |
| *** krow has quit IRC | 07:49 | |
| *** krow has joined #openstack-trove | 07:55 | |
| *** krow1 has quit IRC | 07:56 | |
| *** krow1 has joined #openstack-trove | 07:57 | |
| *** krow has quit IRC | 08:00 | |
| *** krow1 has quit IRC | 08:08 | |
| *** matsuhashi has quit IRC | 08:13 | |
| *** matsuhashi has joined #openstack-trove | 08:14 | |
| *** matsuhashi has quit IRC | 08:15 | |
| *** matsuhashi has joined #openstack-trove | 08:15 | |
| openstackgerrit | Illia Khudoshyn proposed a change to openstack/trove: Initial support for single instance MongoDB support https://review.openstack.org/50597 | 08:16 |
|---|---|---|
| *** SnowDust has joined #openstack-trove | 08:37 | |
| openstackgerrit | Illia Khudoshyn proposed a change to openstack/trove: Fixes inconsistent usage of 'mount_point' in guestagent. https://review.openstack.org/56881 | 08:44 |
| *** nosnos has quit IRC | 08:59 | |
| *** nosnos has joined #openstack-trove | 08:59 | |
| *** nosnos has quit IRC | 09:03 | |
| *** ashestakov has joined #openstack-trove | 09:19 | |
| *** yogesh has quit IRC | 09:48 | |
| *** matsuhashi has quit IRC | 09:55 | |
| *** matsuhashi has joined #openstack-trove | 09:56 | |
| *** matsuhashi has quit IRC | 10:01 | |
| *** matsuhashi has joined #openstack-trove | 10:05 | |
| *** ikhudoshyn has quit IRC | 10:05 | |
| *** ikhudoshyn has joined #openstack-trove | 10:07 | |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Security groups workflow update https://review.openstack.org/50944 | 10:44 |
| *** matsuhashi has quit IRC | 10:47 | |
| *** matsuhashi has joined #openstack-trove | 10:47 | |
| *** matsuhashi has quit IRC | 10:52 | |
| *** matsuhashi has joined #openstack-trove | 10:54 | |
| *** erkules_ is now known as erkules | 11:08 | |
| *** matsuhashi has quit IRC | 11:13 | |
| *** matsuhashi has joined #openstack-trove | 11:14 | |
| *** matsuhashi has quit IRC | 11:19 | |
| *** SushilKM has joined #openstack-trove | 11:26 | |
| *** matsuhashi has joined #openstack-trove | 11:32 | |
| *** coolsvap has quit IRC | 12:09 | |
| *** ashestakov has quit IRC | 12:11 | |
| *** ashestakov has joined #openstack-trove | 12:37 | |
| *** coolsvap has joined #openstack-trove | 12:55 | |
| *** matsuhashi has quit IRC | 13:05 | |
| *** matsuhashi has joined #openstack-trove | 13:05 | |
| *** haomaiwang has joined #openstack-trove | 13:11 | |
| *** pdmars has joined #openstack-trove | 13:14 | |
| openstackgerrit | Denis M. proposed a change to openstack/python-troveclient: Adding ConnectionError class https://review.openstack.org/56930 | 13:27 |
| openstackgerrit | nilakhya proposed a change to openstack/trove: Externalization of heat template https://review.openstack.org/53499 | 13:29 |
| *** SnowDust has quit IRC | 13:33 | |
| *** yogesh has joined #openstack-trove | 13:48 | |
| *** yogesh has quit IRC | 13:53 | |
| *** matsuhashi has quit IRC | 13:56 | |
| *** matsuhashi has joined #openstack-trove | 13:57 | |
| *** matsuhas_ has joined #openstack-trove | 13:58 | |
| *** matsuhashi has quit IRC | 13:59 | |
| *** SushilKM has quit IRC | 14:00 | |
| *** ashestakov has quit IRC | 14:01 | |
| *** ashestakov has joined #openstack-trove | 14:01 | |
| *** cweid has joined #openstack-trove | 14:05 | |
| *** ashestakov has quit IRC | 14:05 | |
| *** ashestakov has joined #openstack-trove | 14:06 | |
| *** kevinconway has joined #openstack-trove | 14:10 | |
| *** ashestakov_ has joined #openstack-trove | 14:10 | |
| *** ashestakov has quit IRC | 14:10 | |
| *** jcru has joined #openstack-trove | 14:24 | |
| *** ashestakov has joined #openstack-trove | 14:27 | |
| *** ashestakov_ has quit IRC | 14:29 | |
| *** Barker has joined #openstack-trove | 14:33 | |
| *** amytron has joined #openstack-trove | 14:38 | |
| *** robertmyers has joined #openstack-trove | 14:42 | |
| *** ashestakov has quit IRC | 14:48 | |
| *** ashestakov has joined #openstack-trove | 14:48 | |
| *** matsuhas_ has quit IRC | 14:57 | |
| *** matsuhashi has joined #openstack-trove | 14:57 | |
| *** matsuhashi has quit IRC | 15:04 | |
| *** matsuhashi has joined #openstack-trove | 15:04 | |
| *** matsuhashi has quit IRC | 15:08 | |
| *** SushilKM has joined #openstack-trove | 15:10 | |
| *** SushilKM has quit IRC | 15:14 | |
| *** tanisdl has joined #openstack-trove | 15:25 | |
| *** SushilKM has joined #openstack-trove | 15:26 | |
| *** grapex_ has joined #openstack-trove | 15:31 | |
| *** SushilKM__ has joined #openstack-trove | 15:32 | |
| *** SushilKM has quit IRC | 15:34 | |
| *** datsun180b has joined #openstack-trove | 15:36 | |
| datsun180b | vipul SlickNik and hub_cap https://review.openstack.org/#/c/45116/ Knock knock! Who's there? CONDUCTOR, THAT'S WHO. CHOO CHOO | 15:42 |
| redthrux | can I get some core member eyes? https://review.openstack.org/#/c/55035/ Thanks grapex_, vipul, SlickNik, hub_cap | 15:47 |
| redthrux | Et. al.. | 15:47 |
| grapex_ | redthrux: +2'd, looks good | 15:57 |
| redthrux | thanks grapex_ | 15:57 |
| grapex_ | denis_makogon: Question about this pull request: https://review.openstack.org/#/c/54900 | 15:57 |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Extract suffix from req URL to avoid escaping dots https://review.openstack.org/56966 | 15:57 |
| *** SushilKM__ has quit IRC | 15:58 | |
| grapex_ | Has it really been decided by everyone (hub_cap, SlickNik, vipul) that the syntax "except:" has to be replaced with "except Exception:"? | 15:58 |
| datsun180b | that seems overly verbose | 15:58 |
| grapex_ | I don't get it- the first form means "except anything", so why not use it? I don't see where the fault is. | 15:58 |
| kevinconway | grapex_: it's a pyflakes style thing | 15:58 |
| grapex_ | Sounds pretty flakey to me | 15:59 |
| kevinconway | pylint also says except Exception: is too vague | 15:59 |
| datsun180b | maybe it's halfway to except (BlarghEx, WhargEx, BlamEx) as e | 15:59 |
| grapex_ | kevinconway: I totally get why you shouldn't use "Exception" if there's a more specific type | 15:59 |
| robertmyers | grapex_: talk to the people who setup openstack hacking | 15:59 |
| grapex_ | but this is about prefering "except Excpetion:" over "except:". I find the later better yet it appears it violates some new PEP8 rule. | 15:59 |
| datsun180b | but sometimes you just don't want to have to give your exception a nametag and put out a bowl of food on the porch for it | 15:59 |
| grapex_ | robertmyers: I already have the letter written in my head: | 16:00 |
| datsun180b | i'm with you grapex_ anyway, i know what except: means | 16:00 |
| grapex_ | robertmyers: Dearest OpenStack Hacking, You are wrong. Sincerely Tim | 16:00 |
| robertmyers | that'll do it | 16:00 |
| grapex_ | Oh well, this is bikeshedding so it doesn't matter. Still, it strikes me as dumb | 16:00 |
| grapex_ | Have they talked to Guido about removing that ability from the language? | 16:01 |
| grapex_ | robertmyers: I'm a modern day Kissinger. | 16:01 |
| kevinconway | grapex_: that would be backwards incompatible. python never does that. | 16:01 |
| grapex_ | kevinconway: What about in Python 4? | 16:01 |
| robertmyers | grapex_: remove try/except? | 16:01 |
| kevinconway | robertmyers: +1 | 16:01 |
| grapex_ | robertmyers: Remove "except:" with no type given. | 16:02 |
| grapex_ | Since apparently it isn't done in decent society. | 16:02 |
| robertmyers | lies, just in openstack | 16:02 |
| robertmyers | plenty of people use except: | 16:02 |
| grapex_ | Really though, how long is it until someone starts pushing an OpenStack specific version of Python we all have to use because everyone (read: 4 people on one important project) decided its the standard. | 16:03 |
| grapex_ | OpenStack Python: Now missing except, as well as some other weird things because it's actually some influential persons's pet project. | 16:03 |
| robertmyers | grapex_: I think you are taking the whole codeing standards a bit too far | 16:04 |
| grapex_ | I kid, I kid. Ok, I'll +2 that review. Thanks everyone. | 16:04 |
| robertmyers | it is just to be consistent | 16:04 |
| grapex_ | robertmyers: Eh, my joke is referencing a few other things besides the coding standards. :) | 16:04 |
| datsun180b | here i was about to joke about implementing our own try and except to sidestep pyflakes | 16:05 |
| denis_makogon | grapex_, hi, i was out of char a while | 16:06 |
| denis_makogon | grapex_, what kind of question? | 16:06 |
| grapex_ | denis_makogon: No worries, question solved. +2'd | 16:06 |
| denis_makogon | grapex_, oh, ok, thanks | 16:06 |
| ikhudoshyn | grapex_: Could u look at https://review.openstack.org/#/c/56881/ please. It's really tiny | 16:09 |
| *** jmontemayor has joined #openstack-trove | 16:13 | |
| ikhudoshyn | robertmyers: Hi, please see my answer @ https://review.openstack.org/#/c/50597/ | 16:15 |
| datsun180b | what's the point of specifying mount_point in the function args then? | 16:15 |
| denis_makogon | grapex_, https://review.openstack.org/#/c/56930/ - could you please review this bug ? | 16:15 |
| datsun180b | and that device.mount line is called regardless of the "if path.exists(conf.mount_point)", i bet that could be pulled right a tab and make more sense | 16:16 |
| ikhudoshyn | datsun180b: agree. there is a BP for that, https://blueprints.launchpad.net/trove/+spec/remove-mount-point-from-parameters-for-instance-prepare | 16:16 |
| datsun180b | okay. belay my second point, i think i'm getting a better scope of this | 16:16 |
| ikhudoshyn | but that's a bigger task, needs to be discussed 'coz it touches more things | 16:17 |
| ikhudoshyn | the review I presented is just a bug fix | 16:17 |
| datsun180b | and you've also already mentioned it in the comment. sorry, haven't had my coffee yet | 16:17 |
| ikhudoshyn | datsun180b: np) thanks for keeping an eye on it | 16:18 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Initial support for single instance Cassandra Database https://review.openstack.org/51884 | 16:18 |
| datsun180b | having had recent firsthand experience refactoring guestagent methods, good luck and have fun | 16:18 |
| *** plodronio has joined #openstack-trove | 16:19 | |
| ikhudoshyn | thanks, there is more I found to do, but a lil'bit later - there are some other reviews in line, not only my | 16:19 |
| robertmyers | ikhudoshyn: changed my review | 16:21 |
| ikhudoshyn | robertmyers: tnx | 16:22 |
| denis_makogon | robertmyers, i removed size check in tests (cassandra review), and i totally agree with ikhudoshyn | 16:22 |
| robertmyers | denis_makogon: I thought it was a real call and not a mock | 16:22 |
| robertmyers | I think we should have a 'real' test somewhere. But I'm fine with it like that | 16:23 |
| grapex_ | ikhudoshyn: Hi, I reviewed https://review.openstack.org/#/c/56881/ with a -2, sorry. | 16:23 |
| denis_makogon | robertmyers, no matter, size check is not valid testcase | 16:23 |
| grapex_ | I am concerned we need to have a discussion about it. You see, if you switch it to only use the config files, then you need to eliminate the argument that comes in via the RPC call. However, I'm not sure we should use the config files instead of the RPC call argument. | 16:24 |
| ikhudoshyn | grapex_: here is the bp, https://blueprints.launchpad.net/trove/+spec/remove-mount-point-from-parameters-for-instance-prepare, there is my reasoning as for proper source | 16:25 |
| datsun180b | so should the approach be to take the arg over the config if it's present? | 16:25 |
| grapex_ | ikhudoshyn: Is everyone ok with removing the mount_point parameter from prepare? | 16:25 |
| ikhudoshyn | grapex_: Would be great if u find some time to take a look, | 16:25 |
| robertmyers | denis_makogon: agreed, we should just check that it returns the correct thing when we call it, rather than testing the python object it is stored in | 16:25 |
| grapex_ | ikhuoshyn: Honestly, I think vipul and SlickNik may have more motivation to allow for vanilla images than I do. | 16:26 |
| denis_makogon | grapex_, https://blueprints.launchpad.net/trove/+spec/template-config-per-datastore | 16:26 |
| grapex_ | ikhudoshyn: However, even if we do, my -2 still stands as that argument needs to be totally removed from the code- its still in the function, and still in guestagent/api. | 16:26 |
| datsun180b | how about mount_point = mount_point if mount_point is not None else CONF.mount_point ? | 16:26 |
| grapex_ | datsun180b: That wouldn't work b/c their goal is to remove it from the RPC call. | 16:27 |
| robertmyers | how about point_mount? | 16:27 |
| kevinconway | datsun180b: what is this? javascript? | 16:27 |
| ikhudoshyn | grapex_: I can do that if everybody is fine | 16:27 |
| ikhudoshyn | got to go, be back in hour or two | 16:28 |
| datsun180b | well straight up m_p or conf.m_p wouldn't work in case m_p is deliberately '' or something | 16:29 |
| *** radez_g0n3 is now known as radez | 16:29 | |
| *** rnirmal has joined #openstack-trove | 16:31 | |
| denis_makogon | grapex_, https://review.openstack.org/#/c/52905/ - could you also take a look at this one ? | 16:32 |
| *** yidclare has joined #openstack-trove | 16:35 | |
| openstackgerrit | Andrey Shestakov proposed a change to openstack/trove-integration: Add support of datastore types https://review.openstack.org/56647 | 16:39 |
| *** ashestakov has quit IRC | 16:48 | |
| *** adrian_otto has joined #openstack-trove | 16:57 | |
| robertmyers | grapex_: and everyone else can you look at this annoying bug I wish to fix: https://review.openstack.org/#/c/54149/ | 17:01 |
| robertmyers | there is no circular reference error :) | 17:01 |
| *** jmontemayor has quit IRC | 17:01 | |
| *** Barker has quit IRC | 17:01 | |
| datsun180b | robertmyers: is this the cause of the random "exceeded recursion depth" messages in otherwise healthy-looking test logs that still don't actually cause failures | 17:03 |
| robertmyers | hmm, it could be | 17:04 |
| robertmyers | but that could be another annoying bug :) | 17:04 |
| grapex_ | robertmyers: There's nothing that returns a webob.Response instead of a Fault is there? | 17:04 |
| *** ashestakov has joined #openstack-trove | 17:04 | |
| robertmyers | grapex_: no, not in our wsgi | 17:04 |
| robertmyers | we specifically catch everything and return a Fault | 17:05 |
| grapex_ | robertmyers: Alrighto | 17:05 |
| robertmyers | grapex_: see line 315 to 343 | 17:06 |
| robertmyers | I think pecan will fix all these issues ;) | 17:08 |
| *** jmontemayor has joined #openstack-trove | 17:08 | |
| datsun180b | robertmyers: not you too! | 17:09 |
| robertmyers | datsun180b: not I, I think we should be using tornado | 17:09 |
| robertmyers | f eventlet and webob | 17:10 |
| *** edmund has joined #openstack-trove | 17:10 | |
| datsun180b | we should just use kevinconway's bash worker pool and just route the urls via one monolithic awk script | 17:11 |
| kevinconway | datsun180b: +1 | 17:11 |
| kevinconway | datsun180b: the bash web server is still in the works | 17:11 |
| kevinconway | but we should go ahead and switch to it now | 17:11 |
| robertmyers | datsun180b: kevinconway: just use ssh | 17:11 |
| robertmyers | done | 17:11 |
| kevinconway | robertmyers: that doesn't scale | 17:11 |
| robertmyers | parallel ssh | 17:12 |
| robertmyers | done | 17:12 |
| kevinconway | the bash workers feed off rabbit queues | 17:12 |
| kevinconway | queues scale | 17:12 |
| *** Barker has joined #openstack-trove | 17:14 | |
| *** ashestakov_ has joined #openstack-trove | 17:15 | |
| *** ashestakov has quit IRC | 17:15 | |
| *** SushilKM__ has joined #openstack-trove | 17:18 | |
| *** adrian_otto has quit IRC | 17:21 | |
| *** ashestakov_ has quit IRC | 17:46 | |
| *** ashestakov has joined #openstack-trove | 17:47 | |
| *** harlowja has joined #openstack-trove | 17:59 | |
| *** SushilKM__ has quit IRC | 18:02 | |
| *** SushilKM__ has joined #openstack-trove | 18:02 | |
| *** isviridov_ has joined #openstack-trove | 18:09 | |
| *** ikhudoshyn_ has joined #openstack-trove | 18:17 | |
| *** adrian_otto has joined #openstack-trove | 18:19 | |
| *** yogesh has joined #openstack-trove | 18:20 | |
| openstackgerrit | Andrey Shestakov proposed a change to openstack/trove: Add support of datastore types https://review.openstack.org/47934 | 18:22 |
| *** cweid has quit IRC | 18:22 | |
| *** amcrn has joined #openstack-trove | 18:24 | |
| *** coolsvap has quit IRC | 18:28 | |
| ikhudoshyn_ | grapex_: ping? as for mount_point, do we really need to run it thru ML, mb just wait other stakeholders here? actually, in https://blueprints.launchpad.net/trove/+spec/remove-mount-point-from-parameters-for-instance-prepare I wrote my thoughts on it. In order to use m_p as method parameter we should provide it in more places as well. On the other hand, CONF looks to be a reliable source of the info. Also pls take into account | 18:29 |
| ikhudoshyn_ | the following considerations https://blueprints.launchpad.net/trove/+spec/template-config-per-datastore | 18:29 |
| *** grapex_ has quit IRC | 18:30 | |
| ashestakov | amcrn: https://review.openstack.org/#/c/47934/11/trove/guestagent/datastore/mysql/service.py 564L | 18:38 |
| ashestakov | i not sure we need to backup that configs at all, but we do it for safe | 18:38 |
| ashestakov | and what we should rollback it? | 18:39 |
| ashestakov | that is default configs, if our prepare step failed, the nothing will works anyway | 18:39 |
| amcrn | the idea is that if something goes wrong (i.e. the pending package can't be found on the repo, or network connectivity to the repo is sketchy) | 18:41 |
| amcrn | the old configuration file(s) are still available on disk | 18:41 |
| amcrn | and the "old" package of the service-type can be restarted | 18:42 |
| amcrn | considering the guest-upgrade code isn't in the public repo, i can't be sure, but given the way the code is structured, i imagine this same method is called in the scenario of an upgrade | 18:43 |
| ashestakov | why we need old configs? | 18:43 |
| amcrn | ex: you have mysql-5.5 installed, an upgrade is issued to bump to 5.6, but 5.6 goes missing on the repo | 18:43 |
| ashestakov | we have no upgrades | 18:44 |
| ashestakov | upgrades is next step | 18:44 |
| amcrn | if by "we" you mean you and I, yes. | 18:44 |
| amcrn | rackspace has their own | 18:44 |
| amcrn | (at least that's what I was told) | 18:44 |
| amcrn | so if you can confirm that no one's upgrade workflow is jeopardized by this patch-set, i'm a-ok | 18:45 |
| ashestakov | if prepare failed, why rx neex to restart some service? | 18:45 |
| ashestakov | id didnt saw any disagree with it, except your one | 18:45 |
| amcrn | who says they aren't calling install_if_needed(self, packages)? | 18:45 |
| amcrn | outside of prepare? | 18:45 |
| amcrn | i'm just being cautious, if you get co-sign from rackspace core folks, go for it. | 18:46 |
| amcrn | because outside of a upgrade scenario, this isn't a concern (as you rightly point out) | 18:46 |
| ashestakov | if trove takes care of pakcage install, the nin should update configs too | 18:46 |
| isviridov_ | amcrn, do you think the config keeping strategy should be discussed in ML? | 18:47 |
| ashestakov | on upgrade 55 - 56, configs can be incompatible | 18:47 |
| ashestakov | so trove should remove old configs, and setup new | 18:47 |
| isviridov_ | That review becomes bigger and bigger. Initially agreed solution becomes everything_done. | 18:49 |
| * amcrn sighs | 18:49 | |
| ikhudoshyn_ | As I can see, config backup only has a little use if any at all (if we talk about upgrades) since if package upgrade fails it can corrupt data too. So we'd rather have a backup for the whole instance, not only config | 18:50 |
| amcrn | there's a difference between a one-in-a-million corruption (considering the package maintainer should be responsible for that) vs. checking for the existence of a package on a repository and whether the repository is reachable | 18:51 |
| amcrn | before rm -rf'ing files | 18:52 |
| ikhudoshyn_ | restoring configs from backup looks like a very specific case that requires sort of black magic | 18:52 |
| amcrn | let me re-word my comment into something easily digestable: the pending package should be asserted to exist on the repo, and downloaded w/ file-size > 0 before rm rf'ing existing installations | 18:53 |
| amcrn | i don't think that's an insane premise | 18:53 |
| ashestakov | for example, we installed new versions of mysql libs, but mysql-server failed, old configs may not work, this should be fixed manually | 18:53 |
| ikhudoshyn_ | amcrn: agree on that, but that's still a possibility. So its a good idea to have a backup anyway, before upgrading an instance with live data | 18:53 |
| amcrn | what you're suggesting is the equivalent of saying "i have home owner's insurance, why bother locking my doors?" | 18:54 |
| ikhudoshyn_ | amcrn: that looks like a separate task even if we want to automate it | 18:54 |
| amcrn | we don't have an upgrade mechanism, so i'm not going to defend data integrity on behalf of other's, consider my -1 for that portion removed | 18:55 |
| ikhudoshyn_ | amcrn: not exactly, I just say that we should be very careful when finding out, whether it is a good choice to restore confs and go on | 18:55 |
| ikhudoshyn_ | amcrn: thanks for that, I do believe we still need to consider backing up the whole instance before an upgrade, sometimes | 18:56 |
| amcrn | ashestakov: the remaining issue then, is the defaulting then, correct? | 18:56 |
| ashestakov | amcrn: defaultingshould be discussed with grapex | 18:57 |
| isviridov_ | Action item: define safe upgrade flow in details | 18:57 |
| ashestakov | amcrn: lets discuss fileds deactivated and deactivated_at for versions db table | 18:57 |
| isviridov_ | amcrn, actually there are existing installation and tools above current API. That default behaviour is needed for easier integration | 18:58 |
| *** rnirmal has quit IRC | 18:58 | |
| ashestakov | amcrn: for example, for instances in nova, deleted_at is ok, coz instance is gone, but our version can be activated again | 18:59 |
| amcrn | ashestakov: all i want is a date column of some kind, either for activation or deactivation | 19:00 |
| *** yidclare has quit IRC | 19:00 | |
| amcrn | because as of now, answering the question "when did this service-type get last activated/deactivated?" is impossible to answer | 19:00 |
| *** vipul is now known as vipul-away | 19:01 | |
| amcrn | so whether you do "activated_at", "last_modified", or some variation thereof, i'm indifferent. | 19:01 |
| *** grapex has joined #openstack-trove | 19:02 | |
| amcrn | usually it's much more important/interesting to understand when something was deactivated vs. activated, hence the suggestion for the reversal, but if you do last_modified, that's decent enough i suppose | 19:02 |
| ashestakov | amcrn: is any same functionality in trove? | 19:02 |
| ashestakov | events log is complex thing, its another task | 19:03 |
| amcrn | if you're asking whether it's an established pattern, then yes it is | 19:03 |
| amcrn | no one said events log, keep it as a single updateable row | 19:03 |
| isviridov_ | grapex, will you join us? What do you think about last_modified field in db to track activation/deactivation of specific version? | 19:04 |
| ashestakov | amcrn: will you happy if i add field "last_modified" to each new table? | 19:04 |
| amcrn | lol | 19:04 |
| juice | ah while you are there can you add last modified by and created by | 19:05 |
| juice | and deleted_by | 19:05 |
| isviridov_ | wow guys it is auditing functionality already | 19:05 |
| juice | I would like to track the user that is making changes to the instances | 19:05 |
| juice | isviridov_: how so? | 19:06 |
| amcrn | juice: i can't tell if you're being sarcastic or serious considering how this conversation has been going | 19:06 |
| *** Ikhudoshyn__ has joined #openstack-trove | 19:06 | |
| juice | i just happened to glance at the irc but I was serious. sounds like I missed something "important" :) | 19:06 |
| amcrn | well, that at least makes me feel like I didn't swallow a bottle of crazy pills this morning | 19:07 |
| amcrn | ashestakov: https://bugs.launchpad.net/trove/+bug/1223217 | 19:08 |
| amcrn | this is a known problem, hence the comment in the review | 19:08 |
| isviridov_ | juice, not sure if it should be added by any adhoc idea. If we need tracking events in db let us do it as separate functionality with event types and defined format. In other way we will have mess in database. | 19:08 |
| juice | I don't think a separate events log is necessary..at least at this time | 19:09 |
| amcrn | we're all agreed there | 19:09 |
| juice | having a core set of "audit fields" which is when/who across created, modified, deleted will do this just fine | 19:09 |
| juice | created_at, created_by, modified_at, modified_by, deleted_at, deleted_by. | 19:10 |
| *** vipul-away is now known as vipul | 19:10 | |
| isviridov_ | Another review? Connected with that bug? | 19:10 |
| amcrn | no | 19:10 |
| *** grapex has quit IRC | 19:10 | |
| amcrn | it's a column or two, nothing earth shattering | 19:10 |
| juice | I created a blue print for this but we have been spending so much time in operations support there hasn't been bandwidth to implement it | 19:10 |
| juice | isviridov_ you can either delete the existing one or link to it | 19:11 |
| juice | https://blueprints.launchpad.net/trove/+spec/instance-audit-fields | 19:11 |
| isviridov_ | amcrn, we are going to implement several BP and bugs in one review. Do we need git at all? | 19:11 |
| amcrn | please stop with those comments, they add nothing to the conversation | 19:12 |
| juice | amcrn: are you talking to me? | 19:12 |
| amcrn | no, isviridov_ | 19:12 |
| amcrn | "Do we need git at all?" | 19:12 |
| amcrn | my position remains that a table should have some sort of timestamp column(s) to indicate state changes | 19:13 |
| amcrn | and considering that nearly all tables already follow this pattern, https://review.openstack.org/#/c/47934/11/trove/db/sqlalchemy/migrate_repo/versions/016_add_datastore_type.py should as well | 19:13 |
| juice | this should be best wedged into the base class of our dbmodels | 19:13 |
| juice | I am with amcrn that this should just be the standard and consistent data across all first class data object | 19:14 |
| amcrn | juice: in lieu of consistency, do you believe we should ship the table with nothing until a standard is agreed upon? or do you think we should take a stab at it? | 19:15 |
| amcrn | i think that's where the contention is | 19:15 |
| amcrn | where "nothing" == no date/timestamp columns, | 19:15 |
| juice | we should just do it. it is practical common sense | 19:16 |
| isviridov_ | amcrn, i agree that it is needed, juice also need it. But let us do it in another review in order to keep it reviewable. | 19:16 |
| juice | and it might take another release before this gets put into any core project that we would leverage any value from | 19:16 |
| juice | in the meantime we are blind without "critical" production data | 19:16 |
| juice | I think it is fair to come back and add this (sorry amcrn) since we are just talking about this now | 19:17 |
| juice | unless it was part of the original blue print | 19:18 |
| amcrn | no official database table designs were part of the blueprint, which is a large part of the problem | 19:18 |
| *** grapex has joined #openstack-trove | 19:18 | |
| juice | I am speculating that this will be a cross-cutting implementation/change to most of the data interactions in the code base and adding the newer tables into that doesn't appear to be a problem. | 19:19 |
| *** grapex has quit IRC | 19:19 | |
| juice | yes it is a bit more tech. debt but if we follow-up with a patch focused just on this issue, it might be cleaner in the end | 19:19 |
| *** grapex has joined #openstack-trove | 19:19 | |
| ikhudoshyn_ | just my 5 cent, ashestakov already had to struggle to make the review less in size, so may be it worth discussing thing that are redundant or simply wrong. It should not be an issue to add missed ones later | 19:20 |
| *** Ikhudoshyn__ has quit IRC | 19:21 | |
| ikhudoshyn_ | 15 hundred LoC is quite a number | 19:21 |
| juice | amcrn: as for reviews/blueprints going forward we might want to have a little copy and paste template that at least provides a check list of artifacts impacted by the change. | 19:21 |
| amcrn | i'll relent, but i'd like to state how it's not productive to green-light blueprints that aren't fully baked (in my opinion), allow folks to push patch-sets, and then guilt trip reviewers that they're inhibiting progress. if more due diligence was done upfront, then this churn would have never happened. | 19:22 |
| juice | Does this affect configuration, if so what? Does this affect the database? API? | 19:22 |
| amcrn | juice: i think that's a great step forward | 19:22 |
| juice | Where would be a good place to post this? I think the blue print template itself is locked down though it would be awesome if we could customize | 19:23 |
| *** ashestakov has quit IRC | 19:26 | |
| juice | The content of a blue print was never really discussed and I don't want to create a huge bureaucratic process but I think at least questions or prompts will help engineers know what is critical in including in their proposal. | 19:26 |
| amcrn | probably would have to be a wiki (like https://wiki.openstack.org/wiki/Trove) | 19:27 |
| *** demorris has joined #openstack-trove | 19:28 | |
| amcrn | it's definitely not about adding red tape, but about documenting established patterns and guidelines to avoid churn on both ends (author and reviewer) | 19:28 |
| grapex | isviridov_ amcrn: Sorry guys, my connection crapped out while I was at lunch so I missed the start of this conversation. | 19:28 |
| grapex | amcrn: I feel like I agree with you, but I don't think I could ever know whether I'd agree with a feature based soley on the blueprint. Often I think the blueprint sounds ok and then find myself not liking the pull request. | 19:29 |
| juice | That works - I'll draft up something in a gist from which we can form a template for our blueprints going forward | 19:29 |
| amcrn | fair enough, but adding timestamp columns to a table is one of those things that can be set in stone for the 99% scenario. | 19:29 |
| amcrn | grapex: the one thing that ashestakov and myself were needing you for was a clarification on why there's a need for default_datastore | 19:30 |
| amcrn | the reason being is that the question came up: should the user be able to provide just a datastore-version (if default_datastore is set to a non-None/empty-string value) | 19:31 |
| grapex | amcrn: Users of the MySQL API would appreciate it- it would allow for backwards compatability instead of a breaking change to the API | 19:32 |
| vipul | late to the party.. but the base model already assumes you have those, and handles everything for you https://github.com/openstack/trove/blob/master/trove/db/models.py#L63 | 19:32 |
| *** ashestakov has joined #openstack-trove | 19:32 | |
| juice | so looking at part of the inconsistency in naming is that "deleted" is a boolean where "updated" is a timestamp | 19:33 |
| ikhudoshyn_ | grapex:, vipul: i'd like to get back to mount_point if u don't mind | 19:33 |
| juice | and thus the inconsistent "deleted_at" | 19:33 |
| vipul | juice: yea, that's going to be a painful migration -- although one we should do | 19:34 |
| grapex | ikhudoshyn_: Sure- if everyone is cool with taking it out of the RPC that's fine with me. | 19:34 |
| vipul | ikhudoshyn_: which review is this | 19:34 |
| grapex | ikhudoshyn_: However, you need to actually remove that argument from the RPC calls everywhere they're referenced. | 19:35 |
| amcrn | grapex: makes sense. so let's assume for a second that default_datastore is "mysql". if the user provides *just* the datastore-version in the request payload as the uuid/pk, should the underlying datastore-type of said uuid be validated against the default_datastore to make sure there weren't any misconceptions? | 19:35 |
| ikhudoshyn_ | grapex: sure | 19:35 |
| ikhudoshyn_ | vipul: just a sec | 19:35 |
| ikhudoshyn_ | vipul: https://blueprints.launchpad.net/trove/+spec/remove-mount-point-from-parameters-for-instance-prepare | 19:35 |
| amcrn | grapex: or should the default_datastore be completely ignored in the case of a datastore-version uuid, but consulted in the case of a datastore-version name? | 19:36 |
| vipul | amcrn: I do think it's a bit odd to just specify a version | 19:36 |
| amcrn | vipul: i'm not a fan of it myself | 19:37 |
| *** yidclare has joined #openstack-trove | 19:37 | |
| vipul | having a default in case nothing is provided is fine, and suffices for backwards compatibility | 19:37 |
| vipul | but I think we should require that a name / version both be provided.. or just the name, and the default version gets picked | 19:38 |
| grapex | amcrn: I get it... I think the default datastore should be ignored. It should use the datastore associated with the datastore-version. | 19:38 |
| grapex | vipul: I still don't get why a version ID alone is insufficient. | 19:38 |
| amcrn | grapex: it's not insufficient, it's just mildly confusing in that the validation permutations increase | 19:39 |
| grapex | I mean I get why people should be allowed to specify the type- but if they're passing in an ugly GUID for the version, they are undoubtably certain of the type. | 19:39 |
| vipul | it definitely is, accoridng to how we model it.. but I think it's not an intuitive experience | 19:39 |
| grapex | amcrn: Just add a few integration tests and we'll be fine forever. | 19:39 |
| * datsun180b Statler & Waldorf laughs | 19:40 | |
| amcrn | so if a user sends "1.2.2", that's a name and it should be looked up in conjunction with default_datastore. but if it's a uuid, then default_datastore should be ignored. | 19:40 |
| amcrn | and if a user just sends in nothing, it uses default_datastore (plus it's set default version, if it has one) | 19:40 |
| amcrn | and if a user sends in a datastore-name, then the version is optional (assuming the default version is set) | 19:41 |
| grapex | amcrn: I like it | 19:41 |
| grapex | Yeah, I meant the type would only be looked up if it was the UUID | 19:41 |
| *** jcooley_ has joined #openstack-trove | 19:41 | |
| vipul | -1 on allowing sending both a name or uuid | 19:41 |
| vipul | if we are saying that just a version suffices.. then it should always be uuid | 19:41 |
| grapex | Honestly, this *IS* a bit confusing, in that there will be some if statements and stuff, but honestly it won't take that long and I think people will appreciate it. | 19:41 |
| amcrn | grapex: it works, i just think it's a bit confusing to explain | 19:42 |
| amcrn | one more scenario then, what if the user sends in a datastore-version uuid, but also sends in a datastore-type, and the datastore-type definitely does *not* match the datastore-version-uuid's underlying type | 19:42 |
| amcrn | should the datastore-type be silently ignored, or should it be validated | 19:42 |
| ikhudoshyn_ | +1 for validating, no silencing | 19:43 |
| grapex | vipul: I won't cry if we only allow the version ID UUID. | 19:43 |
| amcrn | (by the way, i have opinions on which way it should go, i'm just facilitating the discussion) | 19:43 |
| vipul | datastore-type is either meaningful or not -- if we can boot things with just that, i say we always make it meaningful and validate | 19:44 |
| grapex | vipul: Agreed... I'm kind of getting confused on what the points of contention are. :) | 19:44 |
| amcrn | alright, we all agree then that with: | 19:45 |
| grapex | vipul: Though I know you want *only* version UUIDs, and not version names. I think that's OK. | 19:45 |
| amcrn | [11:42:52] <amcrn> one more scenario then, what if the user sends in a datastore-version uuid, but also sends in a datastore-type, and the datastore-type definitely does *not* match the datastore-version-uuid's underlying type | 19:45 |
| amcrn | that it should be validated? | 19:45 |
| vipul | i want to reduce the permutations | 19:45 |
| ashestakov | who would uuid and names for datastores? | 19:45 |
| grapex | As long as we can also only specify a datastroe-type as I think that's another compelling usecase. | 19:45 |
| grapex | amcrn: Here's an idea- what if we only allow them to send the datastore_version or datastore_type, but never both? | 19:46 |
| juice | that's possible to enforce at least at the schema level :) | 19:46 |
| * amcrn ponders | 19:46 | |
| ashestakov | i recall, was usecase when user can specify name same as uuid | 19:46 |
| amcrn | well, that does remove the ability of the user to use human-friendly names for both fields | 19:47 |
| amcrn | datastore=mysql, version=5.5 | 19:47 |
| vipul | it's more intiutive to allow version_name to be provided.. but not if we say version alone is enough | 19:47 |
| vipul | what about making them both required? it removes all ambiguity -- and allows the user to use freindly names or uuid whatever they want | 19:48 |
| grapex | vipul: Not really. It's like with people- assuming Social Security numbers were unique, you could specify a person by their full name, or by their SSN | 19:48 |
| ashestakov | vipul: if user wants specify only version, the he know what he do | 19:48 |
| vipul | ashestakov: sure -- what if we don't allow version to be a standalone thing though.. | 19:49 |
| amcrn | not providing either is reasonable, and only providing the datastore-type is reasonable, but all other scenarios should require providing both (imo) | 19:49 |
| ashestakov | vipul: get default type, and validate if version belongs to that type | 19:50 |
| amcrn | the only negative of the approach I mentioned above is that it seems a bit silly that the type has to be provided if the version is a uuid | 19:51 |
| vipul | Yea, let's not expose the ID in the API.. it's a friendly name only to the user | 19:51 |
| vipul | so you may have 5.5 under mysql as well as something else | 19:51 |
| ikhudoshyn_ | vipul: I like it, just sticking to names, no UUIDs | 19:52 |
| amcrn | vipul: how does one describe a version in the api without a uuid? by the name/label? | 19:52 |
| vipul | if nothing is provided.. then we use default datastore type and default version | 19:52 |
| vipul | it already have a name like '5.5' | 19:52 |
| amcrn | so GET /datastore/1-2-3-4/versions/5.5, correct? | 19:53 |
| vipul | yes | 19:53 |
| vipul | it alone is only informational.. but you always have to have a datastore_type to use it | 19:53 |
| amcrn | i'm not against the idea, though i've never seen a label in openstack on restful apis (it's very uuid-centric) | 19:53 |
| hub_cap | datsun180b: another place with dots in the urls :) | 19:53 |
| datsun180b | lucky for you it's a common function | 19:53 |
| vipul | sure, but there is no point in this having a UUID since you can't really have dupes | 19:54 |
| datsun180b | hub_cap: by the way, take a gander at the review this morning, the robots all like it | 19:54 |
| hub_cap | link me datsun180b | 19:54 |
| amcrn | one could argue that datastore types can't have dupes either, so why not use a label vs. uuid there as well? | 19:54 |
| datsun180b | oh and of course please get some core eyeballs on conductor https://review.openstack.org/#/c/45116/ | 19:55 |
| hub_cap | ++ amcrn | 19:55 |
| datsun180b | but the dots review is https://review.openstack.org/#/c/56966/ | 19:55 |
| vipul | yea i'm ok with label there, I thought that's what we were going to do.. | 19:55 |
| vipul | datstore_type: mysql | 19:55 |
| datsun180b | i even made you a bug | 19:55 |
| amcrn | i think that's a nice approach, label for both, and the omission of both is fine, the datastore-type by itself is fine, but all other scenarios require both labels | 19:56 |
| hub_cap | datsun180b: can i have a user foo.xml ? | 19:56 |
| vipul | amcrn: +1 | 19:56 |
| datsun180b | hub_cap: of course | 19:56 |
| amcrn | and uuid's go away (at least for the end user) | 19:56 |
| vipul | I think that's a much more freindlier user experience | 19:56 |
| datsun180b | same way they do it now | 19:56 |
| hub_cap | datsun180b: ok so i can issue a delete on /users/foo.xml and it will delete foo.xml right? | 19:58 |
| hub_cap | datsun180b: can u just pass me that gist again | 19:58 |
| amcrn | agreed, can we get a consensus from everyone else? | 19:58 |
| datsun180b | no, that doesn't happen now either though | 19:58 |
| datsun180b | if you want to delete foo.xml you have to delete foo%252exml | 19:58 |
| datsun180b | that's the problem | 19:58 |
| hub_cap | how do u delete foo.xml w/ your patch? | 19:58 |
| datsun180b | same as you do now, foo%252exml | 19:59 |
| hub_cap | ah icic | 19:59 |
| datsun180b | er 252e | 19:59 |
| hub_cap | and that will actually delete user foo right? | 19:59 |
| datsun180b | delete .../users/foo.xml yes | 19:59 |
| datsun180b | https://gist.github.com/ed-/f7d1ff499fcddf721c8a examples from last week | 20:00 |
| ashestakov | vipul: grapex amcrn any consensus? | 20:00 |
| vipul | +1 i am cool with labels only | 20:01 |
| amcrn | +1 for labels for users (still have a uuid in the backing db however as the pk) | 20:01 |
| ashestakov | i missed, what is labels? | 20:01 |
| amcrn | labels == names (not uuids) | 20:02 |
| ikhudoshyn_ | no uuids for types and versions. names only allowed | 20:02 |
| ashestakov | ah, but this is already works | 20:02 |
| amcrn | [11:56:30] <amcrn> i think that's a nice approach, label for both, and the omission of both is fine, the datastore-type by itself is fine, but all other scenarios require both labels | 20:02 |
| hub_cap | so now we have 1 new error condition right? | 20:03 |
| amcrn | so the changes on your end would remove the ability to use uuid, and remove the ability to just send the version | 20:03 |
| hub_cap | ambiguous version name | 20:03 |
| vipul | ashestakov: I think we say only labels.. and that's all we expose in the API | 20:03 |
| ashestakov | amcrn: so, if only version specified, we should throw error and not pick default? | 20:03 |
| vipul | hub_cap: version name w/o type is a validation error | 20:03 |
| amcrn | ashestakov: pending grapex's blessing, yes | 20:03 |
| grapex | amcrn: Well one thing you said is you've not seen anything in OpenStack yet that uses anything but UUIDs in REST URLs, right? | 20:04 |
| *** SushilKM__ has quit IRC | 20:04 | |
| amcrn | in my limited exposure, yes, i'm relying the the experience of others to qualify that | 20:05 |
| *** plodronio_ has joined #openstack-trove | 20:05 | |
| *** jcooley_ has quit IRC | 20:05 | |
| *** plodronio has quit IRC | 20:06 | |
| *** plodronio_ is now known as plodronio | 20:06 | |
| isviridov_ | As for me any exposed entity should have UUID or it is not entity but some predefined parameter. | 20:06 |
| hub_cap | id prefer to mandate the type if you pass version, it would also make implementation easier and reduce the possiblity for ambiguous version | 20:06 |
| hub_cap | but we should argue these abotu the _next_ review, should we not? this is not deployed so we can fix the api in a few steps | 20:06 |
| vipul | v2/​{tenant_id}​/servers/​{server_id}​/metadata/​{key}​ | 20:07 |
| grapex | amcrn: one moment, brb | 20:07 |
| vipul | nova has some precedence for named resources | 20:07 |
| hub_cap | so we should try to rememeber that passing uuid's makes for static urls, and a name could change in the db | 20:08 |
| grapex | amcrn: Ok, so no one is considering using "labels" in the urls, are they? | 20:08 |
| hub_cap | and 95% of the time, a user wont be typing those in, some automation layer would be doing that | 20:08 |
| grapex | I think the URLs should be strictly UUIDs | 20:08 |
| *** SushilKM__ has joined #openstack-trove | 20:08 | |
| hub_cap | ++ | 20:08 |
| grapex | I was referring to the instance create call- that should allow, in my opinion, labels or UUIDs in a few different ways. | 20:09 |
| grapex | I don't think those permeatations would be hard to test for if it was just in the instance create call | 20:09 |
| hub_cap | sure that makes sense | 20:10 |
| hub_cap | ok so i totally came in to this convo way late | 20:10 |
| hub_cap | what are we trying to solve? | 20:10 |
| grapex | hub_cap: Data store types. | 20:10 |
| amcrn | if we're going to keep both uuid + name, the problem lies in how the validation works | 20:10 |
| hub_cap | grapex: im good at that high level ;) | 20:10 |
| grapex | amcrn: I'm just suggesting it for the create call | 20:10 |
| amcrn | grapex: i'll concede everything if as long as i provide type + version, that both should be validated against each other | 20:11 |
| grapex | amcrn: Maybe I'm missing something- why would validation be so difficult? Worst case we can't use JSON schema and have to hand roll some checks. | 20:11 |
| grapex | amcrn: seconded | 20:11 |
| amcrn | so in the scenario of a datastore-type is provided, and a datastore-version uuid is provided, if the datastore-version uuid's underlying type does not match the datastore-type provided, it will be rejected/failed | 20:12 |
| hub_cap | ok so what changes are we proposing to the current review? | 20:12 |
| amcrn | that would be the change | 20:12 |
| robertmyers | hub_cap: do you push the python-troveclient to the openstack pypi mirror? | 20:12 |
| hub_cap | thats not already the case amcrn? ok cool | 20:13 |
| hub_cap | robertmyers: i can, yes | 20:13 |
| ikhudoshyn_ | vipul: hub_cap: kindly reminding about https://blueprints.launchpad.net/trove/+spec/remove-mount-point-from-parameters-for-instance-prepare | 20:13 |
| robertmyers | well, you should see openstack-horizon | 20:13 |
| robertmyers | hub_cap: https://gist.github.com/kokhang/7534474 | 20:13 |
| amcrn | not to leave you at the altar vipul, but I can live with this ;) | 20:14 |
| ashestakov | amcrn: this validation already performs | 20:14 |
| amcrn | then why in your review do you say it doesn't | 20:14 |
| vipul | amcrn: I personally prefer names instead of uuids.. even if it's a machine doing it | 20:14 |
| vipul | but if that's against openstack or wahtever, then i'm ok | 20:14 |
| hub_cap | robertmyers: thats odd, cuz 1.0.3 is in pypi | 20:14 |
| hub_cap | oh to the openstack mirror...... | 20:15 |
| vipul | so are we back to saying that version alone is oke? | 20:15 |
| demorris | vipul, users / databases already uses names instead of uuid's | 20:15 |
| ashestakov | amcrn: https://review.openstack.org/#/c/47934/12/trove/datastore/models.py 142L | 20:15 |
| hub_cap | mordred: or clarkb would know how to validate the version mismatch on the pypi mirror, robertmyers | 20:15 |
| vipul | demorris: exactly.. why couldn' datastore_types | 20:15 |
| demorris | but that was not something we wanted to do per se, but more driven out of the fact that we did not want to maintain a mapping of users / databases outside of MySQL | 20:15 |
| demorris | because a user could always go in to MySQL directly and create / delete users... | 20:16 |
| demorris | my point is that it is not the end of the world if you use names over UUID's... | 20:16 |
| vipul | demorris: sure, and it makes sense teh way it's done | 20:16 |
| demorris | its not a RESTy... | 20:16 |
| demorris | err, as RESTy..but that does not bother me too much | 20:16 |
| grapex | demorris: We couldn't use UUIDs for the user / database calls if we wanted to | 20:16 |
| hub_cap | vipul: its more of a restful "http" references, think atom, so the uuid is kinda necessary | 20:16 |
| vipul | i thought th epoint of rest was to be able to identify a unique resource based on a URI | 20:17 |
| vipul | and whether it's name or ids or whatever.. as long as it gives back the same thing every time you call it with a URI.. it's restful | 20:17 |
| *** rnirmal has joined #openstack-trove | 20:18 | |
| hub_cap | my point is that names are possible to change, uuids generally dont change | 20:18 |
| amcrn | hub_cap: the name here though, is the internal name, not necessarily the display-name | 20:18 |
| amcrn | granted if the two diverge, that gets mildly confusing | 20:19 |
| vipul | It only changes if the deployer changes it manually | 20:19 |
| vipul | they could do the same thing with a UUID | 20:19 |
| vipul | although i do get your point | 20:19 |
| *** SushilKM__ has quit IRC | 20:19 | |
| demorris | what decision closes down discussion on this the fastest :) | 20:20 |
| amcrn | ashestakov: see below | 20:20 |
| amcrn | [13:56:06] <amcrn> i'm not sure the code is working that way, is it? | 20:20 |
| amcrn | [13:56:29] <amcrn> if I have the default_datastore set, and in the create payload I provide just the version | 20:20 |
| amcrn | [13:57:25] <ashestakov> oh, it will pick default | 20:20 |
| amcrn | so unless that's changed | 20:20 |
| ashestakov | amcrn: do you still disagree this way? | 20:22 |
| vipul | i'm ok with using uuid -- i just find that providing datastore_version alone is a bit wierd -- but if we do the validation suggested by amcrn, i think it at least reduces the number of permutations that are allowed | 20:22 |
| ashestakov | vipul: if user specified only version, then if this version not belongs to default type - error | 20:23 |
| hub_cap | ok apparently i dc'd for a good bit | 20:23 |
| *** yogesh has quit IRC | 20:24 | |
| demorris | ashestakov: have you put any thought to managing version upgrades with the new types / version code? | 20:24 |
| hub_cap | ok so it sounds like we have consensus, ya amcrn vipul? | 20:24 |
| demorris | not on the management side, but from the user perspective | 20:25 |
| amcrn | typing up a summary chart, one sec | 20:25 |
| hub_cap | amcrn: thx | 20:25 |
| ashestakov | demorris: not yet, this is next step (if we will finish current one) | 20:25 |
| hub_cap | also, id like to reiterate we should let this review go as-is since we all have seen it so many times that the code is good to go | 20:26 |
| hub_cap | and we can do a new review w/ the changes discussed today | 20:26 |
| ashestakov | hub_cap: + | 20:26 |
| hub_cap | otherwise this patch stagnates longer, and prevents otehr things like cassandra/mongo/redis from merging | 20:26 |
| ikhudoshyn_ | hub_cap: + | 20:26 |
| vipul | sure although did we decide whether updated_at/deleted_at would be in this patch or next | 20:26 |
| demorris | ashestakov: okay cool, yeah am pushing for your code to get locked up! seems close :) | 20:27 |
| hub_cap | vipul: im not sure what youre talking about, but id say next patch | 20:27 |
| amcrn | - no datastore-type/datastore-version (ok, assuming a default_datastore is set and said datastore has a default version) | 20:27 |
| amcrn | - datastore-type, no datastore-version (ok, assuming said datastore has a default version) | 20:27 |
| amcrn | - datastore-type, datastore-version name (ok) | 20:27 |
| amcrn | - datastore-type, datastore-version uuid (ok, validation is done that the underlying type from the version uuid matches that of the provided datastore-type) | 20:27 |
| amcrn | - no datastore-type, datastore-version name (ok, only if default_datastore is set) | 20:27 |
| amcrn | - no datastore-type, datastore-version uuid (ok, default_datastore is never consulted/used/etc., instead the type is derived from the version uuid) | 20:27 |
| demorris | I had submitted a blueprint (along with the original types/version blueprint) a while back to allow a user to request an update to their instance | 20:27 |
| grapex | hub_cap: I'm down on merging the current review and then remaining open to changes later. | 20:27 |
| demorris | happy to chat with you about my thoughts here when you have time, I think this one can be pretty basic to solve the use case | 20:27 |
| isviridov_ | vipul, there is BP for that https://blueprints.launchpad.net/trove/+spec/instance-audit-fields , looks like another patch | 20:28 |
| *** yogesh_ has joined #openstack-trove | 20:28 | |
| amcrn | (that summary is from a request payload perspective) | 20:28 |
| amcrn | that seems to be where we've netted | 20:28 |
| amcrn | where "datastore-type" is the name or uuid, doesn't matter | 20:29 |
| hub_cap | amcrn: awesome | 20:30 |
| hub_cap | that all makes sense to me. vipul ? | 20:30 |
| hub_cap | amcrn: can u put them in a blueprint for improving the type/version api | 20:30 |
| amcrn | not sure i follow? | 20:31 |
| hub_cap | amcrn: as in, paste them in a blueprint on launchpad | 20:31 |
| amcrn | as in, this won't necessarily be adhered to in the current review, and will be merged anyway? | 20:32 |
| *** plodronio has quit IRC | 20:32 | |
| hub_cap | amcrn: correct. itll be much saner to review these (and less bug prone) if we do it in another review | 20:32 |
| vipul | amcrn: what's the diff between the 1st case and last | 20:34 |
| amcrn | last case is the user provides a uuid of the datastore-version | 20:34 |
| amcrn | first case is they provide nothing at all (no datastore type or version) | 20:35 |
| vipul | amcrn: Ok, no version i see.. | 20:35 |
| amcrn | i'm not a fan, but it's a consensus nonetheless | 20:35 |
| vipul | hub_cap, amcrn: Ok i can live with that.. | 20:35 |
| amcrn | https://blueprints.launchpad.net/trove/+spec/datastore-type-version-followon | 20:35 |
| hub_cap | ok so there is one other thing that i wantd to discuss w amcrn wrt this review | 20:36 |
| hub_cap | let me find it in the review | 20:37 |
| vipul | isviridov_: i am wondering if we can implemnt that as 2-part.. if we rename those columns etc, i think it will take a long time to migrate db | 20:38 |
| vipul | maybe we introduce those columns first, so new things update those. and we can do an offline migration or something to move old data to the new column | 20:38 |
| hub_cap | amcrn: https://review.openstack.org/#/c/47934/10/trove/guestagent/datastore/mysql/service.py | 20:38 |
| hub_cap | there is a place where you had ashestakov do a mv {file_name} to {file_name}_UUID | 20:39 |
| hub_cap | amcrn: _clear_mysql_config | 20:39 |
| amcrn | right, let me clarify my intentions around that | 20:40 |
| hub_cap | well quickly lemme say this | 20:40 |
| amcrn | sure | 20:40 |
| hub_cap | its done during install, so the "original" configs would be the sytem installed configs and be useless anyway | 20:40 |
| amcrn | correct | 20:41 |
| amcrn | the concern was born out of the fact that there's zero validation or sanity checking around the packages string/value (which in the long run, there needs to be). in lieu of any validation, i was concerned that others were re-using the pkg install methods for guest-agent upgrade logic | 20:42 |
| hub_cap | so i dont see the need for keeping the old ones around, or mv'ing them, cuz no one woul ever try to get them back | 20:43 |
| hub_cap | ah i dont think we have any of that logic in the system yet amcrn :) | 20:43 |
| amcrn | ok, yeah, as I said in here maybe 30-60 minutes ago to ashestakov, if rackspace co-signs on saying they aren't impacted from an upgrade perspective, i'm golden | 20:44 |
| *** radez is now known as radez_g0n3 | 20:44 | |
| amcrn | (i haven't seen the internal implementation since it's not public, so i didn't want to make any assumptions on code re-use) | 20:45 |
| *** Barker has quit IRC | 20:45 | |
| vipul | oh dude, i think that breaks percona | 20:45 |
| *** jcooley_ has joined #openstack-trove | 20:45 | |
| vipul | why are we no longer catching the ProcessExecutionError | 20:45 |
| *** jcooley_ has quit IRC | 20:46 | |
| hub_cap | vipul: /me has no clue what youre talking about | 20:46 |
| vipul | :p | 20:46 |
| *** radez_g0n3 is now known as radez | 20:46 | |
| vipul | let me comment on the review | 20:47 |
| ashestakov | vipul: catch where? | 20:47 |
| amcrn | ashestakov: https://review.openstack.org/#/c/47934/10/trove/guestagent/datastore/mysql/service.py, left panel, line #720 | 20:48 |
| amcrn | (is where vipul put his comment) | 20:49 |
| vipul | crap.. wrong place | 20:49 |
| amcrn | lol | 20:49 |
| vipul | fixing it to the latest patchset | 20:49 |
| hub_cap | ok so im ready to +2 this, but vipul before we do, can u pull down his review (and supplemental redstack review) and make sure they work w/ percona | 20:49 |
| ashestakov | vipul: i tested percona lot of times, same as oracle and maria on different OSs, it works | 20:49 |
| vipul | ashestakov: Well we have a explicit comment on why we're catching that exception | 20:50 |
| vipul | and it seems that we are breaking that.. | 20:50 |
| vipul | let me pull it down and verify | 20:50 |
| vipul | before we merge | 20:50 |
| * amcrn loads up the Top Gun - Danger Zone song | 20:51 | |
| ashestakov | vipul: what version of percona you using for test? | 20:52 |
| vipul | ashestakov: 5.5 | 20:52 |
| ashestakov | vipul: ubuntu? | 20:52 |
| vipul | yep | 20:52 |
| amcrn | it looks like it might be an intermittent thing (at least from the way the comment is worded), so i doubt you'll see it on a single test | 20:52 |
| *** radez is now known as radez_g0n3 | 20:52 | |
| amcrn | s/intermittent/sporadic | 20:53 |
| ashestakov | vipul: i cant remember any problems with it | 20:53 |
| ashestakov | vipul: and if service restarts with fail, but service works, then i think its issue of start script | 20:54 |
| vipul | ashestakov: Yea it was definitely intermittent.. where sometimes it just reported as FAILED since the init script times out | 20:54 |
| vipul | ashestakov: exactly.. it definitley is the init.d script.. but if we don't catch it -- it measn we set the instance to failed | 20:54 |
| vipul | ashestakov: i'd be ok with just preversing that logic in the patchset.. | 20:55 |
| vipul | i don't see why we need to clean that up anyway | 20:55 |
| ashestakov | vipul: i can push new PS with this catch | 20:57 |
| *** denis_makogon_ has joined #openstack-trove | 20:59 | |
| vipul | ashestakov: ok i'd be ok with that | 20:59 |
| openstackgerrit | Andrey Shestakov proposed a change to openstack/trove: Add support of datastore types https://review.openstack.org/47934 | 20:59 |
| ashestakov | ^ ^ | 20:59 |
| hub_cap | ashestakov: im going to rerun the tests against yuour newest patchset | 21:01 |
| vipul | ashestakov: thanks.. just for future info when do these these massive refactors, please do look at the comments in code because we may miss sme important things like this one | 21:01 |
| ashestakov | vipul: i saw it and tested, and didnt reproduced it | 21:02 |
| ashestakov | but ok | 21:02 |
| *** yogesh_ has quit IRC | 21:02 | |
| *** denis_makogon has quit IRC | 21:03 | |
| *** denis_makogon_ is now known as denis_makogon | 21:03 | |
| *** dmakogon_ has joined #openstack-trove | 21:03 | |
| denis_makogon | hi 2 all | 21:04 |
| denis_makogon | ashestakov, what the status of your review ? | 21:04 |
| ikhudoshyn_ | you missed the whole fun)) | 21:05 |
| *** yogesh has joined #openstack-trove | 21:05 | |
| ikhudoshyn_ | he's closer than ever, but not yet. and we're still waitin' | 21:05 |
| denis_makogon | hub_cap, could you please take a look at https://review.openstack.org/#/c/52905/ ||| https://review.openstack.org/#/c/54900/ |||| https://review.openstack.org/#/c/56930/ | 21:05 |
| hub_cap | denis_makogon: the 2nd one ive already +2'd | 21:06 |
| denis_makogon | hub_cap, ah, sorry, wrong link | 21:06 |
| denis_makogon | hub_cap, what kind of problem with ashestakov 's tests ? | 21:07 |
| hub_cap | denis_makogon: just verifying | 21:07 |
| denis_makogon | hub_cap, today i've tested trove with pylint | 21:10 |
| *** adrian_otto has quit IRC | 21:11 | |
| denis_makogon | hub_cap, sad, but trove got almost 4/10 | 21:11 |
| denis_makogon | hub_cap, whole OS got 6/10 | 21:11 |
| datsun180b | yeah but what's a pylint score really mean | 21:12 |
| *** jasonb365 has joined #openstack-trove | 21:12 | |
| denis_makogon | datsun180b, mark means that code is low-documented, low test-coverage, bad func names | 21:14 |
| denis_makogon | amcrn, ping | 21:14 |
| kevinconway | it's also almost impossible to get a perfect pylint score | 21:14 |
| datsun180b | denis_makogon: i withdraw my rhetorical question | 21:14 |
| kevinconway | it has limitations for how many attributes an object can have | 21:14 |
| kevinconway | and how long variable names can be | 21:15 |
| denis_makogon | kevinconway, at leat would be better to get even 6/10 | 21:15 |
| kevinconway | denis_makogon: that's still a failing score | 21:15 |
| denis_makogon | kevinconway, pylint - is pure python =( | 21:15 |
| denis_makogon | kevinconway, yeah, i know | 21:15 |
| kevinconway | nah, it's just a particular style guide | 21:15 |
| datsun180b | oh so vipul / SlickNik i got you a puppy, its name is conductor: https://review.openstack.org/#/c/45116/ all it needs is your review and subsequent approval | 21:15 |
| kevinconway | i like pylint though | 21:15 |
| datsun180b | just throw that on the stack would you kindly | 21:16 |
| denis_makogon | datsun180b, stack ? | 21:16 |
| denis_makogon | ah | 21:16 |
| denis_makogon | datsun180b, it was for -cores | 21:16 |
| amcrn | denis_makogon: yes? | 21:16 |
| datsun180b | right, i know baz is already looking it over, tim already +2'd it, and even you gave it a +1 already, thanks! | 21:17 |
| denis_makogon | amcrn, please tell me, is it necassery to have docstring while class has pure and understandable name ? | 21:17 |
| denis_makogon | amcrn, even if it doe only "pass" ? | 21:18 |
| datsun180b | those adjectives are not well-defined and depend heavily on context that's currently unavailable | 21:18 |
| kevinconway | denis_makogon: didn't you just run pylint which forces you to docstring all classes regardless? | 21:18 |
| kevinconway | and then complain that pylint calls our code undocumented? | 21:18 |
| denis_makogon | kevinconway, there is a restrictions per class, according to them pylint decided could it be documented or not | 21:19 |
| juice | amcrn: hub_cap: datsun180b: isviridov_: based on the previous conversation around sufficient blue prints, I took a stab at outlining a prompt that would be used a template for our blue prints. The purpose of this is mostly a guide to the author and reviewer to ensure all bases are covered in the blue print and appropriate upfront consideration is given and discussed. Please feel free to revise/comment https://gist.github.com/juicegit/7534842 | 21:25 |
| juice | vipul: slicknik ^ ^ sorry brothers you too :) | 21:26 |
| *** yogesh has quit IRC | 21:26 | |
| hub_cap | juice: awesome will do | 21:27 |
| amcrn | nice, thanks juice | 21:27 |
| *** yogesh has joined #openstack-trove | 21:27 | |
| juice | happy to contribute | 21:28 |
| datsun180b | https://gist.github.com/ed-/30b34ca3cbe414ce9506 ahahaha oh pylint | 21:30 |
| datsun180b | It doesn't check that the elements are good, just present | 21:30 |
| *** yogesh has quit IRC | 21:31 | |
| datsun180b | https://gist.github.com/ed-/b44ec54b1f89ea26b34b 2ez | 21:35 |
| hub_cap | lol datsun180b | 21:35 |
| datsun180b | but seriously though my point is that score means well but isn't the final word on good, clean, understandable, or even well-documented code | 21:36 |
| juice | this is static analysis not code critique :) | 21:37 |
| juice | datsun180b I was typing that as you posted your last comment | 21:37 |
| datsun180b | that last one generates Thue-Morse sequences | 21:37 |
| *** grapex has quit IRC | 21:38 | |
| *** grapex has joined #openstack-trove | 21:38 | |
| *** jcooley_ has joined #openstack-trove | 21:43 | |
| hub_cap | ok im running int-tests on andrews code, if it passes im going to +2 it | 21:43 |
| denis_makogon | hub_cap, could you please help me with dependencies | 21:46 |
| hub_cap | sure, so when you do a git review, and have > 1 commit, it marks them as 2 reviews with dependencies | 21:46 |
| denis_makogon | hub_cap, by the way, i forgot about influence | 21:47 |
| hub_cap | ? | 21:47 |
| denis_makogon | hub_cap, vipul points me on my review on problem with touching heat stuff | 21:47 |
| denis_makogon | https://review.openstack.org/#/c/50944/ | 21:47 |
| hub_cap | so really, you need to create a branch where you have the 1 review, and rebase the newest in (or cherry-pick etc) and it will be 2 commits on that single branch | 21:47 |
| denis_makogon | i cleaned it, now there is do dependency between SnowDust's and my review | 21:48 |
| hub_cap | then u just do a git review again, and itll say "hey do you want to push 2 commits?" and you type "yes" and then you are good to go | 21:48 |
| hub_cap | gerrit / git review does the rest | 21:48 |
| denis_makogon | ah, got you | 21:48 |
| hub_cap | ok so denis_makogon where is that fix going to be? | 21:48 |
| hub_cap | the one vipul mentioned | 21:48 |
| denis_makogon | SnowDust updated his review | 21:49 |
| hub_cap | oh he did? | 21:49 |
| denis_makogon | not it deals with all heat stuff | 21:49 |
| denis_makogon | hub_cap, yes | 21:49 |
| denis_makogon | hub_cap, he did it today | 21:49 |
| hub_cap | got it | 21:50 |
| hub_cap | thx | 21:50 |
| denis_makogon | hub_cap, thanks 2 you | 21:50 |
| denis_makogon | hub_cap, now, i suppose, we have 2 sepparate reviews, without any dependencies | 21:50 |
| hub_cap | yup | 21:51 |
| hub_cap | disregard what i say :) | 21:51 |
| denis_makogon | hub_cap, if all cores are ok with SnowDust review, it would be better to megre it first, then could go mine | 21:51 |
| hub_cap | k denis_makogon | 21:54 |
| *** yogesh has joined #openstack-trove | 21:54 | |
| denis_makogon | hub_cap, could you tell us status of ashestakov 's tests ? | 21:54 |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Conductor proxies host db access for guests https://review.openstack.org/45116 | 21:54 |
| hub_cap | test_instance_returns_to_active_after_resize | 21:54 |
| hub_cap | its passed up to that, and now is waiting | 21:54 |
| hub_cap | test_instance_created OK 330.61 | 21:55 |
| denis_makogon | hub_cap, sounds like totall +2 ))) | 21:55 |
| denis_makogon | even ultimate +2))) | 21:55 |
| kevinconway | which change is being merged? | 21:55 |
| hub_cap | :) | 21:55 |
| hub_cap | kevinconway: all of them | 21:56 |
| denis_makogon | lol | 21:56 |
| kevinconway | oh boy | 21:56 |
| hub_cap | its get a pass to merge whatever u want day | 21:56 |
| denis_makogon | hub_cap, it's like christmas, but before thanksgiving day | 21:56 |
| hub_cap | yup. its a new holiday | 21:56 |
| kevinconway | mergimas? | 21:57 |
| denis_makogon | it's like black friday without any people it malls | 21:57 |
| hub_cap | lol | 21:57 |
| denis_makogon | in | 21:57 |
| amcrn | it'd truly be christmas if you bought into bitcoin at the beginning of the year | 21:57 |
| hub_cap | unless u bought 1 | 21:58 |
| *** vipul is now known as vipul-away | 21:59 | |
| hub_cap | amcrn: that bitcoin bs is crazy | 21:59 |
| hub_cap | oh so speaking of crazy | 21:59 |
| denis_makogon | hub_cap, we need robertmyers updates (backups etc) on board | 21:59 |
| hub_cap | i bought this yesterday | 22:00 |
| hub_cap | http://www.amazon.com/Acer-Chromebook-11-6-Inch-Haswell-micro-architecture/dp/B00FNPD1OY | 22:00 |
| kevinconway | i enjoy my chromebook | 22:00 |
| denis_makogon | hub_cap, for what purpose ? | 22:00 |
| hub_cap | going to install linux on it and use it for work | 22:00 |
| kevinconway | mine didn't come with Hasbro architecture though | 22:01 |
| datsun180b | i got a dell mini 9 and covered it in batman tape | 22:01 |
| denis_makogon | kevinconway, Hasbro ?))) | 22:01 |
| kevinconway | i bought the big-boy version | 22:01 |
| hub_cap | kevinconway: hasbro (haswell) advertises like 8+ hr performance | 22:01 |
| denis_makogon | kevinconway, autobot or decepticon? | 22:01 |
| hub_cap | kevinconway: did u get a acer prism? | 22:01 |
| kevinconway | i bought mine about a year ago. it's old junk now. | 22:01 |
| kevinconway | it was acer though | 22:02 |
| denis_makogon | kevinconway, why not macbook pro ? | 22:02 |
| hub_cap | ya i figure its the perfect throw away laptop | 22:02 |
| hub_cap | keep nothing on it | 22:02 |
| kevinconway | denis_makogon: that's an expensive internet browser | 22:02 |
| denis_makogon | kevinconway, nope))) | 22:02 |
| denis_makogon | kevinconway, best for design, architecturing, music, photoshop, coding | 22:03 |
| robertmyers | hub_cap: 1.4 GHz Intel Celeron ?? | 22:03 |
| kevinconway | yes well, when i become a famous DJ, street artist, and building designer I will buy one | 22:03 |
| datsun180b | photoshop is my favorite game on my mbp | 22:03 |
| hub_cap | robertmyers: hell yes | 22:03 |
| kevinconway | in the mean time i have real work to do | 22:03 |
| esmute | 16 GB Solid-State Drive? | 22:04 |
| datsun180b | magic lasso is OP, mods pls nerf | 22:04 |
| hub_cap | i do all my work on 8~16G remote machines | 22:04 |
| kevinconway | besides, windows8 is where it's at | 22:04 |
| hub_cap | why do i need a beefy proc when im running a internet browser and a terminal | 22:04 |
| kevinconway | goodby desktops and start menues | 22:04 |
| hub_cap | kevinconway: lol | 22:04 |
| esmute | hub_cap: Is it going to have a sticker in the back that reads 'My other computer is in the Cloud'? | 22:05 |
| hub_cap | esmute: it should | 22:05 |
| kevinconway | i was actually kind of sad when i installed linux on my last windows8 netbook | 22:05 |
| kevinconway | but at least i installed ubuntu which is basically same | 22:05 |
| datsun180b | what sort of cruel jokester puts w8 on a netbook | 22:05 |
| * esmute wonders if he could use the ipad air for work | 22:07 | |
| denis_makogon | esmute, only for fly killing))) | 22:08 |
| *** pdmars has quit IRC | 22:08 | |
| hub_cap | lol | 22:08 |
| esmute | denis_makogon: i really hope you're refering to an app | 22:09 |
| denis_makogon | esmute, maybe, but it's like hitting to targets with one arrow | 22:09 |
| hub_cap | esmute: it is, however, going to say chrome on it | 22:10 |
| hub_cap | http://static.acer.com/up/Resource/Acer/Chromebook/AGW2%20C/Images/20130805/C720-photo-gallery-01.png | 22:10 |
| hub_cap | its like 2.8 lb or something ungodly light | 22:10 |
| esmute | that is slick | 22:11 |
| esmute | does it have dvi output? or hdmi? | 22:12 |
| esmute | i hate the 11 inch real estate | 22:12 |
| datsun180b | i think that depends on the size of the windshield you're scraping snow off of with it | 22:12 |
| denis_makogon | hub_cap, could you update status on tests ? | 22:13 |
| *** vipul-away is now known as vipul | 22:13 | |
| esmute | denis_makogon: So should i buy this http://www.amazon.com/Amico-Vehicle-Window-Windshield-Scraper/dp/B009PNAP1M? | 22:14 |
| esmute | datsun180b: ^ | 22:14 |
| denis_makogon | esmute, lol, if you like than just go for it))) | 22:14 |
| datsun180b | for $9? what kind of memory does it have | 22:15 |
| kevinconway | or just move to southern US. no snow or ice here! | 22:15 |
| hub_cap | denis_makogon: i started them over, i lost my vpn connection and it nuked the tests (i forgot to put them in a tmux session). they are going now though in a tmux session in case i lose connection | 22:15 |
| hub_cap | esmute: hdmi | 22:15 |
| datsun180b | kevinconway: do NOT jinx it | 22:15 |
| datsun180b | we get a freeze like once every 8 years | 22:15 |
| hub_cap | pssh thats not true datsun180b | 22:15 |
| hub_cap | its like every _few_ years | 22:16 |
| kevinconway | momma always said that ice was the devil sneezin' and we so good down here that it stays nice and warm | 22:16 |
| esmute | but you guys get tornado and shit | 22:16 |
| datsun180b | i don't know, last bad one i was still in school | 22:16 |
| denis_makogon | hub_cap, ashestakov 's review robot got failed =( | 22:16 |
| esmute | when i said 'and shit' i meant to say ' and other stuff' | 22:17 |
| *** grapex_ has joined #openstack-trove | 22:17 | |
| hub_cap | lol denis_makogon yup | 22:17 |
| esmute | my intention was not to say that literally | 22:17 |
| denis_makogon | ashestakov, here ? | 22:18 |
| ashestakov | denis_makogon: yep | 22:18 |
| *** grapex has quit IRC | 22:18 | |
| denis_makogon | ashestakov, robots are crazy. =/ | 22:18 |
| hub_cap | ++ denis_makogon | 22:18 |
| ashestakov | denis_makogon: forget about them | 22:18 |
| denis_makogon | ashestakov, no way | 22:19 |
| ashestakov | hm, jenkins failed too | 22:19 |
| denis_makogon | ashestakov, that is what i told | 22:20 |
| * denis_makogon gone for a cup of tea | 22:20 | |
| *** jasonb365 has quit IRC | 22:28 | |
| openstackgerrit | Andrey Shestakov proposed a change to openstack/trove: Add support of datastore types https://review.openstack.org/47934 | 22:30 |
| *** yogesh has quit IRC | 22:34 | |
| *** jcooley_ has quit IRC | 22:38 | |
| *** yogesh has joined #openstack-trove | 22:40 | |
| openstackgerrit | Auston McReynolds proposed a change to openstack/trove: User-Create Host Does Not Allow Wildcarded Octet https://review.openstack.org/54216 | 22:41 |
| *** ikhudoshyn_ has quit IRC | 22:43 | |
| *** yogesh has quit IRC | 22:44 | |
| *** yogesh has joined #openstack-trove | 22:45 | |
| datsun180b | is is just me or are the gates slow or backed up this afternoon | 22:47 |
| hub_cap | probably both | 22:47 |
| clarkb | they are backed up | 22:48 |
| clarkb | one of the jenkinses fell over early today and that created a large enough backup that we haven't gotten over it yet | 22:49 |
| *** yogesh has quit IRC | 22:49 | |
| *** yogesh has joined #openstack-trove | 22:49 | |
| datsun180b | do you just have a highlight on "slow" or "gates" or something clarkb <3 | 22:51 |
| clarkb | no, I just read far too much irc | 22:52 |
| datsun180b | glad you do | 22:53 |
| *** yogesh has quit IRC | 22:53 | |
| *** yogesh has joined #openstack-trove | 22:58 | |
| *** robertmyers has quit IRC | 23:02 | |
| *** yogesh has quit IRC | 23:02 | |
| *** yogesh has joined #openstack-trove | 23:03 | |
| *** demorris has quit IRC | 23:06 | |
| datsun180b | whoops | 23:06 |
| datsun180b | as soon as i recheck what i thought was a dead job, it comes right back all green anyway just to spite me | 23:06 |
| *** yogesh has quit IRC | 23:08 | |
| *** grapex_ has quit IRC | 23:09 | |
| hub_cap | ok ashestakov's tests have passed. im going to +2 his reviews | 23:11 |
| datsun180b | hub_cap: me next me next ooh ooh | 23:14 |
| hub_cap | datsun180b: did u fix the -1 i had given u? | 23:15 |
| datsun180b | hub_cap: within a minute of you asking | 23:15 |
| hub_cap | if so im ready to +2 the conductor work | 23:15 |
| hub_cap | datsun180b: heh nice | 23:15 |
| datsun180b | you should expect nothing less from me | 23:15 |
| hub_cap | C-c C-o | 23:16 |
| hub_cap | you should expect nothing less from me | 23:17 |
| datsun180b | hooray | 23:19 |
| datsun180b | now to get the rest of the Justice League to help | 23:19 |
| datsun180b | my sneaky-pete changes are nearly there, just have to test it on a real vm | 23:20 |
| hub_cap | :) | 23:20 |
| *** amytron has quit IRC | 23:20 | |
| datsun180b | and i'm out | 23:22 |
| *** datsun180b has quit IRC | 23:22 | |
| esmute | hub_cap, grapex: When/if bored, can you guys look at https://review.openstack.org/#/c/54412/? | 23:24 |
| amcrn | hrm, unless i'm missing something, won't the multilpe-datastores patch-set completely break backups considering it didn't update https://review.openstack.org/#/c/52905/2/trove/guestagent/backup/backupagent.py | 23:24 |
| amcrn | ugh, nevermind, as soon as i hit enter | 23:25 |
| amcrn | i realized how stupid that question was | 23:25 |
| * amcrn sits in the corner | 23:25 | |
| *** denis_makogon has quit IRC | 23:26 | |
| *** vipul is now known as vipul-away | 23:28 | |
| openstackgerrit | A change was merged to openstack/trove: Externalization of heat template https://review.openstack.org/53499 | 23:30 |
| hub_cap | amcrn: :) | 23:30 |
| hub_cap | vipul-away: ping me when u get back | 23:31 |
| *** vipul-away is now known as vipul | 23:32 | |
| hub_cap | dmakogon_: around? | 23:33 |
| hub_cap | dmakogon_: https://blueprints.launchpad.net/trove/+spec/custom-heat-for-services | 23:34 |
| *** vipul is now known as vipul-away | 23:44 | |
| *** vipul-away is now known as vipul | 23:44 | |
| *** edmund has quit IRC | 23:45 | |
| *** vipul is now known as vipul-away | 23:54 | |
| *** vipul-away is now known as vipul | 23:54 | |
| *** vipul is now known as vipul-away | 23:55 | |
| *** vipul-away is now known as vipul | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
