21:04:06 <hub_cap> #startmeeting reddwarf
21:04:07 <openstack> Meeting started Tue May 21 21:04:06 2013 UTC.  The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:04:08 <cp16net|away> hai
21:04:10 <amyt> \ o
21:04:11 <openstack> The meeting name has been set to 'reddwarf'
21:04:13 <datsun180b> supposedly the bot that takes attendance only counts \o
21:04:16 <hub_cap> lol juice i like datsun180b's the best o7
21:04:17 <esp1> hola
21:04:19 <grapex> \o
21:04:20 <imsplitbit> \o
21:04:29 <datsun180b> o7 is a salute of course
21:04:32 <imsplitbit> ha a salute
21:04:34 <juice> awesome
21:04:37 <SlickNik> o/
21:04:40 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/RedDwarfMeeting
21:04:44 <imsplitbit> I don't salute you hub_cap
21:04:48 <hub_cap> #link http://eavesdrop.openstack.org/meetings/reddwarf/2013/reddwarf.2013-05-14-20.37.html
21:04:51 <hub_cap> imsplitbit: sure u do
21:04:57 <juice> feisty crowd today
21:05:09 <cp16net> 7o
21:05:11 <cp16net> heh
21:05:32 <hub_cap> #topic Action Items
21:05:33 <esmute> \o/
21:05:49 <hub_cap> SlickNik: archiving logs for jenkins
21:05:51 * esmute is yawning
21:05:51 <SlickNik> So first one's mine
21:06:09 <SlickNik> Haven't had a chance to look into that one yet.
21:06:31 <SlickNik> And probably won't for another week. :(
21:06:51 <hub_cap> k. is there someone else who u can give it to?
21:06:57 <hub_cap> cuz its super frustrating
21:07:02 <cp16net> #agreed
21:07:23 <SlickNik> Anyone want to volunteer?
21:07:33 <SlickNik> (hp folks?)
21:07:52 <juice> I would but I have enough on my plate
21:07:54 * esmute steps forward
21:08:02 <SlickNik> I'll see what I can do to get something moving on that front.
21:08:03 <hub_cap> so they would have to scp the logs back to jenkins and then archive them eh?
21:08:16 <esmute> just tell me what to do and ill be a good minion
21:08:20 <datsun180b> Why not compress first and then offload, save some bandwidth
21:08:24 <hub_cap> heh esmute nice
21:08:28 <hub_cap> datsun180b: well ya fo sure
21:09:04 <SlickNik> #action esmute work with SlickNik to figure out the archiving of the reddwarf logs for rdjenkins jobs.
21:09:10 <hub_cap> SlickNik: u have the 2nd one too but i dont exactly understand it heh
21:09:19 <SlickNik> Ah, I looked into that.
21:09:30 <hub_cap> okey sup
21:09:35 <SlickNik> And had a short conversation with mordred regarding it.
21:09:50 <SlickNik> Basically the idea is to move to a state where we don't have rdjenkins.
21:10:02 <SlickNik> And have openstack CI running our integration tests for us as well.
21:10:10 <hub_cap> cool. i think that state also involves a lot of other states
21:10:17 <hub_cap> its like a whole country
21:10:23 <SlickNik> yup. :)
21:10:31 <SlickNik> The first step is to have this patch land.
21:10:41 <SlickNik> #link https://review.openstack.org/#/c/23999/
21:10:44 <hub_cap> we need to line up what is devstack and what is redstack.. there is a lot of "stuff" in redstack
21:11:44 <hub_cap> id prefer to not have it call our stuff eventually too
21:11:53 <hub_cap> but thats a whole nutha can-O-worms
21:12:00 <SlickNik> basically mordred is putting in hooks from devstack-vm-gate that we can use to run our stuff from redstack.
21:12:10 <hub_cap> ya
21:12:31 <hub_cap> i figured thatd be the case, but thats a whole conversation id like to have eventualy about why we have all the setup outside of devstack
21:12:38 <SlickNik> My thinking was that we start of this way and then make smaller patches to get our stuff integrated.
21:12:40 <hub_cap> we do a lot of things like add users, for example
21:12:42 <hub_cap> sure def
21:12:47 <SlickNik> Yup me too.
21:12:53 <hub_cap> adding users for tests, frankly, should be in tests that need those users
21:13:01 <hub_cap> and the whole apt repo thing, that needs to go away too
21:13:05 <hub_cap> heat will help w/ that
21:13:10 <hub_cap> heat integration, that is...
21:13:23 <hub_cap> anyhoo, rabbit hole quickly falling down, #movingon
21:13:26 <SlickNik> agreed.
21:13:27 <hub_cap> grapex: your next
21:13:43 <hub_cap> did u talk to tempest guys to see if there is a resize issue?
21:13:50 <grapex> hub_cap: I cancelled this before the end of last meeting
21:13:57 <grapex> as the resize time was said to not be an issue
21:13:57 <hub_cap> Oh okey hehe
21:14:03 <hub_cap> word
21:14:10 <hub_cap> i think the issue mightve been caused by me
21:14:14 <hub_cap> i had a similar issue
21:14:21 <hub_cap> cuz i was trying to use more memory than was avail on the host
21:14:29 <hub_cap> but that was manual resizes
21:14:33 <hub_cap> so no telling if that was the same case
21:14:45 <grapex> We made that action item because there were rumors the resize time was killing rdjenkins
21:14:58 <hub_cap> ok so moving on
21:15:00 <hub_cap> ya?
21:15:02 <grapex> and then before the end of the meeting everyone agreed that wasn't really the problem
21:15:06 <grapex> that's all. :)
21:15:09 <SlickNik> yeah, sounds good.
21:15:10 <hub_cap> cool
21:15:12 <hub_cap> #topic Voting rules and regulations
21:15:28 <hub_cap> so im going ot do a poll just like the polls the openstack community uses
21:15:37 <hub_cap> the Pick Three, assign weight, voting
21:15:51 <hub_cap> #link http://www.cs.cornell.edu/w8/~andru/civs/
21:15:52 <yidclare> I like it
21:16:00 <datsun180b> i'm for it
21:16:07 <esp1> hub_cap: can we do a practice run first?
21:16:18 <SlickNik> ++
21:16:21 <hub_cap> define practice run
21:16:25 <SlickNik> to instant runoff
21:16:26 <juice> VaaS nice
21:16:34 <esp1> hub_cap: just messing with you.  lets vote.
21:16:44 <hub_cap> DORK esp1 ;)
21:16:50 <hub_cap> #link https://gist.github.com/hub-cap/5622714
21:16:59 <hub_cap> list of names so far
21:17:01 <hub_cap> #link https://gist.github.com/hub-cap/5622594
21:17:04 <hub_cap> list of addresses to send to
21:17:10 <hub_cap> only problem is
21:17:17 <datsun180b> It's done via email isn't it?
21:17:24 <hub_cap> yes datsun180b
21:17:31 <datsun180b> I feel sorry for your inbox
21:17:37 <hub_cap> vipul is not around to vote. we can wait till next friday to vote (not this friday, but th 31st)
21:17:45 <hub_cap> but if the group says no, then we will do now
21:18:06 <juice> well let's see where we get and if it's close he can break the tie
21:18:06 <imsplitbit> how critical is the name change?
21:18:07 <hub_cap> the vote results will be submitted to the openstack foundation for vetting
21:18:12 <hub_cap> juice: ok
21:18:19 <esp1> #link: http://en.wikipedia.org/wiki/Seshat
21:18:27 <imsplitbit> good idea juice
21:18:36 <hub_cap> imsplitbit: we cant move to openstack github group till we change it
21:18:52 <juice> so critical
21:18:55 <juice> let's do it
21:18:57 <imsplitbit> esp1: that name just has some um... soiling implications
21:19:13 <hub_cap> ya ps the TC guys didnt like rover ;)
21:19:15 <SlickNik> lol@imsplitbit
21:19:29 <datsun180b> it's "Say-shot" you goon
21:19:33 <esp1> imsplitbit: haha, yeah I was kinda wondering what the long term implications might be.
21:19:52 <datsun180b> Ask ceilometer how they deal with it
21:19:52 <hub_cap> datsun180b: sry man, its hard to say... imagine all the people mispronouncing it
21:19:57 <imsplitbit> datsun180b: sure, but I see it and think "SHE DID WHAT????"
21:20:10 <imsplitbit> :-)
21:20:13 <hub_cap> datsun180b: they dont, the people saying it feel dumb after they hear it correctly
21:20:16 <juice> hub_cap - you need our emails?
21:20:24 <hub_cap> juice: SlickNik is hookin me up
21:20:27 <datsun180b> note to self: deliberately pronounce every ambiguous word incorrectly
21:20:46 <juice> we can run the meeting while you guys setup the voting stuff
21:20:50 <juice> what's next?
21:20:55 <hub_cap> heh
21:21:15 <hub_cap> #topic New Meeting Time
21:21:20 <imsplitbit> oooo
21:21:22 <hub_cap> this one should also be fun
21:21:27 <imsplitbit> I thought we were gonna do 33o
21:21:31 <kagan> +1 datsun180b
21:21:31 <imsplitbit> 330
21:21:33 <imsplitbit> cst
21:21:35 <hub_cap> that doesnt help me
21:21:43 <juice> so selfish
21:21:49 <juice> :)
21:21:50 <hub_cap> i have a 4cst and a 5cst meeting for the ptls
21:22:04 <hub_cap> juice: ya reddwarf doesnt need any representation in the TC meeting ;)
21:22:05 <juice> how about early after our standup
21:22:07 <imsplitbit> sounds like they have too many ptl meetings
21:22:15 <juice> 11:00 pst/1cst
21:22:34 <imsplitbit> I vote 830 cst
21:22:37 <imsplitbit> :-)
21:22:42 <kagan> how about a different day ??
21:22:43 <robertmyers> ha
21:22:43 <hub_cap> imsplitbit: your vote doesnt count
21:22:47 <imsplitbit> lol
21:22:49 <hub_cap> OUR guys cant get in at 830 cst
21:22:56 <imsplitbit> lol
21:23:00 <hub_cap> kagan: yes plz
21:23:04 <imsplitbit> theres a couple that are in at that time
21:23:19 <juice> any day but friday and monday
21:23:22 <imsplitbit> I don't really care about the time so long as it's not past 4 cst
21:23:28 <hub_cap> so ill do this. there is a tool for picking days/times, like a voting tool
21:23:35 <datsun180b> Whatever's decided, I don't want anything on monday before noon central or anything on friday after 3 central
21:23:39 <juice> although monday might not be a bad idea
21:23:40 <hub_cap> ill organize that and send it out
21:23:45 <juice> set the stage for the week
21:24:03 <imsplitbit> juice: I'm a big fan of knocking all meetings out on mondays
21:24:10 <robertmyers> monday is a bad day, as there are usually holidays
21:24:13 <imsplitbit> lets you have the rest of your week to get real work done
21:24:19 <juice> good point
21:24:27 <yidclare> yeah - I think you might be looking at Wednesdays if you change the day
21:24:29 <kagan> how about same time on Wed?
21:24:31 <hub_cap> ya and monday/friday are when people take "extra" days off
21:24:41 <hub_cap> i vote to _not_ have it at 2/4
21:24:43 <juice> wednesday then
21:24:55 <hub_cap> its not terribly fair to the CST'ers
21:25:02 <SlickNik> hub_cap: is there an openstack specific tool?
21:25:06 <hub_cap> SlickNik: nope
21:25:10 <datsun180b> We're two hours apart, right?
21:25:14 <hub_cap> but there is a voting-esque tool
21:25:16 <juice> yep
21:25:18 <hub_cap> datsun180b: always
21:25:36 <SlickNik> http://doodle.com/ is pretty good at  helping with picking a time.
21:25:38 <kagan> no, hub_cap, not on mondays ...
21:25:40 <juice> then 11 pst/13cst it is
21:25:41 <datsun180b> What if we figure for Wednesday, 11:00/1:00
21:25:54 <juice> I'm with datsun180b
21:25:55 <juice> next
21:25:56 <robertmyers> datsun180b: +1
21:25:56 <datsun180b> so it's on either end of lunch for both sides
21:26:10 <amyt> hub_cap:  if you do wed, would that help with giving us feedback from the tc mtgs?
21:26:22 <hub_cap> kagan: i said thats when people take days off... i didnt say yes monday ;)
21:26:29 <datsun180b> right in the middle of the day in the middle of the week
21:26:33 <hub_cap> amyt: ya def
21:26:57 <kagan> i meant regarding not being 2 hours apart on Mondays ...
21:27:06 <amyt> how about earlier on wed to give people more time to "catch up" before the week ends?
21:27:11 <hub_cap> so tahts wed 22 utc?
21:27:16 <SlickNik> datsun180b: ++
21:27:32 <hub_cap> nm thats not 2200
21:27:33 <hub_cap> let me see
21:27:41 <datsun180b> and both sides are motivated to keep the meeting from clobbering lunch, and keeping lunch from clobbering the meeting
21:27:49 <juice> amyt: i don't think that would work out great
21:28:08 <amyt> juice:  yea i forgot about the lunch thing. i GUESS we have to eat
21:28:10 <juice> I think 11:00 is the most practical time from an hp perspective
21:28:10 <hub_cap> 1900
21:28:25 <hub_cap> swift is at 1900
21:28:32 <hub_cap> but thats ok
21:28:37 <amyt> is that.. 11 am ct?
21:28:37 <datsun180b> and we'll all be here at 1:00 our time
21:28:38 <juice> 1900! yowzers
21:28:55 <datsun180b> amyt: 11am Pacific, 1pm Central
21:28:57 <juice> amyt that is 13:00 cst (1 pm)
21:29:03 <notmyname> swift is 1900utc on wednesdays (every other wednesday, currently)
21:29:09 <juice> what datsun180b said
21:29:11 <amyt> gotcha, thanks guys :)
21:29:17 <SlickNik> hub_cap: with PDT, 11PDT would be 1800UTC
21:29:32 <hub_cap> ok crap pdt heh
21:29:33 <datsun180b> to be fair juice suggested it moments before i did
21:29:37 <hub_cap> so we do understand
21:29:43 <hub_cap> that when we go off dst
21:29:48 <hub_cap> our meeting changes by 1 hr
21:30:10 <hub_cap> thats during moniker
21:30:13 <robertmyers> can we just change it then?
21:30:34 <hub_cap> not if we have other teams working w/ us
21:30:40 <hub_cap> none of the other projects change
21:30:52 <hub_cap> its somewhat disruptive to people in otehr countries persay
21:31:16 <hub_cap> so it goes to 12pst/2cst
21:31:18 <SlickNik> so if we move off dst: we become 10PST / 12CST
21:31:19 <datsun180b> wuh oh, grapex might have a collision with 1pm
21:31:25 <hub_cap> doh i suck
21:31:33 <grapex> datsun180b: That's ok
21:31:38 <datsun180b> just looking out for you
21:31:53 <grapex> datsun180b: Thanks man
21:31:57 <hub_cap> sound good then?
21:31:57 <grapex> but if that time works I'm ok with it
21:32:00 <hub_cap> 1800 utc?
21:32:15 <datsun180b> what is that in Earth time
21:32:20 <hub_cap> we can always try to move it later grapex
21:32:25 <grapex> hub_cap: Speak 'Merican
21:32:41 <SlickNik> We've got daily stand up at 10 in the morning here.
21:32:42 <datsun180b> I don't want to have to coordinate this time with the whole universe
21:32:53 <grapex> hub_cap: 2:00 Wednesday would be the best. But it would cut into lunch I imagine
21:32:57 <grapex> 1:00 is fine if that works.
21:33:04 <hub_cap> grapex: but it wont always be that
21:33:14 <hub_cap> itll go from 2pm to 1pm because of dst
21:33:43 <grapex> hub_cap: Argh
21:33:45 <juice> maybe we can take this offline
21:33:45 <cp16net> we change with dst
21:33:54 <hub_cap> juice: prolly a good idea
21:33:59 <SlickNik> yeah, I think we need to take this offline.
21:34:05 <juice> someone work out the kinks and get back to us with a couple of options
21:34:07 <grapex> hub_cap: Ok, that changes things. :(
21:34:14 <datsun180b> well that won't be for months, which i think should be enough time to reevaluate the meeting time
21:34:17 <hub_cap> lets get together during the meeting time weve designated tomorrow
21:34:19 <kagan> how about we do our standup at 11 that day ?
21:34:20 <hub_cap> and discuss
21:34:20 <hub_cap> :)
21:34:29 <juice> damn the pseudoephedrine is kicking in
21:34:38 <SlickNik> lol@hub_cap
21:34:55 <hub_cap> moving on
21:35:06 <SlickNik> hang in there, juice
21:35:10 <hub_cap> #topic Backups
21:35:18 <SlickNik> done!
21:35:22 <hub_cap> nice
21:35:23 <hub_cap> moving on
21:35:25 * juice cheers
21:35:29 <kagan> cheers!
21:35:36 <hub_cap> SlickNik: are they merged?
21:35:40 <esmute> halleluya
21:35:43 <juice> you did it wrong kagan ;)
21:35:53 * hub_cap laughs at juice
21:35:57 <kagan> meaning second ?
21:36:03 <hub_cap> /me cheers
21:36:03 <SlickNik> yes, they are. Thanks for all the good work everyone!
21:36:07 <hub_cap> sweet perfect
21:36:11 <hub_cap> #topic Notifications
21:36:22 <SlickNik> That's merged too.
21:36:30 * robertmyers cheers
21:36:33 <hub_cap> well we still need the hourly right?
21:36:37 <hub_cap> exists
21:36:42 <hub_cap> err *daily*
21:36:42 <juice> well not completely done on my end
21:36:46 <SlickNik> Juice was working on that one
21:36:50 <hub_cap> right
21:36:52 <SlickNik> juice even*
21:36:56 <juice> there's a bunch of crap they want but we are pushing back on it
21:37:16 <juice> they want some stuff out of nova that I just don't think we can do now
21:37:33 <juice> other than that I think it's oke
21:37:50 <robertmyers> seems kind of silly to duplicate all of nova exist events
21:38:02 <robertmyers> since they can just use them
21:38:03 <juice> robertmyers: agree
21:38:10 <SlickNik> robertmyers: ++
21:38:22 <juice> they should be aggregating this stuff on instance id's et
21:38:26 <juice> tc
21:38:34 <hub_cap> well exists nova != exists reddwarf tho right?
21:38:40 <hub_cap> what if mysql has been offline for 24hrs
21:38:47 <SlickNik> hub_cap: that is true.
21:38:53 <juice> true but they have the details if the instance is up
21:38:53 <hub_cap> but compute has been hummin that entire time
21:39:12 <hub_cap> sure the nova compute instance is up
21:39:19 <SlickNik> + there are periods of time where instance is up and not usable.
21:39:20 <hub_cap> but to me that doenst mean jack
21:39:42 <SlickNik> not usable = mysql is not up for whatever reason.
21:39:46 <hub_cap> right
21:39:49 <juice> what I was saying is that the can create a composite set of info IF we tell them mysql is also up.  We don't need to repeat the base nova info
21:39:54 <hub_cap> and does that "exist" if mysql is not up?
21:40:11 <juice> we don't send exists if mysql is down
21:40:17 <juice> we only send exists if mysql is up :)
21:40:40 <hub_cap> ok i guess im a bit confused... yall can work it out
21:40:46 <hub_cap> :P
21:41:00 <hub_cap> i thought u said we werent gonna send exists cuz nova does already but that sounds like its not the case
21:41:43 <juice> no there was just some extra info that nova has that we don't
21:41:48 <hub_cap> AHH ic
21:41:49 <hub_cap> cool
21:41:52 <juice> so my argument was why do we also have to send it
21:41:56 <SlickNik> hub_cap: we need exist events because of nova != reddwarf. But we don't want to send duplicate nova info in our events.
21:41:59 <robertmyers> maybe we just need a hook to optionally run exist evetns
21:42:13 <SlickNik> robertmyers: that is the plan.
21:42:14 <juice> it will be a conf flag so you can turn it off
21:42:30 <juice> we are using it so that if multiple ™ are running only one sends it
21:42:38 <juice> ™ = taskmanager
21:43:04 <hub_cap> ic what u all mean now. perfect
21:43:30 <juice> okie
21:43:38 <juice> good that's all cleared
21:43:48 * juice sips his coffee
21:43:51 <hub_cap> juice: yup great
21:43:56 <hub_cap> moving on
21:44:05 <hub_cap> what is API Validation?
21:44:10 <hub_cap> do we need to cover it?
21:44:11 <juice> that one is me
21:44:14 <hub_cap> ok
21:44:19 <datsun180b> I bet it's about the username/database name evaluation
21:44:20 <hub_cap> #topic API Validation
21:44:24 <juice> I do need to ask you guys a few qestionss
21:44:32 <hub_cap> shoot
21:44:51 <SlickNik> go for it
21:44:55 <juice> so our sec folks say we need to clamp down on the data coming it at all levels but are ok with focusing on api for now
21:45:16 <juice> so I was looking at schemes for validating field length, type, etc
21:45:30 <datsun180b> relevant to https://review.openstack.org/#/c/28850/ or a more general approach?
21:45:39 <juice> I found the validator in nova that seems like it would do that trick and we can just plug it into paste
21:45:53 <grapex> juice: Is this the idea of validating everything according to a JSON or XML schema?
21:46:09 <cp16net> good luck validating json  to a schema
21:46:16 <juice> datsun180b - they want us to do it across all requests on on fields
21:46:20 <hub_cap> juice: we shodul adopt http://json-schema.org/example2.html
21:46:27 <SlickNik> datsun180b: I think a more general approach across the API - not just database name
21:46:36 <juice> grapex: i was thinking that but have since let that go
21:46:46 <datsun180b> Probably a good idea to attack it broadly instead of piecemeal
21:46:49 <grapex> How's the Nova validator work?
21:46:54 <grapex> juice: ^^
21:47:20 <juice> grapex: they have a validator class that you specify the rules.  then they run the request from the context through that
21:47:29 <juice> so you are specifying the schema in python
21:47:42 <hub_cap> json schema!
21:47:43 <juice> this is consistent with another approach I found which is called schematics
21:47:50 <juice> no not json
21:47:54 <grapex> juice: Is this schema some custom thing they made up?
21:48:01 <grapex> Does the same schema work for JSON and XML?
21:48:04 <hub_cap> #link http://json-schema.org/
21:48:05 <juice> I believe so
21:48:19 <juice> it is agnostic since the response has been parsed by that point
21:48:19 <cp16net> its using that special xml definition
21:48:35 <juice> so I think it something like a dict or kwargs or something
21:48:48 <juice> let me send you a link to the class
21:48:54 <grapex> Here's another thing to consider... it's selfish, but we use Repose. I feel like if used generic things like JSON and XML schemas, we could use that with Repose. People creating client libraries could also reuse them.
21:49:10 <SlickNik> Yes, juice a link would be helpful. thanks!
21:49:17 <hub_cap> we cant say that grapex :(
21:49:22 <hub_cap> repose is _not_ openstack compatible
21:49:38 <grapex> hub_cap: Yes, but json and xml schemas are open source compatable. ;)
21:49:48 <hub_cap> for sure
21:50:17 <hub_cap> ok so do we have any resolution on this?
21:50:28 <juice> #link https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py
21:50:38 <grapex> I mean I'll give this thing in Nova a fair shake, but if its 100% custom its worth thinking about if it's a worthwhile approach. If the idea is to validate all input and output I'm sure there's existing tools and libs out there in Python, not Repose, that would also work on typical schemas.
21:51:02 <juice> grapex: we just need input validation
21:51:33 <juice> grapex: feel free to take a look at the python space for libs.  the best I found was schematics
21:51:40 <hub_cap> there is not much
21:51:41 <grapex> juice: Ok.
21:51:44 <cp16net> lol
21:51:48 <hub_cap> validation is not terribly pythonic it seems ;)
21:51:54 <juice> #link https://github.com/j2labs/schematics
21:51:56 <esmute> not to hijack this topic but i think https://review.openstack.org/#/c/28850/ is related to this
21:51:58 <grapex> hub_cap: *sigh*
21:51:58 <cp16net> yeah its not so much
21:52:02 <hub_cap> #link https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L205
21:53:06 <hub_cap> by the time it reaches us we can validate w/ json schema id guess
21:53:06 <esmute> we can talk about this later in another topic or right now
21:53:13 <hub_cap> good call esmute
21:53:24 <hub_cap> moving on
21:53:42 <hub_cap> #topic open discussion
21:53:43 <juice> thanks please get back to me in the reddwarf if you want any input on this
21:53:51 <hub_cap> juice: ya lets chat after
21:54:29 <grapex> hub_cap: The glance thing looks pretty good, seems to support a standard, though its just JSON
21:54:50 <grapex> Something to note, we transform XML stuff into dictionaries
21:55:03 <esmute> i want to talk about ephemeral drive
21:55:03 <grapex> which means we could probably run it through the JSON schema at that point
21:55:10 <hub_cap> grapex: sure but by the tiem its gets to us its dict's
21:55:11 <hub_cap> exactly
21:55:28 <imsplitbit> I can't wait for the day when we say "we support xml" and the world snickers and says "who still does that anymore???"
21:55:31 <hub_cap> it just means we could have a delta between what our xml "says" and "does"
21:55:40 <hub_cap> esmute: chat away
21:56:26 <hub_cap> grapex: https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L482
21:56:35 <esmute> hub_cap: I have incorporated your suggestion, which is using the same exisiting flags to determining ephemeral support
21:56:35 * SlickNik can hear  esmute typing away
21:56:38 <juice> whens the vote?
21:56:51 <imsplitbit> yeah I'm waiting for my vote email
21:56:54 <SlickNik> juice: what vote?
21:56:58 <esmute> a pull requests is already up for review.. Im expecting robots to like it
21:56:58 <esmute> https://review.openstack.org/#/c/28857/
21:57:08 <juice> umm name vote?
21:57:09 <grapex> hub_cap: The glance stuff looks pretty cool.
21:57:09 <esmute> hub_cap, please review when you can
21:57:10 <hub_cap> brb its my turn in opesntack-meeting
21:57:18 <cp16net> imsplitbit: at least xml you can "validate"
21:58:02 <robertmyers> I vote for 'thrift' just to piss everyone off
21:58:03 <imsplitbit> there are different philosophies on *where* one should do validation
21:58:05 <juice> should we stick a fork in this meeting?
21:58:18 <juice> oh still talking balidation great
21:58:24 <SlickNik> There was one quick thing I wanted to bring up.
21:58:25 <cp16net> its so juicey in here tho
21:58:30 <cp16net> :-P
21:58:30 <esmute> we need to decide on https://review.openstack.org/#/c/28850/
21:58:44 <SlickNik> During the backup reviews, there was some confusion about line continuations.
21:58:49 <juice> my concern over validating on the payload is that we have to put schema into two different formats
21:58:56 <grapex> esmute: Looks like datsun180b had some comments on it.
21:59:10 <juice> so I though waiting for it to be parsed into something neutral will create a single checkpoint
21:59:17 <SlickNik> and whether to use "\" or implicit continuation using parentheses.
21:59:29 <esmute> grapex: just wanted to clarify.. So no validation on the DB name?
21:59:30 <datsun180b> I did. The API still uses the guest agent's models to do some output validation, and those will kill responses that contain goofy but extant databases
21:59:33 <grapex> juice: That's fair. I think the json_schema code in Glance can be used from XML as well, since the XML code turns stuff into tables
21:59:43 <grapex> esmute: What datsun180b just said.
21:59:46 <SlickNik> Yeah, so the PEP8 spec favors implicit continuations using parens.
21:59:54 <SlickNik> And it does seem a little cleaner.
21:59:55 <datsun180b> SlickNik: it does so very clearly
22:00:04 <grapex> SlickNik: So here's what I think about "\"... I don't know why the language includes if it shouldn't be used.
22:00:23 <grapex> datsun180b and I have disagreed on this in the past... :) I'll go either way though as I don't care too much
22:00:26 <esmute> datsun180b: I can remove that validatation from the guest agent. But not sure what you meant by removing it from the API
22:00:30 <grapex> I just don't think it's worth holding up pull requests over.
22:00:40 <datsun180b> Now remember that while PEP8 is prescriptive, it does also say never to sacrifice readability for the sake of blindly following the rules
22:00:50 <datsun180b> that's rule 0
22:01:06 <datsun180b> esmute: side convo
22:01:10 <robertmyers> datsun180b: I'm with you
22:01:11 <SlickNik> grapex: PEP 8 allows for "\", just prefers the implicit line continuations using parens.
22:01:13 <hub_cap> woo gave the first offical project status for the project status meeeting :)
22:01:17 <grapex> esmute: The problem is, on the way back from a read operation, validation occurs and crashes the call right? So we're just saying to remove it from the Reddwarf server side as well.
22:01:18 <juice> grapex: I haven't looked at the glance validation. so that is something good for me to examine
22:01:22 <SlickNik> hub_cap: nice!
22:01:40 <hub_cap> the json schema stuff is the bomb
22:01:49 <juice> hub_cap: was there any hazing involved?
22:01:50 <SlickNik> grapex ++
22:01:56 <hub_cap> it even gives generated json schema files, which we can integrate after the fact
22:02:03 <hub_cap> juice: nope! just had to do it fast
22:02:10 <hub_cap> cuz it was at the VERY end
22:02:23 <hub_cap> jsonschema FTW PLZ juice grapex
22:02:34 <juice> cereals?
22:02:40 <hub_cap> give it serious consideration. its free validation
22:02:45 <juice> ok
22:02:58 <hub_cap> and free schema generation (ie no more wadl)
22:03:08 <datsun180b> in general you're also free to happily ignore my style nitpicks fyi
22:03:19 <datsun180b> i won't hold up code that's clear and correct
22:03:45 <SlickNik> datsun180b: I was actually glad you mentioned it, since I learned something new.
22:04:04 <SlickNik> but just wanted to bring it up so that we're not holding up reviews because of it.
22:04:13 <juice> hub_cap: will take a look at jsonschema.  I don't have a strong opinion on this.  you all have been simmering in this stuff for much longer so if you feel strongly about jsonschema then we can roll with that
22:04:29 <datsun180b> right, i understand some IDEs like to make some silly decisions when making the code compliant with pep8 (and not PEP8)
22:04:48 <SlickNik> So please feel free to leave style comments if you'd like but don't let those turn your +1's into −1's.
22:04:49 <datsun180b> personally I don't like pep8 because it's mechanical and has no sense of style
22:04:53 <juice> of course as I dig in and try to implement it and it turns out troublesome I'll let you know
22:04:58 <datsun180b> will do moving forward
22:05:02 <juice> datsun180b ++++!
22:05:05 <juice> ++++1
22:05:30 <datsun180b> pep8 can be gamed. i'm harder to compromise
22:05:44 <juice> ha :)
22:05:47 <hub_cap> juice: i do ;)
22:05:49 <grapex> datsun180b: Every man has his price Ed. Even you!!
22:05:57 <hub_cap> ok we are 5min over
22:06:11 <datsun180b> protip: gummy worms
22:06:12 <hub_cap> can i call it
22:06:15 <imsplitbit> okie
22:06:17 <imsplitbit> done
22:06:18 <datsun180b> call it, doc
22:06:18 <hub_cap> and move to #reddwarf
22:06:21 <hub_cap> #endmeeting