19:01:53 #startmeeting OpenStackClient 19:01:54 Meeting started Thu Sep 10 19:01:53 2015 UTC and is due to finish in 60 minutes. The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:56 yup ;) 19:01:58 The meeting name has been set to 'openstackclient' 19:01:59 o/ 19:02:00 yay! 19:02:44 topics: lhcheng nod, swift accounts, any lingering patches before we release one more version in L 19:04:13 so let's get started then… 19:04:24 #topic lhcheng core status 19:04:51 looks like that will be a thing tomorrow, welcome Lin 19:05:13 mestery: will you push a git tag on stable/kilo for vmware-nsx? tag=2015.1.2 19:05:15 sorry wrong room 19:05:22 salv-orlando: it happens ;) 19:05:52 dtroyer: i was thinking, when i did my ML post, i picked friday arbitrarily, maybe today at the end of the meeting is better :) 19:05:52 #topic next release 19:06:22 stevemar: it is usually a week, we have a small community and pretty much know the outcome, I'm fine with that 19:06:32 cool :) 19:06:48 #action make lhcheng core at end of meeting 19:07:09 kk, next release 19:07:52 for release bits, I'd like to get terry's log bits finished for completeness 19:08:18 stevemar: thanks for the nomination :) 19:08:23 do you feel strongly about the v3 default for this? 19:08:41 dtroyer: i'm on the fence 19:08:45 this release is likely to be informally considered 'Liberty' 19:08:56 thanks dtroyer, will try to help the team as much as I can. 19:09:03 maybe wait til M, this way devstack and osc are both v3 by default 19:09:11 lhcheng: thank you, you have already been a great help 19:09:24 stevemar: I'm ok with that 19:09:44 * lhcheng slow to respond - have another meeting at this time 19:10:02 np 19:10:19 I don't think I see any others that I'd want to hold up a release for 19:10:54 I wonder if we should do more testing on nova command before release, just to make sure the latest release of novaclient doesn't break anything else. 19:11:00 i'd like this in ... 19:11:17 https://review.openstack.org/#/c/212977/ 19:12:11 and this one https://review.openstack.org/#/c/217647/ 19:12:35 +2 on the first one, not sure how I missed it this morning 19:14:53 on the second one, and it's followup, I'd like better help strings to clarify when the domain arg is needed 19:14:53 what is there doesn't seem clear to me 19:18:09 dtroyer: so that help string ... 19:18:34 we might have to change :) 19:18:35 https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/common.py#L126-L153 19:19:09 probably. good help is more important that a few lines of code 19:19:13 if you want, you can push through that previous patch in question, and we can open a bug to fix up the strings here? 19:19:34 we just need to decide on the veribiage 19:19:39 if I do it I might un-normalize thos e functions ;) 19:20:05 but I can do that 19:21:21 #action dtroyer: follow up https://review.openstack.org/#/c/217647/ and https://review.openstack.org/#/c/211835/ to clarify help strings 19:21:40 nooo don't un-normalize :P 19:22:11 I don't see a huge win with the functions if they tryly are not common... 19:22:33 maybe use a decorator? 19:22:50 * dtroyer ducks 19:24:23 * stevemar throws decorators at dtroyer 19:24:34 i really dont like decorators 19:25:05 I'm not a big fan either, but that logging review seemed simple enough 19:25:21 the function was common though! it's common to neutron/nova and keystone so far 19:25:36 updating the stuff in /doc won't be fun >.< 19:25:43 does the same help string make sense in all of the use cases? 19:26:03 I'm not convinced it does 19:27:05 so, the individual --project or --user may differ 19:27:21 but --project-domain and --user-domain and --group-domain should all be the same 19:27:50 its "use this option if you want to specify a in a non-default domain" 19:28:15 that's not what the current help says, it talks about collisions. 19:28:39 so if there is one foo in all of the projects, I don't need —project-domain even if foo isn't in the default domain? 19:28:42 i'll admit the current verbiage is not the best 19:29:13 no, you need --project-domain even if foo is the only one 19:29:14 I just need to be clear on what the actual requirement is to fix it 19:29:18 i get what you're saying 19:29:27 gotcha 19:30:13 * dtroyer again wishes domain had been grafted onto project with a separator 19:30:54 any other reviews we should talk about? 19:32:41 dtroyer: nah, you need users to be in a certain domain, sometimes, 19:32:44 thats the theory anyway 19:32:55 umm 19:33:20 depending on how fast i code up the swift-y bits, are you game for merging those? 19:33:52 #topic object-store 'account' naming 19:34:53 I just want to go on record in a searchable place that, I really don' tlike using 'account' in the object-store context like that. I honestly feel like it is a dis-service to users who are not familiar with Swift's history 19:35:03 or not reading API/deployment docs 19:35:16 but I can be done with that now 19:35:43 i kinda like "openstack project set --object-store-property" 19:36:06 I thought about that too… 19:36:16 but then we'll have to check if swift is enabled and such 19:36:17 but the user _still_ has to know the difference 19:36:27 that's easy…service catalog 19:36:28 i call upon dhellmann 19:36:47 damn, didn't work 19:36:50 normally does 19:37:12 bucket? 19:37:13 the icky part is that project XXX anythign is cloud admin only 19:37:28 not project list 19:37:29 maybe os object property set/list/unset 19:37:45 terrylhowe: leave the room 19:37:57 I'd rather use acocunt than invent a new word 19:38:01 or container property set/list/unset :) 19:38:28 the problem is those properties apply to swift's account thingy, not to objects or containers 19:38:30 terrylhowe: doesn't container have set/unset already 19:38:39 it should 19:39:35 I feel like we're losing grasp of the consistency, especially with multiple plugins doing stuff willy-nilly 19:39:45 anyway, sorry I’m late carry on with the debug. I don’t really have any good ideas on this one. 19:40:01 so maybe it isn't too bad. go ahead with account and if I figure it out clearly before we release I'll do the work if everyone agrees 19:40:03 yes, it does, not sure if we expose it 19:40:04 http://developer.openstack.org/api-ref-objectstorage-v1.html 19:40:46 you can set metadata on account/container and object 19:42:24 alright, i'll continue to hack on it, just let me know if you think of a better name 19:42:25 anything else on that shed? 19:42:31 lol 19:42:31 will do 19:42:35 naw 19:42:43 #topic bugs 19:42:59 so I have not even looked at the bug list yet… how is it? 19:43:11 we're just waiting until the other clients release now, i'm assuming dhellmann and others from the rel team know / realize that we'll be the last ones 19:43:27 its not so bad 19:44:42 anything we need to bring up? 19:44:57 I promise to have been through it by next week 19:46:10 there are oddly a lot of new ones 19:46:12 damn 19:47:52 https://bugs.launchpad.net/python-openstackclient/+bug/1489917 19:47:54 Launchpad bug 1489917 in python-openstackclient "Pretty much all --os- auth options are broken" [Undecided,New] - Assigned to Terry Howe (thowe-g) 19:48:07 I started look at that one and got sidetracked 19:48:27 nice 19:48:35 is that in an unusual configuration? 19:49:07 I don’t think so, just regular options like —os-username —os-password don’t work 19:49:11 they are ignored 19:50:02 It think the problem is they are not mapped to auth.username and auth.password for occ 19:50:43 ten minutes….other bugs? 19:50:53 nothing here 19:51:54 we should fix that one before releasing.. 19:52:29 thats a pretty major regression no? 19:53:03 it would be if it's for real…I've not noticed anythign like that happening to me so far and I'm stil using env vars/args for about half of my config 19:53:42 i'll try and reproduce too 19:54:03 i'm done for today! 19:54:33 #topic open discussion 19:54:41 what's on our minds? 19:55:54 *wind rustles gently* 19:56:24 we should poke cinder folks in tokyo, on switching to osc 19:56:52 agreed 19:56:56 #action give stevemar a stick in Tokyo 19:57:06 i think that's the next closest CLI 19:57:16 keystone CLI is going the way of the dinosaur 19:57:19 in M 19:57:29 possibly L 19:58:42 glance would be the next logical one, there isn't too much to it? or maybe i'm wrong 19:59:11 though, they've started to work on v3 of their API now 19:59:13 yeesh 19:59:22 Image is going to be interesting…see nik's recent (minutes ago) post to the ML on glanceclient and back-compat 19:59:53 dunno yet if that should concern us or if it;s just cli 20:00:02 in any case, bring on the SDK! 20:00:19 let's get out of the business of being beholden to arbitrary decisions 20:00:32 and with that my soap box is whisked away 20:00:35 thanks guys! 20:00:39 #endmeeting