16:04:27 <kgriffs> #startmeeting marconi
16:04:28 <openstack> Meeting started Mon Sep 30 16:04:27 2013 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:32 <openstack> The meeting name has been set to 'marconi'
16:04:44 <kgriffs> #link https://wiki.openstack.org/wiki/Meetings/Marconi#Agenda
16:04:53 <kgriffs> #topic Review actions from last time
16:05:05 <kgriffs> #link http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-09-23-16.19.html
16:05:17 <kgriffs> Looks like the only action noted was to get the proxy patches reviewed
16:05:31 <kgriffs> I think we made good progress there, nicht?
16:05:50 <kgriffs> I haven't had a chance yet to weigh in on the latest round
16:05:58 <kgriffs> but am planning on doing that ASAP today
16:06:10 <megan_w> sounds good
16:06:16 <kgriffs> questions, comments, rude remarks?
16:06:18 <alcabrera> kgriffs: yup - most of the proxy patches were reviewed. In fact, WRT to the state of the proxy last week, I think you reviewed all patches that existed as of last meeting
16:06:19 <malini> cool! I am waiting on those reviews to start testing :)
16:06:29 <malini> tht was not a rude remark *
16:06:35 <kgriffs> :p
16:06:49 <kgriffs> ok, moving on
16:06:53 <kgriffs> #topic bugz
16:07:03 <kgriffs> #link http://goo.gl/uKe5gp
16:07:10 <kgriffs> starting at the top
16:07:21 <kgriffs> I have a patch pending for that one
16:08:08 <alcabrera> kgriffs: it needs a little bit of consensus before moving forward.
16:08:15 <zyuan> i'm not sure how this can happen
16:08:17 <kgriffs> just got a couple minor comments to address and then it should go in and be ready for testing
16:08:35 <kgriffs> alcabrera: re ASCII or whatever, you can't have unicode in URLs
16:08:40 <kgriffs> per RFC
16:08:41 <kgriffs> iirc
16:08:50 <kgriffs> anyone have evidence to the contrary?
16:09:05 <zyuan> kgriffs: i think you can
16:09:31 <kgriffs> it is supposed to be %-encoded. I will check it out again.
16:09:36 <alcabrera> #link http://stackoverflow.com/questions/2742852/unicode-characters-in-urls
16:09:50 <alcabrera> That SO exchange has some good pointers.
16:10:13 <kgriffs> yeah, looks familiar
16:10:21 <alcabrera> kgriffs: %-encoding seems right, based on what I just read.
16:10:31 <zyuan> what is the charset of URI?
16:11:00 <zyuan> unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
16:11:19 <alcabrera> zyuan: "...UTF-8-encode them then percent-encode the non-ASCII bytes..."
16:11:51 <alcabrera> zyuan: Though that's not standards text, just a comment on the internet. :P
16:12:00 <zyuan> don't use the term ASCII
16:12:27 <zyuan> there is EBCDIC
16:12:51 <kgriffs> "Percent-encoded
16:12:51 <kgriffs> octets (Section 2.1) may be used within a URI to represent characters
16:12:51 <kgriffs> outside the range of the US-ASCII coded character set if this
16:12:54 <kgriffs> Berners-Lee, et al.         Standards Track                     [Page 8]
16:12:54 <zyuan> URI does not define encoding, it defines charset (reserved + unreserved); encoding is platform-defined.
16:12:57 <kgriffs> RFC 3986                   URI Generic Syntax               January 2005
16:13:00 <kgriffs> representation is allowed by the scheme or by the protocol element in
16:13:01 <kgriffs> which the URI is referenced.
16:13:02 <kgriffs> "
16:13:03 <kgriffs> https://www.ietf.org/rfc/rfc3986.txt
16:13:20 <alcabrera> kgriffs: thanks. I posit that we move the rest of this discussion for breakout.
16:13:33 <kgriffs> TL;DR I will need to see what WSGI servers do with percent-encoded chars. We may indeed want to support them if WSGI servers translate them to unicode
16:14:04 <kgriffs> #info Discuss unicode queue names in a breakout
16:14:14 <kgriffs> moving down the list of bugs...
16:14:35 <kgriffs> "https://bugs.launchpad.net/marconi/+bug/1214973"
16:14:49 <flaper87> o/
16:14:56 <kgriffs> flaper87: hi!
16:15:01 <alcabrera> flaper87: wooooo, you made it!
16:15:02 <kgriffs> glad you made it!
16:15:05 * alcabrera cheers
16:15:14 <flaper87> Fuck YEAHHH!!!
16:15:23 <flaper87> stupid vpn
16:15:25 <flaper87> aaanyway
16:15:26 <kgriffs> #info kgriffs started working on "Autoreconnect not handled in all cases"
16:15:36 <alcabrera> kgriffs: awesome
16:16:02 <kgriffs> I will have a patch ready for that soon. It is tricksy, so we will need to closely vet this one
16:16:08 <flaper87> kgriffs: +1
16:16:12 <flaper87> glad to hear that
16:16:21 <kgriffs> moving down the list
16:16:37 <kgriffs> Any other bugs people would like to comment on?
16:16:49 <flaper87> yeah
16:16:53 <flaper87> the config one
16:16:56 <flaper87> or is that a bp ?
16:16:59 <flaper87> mmhh
16:17:04 <flaper87> don't remember exaclty
16:17:09 <kgriffs> bug list: http://goo.gl/uKe5gp
16:17:10 <alcabrera> This one?
16:17:13 <alcabrera> #link https://bugs.launchpad.net/marconi/+bug/1229848
16:17:24 <alcabrera> Global configs
16:17:38 <alcabrera> flaper87: ^
16:17:59 <flaper87> alcabrera: yeah
16:18:06 <flaper87> that and deprecate common.config
16:18:14 <flaper87> but the deprecation one is a bp
16:18:16 <flaper87> IIRC
16:18:54 <flaper87> anyway, I think both are important
16:19:18 <alcabrera> flaper87: I don't see a bug report or a BP addressing common.config
16:19:20 <flaper87> meaning, they may not have the highest priority right now but, if we don't takle them now we won't be able to do it later
16:19:46 <flaper87> because things will keep getting bigger and bigger
16:19:59 <flaper87> and more code will use that "method" and "module" for doing things
16:20:07 <flaper87> alcabrera: mmh, I thought I opened oen
16:20:14 <flaper87> I might have done that in my brain
16:20:45 <alcabrera> flaper87: Could you double check later and document that somehow?
16:20:58 <alcabrera> kgriffs: Thoughts about moving away from common.config?
16:21:08 <flaper87> yeah, just did, no bug
16:21:12 <flaper87> I'll file a new one
16:21:36 <kgriffs> i think it's fine, but I would like us to identify any nice features it provides and commit to contributing them upstream
16:21:56 <alcabrera> That sounds good to me.
16:22:04 <flaper87> the reason I'm bringing both is because if we move away form common.config we should take that chance to remove the global instance
16:22:15 <alcabrera> flaper87: +1
16:22:15 <flaper87> kgriffs: +1
16:22:22 <flaper87> kk, I'll those 2 issues
16:22:34 <flaper87> I mean, that issue and the one I'll open in 3, 2, 1....
16:22:41 <alcabrera> cool, cool
16:23:02 <flaper87> that's all from me
16:23:16 <alcabrera> Regarding bugs, I'm tackling proxy-related bugs atm.
16:23:33 <flaper87> alcabrera: that sounds great, you've been doing an amazing job there
16:23:54 <flaper87> IMHO, you should make sure to tackle them all before moving to soemthing else
16:23:58 <alcabrera> The hottest item on my list is the notion of updating partition data, and I'd love comments on that in the related patch. :)
16:24:01 <alcabrera> #link https://review.openstack.org/#/c/48737/
16:24:09 <flaper87> current bugs are important and related to the proxy design
16:24:19 <alcabrera> flaper87: no worries, there. The proxy is my main concern for awhile yet. :D
16:24:32 <flaper87> awesome
16:24:35 <flaper87> thanks, d0000d
16:24:42 <kgriffs> ok, anything else on the topic of bugs?
16:24:48 <alcabrera> kgriffs: none from me
16:24:52 <malini> none from me
16:24:59 <kgriffs> #topic incubation bps/bugs
16:25:26 <kgriffs> flaper87: seems like you created bps for all the things we need to do in order to graduate?
16:25:45 <kgriffs> https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
16:25:54 <alcabrera> #link https://wiki.openstack.org/wiki/Marconi/Incubation/Graduation
16:26:11 <flaper87> kgriffs: that's correct
16:26:13 <kgriffs> flaper87: would you mind linking from that tracking wiki to all those?
16:26:26 <flaper87> kgriffs: that's a good idea, will do that!
16:26:39 <kgriffs> cool
16:26:42 <megan_w> are any of these in progress?
16:26:46 <flaper87> megan_w: yup
16:26:51 <alcabrera> client library, for sure
16:26:57 <kgriffs> I would like to spend a few minutes each week discussing our progress on those
16:27:05 <megan_w> +1
16:27:08 <alcabrera> kgriffs: +1
16:27:28 <kgriffs> #action kgriffs to add graduation progress to weekly agenda
16:27:33 <kgriffs> ok cool
16:27:34 <flaper87> kgriffs: +1
16:27:51 <kgriffs> If we come up with any other ToDos pls add them to the wiki and link the appropriate launchpad item
16:28:22 <kgriffs> #topic Review the rough draft of the proxy's admin API
16:28:34 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/specs/proxy/v1
16:29:07 <kgriffs> alcabrera: can you walk us through the spec?
16:29:12 <alcabrera> Sure, thing, kgriffs
16:29:25 * flaper87 sits, open his eyes and reads carefully
16:29:41 <alcabrera> The proxy itself is responsible for forwarding requests to registered marconi partitions.
16:29:57 <alcabrera> There's two components to it: 1) partition management, 2) implicit catalogue handling
16:30:06 <alcabrera> I'll speak on partitions first, then the catalogue.
16:30:12 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/specs/api/v1
16:30:23 <kgriffs> let us know which doc to reference. :p
16:30:36 <alcabrera> kgriffs: Thanks for linking!
16:30:51 <alcabrera> To register a partition, an admin must send a PUT command to a marconi proxy admin instance.
16:31:09 <alcabrera> That PUT needs to give the partition a name, a list of hosts, and a weight
16:31:31 <alcabrera> Those are all used by the marconi-proxy when making decisions about where to allocate queues and where to forward requests
16:31:53 <alcabrera> An admin can also list all partitions and GET a particular one to review details.
16:32:17 <alcabrera> There's planned support for updating a partitions hosts/weight, and that's in the works.
16:32:29 <alcabrera> The other side is...
16:32:32 <alcabrera> The Catalogue
16:32:35 <alcabrera> ====
16:32:51 <alcabrera> That's where the mapping from a project + queue to a partition lives.
16:33:09 <alcabrera> It's handled implicity by the proxy when a client creates/deletes queues.
16:33:23 <alcabrera> So, from an API perspective, the catalogue is immutable (GET only).
16:33:44 <alcabrera> An admin can review what lives in the catalogue to understand the flow of the system.
16:33:59 <alcabrera> That's the proxy API in a nutshell
16:34:01 <alcabrera> Comments?
16:34:21 <kgriffs> so, I am assuming the API will be augmented at some point to support migration?
16:34:40 <flaper87> the admin API, i guess
16:34:54 <alcabrera> kgriffs: yes - there needs to be some way to move data from one partition to another.
16:35:08 <alcabrera> as well as mark certain project + queues as "frozen"
16:35:12 <kgriffs> ok
16:35:46 <kgriffs> what happens if I PUT a queue that is already there?
16:35:49 <malini> alcabrera: can the same queue span across multiple partitions?
16:35:57 <kgriffs> sorry, not queue
16:35:59 <flaper87> malini: HEEEELLLOOOOOOO!!!!!!
16:36:01 <kgriffs> i meant partition
16:36:01 <flaper87> :)
16:36:17 <malini> kgriffs: you stole my next question :)
16:36:21 <zyuan> it'd better not
16:36:23 <alcabrera> kgriffs: it short-circuits and returns 204
16:36:28 <malini> flaper87: hello!!!
16:36:35 <alcabrera> kgriffs: the contents are not replaced
16:36:38 <kgriffs> seems like you should return an error status
16:36:42 <kgriffs> and use PATCH for updating
16:36:43 <alcabrera> malini: no
16:36:49 <alcabrera> kgriffs: +1
16:36:55 <malini> kgriffs:  +1
16:37:07 <alcabrera> kgriffs: I'd received many comments in that direction when I proposed an updating API for the admin interface.
16:37:10 <flaper87> alcabrera: did you see my comments in the hosts weight patch ?
16:37:13 <alcabrera> kgriffs: PATCH, that is
16:37:16 <kgriffs> kk
16:37:27 <flaper87> cool
16:37:31 <alcabrera> flaper87: I'm pretty sure I did, as well as malini's. :)
16:38:02 <flaper87> awesome (I commented using my ipad so, not sure what I actually did)
16:38:05 <kgriffs> alcabrera: you don't have to support JSON-patch but using a different verb would be more explicit. We had a similar discussion for the queues resource
16:38:16 <kgriffs> s/queues/queue
16:38:28 <alcabrera> kgriffs: I'll reference the PATCH claims implementation when building this out.
16:38:33 <kgriffs> kk
16:39:24 <kgriffs> so, how about ditching HTTP and only supporting zmq for the admin interface?
16:39:27 * kgriffs runs away
16:39:31 <alcabrera> lol
16:39:34 <zyuan> ...
16:39:38 <kgriffs> jk
16:39:45 <flaper87> LOOOOOOOL
16:39:57 <kgriffs> actually, I was hoping for nanomsg. srlsy
16:40:06 <kgriffs> :p
16:40:17 <flaper87> hahaha
16:40:18 <malini> alcabrera: Is the catalogue stored in memory ?
16:40:19 <alcabrera> kgriffs: let's figure out marconi-queues:zmq/nanomsg first. :P
16:40:20 <kgriffs> so, I imagine this interface being accessed mostly via a CLI tool?
16:40:41 <flaper87> I think so
16:40:44 <zyuan> does curl count as a CLI tool?
16:40:51 <kgriffs> maybe also config management
16:40:55 <flaper87> I think this should be part of marconiclient as well
16:40:57 <alcabrera> malini: no - it is stored in a combination of primary storage (mongodb atm) + cached in a local cache layer (memcached atm)
16:41:00 <kgriffs> zyuan: heh
16:41:02 <flaper87> I guess
16:41:06 <zyuan> no, it can't be in marconiclient
16:41:19 <alcabrera> malini: it's a hierarchical caching scheme
16:41:20 <zyuan> admin only
16:41:34 <flaper87> yup, it depends on who's using it
16:41:43 <malini> alcabrera: thanks !!
16:41:52 <kgriffs> alcabrera: delete a partition
16:42:07 <kgriffs> when would someone want to do that?
16:42:29 <alcabrera> Hmmm...
16:42:35 <megan_w> bursting for scale?
16:42:40 <megan_w> and then trimming back down
16:43:04 <alcabrera> megan_w: I like that line of thought.
16:43:09 <kgriffs> ok
16:43:28 <kgriffs> then, seems like queues need to be migrated off as part of the delete
16:43:35 <kgriffs> ?
16:43:44 <zyuan> not very sure
16:44:02 <zyuan> if a partition has no queue left
16:44:05 <alcabrera> kgriffs: yup, given that the deployer wants to support strict persistence requirements
16:44:07 <zyuan> you can just delete it...
16:44:07 <kgriffs> seems like more of a "stand down" partition than "nuke it and everything on there"
16:44:39 <alcabrera> so migration sounds a lot like a next major feature for the -proxy layer.
16:44:40 <kgriffs> ok, can you make a note about this - we should revisit when we start working on migration
16:45:00 <flaper87> +1 for revisiting this later
16:45:10 <alcabrera> #info Deleting a partition should migrate queues associated with it to another partition (needs exploration)
16:45:19 <kgriffs> deleting a partition is tricksy
16:45:32 <kgriffs> you also have to handle the fact now that weights have changed
16:45:46 <alcabrera> kgriffs: that's already handled - the weights. :D
16:45:56 <alcabrera> The choice of weighting algorithm made that part pretty easy, I think.
16:46:05 <kgriffs> i guess since we have static catalog mapping, existing queues will continue to go the right place
16:46:10 <kgriffs> ok
16:46:32 <kgriffs> one last comment, then we will move on. I imagine we will keep reviewing the API over the next few mtgs
16:46:40 <kgriffs> list partitions
16:46:41 <alcabrera> agreed
16:46:45 * flaper87 nods
16:47:14 <kgriffs> any particular reason you chose an object as the outermost type in lieu of an array?
16:47:38 <kgriffs> (using JSON terminology)
16:47:50 <alcabrera> kgriffs: no rational reason. My fingers prefer objects to arrays ({} vs [])
16:48:03 <kgriffs> TBH, I would go for an array
16:48:14 <kgriffs> seems more natural when presenting a "list" of things
16:48:18 <alcabrera> kgriffs: agreed
16:48:31 <alcabrera> moving at the speed of POC leads to strange things.
16:48:44 <kgriffs> unless the client is trying to lookup a specific partition
16:48:56 <alcabrera> I'll file a bug for that.
16:48:58 <kgriffs> in which case, it would just GET the partition directly, no?
16:49:04 * flaper87 agrees with the above
16:49:09 <alcabrera> yup
16:49:10 <kgriffs> kk
16:49:17 <alcabrera> Another note - pagination
16:49:20 <kgriffs> you might change that at the same time you implement paging
16:49:34 <alcabrera> exactly!
16:49:50 <alcabrera> cool, we're in consensus on this. :)
16:50:42 <flaper87> 10mins left
16:50:49 <alcabrera> next topic - API audit?
16:51:14 <malini> tht was a quick discussion (with our history) !!
16:51:34 <flaper87> alcabrera: +1
16:51:38 <alcabrera> #link https://bugs.launchpad.net/marconi/+bug/1233277
16:51:41 <alcabrera> Bug filed.
16:52:23 <kgriffs> anything else on that topic?
16:52:24 <alcabrera> malini: we're learning to work better together. :D
16:52:55 <alcabrera> kgriffs: nothing from me
16:53:06 <kgriffs> ok, moving on
16:53:48 <zyuan> question - progress on mysql?
16:53:54 <kgriffs> #topic finalize marconi-queues API
16:54:09 <kgriffs> zyuan: one moment, we will can addess during open discussion
16:54:30 <kgriffs> So, I'd like to dedicate the entire next mtg to finalizing and freezing the API
16:54:36 <alcabrera> kgriffs: +1
16:54:41 <kgriffs> it hasn't changed for a while, so think now is a good time
16:54:41 <flaper87> kgriffs: +1
16:54:47 <flaper87> makes sense
16:54:48 <kgriffs> ok.
16:55:02 <kgriffs> so if there are any changes y'all have one more week to sneak those in. :D
16:55:27 * flaper87 prepares a 10000 LOC patch
16:55:29 <flaper87> :D
16:55:36 * kgriffs passes out on the floor
16:55:50 * kgriffs recovers
16:55:57 <alcabrera> lol
16:56:03 <kgriffs> #topic Summit sessions
16:56:12 <flaper87> kgriffs: you just read my mind
16:56:14 <kgriffs> FYI, I spoke with ametts about that last week
16:56:19 <zyuan> what is the last change?
16:56:23 <zyuan> to marconi API?
16:56:48 <kgriffs> I think we are looking at 4 sessions
16:57:03 <kgriffs> 1. alternate transports
16:57:06 <kgriffs> 2. alternate backends
16:57:21 <kgriffs> 3. notifications
16:57:48 <kgriffs> 4. proposed new features
16:57:52 <kgriffs> something like that
16:57:56 <flaper87> +1
16:58:06 <alcabrera> What's the link to summit sessions?
16:58:07 <kgriffs> so, existing proposals will slot into one of those 4
16:58:15 <kgriffs> #link http://summit.openstack.org/cfp/topic/19
16:58:20 <alcabrera> Also, I love the list of proposed sesssions - awesome stuff.
16:58:27 <alcabrera> kgriffs: thanks!
16:58:36 <kgriffs> re the talk, it got scheduled at the same time as the design sessions
16:58:37 <kgriffs> so....
16:59:32 <kgriffs> ametts is working to try and get the talk rescheduled to avoid a "conflict of interest"
16:59:35 <kgriffs> ;)
16:59:42 <megan_w> fine.  i'll go to hong kong.  ugh.
16:59:48 <alcabrera> lol
17:00:06 <kgriffs> megan_w: yeah, that would really be unfortunate if you had to do that
17:00:13 <kgriffs> ;)
17:00:13 <megan_w> haha
17:00:16 <flaper87> :D
17:00:22 <malini> megan_w: I am sorry, megan_w
17:00:23 <kgriffs> ok,
17:00:28 <kgriffs> #topic open discussion
17:00:35 <kgriffs> zyuan had a q?
17:00:50 <zyuan> 1st, API finallize
17:00:51 <kgriffs> "progress on mysql?"
17:00:52 <zyuan> decided?
17:00:59 <zyuan> and progress on mysql
17:01:15 <kgriffs> API finalized, the only pending thing I recall was a status code
17:01:25 <zyuan> ??
17:01:35 <alcabrera> HTTP 200 vs. HTTP 204 on /v1/health, I think?
17:01:46 <zyuan> queues use 204
17:01:53 <zyuan> i'm fine with 200
17:01:59 <kgriffs> no,
17:02:02 <kgriffs> it was something else
17:02:05 <kgriffs> can't remember
17:02:13 <kgriffs> oz_akan was in on it
17:02:23 <zyuan> class HealthResource(object):
17:02:24 <zyuan> def on_get(self, req, resp, project_id):
17:02:24 <zyuan> resp.status = falcon.HTTP_204
17:02:24 <zyuan> def on_head(self, req, resp, project_id):
17:02:25 <zyuan> resp.status = falcon.HTTP_204
17:02:30 <kgriffs> he tortured me until i agreed to consider it
17:02:48 <kgriffs> it's no wonder i can't remember
17:02:52 <alcabrera> kgriffs: lol
17:03:04 <kgriffs> THERE ARE THREE LIGHTS!
17:03:18 <flaper87> re progress on mysql: ykaplan is working on that, this whole month was holiday in Israel (Starting here: Rosh Hashana)
17:03:19 <zyuan> i... don't know. let's make it 200...
17:03:30 <flaper87> so, she wasn't able to do much on it
17:03:41 <flaper87> She's also getting familiar with sqlalchemy
17:03:47 <zyuan> ................................
17:03:53 <alcabrera> #info ykaplan is working on mysql backend
17:03:58 <kgriffs> #link https://bugs.launchpad.net/marconi/+bug/1220768
17:04:00 <kgriffs> found it
17:04:08 <flaper87> zyuan: ?
17:04:14 <alcabrera> ah
17:04:25 <zyuan> "getting familiar"
17:04:35 <flaper87> zyuan: what's wrong with that?
17:05:04 <zyuan> i suppose people should be familiar with it within 10 mins...
17:05:27 <alcabrera> we're 5 minutes over time - we should end the meeting, maybe?
17:05:32 <flaper87> zyuan: you suppose more things than you should, TBH! Plus, read my previous message, she was on holidays
17:05:52 <flaper87> alcabrera: +1
17:06:04 * flaper87 has nothing more to say
17:07:08 <kgriffs> we can go over a few minutes. nobody waiting on us.
17:07:23 <flaper87> hehe, this time slot is awesome
17:07:24 <flaper87> :D
17:07:26 <alcabrera> lol
17:07:30 <flaper87> we can have longer meetings
17:07:42 * kgriffs wonders if that is a good thing, heh
17:07:43 <kgriffs> sooo
17:07:47 <kgriffs> we have two breakouts
17:07:51 <alcabrera> I was worried about conflicting with others, but that concern is abated.
17:08:00 <kgriffs> 1. that bug just mentioned above
17:08:19 <kgriffs> 2. unicode queue names
17:08:31 * kgriffs just realized both of these impact API finalization
17:08:37 <alcabrera> kgriffs: yup
17:08:37 <kgriffs> so, starting with 1.
17:09:11 <zyuan> NAD
17:09:15 <kgriffs> i believe were we ended up last time discussing the issue was we didn't want client's to raise an exception or anything if the queue didn't exist
17:09:22 <zyuan> Not a Defect
17:09:51 <alcabrera> Hmm...
17:09:53 <kgriffs> well, that's the first question, isn't it?
17:10:07 <kgriffs> seems to me an app may be logging requests
17:10:25 <kgriffs> and something odd may happen that the user is trying to diagnose
17:10:37 <zyuan> i don't think there is a place to have question, both from interface and implementation.
17:10:38 <kgriffs> and they want to check their logs for anomalies
17:10:48 <kgriffs> any other use cases people can think of?
17:12:05 <zyuan> if user want to tell whether a message exists, how about GET?
17:12:11 <kgriffs> personally, don't think it is a big deal to leave as-is, but I also am not opposed to returning 200 or 205 or something.
17:12:11 <alcabrera> kgriffs: could you tie the example in with the case of deleted queues? I think you're trying to say that the user would want to detect erroneously deleted queues.
17:12:35 <flaper87> I'd prefer to leave it as-is
17:12:40 <kgriffs> mmm, possibly. Do we fail silently there as well?
17:13:06 <alcabrera> kgriffs: GET message on non-existing queue => 404
17:13:15 <kgriffs> so...
17:13:48 <kgriffs> if we can assume that a client would be able to detect the problem elsewhere, then I too vote to leaving as-is
17:13:57 <kgriffs> any opposed?
17:14:21 <zyuan> i want to say i don't see the problem the user want to detect...
17:14:24 <zyuan> anyway.
17:14:34 <kgriffs> going once
17:14:44 <kgriffs> going twice
17:14:45 <flaper87> sold
17:14:48 <alcabrera> woot
17:14:48 <flaper87> muahahah
17:14:51 <alcabrera> bug update?
17:14:53 <zyuan> ....
17:15:04 <kgriffs> set to "won't fix"
17:15:09 <alcabrera> sweet
17:16:09 <alcabrera> next
17:16:15 <alcabrera> 2. unicode queue names
17:16:29 <flaper87> I'm fine with either
17:16:32 <kgriffs> http://asg.web.cmu.edu/rfc/rfc3986.html#sec-2.1
17:16:34 <zyuan> i want to add some background about URI
17:16:36 <flaper87> I wanted us to discuss it a bit more
17:17:03 <zyuan> rfc 3986 refered ASCII
17:17:09 <zyuan> as "charset"
17:17:16 <zyuan> however, it also says
17:17:48 <zyuan> everything which is neither "reserved" nor "unreserved" should be percent-encoded
17:18:13 <zyuan> which means, the actually charset is "reserved" and "unreserved"; it has nothing to do with ASCII
17:18:40 <kgriffs> yes
17:19:03 <zyuan> and, considering URI encodings are different on different platforms
17:19:05 <kgriffs> the tricky thing is that, to my knowledge, there is non header that hints at the decoded charset for the uri
17:19:12 <kgriffs> s/non/no
17:19:22 <zyuan> i think it's dangours for us to define an encoding
17:19:45 <kgriffs> i would tend to agree
17:19:55 <flaper87> in that case, lets restrict it to ASCII as kgriffs' patch proposed
17:20:03 <zyuan> so my preference is to limit queue name to "unreserved"; thus, a-z0-9 stuff
17:20:17 <flaper87> I agree, given the above
17:20:31 <kgriffs> can anyone think of a reason that a user would want more latitude in choosing a queue's name?
17:20:32 <zyuan> re the patch, i'm not sure whether the patch is applied to the right place
17:20:48 <zyuan> there are multiple places this problem can happen
17:21:22 <alcabrera> kgriffs: nah - I'm satisfied as a user being able to choose queue names from 128**64 combinations (~128 characters - 64 of them)
17:21:24 <kgriffs> you mean, wrt queue names, or other params?
17:21:43 <kgriffs> alcabrera: lol
17:21:51 <zyuan> first, what is the type of the uri returned from falcon?
17:22:18 <zyuan> depends on the type and content, it might be falcon's problem instead of regex's
17:23:08 <flaper87> alcabrera: huauhauhau
17:23:18 <kgriffs> zyuan: falcon just passes through
17:23:30 <kgriffs> it would be the WSGI server doing any transforms, if any
17:23:39 <zyuan> python3?
17:24:26 <zyuan> yes it "pass though", but why regex \w does not work here? i don't think regex has "problem"
17:24:36 <alcabrera> bytes vs. text URI, zyuan?
17:24:42 <zyuan> yes
17:24:42 <kgriffs> zyuan
17:24:48 <kgriffs> no, it is nothing like that
17:24:50 <kgriffs> the problem is...
17:25:03 <kgriffs> \w can actually match unicode chars
17:25:10 <zyuan> i know
17:25:12 <kgriffs> depending on some python build flags
17:25:17 <flaper87> guys, gtg
17:25:20 <kgriffs> kk
17:25:24 <zyuan> but we should not give it unicode
17:25:25 <alcabrera> flaper87: thanks for joining us!
17:25:28 <flaper87> will read backlog later!
17:25:32 <flaper87> alcabrera: my pleasure!
17:25:32 <alcabrera> flaper87: :)
17:25:40 <zyuan> i said in comments, the input must be bytes
17:25:44 <flaper87> dinner awaits
17:26:49 <kgriffs> zyuan: in python2 even if the input is bytes it can still contain multi-byte encoding such as UTF-8
17:27:31 <zyuan> kgriffs: it doesn't matter; regex can not work directly on UTF-8 it the bytes are not decoded.
17:28:01 <zyuan> i mean, it does not recognize multibyte encoded string "automatically"
17:28:15 <zyuan> but if WSGI decoded it into unicode, hehe
17:29:21 <kgriffs> seems like if \w ended up allowing non-ascii chars, but the bytestring was something other than ascii (may not even be unicode; there are many possiblities) we wouldn't want the regex to match inadvertantly
17:29:26 <kgriffs> anyway, I gotta run too
17:29:45 <zyuan> i'' recheck WSGI
17:29:46 <kgriffs> we can continue discussing later in #openstack-marconi if you like
17:29:59 <kgriffs> #endmeeting