19:03:17 <dtroyer_zz> #startmeeting openstackclient
19:03:18 <openstack> Meeting started Thu Nov 12 19:03:17 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer_zz. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:22 <openstack> The meeting name has been set to 'openstackclient'
19:04:17 <dtroyer_zz> courtesy ping: dhellmann, briancurtin, lhcheng, sigmavirus24, dstanek
19:04:50 <lhcheng> o/
19:04:51 <dtroyer_zz> No prepared agenda today, basically summit thoughts, reviews, etc
19:05:16 <dtroyer_zz> #topic summit followup
19:05:52 <dtroyer_zz> the main session
19:05:55 <dtroyer_zz> #link https://etherpad.openstack.org/p/tokyo-osc-session
19:06:08 <dtroyer_zz> didn't have much for notes added to the etherpad
19:07:08 <stevemar_> reading it now
19:07:50 <dtroyer_zz> and in the meetup we talked a bit about cleaning up deleted tenants, not sure how much of that is an OSc issue
19:07:59 <dtroyer_zz> #link https://etherpad.openstack.org/p/tokyo-osc-meetup
19:08:31 <dtroyer_zz> also a lot of talk about help and the other things a couple of people want to rewind two years to change…
19:09:34 <dtroyer_zz> anyone have anything to add re the summit?
19:09:54 <MeganR> no, I don't
19:09:56 <dtroyer_zz> aside from coming-home-sick stories ;)
19:10:19 <MeganR> nope - just exhausted  :)
19:10:31 <stevemar_> i'll eventually tackle one of these :)
19:11:04 <dtroyer_zz> ok, moving on
19:11:13 <dtroyer_zz> #topic Current Reviews
19:11:26 <dtroyer_zz> I am just today getting caught up on the queue
19:11:33 <stevemar_> we've had a lot of good patches from tangchen lately
19:11:43 <rtheis> o/
19:11:46 <dtroyer_zz> yes, I've got a few of those left to look at
19:11:56 <stevemar_> and other folks from fujitsu
19:12:22 <stevemar_> lhcheng and i have been getting those patches through
19:12:41 <dtroyer_zz> one that I wanted to talk about was https://review.openstack.org/#/c/243393/
19:13:08 <dtroyer_zz> I don't think we want/need to add a new command for this, 'state' is a server property, or enough like one to treat it as one
19:14:04 <stevemar_> i'm down with that
19:14:19 <stevemar_> i didn't like the original suggestion "server reset state", felt icky
19:14:44 <stevemar_> i was originally thinking `server reset --state <state>`
19:14:45 <dtroyer_zz> I haven't refreshed on the server fields, there may be more than one or two called 'state'
19:15:35 <stevemar_> or `server reset <server> [--state <state>]` where state defaults to `active`
19:15:49 <stevemar_> so you could do `server reset myserv1`
19:16:22 * dtroyer_zz tries to decide if 'reset' is differernt from 'set' there
19:16:34 <dtroyer_zz> other than the default state value
19:18:02 <stevemar_> looking at the api, http://developer.openstack.org/api-ref-compute-v2.1.html#resetState they are all the same
19:18:03 <rtheis> servers have power, task and vm states...does that need to be noted?  I only think vm can be changed by user.
19:18:22 <lhcheng> so there's reset_state and reset_network in novaclient
19:18:36 <dtroyer_zz> if the other states are never exposed to the user, than maybe not?
19:19:00 <dtroyer_zz> but it might be safer to not assume only one 'state' option
19:19:00 <stevemar_> dtroyer_zz: those are all actions, like lock/pause/resume
19:19:24 <stevemar_> i think reset should be it's own highlevel action
19:19:46 <dtroyer_zz> what is the text to define what it does?
19:20:02 <stevemar_> i dont follow
19:20:15 <dtroyer_zz> we define what each action does in a generic way in the docs
19:20:18 <lhcheng> something like: 'server reset --state', 'server reset --network' ?
19:20:26 <dtroyer_zz> what can a user expect to happen with a reset command?
19:20:43 <dtroyer_zz> here it is changing a state, which doesn't seem different from set to me
19:21:35 <stevemar_> well `set` should just be for server properties, like name/description
19:21:43 <stevemar_> metadata
19:22:18 <dtroyer_zz> so reset really becomes more like the API 'action' call
19:22:22 <dtroyer_zz> which needs to die
19:22:49 <dtroyer_zz> I'm not quite convinced but heading that direction
19:23:11 <dtroyer_zz> I don't want server reset to be drastically different from foobar reset down the road
19:23:16 <stevemar_> i'm okay with either tbh
19:24:31 <dtroyer_zz> if we can think of reset as the lever for pushing a resource around, maybe
19:25:07 <dtroyer_zz> there teally isn't an opposite action for that, right?
19:25:12 <stevemar_> nope
19:25:15 <dtroyer_zz> in this case, it's just a different state
19:25:29 <dtroyer_zz> and maybe that's another criteria for set/unset vs reset
19:25:42 <dtroyer_zz> ok, I'm getting closer ;)
19:26:06 <dtroyer_zz> I'll update my comment in the review after letting this bake a little longer
19:26:12 <stevemar_> my counter to that is that `set` is usually modifying bits you established with `create`
19:26:49 <stevemar_> can you define state in create/?
19:27:12 <dtroyer_zz> maybe for some resources?  enabled/disables is one example
19:27:41 <dtroyer_zz> forget that those are just a db entry, conceptually it is a state change to the user
19:27:52 <stevemar_> true
19:28:08 <stevemar_> alright, update the patch with comments i guess
19:28:24 <stevemar_> you already did!
19:28:38 <dtroyer_zz> before this discussion though ;)
19:28:57 <stevemar_> any other patches?
19:29:05 <dtroyer_zz> I left a question in https://review.openstack.org/243037
19:29:16 <dtroyer_zz> wondering if that s a usage change?
19:29:25 <dtroyer_zz> ie do we need to doc a new behaviour?
19:29:51 <dtroyer_zz> another thing I haven't thought about in a while
19:30:26 <dtroyer_zz> my guess is no, but I'd like to verify before approving
19:31:24 <stevemar_> i think now it also works with weird values that have :'s
19:31:30 <lhcheng> operators may customize openstack to add more state, for example: we added more state for project other than enabled/disabled. So I kinda lean to 'set' now, may be more generic and useful for users.
19:32:15 <stevemar_> "No volume with a name or ID of '4bdca3de-2bae-411a-b865-8f4039dd522b:::0' exists."
19:32:56 <dtroyer_zz> stevemar_: so bug fix?
19:33:04 <stevemar_> i think so
19:33:24 <stevemar_> the details are in the bug report
19:33:40 <stevemar_> i assumed it was proper, but my nova knowledge is pretty spotty
19:34:03 <dtroyer_zz> a little light though.  the block device mapping format is ill-defined, so this does seem like a good defensive move
19:34:37 <stevemar_> yeah, at the least
19:34:53 <dtroyer_zz> ok, anyone else have a review to talk about?
19:36:00 * dtroyer_zz crickets
19:36:08 <dtroyer_zz> #topic open discussion
19:36:18 <dtroyer_zz> What else is on our collective minds?
19:37:09 <stevemar_> oh i've got a few
19:37:38 <stevemar_> for dtroyer_zz, cause devstack: https://review.openstack.org/#/c/237871/ and https://review.openstack.org/#/c/237860/
19:38:24 <dtroyer_zz> cool, I had see the 'swift post' one
19:38:45 <dtroyer_zz> the exercises get little love these days, but should be cleaned up too, I do still use them ;)
19:39:36 <stevemar_> then there's jamie's cross-project patch: https://review.openstack.org/#/c/243348/
19:40:27 <dtroyer_zz> we talked about it when he posted it, I'm curious to see the reaction so far…doesn't look to hostile ;)
19:41:19 <stevemar_> dtroyer_zz: next 2
19:41:29 <stevemar_> i need you to do a quick review of https://review.openstack.org/#/c/236021/
19:41:36 <stevemar_> and i can push a new patch
19:41:47 <stevemar_> and then bully zaqar into releasing something
19:42:08 <dtroyer_zz> added to list
19:42:27 <stevemar_> the last thing i wanted to discuss was dropping py26 support
19:42:37 <stevemar_> all the oslo libs are dropping it
19:42:51 <stevemar_> i think  the clients are ext
19:43:35 <dtroyer_zz> I'd prefer to be slow to do that, as long as the jobs are still supported and there are dependencies that work we should keep it
19:44:03 <dtroyer_zz> I suspect the dependency thing isn't going to last too long though
19:44:10 <stevemar_> agreed
19:44:29 <stevemar_> selfishly, i wanted to do that so we can start testing the namespace stuff https://review.openstack.org/#/c/235747/
19:44:47 <stevemar_> currently something is not py26 friendly, sahara?
19:45:12 <stevemar_> nope, congress, i wrote it in the patch
19:45:24 <dtroyer_zz> should we let plugins drive us like that though?
19:46:01 <dtroyer_zz> that's an example of why OSC proper should be last or close-to-last to drop it
19:46:37 <stevemar_> well, mriedem just wrote "python-novaclient is preparing for a 3.0 release, we can drop py26 as part of that also."
19:46:54 <dtroyer_zz> I saw that…and wondered how much we're going to break when that hits ;)
19:47:05 <dtroyer_zz> for non-py26 reasons
19:47:12 <stevemar_> i suspect we're gonna have to drop py26 soon :(
19:47:56 <stevemar_> anyway, that's it from me
19:48:01 <MeganR> @stevemar: when you say soon, do you think before the next summit?
19:48:09 <stevemar_> please comment on the zaqar bits
19:48:31 <stevemar_> MeganR: i think so, oslo libraries are dropping support now, and novaclient too
19:48:45 <stevemar_> it's gonna be quick, i think, there was a mailing list note about this
19:48:47 <MeganR> interesting, thank you for the insight
19:49:08 <MeganR> I am behind on the mailing list communications
19:49:09 <dims> MeganR gate jobs will be gone by end of the month
19:49:28 <dtroyer_zz> oh, I didn't know that was that soon, thanks dims
19:49:31 <MeganR> @dims: thank you
19:49:53 <dims> dtroyer_zz y passing that along from infra :)
19:50:08 <stevemar_> MeganR: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079260.html
19:50:55 <stevemar_> thats all from me
19:51:00 <stevemar_> now i go pass out
19:51:15 <MeganR> stevemar: thank you, I'll read through that an pass it on to my team
19:51:23 <dtroyer_zz> thanks stevemar_, go pass out
19:51:24 <stevemar_> MeganR: np
19:51:33 <dtroyer_zz> anyone have anything else to talk about?
19:52:55 <dtroyer_zz> ok, lets end a bit early then
19:52:58 <dtroyer_zz> thanks everyone!
19:53:01 <dtroyer_zz> #endmeeting