| mattoliverau | notmyname: gotta go to a meeting, be back in about 30 mins or so. | 00:01 |
|---|---|---|
| notmyname | mattoliverau: hmm...I don't see a way to give you access to that BP (yet another reason I don't like Launchpad) | 00:01 |
| notmyname | mattoliverau: the spec is more important than the BP | 00:01 |
| mattoliverau | notmyname: OK, I'll just work on the Spec :) | 00:03 |
| *** miurahr has quit IRC | 00:03 | |
| *** kopparam has quit IRC | 00:03 | |
| *** sandywalsh_ has quit IRC | 00:03 | |
| *** Masahiro has joined #openstack-swift | 00:07 | |
| *** Masahiro has quit IRC | 00:11 | |
| *** jasondotstar has joined #openstack-swift | 00:21 | |
| *** jasondotstar has quit IRC | 00:21 | |
| *** dmorita has joined #openstack-swift | 00:24 | |
| *** oomichi has joined #openstack-swift | 00:35 | |
| *** miurahr has joined #openstack-swift | 00:43 | |
| *** Masahiro has joined #openstack-swift | 00:44 | |
| *** miurahr has quit IRC | 01:01 | |
| *** kopparam has joined #openstack-swift | 01:02 | |
| *** kajinamit has quit IRC | 01:08 | |
| *** addnull has joined #openstack-swift | 01:11 | |
| *** infotection has joined #openstack-swift | 01:11 | |
| notmyname | interesting proposed http extension spec for reporting specifics of error messages http://tools.ietf.org/html/draft-ietf-appsawg-http-problem-00 | 01:30 |
| *** kopparam has quit IRC | 01:33 | |
| mattoliverau | I'll have to add it to me reading list | 01:36 |
| notmyname | it's pretty short | 01:37 |
| notmyname | I think what's interesting to me is really just proposing a standard way to return a json doc about the error. defined content type and a few recommended keys and what they should have in them | 01:38 |
| mattoliverau | notmyname: well, finally got my LCA flights, I'll be arriving on Saturday arvo so I can attend the ATC meet up :) | 01:56 |
| *** Masahiro has quit IRC | 02:01 | |
| *** Masahiro has joined #openstack-swift | 02:04 | |
| *** fifieldt has joined #openstack-swift | 02:05 | |
| *** haomaiwang has joined #openstack-swift | 02:13 | |
| *** tkay has joined #openstack-swift | 02:25 | |
| *** kopparam has joined #openstack-swift | 02:29 | |
| *** kopparam has quit IRC | 02:34 | |
| *** Masahiro has quit IRC | 03:07 | |
| *** addnull has quit IRC | 03:07 | |
| *** SkyRocknRoll has joined #openstack-swift | 03:08 | |
| *** anticw_ has quit IRC | 03:23 | |
| *** anticw has joined #openstack-swift | 03:24 | |
| *** Masahiro has joined #openstack-swift | 03:30 | |
| *** david-lyle_afk has quit IRC | 03:31 | |
| *** bkopilov has quit IRC | 03:33 | |
| *** Masahiro has quit IRC | 03:35 | |
| *** Masahiro has joined #openstack-swift | 03:40 | |
| *** miqui_ has quit IRC | 03:40 | |
| *** david-lyle_afk has joined #openstack-swift | 03:43 | |
| *** Masahiro has quit IRC | 03:48 | |
| *** david-lyle_afk has quit IRC | 03:50 | |
| *** Masahiro has joined #openstack-swift | 03:52 | |
| *** david-lyle_afk has joined #openstack-swift | 04:02 | |
| *** david-lyle_afk has quit IRC | 04:02 | |
| *** Masahiro has quit IRC | 04:02 | |
| *** addnull has joined #openstack-swift | 04:04 | |
| *** Masahiro has joined #openstack-swift | 04:09 | |
| *** kopparam has joined #openstack-swift | 04:17 | |
| *** kopparam has quit IRC | 04:21 | |
| *** tkay has quit IRC | 04:49 | |
| *** david-lyle_afk has joined #openstack-swift | 05:01 | |
| *** bkopilov has joined #openstack-swift | 05:08 | |
| *** ipolyzos has quit IRC | 05:09 | |
| *** ipolyzos has joined #openstack-swift | 05:11 | |
| *** kopparam has joined #openstack-swift | 05:24 | |
| *** ppai has joined #openstack-swift | 05:26 | |
| *** SkyRocknRoll has quit IRC | 05:26 | |
| *** SkyRocknRoll has joined #openstack-swift | 05:27 | |
| *** nshaikh has joined #openstack-swift | 05:32 | |
| openstackgerrit | Xiang Hui proposed openstack/swift: Fix getaddrinfo if dnspython is installed. https://review.openstack.org/116618 | 05:32 |
| *** kopparam has quit IRC | 05:35 | |
| *** serverascode___ has quit IRC | 05:37 | |
| *** kopparam has joined #openstack-swift | 05:37 | |
| *** Masahiro has quit IRC | 05:38 | |
| *** Masahiro has joined #openstack-swift | 05:38 | |
| *** serverascode___ has joined #openstack-swift | 05:41 | |
| *** ipolyzos has quit IRC | 05:45 | |
| *** ipolyzos has joined #openstack-swift | 05:46 | |
| *** tkay has joined #openstack-swift | 05:54 | |
| *** SkyRocknRoll has quit IRC | 05:55 | |
| *** SkyRocknRoll has joined #openstack-swift | 05:55 | |
| *** tkay has quit IRC | 06:01 | |
| *** k4n0 has joined #openstack-swift | 06:01 | |
| *** addnull has quit IRC | 06:19 | |
| *** Masahiro has quit IRC | 06:29 | |
| *** kopparam has quit IRC | 06:30 | |
| *** Masahiro has joined #openstack-swift | 06:31 | |
| *** SkyRocknRoll has quit IRC | 06:33 | |
| xianghui | notmyname: hello, around? | 06:36 |
| notmyname | xianghui: hi | 06:37 |
| xianghui | if you got a minute, can we talk a bit about https://review.openstack.org/#/c/116618/ | 06:37 |
| xianghui | notmyname: hello : ) | 06:37 |
| xianghui | I replied inline | 06:37 |
| *** kopparam has joined #openstack-swift | 06:38 | |
| notmyname | xianghui: ah, yes. I haven't spend the time I need to fully look at that patch. my comment was one of the first things that jumped out | 06:38 |
| xianghui | notmyname: ah , understand | 06:38 |
| notmyname | xianghui: I get your point about circular imports. but refactoring to avoid a whole new dependency just to know if and env var as "yes" is a True value is worth it. phrased another way, I don't want a whole new dependency to determine that. especially since we already have a function to do it in swift | 06:39 |
| xianghui | notmyname: so do you mind I write a simple func same as utils.config_true_value() in __init__.py to avoid new dependency? | 06:40 |
| notmyname | xianghui: however, I want to be careful to say that's just an implementation detail on the patch. it's important, but thank you for working on this issue! | 06:40 |
| notmyname | xianghui: is there a way to refactor so you don't have to have the code in __init__.py? | 06:40 |
| xianghui | notmyname: sorry, what you mean about 'refactor', I may not fully follow you | 06:41 |
| xianghui | remove the change in __init__py instead of somewhere? | 06:41 |
| notmyname | xianghui: basically, yes. let me look at the patch a little more closely | 06:43 |
| xianghui | notmyname: thank you very much! take you time :) | 06:44 |
| notmyname | xianghui: I'm not going to be able to give it a full review tonight (my local time), but the basic principle I'm saying is that adding a dependency is a Big Deal that we really want to avoid, if possible | 06:45 |
| xianghui | notmyname: understand | 06:45 |
| notmyname | xianghui: so mostly I have a challenge to you: implement it using existing functionality instead of adding a dependency. I don't know exactly the best way to do that right now | 06:48 |
| notmyname | xianghui: but thank you for working on it. I love to see patches that help with ipv6 support! | 06:49 |
| xianghui | notmyname: I would like to thank you for your efforts to review this patch today and future :) | 06:50 |
| *** SkyRocknRoll has joined #openstack-swift | 06:51 | |
| *** sungju has quit IRC | 06:53 | |
| openstackgerrit | Matthew Oliver proposed openstack/swift-specs: Container sharding spec https://review.openstack.org/139921 | 06:56 |
| notmyname | xianghui: I'm curious. why is the import checking required in __init__.py rather than doing inside cname_lookup.py (ie where the current import checking is done)? | 06:59 |
| xianghui | notmyname: they reason is the checking need to be done before anyplace import eventlet first | 07:02 |
| xianghui | and for swift services, most of them are importing swift/common /utils in the begginning | 07:02 |
| openstackgerrit | Matthew Oliver proposed openstack/swift-specs: Container sharding spec https://review.openstack.org/139921 | 07:03 |
| xianghui | so to support swift services could listening on ipv6 address, the greendns need to be disabled | 07:03 |
| notmyname | is EVENTLET_NO_GREENDNS an env var that eventlet respects? | 07:04 |
| xianghui | so we added checking in __init__.py, reffering nova's implementation in nova/cmd/__init__.py | 07:05 |
| mattoliverau | I'm calling it a day, have a great night/day all! | 07:05 |
| notmyname | otherwise all I see is that cname_lookup now uses a ThreadPool | 07:05 |
| mattoliverau | notmyname: get some sleep | 07:05 |
| notmyname | mattoliverau: ;-) | 07:05 |
| notmyname | mattoliverau: still gotta finish my preso | 07:05 |
| notmyname | (I'm about 2/3 done) | 07:06 |
| mattoliverau | notmyname: you'll need extra coffee tomorrow! | 07:06 |
| xianghui | yep, if setting EVENTLET_NO_GREENDNS this evironment variable, the greendns will be disabled, and ipv6 addr will be working | 07:06 |
| xianghui | mattoliverau: night | 07:06 |
| notmyname | xianghui: ah, interesting | 07:06 |
| xianghui | notmyname: there are two changes: 1. set env EVENTLET_NO_GREENDNS=yes, if eventlet has been imported before and dnspython is used | 07:07 |
| notmyname | xianghui: ok but all you're doing is warning. and telling the user to set the env var before running the code | 07:07 |
| xianghui | 2. the cname_lookup is used for using a ThreadPool to improve performance which down by disable greendns | 07:07 |
| notmyname | yes, you're doing the ThreadPool, but that's not disabling anything in eventlet | 07:08 |
| xianghui | notmyname: yep, set the env var will be working , the evenlet patch will lookup this env var to decide whether use greendns | 07:08 |
| notmyname | which brings me back to wondering why you can't raise the warning in cname_lookup instead of the __init__ | 07:08 |
| xianghui | hmm, let me explain it | 07:09 |
| notmyname | which would allow easy removal of the dependency | 07:09 |
| notmyname | thanks. clearly I'm being slow tonight ;-) | 07:09 |
| xianghui | :) I am slow a bit today, still in weekend mode | 07:09 |
| xianghui | 1. we can ignore the cname_lookup first | 07:10 |
| xianghui | 2. what we wantis mainly in the __init__ | 07:10 |
| ahale | I hate that 2/3 point in pressos, where you have the cat memes in and need to write the actual content | 07:11 |
| notmyname | ahale: lol. you've been looking over my shoulder? | 07:11 |
| ahale | hehe | 07:11 |
| xianghui | 3. that is: check whether eventlet is imported and the env var is set no, if eventlet is already imported, then all we can do is just give a warnning | 07:11 |
| xianghui | 4. but if eventlet is not imported yet, then we set the env var to yes, to let evenlet not use greendns if it is imported later | 07:12 |
| notmyname | xianghui: ok. got it. it's #4 that I was missing | 07:12 |
| xianghui | yep, so only then env var is set to yes, then canme_loolkup will be go to the added logistic | 07:13 |
| notmyname | xianghui: but let me propose something else. if a deployer is using cname_lookup, they are using eventlet. ie by the time the execution point gets to that middleware eventlet is already imported (in all likelihood). and the point is that this happens at startup, not when the first cname lookup request comes in | 07:14 |
| notmyname | xianghui: so at what point will we ever be using cname lookup and then later need to give a warning. it all happens at startup, which is effectively instant for the user. I'm thinking that maybe just the error (and resulting failure to start) is sufficient instead of needing to patch eventlet with an env var at runtime | 07:15 |
| notmyname | and as a follow-on question (after we get this one resolved), is it good to always use a thread pool for lookups? why not do that every time and remove the conditional? | 07:16 |
| notmyname | xianghui: the user story for you patch (IIRC) is that the user sets an env var to tell the process that IPv6 addrs should be expected. at that point it fails to start if eventlet is already imported. otherwise, it monkypatches eventlet to enable IPv6 DNS support | 07:17 |
| xianghui | notmyname: yep | 07:18 |
| notmyname | xianghui: but what I'm learning now is that if the env var is set by the deployer explicitly, then it should Just Work (tm) | 07:18 |
| xianghui | notmyname: what do you mean "[07:14] < notmyname> | xianghui: but let me propose something else.." | 07:18 |
| xianghui | notmyname: what you mean is that we remove the warnning in __init__, and maybe move it to cname_lookup? | 07:19 |
| notmyname | ya, that's one option. let me type out what I think the options are | 07:19 |
| xianghui | and hold thet env var set in __init__? | 07:19 |
| notmyname | 1) check in __init__. this means that the deployers sets an openstack-specific env var to get the process to set an eventlet env var (assuming that swift.common is imported before eventlet) | 07:20 |
| notmyname | 2) check at startup in cname_lookup. the openstack env var to say IPv6 support should be enabled. effectively, the deployer would need to set 3 env vars now. the openstack one and the eventlet one | 07:22 |
| notmyname | 3) keep the checks in cname_lookup, and only check the IPv6 stuff if an IPv6 request is give. I don't know the detail here yet, but the goal is to return an error code (5xx?) to the client for IPv6 lookups instead of current behavior (crash?). also a log message could tell the deployer what to do | 07:23 |
| notmyname | that's what I've got right now | 07:23 |
| notmyname | number 3 is weak, I'll admit | 07:24 |
| notmyname | oh. in number 2, the deployer has to set 2 env vars. not 3 | 07:24 |
| notmyname | so I'm wondering if we can keep the check in cname_lookup and keep it at one env var for the deployer to explicitly set (rather than swift setting it at runtime) | 07:25 |
| xianghui | the background of chaning cname_lookup is that in the beginning we don't have the cname_lookup modification, that's to fix other review's concern about performance when enable IPv6 due to disable greendns | 07:25 |
| xianghui | about openstack-specific evn var , is that 'OS_ENABLE_IPV6' here? | 07:26 |
| notmyname | right | 07:26 |
| xianghui | sorry I am a bit confused about 2) and 3), what's the reason to check in cname_lookup ? | 07:28 |
| notmyname | mattoliverau: still around? | 07:28 |
| *** addnull has joined #openstack-swift | 07:30 | |
| *** stevage has joined #openstack-swift | 07:32 | |
| stevage | g'day, I was venting about Swift on Twitter and @notmyname suggested I come here :) | 07:33 |
| notmyname | stevage: hi! | 07:33 |
| stevage | I'm trying to make a public repository of some open data, about a terabyte, with basically a simple HTML file browser | 07:34 |
| notmyname | xianghui: with 2, the idea would be to simply check at process startup (like in your patch) for the appropriate things. with 3 the idea is to only fail (ie log a warning) when an IPv6 request is handled. | 07:34 |
| notmyname | xianghui: but that's probably not possible at that point in the execution. (like I said, I'm fuzzy on that) | 07:34 |
| notmyname | stevage: cool | 07:34 |
| stevage | I'm not super familiar with the openstack techs (and especially their names), although I use the compute services a lot - on NeCTAR, in the Australian university sector | 07:34 |
| *** addnull has quit IRC | 07:35 | |
| notmyname | stevage: our resident Oz contributor just logged off for the night, but I'll be happy to help as I can until it gets too late for me | 07:35 |
| stevage | so first I tried uploading a lot of files with Cyberduck, then accessing them through Owncloud - but those two tools seem to treat directories differently. end result: no directories in Owncloud. | 07:35 |
| xianghui | notmyname: thanks for your great advice, I will think about how to refactor it .:) | 07:35 |
| notmyname | stevage: yup, I'm familiar with NeCTAR. I know some of the people who manage it | 07:35 |
| stevage | then I tried uploading files directly with Owncloud desktopclient, but that didn't work because for some reason it didn't support "hard links" from my external hard drive | 07:35 |
| *** nellysmitt has joined #openstack-swift | 07:36 | |
| stevage | cool, thanks. it's one of those things where I just don't really know what the right tools are and how they fit together. | 07:36 |
| notmyname | stevage: yup. I can understand your frustration with that. | 07:36 |
| notmyname | stevage: ok, I'll try to help | 07:36 |
| stevage | currently I can upload files with cyberduck, or with python swift client - so far so good. | 07:37 |
| notmyname | stevage: just so I know where to start, what have you tried so far? have you looked at any of the docs around openstack object storage (swift)? | 07:37 |
| notmyname | ok | 07:37 |
| stevage | now to make a website. I tried to follow the instructions here: http://docs.openstack.org/api/openstack-object-storage/1.0/content/static-website.html | 07:37 |
| notmyname | ok | 07:37 |
| stevage | it shows the contents of some unidentified config file. what is it? where is it? etc. | 07:38 |
| notmyname | stevage: that config is for swift deployers. in your case, that's nectar | 07:38 |
| stevage | I don't know if I have the time to really learn Swift from the ground up - I'm trying to just solve this one use case. always a tough decision knowing how much time to invest learning it... | 07:38 |
| *** nottrobin has quit IRC | 07:39 | |
| notmyname | stevage: totally understand. if you've got about 30 minutes, I'll be we can get you up and running | 07:39 |
| stevage | hmm. so I jumped into trying to follow this: http://docs.openstack.org/api/openstack-object-storage/1.0/content/Examples_for_static_web-dle4025.html | 07:39 |
| stevage | I set the container world readable and that seems to work: https://vault.melbourne.vicnode.org.au:8888/v1/AUTH_5efcf00a5431448586564b8341ba6a17/newcontainer/index.html | 07:40 |
| notmyname | stevage: yup. that's an example of how to use the CLI to set metadata to do it | 07:40 |
| stevage | but it doesn't seem to allow directory listing: https://vault.melbourne.vicnode.org.au:8888/v1/AUTH_5efcf00a5431448586564b8341ba6a17/newcontainer/ | 07:40 |
| notmyname | stevage: `swift post -m 'web-listings: true' container` | 07:40 |
| *** nottrobin_ has joined #openstack-swift | 07:40 | |
| stevage | where I'm trying to get to is running something like this: https://github.com/fanatic/swift-ui - but preferably something better than "alpha quality" if there is such a thing. | 07:41 |
| stevage | yep, I did: $ swift post -m 'web:listings: true' newcontainer vagrant@vagrant-ubuntu-trusty-64:/vagrant/newcontainer$ | 07:41 |
| notmyname | I just did this exact thing for my kid's soccer team a few weekends ago (upload a bunch of photos and server them as a static website) | 07:41 |
| stevage | that doesn't seem to have enabled it. | 07:41 |
| notmyname | interesting. I hadn't seen that swift browser before | 07:42 |
| notmyname | stevage: do you have access to curl? | 07:42 |
| stevage | hmm, seems to work in my browser with a trailing slash, but not without it. | 07:42 |
| stevage | http://vault.melbourne.vicnode.org.au:8888/v1/AUTH_5efcf00a5431448586564b8341ba6a17/newcontainer/ | 07:42 |
| stevage | curl? yep. | 07:42 |
| stevage | where I'm intending to end up is a small NeCTAR node running a simple (probably static) website that points to all the files on VicNode (Swift) | 07:43 |
| notmyname | stevage: ok, and do you know the auth token (ie can you stick it in an env var)? | 07:44 |
| stevage | what web UI did you use for your project? | 07:44 |
| stevage | yes, I think it is already - ie, I have downloaded the settings file and sourced it | 07:44 |
| notmyname | fifieldt: hi. I'm helping stevage with getting a static website set up on NeCTAR | 07:44 |
| notmyname | stevage: ( fifieldt is one of the original NeCTAR admins, although he's moved on since then) | 07:44 |
| stevage | oh yeah, I know Tom. | 07:45 |
| stevage | (like the rest of the openstack world I guess :) | 07:45 |
| notmyname | heh | 07:45 |
| * fifieldt waves | 07:45 | |
| *** addnull has joined #openstack-swift | 07:46 | |
| stevage | um, so this settings file sets OS_TENANT_ID and OS_PASSWORD, but I think that's not the same thing? | 07:46 |
| notmyname | stevage: I used a small python script to upload the files. and IIRC some curl to set the staticweb settings | 07:46 |
| stevage | ah, but you built the static website manually? no templates even? | 07:47 |
| notmyname | stevage: `swift stat -v` should give you your token info (assuming your creds are set | 07:47 |
| notmyname | stevage: ya. another little script to generate the html. definitely nothing pretty ;-) | 07:48 |
| stevage | whoa. auth token is massive. heh. | 07:48 |
| notmyname | stevage: heh. ok. throw that in an env var. $TOKEN maybe? that way I can give you some stuff to copy/paste | 07:48 |
| stevage | ok, done - $TOKEN | 07:49 |
| *** quack_quack_ has quit IRC | 07:49 | |
| notmyname | to start with, `curl -I -H "X-Auth-Token: ${TOKEN}" http://vault.melbourne.vicnode.org.au:8888/v1/AUTH_5efcf00a5431448586564b8341ba6a17/newcontainer/` | 07:49 |
| notmyname | that will do a HEAD request to that container and return the headers. you'll be able to see the metadata that is set | 07:49 |
| stevage | it said empty reply from server | 07:50 |
| stevage | $ curl -I -H "X-Auth-Token: ${TOKEN}" http://vault.melbourne.vicnode.org.au:8888/v1/AUTH_5efcf00a5431448586564b8341ba6a17/newcontainer/ curl: (52) Empty reply from server | 07:50 |
| notmyname | hmm...I used the URL you had above. maybe you need https? | 07:50 |
| stevage | sweet. HTTP/1.1 204 No Content X-Container-Meta-Web: listings: true | 07:51 |
| *** nottrobin_ has quit IRC | 07:51 | |
| notmyname | "-web: listings: true" that seems off | 07:51 |
| *** miqui has quit IRC | 07:51 | |
| stevage | so what are we accessing here - Swift's HTTP API? this does something the swift python client can't? | 07:51 |
| *** quack_quack_ has joined #openstack-swift | 07:52 | |
| notmyname | stevage: yes, this is Swift's API. doing with curl allows us to be more explicit. good for debugging | 07:52 |
| stevage | ah, I think I typoed earlier | 07:52 |
| stevage | I set "web:listings" instead of "web-listings" | 07:52 |
| notmyname | ah. that's it | 07:53 |
| *** bkopilov has quit IRC | 07:53 | |
| notmyname | ok, here's the new thing to copy/paste | 07:53 |
| stevage | HTTP/1.1 204 No Content X-Container-Meta-Web-Listings: true X-Container-Meta-Web: listings: true | 07:53 |
| stevage | now: | 07:53 |
| notmyname | ah, ok :-) | 07:53 |
| notmyname | way ahead of me :-) | 07:53 |
| stevage | still not browsable | 07:53 |
| *** nottrobin_ has joined #openstack-swift | 07:54 | |
| stevage | (yeah, I'm actually pretty comfortable with command line etc, run a lot of linux servers - I've just never really used openstack from cli) | 07:54 |
| notmyname | stevage: you have the x-container-meta-web-index value set? | 07:54 |
| stevage | I do now! | 07:55 |
| notmyname | stevage: ok, it's because you have that set to index.html and you have an index.html object in that container | 07:55 |
| stevage | ok, so now it's browsable with trailing / | 07:55 |
| notmyname | stevage: yup. I see it | 07:56 |
| stevage | ah ok, makes sense now. | 07:56 |
| stevage | I can either have my own index.html or allow the default browsing thing. | 07:56 |
| notmyname | stevage: right | 07:56 |
| stevage | so...the default directory listing is standard swift? | 07:56 |
| stevage | but I can CSS-ify it? | 07:57 |
| notmyname | stevage: the auto-generated listing is the bare-bones copy of apache's index functionality | 07:57 |
| notmyname | ya, everything you're using there is included in "standard swift" (ie it's all upstream functionality | 07:57 |
| stevage | cool. and it supports the pesudo-directory break-on-slash thing | 07:57 |
| stevage | sweet, got some basic CSS going. | 08:00 |
| notmyname | stevage: ya. swift supports breaking on arbitrary delimiter characters. and the "staticweb" functionality uses the / to break it up | 08:00 |
| notmyname | I'm curious about the need for the trailing / on the listing | 08:01 |
| notmyname | shoud return a 301 redirect in that case | 08:01 |
| fifieldt | could be load balancer | 08:01 |
| fifieldt | ? | 08:01 |
| notmyname | ah. could also be my browser cache. curl says 301 there | 08:01 |
| notmyname | see? curl is good for debugging :-) | 08:02 |
| stevage | shouldn't be a problem for me, I'll have an nginx in front of it I think | 08:02 |
| notmyname | stevage: so what else do you need? how can I help? | 08:02 |
| notmyname | stevage: for serving the content? or uploading? | 08:02 |
| stevage | actually you've solved my biggest blockers, so that's awesome | 08:02 |
| notmyname | great! | 08:02 |
| stevage | I'll like have nginx for serving content. There'll be some other static stuff that I'll just serve from a normal file store I think. | 08:03 |
| notmyname | http://adrift.org.au is pulling content directly from the NeCTAR Swift cluster. I'd love to see your site when it's put together (if it's a public thing). I'm always looking for end-user stories :-) | 08:03 |
| stevage | yeah, it's very public. | 08:03 |
| stevage | It's an open data project for VicRoads, our road management authority | 08:04 |
| stevage | similar to Google StreetView, but a different tech | 08:04 |
| stevage | they send a car out along the whole network every 2 years, taking 5 photos every 20 metres | 08:04 |
| stevage | they've never had a way to share the images with anyone | 08:04 |
| notmyname | so all those photos are what you're putting in swift? | 08:04 |
| stevage | yeah. there's a lot of associated raw data, too. | 08:05 |
| notmyname | that's so cool! | 08:05 |
| stevage | well, metadata | 08:05 |
| stevage | so also I have to build a kind of map interface to it | 08:05 |
| stevage | I think I know how all the pieces fit together now | 08:05 |
| stevage | just afraid it might be too big for me to get done | 08:06 |
| notmyname | please let me know how I can help. you've obviously found me on twitter, and I'm in here all the time. we also have people in all kinds of timezones in here (although mostly the USA). mattoliverau is in sydney though | 08:06 |
| notmyname | too big? ie just to upload it all? | 08:06 |
| stevage | no, project too big for me to code in the time I have | 08:07 |
| stevage | size is not a huge problem, althoug for some reason upload is pretty slow | 08:07 |
| stevage | is swift support your day job, or...? | 08:08 |
| notmyname | stevage: very special case, but maybe https://github.com/notmyname/directory_uploader will help you. also, I have an older blog post on that topic http://programmerthoughts.com/programming/quickly-uploading-to-cloud-files-part-2/ | 08:08 |
| notmyname | stevage: heh. seeing as it's midnight in san francisco, I guess it's my night job too ;-) | 08:08 |
| notmyname | stevage: I'm one of the swift contributors | 08:08 |
| *** bkopilov has joined #openstack-swift | 08:08 | |
| * fifieldt nods at notmyname's modesty | 08:09 | |
| notmyname | stevage: and I like to help people out to get the to use swift | 08:09 |
| notmyname | stevage: if you're going to LCA in auckland next month, I'll be there | 08:10 |
| stevage | sadly not | 08:10 |
| stevage | I'd never heard of it until a few months ago, but apparently everyone I know goes. | 08:10 |
| stevage | ok, so your python script is faster than using "swift upload ..."? | 08:10 |
| stevage | and if so, how come? | 08:11 |
| stevage | Cloud Files = Rackspace's Swift service? | 08:11 |
| *** Masahiro has quit IRC | 08:11 | |
| notmyname | stevage: the CLI does "helpful" things like a HEAD request for every object you want to upload. mine doesn't. the blog post talks about another way to make things a lot faster: use concurrency | 08:12 |
| stevage | oic, cloud files also has a CDN | 08:12 |
| notmyname | stevage: ya. swift was originally written at rackspace as the engine for the cloud files product. I used to work there. | 08:12 |
| stevage | oh, cool. so to use your script is it just the HTTP endpoint I have to change? everything else is the same b/w rackspace and nectar | 08:13 |
| stevage | ? | 08:13 |
| stevage | HTTPS rather | 08:13 |
| *** rledisez has joined #openstack-swift | 08:14 | |
| notmyname | stevage: should be. no warranties and I've not tested that, etc etc. but yeah. rackspace cloud files == swift. and nectar == swift. | 08:14 |
| notmyname | stevage: yup. I just checked. nectar is running a recentish version of swift (`curl https://vault.melbourne.vicnode.org.au:8888/info | python -m json.tool`) | 08:15 |
| *** jistr has joined #openstack-swift | 08:16 | |
| *** Masahiro has joined #openstack-swift | 08:16 | |
| notmyname | compare at rackpsace (`curl https://storage101.dfw1.clouddrive.com/info | python -m json.tool`) | 08:17 |
| * notmyname needs to finish writing this presentation | 08:17 | |
| notmyname | stevage: please let me know where else I can help point you in the right direction | 08:18 |
| stevage | seriously, you've been a huge help - was really frustrated, and now I'm on the way forward again | 08:18 |
| stevage | (and me too - only I need to *start* writing a presentation for tomorrow morning. ulp.) | 08:18 |
| notmyname | yes, but my presentation starts in just under 10 hours ;-) | 08:19 |
| stevage | 15 here. :) | 08:21 |
| stevage | good luck! | 08:22 |
| notmyname | thanks. you too | 08:24 |
| *** addnull has quit IRC | 08:24 | |
| notmyname | has anyone seen or used https://github.com/wizzard/SwiftFS ? the author's contact link is mega.co.nz | 08:44 |
| *** addnull has joined #openstack-swift | 08:45 | |
| *** jordanP has joined #openstack-swift | 08:46 | |
| *** nellysmitt has quit IRC | 08:49 | |
| *** exploreshaifali has joined #openstack-swift | 08:50 | |
| *** jordanP has quit IRC | 08:51 | |
| *** nellysmitt has joined #openstack-swift | 08:52 | |
| *** nellysmitt has quit IRC | 08:54 | |
| *** nellysmitt has joined #openstack-swift | 08:56 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/swift: Updated from global requirements https://review.openstack.org/88736 | 08:59 |
| *** acoles_away is now known as acoles | 08:59 | |
| *** jordanP has joined #openstack-swift | 09:03 | |
| *** Masahiro has quit IRC | 09:05 | |
| *** stevage has quit IRC | 09:06 | |
| *** Masahiro has joined #openstack-swift | 09:08 | |
| *** nellysmitt has quit IRC | 09:12 | |
| *** exploreshaifali has quit IRC | 09:12 | |
| *** nellysmitt has joined #openstack-swift | 09:18 | |
| notmyname | ok, presentation done. time to go to bed | 09:19 |
| *** jordanP has quit IRC | 09:21 | |
| *** Roland has joined #openstack-swift | 09:21 | |
| *** oomichi has quit IRC | 09:22 | |
| *** jordanP has joined #openstack-swift | 09:36 | |
| *** kopparam has quit IRC | 09:37 | |
| *** addnull has quit IRC | 09:41 | |
| *** nellysmitt has quit IRC | 09:45 | |
| *** aix has joined #openstack-swift | 09:46 | |
| *** dmorita has quit IRC | 09:46 | |
| *** Masahiro has quit IRC | 09:56 | |
| *** Masahiro has joined #openstack-swift | 10:00 | |
| *** kopparam has joined #openstack-swift | 10:05 | |
| *** Masahiro has quit IRC | 10:09 | |
| *** jordanP has quit IRC | 10:17 | |
| *** nellysmitt has joined #openstack-swift | 10:28 | |
| *** jordanP has joined #openstack-swift | 10:29 | |
| *** bkopilov has quit IRC | 10:45 | |
| *** addnull has joined #openstack-swift | 10:46 | |
| *** jistr has quit IRC | 10:51 | |
| *** erlon has joined #openstack-swift | 11:02 | |
| *** kopparam_ has joined #openstack-swift | 11:02 | |
| *** kopparam has quit IRC | 11:03 | |
| *** jistr has joined #openstack-swift | 11:09 | |
| *** Masahiro has joined #openstack-swift | 11:10 | |
| *** ppai has quit IRC | 11:11 | |
| *** Masahiro has quit IRC | 11:14 | |
| *** ppai has joined #openstack-swift | 11:23 | |
| *** haomaiwang has quit IRC | 11:23 | |
| openstackgerrit | Hisashi Osanai proposed openstack/swift: Allow hostnames for nodes in Rings https://review.openstack.org/133155 | 11:24 |
| *** bkopilov has joined #openstack-swift | 11:27 | |
| *** addnull has quit IRC | 11:27 | |
| Roland | Hello I have a quick question but I don't know if this is the right place to do so but anyway here goes. Currently we are deploying a standalone swift cluster with keystone as the authentication service. My question is can I run to completely separte keystone servers? This meaning that even if the same project and username exists on both keystone servers it won't conflict on de swift cluster itself? | 11:33 |
| *** yuanz has quit IRC | 11:42 | |
| *** yuanz has joined #openstack-swift | 11:43 | |
| acoles | Roland: never tried it, I think you would need two instances of the authtoken middleware in the swift proxy server, one pointing to each keystone service, BUT I suspect that may not work because (looking at the code) the second authtoken will remove any ID attributes that the first may add to the request env | 11:53 |
| acoles | Roland: you could try to verify that in #openstack-keystone | 11:53 |
| *** addnull has joined #openstack-swift | 12:02 | |
| *** ppai has quit IRC | 12:04 | |
| *** X019 has quit IRC | 12:08 | |
| Roland | Acoles: Okay I will try it there as a side note I will use two different proxies each connecting to a different keystone server but using the same swift cluster. Do you think it will work? | 12:17 |
| *** ppai has joined #openstack-swift | 12:18 | |
| *** cdelatte has joined #openstack-swift | 12:24 | |
| *** bkopilov has quit IRC | 12:27 | |
| *** jistr has quit IRC | 12:27 | |
| *** jistr has joined #openstack-swift | 12:28 | |
| *** tellesnobrega has joined #openstack-swift | 12:29 | |
| *** bkopilov has joined #openstack-swift | 12:31 | |
| *** silor has joined #openstack-swift | 12:32 | |
| acoles | Roland: i guess that would work, but swift will not distinguish between users authenticated on the two keystones i.e. project:user X:Y in keystone A will gain access to the same swift account as project:user X:Y in keystone B. Even if you separate the account namespace prefixes in the service endpoint returned from each keystone service, that will not prevent users with same id/project accessing each others accounts i.e. its | 12:35 |
| acoles | not secure. | 12:35 |
| Roland | Acoles: Okay thank you very much if have all the information I need right now! | 12:39 |
| *** kopparam_ has quit IRC | 12:40 | |
| *** kopparam has joined #openstack-swift | 12:40 | |
| *** kopparam has quit IRC | 12:41 | |
| *** ppai has quit IRC | 12:41 | |
| *** miurahr has joined #openstack-swift | 12:43 | |
| *** Masahiro has joined #openstack-swift | 12:44 | |
| *** ppai has joined #openstack-swift | 12:46 | |
| *** Masahiro has quit IRC | 12:49 | |
| *** sandywalsh has joined #openstack-swift | 12:52 | |
| *** tellesnobrega has quit IRC | 12:53 | |
| *** exploreshaifali has joined #openstack-swift | 13:03 | |
| *** miurahr has quit IRC | 13:05 | |
| *** miurahr has joined #openstack-swift | 13:08 | |
| *** miurahr has quit IRC | 13:29 | |
| *** aerwin_ has joined #openstack-swift | 13:32 | |
| *** kopparam has joined #openstack-swift | 13:41 | |
| *** addnull has quit IRC | 13:42 | |
| *** bkopilov has quit IRC | 13:43 | |
| *** tdasilva has joined #openstack-swift | 13:43 | |
| *** kopparam has quit IRC | 13:48 | |
| *** kopparam has joined #openstack-swift | 13:53 | |
| *** addnull has joined #openstack-swift | 13:54 | |
| *** addnull has quit IRC | 13:54 | |
| *** SkyRocknRoll has quit IRC | 13:54 | |
| *** kopparam has quit IRC | 14:01 | |
| *** mahatic has joined #openstack-swift | 14:02 | |
| *** SkyRocknRoll has joined #openstack-swift | 14:06 | |
| *** ppai has quit IRC | 14:16 | |
| *** SkyRocknRoll has quit IRC | 14:25 | |
| *** nshaikh has quit IRC | 14:33 | |
| *** Masahiro has joined #openstack-swift | 14:33 | |
| *** Masahiro has quit IRC | 14:38 | |
| *** mahatic has quit IRC | 14:44 | |
| *** mahatic has joined #openstack-swift | 14:45 | |
| *** delattec has joined #openstack-swift | 14:59 | |
| *** cdelatte has quit IRC | 15:01 | |
| *** lpabon has joined #openstack-swift | 15:07 | |
| *** miurahr has joined #openstack-swift | 15:08 | |
| *** tellesnobrega has joined #openstack-swift | 15:12 | |
| *** nellysmitt has quit IRC | 15:12 | |
| *** miurahr has quit IRC | 15:13 | |
| *** exploreshaifali has quit IRC | 15:14 | |
| *** dmsimard_away is now known as dmsimard | 15:15 | |
| *** nellysmitt has joined #openstack-swift | 15:19 | |
| *** silor has quit IRC | 15:23 | |
| *** tellesnobrega has quit IRC | 15:28 | |
| *** kani has joined #openstack-swift | 15:30 | |
| ctennis | portante: I wanted to talk a little more about this replicator sync stuff if you have a few minutes today | 15:33 |
| *** k4n0 has quit IRC | 15:40 | |
| *** delatte has joined #openstack-swift | 15:41 | |
| *** acoles is now known as acoles_away | 15:42 | |
| *** delattec has quit IRC | 15:43 | |
| kani | Hi... I am new to openstack-swift. I have configured swift as glance's banckend. glance and swift services are running in 2 different vms. While uploading an image to glance, it is uploaded to glance and then it is chunked and transferred to swift. Is there any configuration to upload directly to swift to avoid this 2 hops? | 15:45 |
| *** sagar_nikam has joined #openstack-swift | 15:46 | |
| *** miurahr has joined #openstack-swift | 15:46 | |
| openstackgerrit | Daniel Wakefield proposed openstack/python-swiftclient: Fix misnamed dictionary key. https://review.openstack.org/129574 | 15:47 |
| *** tellesnobrega has joined #openstack-swift | 15:49 | |
| openstackgerrit | Daniel Wakefield proposed openstack/python-swiftclient: Fix misplaced check for None in SwiftUploadObject. https://review.openstack.org/133107 | 15:51 |
| *** aix has quit IRC | 15:55 | |
| dmsimard | notmyname: Haven't used SwiftFS but I've tried s3ql. | 16:00 |
| *** david-lyle_afk is now known as david-lyle | 16:06 | |
| *** ashaw_ has quit IRC | 16:09 | |
| *** Masahiro has joined #openstack-swift | 16:22 | |
| *** exploreshaifali has joined #openstack-swift | 16:23 | |
| *** Masahiro has quit IRC | 16:26 | |
| *** lpabon has quit IRC | 16:32 | |
| *** jdaggett_ is now known as jdaggett | 16:37 | |
| *** Roland has quit IRC | 16:42 | |
| kani | I have configured swift as glance's banckend. glance and swift services are running in 2 different vms. While uploading an image to glance, it is uploaded to glance and then it is chunked and transferred to swift. Is there any configuration to upload directly to swift to avoid this 2 hops? | 16:45 |
| kani | can someone help me? | 16:46 |
| *** exploreshaifali has quit IRC | 16:49 | |
| *** rdaly2 has joined #openstack-swift | 16:50 | |
| glange_ | kani: I don't know much about glance -- if you stick around, you might get an answer as people come onto channel and start their workday | 16:52 |
| glange_ | kani: also, you might try asking on a nova channel, they might know the answer over there | 16:53 |
| glange_ | #openstack-nova | 16:54 |
| kani | +glange_: Thank you | 16:57 |
| *** sagar_nikam has quit IRC | 17:01 | |
| *** tkay has joined #openstack-swift | 17:05 | |
| *** kani has quit IRC | 17:07 | |
| notmyname | good morning | 17:12 |
| *** tellesnobrega has quit IRC | 17:13 | |
| *** silor has joined #openstack-swift | 17:13 | |
| *** openstackgerrit has quit IRC | 17:19 | |
| *** openstackgerrit has joined #openstack-swift | 17:20 | |
| peluse | good morning | 17:33 |
| *** bkopilov has joined #openstack-swift | 17:38 | |
| *** rledisez has quit IRC | 17:41 | |
| *** tab___ has joined #openstack-swift | 17:44 | |
| *** aerwin_ has quit IRC | 17:49 | |
| openstackgerrit | Mahati proposed openstack/swift: OPTIONS verb implemented for object server. Note: Tests are not written yet. This is only an initial version for review. https://review.openstack.org/140103 | 18:00 |
| mahatic | notmyname, good morning | 18:01 |
| notmyname | mahatic: good morning | 18:01 |
| *** jwang__ has quit IRC | 18:02 | |
| mahatic | notmyname, just submitted an initial version of patch, let me know the review when you find time | 18:02 |
| notmyname | mahatic: will do | 18:03 |
| *** jordanP has quit IRC | 18:09 | |
| *** Masahiro has joined #openstack-swift | 18:11 | |
| *** jistr has quit IRC | 18:11 | |
| *** jonb has joined #openstack-swift | 18:14 | |
| *** Masahiro has quit IRC | 18:15 | |
| *** abhirc has joined #openstack-swift | 18:24 | |
| *** shri has joined #openstack-swift | 18:33 | |
| tdasilva | notmyname, clayg: Hi, I've seen references in docs that a large object manifest file cannot be versioned, but while testing against master I'm able to version not only a segment but also the manifest file. Do you guys have any history on this? wondering if it's a bug that was introduced recently or if there's something else going on that is not obvious to me... | 18:37 |
| * notmyname wonders if it was introduced when manifests were pulled to middleware | 18:38 | |
| tdasilva | notmyname: plus, I think the unit test for the case is broken: https://github.com/openstack/swift/blob/master/test/unit/proxy/test_server.py#L4252,L4273 | 18:47 |
| *** nellysmitt has quit IRC | 18:52 | |
| *** lpabon has joined #openstack-swift | 19:02 | |
| notmyname | tdasilva: sorry. was in a meeting. out now | 19:10 |
| tdasilva | notmyname: np | 19:10 |
| tdasilva | notmyname: i'm still digging to see what I can find out... | 19:11 |
| *** zaitcev has joined #openstack-swift | 19:15 | |
| *** ChanServ sets mode: +v zaitcev | 19:15 | |
| openstackgerrit | Mahati proposed openstack/swift: OPTIONS verb implemented for object server. Many times new deployers get mysterious errors after first setting up their Swift clusters. Most of the time, the errors are because the values in the ring are incorrect (e.g. a bad port number). OPTIONS will be https://review.openstack.org/140103 | 19:19 |
| *** aix has joined #openstack-swift | 19:19 | |
| *** zul has quit IRC | 19:25 | |
| notmyname | tdasilva: the issues IIRC is that you can't copy the manifest since that squashes it down to one object. so if a manifest refers to more than max_object_size, the versioning can't work. however, a manifest can refer to a versioned object. make sense? | 19:31 |
| tdasilva | notmyname: oh...i understand why you wouldn't want to version the manifest file...just saying, i think it is at the moment.... | 19:32 |
| notmyname | tdasilva: thanks for looking. | 19:33 |
| *** zul has joined #openstack-swift | 19:38 | |
| *** abhirc has quit IRC | 19:39 | |
| *** abhirc has joined #openstack-swift | 19:51 | |
| *** jwang has joined #openstack-swift | 19:54 | |
| *** Masahiro has joined #openstack-swift | 19:59 | |
| *** nellysmitt has joined #openstack-swift | 20:01 | |
| *** Masahiro has quit IRC | 20:04 | |
| *** gyee has joined #openstack-swift | 20:13 | |
| *** tdasilva has quit IRC | 20:36 | |
| *** nellysmitt has quit IRC | 20:37 | |
| portante | ctennis: I am available now | 20:47 |
| *** silor has quit IRC | 20:51 | |
| *** tdasilva has joined #openstack-swift | 20:52 | |
| *** abhirc_ has joined #openstack-swift | 21:04 | |
| *** annegent_ has joined #openstack-swift | 21:04 | |
| *** abhirc has quit IRC | 21:06 | |
| *** annegent_ has quit IRC | 21:11 | |
| notmyname | ctennis: best. bug report. ever. thanks for including the builder files that actually exhibit the bug | 21:12 |
| *** fifieldt_ has joined #openstack-swift | 21:15 | |
| mattoliverau | Morning | 21:16 |
| notmyname | hi mattoliverau | 21:17 |
| mattoliverau | notmyname: how'd the presentation go? And how much coffee have you had to drink to stay awake today :p | 21:18 |
| notmyname | mattoliverau: heh | 21:18 |
| notmyname | I hope it went well. haven't seen the recording yet | 21:18 |
| *** fifieldt has quit IRC | 21:19 | |
| *** gyee has quit IRC | 21:32 | |
| *** tdasilva has quit IRC | 21:36 | |
| notmyname | mattoliverau: FWIW https://www.youtube.com/watch?v=EUpuMTZOMVI&t=40m56s | 21:46 |
| *** Masahiro has joined #openstack-swift | 21:48 | |
| mattoliverau | Nice, I'll give it watch :) | 21:49 |
| *** Masahiro has quit IRC | 21:53 | |
| *** mahatic has quit IRC | 22:05 | |
| *** oomichi has joined #openstack-swift | 22:11 | |
| *** bill_az has joined #openstack-swift | 22:11 | |
| mattoliverau | notmyname: just finished it, you did well! Nice work | 22:15 |
| bill_az | question - looking at the Paris user survey. Under compatibility API section, It shows 34% of production deployments using S3 compatibility API. Does that mean that 34% of all swift deployments are using swift3 middleware? | 22:16 |
| bill_az | http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 | 22:16 |
| notmyname | bill_az: I don't think you can draw that conclusion | 22:20 |
| notmyname | bill_az: "use s3" might mean some older nova and/or glance functionality. more of it is probably using swift3 with swift and using s3 clients | 22:21 |
| bill_az | notmyname: I was suspicious of such a large number. Do you know if production deployments are using swift3 or is there another approach for this? | 22:21 |
| notmyname | bill_az: swift3 is the only compat thing I know of | 22:21 |
| notmyname | bill_az: on the other hand, I don't think the full set of swift deployments are represented in the survey | 22:22 |
| bill_az | notmyname: right, I'm sure it's not a very statistically correct sample. But deployers/end users that are using swift3 middleware find that it covers most of their requirements? (it works for the most common use cases) | 22:23 |
| notmyname | bill_az: I think there's selection bias. the answer to the question you asked is "yes" because otherwise they wouldn't use it ;-) | 22:24 |
| notmyname | bill_az: but yeah, the more general question remains | 22:24 |
| notmyname | bill_az: swift 3 covers some basic functionality. but it's under active development to close some of the remaining gaps | 22:25 |
| bill_az | bill_az: yes, we did some testing of this and are working with Kota to update compatibilty matrix thats in Swift wiki, and hope to also assist with new features. | 22:26 |
| notmyname | nice | 22:26 |
| bill_az | notmyname: but I wanted to see if you could help interpret the results in the fall survye | 22:27 |
| notmyname | bill_az: I don't have any more insights than you do | 22:27 |
| notmyname | bill_az: one thing I've speculated on in the past is that the use of swift3 might show that people are moving from s3 to swift | 22:28 |
| bill_az | notmyname: I would like to believe that too | 22:30 |
| notmyname | bill_az: one piece of evidence for this is that there are more s3 compat cluster reported in prod, even though there are the same number reported as POC. ie the fact that newer clusters seem to tend away from swift3 shows that s3 compat is an important bridge but not the key feature | 22:31 |
| *** tellesnobrega has joined #openstack-swift | 22:33 | |
| bill_az | notmyname: that surprised me, I would expect to see a larger POC percentage, but what you say makes sense | 22:33 |
| bill_az | notmyname: And I would hope it's not the key feature; other features/properties of Swift provide the incentive to move | 22:34 |
| notmyname | bill_az: oh don't worry. that's just speculation layered on guesses, all mixed with hopes and dreams | 22:35 |
| *** nellysmitt has joined #openstack-swift | 22:38 | |
| bill_az | notmyname: bottom line, we're free to interpret the results in the way that makes us happy! ;-) Thanks | 22:39 |
| notmyname | lol | 22:39 |
| notmyname | yes | 22:40 |
| notmyname | fifieldt_: ^^ you'll love that comment about the user survey ;-) | 22:40 |
| *** nellysmitt has quit IRC | 22:43 | |
| ctennis | sorry portante I was in transit today, I'll hit you up tomorrow | 22:49 |
| *** tellesnobrega has quit IRC | 22:49 | |
| *** sungju has joined #openstack-swift | 22:50 | |
| ctennis | portante: sorry, I'm reading my history adn realize I meant to ping peluse originally! | 22:52 |
| ctennis | notmyname: set my straight | 22:52 |
| eikke | notmyname: I toook the liberty today to slightly edit the 'priority reviews' wiki page, add one a link to a minor review related to the splice patch | 22:57 |
| eikke | hope that's OK | 22:58 |
| notmyname | eikke: thanks for letting me know | 22:59 |
| eikke | y/w | 23:00 |
| fifieldt_ | bill_az, it's important to read the start of the results before looking at the graphs and comparing them to last year | 23:00 |
| fifieldt_ | in the most recent survey we basically only looked at stuff that had been updated since Feb or something | 23:01 |
| fifieldt_ | I just woke up, but feel free to email me random things and I can look into them | 23:01 |
| *** jonb has quit IRC | 23:04 | |
| bill_az | fifieldt_: ok, I have read the introduction, and I wasn't comparing with past surveys, but trying to understand compatibility api section, stating that 34% of production deployments use s3 api. That seems high for s3 & swift, but as nonmyname said, this number could also include glance and other projects | 23:09 |
| fifieldt_ | ah,. sorry, my bad - early morning :) | 23:10 |
| fifieldt_ | that number is primarily for swift | 23:10 |
| fifieldt_ | I can try and do some correlation | 23:10 |
| fifieldt_ | (ps the next version of the survey will have this directly correlated, I hope - as in it will only be shown for people who tick swift) | 23:11 |
| bill_az | fifieldt_: thanks, it would be really useful know how much of that is swift3 middleware | 23:12 |
| fifieldt_ | so I did some very rough grepping, which is probably innacurate, but the lowest % I'd say for swift3 would be 20% of swift users | 23:15 |
| fifieldt_ | but this was over a different dataset | 23:16 |
| fifieldt_ | rather than the survey one | 23:16 |
| fifieldt_ | a larger dataset | 23:16 |
| fifieldt_ | but 20% seems like a decent low | 23:16 |
| fifieldt_ | and 34 a decent high | 23:16 |
| openstackgerrit | Samuel Merritt proposed openstack/swift: Improve object-replicator startup time. https://review.openstack.org/140178 | 23:26 |
| *** annegent_ has joined #openstack-swift | 23:26 | |
| *** rdaly2 has quit IRC | 23:31 | |
| *** miurahr has quit IRC | 23:36 | |
| *** Masahiro has joined #openstack-swift | 23:37 | |
| *** Masahiro has quit IRC | 23:41 | |
| *** lpabon has quit IRC | 23:45 | |
| *** rebelshrug has joined #openstack-swift | 23:46 | |
| *** dmsimard is now known as dmsimard_away | 23:52 | |
| *** gyee has joined #openstack-swift | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!