09:00:18 <priteau> #startmeeting blazar
09:00:19 <openstack> Meeting started Tue Dec 13 09:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:22 <openstack> The meeting name has been set to 'blazar'
09:00:30 <priteau> #chair masahito hiro-kobayashi
09:00:31 <openstack> Current chairs: hiro-kobayashi masahito priteau
09:00:42 <masahito> hi all
09:00:44 <priteau> Hello
09:00:47 <GeraldK> hi
09:00:48 <r-mibu> o/
09:00:49 <hiro-kobayashi> Hello!
09:00:51 <priteau> #topic Roll call
09:00:52 <bertys> Hello
09:01:18 <priteau> Hi r-mibu, nice to have you with us
09:01:22 <bauzas> \o
09:01:47 <priteau> anyone else? janki?
09:02:04 <janki> o/
09:02:08 <janki> priteau, hey
09:02:11 <r-mibu> yes, sorry for the absence last week
09:02:22 <priteau> Great, let's get started
09:02:29 <priteau> #topic Action items from last call
09:02:50 <priteau> In the meeting notes last week we had three explicit action items
09:03:03 <r-mibu> http://eavesdrop.openstack.org/meetings/blazar/2016/blazar.2016-12-06-09.00.html
09:03:04 <priteau> 1. Review state of API versions: v1 vs v2
09:03:04 <priteau> 2. bauzas to review https://review.openstack.org/#/c/398716/
09:03:04 <priteau> 3. hiro-kobayashi to rebase 398716 on top of 406009
09:03:19 <priteau> First one was for me
09:03:35 <priteau> I added my findings to our current Etherpad
09:03:44 <priteau> #link https://etherpad.openstack.org/p/Blazar_status_2016 Status of the Blazar project (December 2016)
09:04:05 <priteau> Scroll down to the header "Blazar REST API: v1 vs v2"
09:04:44 <priteau> As far as I understand, the service code has support for the two API versions and both are loaded by default
09:04:56 <bauzas> exactly
09:05:26 <bauzas> the main difference for v2 is not zactly the WSGI router
09:05:30 <priteau> There doesn't seem to be a big difference in API capabilities except for support for CRUD operations on "Before end" notifications, but I may be wrong
09:05:48 <bauzas> that's rather that we have an automatic documentation
09:06:03 <bauzas> and that we have a different input validation
09:06:03 <priteau> yes, the difference seems to be more on implementation
09:06:10 <masahito> priteau: thanks.
09:06:19 <priteau> however, there is no support for v2 in the client yet
09:06:35 <priteau> I found some patches on Gerrit which were never merged
09:06:50 <r-mibu> priteau, wich version are you using?
09:06:59 <priteau> r-mibu: we use v1 in Chameleon
09:07:10 <priteau> so if we want to deprecate / disable v1, we need support in the client first
09:07:24 <GeraldK> are people from HPE in the meeting? which version are you using?
09:07:32 <r-mibu> ok, is v2 experimental?
09:07:41 <bauzas> I added v2
09:07:49 <tejaswi> Hi Gerald. I am from HPE
09:08:02 <bauzas> but we stopped working on Climate quite close after that
09:08:25 <bauzas> so we didn't had time to work more on v2
09:08:38 <GeraldK> hi tejaswi.
09:08:45 <masahito> hi tejaswi
09:08:49 <bauzas> there are a bit of differences between v1 and v2 about the REST objects etc.
09:08:56 <tejaswi> I believe we are using v1
09:09:14 <bauzas> so v2 is not bacwards compatible with v1
09:09:15 <priteau> Hi tejaswi
09:09:30 <bauzas> but I leave you guys think about that
09:09:47 <priteau> so I listed a few action items on the Etherpad
09:09:54 <priteau> first is better documentation of differences between v1 and v2
09:09:58 <GeraldK> has the new implementation in v2 significant benefits to v1?
09:10:03 <priteau> I would like to understand exactly the difference in REST objects
09:10:16 <tejaswi> hi masahito, priteau
09:10:25 <bauzas> GeraldK: at least for documenting
09:10:39 <GeraldK> priteau: +1. shall we collect a list of things to review in detail?
09:10:46 <bauzas> GeraldK: and since we used WSME, we have a better input validation
09:11:18 <r-mibu> +1 to check out difference in API versions
09:11:30 <priteau> GeraldK: There is a wiki page documenting the v1 API: https://wiki.openstack.org/wiki/Blazar/REST_API
09:11:31 <masahito> +1
09:11:43 <masahito> bauzas: sounds like object means python object in server side, right?
09:11:43 <bauzas> priteau: because v2 is autodocumented
09:11:53 <r-mibu> note, we don't have to keep backward compatibility
09:12:11 <priteau> bauzas: is the v2 documentation generated by tox -e docs or something else?
09:12:15 <bauzas> masahito: yeah, a WSME object rather
09:12:36 <bauzas> priteau: I don't remember the exact tox call but yeah
09:13:11 <priteau> #action Generate WSME doc for v2 API and check for differences with v1 (priteau)
09:13:34 <bauzas> priteau: indeed that's the doc target https://github.com/openstack/blazar/blob/master/tox.ini#L34
09:13:38 <priteau> I noticed that the WSME upstream repo doesn't have any recent changes, is it still the recommended framework for OpenStack APIs?
09:13:56 <bauzas> nope
09:14:12 <bauzas> that's a good point
09:14:25 <bauzas> the thing is that WSME was giving us great benefits
09:14:33 <bauzas> but that's very strict
09:14:47 <r-mibu> fyi: https://krotscheck.net/2016/03/25/we-need-an-consistent-openstack.html
09:14:49 <priteau> the docs are generated by Jenkins on each review change
09:14:53 <priteau> e.g. http://docs-draft.openstack.org/66/406666/7/check/gate-blazar-docs-ubuntu-xenial/5ddde5e//doc/build/html/restapi/index.html
09:15:29 <priteau> r-mibu: very interesting link!
09:15:32 <bauzas> r-mibu: I'd recommend to reach the API WG
09:16:09 <r-mibu> it is valuable to have discussion which framework to be used in blazar
09:16:18 <bauzas> when I was working on Climate, there was no group trying to make a consistent experience
09:16:31 <bauzas> now, we have some guidelines
09:16:32 <r-mibu> i don't have strong preference though
09:16:36 <bauzas> me too
09:16:46 <bauzas> we can even draft a v3 honestly
09:17:10 <bauzas> that's not a big deal
09:17:29 <bauzas> moving to Pecan was really a nobrainer, supporting WSME was the big deal but not that hard
09:17:35 <masahito> I don't think we need to move new version depending on API implementation.
09:17:40 <priteau> Yes, although we may want to have some new features added to Blazar to find out exactly how we want to shape a new API
09:17:41 <bauzas> what I'd love honestly is us supporting microversions
09:18:23 <r-mibu> microversions in NB API? or to talk to nova microversions APIs?
09:18:35 <bauzas> API-WG microversions :)
09:18:39 <bauzas> those are documented
09:18:46 <r-mibu> ok
09:18:53 <bauzas> but yeah, basically coming from nova
09:18:56 <priteau> #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
09:20:13 <priteau> From my use case I would like if our next release kept support for v1 in both service and client for providing an easy upgrade of Chameleon to Ocata
09:20:33 <priteau> Afterwards, I am happy if we make more drastic changes
09:20:38 <bauzas> I don't disagree with that :)
09:20:40 <r-mibu> that makes sense
09:20:44 <bauzas> that sounds very reasonable
09:20:44 <hiro-kobayashi> +1
09:20:46 <masahito> make sense
09:21:12 <bauzas> what I'm saying is that probably v2 would either need some rework to get rid of WSME or a v3
09:21:16 <masahito> IMO, we should support all existing feature in O release
09:21:30 <priteau> #agreed keep support for v1 API in the next Blazar release
09:21:30 <r-mibu> at least, we found no one using v2, so we can change v2 API maybe...
09:21:58 <bauzas> the real problem with v1 is that you'll need to keep it stable
09:22:13 <masahito> :-)
09:22:35 <masahito> It's our first priority.
09:22:41 <bauzas> so, once you'll begin modifying objects, you'll need to provide a backwards-compat path for returning those objects in a stable RESTful way
09:23:23 <priteau> if we have a replacement API ready soon we should mark v1 as deprecated
09:23:25 <bauzas> hence IMHO the need for another API endpoint but v1 that would propose a microversion support
09:24:00 <bauzas> or you would suffer from not being able to expose your latest features
09:24:10 <priteau> that's a very good point
09:24:44 <priteau> #action investigate microversion support for Blazar API
09:25:16 <priteau> I am not sure by when we can get this done though
09:25:53 <bauzas> honestly, I think you guys should consider writing your own WSGI stack from stratch
09:26:01 <masahito> we can discuss it after fixing known issue.
09:26:21 <bauzas> so that you wouldn't suffer from trying to adapt the existing Flask or Pecan app
09:26:35 <priteau> yes we have to focus on fixing known issues first and making the code more modern
09:26:54 <bauzas> masahito: agreed, the problem would only be with new features
09:27:28 <bauzas> if you guys focus on stability for your next release, then you can defer those points for later
09:28:07 <priteau> I vote for defer until Ocata timeframe
09:28:29 <masahito> priteau: +1
09:28:34 <hiro-kobayashi> +1
09:28:40 <GeraldK> focusing on stability and bug fixing for the next release makes sense, but we should not ignore the new features. it is because of them that we started looking into Blazar.
09:28:52 <GeraldK> we should target new features for the next release already.
09:29:10 <bauzas> that's really a resource problem
09:29:15 <priteau> GeraldK: let's talk about new features later in the meeting
09:29:17 <GeraldK> i mean new features for the following release
09:29:28 <priteau> I would like to continue progressing on the agenda
09:29:48 <priteau> Action item 2 was bauzas to review https://review.openstack.org/#/c/398716/
09:29:49 <bauzas> yeah, either way, exposing a new REST API is totally uncorrelated from fixing bugs
09:29:50 <masahito> yes, so we need to write down what we need or discuss in etherpad ant try to keep it in mind.
09:30:21 <priteau> bauzas pointed out that there were two many changes in the same patch and requested a new patch from hiro-kobayashi
09:30:30 <priteau> which has now been contributed
09:30:36 <bauzas> someone can work on supporting microversions (and decide which framework to use, and have the client supporting it) very separatetly from the team, that's not intricated
09:31:04 <priteau> hiro-kobayashi: I didn't understand your last comment on the patch. Are you saying that the line "if access == 'True':" is correct or incorrect?
09:31:06 <bauzas> yeah, about https://github.com/openstack/blazar/blob/master/tox.ini#L34 I need to do a second pass, but I second your argument, priteau
09:31:20 <hiro-kobayashi> priteau: it's correct
09:31:21 <bauzas> oops
09:31:28 <bauzas> https://review.openstack.org/#/c/398716/ I meant
09:31:49 <priteau> hiro-kobayashi: but in your comment you say "it should be compared as not boolean but string."
09:31:51 <hiro-kobayashi> I wrote details about it above link
09:32:20 <priteau> oh, I see what you mean now
09:32:25 <hiro-kobayashi> I meant the object stored in metadata is String
09:32:38 <bauzas> well, I don't want to discuss about a specific point in the review, but I orginally wrote that because .get() can return None
09:32:45 <priteau> what I meant was, the original check is "if access", which for a string means if access is anything but the empty string
09:32:56 <bauzas> so the conditional is only false if the key isn't present
09:33:23 <bauzas> what the value of the key is is not tested in the original code
09:33:44 <priteau> what I couldn't find is where is this key set, is it somewhere in the Blazar code?
09:33:54 <hiro-kobayashi> Oh, i may misunderstand, then
09:34:14 <hiro-kobayashi> So, that should be not changed from original?
09:34:14 <bauzas> priteau: mmm, I need to remember that
09:34:35 <priteau> I checked our Chameleon deployment and all aggregates are tagged with "climate:owner"
09:34:45 <bauzas> hiro-kobayashi: it *could* be changed, but that's a behavioural change, so I tend to deny that
09:35:04 <r-mibu> 25 mins left...
09:35:08 <priteau> but I didn't see a *key* set to the project_id and a value of *true*
09:35:22 <priteau> I think we can continue the discussion on Gerrit
09:35:37 <hiro-kobayashi> priteau: +1
09:35:38 <bauzas> agreed, I need to dig into old code
09:35:47 <bauzas> because I can't remind that for now
09:36:08 <priteau> third was hiro-kobayashi to rebase 398716 on top of 406009, which has been done
09:36:25 <priteau> #topic Ongoing patch reviews
09:36:25 <hiro-kobayashi> Yes, and it passes jenkins check
09:36:40 <priteau> I would like to keep this point short to leave time for the rest of the discussion
09:36:59 <priteau> Good news is that Tony's patches have all been merged now
09:37:18 <priteau> I think I got all current patches linked from the Etherpad
09:37:32 <priteau> and highlighted with "(needs review)"
09:37:42 <masahito> good news.
09:37:50 <masahito> we can only discuss the patch someone needs help or something in this topic.
09:38:09 <priteau> masahito: I would like if you could take a second look to https://review.openstack.org/#/c/408079/
09:38:14 <masahito> for time keeping.
09:38:33 <priteau> I need to review your tempest patches
09:38:34 <bauzas> masahito: agreed
09:38:41 <masahito> priteau: got it.
09:39:03 <bauzas> we could just point out patches needing attention or just having disagreements or unclear statement in there
09:39:20 <bauzas> since meeting times are short :-)
09:39:30 <priteau> and hiro-kobayashi if you could change the if test on "access" that we just mentioned
09:39:44 <priteau> If nothing else let's move on
09:39:46 <bauzas> FWIW, don't hesitate to ping me folks on #openstack-blazar when you want me to make a pass
09:39:52 <priteau> #topic Discussion of new features
09:39:55 <hiro-kobayashi> priteau: OK
09:40:05 <bauzas> I have a very limited capacity of reminding patches to review :)
09:41:20 <priteau> We have some features already identified on the pad
09:41:26 <priteau> Add resource plugins (e.g. Cinder, Neutron)
09:41:48 <priteau> I think there was preliminary work done on volume reservation
09:42:11 <priteau> https://wiki.openstack.org/wiki/Blazar/Use_Cases#Volume_Reservation
09:42:48 <bertys> #link https://blueprints.launchpad.net/blazar/+spec/basic-volume-plugin
09:42:53 <bauzas> the real problem people objected was with quotas
09:43:39 <bauzas> if you assume that reserving a resource will decrement your quota at the moment of the reservation and not at the time of the lease, then it can be possible to have other resources but just hosts or instances
09:44:30 <bauzas> FWIW, that's why I tend to dislike the way we implemented instances reservation in Climate, because by the time the instance is unshelved, you could be out of quotas
09:44:57 <bauzas> (but that's unrelated to the current topic)
09:45:36 <priteau> What are the new resource reservations needed for OPNFV?
09:45:39 <r-mibu> bauzas, that's good point - we need to see clear use cases
09:46:15 <GeraldK> for Promise: see the 3rd user story in http://specs.openstack.org/openstack/openstack-user-stories/user-stories/draft/capacity_management.html
09:46:23 <bauzas> r-mibu: I'd rather say that a usecase should also document the reservation workflow
09:46:39 <r-mibu> bauzas, kk
09:46:42 <GeraldK> "I want guaranteed access to 30 vCPUs and 200GB of RAM for my project. In addition, during October-December, I want to be able to increase my usage to 150 vCPUs and 1TB of RAM"
09:47:12 <hiro-kobayashi> And we are analyzing gap between the usecase and current OpenStack(especially blazar): https://etherpad.opnfv.org/p/promise_gap_analysis
09:47:33 <hiro-kobayashi> Above is for topic later
09:47:40 <hiro-kobayashi> also
09:48:30 <GeraldK> for OPNFV Promise requirements see also: https://etherpad.opnfv.org/p/promise_minimum_features
09:48:32 <priteau> GeraldK: that's only hypervisors though. What about volumes or floating IPs?
09:49:29 <GeraldK> priteau: yes, volumes, IP address ranges, (anti-)affintiy rules are also important
09:50:30 <priteau> Would someone from OPNFV be willing to take ownership of investigating what it would take to extend reservation to new kind of resources?
09:51:41 <masahito> ok, I try to prioritize which resource is needed.
09:51:54 <GeraldK> i think this can be done as part of the gap analysis
09:52:14 <GeraldK> masahito: thanks
09:52:46 <priteau> i.e. review the existing drafts, identify what were the problems at the time, propose an implementation approach, and most importantly check what would be required to be added in other projects
09:52:58 <priteau> Thanks for volunteering masahito
09:52:59 <masahito> GeraldK: yes. we need to make some orders as action item or blueprint in blazar
09:53:44 <priteau> other features?
09:53:56 <masahito> #action masahito translates Promise requirement to blazar feature
09:54:18 <priteau> Horizon support: I think we can work from the patch we use in Chameleon (which was written by one of the Blazar contributors)
09:54:28 <priteau> I will find the URL and add it to Etherpad
09:54:33 <bertys> priteau: +1
09:54:40 <hiro-kobayashi> priteau: that's very nice!
09:54:46 <masahito> +1, the GUI looks nice
09:55:28 <masahito> if possible, I want to talk about PTG in remaining time.
09:55:32 <priteau> Ability to terminate a lease on demand: that's a small change we made in Chameleon, I can submit it when we have finalized the test framework fixes
09:55:52 <priteau> Ability to add / remove resources from a reservation: that's a bigger change because it doesn't fit well in the SQL model
09:55:59 <priteau> and will probably require API changes too
09:56:26 <priteau> #topic Project Teams Gathering (PTG)
09:56:49 <masahito> Does anyone in the meeting plan to go PTG?
09:57:14 <bertys> masahito: Maybe, need to check internally
09:57:18 <masahito> If most of us join it, we could unofficial meeting in there.
09:57:38 <masahito> because we don't have room for gathering.
09:57:53 <bauzas> FWIW, I'll attend the PTG
09:57:59 <hiro-kobayashi> masahito: +1
09:58:25 <hiro-kobayashi> I will attend if you guys will attend and have time to F2F meeting
09:58:51 <bauzas> there are 2 different timings for the PTG
09:58:58 <priteau> I had not planned to go, I am not sure if I could get approval for attending since I would probably go to Boston too
09:59:10 <bauzas> the 2 first days are intentionally for cross-project meetings
09:59:21 <bauzas> while the 3 last ones are for internal discussions
09:59:57 <bauzas> if someone would drop kind of a BoF session or a meetup around Blazar, probably the two first days are doable
10:00:03 <priteau> #info The first Project Teams Gathering (PTG) will be held in Atlanta, Feb 20-24, 2017
10:00:08 <masahito> bauzas: yes. if we have free time on any days we can gather.
10:00:13 <priteau> #info the 2 first days are intentionally for cross-project meetings, while the 3 last ones are for internal discussions
10:01:15 <masahito> ok. I'll send mail in openstack-dev which day works for us if we have meeting.
10:01:29 <priteau> It would be an ideal venue to present our requirements to other teams
10:02:09 <masahito> priteau: right.
10:02:24 <masahito> btw, we're running out time.
10:02:38 <priteau> masahito: you're taking ownership of organizing meeting there?
10:02:42 <GeraldK> priteau: +1. i will check if bertys or I can join
10:02:56 <masahito> priteau: if we have.
10:03:16 <priteau> ok
10:03:40 <priteau> We're out of time, thanks everyone!
10:03:43 <priteau> #endmeeting