*** joeljwright has joined #openstack-swift | 00:00 | |
*** joeljwright1 has joined #openstack-swift | 00:01 | |
*** joeljwright2 has joined #openstack-swift | 00:03 | |
*** joeljwright has quit IRC | 00:04 | |
*** joeljwright1 has quit IRC | 00:06 | |
*** joeljwright2 has quit IRC | 00:08 | |
*** dmsimard is now known as dmsimard_away | 00:16 | |
*** kyles_ne has joined #openstack-swift | 00:17 | |
*** gyee has quit IRC | 00:20 | |
*** lpabon has quit IRC | 00:32 | |
*** dmorita has joined #openstack-swift | 00:32 | |
*** kopparam has joined #openstack-swift | 00:33 | |
*** NM has joined #openstack-swift | 00:36 | |
*** kopparam has quit IRC | 00:38 | |
*** shri has quit IRC | 00:48 | |
*** nitika2__ has quit IRC | 00:50 | |
*** joeljwright has joined #openstack-swift | 01:02 | |
*** joeljwright has quit IRC | 01:06 | |
*** andreia_ has joined #openstack-swift | 01:08 | |
*** kyles_ne has quit IRC | 01:25 | |
*** kyles_ne has joined #openstack-swift | 01:26 | |
swift_fan | Are there companies out there that provide *only* cloud storage, | 01:28 |
---|---|---|
swift_fan | and not any other cloud services ? | 01:28 |
swift_fan | For example, you would see that Amazon has cloud storage, but also a variety of other cloud services as well. | 01:28 |
swift_fan | But are there some companies (small, medium, or large), that focus only on offering/providing cloud data storage ? | 01:29 |
*** kyles_ne has quit IRC | 01:30 | |
swift_fan | (And if there are, then are those companies mainly offering main persistent storage, or backup+archive storage) ? | 01:30 |
*** kopparam has joined #openstack-swift | 01:34 | |
*** corvus has quit IRC | 01:36 | |
*** corvus has joined #openstack-swift | 01:37 | |
*** kopparam has quit IRC | 01:39 | |
*** andreia_ has quit IRC | 01:45 | |
swift_fan | persistent* storage | 01:45 |
swift_fan | or backup+archive storage | 01:45 |
*** nosnos has joined #openstack-swift | 01:51 | |
*** NM has quit IRC | 01:59 | |
*** joeljwright has joined #openstack-swift | 02:02 | |
*** joeljwright has quit IRC | 02:06 | |
*** mrsnivvel has joined #openstack-swift | 02:09 | |
*** hhuang has joined #openstack-swift | 02:10 | |
*** NM has joined #openstack-swift | 02:14 | |
openstackgerrit | A change was merged to openstack/swift: Add a reference to the OpenStack security guide https://review.openstack.org/126709 | 02:17 |
*** swift_fan has quit IRC | 02:27 | |
*** swift_fan has joined #openstack-swift | 02:28 | |
*** NM has quit IRC | 02:35 | |
*** kopparam has joined #openstack-swift | 02:35 | |
*** kopparam has quit IRC | 02:39 | |
*** NM has joined #openstack-swift | 02:41 | |
*** NM has quit IRC | 02:53 | |
*** dmsimard_away is now known as dmsimard | 02:54 | |
*** joeljwright has joined #openstack-swift | 03:02 | |
*** occupant has quit IRC | 03:03 | |
*** joeljwright has quit IRC | 03:06 | |
*** kyles_ne has joined #openstack-swift | 03:13 | |
*** dmsimard is now known as dmsimard_away | 03:19 | |
*** oomichi has joined #openstack-swift | 03:28 | |
*** nosnos has quit IRC | 03:30 | |
*** kopparam has joined #openstack-swift | 03:36 | |
*** oomichi has quit IRC | 03:38 | |
*** kopparam has quit IRC | 03:40 | |
*** kyles_ne has quit IRC | 03:42 | |
*** kyles_ne has joined #openstack-swift | 03:43 | |
*** miqui has quit IRC | 03:44 | |
*** kyles_ne has quit IRC | 03:47 | |
*** hhuang has quit IRC | 04:00 | |
*** joeljwright has joined #openstack-swift | 04:02 | |
*** joeljwright has quit IRC | 04:06 | |
*** nosnos has joined #openstack-swift | 04:19 | |
openstackgerrit | Madhuri Kumari proposed a change to openstack/swift: Convert maximum length to integer in name_check https://review.openstack.org/125315 | 04:29 |
*** kopparam has joined #openstack-swift | 04:36 | |
*** kopparam has quit IRC | 04:42 | |
*** joeljwright has joined #openstack-swift | 05:02 | |
*** hhuang has joined #openstack-swift | 05:04 | |
*** joeljwright has quit IRC | 05:07 | |
*** kyles_ne has joined #openstack-swift | 05:22 | |
*** HenryG_ has joined #openstack-swift | 05:29 | |
*** HenryG has quit IRC | 05:30 | |
*** kopparam has joined #openstack-swift | 05:36 | |
*** zaitcev has quit IRC | 05:55 | |
*** echevemaster has quit IRC | 06:01 | |
*** joeljwright has joined #openstack-swift | 06:02 | |
*** ttrumm has joined #openstack-swift | 06:03 | |
*** ttrumm_ has joined #openstack-swift | 06:04 | |
*** joeljwright has quit IRC | 06:06 | |
*** ttrumm has quit IRC | 06:07 | |
*** oomichi has joined #openstack-swift | 06:34 | |
*** shakamunyi has joined #openstack-swift | 06:35 | |
*** joeljwright has joined #openstack-swift | 06:38 | |
*** joeljwright has quit IRC | 06:42 | |
*** kyles_ne has quit IRC | 06:43 | |
*** kyles_ne has joined #openstack-swift | 06:43 | |
*** kyles_ne has quit IRC | 06:48 | |
*** joeljwright has joined #openstack-swift | 07:02 | |
*** joeljwright has quit IRC | 07:06 | |
*** k4n0 has joined #openstack-swift | 07:08 | |
openstackgerrit | Christian Schwede proposed a change to openstack/python-swiftclient: Use skipTest from testtools instead of inherited Exception https://review.openstack.org/125323 | 07:09 |
openstackgerrit | Christian Schwede proposed a change to openstack/python-swiftclient: Use skipTest from testtools instead of inherited Exception https://review.openstack.org/125323 | 07:10 |
*** kopparam has quit IRC | 07:12 | |
*** shakamunyi has quit IRC | 07:18 | |
*** shakamunyi has joined #openstack-swift | 07:18 | |
*** acoles_away is now known as acoles | 07:22 | |
acoles | notmyname: ack meeting time | 07:26 |
*** geaaru has joined #openstack-swift | 07:28 | |
*** joeljwright has joined #openstack-swift | 07:35 | |
*** Krast has joined #openstack-swift | 07:38 | |
*** kota_ has joined #openstack-swift | 07:39 | |
*** kopparam has joined #openstack-swift | 07:56 | |
acoles | notmyname: metadata backport review only allowed me +/-1 | 08:03 |
*** foexle has joined #openstack-swift | 08:06 | |
*** jistr has joined #openstack-swift | 08:10 | |
*** jistr has quit IRC | 08:12 | |
*** jistr has joined #openstack-swift | 08:20 | |
*** shakamunyi has quit IRC | 08:24 | |
*** kevinbenton has quit IRC | 08:28 | |
*** kevinbenton has joined #openstack-swift | 08:36 | |
*** shakamunyi has joined #openstack-swift | 08:50 | |
*** nellysmitt has joined #openstack-swift | 08:52 | |
*** Krast has quit IRC | 08:52 | |
*** shakamunyi has quit IRC | 08:55 | |
*** Krast has joined #openstack-swift | 09:01 | |
*** Krast has quit IRC | 09:04 | |
*** jamiehannaford has joined #openstack-swift | 09:05 | |
*** Krast has joined #openstack-swift | 09:05 | |
*** dmorita has quit IRC | 09:28 | |
*** mkollaro has joined #openstack-swift | 09:35 | |
*** oomichi has quit IRC | 09:36 | |
*** haomaiwang has joined #openstack-swift | 09:48 | |
*** shakamunyi has joined #openstack-swift | 09:50 | |
*** shakamunyi has quit IRC | 09:55 | |
*** aix has joined #openstack-swift | 10:00 | |
*** nosnos has quit IRC | 10:09 | |
*** mkollaro has quit IRC | 10:16 | |
*** jistr has quit IRC | 10:17 | |
*** joeljwright1 has joined #openstack-swift | 10:18 | |
*** joeljwright has quit IRC | 10:19 | |
*** Krast has quit IRC | 10:22 | |
*** jistr has joined #openstack-swift | 10:22 | |
*** mahatic has joined #openstack-swift | 10:37 | |
*** nosnos has joined #openstack-swift | 10:38 | |
*** shakamunyi has joined #openstack-swift | 10:51 | |
*** shakamunyi has quit IRC | 10:56 | |
*** mrsnivvel has quit IRC | 11:03 | |
*** mrsnivvel has joined #openstack-swift | 11:06 | |
*** haomaiwang has quit IRC | 11:08 | |
*** openstack has joined #openstack-swift | 14:14 | |
*** openstackstatus has joined #openstack-swift | 14:15 | |
*** ChanServ sets mode: +v openstackstatus | 14:15 | |
*** CaioBrentano has quit IRC | 14:15 | |
*** kopparam has quit IRC | 14:15 | |
*** CaioBrentano has joined #openstack-swift | 14:15 | |
*** kopparam has joined #openstack-swift | 14:16 | |
zigo | Hey, I got a question here. Is it ok to use the latest swift with Icehouse? | 14:19 |
zigo | I wonder, because I'm not sure which version of Swift I should upload for Debian Jessie (which freeze on the next 5th of November). | 14:20 |
zigo | Should I plan for an upload to Debian Unstable of swift 2.2.0 ? | 14:20 |
*** ttrumm has joined #openstack-swift | 14:20 | |
*** kopparam has quit IRC | 14:20 | |
vr1 | swifterdarrel: OK | 14:20 |
zigo | chmouel: Your opinion? | 14:21 |
chmouel | zigo: i think notmyname would be able to let you know when is up (PST time) ^ | 14:22 |
zigo | Ok, thanks. | 14:22 |
*** ttrumm_ has joined #openstack-swift | 14:22 | |
*** ttrumm_ has quit IRC | 14:23 | |
wasmum | removing storage nodes. set_weight 0 in the ring but devices still getting put requests, is there a better way to move data to the other devices and remove these nodes? | 14:23 |
notmyname | zigo: yes it's ok to use the latest swift with icehouse | 14:25 |
zigo | notmyname: Ok, will upload that soon then. | 14:25 |
*** ttrumm has quit IRC | 14:25 | |
notmyname | zigo: to be pedantic, the icehouse release includes swift 1.13.1, and there have been a couple of backports there. what I'm saying is that juno release of swift should work just fine with the icehouse release of other openstack projects | 14:26 |
zigo | notmyname: I think it's best to have the latest, considering Swift has a rapid pace for releasing... | 14:27 |
notmyname | zigo: I support that :-) | 14:27 |
zigo | notmyname: I hope to get 3 years of support for 2.2.0 then! :) | 14:28 |
zigo | (security patches, I mean...) | 14:28 |
notmyname | zigo: nice | 14:28 |
notmyname | zigo: thanks | 14:28 |
zigo | I meant, from you guys ... | 14:28 |
* notmyname commute time | 14:28 | |
notmyname | zigo: we'll do what we can | 14:28 |
zigo | :) | 14:28 |
*** andreia_ has quit IRC | 14:35 | |
*** haomaiwang has joined #openstack-swift | 14:35 | |
openstackgerrit | Prashanth Pai proposed a change to openstack/swift: fsync() on directories https://review.openstack.org/126923 | 14:36 |
cschwede | mahatic: you don’t need "@mock.patch('swiftclient.service.Connection')" for this test, because swiftclient fails earlier and doesn’t create a new connection | 14:37 |
cschwede | mahatic: you would need it if you expect the operation to succeed, to actually mock out the connection and make it testable without a running swift cluster at the other side | 14:38 |
swift_fan | Just curious, but does anyone know whether Swift is good for storing structured data ? | 14:38 |
swift_fan | I've read somewhere that it's used for unstructured data | 14:38 |
*** vr1 has quit IRC | 14:38 | |
swift_fan | but didn't hear much about its stance on structured data ..... | 14:38 |
swifterdarrell | swift_fan: how would you characterize the difference between structured data and unstructured data? particularly with respect to read/write access patterns? | 14:39 |
swift_fan | swifterdarrell : Are you unsure about what "structured vs unstructured data" means ? | 14:39 |
swift_fan | Structured data - data where you know the semantics/labels of the values (a good example would be database tables). | 14:40 |
swifterdarrell | swift_fan: I'm unsure what *you* mean in your question and I'm asking for a clarification | 14:40 |
mahatic | cschwede, oh okay. Also, I would be putting this test under this class : class TestShell, correct? (I'm sorry if you don't exactly remember the class name, I will send the change in any case) | 14:40 |
swift_fan | Unstructured data - where there is no such labeling of data -- a text document would be a good example. | 14:40 |
swift_fan | swifterdarrell ^ | 14:40 |
cschwede | mahatic: yes, afaik that is the right class name | 14:40 |
*** tdasilva has quit IRC | 14:41 | |
swifterdarrell | swift_fan: great! so on to: how would you characterize the difference between structured data and unstructured data with respect to read/write access patterns? | 14:41 |
swift_fan | swifterdarrell : That, I'm not sure. | 14:41 |
cschwede | mahatic: so the whole thing about all this mock stuff in swiftclient is either: | 14:41 |
cschwede | 1) avoid an actual call to Swift (which is not available in the test) | 14:41 |
swifterdarrell | swift_fan: cool, when you can answer that, you can answer whether Swift would work well for structured data | 14:41 |
cschwede | 2) or make something testable, like the output from a print command | 14:41 |
swift_fan | swifterdarrell : Just curious, then, what types of read/write access patterns are recommended for Swift ? | 14:42 |
*** shakamunyi has joined #openstack-swift | 14:42 | |
swifterdarrell | swift_fan: basically Swift will store data for you at a location, and give it back to you when you ask for it at that location, and you can overwrite all the data at a location (subject to eventual consistency as already discussed), and you can read ranges of the data (HTTP range requests) | 14:42 |
swift_fan | swifterdarrell : I'll try to get back with a read/write characterization of structured data, too. | 14:42 |
swifterdarrell | swift_fan: but you cannot do partial writes to an object | 14:42 |
*** bsdkurt has quit IRC | 14:43 | |
swifterdarrell | swift_fan: so if you had a Swift object and what was stored in it was some binary representation of a database table, and you wanted to update one row, what would happen? | 14:43 |
mahatic | cschwede, ah okay. I just discovered through these tests about mock object library in python. | 14:44 |
swift_fan | swifterdarrell : It seems from your explanation of what exactly Swift does, that wouldn't be possible ..... | 14:44 |
swift_fan | swifterdarrell : Because "you cannot do partial writes to an object". | 14:44 |
swifterdarrell | swift_fan: well, it'd be *possible*, it'd just be prohibitively slow (you'd have to overwrite the entire table for every row update) | 14:44 |
swifterdarrell | swift_fan: correct | 14:45 |
swift_fan | swifterdarrell : So, then why doesn't Swift have a feature that allows for partial writes to an object ? | 14:45 |
swift_fan | swifterdarrell : Or, why can't Swift be modified to allow for that ? | 14:45 |
swifterdarrell | swift_fan: engineering tradeoffs | 14:45 |
swift_fan | swifterdarrell : This makes me curious. | 14:45 |
swifterdarrell | swift_fan: I'm afraid I don't have time to go into that | 14:46 |
swift_fan | swifterdarrell : engineering tradeoffs? As in, you *have* to give up one or more things, in order to allow partial writes to an object ? | 14:46 |
swift_fan | swifterdarrell : And is that one thing extremely crucial ? | 14:47 |
swift_fan | swifterdarrell : Ok, if you don't have time now that's fine. I'll try to look into it, and perhaps follow up on that later. Thanks | 14:48 |
mahatic | cschwede, after my changes, i will do the pep8 tests (tox -e pep8) and will run "run_tests.sh", anything else i should be checking before submitting for review? | 14:50 |
*** vr1 has joined #openstack-swift | 14:50 | |
*** shakamunyi has quit IRC | 14:50 | |
wasmum | removing storage nodes. set_weight 0 in the ring but devices still getting put requests, is there a better way to move data to the other devices and remove these nodes? | 14:51 |
vr1 | swifterdarrell: if you have the container servers on the proxy servers and let's say you have 3 proxy-servers | 14:52 |
vr1 | if the replication factor is 3 | 14:52 |
vr1 | and one machine fails | 14:52 |
vr1 | some DB won't be accessible no ? | 14:52 |
swifterdarrell | swift_fan: for fun and excitement, you can check out this old patch for allowing *appending* (only) to objects, but it didn't get through: https://review.openstack.org/#/c/11969/ | 14:52 |
swift_fan | swifterdarrell : Ok, thanks. I thought up of something that may or may not be a good idea -- why not have each database row (or any portions of the database) be its own Swift "object"/file ? | 14:54 |
*** tdasilva has joined #openstack-swift | 14:54 | |
cschwede | mahatic: if you have a running swift cluster (saio) you could run the functional tests too: „sh .functests“ | 14:54 |
swift_fan | swifterdarrell : So that Swift wouldn't have to do partial writes to an object, in order to update/modify a database. | 14:54 |
cschwede | wasmum: hmm, that should not happen. is the modified ring.gz file distributed to all nodes? | 14:55 |
swifterdarrell | vr1: with >= 1 replica available, reads can succeed, and with CEIL(replica_count / 2) replicas available (quorum), writes can succeed | 14:56 |
swifterdarrell | vr1: so in your example, reads and writes to containers would be fine with one node down | 14:56 |
swifterdarrell | vr1: fire up some VMs and try it! | 14:56 |
mahatic | cschwede, ah yes. and also i forgot, this one too "sh .unittests" | 14:57 |
cschwede | mahatic: in that case you could skip „run_tests.sh“ | 14:58 |
mahatic | cschwede, oh okay | 14:59 |
*** mkollaro has quit IRC | 15:05 | |
mahatic | cschwede, I'm getting this error when i run the tests: "AssertionError: SystemExit not raised" | 15:10 |
mahatic | cschwede, http://paste.openstack.org/show/119650/ -> While my test has the above syntax, the rest of them are called differently. Could that be a reason? | 15:11 |
*** shakamunyi has joined #openstack-swift | 15:15 | |
cschwede | mahatic: hmm, no, i don’t think so. The test passed fine during my test - I assume you need to do a „python setup.py develop“ (or install) in swiftclient, sounds like it’s not using the modified code (and in that case the error is correct). | 15:17 |
mahatic | cschwede, hmm, i did run "python setup.py develop" | 15:20 |
mahatic | cschwede, http://paste.openstack.org/show/119653/ that's the error | 15:21 |
cschwede | mahatic: what is the output from python -c "import swiftclient; print swiftclient.__file__“ ? | 15:23 |
*** aerwin has joined #openstack-swift | 15:24 | |
mahatic | cschwede, "swiftclient/__init__.pyc" that's the output | 15:25 |
cschwede | mahatic: which is fine. strange. can you upload your new patchset to gerrit, and i have a look at the code there? | 15:26 |
mahatic | cschwede, sure, will do it | 15:26 |
swift_fan | swifterdarrell : Would it be a good idea to support database storage in Swift by configuring Swift to upload each database row (or a smaller or larger piece) as its own object, since Swift does not seem to support partial writes to an object ? | 15:39 |
swift_fan | swifterdarrell : (Instead of storing the whole database or table as an object). | 15:40 |
swift_fan | swifterdarrell : There's got to be a way to make it work well .......... | 15:40 |
openstackgerrit | Mahati proposed a change to openstack/python-swiftclient: Adds a user friendly message when --segment-size is a non-integer https://review.openstack.org/125275 | 15:44 |
*** vr1 has quit IRC | 15:45 | |
*** hhuang has quit IRC | 15:46 | |
mahatic | cschwede, strangely enough, now the tests have passed! Submitted new patchset | 15:46 |
glange | swift_fan: that's an interesting idea (the swift as db, objects as rows thing) -- you should try that out and let us know how it goes | 15:47 |
*** Nadeem has joined #openstack-swift | 15:47 | |
cschwede | mahatic: great! will review the new patchset later | 15:48 |
mahatic | cschwede, sure, thank you! | 15:49 |
*** k4n0 has quit IRC | 16:00 | |
*** SkyRocknRoll has joined #openstack-swift | 16:04 | |
*** SkyRocknRoll has quit IRC | 16:04 | |
*** SkyRocknRoll has joined #openstack-swift | 16:05 | |
*** SkyRocknRoll has joined #openstack-swift | 16:05 | |
*** kyles_ne has joined #openstack-swift | 16:07 | |
*** SkyRocknRoll has quit IRC | 16:09 | |
*** SkyRocknRoll has joined #openstack-swift | 16:09 | |
*** aerwin has quit IRC | 16:09 | |
*** kyles_ne_ has joined #openstack-swift | 16:13 | |
*** kyles_ne has quit IRC | 16:14 | |
*** SkyRocknRoll has quit IRC | 16:14 | |
*** SkyRocknRoll has joined #openstack-swift | 16:15 | |
*** SkyRocknRoll has joined #openstack-swift | 16:15 | |
notmyname | good morning | 16:16 |
notmyname | mahatic: did you see that I added another OPW project idea. it's more complex than the first one, but it's an option now | 16:20 |
notmyname | acoles: I too only have +/- 1 on backports https://review.openstack.org/#/c/126645/. we'll have to get ttx to land it, I think | 16:21 |
notmyname | acoles: probably needs one more core +1 for good measure | 16:21 |
acoles | notmyname: ok | 16:22 |
*** jistr has quit IRC | 16:22 | |
mahatic | notmyname, oh cool, looking at it | 16:23 |
notmyname | there's a WIP patch for fsync'ing directories. https://review.openstack.org/#/c/126923/ | 16:23 |
notmyname | portante: FYI ^ | 16:23 |
mahatic | notmyname, great, you're done with the schedule too! And also, i noticed, this one https://review.openstack.org/#/c/93788/ overrides this patch https://review.openstack.org/#/c/119193/ | 16:24 |
mahatic | correct? | 16:24 |
notmyname | mahatic: yes | 16:26 |
*** kenhui has joined #openstack-swift | 16:26 | |
notmyname | mahatic: you and nitika are both interested in swift OPW projects, so I'm not sure what happens if you both apply for the same one | 16:27 |
mahatic | notmyname, hmm, maybe you should get in touch with one of the coordinators? | 16:27 |
notmyname | mahatic: for that multinode doc patch, at the same time I'd say that both are good. removing the document until it can be updated completely is best for now, but that isn't a commentary on your UUID/label patch | 16:28 |
notmyname | zigo: re 3 years of support for swift 2.2.0, I'm not sure we've ever made that promise, at least to that degree, before | 16:29 |
zigo | notmyname: That's the life of a Debian release. | 16:30 |
zigo | There's been very few security issues in Swift in the past. | 16:30 |
notmyname | reminder to all that today's swift team meeting (in #openstack-meeting) is pushed back 30 minutes to 1930UTC (12:30pm pacific) and will be only 30 minutes max | 16:30 |
zigo | notmyname: I don't expect so many patches to be backproted, do you? | 16:30 |
mahatic | notmyname, sure, makes sense. I was just confused about its status. It's mandatory for OPW to have a patch merged. | 16:30 |
notmyname | zigo: true. we've done backports to openstack integrated releases before, but only for as long as openstack is maintaining that integrated release | 16:30 |
notmyname | zigo: and at the same time (and this probably conflicts with debian policy) our primary view is that you can upgrade to each release with no downtime or client breakage | 16:31 |
mahatic | notmyname, and here is a doc that could help you about the opw process: https://wiki.gnome.org/OutreachProgramForWomen/Admin/InfoForMentors | 16:31 |
mahatic | help you with* | 16:31 |
notmyname | zigo: not saying we won't backport | 16:32 |
zigo | notmyname: Things in Debian Stable never see upgrades from one version to the next (appart from a very few exception like Firefox...). | 16:32 |
zigo | So no way to upgrade in Debian Stable. | 16:32 |
*** kyles_ne_ has quit IRC | 16:33 | |
notmyname | zigo: heh. sounds like that's inviting projects to add internal "update the code to the new version" tools ;-) | 16:33 |
*** kyles_ne has joined #openstack-swift | 16:33 | |
zigo | notmyname: Which would not respect the Debian policy. :) | 16:33 |
zigo | notmyname: There must be only *one* way to upgrade software, and it's called apt. | 16:34 |
zigo | (or other implementations like aptitude) | 16:34 |
zigo | notmyname: We consider this kind of features as evil backdors. | 16:34 |
*** NM has quit IRC | 16:36 | |
*** SkyRocknRoll has quit IRC | 16:41 | |
*** marcusvrn_ has quit IRC | 16:43 | |
*** bsdkurt has joined #openstack-swift | 16:45 | |
notmyname | zigo: yeah yeah :-) | 16:45 |
notmyname | zigo: /me has zero plans to start typing that sort of code for swift | 16:46 |
*** shakamunyi has quit IRC | 16:46 | |
notmyname | ppai: is https://review.openstack.org/#/c/126923/ your patch? (I'm guessing at IRC nicks) | 16:54 |
*** NM has joined #openstack-swift | 17:01 | |
*** aix has quit IRC | 17:15 | |
*** dmsimard is now known as dmsimard_away | 17:19 | |
*** dmsimard_away is now known as dmsimard | 17:20 | |
*** HenryG is now known as HenryG_afk | 17:20 | |
ppai | notmyname, yes | 17:23 |
notmyname | ppai: great! thanks for working on that! | 17:23 |
ppai | notmyname, :) | 17:24 |
notmyname | ah, good. the metadata backport was approved (/cc hurricanerix) | 17:26 |
*** cutforth has joined #openstack-swift | 17:27 | |
notmyname | cutforth: did you see that today's meeting is pushed back? (I know you normally attend) | 17:29 |
cutforth | notmyname: yes, I have noticed that. thanks for the heads up. | 17:30 |
notmyname | http://goo.gl/9UsZoY <-- more different swift review dashboard. this one focuses on things that need to get through jenkins | 17:35 |
tdasilva | notmyname: what time is the meeting today? | 17:36 |
notmyname | tdasilva: 1930 (3:30 eastern) | 17:37 |
notmyname | tdasilva: 30 minutes later than normal | 17:37 |
tdasilva | notmyname: ok, thanks | 17:37 |
*** HenryG_afk is now known as HenryG | 17:44 | |
*** acoles is now known as acoles_away | 17:47 | |
*** marcusvrn_ has joined #openstack-swift | 17:57 | |
*** occupant has joined #openstack-swift | 17:57 | |
swift_fan | glange -- You weren't joking about that ? | 17:57 |
*** mrsnivvel has quit IRC | 17:58 | |
portante | notmyname, ppai: sweet | 17:58 |
swift_fan | notmyname : Why does Swift not support partial writes/updates to existing objects in the cluster ? | 18:01 |
portante | swift_fan: do you mean to ask why objects are immutable? | 18:01 |
swift_fan | portante : I suppose that may mean the same thing. | 18:02 |
swift_fan | :/ | 18:02 |
portante | I believe because of atomicity concerns, GETs need to return a consistent view of the object | 18:02 |
swift_fan | portante : But I thought that Swift doesn't care about atomicity ; (e.g., eventual consistency). | 18:02 |
swift_fan | (because it's eventually consistent). | 18:03 |
portante | I don't think they are the same concept | 18:03 |
swift_fan | portante : Then why do GETs need to return a consistent view of the object ? | 18:03 |
notmyname | swift_fan: a lot of detail on those issues in object storage are described in that Hitachi paper I linked for you yesterday | 18:03 |
swift_fan | portante : I thought eventual consistency meant that they *don't*..... | 18:03 |
portante | when reading an object being updated on all three replicas, concurrent writes will return potentially conflicting data | 18:04 |
swift_fan | portante : I wasn't referring to concurrent writes ; I was talking about why partial writes to an object isn't supported. | 18:05 |
swift_fan | asking, rather | 18:05 |
*** mrsnivvel has joined #openstack-swift | 18:05 | |
swift_fan | portante : Not sure why 'concurrent writes' comes into the picture for that ..... | 18:05 |
*** echevemaster has joined #openstack-swift | 18:06 | |
portante | swift_fan: I think I am answering that, but perhaps we need to examine all the possible operations on an object, how they can be applied concurrently, and then how the current implementation addresses them | 18:06 |
wasmum | cschwede: yes, the ring has been pushed to all files and replication has started. I can see the data moving off of partitions (df -h) but logging is still showing puts to the same (weight 0) partitions | 18:07 |
swift_fan | notmyname : I remember opening up a lot of links ; do you have that particular one on hand ? | 18:07 |
swift_fan | notmyname : If not, then no worries. | 18:07 |
wasmum | using grizzly on an ubuntu build | 18:07 |
notmyname | swift_fan: https://dl.dropboxusercontent.com/u/21194/distributed-object-store-principles-of-operation.pdf | 18:08 |
swift_fan | portante : Because in regards to partial writes to an object, it seems that the binary encoding of the part of the object, can be considered a "sub-object" itself. | 18:08 |
swift_fan | portante : So I don't see why Swift doesn't support portioning off part of the object just for an update. | 18:09 |
portante | swift_fan: so you want swift to do the read/modify/write update itself as a convenience? | 18:09 |
swift_fan | portante : After all, the portion/part of the object is just a BLOB (binary large object). | 18:09 |
portante | and recalculate the MD5 checksum for the entire object so that the API constraints are satisfied? | 18:10 |
swift_fan | portante : Are you saying that Swift doesn't do the read/modify/write update itself ? Then what does ? | 18:10 |
portante | the API definition is such that with no update, a PUT of an object replaces the entire previous version | 18:10 |
portante | so a client is responsible for read/modify/write | 18:11 |
swift_fan | notmyname : Thank you. | 18:11 |
swift_fan | portante : What I don't get is why the API definition wasn't first made to say "yes, you can do updates". | 18:12 |
portante | perhaps you should code a read/modify/write middleware that would accept the existing etag, offset, block of data, and return the new etag, such that it works under all the existing constraints | 18:12 |
portante | swift_fan: not sure why, but perhaps if you attend to implement it, you might get a better insight into what is happening | 18:12 |
swift_fan | portante : So would it be a better solution to store lots of small objects as "pieces" of the file ? | 18:14 |
swift_fan | portante : Somewhat like the concept of Static Large Objects. | 18:14 |
portante | swift does have that, SLO and DLO, static/dynamic large objects | 18:14 |
swift_fan | portante : maybe not exactly like that, though. | 18:14 |
*** geaaru has quit IRC | 18:14 | |
portante | Ceph does something like that, along with Kinetics drives (if I understand things correctly) | 18:15 |
swift_fan | portante : So is it recommended to store a database / database tables by using SLO and/or DLO ? | 18:15 |
portante | hmm ... | 18:15 |
portante | database? | 18:15 |
swift_fan | portante : Yes, for instance (just an example; not limited to) -- having each database row be its own object. | 18:15 |
swift_fan | portante : So that if you want to update/modify only a particular row(s) | 18:16 |
swift_fan | portante : You don't need to update the entire table (if the table were its own object). | 18:16 |
swift_fan | portante : Or, in general, I'm wondering if databases are ever stored (in the real production environment), using Swift. | 18:16 |
notmyname | swift_fan: no | 18:16 |
portante | probably not | 18:16 |
swift_fan | portante : Basically, whether enterprises ever choose to use Swift, or any Object Storage, to store their databases, ever ? | 18:17 |
notmyname | no | 18:17 |
notmyname | if by "database" you're referring to some SQL store that supports ACID | 18:17 |
swift_fan | notmyname portante : See, here we get into the ACID/consistency debate again -- why does SQL in that case need to support ACID ? | 18:18 |
notmyname | swift_fan: I get the impression that you need to read up on ACID and strong vs eventual consistency. and distributed systems | 18:18 |
swift_fan | notmyname : Why does a database storage particular need to be ACID ?? | 18:18 |
swift_fan | particularly* | 18:18 |
swift_fan | notmyname portante : It doesn't seem like there's anything special about it that makes it not be able to use eventual consistency as well ? | 18:19 |
swift_fan | like Swift. | 18:19 |
swift_fan | notmyname portante : I have a college-level understanding of ACID, strong, and eventual consistency (in regards to what they are). | 18:19 |
swift_fan | notmyname portante : In regards to the deep technical motivations of why certain systems (for instance databases) *have to be* ACID, for instance, | 18:20 |
swift_fan | not so much knowledge there. | 18:20 |
clayg | isn't the c like... consistency? like *strong* consistency? | 18:20 |
clayg | I think some "datastores" aren't acid, and some "document stores" aren't acid - some of them (mongodb, couch) still support queries... | 18:21 |
notmyname | swift_fan: go read the hitachi paper I gave you a link for. it does a great job of explaining the need for object storage, the use cases, and the problems implementations have to solve | 18:21 |
hurricanerix | notmyname: hurrah! (regarding metadata backport) | 18:22 |
swift_fan | notmyname portane : Well, I get that SQL databases have to be ACID, since the original designers decided it that way (like how Swift's API places constraints such as no partial updates to objects) -- but the question is why, were these constraints ever in place to begin with ? | 18:22 |
clayg | so you can have a thing that's not acid, and you can call it a database if you want - but I'm sure some popele would disagree with your use of the term - but it's just language - use it however you want - what you say doesn't even have to be true! | 18:22 |
swifterdarrell | maybe we should all just drop acid | 18:22 |
clayg | i don't think folks started with "I want to build a thing called acid" it was more of an observed property of a number of similar systems | 18:23 |
clayg | I think many applications have proven you can do interesting things without an acid compliant datastore | 18:23 |
notmyname | clayg: eventual consistency is best consistency | 18:24 |
swift_fan | notmyname : Ok, I will read the Hitachi paper for the answer to why Swift API does not support partial updates/writes to an object; however, I'm still confused as to why you can't have SQL databases stored on Swift. | 18:24 |
ctennis | because when you update object data, then immediately read it back you don't have a guarantee that you will get back your updated value. | 18:26 |
alpha_ori | swifterdarrell: lol | 18:26 |
alpha_ori | swifterdarrell: you're so subversive | 18:26 |
swift_fan | notmyname : The fact that SQL databases support ACID is a well-known fact, but it doesn't seem to explain very much. | 18:26 |
ctennis | Technically you could write a SQL database that uses Swift as long as you don't make a guarantee on the consistency of the data. | 18:27 |
alpha_ori | notmyname: eventual consistency is the best inconsistency | 18:27 |
swift_fan | ctennis : So that is what discourages everybody from using Swift to store SQL databases ? | 18:28 |
swift_fan | ctennis : Is that a correct conclusion ? | 18:28 |
ctennis | I guess nobody has had a need to do that, there are already plenty of SQL databases that use other things | 18:28 |
ctennis | It would also be horribly slow, because of the HTTP layer | 18:28 |
swift_fan | ctennis : What "other things" do SQL databases use ? | 18:31 |
ctennis | they talk directly to a filesystem on a machine | 18:31 |
*** elambert has joined #openstack-swift | 18:31 | |
swift_fan | ctennis : Are you sure they aren't talking directly to *block storage*, and not to a filesystem ? | 18:33 |
ctennis | yes, in some cases they do that too | 18:33 |
swift_fan | ctennis : Why would they talk to a filesystem, when they could have direct access to *block storage* ? | 18:34 |
ctennis | depends on the implementation, you're getting way off topic though | 18:34 |
swift_fan | ctennis : sorry | 18:34 |
ctennis | the point is, you can layer whatever you want on top of swift, some things will work better than others from a performance and fit standpoint | 18:36 |
ctennis | just like a block or filesystem | 18:36 |
swift_fan | ctennis : By "layer whatever you want", to clarify, you mean "you can store whatever you want" | 18:39 |
swift_fan | ctennis : ? | 18:39 |
ctennis | sure | 18:39 |
swift_fan | ctennis : Sorry, was just clarifying whether that was what you meant. | 18:40 |
swift_fan | to see. | 18:41 |
*** gyee has joined #openstack-swift | 18:41 | |
ctennis | yeah. You're fine, no worries. | 18:41 |
*** aix_ has joined #openstack-swift | 18:50 | |
swift_fan | ctennis : Then is Swift (or other Object Stores) used for *storing* database data when the data isn't being operated on? | 18:59 |
*** jistr has joined #openstack-swift | 18:59 | |
swift_fan | ctennis : kind of like a form of persistent storage for the databases. | 18:59 |
ctennis | maybe if it was an archival of that data, but likely not something where you're going to operate directly on the data | 18:59 |
swift_fan | ctennis : Or do enterprises/people try to use cloud *block* storage for that ? | 18:59 |
ctennis | you could probably get away with it either way..the main differentiator is that object storage is orders of magnitude cheaper than block storage | 19:00 |
*** mahatic has quit IRC | 19:01 | |
swift_fan | ctennis : cheaper, you mean in terms of dollars per GB of storage ? | 19:03 |
swift_fan | ctennis : Why so ? | 19:04 |
*** kyles_ne has quit IRC | 19:04 | |
ctennis | because it's how the market works I guess | 19:04 |
*** kyles_ne has joined #openstack-swift | 19:04 | |
* portante wonders if there is a team meeting today? | 19:05 | |
peluse | portante, it starts 30 min later today | 19:05 |
portante | k thanks | 19:06 |
* portante is out of the loop | 19:06 | |
* peluse had to scroll up a few screens to find out :) | 19:06 | |
*** kyles_ne has quit IRC | 19:09 | |
*** jamiehannaford has quit IRC | 19:11 | |
*** ejgaunga has joined #openstack-swift | 19:16 | |
*** mahatic has joined #openstack-swift | 19:17 | |
* notmyname is out of the earlier meeting | 19:20 | |
notmyname | swift team meeting is in 10 minutes in #openstack-meeting | 19:20 |
*** zaitcev has joined #openstack-swift | 19:21 | |
*** ChanServ sets mode: +v zaitcev | 19:21 | |
swift_fan | How long is the meeting, usually ? | 19:22 |
notmyname | swift_fan: normally up to an hour. today it will be max 30 minutes | 19:23 |
openstackgerrit | paul luse proposed a change to openstack/swift: Allow Diskfile to choose whether to cleanup old files per policy https://review.openstack.org/112449 | 19:23 |
*** nshaikh has joined #openstack-swift | 19:26 | |
*** acoles_away is now known as acoles | 19:26 | |
ctennis | swift_fan: you seem very keen for informational input, why don't you look at some of the broken things at https://bugs.launchpad.net/swift and pick an easy one to fix? The more you do that, the more exposure you'll get to Swift, and the more you'll understand | 19:27 |
notmyname | ok, meeting time :-) | 19:30 |
notmyname | in #openstack-meeting | 19:30 |
swift_fan | ctennis : Thanks :) | 19:30 |
*** lpabon has joined #openstack-swift | 19:31 | |
*** ttrumm has joined #openstack-swift | 19:33 | |
*** kyles_ne has joined #openstack-swift | 19:35 | |
swift_fan | Does anyone know how to enable healthcheck from the HAProxy end ? | 19:38 |
swift_fan | I believe in order to enable it from the Swift cluster end, you just insert it into the /etc/swift/*.conf pipelines ? | 19:38 |
swift_fan | But how do you make it so that you enable HAProxy to use the Swift cluster's healthcheck feature ? | 19:39 |
swift_fan | (and how do you verify/check that it's working?) | 19:39 |
*** kyles_ne has quit IRC | 19:39 | |
*** tsg has joined #openstack-swift | 19:40 | |
*** ttrumm_ has joined #openstack-swift | 19:46 | |
*** mkollaro has joined #openstack-swift | 19:50 | |
*** ttrumm has quit IRC | 19:50 | |
*** kyles_ne has joined #openstack-swift | 19:51 | |
*** kyles_ne has quit IRC | 19:55 | |
ahale | look for 'option httpchk' in haproxy manual | 20:00 |
*** tsg has quit IRC | 20:01 | |
*** tsg has joined #openstack-swift | 20:01 | |
*** lpabon has quit IRC | 20:02 | |
swift_fan | ahale : I've been doing that, but I'm in need of a way to verify that it's actually doing the healthcheck. | 20:02 |
*** acoles is now known as acoles_away | 20:02 | |
swift_fan | ahale : properly | 20:02 |
ahale | kill a proxy and see what happens on the haproxy stats page for that backend? this is more a question for the haproxy community | 20:03 |
*** nellysmi_ has quit IRC | 20:03 | |
*** jistr has quit IRC | 20:08 | |
swift_fan | ahale : ok. wasn't able to access the haproxy stats page for some reason ... any other method ? | 20:13 |
*** ejgaunga has left #openstack-swift | 20:14 | |
*** kyles_ne has joined #openstack-swift | 20:16 | |
*** ttrumm has joined #openstack-swift | 20:21 | |
swift_fan | ahale : Or maybe a way to check that the HAProxy healthchecks are working from the Swift nodes' point of view ?? | 20:22 |
ahale | logfiles...? | 20:22 |
*** ttrumm_ has quit IRC | 20:24 | |
swift_fan | ahale : Which one ? I don't see anything referring to healthcheck ........... | 20:27 |
swift_fan | ahale : And I don't know if that's because Swift log files don't store that information, or if it's because healthcheck isn't working. | 20:27 |
ahale | i dunno wherever you set your healthcheck to - its just a plain get to /healthcheck - theres nothing hard or magical about it | 20:27 |
ahale | set your proxy to* | 20:28 |
swift_fan | ahale : ok, so where would that be ? | 20:29 |
ahale | srsly? wherever you set it to log to | 20:30 |
*** kyles_ne has quit IRC | 20:32 | |
*** ttrumm has quit IRC | 20:36 | |
*** kyles_ne has joined #openstack-swift | 20:37 | |
*** kenhui has quit IRC | 20:41 | |
swift_fan | ahale : Okay, I basically added this line into my HAProxy configuration : | 20:43 |
swift_fan | option httpchk HEAD /healthcheck HTTP/1.0 | 20:44 |
swift_fan | and am wondering if that is correct, and should make it work. | 20:44 |
swift_fan | and also, changed the config line that says "mode tcp" to "mode http". | 20:44 |
mahatic | acoles_away, thank you for your comments. When I move up the check (after line 1183), make the other suggested changes, and run the tests, it throws this error: http://paste.openstack.org/show/119726/ | 20:45 |
swift_fan | Is the above configuration what is needed to make healthcheck work ? | 20:46 |
swift_fan | And is it recommended to use HTTP/1.0 as such : | 20:49 |
swift_fan | option httpchk HEAD /healthcheck HTTP/1.0 | 20:49 |
swift_fan | or HTTP/1.1 as such(?) : | 20:50 |
notmyname | mahatic: which patch? | 20:50 |
swift_fan | option httpchk HEAD /healthcheck HTTP/1.1 | 20:50 |
mahatic | notmyname, https://review.openstack.org/#/c/125275/ | 20:50 |
*** miqui has quit IRC | 20:51 | |
swift_fan | notmyname : Do you know how to make HAProxy--Swift healthcheck work ?? | 20:52 |
notmyname | mahatic: looking | 20:52 |
mahatic | okay | 20:53 |
mahatic | notmyname, maybe i should move my check before line 1201, correct? | 20:57 |
notmyname | mahatic: yes, acoles_away's suggestion was a good one | 20:57 |
notmyname | mahatic: as was cschwede's to use the .get() instead of the try/except | 20:59 |
NM | clayg: and notmyname I changed the conntrack parameters a few hours ago and no syncing error untill now. It helped a lot :) | 21:00 |
notmyname | NM: great!! | 21:00 |
notmyname | mahatic: why don't you make whatever changes are pending, then push that version up so that we can be looking at the same thing | 21:00 |
mahatic | notmyname, oh, instead of try/except? I thought it was a better way to replace the existing call. And when i do that, i get a TypeError | 21:01 |
notmyname | NM: "until now". does that mean you just had an error or that so far you haven't seen any | 21:01 |
mahatic | notmyname, alright, will do that | 21:01 |
notmyname | mahatic: ah, ok | 21:01 |
notmyname | mahatic: mostly I just want to see the same thing you see :-) | 21:01 |
mahatic | notmyname, yes sure :) | 21:01 |
NM | notmyname: My bad. I haven't seen any. This blog post was quite helpfull: http://www.pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/ | 21:02 |
notmyname | NM: great | 21:03 |
notmyname | NM: we mention conntrack in http://docs.openstack.org/developer/swift/deployment_guide.html#general-system-tuning but also https://bugs.launchpad.net/swift/+bug/1354909. | 21:05 |
NM | notmyname: I also found this https://bugs.launchpad.net/swift/+bug/1183152. Do you think it might be the case we were talking about? I mean, the statd error shouldn't be reported as syincing error. | 21:07 |
notmyname | NM: hmm...and it looks like I'm the one who patched that ;-) | 21:08 |
notmyname | NM: you're using an older version of swift right? ie not 2.1.0 | 21:09 |
NM | I'm upgrading today! I'm upgrading today! | 21:09 |
* NM enough shame using python 2.6 | 21:10 | |
notmyname | lol | 21:10 |
mahatic | notmyname, how do i add Closes-Bug line? Should i have to manually link the launchpad bug? | 21:11 |
NM | Btw, a swiftstack post says it's better to upgrade SN before the proxy. I thought it would be the opposite. | 21:11 |
notmyname | mahatic: it's just a line you type in to your commit message | 21:11 |
notmyname | NM: I wrote that one too :-) | 21:11 |
notmyname | NM: so the main reason is that a proxy being down can handle storage nodes being down. and the storage nodes generally do less than the proxy. so do storage nodes, then proxy. and all of it zone by zone | 21:12 |
notmyname | NM: and then ask ahale because he's probably the most expert on that in here ;-) | 21:12 |
NM | I saw it. But the way, did you choose that momment of Joe Arnold on purpose? | 21:13 |
notmyname | moment? | 21:13 |
*** tgohad has joined #openstack-swift | 21:13 | |
NM | He is with his mouth open, on the youtube screenshot. | 21:13 |
mahatic | notmyname, for this https://bugs.launchpad.net/swift/+bug/1244506, I would put "Closes-Bug: #1244506" ? (excuse for sounding silly!) | 21:13 |
ahale | mmm, probably it doesn't really matter that much to be honest - just its good to be structured about these things and have an order and stick to it | 21:14 |
notmyname | NM: oh, heh. actually no. youtube chooses the poster frame (via magic as far as i can tell) and users can't choose it | 21:14 |
*** tsg has quit IRC | 21:15 | |
notmyname | mahatic: yup. exactly right. here's an example on a different patch https://review.openstack.org/#/c/126645/ | 21:15 |
mahatic | notmyname, okay, thank you | 21:17 |
openstackgerrit | Mahati proposed a change to openstack/python-swiftclient: Adds a user friendly message when --segment-size is a non-integer https://review.openstack.org/125275 | 21:17 |
NM | ahale: thank you! Any other tip? | 21:17 |
ahale | well, thinking about it - most of the weirdness when updating a new cluster is going to be in proxies - the storage is pretty straightforward most times.. so its nicer to confirm that proxy weirdness is from proxy and not interaction with previous version storage.. so thats a reason for storage first | 21:19 |
notmyname | mahatic: looking | 21:19 |
mahatic | okay | 21:19 |
notmyname | mahatic: "FAILED (id=39, failures=3 (+1))" is that what you're seeing? | 21:20 |
ahale | take it slowly, when you do proxies, only do one first.. watch the logs for changes.. remember things can be cached and dont always show up first.. be prepared to stop stuff if you're not sure. | 21:20 |
*** cdelatte has quit IRC | 21:20 | |
ahale | we run pretty recent swifts so can see things that haven't popped up before so maybe im a bit more careful than really needed | 21:21 |
*** mkollaro has quit IRC | 21:21 | |
notmyname | ahale: just means the rest of us can watch https://github.com/rackerlabs/swift/tree/rackspace_production ;-) | 21:21 |
mahatic | notmyname, i don't see anything yet. I mean jenkins hasn't posted anything right? Or you mean the error in my local? | 21:22 |
notmyname | mahatic: ya, locally | 21:22 |
ahale | :) | 21:22 |
NM | ahale: Waht kind of errors have you seen upgrading swift? | 21:22 |
ahale | all kinds ! :) | 21:22 |
ahale | nah i joke normally its fine | 21:22 |
notmyname | ahale: and by "all kinds" you mean "very few" ;-) | 21:22 |
mahatic | notmyname, http://paste.openstack.org/show/119743/ that's what i see in my local | 21:23 |
ahale | yeah indeed - very occasionally we get bit by things, normally memcache is involved | 21:23 |
notmyname | mahatic: what did you run? I ran `./.unittests` | 21:24 |
swift_fan | Whenever my HAProxy configuration has "mode http", instead of "mode tcp", I keep getting the following error when trying to issue a swiftclient command: | 21:24 |
openstackgerrit | James Page proposed a change to openstack/swift: Adjust MAX_FILE_SIZE default on 32 bit systems https://review.openstack.org/127030 | 21:24 |
swift_fan | "_ssl.c:492: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol" | 21:25 |
*** joeljwright1 has left #openstack-swift | 21:25 | |
swift_fan | Can anyone figure out why? | 21:25 |
*** cds has joined #openstack-swift | 21:25 | |
cds | anyone around who is familiar with swift's auth mechanisms? | 21:25 |
notmyname | cds: what are you curious about? | 21:26 |
mahatic | notmyname, I see this when i run "./.unittests" -> FAILED (id=25, failures=1) | 21:27 |
cds | i have a pretty large swift cluser as part of an (old) openstack deployment | 21:27 |
mahatic | notmyname, i earlier ran "sh run_tests.sh" | 21:27 |
cds | we need to bring up a completely new openstack cloud, but keep the swift cluster | 21:27 |
cds | with the accounts being in the format AUTH_some-keystone-uuid | 21:28 |
notmyname | https://review.openstack.org/#/c/127030/ <<-- first response: "What?!" | 21:28 |
notmyname | cds: cool | 21:28 |
cds | how are my new openstack tenants going to see the containers in the old accounts? | 21:28 |
cds | would i have to go into the DB and change the names? | 21:28 |
swifterdarrell | notmyname: hahahaha, I remember when I only had 32 bits | 21:28 |
notmyname | swifterdarrell: back in my day we had 8 bits. and we were grateful! | 21:29 |
notmyname | swifterdarrell: back in my day a byte only had 7 bits. and we were grateful! | 21:29 |
notmyname | cds: will you still be using keystone in the new setup? | 21:32 |
cds | yes | 21:32 |
cds | and even if we use the same tenant names, wouldn't the uuids still be different | 21:32 |
notmyname | cds: ok. so conceptually I think that's pretty simple and totally possible. probably will take some careful planning though | 21:32 |
notmyname | cds: keystone is a map of user ID to swift account. so conceptually it's just* making sure the new keystone instance has the right mapping. | 21:33 |
cds | well hopefully is is possible without having to transfer 100TB+ out of the original swift cluster :) | 21:33 |
notmyname | * I hate the work "just" | 21:33 |
notmyname | word | 21:33 |
notmyname | cds: right. that should be avoided :-)( | 21:33 |
NM | ahale: Would you suggest to restart the memcahe? Or only if necessary? | 21:34 |
notmyname | NM: no! | 21:34 |
openstackgerrit | James Page proposed a change to openstack/swift: Adjust MAX_FILE_SIZE default on 32 bit systems https://review.openstack.org/127030 | 21:34 |
ahale | oh as little as possible for us! it kills auth endpoints | 21:34 |
notmyname | NM: well, it depends on your usage. normally no, though | 21:34 |
notmyname | ahale: "this kills the keystone" | 21:34 |
notmyname | (or whatever auth you have) | 21:35 |
ahale | yeah | 21:35 |
cds | notmyname: thanks, I can probably figure it out | 21:35 |
notmyname | ahale: I remember when auth guys were complaining that the auth load from swift was causing them trouble. then we found out we had a 1% cache miss rate. we were only sending them 1% of the traffic! | 21:35 |
cds | notmyname: one more question, how safe would you feel upgrading swift essex straight to juno? | 21:36 |
*** jamespage has joined #openstack-swift | 21:36 | |
ahale | ahh good times notmyname - sometimes scale can be scary | 21:36 |
notmyname | cds: I'd suggest moving in a couple of steps. one marker would be 1.13.1 (the last 1.X series) before moving to 2.2.0 | 21:37 |
cds | swift --version | 21:38 |
cds | swift 1.0 | 21:38 |
cds | lol :) | 21:38 |
notmyname | cds: no, that's the version of the CLI | 21:38 |
cds | oh | 21:38 |
*** foexle has quit IRC | 21:38 | |
notmyname | cds: and that's not because I'm too concerned about upgrades, it's just to give you some places to check. read over the CHANGELOG. it should have the important things listed that would affect upgrades | 21:39 |
mahatic | notmyname, when i run "./.unittests" again now, i get "FAILED (id=26, failures=1)" | 21:39 |
notmyname | cds: let me go find the essex release | 21:39 |
notmyname | cds: the openstack essex integrated release included swift 1.4.8 | 21:40 |
*** ppai has quit IRC | 21:40 | |
*** tdasilva has quit IRC | 21:40 | |
openstackgerrit | Prashanth Pai proposed a change to openstack/swift: fsync() on directories https://review.openstack.org/126923 | 21:40 |
mahatic | notmyname, I'll call it a night. Please leave your comments, will check them in the morning | 21:42 |
notmyname | mahatic: ok. have a good night! | 21:44 |
cds | notmyname: is there something exposed by the swift api to download files by the date last modified? ie download oldest files first? | 21:44 |
notmyname | cds: no | 21:45 |
openstackgerrit | David Goetz proposed a change to openstack/swift: Ssync does not replicate custom object headers https://review.openstack.org/127033 | 21:46 |
*** shri has joined #openstack-swift | 21:48 | |
notmyname | dfg: is that the bug you mentioned last week? ^^ | 21:54 |
dfg | notmyname: ya | 21:55 |
*** nellysmitt has joined #openstack-swift | 22:00 | |
*** nellysmitt has quit IRC | 22:05 | |
*** tgohad has quit IRC | 22:08 | |
*** echevemaster has quit IRC | 22:13 | |
NM | Good night guys :) | 22:14 |
*** CaioBrentano has quit IRC | 22:16 | |
*** NM has quit IRC | 22:20 | |
*** cdelatte has joined #openstack-swift | 22:21 | |
*** shakamunyi has joined #openstack-swift | 22:21 | |
*** swift_fan1 has joined #openstack-swift | 22:24 | |
*** swift_fan has quit IRC | 22:26 | |
*** shakamunyi has quit IRC | 22:35 | |
*** nshaikh has left #openstack-swift | 22:40 | |
*** themadcanudist has joined #openstack-swift | 22:42 | |
themadcanudist | hey guys, is there an apachetop like tool for swift proxy logs? Or something to easily convert the logs to apache common/combined format | 22:42 |
*** Nadeem has quit IRC | 22:44 | |
*** pberis has quit IRC | 22:44 | |
*** dmsimard is now known as dmsimard_away | 22:45 | |
*** kyles_ne has quit IRC | 22:47 | |
*** kyles_ne has joined #openstack-swift | 22:47 | |
*** kyles_ne has quit IRC | 22:51 | |
*** marcusvrn_ has quit IRC | 22:52 | |
*** pberis has joined #openstack-swift | 22:56 | |
notmyname | themadcanudist: swift has a lot more info in the log lines that is in an apache CLF log line. so yeah, you could (probably with a "simple" sed/awk script), but you'll lose info | 22:59 |
notmyname | themadcanudist: here's your starting point (we now have it all documented!) http://docs.openstack.org/developer/swift/logs.html | 22:59 |
notmyname | themadcanudist: but the quick answer to your original questions is "not that I know of" | 23:00 |
*** kyles_ne has joined #openstack-swift | 23:03 | |
*** dmsimard_away is now known as dmsimard | 23:07 | |
*** kyles_ne has quit IRC | 23:07 | |
themadcanudist | notmyname: thanks! | 23:12 |
*** kyles_ne has joined #openstack-swift | 23:15 | |
*** Tyger has quit IRC | 23:29 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!