Skip to content
This repository has been archived by the owner on Jul 16, 2020. It is now read-only.

Weekly Meeting 2016 07 14

Jump to bottom
Leoswaldo Macias edited this page Aug 4, 2016 · 9 revisions

Agenda

##Minutes

#ciao-project Meeting

Meeting started by AmyLee7 at 16:00:24 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-07-14-16.00.log.html .

Meeting summary

Meeting ended at 16:54:08 UTC.

Action Items

  • [done] leoswaldo will update the API wiki with API's not implemented
  • [wip] obedmr and leoswaldo will put together the list of candidate APIs for heat for the team
  • [done] leoswaldo will investigate automation using swagger and godoc
  • leoswaldo will update the API docs on the wiki to two sections: ciao apis and nova apis
  • tcpepper and markus_ will update issue 343 with suggested solutions [done]
  • team to scrub P3's [done]
  • tcpepper update issue 104 to sprint 3 [done]

Action Items, by person

  • leoswaldo
    • leoswaldo will update the API wiki with API's not implemented
    • obedmr and leoswaldo will put together the list of candidate APIs for heat for the team
    • leoswaldo will investigate automation using swagger and godoc
    • leoswaldo will update the API docs on the wiki to two sections: ciao apis and nova apis
  • obedmr
    • obedmr and leoswaldo will put together the list of candidate APIs for heat for the team
  • tcpepper
    • tcpepper and markus_ will update issue 343 with suggested solutions
    • tcpepper update issue 104 to sprint 3
  • UNASSIGNED
    • team to scrub P3's

People Present (lines said)

  • AmyLee7 (52)
  • tcpepper (43)
  • kristenc (41)
  • markus__ (28)
  • leoswaldo (24)
  • obedmr (11)
  • albertom (5)
  • mcastelino (5)
  • mrkz (4)
  • ciaomtgbot (2)
  • _erick0zcr (1)

Generated by MeetBot_ 0.1.4

.. _MeetBot: http://wiki.debian.org/MeetBot

###Full IRC Log

16:00:24 <AmyLee7> #startmeeting
16:00:24 <ciaomtgbot> Meeting started Thu Jul 14 16:00:24 2016 UTC.  The chair is AmyLee7. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:32 <AmyLee7> #link https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-07-14
16:00:39 <kristenc> o/
16:00:42 <mcastelino> o/
16:00:44 <obedmr> mcastelino: I'm sorry I was out this morning, I just sent you an email with details about what I'm facing with the dummy interface
16:00:47 <obedmr> o?
16:00:50 <obedmr> o/
16:00:53 <leoswaldo> o/
16:00:53 <albertom> o/
16:00:55 <AmyLee7> o/
16:00:56 <_erick0zcr> o/
16:01:54 <markus__> o/
16:01:55 <AmyLee7> #topic opens
16:02:23 <mrkz> o/
16:02:39 <leoswaldo> I have one, about documentation
16:03:16 <AmyLee7> go for leoswaldo
16:03:37 <leoswaldo> During last days I've been documenting the status for CIAO's compute API
16:03:43 <leoswaldo> #link  https://github.com/01org/ciao/wiki/HTTPS-API
16:04:27 <leoswaldo> we should have docummented all APIs stuff for our future users, this way they know what we have they can use
16:04:36 <leoswaldo> and what is pending or in development
16:05:27 <kristenc> leoswaldo, these pending apis - how are you deciding whether they are ones we will support? are they ones that are required for rally?
16:05:39 <leoswaldo> I would like the team, if anybody creates a new API call compatible with OpenStack, not only of compute, to come to the wiki and update the stuff
16:05:42 <kristenc> I don't think it was ever our goal to fully support the compute api.
16:06:04 <leoswaldo> the pending ones are the ones openstack has that we dont
16:06:11 <kristenc> but do we need them?
16:06:21 <kristenc> i.e. - pending implies we are going to do them one day.
16:06:25 <kristenc> (implement them)
16:06:40 <leoswaldo> no, we dont need them, but in the future we'll be working on them
16:06:46 <kristenc> we will?
16:06:52 <kristenc> for example - cells?
16:06:55 <kristenc> we aren't going to do that.
16:07:07 <mcastelino> leoswaldo: how many of the pending do we need to run rally?
16:07:10 <obedmr> if we're planning to be officially compatible with OpenStack, we'll need them
16:07:23 <leoswaldo> we should. if we want users to use CIAO, our APIs should grow for  users
16:07:26 <kristenc> obedmr, I thought the rally stuff only required a subset of the apis?
16:07:29 <obedmr> it's a requirement for being Officially accepted
16:07:47 <kristenc> i think we decided last week to not go for big tent as well.
16:07:59 <leoswaldo> mcastelino: some of them, we are still in discovery for rally main scenarios
16:08:02 <obedmr> it's not exactly for big tent
16:08:13 <markus__> Is it for the conformance tool?
16:08:19 <obedmr> it's for being officially accepted as compatible
16:08:23 <leoswaldo> its not for big tent, its to provide support for its use
16:08:53 <obedmr> there are more API methods we'll need for cloud apps orchestration, not just for rally
16:09:32 <leoswaldo> these listed does not mean we have them, or we are planning to develop righ now, but we need to let the users know, what we have, not to expect them to dig into the code to figure out
16:10:08 <mcastelino> leoswaldo: to run a heat template. do we need all of the APIs
16:10:29 <obedmr> mcastelino: some of them, I'm on the path for getting the requirements
16:10:55 <mcastelino> if we can run rally and heat should it not meet most user's needs?
16:11:17 <kristenc> i think its the pending status. it sounds like a promise that we are going to get to these.
16:11:24 <kristenc> I'd rather just it said "not implemented".
16:11:27 <obedmr> not sure, if we'll choose Heat, but maybe on next week I'd be sending you the research I have. There are some cons about heat, so, I'm looking for other orchestration tools
16:11:39 <leoswaldo> no, because we just cover main scenarios
16:11:44 <kristenc> unless we know for sure we will implement them.
16:12:05 <albertom> leoswaldo: you could list all the apis, and then we can go one by one decide if it is really needed
16:12:12 <tcpepper> other tools aside, it would be good to share the list of candidate APIs for heat now so they're in our heads
16:12:14 <leoswaldo> kristenc: agree on the "not implemented" will update to it
16:12:20 <tcpepper> we've been talking about getting this list for a month or two
16:12:21 <albertom> like, this one is needed for orchestration, this one for rally, this one nobody uses it..
16:12:21 <albertom> etc
16:12:59 <markus__> Have we considered using something like Swagger so that we could automatically generate the docs from the code or a spec?
16:12:59 <obedmr> tcpepper: yes, I'll sync with leoswaldo for getting those required methods
16:13:17 <kristenc> markus__, I need to learn more about swagger. I saw that kubernetes uses it.
16:13:22 <AmyLee7> #action leoswaldo will update the API wiki with API's not implemented
16:13:28 <markus__> Yes, that's where I came across it.
16:13:42 <leoswaldo> albertom: that's a meeting that would involved the future of CIAO development
16:13:50 <kristenc> we should investigate it and see if it would work - I'd rather generate documentation from the code if possible.
16:14:08 <AmyLee7> #action obedmr and leoswaldo will put together the list of candidate APIs for heat for the team
16:14:08 <kristenc> to some extent - go doc could also be used.
16:14:10 <mrkz> +1 to autodocument from code
16:14:16 <markus__> There may be alternative specs as well.  Haven't investigated.
16:14:21 <kristenc> we could link to the godoc site from our wiki.
16:14:49 <AmyLee7> #info Swagger could automatically generate the docs from the code or a spec
16:14:53 <markus__> Write a swagger to godoc converter
16:15:00 <kristenc> hum.
16:15:11 <leoswaldo> ok, we'll investigate on automating that
16:15:15 <kristenc> cool.
16:15:45 <AmyLee7> #action leoswaldo will investigate automation using swagger and godoc
16:15:50 <markus__> Still, I like the wiki page as well.  it's the first time I've really grasped what we're missing.
16:15:56 <kristenc> i have one more comment regarding the compute apis.
16:16:10 <kristenc> this is one actually that's not just about documentation.
16:16:20 <kristenc> we mix our custom ciao apis with the openstack apis.
16:16:21 <markus__> There's a lot of Pendings
16:16:41 <kristenc> there are apis that have nothing to do with the openstack compute api spec 2.1 being presented as 2.1 apis.
16:16:46 <kristenc> this bugs me.
16:16:53 <kristenc> I wish we had done this differently.
16:17:13 <kristenc> at the least though - we should separate them in the documentation.
16:17:26 <mcastelino> kristenc: agree.. for example CNCI API's have nothing to do with Openstack and it may confuse people
16:17:31 <kristenc> yes.
16:17:50 <leoswaldo> actually
16:17:54 <kristenc> i wish we had presented the ciao apis on a completely separate port than the nova apis.
16:18:19 <leoswaldo> something I had planed for documentation is that for those we have only in CIAO, add a "special" link
16:18:26 <leoswaldo> where we documents its specs
16:18:44 <tcpepper> could we start with two sections in the docu:  ciao apis and nova apis.
16:18:58 <tcpepper> then split the code at least to top of file / bottom or file
16:19:08 <tcpepper> and push them further apart from there
16:19:30 <tcpepper> top of file / bottom of file becomes top/bottom+common
16:19:36 <tcpepper> the common starts to look like the abstraction layer
16:19:42 <leoswaldo> yeah, give a better picture of what is from both
16:19:59 <tcpepper> top/bottom+common "helpers"
16:20:04 <AmyLee7> #action leoswaldo will update the API docs on the wiki to two sections: ciao apis and nova apis
16:20:43 <kristenc> markus__, what is missing from the implemented apis doesn't imply a code gap neccessarily btw. the compute api has over 200 endpoints defined. we certainly don't need to implement all those.
16:20:45 <AmyLee7> tcpepper if there are further actions out of the suggestions you gave please capture as I am not following the remaining requests
16:20:58 <tcpepper> docu's the start
16:21:06 <markus__> kristenc: Okay, thanks
16:21:07 <kristenc> I would in all honestly prefer to just document what we *do* implement, and refer people to the openstack spec for anything else.
16:21:10 <leoswaldo> I would call them as tcpepper metioned  OpenStack Common apis and CIAO apis   or so
16:21:14 <tcpepper> we'll sit down and hash out implementation later
16:21:29 <leoswaldo> good recomendation for that one tcpepper
16:21:54 <AmyLee7> ok any additional opens this morning before we move on to scrubbing?
16:21:55 <tcpepper> kristenc: to the point of not mentioning the openstack ones?  or mention with no more than a list of api names and a link to the openstack docu?
16:22:43 <kristenc> tcpepper, I don't see the point in redocumenting a bunch of apis that we don't implement. If it's not on the "we implemented this" list, then implicitly it's not implemented.
16:23:11 <tcpepper> yes I agree
16:23:15 <tcpepper> I'm talking about the ones we do implement
16:23:28 <tcpepper> do we minimially list their names and leave the docu to the official docu?
16:23:59 <kristenc> for those I'd simply list the apis and methods exactly as they have with the addition of a link to the openstack spec corresponding api.
16:24:15 <leoswaldo> +1
16:24:17 <albertom> +1
16:24:25 <tcpepper> ok we're agreed
16:24:28 <mrkz> 1+ ^
16:24:31 <tcpepper> AmyLee7: let's scrub
16:24:35 <mrkz> please
16:24:42 <AmyLee7> k
16:24:53 <AmyLee7> #topic bugs
16:25:00 <AmyLee7> No P1
16:25:36 <AmyLee7> #link https://github.com/01org/ciao/issues/343 P2 assigned to markdryan
16:25:48 <AmyLee7> or markus_
16:26:04 <markus__> Yes, I came across this one the other day when testing on the cluster.
16:26:20 <markus__> It can prevent a cluster from resetting.
16:26:32 <markus__> Or a least one of the compute nodes.
16:27:56 <tcpepper> maybe have a helper goroutine that sends a result via a channel upon success and the 'main' caller selects on either the result from shutting down qemu or a timer?
16:28:18 <tcpepper> then you can just leave the loop that usually works fine, but have a higher level timeout on the attempt?
16:28:42 <markus__> I could do that or perhaps I can start checking the data returned from the socket as well
16:29:13 <markus__> But in any case, the current potentially endless loop isn't good.
16:29:17 <tcpepper> i wonder if it's not looping forever, and is actually blocked on the non-responsding socket
16:29:45 <markus__> Could also be that.
16:29:49 <tcpepper> socket read can return something, fail, or block
16:29:54 <markus__> I need to investigate further
16:29:57 <tcpepper> if qemu died somehow, my odds are on the latter
16:30:02 <AmyLee7> tcpepper and markus_ will you add your comments and suggestions in the issue?
16:30:06 <tcpepper> yep
16:30:33 <markus__> if qemu died, we'd be okay though as we'd get an error on the socket.  But maybe it's hung as you suggest.
16:30:51 <AmyLee7> #action tcpepper and markus_ will update issue 343 with suggested solutions
16:31:48 <AmyLee7> #link https://github.com/01org/ciao/issues/267 P2 assigned to markus_ this is scheduled for Sprint 2
16:32:47 <markus__> Yes, so P2 is probably okay for this as well.  It's only going to cause me problems, unless someone else vendors something
16:33:30 <markus__> Should be easy to fix.  Other ciao-vendor commands, the ones I've added more recently, work correctly in this regard.
16:33:50 <AmyLee7> #info issue 267 is still a P2 and scheduled for Sprint 2
16:34:12 <AmyLee7> next ones are also scheduled for Sprint 2 and have been discussed a few times
16:34:12 <markus__> I think I need to have another ciao-vendor day to get through some of these remaining issues.
16:34:28 <markus__> Yes, they were postpone from sprint 1.  Still haven't started to look at them yet
16:34:37 <AmyLee7> #link Issue 16 https://github.com/01org/ciao/issues/16 and Issue 17 https://github.com/01org/ciao/issues/17
16:35:08 <AmyLee7> markus_ do you need any help with looking at them?
16:36:03 <markus__> I suppose it depends on how much of the main Sprint2 features I work on
16:36:10 <markus__> i.e., Storage and Public IP.
16:36:58 <AmyLee7> ok we should take these into account as well when we are doing our 2nd map session next week
16:37:23 <markus__> Sounds good.
16:37:37 <AmyLee7> #info Issues 16 and 17 are still open and we will discuss in our map day next week
16:37:55 <AmyLee7> #link P3 issues- https://github.com/01org/ciao/issues?q=is0X0P+0open+is0X0P+0issue+label0X0P+0bug+label0X0P+0P3
16:38:37 <AmyLee7> can folks go through your individual P3's and make sure that they are the correct priority?
16:38:48 <tcpepper> sort-by-newest
16:38:53 <tcpepper> newest is 17 days old, next is 22
16:39:01 <tcpepper> in that range we'd all scrubbed them
16:40:03 <AmyLee7> #action team to scrub P3's
16:40:17 <tcpepper> given they're down in the 3/4 range,they're not getting attention and are very unlikely to have a new/different assessment
16:40:34 <AmyLee7> ok
16:41:00 <AmyLee7> #topic Issues left in sprint 1
16:41:51 <AmyLee7> #link https://github.com/01org/ciao/issues/99 assigned to tcpepper P1
16:42:49 <tcpepper> haven't started, still in ready state, will start soon.  sizing is small.
16:43:29 <AmyLee7> These 3 left are assigned to you as P1 tcpepper 99, 104- https://github.com/01org/ciao/issues/104 and 235- https://github.com/01org/ciao/issues/235
16:44:16 <tcpepper> re: 235 I've been looking at that this week.  I should bump it past ready.
16:44:42 <tcpepper> re: 104 we've talked about pushing some of these detail scheduling options to the next sprint
16:44:53 <tcpepper> it's fanciness.  we need the basic usability items sooner.
16:44:57 <AmyLee7> #info issue 235 is currently being worked on
16:45:32 <AmyLee7> should we push #104 to sprint 2?
16:45:35 <tcpepper> my suggestion would be to defer 104 to next sprint and as a part of that one's planning, split it into a dozen tickets and prioritize them.  some will be chosen and some not
16:45:57 <tcpepper> sprint 3
16:46:03 <AmyLee7> #action tcpepper update issue 104 to sprint 3
16:46:07 <AmyLee7> ok
16:46:12 <tcpepper> or two?
16:46:15 <tcpepper> which is august?
16:46:18 <kristenc> sprint3 good - I was just going to complain about adding it to 2.
16:46:26 <AmyLee7> k sprint 3 it is
16:46:32 <tcpepper> ok 3 is what I intended
16:46:37 <AmyLee7> I just updated it
16:46:40 <tcpepper> the non-august one
16:46:43 <AmyLee7> k
16:46:49 <AmyLee7> that is sprint 3 and the update is done
16:46:54 <tcpepper> perfect thanks
16:47:10 <AmyLee7> that is all I had on the agenda but I do have one more open
16:47:20 <AmyLee7> IRC meetings
16:49:04 <tcpepper> ...?
16:49:05 <AmyLee7> Arjan's staff is now scheduled on top of this every week so I am not able to attend this. I was chatting to sameo and tcpepper and we discussed having the team rotate who runs the IRC meeting every week
16:49:42 <AmyLee7> I will make sure to check in on notes and will look to you to let me know if there are any issues or blockers that come up
16:49:44 <tcpepper> oh yeah totally.  imho we should run our meetings and report out to stakeholders the minutes and actions where we need their help or want to fyi them of something specific
16:49:57 <tcpepper> we can actively manage this
16:50:10 <kristenc> yes, not a problem
16:50:19 <AmyLee7> ok great! Thank you
16:50:33 <markus__> FIne with me too.  I'm not longer scared of ciaomtgbot
16:50:38 <kristenc> heh.
16:50:57 <AmyLee7> #info the team will run the IRC meetings moving forward
16:51:11 <AmyLee7> ok any other items before we end the meeting
16:51:31 <tcpepper> not from me
16:51:36 <kristenc> I am not going to be able to update the minutes today.
16:51:45 <kristenc> I can get to it tomorrow if nobody else has time.
16:52:20 <AmyLee7> kristenc: that works and if someone has time maybe they can help with it today, but I think it can wait until tomorrow
16:52:24 <markus__> kristenc: I can do it if you send me the logs
16:52:32 <markus__> Or whatever it is I need.
16:52:34 <kristenc> markus__, I'll paste you the link.
16:52:39 <markus__> Thanks
16:52:40 <kristenc> they get sent to a website.
16:52:47 <kristenc> I have a script in the wiki git that you can use.
16:52:50 * tcpepper has done it a few times too, but good for markus__ to see it
16:53:20 <AmyLee7> tcpepper do you want to show markus_ how to get to it?
16:53:49 <tcpepper> yep will do
16:54:01 <AmyLee7> cool! thank you

Weekly Meetings

Development

Architecture

Clone this wiki locally