18:59:58 <malini> #startmeeting: poppy
18:59:59 <openstack> Meeting started Thu Oct 16 18:59:58 2014 UTC and is due to finish in 60 minutes.  The chair is malini. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:04 <openstack> The meeting name has been set to '__poppy'
19:00:22 <malini> who is here for poppy?
19:00:30 <obulpathi> hi there o/
19:00:52 <amitgandhinz> o/
19:00:53 <tonytan4ever> o/
19:00:53 <malini> hello amitgandhinz
19:00:59 <malini> #chair amitgandhinz
19:00:59 <openstack> Current chairs: amitgandhinz malini
19:02:04 <amitgandhinz> hi everyone
19:02:10 <amitgandhinz> ok lets get this party started =)
19:02:19 <obulpathi> yay
19:02:21 <obulpathi> party
19:02:22 <amitgandhinz> #topic Review Last Week
19:02:29 <amitgandhinz> #link http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-10-09-19.00.html
19:02:48 <amitgandhinz> obulpathi to finalize on the format of the next_url for listing services
19:02:54 <obulpathi> yes
19:03:08 <obulpathi> I contacted the DRG and took feedback from them
19:03:22 <amitgandhinz> did the apiary doc get updated?
19:03:22 <obulpathi> a good way to structure the next links: is to leave it empty for the last batch
19:03:27 <obulpathi> yes
19:03:31 <amitgandhinz> cool
19:03:46 <obulpathi> and the implementation is also done
19:03:55 <amitgandhinz> =)
19:03:55 <obulpathi> as a part of the list end point
19:04:04 <obulpathi> :)
19:04:10 <amitgandhinz> ok next item: megan_w to gauge vendor participation in Paris
19:04:22 <amitgandhinz> megan_w is not around
19:04:54 <amitgandhinz> any vendors here today?
19:05:11 <amitgandhinz> anyone else planning to attend the openstack summit in paris?
19:05:41 <obulpathi> nop
19:05:51 <amitgandhinz> ok carry this one over
19:05:57 <amitgandhinz> #action megan_w to gauge vendor participation in Paris
19:06:04 <megan_w_> here
19:06:13 <amitgandhinz> hi megan_w_
19:06:17 <megan_w_> hi there
19:06:18 <obulpathi> hi megan_w
19:06:22 <megan_w_> do we have any vendors here with us today?
19:06:31 <amitgandhinz> no one appears to be
19:06:49 <megan_w_> we need to get better about communicating with so they get here
19:06:56 <amitgandhinz> yeh
19:06:57 <megan_w_> with them*
19:07:17 <amitgandhinz> do you know if any of them plan to attend paris?
19:07:32 <megan_w_> i don't, i was hoping we could discuss it in these meetings
19:07:55 <megan_w_> we should propose what we would want from them in the session
19:07:57 <megan_w_> then ask for attendance
19:08:05 <amitgandhinz> yeh, may need to encourage them outside these meetings
19:08:24 <amitgandhinz> it will be a design session, so the idea is to come up with the features to build during kilo
19:08:24 <megan_w_> take it away, PTL :)
19:08:57 <megan_w_> hmm, ok
19:09:06 <amitgandhinz> ok moving on...
19:09:27 <amitgandhinz> #topic Blueprint Updates
19:09:32 <amitgandhinz> #link https://blueprints.launchpad.net/poppy
19:09:41 <amitgandhinz> obulpathi: list-services
19:09:49 <obulpathi> list-services is merged
19:09:57 <megan_w_> moving on
19:09:57 <obulpathi> thanks all for the review
19:10:04 <obulpathi> and special thanks to malini
19:10:18 <obulpathi> for having lot of patience to find all the bugs iun my code :)
19:10:23 <malini> obulpathi: I was expecting something bad :D
19:10:24 <amitgandhinz> miqui: add-docstrings
19:10:29 <obulpathi> hahha
19:11:25 <amitgandhinz> looks like that one needs me to review
19:11:43 <amitgandhinz> tonytan4ever: delete-service
19:12:09 <tonytan4ever> This one is "under review", but really it is ready to be merged.
19:12:23 <amitgandhinz> no one has +1'd the latest patch yet
19:12:27 <tonytan4ever> I cleared the api test blocker yesterday,
19:12:35 <amitgandhinz> ok lets get some reviewers on that
19:12:41 <obulpathi> roger that
19:12:50 <amitgandhinz> tonytan4ever: purge-content
19:13:10 <tonytan4ever> I will call that in Good progress. 1st PR got +3
19:13:15 <tonytan4ever> ready to be merged now.
19:13:36 <tonytan4ever> https://review.openstack.org/#/c/126728/
19:13:36 <amitgandhinz> actually has  a +4 hehe
19:13:46 <malini> :-Pdoes jenkins count?
19:14:10 <amitgandhinz> no, but mine is a +2 =P
19:14:12 <amitgandhinz> merged!
19:14:17 <tonytan4ever> kk
19:14:51 <amitgandhinz> this was at the provider part only right
19:14:55 <tonytan4ever> yes
19:14:58 <amitgandhinz> so still needs api work
19:15:13 <amitgandhinz> ill mark it as good progress
19:15:15 <tonytan4ever> yes, that's what I am working on now.
19:15:20 <tonytan4ever> Sure.
19:15:28 <amitgandhinz> amitgandhinz: dns-driver
19:15:44 <amitgandhinz> this one as an initial patch to create the basic driver setup
19:15:58 <amitgandhinz> then i need to implement the cloud-dns-driver which is a seperate bp
19:16:14 <amitgandhinz> i currently only have 2 +1's
19:16:36 <malini> o/
19:16:39 <amitgandhinz> i need one more malini
19:16:47 <malini> tht would be really bad
19:16:51 <amitgandhinz> https://review.openstack.org/#/c/127628/
19:17:20 <malini> will check that out
19:17:52 <amitgandhinz> cloud-dns-driver already has a +3 but it depends on the above patch
19:18:17 <amitgandhinz> obulpathi:  patch-service
19:18:37 <obulpathi> patch-service: happy path test cases are passing now
19:18:53 <obulpathi> going through and ironing out the error inputs
19:19:04 <obulpathi> so, we can say its in good progress
19:19:15 <malini> obulpathi: can you re-use some of the code for POST service for error handling?
19:19:18 <obulpathi> will update the apiary, once I finish the error cases
19:19:43 <obulpathi> malini: the json service is validated by the same code as post
19:19:59 <obulpathi> but there are few more conditions that PATCH needs to take care of
19:20:07 <obulpathi> I am working through them
19:20:17 <malini> cool! thanks
19:20:20 <obulpathi> :)
19:20:45 <amitgandhinz> ok update on the https://blueprints.launchpad.net/poppy/+spec/master-sub-provider-accounts
19:20:56 <amitgandhinz> megan_w_ and I met with MaxCDN yesterday
19:21:06 <amitgandhinz> the CDN Manager is not actually required
19:21:20 <amitgandhinz> it basically give syou the added bonus of seperate control panels for each sub user
19:21:26 <amitgandhinz> which in the case of poppy we dont need
19:21:32 <megan_w_> i think that will end up being a more generic solution anyway, which is preferred for us
19:21:48 <amitgandhinz> if you plan to do reporting, billing, etc on your own from the logs, then the one account method works fine
19:21:54 <amitgandhinz> just need to up the limits
19:22:12 <amitgandhinz> im going to mark this bp as done
19:22:21 <obulpathi> awesome!
19:22:30 <tonytan4ever> I think we also need to find a better naming scheme from poppy service --> maxcdn service though.
19:22:58 <amitgandhinz> lets move that to open discussion tonytan4ever
19:23:07 <tonytan4ever> ok.
19:23:22 <amitgandhinz> malini: gate-cassandra
19:23:33 <malini> I haven't got a chance to work on tht yet
19:23:36 <amitgandhinz> ok
19:23:48 <malini> It'll probably have to move to the next Series Goal
19:24:15 <amitgandhinz> same with the rm-mockdb
19:24:31 <amitgandhinz> that bp is blocked until we can run cassandra at the gate or we have sqla
19:25:06 <amitgandhinz> ok moving on
19:25:09 <amitgandhinz> #topic bugs
19:25:13 <amitgandhinz> link https://bugs.launchpad.net/poppy
19:25:14 <malini> yayyyy !!!
19:25:16 <amitgandhinz> #link https://bugs.launchpad.net/poppy
19:25:30 <amitgandhinz> malini: you want to drive this topic
19:25:34 <malini> sure
19:25:40 <malini> the bugs need some love
19:25:43 <amitgandhinz> ew
19:25:47 <obulpathi> hhaha
19:25:54 <amitgandhinz> kiss the spiders
19:25:56 <malini> We have a lot surrounding the error handling for create flavors
19:26:12 * amitgandhinz hides
19:26:14 <malini> amitgandhinz: I meant more along the lines of bugspray
19:26:43 <malini> I suggest we make a bp for it, as I got tired of writing down the bugs & stopped after a while :-$
19:26:52 <amitgandhinz> ok please do that
19:27:07 <malini> ok..will do after the meeting & get rid of the related bugs
19:27:17 <malini> tht still leaves us a few bugs
19:27:34 <malini> https://bugs.launchpad.net/poppy/+bug/1379901
19:27:35 <uvirtbot> Launchpad bug 1379901 in poppy "400s returns as HTML" [Undecided,New]
19:27:51 <malini> wow..I didn't know it wud fetch bug details
19:27:58 <amitgandhinz> ya thats cool
19:28:05 <tonytan4ever> I think I can fix that one real quick
19:28:17 <amitgandhinz> ok lets get this one
19:28:23 <malini> tonytan4ever: Can I assign tht to you?
19:28:24 <tonytan4ever> by utilizing Pheniox's pecan hook's code
19:28:26 <tonytan4ever> Yes
19:28:30 <amitgandhinz> +1
19:28:33 <amitgandhinz> next
19:28:50 <malini> https://bugs.launchpad.net/poppy/+bug/1380679
19:28:51 <uvirtbot> Launchpad bug 1380679 in poppy "Remove project_id from the request url in tests" [Undecided,New]
19:29:01 <obulpathi> I added the pecan hook to take care of this
19:29:10 <amitgandhinz> is this still an issue?
19:29:12 <malini> we need to cleanup the unit tests
19:29:15 <obulpathi> we just need to use the url format code
19:29:32 <obulpathi> I think in some cases, we still return the tenant / project id
19:29:40 <malini> obulpathi: you want to take that one?
19:29:45 <obulpathi> Yes,Please
19:29:47 <amitgandhinz> ok so sounds like we need to sweep
19:29:57 <malini> can you assign urself obulpathi ?
19:29:57 <obulpathi> Amitgandhinz: Assign this to me
19:29:59 <amitgandhinz> all these dead bugs are starting to smell
19:30:07 <obulpathi> sure
19:30:12 <malini> they'll breed if live
19:30:18 <amitgandhinz> assigned
19:30:29 <malini> last one is interesting
19:30:32 <malini> https://bugs.launchpad.net/poppy/+bug/1382155
19:30:33 <uvirtbot> Launchpad bug 1382155 in poppy "/health endpoint returns wrong status when cassandra is offline" [Undecided,New]
19:30:43 <malini> I ran into this one just an hour back
19:30:47 <malini> so its still fresh
19:31:06 <obulpathi> The cassandra driver is hardcoded to return True
19:31:14 <obulpathi> My bad, should have taken care of that
19:31:21 <obulpathi> I will take care of this one
19:31:32 <malini> can you assign urself obulpathi?
19:31:33 <amitgandhinz> assigned
19:31:38 <malini> thanks amitgandhinz :)
19:31:40 <obulpathi> thanks
19:31:53 <malini> amitgandhinz: https://bugs.launchpad.net/poppy/+bug/1379901 shud go to tonytan4ever
19:31:54 <uvirtbot> Launchpad bug 1379901 in poppy "400s returns as HTML" [Undecided,New]
19:31:59 <amitgandhinz> done
19:32:14 <malini> the rest is post flavor related. I'll create a bp for tht
19:32:19 <amitgandhinz> thanks
19:32:33 <malini> we missed this one https://bugs.launchpad.net/poppy/+bug/1375341
19:32:35 <uvirtbot> Launchpad bug 1375341 in poppy "Error Messages in test logs" [Medium,Confirmed]
19:32:50 <malini> do we care to fix it now?
19:32:58 <amitgandhinz> thats a lower priority
19:33:15 <malini> amitgandhinz: can you change the priority, plz?
19:33:23 <malini> https://bugs.launchpad.net/poppy/+bug/1375341
19:33:39 <malini> hmm…why didn't it fetch the summary?
19:33:49 <malini> "Unable to create a distribution with multiple origins for CloudFront driver"
19:34:11 <malini> obulpathi: can this wait?
19:34:14 <obulpathi> This one got to do with teh limitations of boto
19:34:24 <obulpathi> the cloudfront client
19:34:36 <obulpathi> so, we can fix this until we fix the boto
19:34:41 <malini> ok
19:34:51 <malini> do we have an issue open for boto?
19:34:54 <obulpathi> yes, this can wait, unless amitgandhinz says otherwise
19:35:01 <amitgandhinz> low
19:35:30 <malini> obulpathi: https://bugs.launchpad.net/poppy/+bug/1359950 what abt this one?
19:35:31 <uvirtbot> Launchpad bug 1359950 in poppy "Support for updating service with CloudFront driver is missing" [Undecided,New]
19:35:53 <obulpathi> thats is a different one
19:35:56 <malini> yes
19:36:30 <amitgandhinz> is there a way that can be surfaced via tests rather than as a bug?
19:36:33 <obulpathi> cloudfront python client has limited capabilities right now
19:36:55 <amitgandhinz> because as new drivers are built its possible they lack a feature and i would rather the tests identify that than have an open bug for it
19:37:11 <tonytan4ever> +1 on that.
19:37:13 <malini> amitgandhinz: you want the tests to keep failing for these?
19:37:16 <amitgandhinz> ie run the api tests against each provider
19:37:26 <obulpathi> +1
19:37:27 <amitgandhinz> they can be made non failing, just informational
19:37:47 <amitgandhinz> ie its own environment in tox?
19:37:52 <malini> We can skip the tests with INFO message, but when do we decide it's time to not skip them?
19:37:54 <amitgandhinz> that appears on the review page?
19:38:15 <amitgandhinz> im just thinking when a new provider build their own driver, and stops half way it should not halt poppy
19:38:29 <amitgandhinz> but users should be able to see that driver X is failing in these areas so choose not to use it
19:38:37 <malini> yeah..I think we need to somehow track them
19:38:39 <obulpathi> +1 good idea
19:38:46 <malini> SKIPPED tests usually get ignored
19:38:50 <amitgandhinz> lets discuss that offline
19:38:56 <amitgandhinz> maybe failing but non voting?
19:38:57 <malini> ok
19:39:12 <malini> lets chat in #openstack-poppy
19:39:16 <amitgandhinz> ya
19:39:20 <malini> tht's all for bugs
19:39:25 <obulpathi> cool
19:39:27 <malini> amitgandhinz: we can move to the next topic
19:39:36 <amitgandhinz> ya
19:39:47 <amitgandhinz> #topic Standardized Error Responses
19:39:52 <miqui> hi folks..sorry am late..
19:39:57 <amitgandhinz> #link https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines#Failure_Codes
19:39:59 <obulpathi> hi miqui
19:40:01 <amitgandhinz> hi miqui
19:40:02 <malini> miqui: glad you could make it :)
19:40:02 <miqui> hi
19:40:22 <malini> So I am running into issues where our error messages don't make sense
19:40:32 <malini> which is bad for a project as young as us
19:40:47 <malini> example error:
19:40:48 <malini> {
19:40:48 <malini> "code": 400,
19:40:48 <malini> "description": "u'fastly'",
19:40:48 <malini> "title": "Bad Request"
19:40:48 <malini> }
19:40:54 <miqui> malini: is that becuase the msg is different per vendor?
19:41:19 <malini> miqui: even within our code we are not providing descriptive error messages
19:41:26 <miqui> gotcha...
19:41:45 <amitgandhinz> i think its just lacking in quality messages being surfaced
19:41:57 <amitgandhinz> we need to be better at handling errors, and outlining why it failed
19:41:57 <malini> amitgandhinz: yes
19:42:04 <miqui> +1
19:42:16 <malini> If it fails with a 400, we shouldn't leave the user wondering why
19:42:20 <tonytan4ever> #agreed
19:42:30 <malini> tonytan4ever never argues :)
19:42:34 <amitgandhinz> #agreed to handle error messages better
19:42:35 <miqui> ..heheh
19:42:39 <tonytan4ever> #agreed
19:42:51 <amitgandhinz> i dont think tonytan4ever knows that using a hashtag logs it in the summary lol
19:42:59 <tonytan4ever> #agreed
19:43:06 <malini> what does everybody think of this format https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines#Failure_Codes ?
19:43:15 <amitgandhinz> tonytan4ever: http://meetbot.debian.net/Manual.html
19:43:41 <obulpathi> yes, I also wanted to bring up about the API Guidelines
19:43:59 <obulpathi> I will be good for to study this and pick up good parts
19:44:00 * miqui reading...
19:44:01 <amitgandhinz> that format looks better than what i proposed in the apiary docs
19:44:10 * amitgandhinz which somehow disappeared hmmmm
19:44:41 <miqui> i think the APIGuidelines is fine...
19:44:48 <malini> amitgandhinz: it made rom for something better
19:45:18 <malini> since we all agree, should this go to a bp to clean up existing stuff?
19:45:30 <malini> All new code should follow this format
19:45:34 <amitgandhinz> ya
19:45:37 <miqui> yes
19:45:40 <amitgandhinz> we should have a standardized class for it
19:45:44 <amitgandhinz> and use that
19:45:56 <amitgandhinz> also we should be using the oslo logging more when errors do happen
19:46:01 <amitgandhinz> we are very light on log lines
19:46:08 <malini> amitgandhinz: Can you write up tht bp?
19:46:18 <amitgandhinz> will do
19:46:25 <obulpathi> amitgandhinz: +1
19:46:26 <malini> amitgandhinz: good point..these should be stuff to watch out for during reviews
19:46:34 <amitgandhinz> yep
19:46:37 <malini> we need review guidelines in the wiki
19:46:50 <miqui> question: an error msg fromthe vendor would end up in message: right?
19:47:27 <malini> tonytan4ever can answer that best
19:47:30 <amitgandhinz> miqui: its possible
19:47:48 <tonytan4ever> Well, not always.
19:47:48 <amitgandhinz> sometimes poppy could determine why it failed and create a more poppy friendly message back to the user
19:47:58 <amitgandhinz> sometimes it may make sense for the vendor's error to propogate back
19:48:08 <miqui> right..
19:48:18 <miqui> was trying to gage when to do what....
19:48:36 <amitgandhinz> we should probably make a best guess determination of what will make the most sense to the user
19:48:47 <miqui> ok, sounds good..
19:49:01 <amitgandhinz> for example, if we get a duplicate key exception from a vendor, poppy can relay an appropriate message back
19:49:24 <miqui> +1
19:49:31 <amitgandhinz> hoever, if a vendor had an unknown exception occur, then we may be best suited to relay that error back
19:49:49 <obulpathi> +1
19:49:52 <amitgandhinz> also, theres a section on friendly user message, and then more details
19:49:59 <amitgandhinz> in the guideline proposed
19:50:07 <miqui> thats a good point becuase vendor support folks are wanting to know this info..
19:50:23 <amitgandhinz> #agreed team gets better at handling error messages and logging them
19:50:45 <amitgandhinz> #agreed team will surface errors based on https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines#Failure_Codes
19:50:50 <amitgandhinz> #link https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines#Failure_Codes
19:50:52 <amitgandhinz> ok
19:50:57 <amitgandhinz> 9  minutes remain
19:51:08 <amitgandhinz> #topic open discussion
19:51:18 <amitgandhinz> tonytan4ever: you had an item about using id's
19:51:29 <tonytan4ever> Yes.
19:52:18 <tonytan4ever> Since for vendors like MaxCDN we are not to use Master/Sub accounts, the service name mapping from poppy to maxcdn will be a little tricky.
19:52:51 <amitgandhinz> please explain
19:53:46 <tonytan4ever> Also for logging purposes, since a poppy service's name can be changed by PATCH endpoint, tracking which provider (say MaxCDN) service belong to which user service will be an issue.
19:54:11 <malini> does MaxCDN generate its own service name?
19:54:23 <amitgandhinz> so basically if i call my service "Amits Service" then no one else within maxcdn through my operator account can use that name
19:54:48 <amitgandhinz> or more generically "My Service"
19:54:52 <tonytan4ever> Right, since different users can have same poppy service name
19:54:56 <amitgandhinz> yeh
19:55:15 <amitgandhinz> so how about we generate a provider id (uuid) and use that as the servicename with the providers
19:55:16 <tonytan4ever> but they cannot have the same MaxCDN service name in the same account
19:55:25 <amitgandhinz> and we store that in our provider details ( i think we already have a field for it)
19:55:28 <malini> hmm..but tht is true for other providers too, rt? like fastly
19:55:31 <tonytan4ever> That looks like a good idea to me.
19:55:33 <tonytan4ever> Yes.
19:55:46 <amitgandhinz> and so users of poppy can have whatever name (unique by projectid + servicename)
19:56:02 <tonytan4ever> Same applies for fastly, assume we only use one fastly operator account.
19:56:04 <amitgandhinz> and the providers end up have UUID as the servicename/pullzoneid/distributionid
19:56:29 <obulpathi> +1
19:56:41 <amitgandhinz> if a user patches the servicename in poppy, the provider id need not change
19:56:41 <malini> do providers allow different users to have the same service name?
19:56:47 <amitgandhinz> no
19:56:56 <amitgandhinz> well depends on the provider
19:57:11 <amitgandhinz> if its a different account they can have the same name
19:57:16 <amitgandhinz> but within an account it must be unique
19:57:26 <amitgandhinz> in the case of poppy, its one operator account only
19:57:39 <malini> ok.
19:57:56 <tonytan4ever> Almost all of the case we are only gonna have one provider service account.
19:58:04 <amitgandhinz> ok so do we agree to submit a uuid as the name at the provider level?
19:58:26 <tonytan4ever> agreed.
19:58:27 <obulpathi> +1
19:58:29 <amitgandhinz> i cant see a problem with it
19:58:56 <amitgandhinz> the uuid may need to be custom based on name rules at the provider
19:59:04 <amitgandhinz> but we already have a function to handle that
19:59:16 <amitgandhinz> we just store whatever the id ends up being in the provider-details
19:59:27 <tonytan4ever> yes.
19:59:40 <amitgandhinz> malini: miqui: any concerns on this approach?
19:59:58 <miqui> not atm...
20:00:02 <malini> hmmm..I am still hazy on the details
20:00:14 <malini> so no atm :)
20:00:15 <amitgandhinz> we can discuss more in the normal channel then
20:00:24 <amitgandhinz> time is up
20:00:28 <amitgandhinz> thanks everyone
20:00:34 <malini> thank you!!
20:00:39 <obulpathi> thank you!
20:00:44 <obulpathi> see you all next week
20:00:45 <amitgandhinz> and miqui, we will see you in a few hours at the tavern!
20:00:49 <amitgandhinz> #endmeeting