| *** annashen has joined #openstack-trove | 00:25 | |
| *** mattgriffin has quit IRC | 00:26 | |
| *** grapex_ has quit IRC | 00:29 | |
| *** sbfox has quit IRC | 00:39 | |
| *** annashen has quit IRC | 00:46 | |
| *** annashen has joined #openstack-trove | 00:46 | |
| *** annashen has quit IRC | 00:50 | |
| *** _amrith_ is now known as amrith | 01:12 | |
| amrith | peterstac, I just approved it. | 01:15 |
|---|---|---|
| *** zigo_ has joined #openstack-trove | 01:21 | |
| *** zigo has quit IRC | 01:21 | |
| *** shayneburgess has quit IRC | 01:21 | |
| *** rwsu has quit IRC | 01:23 | |
| *** radez is now known as radez_g0n3 | 01:25 | |
| *** zigo has joined #openstack-trove | 01:27 | |
| *** zigo_ has quit IRC | 01:27 | |
| jodah | amrith: Are you familiar with any requirement for partitioned data in a clustered database (mysql, mongo, etc) to be placed on nodes/VMs with location in mind - such as on the same rack? | 01:33 |
| amrith | jodah, not sure what you mean by the question. | 01:34 |
| jodah | I'm looking at node placement for different types of clusters in OpenStack, and I assume node placement could be important for Trove supported datastores. | 01:35 |
| jodah | Well, in a traditional DC you might partition a table across nodes that are physically located on the same rack, so that a query that spans nodes does not need to pull data from around the datacenter. | 01:35 |
| amrith | i.e. trove instance placecment on multiple (real) machines. | 01:35 |
| jodah | yep | 01:36 |
| amrith | i.e. where nova places the instanes? | 01:36 |
| jodah | In a cloud environment where we don't have much control over node placement - clustered trove VMs could be placed anywhere in the datacenter | 01:36 |
| jodah | yea | 01:36 |
| jodah | which could be problematic for partitioned datasets. | 01:36 |
| amrith | yes, longer conversation, could we chat about this tomorrow? | 01:36 |
| jodah | yes, please | 01:36 |
| jodah | I'll ping you | 01:36 |
| amrith | sure, thanks. | 01:37 |
| *** zigo has quit IRC | 01:46 | |
| *** zigo has joined #openstack-trove | 01:47 | |
| *** jcru has quit IRC | 01:52 | |
| *** mattgriffin has joined #openstack-trove | 01:52 | |
| *** zigo has quit IRC | 02:00 | |
| *** zigo has joined #openstack-trove | 02:00 | |
| *** amrith is now known as _amrith_ | 02:05 | |
| *** sbfox has joined #openstack-trove | 02:09 | |
| *** sbfox has quit IRC | 02:14 | |
| *** grapex has joined #openstack-trove | 02:20 | |
| *** grapex_ has joined #openstack-trove | 02:22 | |
| *** grapex has quit IRC | 02:25 | |
| openstackgerrit | Merged openstack/trove: Fix trove-tox-doc-publish-checkbuild failures https://review.openstack.org/148728 | 02:29 |
| *** erkules_ has joined #openstack-trove | 02:32 | |
| *** erkules has quit IRC | 02:34 | |
| *** mattgriffin has quit IRC | 02:36 | |
| *** annashen has joined #openstack-trove | 02:52 | |
| *** Longgeek has joined #openstack-trove | 02:55 | |
| *** grapex_ has quit IRC | 02:57 | |
| *** annashen has quit IRC | 03:08 | |
| *** annashen has joined #openstack-trove | 03:09 | |
| *** annashen has quit IRC | 03:13 | |
| *** kbyrne has quit IRC | 03:16 | |
| *** _amrith_ is now known as amrith | 03:24 | |
| *** grapex has joined #openstack-trove | 03:25 | |
| *** grapex has quit IRC | 03:28 | |
| *** grapex has joined #openstack-trove | 03:43 | |
| *** grapex_ has joined #openstack-trove | 03:59 | |
| *** bhunter71 has quit IRC | 03:59 | |
| *** grapex has quit IRC | 04:02 | |
| *** coolsvap has joined #openstack-trove | 04:12 | |
| *** sbfox has joined #openstack-trove | 04:13 | |
| *** grapex_ has quit IRC | 04:24 | |
| *** amrith is now known as _amrith_ | 04:49 | |
| *** mattgriffin has joined #openstack-trove | 05:09 | |
| *** kbyrne has joined #openstack-trove | 05:12 | |
| *** vigneshvar has joined #openstack-trove | 05:20 | |
| *** mattgriffin has quit IRC | 05:32 | |
| *** mattgriffin has joined #openstack-trove | 05:32 | |
| *** mattgriffin has quit IRC | 05:41 | |
| *** Kieleth has joined #openstack-trove | 05:59 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/trove: Imported Translations from Transifex https://review.openstack.org/145413 | 06:08 |
| *** exploreshaifali has joined #openstack-trove | 06:22 | |
| *** eghobo has joined #openstack-trove | 06:53 | |
| *** sgotliv has quit IRC | 07:11 | |
| *** grapex has joined #openstack-trove | 07:25 | |
| *** grapex has quit IRC | 07:34 | |
| *** vigneshvar has quit IRC | 07:37 | |
| *** chlong has quit IRC | 07:46 | |
| *** erkules_ is now known as erkules | 07:56 | |
| *** romainh has joined #openstack-trove | 08:18 | |
| *** sgotliv has joined #openstack-trove | 08:19 | |
| *** sgotliv_ has joined #openstack-trove | 08:26 | |
| *** sgotliv has quit IRC | 08:26 | |
| *** grapex has joined #openstack-trove | 08:26 | |
| *** exploreshaifali has quit IRC | 08:29 | |
| *** exploreshaifali has joined #openstack-trove | 08:32 | |
| *** grapex has quit IRC | 08:34 | |
| *** boblebauce has joined #openstack-trove | 08:35 | |
| *** sgotliv_ has quit IRC | 09:10 | |
| *** sgotliv_ has joined #openstack-trove | 09:26 | |
| *** grapex has joined #openstack-trove | 09:26 | |
| *** grapex has quit IRC | 09:34 | |
| *** vigneshvar has joined #openstack-trove | 09:38 | |
| *** eghobo has quit IRC | 09:41 | |
| *** sbfox has quit IRC | 09:58 | |
| *** grapex has joined #openstack-trove | 10:27 | |
| *** grapex has quit IRC | 10:34 | |
| *** tlashchova has joined #openstack-trove | 11:04 | |
| *** exploreshaifali has quit IRC | 11:17 | |
| *** Kieleth has quit IRC | 11:33 | |
| *** _amrith_ is now known as amrith | 11:53 | |
| openstackgerrit | amrith proposed openstack/trove: Address predictable temp file vulnerability https://review.openstack.org/138719 | 11:58 |
| *** kbyrne has quit IRC | 11:58 | |
| *** kbyrne has joined #openstack-trove | 11:59 | |
| *** chlong has joined #openstack-trove | 12:02 | |
| *** IanGovett has joined #openstack-trove | 12:05 | |
| *** jcru has joined #openstack-trove | 12:07 | |
| *** jcru has quit IRC | 12:31 | |
| *** grapex has joined #openstack-trove | 12:57 | |
| *** Longgeek has quit IRC | 12:58 | |
| *** grapex_ has joined #openstack-trove | 12:59 | |
| *** grapex has quit IRC | 13:03 | |
| *** newb has joined #openstack-trove | 13:04 | |
| *** grapex_ has quit IRC | 13:07 | |
| *** Longgeek has joined #openstack-trove | 13:08 | |
| *** pboros has joined #openstack-trove | 13:15 | |
| *** robertmyers has quit IRC | 13:26 | |
| *** IanGovett1 has joined #openstack-trove | 13:43 | |
| *** IanGovett has quit IRC | 13:46 | |
| *** vigneshvar has quit IRC | 13:47 | |
| *** mikehn has quit IRC | 13:54 | |
| *** mikehn has joined #openstack-trove | 13:57 | |
| *** radez_g0n3 is now known as radez | 14:00 | |
| *** grapex has joined #openstack-trove | 14:02 | |
| *** Longgeek has quit IRC | 14:08 | |
| *** exploreshaifali has joined #openstack-trove | 14:08 | |
| *** Longgeek has joined #openstack-trove | 14:09 | |
| *** grapex_ has joined #openstack-trove | 14:10 | |
| *** pmackinn has joined #openstack-trove | 14:12 | |
| *** grapex has quit IRC | 14:14 | |
| *** shayneburgess has joined #openstack-trove | 14:16 | |
| *** bhunter71 has joined #openstack-trove | 14:19 | |
| openstackgerrit | Merged openstack/trove: Use unit file to enable systemd service https://review.openstack.org/141656 | 14:19 |
| *** coolsvap is now known as coolsvap|afk | 14:25 | |
| *** shayneburgess has quit IRC | 14:25 | |
| *** mattgriffin has joined #openstack-trove | 14:29 | |
| *** coolsvap|afk is now known as coolsvap | 14:36 | |
| *** robertmyers has joined #openstack-trove | 14:48 | |
| *** jcru has joined #openstack-trove | 14:49 | |
| *** jcru has quit IRC | 14:55 | |
| *** jcru has joined #openstack-trove | 14:55 | |
| openstackgerrit | Denis M. proposed openstack/trove: Implement MongoDB clustering integration tests https://review.openstack.org/147920 | 15:00 |
| openstackgerrit | Denis M. proposed openstack/trove: Implement TM and Guest strategies for Cassandra datastore https://review.openstack.org/146146 | 15:00 |
| openstackgerrit | Denis M. proposed openstack/trove: Implement advanced MongoDB cluster actions timeout definition https://review.openstack.org/145791 | 15:00 |
| openstackgerrit | Denis M. proposed openstack/trove: Implement API strategy for Cassandra clustering https://review.openstack.org/146145 | 15:00 |
| *** thedodd has joined #openstack-trove | 15:16 | |
| *** mattgriffin has quit IRC | 15:40 | |
| openstackgerrit | Denis M. proposed openstack/trove: Implement MongoDB clustering integration tests https://review.openstack.org/147920 | 15:41 |
| *** shayneburgess has joined #openstack-trove | 15:55 | |
| *** mattgriffin has joined #openstack-trove | 15:57 | |
| openstackgerrit | Anna proposed openstack/trove-specs: Allow users to retreive guest log files https://review.openstack.org/131610 | 16:00 |
| *** pmalik has joined #openstack-trove | 16:18 | |
| *** amrith is now known as _amrith_ | 16:21 | |
| *** shayneburgess has left #openstack-trove | 16:29 | |
| *** boblebauce has quit IRC | 16:53 | |
| *** shayneburgess has joined #openstack-trove | 16:56 | |
| *** robertmyers has quit IRC | 17:03 | |
| *** robertmyers has joined #openstack-trove | 17:04 | |
| *** rwsu has joined #openstack-trove | 17:04 | |
| *** vigneshvar has joined #openstack-trove | 17:04 | |
| *** robertmyers has quit IRC | 17:05 | |
| *** robertmyers has joined #openstack-trove | 17:05 | |
| *** vigneshvar has quit IRC | 17:09 | |
| *** shayneburgess has quit IRC | 17:28 | |
| *** eghobo has joined #openstack-trove | 17:30 | |
| *** radez is now known as radez_g0n3 | 17:35 | |
| *** annashen has joined #openstack-trove | 17:45 | |
| *** thedodd has quit IRC | 17:45 | |
| openstackgerrit | Merged openstack/trove: Address predictable temp file vulnerability https://review.openstack.org/138719 | 17:51 |
| *** thedodd has joined #openstack-trove | 17:52 | |
| *** shayneburgess has joined #openstack-trove | 17:55 | |
| *** danritchie has joined #openstack-trove | 17:55 | |
| *** thedodd has quit IRC | 17:58 | |
| *** thedodd has joined #openstack-trove | 18:00 | |
| *** sbfox has joined #openstack-trove | 18:00 | |
| *** denis_makogon_ has joined #openstack-trove | 18:04 | |
| *** denis_makogon has quit IRC | 18:05 | |
| *** denis_makogon_ is now known as denis_makogon | 18:05 | |
| *** dmakogon_ has joined #openstack-trove | 18:05 | |
| *** _amrith_ is now known as amrith | 18:07 | |
| *** atomic77 has joined #openstack-trove | 18:11 | |
| *** bartash has joined #openstack-trove | 18:12 | |
| *** thedodd has quit IRC | 18:13 | |
| jodah | amrith: Picking up on yesterday's convo - do you see a need at all for Trove to be able to place VMs in certain physical locations? | 18:15 |
| jodah | ....or even to have a feature available from Nova similar to EC2's placement groups | 18:15 |
| denis_makogon | jodah, Trove uses availability zones as the only one way to place VMs | 18:16 |
| *** thedodd has joined #openstack-trove | 18:16 | |
| jodah | so you'd configure a cluster to replicate across AZs? | 18:16 |
| shayneburgess | AZ is a different concept. Many of the “big data” technologies have requirements around rack awareness and the ability to place nodes within a specific physical topology | 18:17 |
| shayneburgess | Hadoop, Vertica, etc | 18:17 |
| denis_makogon | yes, but there's no such concept in OpenStack except scheduling hints | 18:17 |
| denis_makogon | you have hints, AZs, nothing else | 18:18 |
| shayneburgess | I think Jodah is suggesting that it could be added to Nova | 18:18 |
| denis_makogon | yeah, it seems like yes | 18:18 |
| shayneburgess | and I think if it was added there are datastores that would want to take advantage of it | 18:18 |
| jodah | Right now does trove place replicas in diff AZs? | 18:18 |
| jodah | ...for mongo or mysql clusters | 18:19 |
| SlickNik | jodah: Right now trove forwards the AZ hints on to nova | 18:19 |
| jodah | for the placement of replicas? | 18:19 |
| SlickNik | jodah: The cluster create takes node information that can include AZ information. | 18:19 |
| jodah | how does it use it? | 18:19 |
| SlickNik | It just forwards the info to nova when doing the instance create call to the nova-client. | 18:20 |
| *** exploreshaifali has quit IRC | 18:20 | |
| jodah | Are MySQL or Mongo configured to replicate to those nodes in diff AZs? | 18:20 |
| shayneburgess | Jodah: it’s completely up to the user which AZs the replicas are placed in | 18:21 |
| shayneburgess | it can be the same or different | 18:21 |
| shayneburgess | and there are good scenarios for both choices | 18:21 |
| jodah | Are there any docs that mention how to create a cluster across AZs? | 18:23 |
| *** amrith is now known as _amrith_ | 18:24 | |
| denis_makogon | jodah, for now mongodb clusters provisioned through Trove are placed on the same AZ | 18:26 |
| *** _amrith_ is now known as amrith | 18:26 | |
| denis_makogon | but as i can foresee, at the end of the Kilo we'd provide an ability to deploy clusters within multiple zones | 18:26 |
| shayneburgess | jodah: were you asking about clusters or replicas? | 18:27 |
| denis_makogon | shayneburgess, i guess both | 18:27 |
| esmute | jodah: ATM only mongodb datastore support clustering... you can read up here http://docs.openstack.org/user-guide/content/set_up_clustering.html | 18:27 |
| *** romainh has left #openstack-trove | 18:27 | |
| jodah | both | 18:27 |
| jodah | Does mongo care about host placement for partition data locality? | 18:28 |
| jodah | er, shards, in mongo speak | 18:28 |
| denis_makogon | jodah, i'd yes, at least for shards, but not sure about QR and CS | 18:28 |
| jodah | QR and CS? | 18:29 |
| denis_makogon | query routes and config servers | 18:29 |
| *** pmalik has quit IRC | 18:30 | |
| *** thedodd has quit IRC | 18:31 | |
| *** pmalik has joined #openstack-trove | 18:31 | |
| *** coolsvap is now known as coolsvap|afk | 18:33 | |
| *** thedodd has joined #openstack-trove | 18:35 | |
| jodah | I wonder if creating a cluster across AZs fits well with the way Nova and Trove clients work and are configured | 18:38 |
| X019 | SlickNik, drat missed it | 18:40 |
| X019 | SlickNik, amrith sgotliv_ if you guys have any other issues with this https://review.openstack.org/#/c/131610 | 18:41 |
| X019 | is it ok if you could approve ? | 18:42 |
| vkmc | X019, hi there! we chatted about that spec a little more in today's meeting | 18:43 |
| X019 | I'll go check the logs then | 18:44 |
| vkmc | X019, I'm leaving the comments in the spec | 18:44 |
| *** amcrn has joined #openstack-trove | 18:45 | |
| *** sgotliv_ has quit IRC | 18:51 | |
| *** shayneburgess has quit IRC | 18:53 | |
| *** shayneburgess has joined #openstack-trove | 18:55 | |
| *** sbfox has quit IRC | 19:00 | |
| *** sbfox has joined #openstack-trove | 19:02 | |
| *** danritchie has quit IRC | 19:04 | |
| amrith | jodah, sorry, I've been off IRC all morning. | 19:05 |
| amrith | at this time the best one can do in trove with respect to node/instance placement is to depend on the policies within Nova | 19:05 |
| jodah | what would be ideal? | 19:06 |
| amrith | over time, I assume that as nova supports more / richer policies, we would leverage those. | 19:06 |
| amrith | I think it would be ideal to leave placement to Nova (from a layering perspective). | 19:06 |
| jodah | indeed - the reason i ask is that the proposal for Nova should include insight from the teams that will actually use the feature, like Trove, which is why I ask :) | 19:07 |
| amrith | oh, ok. | 19:07 |
| amrith | I've got a lot of ideas on that, are you the person who we should speak to on rove? | 19:08 |
| jodah | I plan to put forth a proposal, or aid with one | 19:08 |
| jodah | Sure | 19:08 |
| amrith | i.e. are you the liaison to nova? | 19:08 |
| jodah | I don't work on Nova, but I'm the one trying to push this forward a bit by looking at what different teams would need out of such a feature | 19:09 |
| *** shayneburgess has quit IRC | 19:09 | |
| jodah | I'm meeting with some Nova folks tomorrow on it and the proposal will be discussed more with them next week | 19:09 |
| amcrn | jodah: as long as your cloud has multiple azs per region, *most* don't need rack-awareness. | 19:09 |
| jodah | That's one thing I've been interested to know... whether we should just replicate across AZs and not worry about racks | 19:10 |
| jodah | Possibly the cross-AZ latency would be higher? | 19:10 |
| amcrn | az to az latency should be miniscule | 19:11 |
| jodah | I guess it depends on the use case. For Hadoop, where you're moving a lot of data around, it can have a huge impacty | 19:11 |
| jodah | Sahara has implemented rack awareness by requiring administrators to describe host->rack associations, which are then fed into Hadoop's support for rack awareness (which it uses for HDFS replication) | 19:12 |
| amcrn | that's unfortunate, such logic should exist in nova | 19:12 |
| jodah | agree | 19:12 |
| *** Longgeek has quit IRC | 19:13 | |
| amrith | not a nice thing for sahara to implement/have to implement that kind of logic. | 19:13 |
| jodah | But I'm not sure if they could get away with simply placing VMs in different AZs and making Hadoop think that AZs are racks | 19:13 |
| amrith | nova should do it. | 19:13 |
| jodah | definitely | 19:13 |
| amcrn | jodah: fwiw, in the context of trove at least, rack-awareness is mostly useful for anti-rack-affinity in placement | 19:14 |
| jodah | So that's for fault tolerance. For databases, locality comes into play though. Like for sequential Mongo shards, would it make sense to have the shards all on the same rack? | 19:14 |
| amcrn | jodah: if you want a single rack failure to take out your entire cluster | 19:14 |
| amcrn | ;) | 19:15 |
| amrith | that's a feature amcrn ;) | 19:15 |
| jodah | You'd still have replicas on diff racks, but wouldn't you also want contiguous data on the same rack? | 19:15 |
| jodah | I'm not sure if that's a thing in some of the databases Trove is interested in - which is why I'm asking | 19:16 |
| amcrn | in general, having the concept of a rack in nova, and choosing affinity or anti-affinity would be helpful for many | 19:16 |
| jodah | The alternative is where a query might need to pull data from shards/blocks/partitions that are scattered all over a datacenter, which is not ideal. | 19:16 |
| amcrn | today, there's only anti-host-affinity, which isn't quite up to the mark for what people want/need | 19:17 |
| jodah | amcrn: How about for contiguous data - could Trove possibly want rack-affinity for the placement of contiguous data on the same rack? | 19:18 |
| jodah | as opposed to having it scattered around a DC | 19:19 |
| *** eghobo has quit IRC | 19:20 | |
| jodah | The use case I'm thinking about is query performance, as opposed to fault tolerance | 19:20 |
| *** shayneburgess has joined #openstack-trove | 19:22 | |
| *** annashen has quit IRC | 19:24 | |
| *** annashen has joined #openstack-trove | 19:24 | |
| *** exploreshaifali has joined #openstack-trove | 19:25 | |
| amrith | yes jodah, I would want that. one of the things that I've worked on (not doing it now on trove but will soon) is a parallel database where I want nodes to be proximate. | 19:25 |
| amrith | not on the same phys machine though ... | 19:25 |
| *** annashen has quit IRC | 19:26 | |
| jodah | Good to know | 19:26 |
| *** annashen has joined #openstack-trove | 19:26 | |
| jodah | is this a publicly available database? I'd like to cite it in the proposal if possible | 19:26 |
| amrith | yes, open source no less, I will send you links. | 19:27 |
| amrith | http://github.com/Tesora/tesora-dve-pub | 19:28 |
| *** sgotliv has joined #openstack-trove | 19:30 | |
| jodah | Thanks | 19:31 |
| SlickNik | amrith / jodah / amcrn: Isn't an AZ in nova just a host aggregate though? So there's nothing in nova stopping you from setting up AZs for your racks. | 19:31 |
| SlickNik | "AZs" | 19:31 |
| jodah | Right and that's what sahara does | 19:32 |
| jodah | But it requires some overhead on their part | 19:32 |
| jodah | And it has some drawbacks - the list of hosts, which Sahara is basically managing, becomes stale over time as new hosts come and go | 19:33 |
| amrith | SlickNik, I'd be interested in anti-affinity support within an AZ and anti affinity within an AZ as well | 19:33 |
| jodah | Host aggregates require 1 flavor each where you boot instances into the flavor. So 1 flavor per customer cluster. Not ideal. | 19:33 |
| *** pmalik has quit IRC | 19:33 | |
| jodah | And doing host aggregate anti-affinity is hard... how to ensure that you're booting a VM into an aggregate that does NOT contain some host. | 19:34 |
| *** thedodd has quit IRC | 19:34 | |
| jodah | It requires overhead on the part of the service managing all of this information - which is not Nova. | 19:34 |
| shayneburgess | also do we have any data to suggest that when operators are setting up the DC that the AZ concept implies any phyiscal or network locality of the hosts? | 19:34 |
| jodah | I'm really curious about that as well | 19:35 |
| jodah | I've looked for guidelines on setting up an Openstack deployment, but haven't found anything yet | 19:35 |
| shayneburgess | for me AZ means things like: Same power supply and order of upgrades | 19:36 |
| SlickNik | Perhaps it makes sense for trove to support Host Aggregates in general and not just Availability Zones. | 19:36 |
| jodah | Yea it should represent a group of things behind a single point of failure | 19:36 |
| jodah | but what that point of failure is could vary | 19:36 |
| *** bartash has quit IRC | 19:36 | |
| shayneburgess | agreed. and that’s very different from host locality which is generally about latency and bandwidth guarantees between nodes | 19:36 |
| SlickNik | But yes, the anti-affinity story in general, even with host-aggregates isn't very good. | 19:36 |
| jodah | SlickNik - I think the ideal solution for some of the needs discussed above would be for Nova to support rack level affinity and anti-affinity. I'm not sure of the best way to tie those into Trove's API, but the underlying databases could use those features from Nova. | 19:37 |
| jodah | As an alternative to rack level affinity we could get away with something like EC2's placement groups (which are most likely effectively a set of hosts on the same rack) and using separate AZs for anti-affinity/fault tolerance. | 19:38 |
| jodah | I'll see what the Nova folks think the best way to go is.. | 19:38 |
| jodah | placement groups are a way of giving a set of hosts guaranteed low latency networking to each other. for a nova admin, this effectively means a set of hosts on the same rack. | 19:39 |
| jodah | ...if openstack had such a feature | 19:39 |
| openstackgerrit | Steve Leon proposed openstack/trove: Move cluster strategies to strategies/cluster https://review.openstack.org/123254 | 19:39 |
| *** bartash has joined #openstack-trove | 19:48 | |
| *** amrith is now known as _amrith_ | 19:53 | |
| *** fifieldt__ has joined #openstack-trove | 19:53 | |
| *** jodah has quit IRC | 19:54 | |
| *** jodah has joined #openstack-trove | 19:55 | |
| *** fifieldt_ has quit IRC | 19:56 | |
| X019 | hey SlickNik, sgotliv even if the admin couldn't call method | 19:59 |
| *** thedodd has joined #openstack-trove | 19:59 | |
| *** thedodd has quit IRC | 19:59 | |
| X019 | wouldn't the he able to see the logs from the swift container? | 19:59 |
| vkmc | that's certainly a good point X019 | 19:59 |
| vkmc | I didn't know that logs would be stored in Swift | 20:00 |
| *** shayneburgess has quit IRC | 20:01 | |
| *** pmalik has joined #openstack-trove | 20:03 | |
| *** bartash has quit IRC | 20:05 | |
| denis_makogon | vkmc, we do have only one remote storage - Swift | 20:11 |
| denis_makogon | but ... for example Amazon RDS allows to pull logs to specific host | 20:12 |
| denis_makogon | that might be the case for us too | 20:12 |
| vkmc | I was thinking on that denis_makogon | 20:14 |
| vkmc | like... when you pull the logs then you retrieve those to your host | 20:14 |
| denis_makogon | but there's a problem - RPC timeouts | 20:14 |
| denis_makogon | and direct streaming | 20:15 |
| denis_makogon | it may take a while | 20:15 |
| denis_makogon | how would you act if connection lost ? | 20:15 |
| denis_makogon | there are tons of question about pulling logs to host | 20:15 |
| denis_makogon | also, what about HTTPS for troveclient | 20:16 |
| denis_makogon | because everybody can use network monitors to mirror your data | 20:16 |
| denis_makogon | so, for initial implementation i'd suggest to use Swift, because it uses ACL (at least we have some sort of security) | 20:17 |
| vkmc | makes sense | 20:19 |
| vkmc | and with ACL we could forbid access to users if the switch is on | 20:20 |
| vkmc | X019 was asking what happens with the cloud admin... but unfortunately there is nothing we can do about it | 20:20 |
| *** mattgriffin has quit IRC | 20:21 | |
| *** shayneburgess has joined #openstack-trove | 20:21 | |
| *** annashen has quit IRC | 20:24 | |
| *** atomic77 has quit IRC | 20:24 | |
| *** annashen has joined #openstack-trove | 20:41 | |
| *** mattgriffin has joined #openstack-trove | 20:47 | |
| *** mattgriffin has quit IRC | 20:51 | |
| *** denis_makogon has quit IRC | 20:51 | |
| *** jcru has quit IRC | 20:53 | |
| edmondk | Hey was wondering if I could get 1 more +2 on this review: https://review.openstack.org/#/c/146732/ | 21:17 |
| amcrn | edmondk: done | 21:26 |
| edmondk | amcrn: Thanks much appreciated | 21:27 |
| amcrn | np | 21:27 |
| *** amcrn has quit IRC | 21:28 | |
| *** sbfox has quit IRC | 21:30 | |
| *** sbfox has joined #openstack-trove | 21:31 | |
| *** david-lyle has joined #openstack-trove | 21:46 | |
| *** chlong has quit IRC | 22:05 | |
| *** grapex_ has quit IRC | 22:08 | |
| dougshelley66 | slicknik, yt? | 22:11 |
| *** david-lyle has quit IRC | 22:11 | |
| *** david-lyle has joined #openstack-trove | 22:11 | |
| *** radez_g0n3 is now known as radez | 22:14 | |
| *** david-lyle has quit IRC | 22:15 | |
| SlickNik | dougshelley66: yes | 22:16 |
| dougshelley66 | I was wondering if we could chat about https://review.openstack.org/#/c/147908/ | 22:16 |
| dougshelley66 | i understand your comment - just wondered if you had an opinion as to what we should do about it | 22:17 |
| SlickNik | dougshelley66: Sure thing — was thinking about that earlier. | 22:17 |
| dougshelley66 | do we need to move the mysql datadir value to CONF file? | 22:18 |
| dougshelley66 | so that on upgrade you could add it to your guest conf and set it appropriately? | 22:19 |
| *** pboros has quit IRC | 22:19 | |
| SlickNik | dougshelley66: Perhaps something that looks at where the data is on the machine, and decide the path based on that — using the new path if no data exists. | 22:19 |
| dougshelley66 | even on first boot, some "data" exists | 22:19 |
| dougshelley66 | i.e. mysql has generally installed and would have created the initial db | 22:20 |
| dougshelley66 | but also, on an upgrade the code that handles all of that probably wouldn't run right? | 22:21 |
| dougshelley66 | i.e. the prepare method? | 22:21 |
| dougshelley66 | SlickNik, actually can you describe how you envision a guest upgrade to proceed? | 22:21 |
| peterstac | SlickNik: by 'looking at where the data is' do you mean getting it from my.cnf? | 22:22 |
| SlickNik | peterstac: Yes — that or actually inspecting the FS to see where the database data lies. | 22:23 |
| SlickNik | dougshelley66: Today a guest-upgrade involves installing a new guest agent package, and updating the guest config file. | 22:24 |
| dougshelley66 | right so if we moved the datadir location to the conf file thta would handle it, no? | 22:24 |
| dougshelley66 | i.e. during this upgrade you would add that conf setting and point it to /var/lib/mysql | 22:24 |
| dougshelley66 | which is the old location | 22:24 |
| SlickNik | dougshelley66: Yes, that should work. | 22:25 |
| dougshelley66 | ok i will work towards that | 22:25 |
| dougshelley66 | i guess what people should really do | 22:25 |
| dougshelley66 | is migrate their data to .../data so that they get the bug fix this is for | 22:26 |
| dougshelley66 | :) | 22:26 |
| dougshelley66 | i guess they would have that choice | 22:26 |
| SlickNik | Yes, they can always choose to do that and leave the conf value to /var/lib/mysql/data | 22:27 |
| dougshelley66 | SlickNik, on your description of the upgrade process. I'm assuming that is "manual" today i.e. the trove api/tm have no involvement in that | 22:27 |
| SlickNik | dougshelley66: Yes, there is no automated upgrade supported by Trove today. | 22:27 |
| dougshelley66 | SlickNik, ok thx | 22:27 |
| *** Longgeek has joined #openstack-trove | 22:36 | |
| *** Longgeek has quit IRC | 22:40 | |
| openstackgerrit | Merged openstack/python-troveclient: default endpoint_type to 'publicURL' https://review.openstack.org/146732 | 22:42 |
| *** robertmyers has quit IRC | 22:46 | |
| *** david-lyle has joined #openstack-trove | 22:58 | |
| *** david-lyle has quit IRC | 23:09 | |
| *** eghobo has joined #openstack-trove | 23:13 | |
| *** pmalik has quit IRC | 23:25 | |
| *** shayneburgess has quit IRC | 23:30 | |
| *** chlong has joined #openstack-trove | 23:33 | |
| *** shayneburgess has joined #openstack-trove | 23:37 | |
| openstackgerrit | Merged openstack/trove: Obsolete oslo-incubator modules - processutils https://review.openstack.org/141081 | 23:46 |
| *** atomic77 has joined #openstack-trove | 23:47 | |
| *** IanGovett1 has quit IRC | 23:53 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!