notmyname | physcx: thanks | 00:00 |
---|---|---|
*** bach has joined #openstack-swift | 00:02 | |
*** matsuhashi has joined #openstack-swift | 00:04 | |
*** ChanServ changes topic to "Current Swift Release: 1.13.1 | Priority Reviews: https://wiki.openstack.org/wiki/Swift/PriorityReviews | Channel Logs: http://eavesdrop.openstack.org/irclogs/%23openstack-swift/" | 00:05 | |
-openstackstatus- NOTICE: the gate is still fairly backed up, though nodepool is back on track and chipping away at remaining changes. some py3k/pypy node starvation is slowing recovery | 00:05 | |
*** bach has quit IRC | 00:07 | |
*** bach has joined #openstack-swift | 00:12 | |
*** joeljwright has joined #openstack-swift | 00:16 | |
clayg | peluse_: so i was doing some functional tests for storage policies and noticed that clients can send x-storage-policy-index headers through the proxy for some reason? | 00:18 |
clayg | physcx: and is there less cpu somehow doing chunked uploads with the buffering in diskfile? | 00:20 |
*** joeljwright has quit IRC | 00:20 | |
*** dvas_ has joined #openstack-swift | 00:21 | |
*** dvas_ has quit IRC | 00:25 | |
*** wer has quit IRC | 00:26 | |
*** wer has joined #openstack-swift | 00:27 | |
*** bill_az has quit IRC | 00:34 | |
*** dmorita has joined #openstack-swift | 00:36 | |
*** csd_ has quit IRC | 00:39 | |
*** bach has quit IRC | 00:56 | |
*** joeljwright has joined #openstack-swift | 01:16 | |
*** praveenkumar has quit IRC | 01:19 | |
*** joeljwright has quit IRC | 01:21 | |
*** dvas_ has joined #openstack-swift | 01:22 | |
*** dvas_ has quit IRC | 01:26 | |
*** saschpe has quit IRC | 01:28 | |
*** saschpe has joined #openstack-swift | 01:29 | |
openstackgerrit | A change was merged to openstack/swift: Merge tag '1.13.1' https://review.openstack.org/91417 | 01:46 |
*** nosnos has joined #openstack-swift | 01:49 | |
*** mkollaro has joined #openstack-swift | 01:52 | |
*** dvas_ has joined #openstack-swift | 01:52 | |
peluse_ | clayg: yeah, that's probably true. we talked about preventing it but I think just implemented the translation on response headers at the time | 01:55 |
*** dvas_ has quit IRC | 01:55 | |
peluse_ | clayg: let me know if you want me to take care of it if you haven't already | 01:55 |
*** dvas_ has joined #openstack-swift | 01:56 | |
clayg | peluse_: nah it's cool i got it | 01:58 |
clayg | peluse_: thanks for confirming | 01:59 |
*** zhiyan_ is now known as zhiyan | 01:59 | |
*** dvas_ has quit IRC | 02:00 | |
peluse_ | clayg: no problema | 02:06 |
clayg | peluse_: do you think the storage_policy key in container info should be named storage_policy_index or at least be an integer? | 02:08 |
peluse_ | clayg: at least and int, yeah that makes sense. I'm not a huge fan of the longer names and not sure we'll have too many other types of policies but for consistency might as well | 02:15 |
clayg | i'm less worried about the name, tripped me up it wasn't already cast for me - should I file it in trello? | 02:16 |
peluse_ | clayg: up to you, doesn't seem like a very big thing to fix so adding a card might be more work than pushing the patch | 02:17 |
*** joeljwright has joined #openstack-swift | 02:18 | |
*** joeljwright has quit IRC | 02:23 | |
*** swills has quit IRC | 02:23 | |
*** swills has joined #openstack-swift | 02:23 | |
*** dvas_ has joined #openstack-swift | 02:26 | |
*** dvas_ has quit IRC | 02:30 | |
*** haomai___ has joined #openstack-swift | 02:51 | |
*** haomaiwang has quit IRC | 02:54 | |
*** mrsnivvel has joined #openstack-swift | 03:10 | |
*** zhiyan is now known as zhiyan_ | 03:18 | |
*** joeljwright has joined #openstack-swift | 03:19 | |
clayg | yuan: what ever happened to the patch to do the container migrations in the container auditor? | 03:19 |
*** dvas_ has joined #openstack-swift | 03:20 | |
*** joeljwright has quit IRC | 03:23 | |
*** dvas_ has quit IRC | 03:25 | |
openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Additional functional tests for Storage Policies https://review.openstack.org/91502 | 03:28 |
openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Fix cross policy versioning DELETE https://review.openstack.org/91503 | 03:28 |
*** matsuhashi has quit IRC | 03:28 | |
clayg | peluse_: lol - i missed your first pass of comments on yuan's functional tests (in the gate) - you'll probably have to make them all again on https://review.openstack.org/#/c/91502/ | 03:35 |
clayg | g'night | 03:35 |
peluse_ | clayg: will do... night | 03:43 |
*** nosnos has quit IRC | 03:46 | |
*** mkollaro has quit IRC | 03:51 | |
*** madhuri has quit IRC | 04:04 | |
*** madhuri has joined #openstack-swift | 04:04 | |
*** dvas_ has joined #openstack-swift | 04:14 | |
*** dvas_ has quit IRC | 04:19 | |
*** joeljwright has joined #openstack-swift | 04:20 | |
*** joeljwright has quit IRC | 04:25 | |
*** matsuhashi has joined #openstack-swift | 04:35 | |
*** nosnos has joined #openstack-swift | 04:36 | |
*** matsuhashi has quit IRC | 04:48 | |
*** matsuhashi has joined #openstack-swift | 04:53 | |
*** bill_az has joined #openstack-swift | 05:05 | |
*** dvas_ has joined #openstack-swift | 05:08 | |
*** dvas_ has quit IRC | 05:13 | |
*** joeljwright has joined #openstack-swift | 05:21 | |
*** joeljwright has quit IRC | 05:26 | |
*** zaitcev has quit IRC | 05:31 | |
*** bach has joined #openstack-swift | 05:52 | |
*** dvas_ has joined #openstack-swift | 06:02 | |
*** bach has quit IRC | 06:03 | |
*** dvas_ has quit IRC | 06:07 | |
*** bach has joined #openstack-swift | 06:09 | |
*** joeljwright has joined #openstack-swift | 06:23 | |
*** joeljwright has quit IRC | 06:27 | |
openstackgerrit | Andreas Jaeger proposed a change to openstack/python-swiftclient: Add "." for help strings https://review.openstack.org/91524 | 06:39 |
*** bill_az has quit IRC | 06:39 | |
*** chandan_kumar has joined #openstack-swift | 06:44 | |
*** dvas_ has joined #openstack-swift | 06:57 | |
*** dvas_ has quit IRC | 07:01 | |
*** dvas_ has joined #openstack-swift | 07:07 | |
*** chandan_kumar has quit IRC | 07:07 | |
*** matsuhashi has quit IRC | 07:09 | |
*** matsuhas_ has joined #openstack-swift | 07:12 | |
*** joeljwright has joined #openstack-swift | 07:23 | |
*** joeljwright has quit IRC | 07:28 | |
*** acoles_away is now known as acoles | 07:34 | |
*** joeljwright has joined #openstack-swift | 07:52 | |
*** mkerrin has joined #openstack-swift | 08:03 | |
*** dvas_ has quit IRC | 08:19 | |
*** matsuhas_ has quit IRC | 08:33 | |
*** dvas_ has joined #openstack-swift | 08:40 | |
*** matsuhashi has joined #openstack-swift | 08:41 | |
*** zanc has quit IRC | 09:20 | |
*** matsuhashi has quit IRC | 09:32 | |
*** matsuhashi has joined #openstack-swift | 09:33 | |
*** ccorrigan has quit IRC | 09:53 | |
*** nosnos has quit IRC | 09:54 | |
*** ccorrigan has joined #openstack-swift | 09:56 | |
*** Midnightmyth has joined #openstack-swift | 09:59 | |
*** Midnightmyth has quit IRC | 10:07 | |
*** mkollaro has joined #openstack-swift | 10:07 | |
*** chandan_kumar has joined #openstack-swift | 10:15 | |
*** dmorita has quit IRC | 10:34 | |
*** chandan_kumar has quit IRC | 10:52 | |
*** dvas__ has joined #openstack-swift | 11:14 | |
*** dvas_ has quit IRC | 11:15 | |
*** Midnightmyth has joined #openstack-swift | 11:19 | |
*** dvas___ has joined #openstack-swift | 11:40 | |
*** dvas__ has quit IRC | 11:42 | |
*** bach has quit IRC | 11:45 | |
*** dvas___ has quit IRC | 11:45 | |
*** dvas___ has joined #openstack-swift | 11:45 | |
*** bach has joined #openstack-swift | 11:45 | |
*** tdasilva has joined #openstack-swift | 12:02 | |
*** mkollaro has quit IRC | 12:38 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 12:43 |
*** changbl has quit IRC | 12:59 | |
*** bach has quit IRC | 13:26 | |
*** Midnightmyth has quit IRC | 13:30 | |
*** bach has joined #openstack-swift | 13:35 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/python-swiftclient: Updated from global requirements https://review.openstack.org/89250 | 13:50 |
*** shakamunyi has joined #openstack-swift | 13:59 | |
*** chandan_kumar has joined #openstack-swift | 14:01 | |
*** byeager has joined #openstack-swift | 14:10 | |
physcx | clayg: no, buffering has no effect on this problem (eventlets wsgi chunked read) - it gets worse as network_chunk_size increases though so buffering was an attempt at keeping it small while still being able to increase the size of chunks passed to the disk | 14:51 |
*** rcleere has quit IRC | 14:52 | |
notmyname | redbo: did you see http://blog.plenz.com/2014-04/so-you-want-to-write-to-a-file-real-fast.html ? | 14:53 |
*** matsuhashi has quit IRC | 14:54 | |
portante | nice, and I had a conversation at the same time! | 14:59 |
peluse_ | portante: so I ran in process on the SP code - merged ec+master+yuanz's branch w/SP specific functional tests (and one tweak to your process patch to add another obj ring) | 15:05 |
peluse_ | portante: ran link a champ and has withint 1% same coverage as master | 15:05 |
peluse_ | portante: I looked into some of the details and it makes sense as much of the SP specific code is executed regardless of whether you are using pol 0 (legacy) or a 2nd one so we would expect about the same coverage | 15:06 |
peluse_ | also FYI for everyone. quick snapshot of diff stats between SP and master to gauge size of full set of patches: | 15:06 |
peluse_ | functional code: LOC added 653. LOC changed: 423 (w/o reconciler) | 15:07 |
peluse_ | test code: LOC added 2427. LOC changed: 1036 (w/o reconciler) | 15:08 |
notmyname | first thought: most expensive 1k lines evar | 15:09 |
peluse_ | ha! I like the functional/test LOC ratios though | 15:10 |
portante | peluse_: sec | 15:11 |
*** mmcardle has joined #openstack-swift | 15:12 | |
*** kevinc_ has joined #openstack-swift | 15:13 | |
*** bach has quit IRC | 15:22 | |
*** bach has joined #openstack-swift | 15:23 | |
*** bach has quit IRC | 15:23 | |
*** changbl has joined #openstack-swift | 15:27 | |
*** dvas___ has quit IRC | 15:28 | |
*** dvas___ has joined #openstack-swift | 15:29 | |
*** byeager has quit IRC | 15:30 | |
*** byeager has joined #openstack-swift | 15:30 | |
*** dvas____ has joined #openstack-swift | 15:31 | |
*** dvas___ has quit IRC | 15:33 | |
*** byeager has quit IRC | 15:36 | |
*** byeager has joined #openstack-swift | 15:36 | |
* peluse_ needs to step away for ~20 min | 15:37 | |
*** chandan_kumar has quit IRC | 15:39 | |
*** bach has joined #openstack-swift | 15:39 | |
*** bach has quit IRC | 15:41 | |
*** byeager has quit IRC | 15:42 | |
*** byeager has joined #openstack-swift | 15:43 | |
*** bach has joined #openstack-swift | 15:46 | |
*** kevinc_ has quit IRC | 15:47 | |
*** bach_ has joined #openstack-swift | 15:48 | |
*** bach_ has quit IRC | 15:49 | |
*** bach has quit IRC | 15:51 | |
*** bach has joined #openstack-swift | 15:51 | |
*** kevinc_ has joined #openstack-swift | 15:51 | |
*** bach has quit IRC | 15:53 | |
*** mwstorer has joined #openstack-swift | 15:55 | |
*** mmcardle has quit IRC | 16:07 | |
*** zaitcev has joined #openstack-swift | 16:09 | |
*** ChanServ sets mode: +v zaitcev | 16:09 | |
*** dvas____ has quit IRC | 16:32 | |
*** dvas____ has joined #openstack-swift | 16:33 | |
*** dvas____ has quit IRC | 16:37 | |
*** dvas____ has joined #openstack-swift | 16:38 | |
*** dvas____ has quit IRC | 16:38 | |
*** dvas____ has joined #openstack-swift | 16:39 | |
*** dvas____ has quit IRC | 16:43 | |
*** dvas____ has joined #openstack-swift | 16:55 | |
*** Midnightmyth has joined #openstack-swift | 16:58 | |
*** dvas____ has quit IRC | 16:59 | |
*** mmcardle has joined #openstack-swift | 17:00 | |
*** bach has joined #openstack-swift | 17:04 | |
*** shri has joined #openstack-swift | 17:07 | |
*** shakamunyi has quit IRC | 17:09 | |
*** byeager has quit IRC | 17:10 | |
*** mmcardle has quit IRC | 17:11 | |
clayg | i'm looking at a gate failure for grenade where n-net failed to start, and I don't know why? It has a screen log in old/ but not in new/ - and then vms' go to state error timeout waiting on network | 17:15 |
clayg | have anyone ever had any luck asking in #openstack or -infra about something like that? I'm not sure what bug to file? | 17:15 |
peluse_ | clayg: not I but glad to see the SP functional tests get approved! did you see my earlier comments on func tests w/policies? | 17:17 |
clayg | peluse_: only too late - can you make them again against the additional func tests? | 17:17 |
peluse_ | clayg: sorry, I mean in IRC, scroll up a few hrs | 17:18 |
peluse_ | but I'll go look and see if I had anything worth repeating in the review... | 17:18 |
peluse_ | clayg: OK, Yuan had already addressed my earlier comments | 17:19 |
clayg | yeah i think his stuff was a solid start, thanks for reviewing it | 17:24 |
*** kevinc_ has quit IRC | 17:27 | |
*** gyee has joined #openstack-swift | 17:36 | |
*** bach has quit IRC | 17:40 | |
*** byeager has joined #openstack-swift | 17:41 | |
openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Fix cross policy versioning DELETE https://review.openstack.org/91503 | 17:47 |
*** kevinc_ has joined #openstack-swift | 17:48 | |
*** byeager has quit IRC | 17:50 | |
*** byeager has joined #openstack-swift | 17:57 | |
*** cds has joined #openstack-swift | 17:58 | |
cds | i just switched openstack controllers, is there an easy way to give my new controller (specifically glance) access to the containers in swift? | 17:58 |
notmyname | cds: do you have an existing swift clusteR? | 17:59 |
cds | yes | 17:59 |
cds | i stood up a brand new controller with icehouse | 17:59 |
notmyname | (I'm not sure what an "openstack controller" is) | 18:00 |
cds | keystone+glance+horizon | 18:00 |
*** shri1 has joined #openstack-swift | 18:00 | |
cds | basically, how can i transfer a container to a new swift user | 18:00 |
cds | maybe that makes more sense | 18:00 |
notmyname | I'd think that there aren't any changes required on the swift side of things. if you already had roles+ACLs set up to have swift working with glance, there should......ah, that's different I think | 18:01 |
*** shri1 has quit IRC | 18:01 | |
notmyname | sorry for the questions here, but "user" is a very overloaded term. what do you mean by "swift user"? | 18:01 |
*** bach has joined #openstack-swift | 18:02 | |
cds | i suppose user = account in swift | 18:02 |
*** shri has quit IRC | 18:02 | |
clayg | cds: so like did you setup a new service user for glance, like fresh keystone db or something? | 18:02 |
notmyname | ok (it could have also meant some end-user that gets keystone tokens or even the process owner) | 18:02 |
cds | clayg: yes | 18:03 |
cds | new everything, however I am reusing all of the old passwords from the original controller | 18:03 |
clayg | hrmm.... you might have to like hack that users storage-url by hand? | 18:03 |
cds | that is what it is looking like | 18:03 |
cds | just curious if there is an easier way | 18:03 |
notmyname | cds: swift should still be set up with the same data. eg all existing containers still have the same container ACLs. | 18:03 |
notmyname | ya, what clayg said :-) | 18:03 |
notmyname | can keystone explicitly set the storage URL when adding an entry to the service catalog? | 18:04 |
clayg | notmyname: does glance really use container ACLs? like I don't even know if the default behavior is to stuff everything into a service account or store images per user... I guess base images have to be in the service account | 18:04 |
notmyname | or is it always set as some random uuid | 18:04 |
clayg | notmyname: for all I know it's tied to the tenants uuid or something - it may not be it's own seperate field :\ | 18:04 |
notmyname | I don't know. I can imagine lots of ways it /could/ work | 18:05 |
cds | is there a simple way to list all accounts currently in swift? | 18:05 |
clayg | cds can keystone give you anything that will authenticate for the old data? like idk, maybe with a superadmin/reseller admin token? | 18:05 |
*** byeager has quit IRC | 18:06 | |
cds | i'm sure it could, but wouldn't the token expire eventually? | 18:06 |
*** byeager has joined #openstack-swift | 18:06 | |
clayg | heh: for db in $(find /srv/node*/sd*/account* -name \*.db) ; do swift-account-info $db | grep "Account: "; done | sort -u | 18:06 |
clayg | cds well i just was wondering if you could get at the storage url of the old account - but I guess it wont' really matter until you what the data model looks like in keystone | 18:07 |
clayg | but you could always just copy the data to the new glance services account too... | 18:07 |
cds | yeah | 18:07 |
cds | simple for one of my swift clusters | 18:08 |
cds | but another has 50TB + | 18:08 |
clayg | cds you should probably ask in keystone if anyone knows anything about chaning the storage url of an existing user | 18:09 |
cds | good idea. | 18:09 |
cds | thanks for the help guys :) | 18:09 |
notmyname | keystone devs lurk in #openstack-dev | 18:09 |
cds | have either of you tried 12.04 -> 14.04 with havana -> icehouse ? | 18:10 |
cds | for glance+keystone+horizon | 18:10 |
cds | that would solve my problem | 18:10 |
cds | only reason i created this new controller was to hopefully migrate cleanly to 14.04 and icehouse | 18:11 |
cds | swift upgraded fine | 18:11 |
clayg | i have not spun up a trusty yet | 18:13 |
cds | i had the idea of spinning up a trust controller and migrating services incrementally, which hasn't worked very well | 18:13 |
cds | just can risk my existing controller being down for extended periods | 18:13 |
cds | trusty* | 18:14 |
cds | cant* | 18:14 |
acoles | cds: notmyname: clayg: i think when you add swift service to keystone there's some syntax to tell keystone to generate endpoint urls of form AUTH_tenantId | 18:16 |
notmyname | acoles: I would trust your view on this more than my own :-) I think you use keystone more often that I do | 18:17 |
clayg | acoles: bollocks - so it sounds like chaging the storage url means changing the tenantId? that's probably a terrible idea (or genious, dunno) | 18:17 |
cds | can you change a tenant id? | 18:17 |
cds | i guess i could in the sqldb | 18:17 |
acoles | cds: that i don't know, sorry. but sounds like the question you may need to ask keystone folks. | 18:18 |
clayg | cds: i'm guessing it's sorta denormalized across services in weird ways - but i if you could track down all the right references you might be able to pull it out | 18:18 |
acoles | cds: or can you specify an id when you create a tenant (in this case glance, if i understand the problem) | 18:19 |
cds | alright. and just to verify, a reseller admin user is *the* superuser on a swift cluster correct? | 18:19 |
acoles | notmyname: don't label me a keystone expert :) | 18:19 |
notmyname | cds: from the perspective of swift, yes | 18:20 |
notmyname | acoles: lol | 18:20 |
clayg | peluse_: i'm waiting to hear back from yuan on some of the patches he's been working on - container sync looks pretty close, but i think it's missing a test. | 18:20 |
notmyname | cds: to be more specific, the reseller admin has full read/write access to every swift account that is for that reseller (the reseller concept allows swift to use more than one auth system at the same time) | 18:21 |
notmyname | cds: and funnily enough, I was just having a very similar conversation in a different channel | 18:21 |
acoles | cds: so maybe if you know the tenant_id of your old glance you can give your new glance reseller admin role and then point it at the url for the old glance tenant | 18:23 |
cds | that is what i was thinking | 18:23 |
clayg | notmyname: peluse_: have storage policies always had a "type" | 18:27 |
acoles | cds: remember to add the AUTH_ part in front of the old tenant id when constructing your url. Or whatever your reseller prefix is. | 18:28 |
notmyname | clayg: I don't think so, but I'll defer to peluse_. I think that got added as peluse_ et al we're doing the EC stuff, and I think it doesn't do anything now | 18:28 |
clayg | oic, it was added so the replicator would know if it can process a storage directory or not... | 18:28 |
cds | acoles: is it possible to change the old url to reflect the new tenant ID> | 18:31 |
notmyname | cds: no, the swift account name (ie the AUTH_XXX part) is used in the data placement in the swift cluster | 18:32 |
acoles | cds: not sure what you mean. change it where? | 18:32 |
cds | the account name | 18:32 |
cds | notmyname answered it | 18:32 |
cds | would syncing the containers between the accounts be an option? | 18:33 |
clayg | cds: i'd avoid a bit data migration util I'd cofirmed twiddling some fields in the db is not an option... | 18:35 |
cds | ok | 18:35 |
cds | i'll work on it for a bit. thanks again for the help | 18:35 |
*** changbl has quit IRC | 18:36 | |
clayg | but yeah, a wholesale copy would definately square it - just gunna take a bit | 18:36 |
*** bach has quit IRC | 18:36 | |
*** acoles is now known as acoles_away | 18:38 | |
openstackgerrit | paul luse proposed a change to openstack/swift: Add Storage Policy Support to Container Sync https://review.openstack.org/86469 | 18:46 |
peluse_ | clayg: yes, I added when I added support (SP) for the replciator. It needs it regardless of EC being introduced | 18:47 |
*** changbl has joined #openstack-swift | 18:50 | |
zaitcev | cds: look at http://people.redhat.com/zaitcev/tmp/keystone-setup.sh, it creates pre-set AUTH_x in Keystone. | 18:52 |
cds | awesome | 18:56 |
cds | this is exactly what i needed | 18:56 |
notmyname | zaitcev to the rescue | 18:58 |
*** bach has joined #openstack-swift | 19:13 | |
openstackgerrit | Clay Gerrard proposed a change to openstack/swift: cleanup policy parsing a bit more https://review.openstack.org/87078 | 19:13 |
clayg | peluse_: ^ can you give that one a last over? I'm looking at container sync - I think I can do a probetest for container sync (& cross policy) | 19:14 |
clayg | er... at least I think I can - container sync doesn't *have* to be cross realm right? you can just go from one container to anotehr? | 19:15 |
*** kragniz has quit IRC | 19:18 | |
clayg | gholt: does "A sync realm is a set of clusters that have agreed to allow container syncing with each other" mean that we don't expect a cluster in relam1 to be able to sync with realm2? | 19:21 |
peluse_ | clayg: good question and sure I'll take a look at the parsing cleanup, about 40 min or so - have a call | 19:25 |
*** kragniz has joined #openstack-swift | 19:27 | |
*** tzumainn has joined #openstack-swift | 19:28 | |
tzumainn | hi - would someone be able to answer some questions here about object versioning in swift? | 19:28 |
notmyname | tzumainn: ask away. and someone may be able to answer | 19:28 |
tzumainn | notmyname, okay, so. . . | 19:29 |
tzumainn | if I understand correctly | 19:29 |
tzumainn | to version an object in swift, you actually need two containers - one that always contains the latest version | 19:29 |
tzumainn | and a versioning container that has copies of that object | 19:29 |
tzumainn | er, I mean the older versions of that object | 19:29 |
notmyname | correct | 19:30 |
tzumainn | the older versions are prefixed | 19:30 |
tzumainn | how is that prefix determined? | 19:30 |
*** JayF has left #openstack-swift | 19:30 | |
tzumainn | and is the current version of the object also contained in the versioning container? | 19:31 |
notmyname | tzumainn: I'm not looking at the code, but IIRC, it's the length of the object name + a counter or timestamp + the object name. I should go look at the code | 19:31 |
*** tsg has joined #openstack-swift | 19:31 | |
notmyname | tzumainn: no, the current version isn't in the versions container | 19:31 |
tzumainn | notmyname, okay, so - if we have a versioned object, and something like a heat template refers to the latest version of that object | 19:32 |
notmyname | ok | 19:32 |
tzumainn | that object could actually change, right? or is there a way to say "always refer to this particular version, and not necessarily the latest"? | 19:33 |
notmyname | tzumainn: from http://docs.openstack.org/developer/swift/overview_object_versioning.html "The new object name (for the previous version) is <versions_container>/<length><object_name>/<timestamp>, where length is the 3-character zero-padded hexidecimal length of the <object_name> and <timestamp> is the timestamp of when the previous version was created." | 19:33 |
clayg | peluse_: no it works, but i'm sitting here looking at this info dict and trying to decide which realm is acctually the same realm/cluster is the same as realm/cluster of my container :P | 19:33 |
tzumainn | notmyname, ah, ok, I read that page but completely missed that - thanks | 19:34 |
tzumainn | so I guess my only question is about a heat template that refers to, say, the latest version of something in swift; is there a way to make sure it always points to that version, even if a newer version of the object is added? | 19:34 |
notmyname | tzumainn: no. in that case, you'd have to use a specific (static) object name | 19:35 |
notmyname | tzumainn: but that is possible (just not with versioned writes) | 19:36 |
tzumainn | okay, so we could do it, just not with a versioned object? | 19:36 |
notmyname | tzumainn: you could write the stuff with a unique name and then create a manifest file referring to that one object. then request the object with the "friendly" name (eg cool_beans_latest.awesome) and update that as you add new versions. if you need a specific version, refer to it specifically | 19:37 |
notmyname | where manifest == static large object manifest | 19:37 |
zaitcev | Interesting. the API doc of 20140219 does not have a slash between the lengh-name and timestamp. | 19:38 |
tzumainn | notmyname, ah, okay, that makes sense - so essentially create our own versioning system using the manifest and static file names | 19:39 |
tzumainn | that makes sense | 19:39 |
tzumainn | that's all very helpful - thank you very much! | 19:39 |
notmyname | code says: prefix_len + self.object_name + '/' + new_ts | 19:40 |
notmyname | http://shop.oreilly.com/product/0636920033288.do <-- your very own Swift O-Reilly book (you can get it at the summit) | 19:42 |
physcx | trying to set up a swift-bench config file for a distributed swift-bench run and there isn't a good example for how to set the ip:port of the swift-bench-clients... anybody familiar with the tool know how to set multiple -b host:ip args in the config file? | 19:44 |
tzumainn | notmyname, nice, okay - I might pick one up there in atlanta then - thanks! | 19:44 |
notmyname | tzumainn: first 100 people in the swiftstack booth each day will get a free book | 19:44 |
tzumainn | lol, really? | 19:45 |
notmyname | yup. https://swiftstack.com/blog/2014/05/01/save-the-date-were-heading-to-atlanta-for-the-openstack-summit/ | 19:46 |
notmyname | physcx: looking | 19:46 |
tzumainn | awesome, I'll bring a tent and camp out | 19:46 |
*** shri has joined #openstack-swift | 19:48 | |
*** lpabon has joined #openstack-swift | 19:49 | |
*** zhiyan_ is now known as zhiyan | 19:49 | |
zaitcev | I got the original inknabula off of of Joe's minions which apparently never made it to the stores or even Amazon. | 19:50 |
zaitcev | I red it through and sent him a list of some 190 corrections. | 19:50 |
notmyname | physcx: hmm...looking at the code (but not having run it) I'm not sure if that's possible. maybe only specified on the cmd line | 19:54 |
*** schofield has joined #openstack-swift | 19:55 | |
swifterdarrell | zaitcev: are you saying you'd like a copy of the book? | 19:56 |
*** schofield has quit IRC | 19:56 | |
*** schofield has joined #openstack-swift | 19:57 | |
zaitcev | swifterdarrell: sure, we'll see if I can swing by | 19:57 |
zaitcev | swifterdarrell: Are you going to do the booth babe duty? | 19:57 |
*** kevinc_ has quit IRC | 19:57 | |
swifterdarrell | zaitcev: i'm always doing babe duty, but I won't be going to the conference | 19:57 |
swifterdarrell | zaitcev: however we really appreciate your help editing and I'm sure getting you a copy of the book won't be a problem :) | 19:58 |
*** kevinc_ has joined #openstack-swift | 19:59 | |
physcx | notmyname: thx, just checked the python and yea it is setting conf.bench_clients = [] right after reading it so cmd line only i guess | 20:00 |
swifterdarrell | physcx: I added that feature, but never ended up using it much; I probably used it 100% via command-line | 20:01 |
*** schofield has left #openstack-swift | 20:04 | |
physcx | it is a nice little tool, just discovered today it can be used distributed | 20:06 |
portante | physcx: are you talking about ssbench? | 20:07 |
physcx | swift-bench | 20:07 |
portante | ah, k | 20:07 |
portante | okay, in-process func tests are now a gate/check job | 20:12 |
notmyname | portante: voting? | 20:18 |
portante | not yet, that is the easiest way to debug it to make sure it is functioning correctly | 20:19 |
portante | once it is passing for a bit, a healthy number of jobs (not sure what that is) they'll change it to voting | 20:19 |
portante | and yes, May 6th is Westford Town Elections, and I am planning on voting | 20:20 |
*** bach has quit IRC | 20:23 | |
*** bach has joined #openstack-swift | 20:27 | |
*** shri1 has joined #openstack-swift | 20:28 | |
*** shri1 has quit IRC | 20:28 | |
clayg | portante: aren't like... *real* functests already part of the gate? | 20:30 |
*** shri has quit IRC | 20:31 | |
portante | clayg: yes, but if changes break the in-process func tests and don't break the regular func tests, then I think we want to know about it so that we can address it | 20:32 |
portante | so I was thinking that we'd want to know as soon as possible | 20:33 |
notmyname | clayg: see, you shouldhave been at the swift meeting yesterday instead of those "customer" problems ;-) | 20:37 |
notmyname | where we talked about devstack functests vs in-process func tests | 20:38 |
portante | clayg: the goal is to be sure in-process func tests are reliable enough that developers can use it to help write new func tests | 20:38 |
portante | for example, the swift-on-file team in Red Hat is taking on the task to work on increasing func test coverage based on this | 20:39 |
clayg | yeah looks like i did miss some stuff | 20:48 |
*** byeager has quit IRC | 20:53 | |
*** byeager has joined #openstack-swift | 20:55 | |
*** lpabon has quit IRC | 20:55 | |
*** lpabon has joined #openstack-swift | 20:57 | |
*** cds has quit IRC | 21:00 | |
*** mwstorer has quit IRC | 21:02 | |
*** bach_ has joined #openstack-swift | 21:12 | |
*** bach_ has quit IRC | 21:12 | |
*** bach_ has joined #openstack-swift | 21:13 | |
*** lpabon has quit IRC | 21:15 | |
*** bach has quit IRC | 21:15 | |
*** bach_ has quit IRC | 21:24 | |
*** zhiyan is now known as zhiyan_ | 21:24 | |
*** shri has joined #openstack-swift | 21:26 | |
clayg | portante: ERROR: unknown environment 'pyfunc' | 21:26 |
portante | hmm | 21:26 |
* portante runs over to that sandbox and looks | 21:27 | |
*** changbl has quit IRC | 21:27 | |
*** lpabon has joined #openstack-swift | 21:27 | |
*** lpabon has quit IRC | 21:27 | |
portante | clayg: job id? | 21:28 |
clayg | portante: what's a job id? http://logs.openstack.org/78/87078/4/check/gate-swift-unittests-func/8ce760f/console.html | 21:29 |
openstackgerrit | Clay Gerrard proposed a change to openstack/swift: Add probetest for container sync https://review.openstack.org/91685 | 21:29 |
portante | hrumph | 21:33 |
portante | rats, gonna have to see what the infra team wants to do here | 21:37 |
*** changbl has joined #openstack-swift | 21:48 | |
*** joeljwright has quit IRC | 22:05 | |
*** bach has joined #openstack-swift | 22:07 | |
*** bach has quit IRC | 22:07 | |
*** bach has joined #openstack-swift | 22:08 | |
gholt | clayg: re: the sync realms question: yes, each realm is its own shared grouping. For instance, Rackspace will have a realm for its clusters and maybe add an additional realm to share with SwiftStack or ... Perhaps that realm wouldn't include all Rackspace clusters due to bandwidth concerns or whatever reason. Also, I am not and cannot make any such commitments, just examples. ;) | 22:11 |
*** changbl has quit IRC | 22:19 | |
*** mmcardle has joined #openstack-swift | 22:24 | |
*** mmcardle has quit IRC | 22:28 | |
*** bach has quit IRC | 22:34 | |
*** joeljwright has joined #openstack-swift | 22:47 | |
*** rahmu has left #openstack-swift | 22:48 | |
*** byeager has quit IRC | 22:57 | |
*** joeljwright has quit IRC | 23:00 | |
openstackgerrit | paul luse proposed a change to openstack/swift: cleanup policy parsing a bit more https://review.openstack.org/87078 | 23:04 |
peluse_ | clayg: ^ looks fantastic. made a few minor tweaks to get unit coverage up to 100% | 23:05 |
*** Midnightmyth has quit IRC | 23:06 | |
*** shakamunyi has joined #openstack-swift | 23:42 | |
*** joeljwright has joined #openstack-swift | 23:57 | |
*** kevinc_ has quit IRC | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!