*** kei_yama has quit IRC | 00:01 | |
*** kei_yama has joined #openstack-swift | 00:03 | |
mattoliverau | morning | 00:06 |
---|---|---|
*** linkmark has quit IRC | 00:07 | |
*** itlinux has joined #openstack-swift | 00:15 | |
openstackgerrit | Merged openstack/swift master: Remove contentdir hack https://review.openstack.org/585894 | 00:17 |
*** gyee has quit IRC | 00:23 | |
*** itlinux has quit IRC | 00:25 | |
openstackgerrit | Merged openstack/swift master: make probe tests voting in the gate https://review.openstack.org/585900 | 00:42 |
openstackgerrit | Merged openstack/swift master: Remove some unnecessary SkipTests https://review.openstack.org/585910 | 00:49 |
*** kei_yama has quit IRC | 01:23 | |
*** kei_yama has joined #openstack-swift | 01:26 | |
openstackgerrit | Nguyen Hai proposed openstack/swift master: add lower-constraints job https://review.openstack.org/556255 | 01:59 |
openstackgerrit | Nguyen Hai proposed openstack/swift master: add lower-constraints job https://review.openstack.org/556255 | 01:59 |
*** psachin`` has joined #openstack-swift | 02:23 | |
*** psachin`` has quit IRC | 02:33 | |
*** links has joined #openstack-swift | 03:52 | |
*** itlinux has joined #openstack-swift | 04:22 | |
*** pcaruana has joined #openstack-swift | 04:28 | |
*** pcaruana has quit IRC | 04:30 | |
*** kei_yama has quit IRC | 04:44 | |
*** kei_yama has joined #openstack-swift | 04:56 | |
*** itlinux has quit IRC | 05:05 | |
*** cshastri has joined #openstack-swift | 05:14 | |
*** silor has joined #openstack-swift | 05:33 | |
*** zigo_ has joined #openstack-swift | 05:53 | |
*** zigo has quit IRC | 05:53 | |
*** bharath12345 has joined #openstack-swift | 06:07 | |
*** bharath12345 has quit IRC | 06:07 | |
*** pavelk has quit IRC | 06:42 | |
*** tesseract has joined #openstack-swift | 06:52 | |
*** rcernin has quit IRC | 07:00 | |
openstackgerrit | Tim Burke proposed openstack/swift master: Add support for multiple root encryption secrets https://review.openstack.org/577874 | 07:05 |
openstackgerrit | Tim Burke proposed openstack/swift master: WIP: multi-key KMIP keymaster https://review.openstack.org/586455 | 07:05 |
*** ccamacho has joined #openstack-swift | 07:20 | |
*** gkadam has joined #openstack-swift | 07:49 | |
*** mikecmpbll has joined #openstack-swift | 07:58 | |
*** geaaru has joined #openstack-swift | 08:01 | |
*** lifeless has quit IRC | 08:54 | |
*** d0ugal has joined #openstack-swift | 09:09 | |
*** lifeless has joined #openstack-swift | 09:11 | |
*** andymccr- has joined #openstack-swift | 09:47 | |
*** andymccr_ has quit IRC | 09:50 | |
*** andymccr has quit IRC | 10:04 | |
*** andymccr- is now known as andymccr | 10:05 | |
*** cshastri has quit IRC | 11:02 | |
*** kei_yama has quit IRC | 11:15 | |
*** cshastri has joined #openstack-swift | 11:17 | |
*** d0ugal has quit IRC | 11:41 | |
*** linkmark has joined #openstack-swift | 12:03 | |
*** bharath12345 has joined #openstack-swift | 12:05 | |
*** armaan has joined #openstack-swift | 12:22 | |
*** armaan has quit IRC | 12:41 | |
*** armaan has joined #openstack-swift | 12:45 | |
*** armaan has quit IRC | 12:49 | |
*** armaan has joined #openstack-swift | 12:50 | |
*** armaan has quit IRC | 12:54 | |
*** bharath12345 has quit IRC | 13:28 | |
*** jistr is now known as jistr|mtg | 13:32 | |
*** ianychoi has joined #openstack-swift | 13:56 | |
*** ianychoi_ has quit IRC | 14:00 | |
openstackgerrit | Tim Burke proposed openstack/swift master: Stop holding on to sys.exc_info tuples quite so much https://review.openstack.org/570477 | 14:01 |
*** links has quit IRC | 14:10 | |
*** jlvacation is now known as jlvillal | 14:18 | |
*** links has joined #openstack-swift | 14:29 | |
*** jistr|mtg is now known as jistr | 14:39 | |
*** links has quit IRC | 15:02 | |
openstackgerrit | Tim Burke proposed openstack/swift master: Stop logging overlapping tracebacks https://review.openstack.org/546808 | 15:04 |
openstackgerrit | Tim Burke proposed openstack/swift master: Have yield_suffixes just take a partition_path https://review.openstack.org/578221 | 15:13 |
*** cshastri has quit IRC | 15:15 | |
*** andymccr has quit IRC | 15:34 | |
*** andymccr has joined #openstack-swift | 15:35 | |
*** gkadam has quit IRC | 15:38 | |
-openstackstatus- NOTICE: A zuul config error slipped through and caused a pile of job failures with retry_limit - a fix is being applied and should be back up in a few minutes | 15:40 | |
*** ChanServ changes topic to "A zuul config error slipped through and caused a pile of job failures with retry_limit - a fix is being applied and should be back up in a few minutes" | 15:40 | |
*** gyee has joined #openstack-swift | 15:52 | |
*** gkadam has joined #openstack-swift | 15:53 | |
*** gkadam has quit IRC | 15:54 | |
*** gkadam has joined #openstack-swift | 15:55 | |
*** openstackgerrit has quit IRC | 16:04 | |
*** silor has quit IRC | 16:11 | |
*** mikecmpbll has quit IRC | 16:11 | |
*** links has joined #openstack-swift | 16:14 | |
*** links has quit IRC | 16:17 | |
*** links has joined #openstack-swift | 16:17 | |
*** links has quit IRC | 16:23 | |
*** tesseract has quit IRC | 16:32 | |
*** bharath12345 has joined #openstack-swift | 17:03 | |
*** bharath12345 has quit IRC | 17:13 | |
*** mikecmpbll has joined #openstack-swift | 17:25 | |
*** geaaru has quit IRC | 18:01 | |
*** openstackgerrit has joined #openstack-swift | 19:30 | |
openstackgerrit | Merged openstack/swift master: add lower-constraints job https://review.openstack.org/556255 | 19:30 |
*** silor has joined #openstack-swift | 19:32 | |
notmyname | hello, owlrd | 19:48 |
*** ccamacho1 has joined #openstack-swift | 20:00 | |
*** ccamacho has quit IRC | 20:01 | |
*** itlinux has joined #openstack-swift | 20:03 | |
itlinux | hello swift guys, I am using Tripleo and the controllers are configured to use swift, I need to limit the usage on this since this is production and we do not want to have dev, eng, fill up the drives on the controllers, what's the best way to set quota (bytes for each project). Thanks | 20:17 |
notmyname | itlinux: will the account quotas work for you? | 20:24 |
itlinux | account meaning x user? No I have AD it will be hard to do that.. | 20:25 |
itlinux | I am not sure if there is only one account set but I assume that each tenant / AD has their own.. | 20:25 |
itlinux | based on each project | 20:25 |
notmyname | no, "account" meaning swift account, not user | 20:28 |
notmyname | the "AUTH_foobar" part of the url | 20:28 |
itlinux | that could work.. | 20:29 |
itlinux | since I believe there is only one account by default | 20:30 |
itlinux | notmyname: what's the best way to check and verify that.. TY | 20:31 |
notmyname | verify what? | 20:32 |
itlinux | that I have only one account? | 20:32 |
notmyname | are you running any utilization reports in your cluster? | 20:33 |
itlinux | no now.. this is all new deployment prodcution and some of this just pop up.. | 20:36 |
itlinux | http://paste.openstack.org/show/726766/ | 20:36 |
notmyname | itlinux: what auth system are you using? keystone? | 20:41 |
itlinux | keystone backend AD | 20:41 |
notmyname | so keystone has mapped some AD users to swift right? in order to pass out storage urls when the user gets an auth token | 20:42 |
itlinux | I have not mapped any specific users for swift in AD | 20:48 |
notmyname | no, I mean you've got some users that auth against keystone. and they get back a token and storage url. what's the global set of storage urls that can be returned? | 20:50 |
notmyname | that will tell you the answer to the question above. how many swift accounts are being used in the cluster? | 20:52 |
itlinux | ok.. what command will that show the option.. | 20:53 |
itlinux | if there is a command to do that.. | 20:53 |
notmyname | no idea. that's your keystone config. | 20:53 |
itlinux | let me check one sec.. | 20:54 |
notmyname | doesn't keystone figure out the swift storage url with a template? isn't it normally "AUTH_$(tenantid)" or soemthing like that? | 20:54 |
notmyname | if that's the case, then do you have any idea how many tenant ids are being used? | 20:54 |
itlinux | yea but I have not done any of that since tripleo handles that part so I have not checked.. | 20:55 |
itlinux | about 2000 or so | 20:55 |
notmyname | ok, so unless there's been some config change to intentionally map every tenant in keystone to the same swift url, you're using a bunch of different swift accounts (ie one per keystone tenant id) | 20:57 |
*** gkadam has quit IRC | 20:58 | |
itlinux | I guess that's correct | 20:58 |
itlinux | which means 2000 or so accounts.. | 20:58 |
notmyname | you can set an individual quota on each of those accounts in swift | 21:00 |
itlinux | ok how? | 21:00 |
itlinux | that's going to be a lot of management to deal with also .. I was hoping to set the quota on a project | 21:01 |
notmyname | I thought project was the same as tenant in keystone | 21:01 |
itlinux | well a project = 1 with many tenants (users) and yes now the changed the names tenants = projects.. | 21:02 |
itlinux | so I want to have tenant(project) many users and set a quota to that not x user per se.. | 21:02 |
notmyname | how to set an account quote: as a reseller admin, you POST the "x-account-quota-bytes: <number of bytes>" header to the account you want to limit | 21:03 |
notmyname | ok, so it sounds like swift's per-account quotas won't work for you | 21:03 |
itlinux | no I do not manage those users.. | 21:04 |
itlinux | some other teams do manage the AD..I just add them to the projects (tenants) they will work on | 21:05 |
notmyname | there are many definitions of "account" in your system. we're not talking about the same one | 21:05 |
notmyname | I am only talking about a swift account. the place you store stuff. which is completely independent of any AD system or auth system or anything like that. | 21:06 |
itlinux | ok let me clear for account I mean the user which is part of the (project/tenant) space.. | 21:07 |
notmyname | swift accounts are used when the auth system says a given token is ok to use with a particular http method against a particular swift account | 21:07 |
itlinux | sounds good thanks for that | 21:07 |
itlinux | ok | 21:07 |
notmyname | AFAIK, keystone has the idea of "tenants", which have been renamed into "projects" | 21:08 |
notmyname | I don't know how keystone works with an AD backend | 21:09 |
itlinux | that's correct.. the merge happen.. for the AD backend.. that's a tricky one I guess.. | 21:10 |
itlinux | do you want to check out the swift.conf file?? | 21:10 |
notmyname | so I'm not sure what you have set up. I don't understand your use of the word "project". is that something internal to your company? something related to AD? somethng related to keystone? | 21:10 |
itlinux | maybe to get an idea .. | 21:10 |
notmyname | no, the swift.conf file wouldn't help. all the mapping of these concepts happens outside of swift (ie in keystone) | 21:11 |
itlinux | no no.. projects = tenants now... same thing.. I just use them to idenfity a space where (user-a, user-b etc.. do their deployments) | 21:12 |
notmyname | to be fair, I *still* don't have a great mental model of the logical things in keystone and how they fit together, so I'm working against my own ignorance here | 21:12 |
itlinux | well thanks for helping out to cover the issue on how it could be solved.. | 21:13 |
*** silor has quit IRC | 21:13 | |
itlinux | much appreciated | 21:13 |
notmyname | but I don't think we solved it yet! :-) | 21:13 |
itlinux | I know.. | 21:13 |
itlinux | working toward it.. | 21:13 |
notmyname | it sounds like you've got a bunch of different people (to avoid the word "users") who are using swift. some of them work on the same thing and share a quota. you'd like to ensure that together they don't exceed the quota, but you're not sure if they are sharing the same storage url in swift or not | 21:15 |
notmyname | I tried to avoid "user", "account", and "project" there :-) | 21:15 |
itlinux | yes that's right | 21:16 |
notmyname | so *if* they are all using the same storage url, then you can set an quota on the swift account. the swift account is the shared storage url. | 21:17 |
notmyname | the keystone administrator should be able to answer if they share a swift storage url or not | 21:17 |
notmyname | however, if they don't share a storage url, then you will have to find a quota solution somewhere else | 21:17 |
itlinux | let me dig on that and see.. | 21:18 |
notmyname | I'd recommend something that ties the auth system to a utilization system. so you get the utilization for all the storage urls, group them and sum the values, then allow or deny subsequent requests via the auth system based on their current utilization against the quota | 21:18 |
itlinux | notmyname: I got this from the glance-api.conf swift_store_config_file=/etc/glance/glance-swift.conf which is a file calling the user=service:glance | 21:25 |
itlinux | and it has a password and the default domain for example.. on for that account.. | 21:25 |
openstackgerrit | Thiago da Silva proposed openstack/swift master: Update saio sample config files https://review.openstack.org/586703 | 21:29 |
notmyname | tdasilva: yes! | 21:31 |
tdasilva | quick question regarding upgrade of swift cluster, do we document anywhere if there's an expectation that backend services should be upgraded before proxy? | 21:34 |
itlinux | notmyname looking at the account-server.conf it looks like it calls a user (swift) | 21:34 |
itlinux | I guess I could do a quota on that user | 21:35 |
tdasilva | itlinux: that's just the linux user running the service | 21:35 |
itlinux | ahh ok tdasilva: I am using OOO | 21:36 |
tdasilva | not to be confused with a user of the cluster | 21:36 |
itlinux | so trying to do quota on that.. | 21:36 |
notmyname | tdasilva: I did once in a blog post somewhere. not sure if that's in the admin guide in our docs or anything | 21:36 |
tdasilva | zaitcev, notmyname: just wondering if it's worth doing all the dance in the PUT+POST to support any order of upgrade | 21:38 |
itlinux | yes notmyname: the user are configured with admin_tenant_name = %SERVICE_TENANT_NAME% | 21:38 |
tdasilva | why can't we just say: you must upgrade backend services before upgrading proxy | 21:38 |
itlinux | and the admin is admin_user = %SERVICE_USER% | 21:38 |
notmyname | tdasilva: I'd be totally for putting the restriction on it | 21:39 |
zaitcev | The simple answer is that the dance is not all the, so looks like worth the effort. | 21:39 |
tdasilva | zaitcev: not sure this https://etherpad.openstack.org/p/swift-put-post is worth it | 21:40 |
notmyname | tdasilva: we've had upgrade guidance in the changelog for stuff like that before. I think it makes sense to do it again | 21:40 |
tdasilva | zaitcev: anyway we spin it, it's just a hack to support people upgrading anyway they want | 21:41 |
zaitcev | I think you still need the safety. The problem is, I don't remember what happens when new proxy is trying to put to old object. I think it just creates a broken object that auditor later quarantines. | 21:46 |
zaitcev | But at one point I had them stuck and auditor would not take them. | 21:46 |
zaitcev | Seeing at what our customers to do their clusters I really don't want to trust them with upgrade instructions. They can perform simple actions like "upgrade storage first, proxy next". Well, barely. But then they can easily find an old node that was forgotten. | 21:48 |
zaitcev | brb | 21:49 |
tdasilva | zaitcev: i see your point, i'm just weighing your words on keeping user safe from inability to follow instructions with the need to add hacks to our code | 21:51 |
notmyname | tdasilva: zaitcev: scratch everything I said. we need to either order upgrades | 21:52 |
notmyname | eg an all-in-one deployment model (PACO on each node, in a multi-node cluster) is relatively common. we need to ensure that upgrading one server doesn't break thinks when that upgraded proxy talks to the older object server | 21:52 |
* tdasilva nods | 21:56 | |
notmyname | tdasilva: at some point, I'd love to unify the sample configs in etc/ and the saio ones in doc/saio/ (and ones in examples/ and ones proposed under tools/) | 21:57 |
tdasilva | notmyname: yeah, that would be nice! ....talking about that... | 21:59 |
tdasilva | kota_: please remind me again what do we need to do to enable s3 testing in all our functional tests in the gate? | 21:59 |
tdasilva | remove swift3 support from devstack? | 22:00 |
*** itlinux has quit IRC | 22:05 | |
*** itlinux has joined #openstack-swift | 22:10 | |
timburke | Ïyeah, iirc | 22:12 |
*** mikecmpbll has quit IRC | 22:28 | |
*** geaaru has joined #openstack-swift | 22:34 | |
zaitcev | tdasilva, notmyname: At some point PUT+POST had a simple back-off mechanism that allowed a proxy to switch dynamically between new and old and that was not only any-order, but also zero-configuration upgrade. In the current patch, the operator is required to flip a setting once all nodes are upgraded. So, all this buys you is safety. | 22:43 |
notmyname | that's good (a flip to "on" when all servers are upgraded) | 22:43 |
zaitcev | clayg made me take that automation out | 22:43 |
zaitcev | Okay, if you say so, I don't mind. | 22:43 |
notmyname | and that removes the need to worry about upgrade order | 22:43 |
zaitcev | It made it easier to test | 22:44 |
notmyname | good for clayg :-) | 22:44 |
timburke | fwiw, i'd kinda like to still have the graceful degradation -- have a some config on the *object* server to say which protocol versions to accept | 22:48 |
timburke | still get the testability improvements (only need the one SHA to test v1-only and v2-only) and you get the seamless upgrade | 22:49 |
timburke | i feel like 'a flip to "on" when all servers are upgraded' is only useful if lurking old servers can't read data written with the new stuff (so, situations like the disable_encryption option) | 22:51 |
timburke | but that shouldn't be an issue here... | 22:51 |
*** itlinux has quit IRC | 23:37 | |
*** itlinux has joined #openstack-swift | 23:50 | |
*** itlinux has quit IRC | 23:50 | |
*** itlinux has joined #openstack-swift | 23:51 | |
*** itlinux has quit IRC | 23:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!