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

Weekly Meeting 2016 06 09

Jump to bottom
Kristen Carlson Accardi edited this page Jun 9, 2016 · 8 revisions

Agenda

  • opens (5 minutes)
  • Bug scrub (15 minutes)
  • Release process
    • Daily releases: incremental tags ? What's missing for our first release ?
  • Minimal configuration - 1st step
  • testutil package - tpepper

##Minutes

#ciao-project Meeting

Meeting started by sameo at 16:01:21 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-06-09-16.01.log.html .

Meeting summary

Meeting ended at 17:08:46 UTC.

Action Items

  • markusry or AmyLee7 to downgrade #16 and #17 to P2
  • kristenc to open an issue for compute endpoints return values
  • Amy look into how we can re-assign issues to other team members
  • leoswaldo to look at issue #98
  • tpepper will merge https://github.com/01org/ciao/pull/225 and open a sep. ticket for the .travis.yml change
  • tpepper to experiment with -race in travis and test-cases
  • kristenc to add as much information as possible about closed bugs in the release notes.
  • sameo to send an email to the ml about configuration

Action Items, by person

  • AmyLee7
    • markusry or AmyLee7 to downgrade #16 and #17 to P2
  • kristenc
    • kristenc to open an issue for compute endpoints return values
    • kristenc to add as much information as possible about closed bugs in the release notes.
  • leoswaldo
    • leoswaldo to look at issue #98
  • markusry
    • markusry or AmyLee7 to downgrade #16 and #17 to P2
  • sameo
    • sameo to send an email to the ml about configuration
  • tpepper
  • UNASSIGNED
    • Amy look into how we can re-assign issues to other team members

People Present (lines said)

  • sameo (110)
  • tpepper (86)
  • kristenc (57)
  • AmyLee7 (33)
  • markusry (30)
  • leoswaldo (6)
  • ciaoslackbridge (4)
  • mcastelino (4)
  • obedmr (4)
  • arjan_work (3)
  • ciaomtgbot (2)
  • mrkz (1)
  • chamings (1)

Generated by MeetBot_ 0.1.4

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

###Full IRC Log

16:01:21 <sameo> #startmeeting
16:01:21 <ciaomtgbot> Meeting started Thu Jun  9 16:01:21 2016 UTC.  The chair is sameo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:21 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:32 <AmyLee7> o/
16:01:37 <mcastelino> o/
16:01:42 <markusry> o/
16:01:47 <kristenc> o/
16:01:49 <tpepper> o/
16:01:54 <chamings> /o/
16:01:54 <sameo> o/
16:02:11 <obedmr> o/
16:02:12 <mrkz> o/
16:02:40 <sameo> #link https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-06-09
16:02:48 <sameo> Hi everyone, let's start with opens
16:02:54 <sameo> #topic Opens
16:03:10 <tpepper> I'd like to get a little more info on the config stuff...what's the merge plan, AR's remaining, etc.
16:03:16 <sameo> If you want to add something to the agenda, or modify it, please go ahead.
16:03:22 <sameo> tpepper: Yes, I added that to the agenda.
16:03:37 <tpepper> save?
16:03:45 <tpepper> oh n/m...last item
16:03:49 <sameo> yep.
16:04:09 <tpepper> my brain read single-machine not minimal config
16:04:14 <sameo> :)
16:04:55 <sameo> Any other opens ?
16:05:23 <tpepper> I should give ya'll a heads up on the testutil stuff I'm finishing up
16:05:39 <sameo> tpepper: Good point, let me add that to the agenda.
16:05:59 <kristenc> the 23rd of June we will be meeting at 8am Pacific time instead of the usual 9am.
16:06:03 <sameo> #info tpepper to talk about the testutil progress.
16:06:16 <kristenc> also, I setup a google calendar for public consumption of our meeting times.
16:06:44 <sameo> #info 2016/06/23 ciao weekly meeting postponed by one hour: 9am PST instead of 8am
16:06:55 <sameo> kristenc: Do we have a link for that ?
16:07:11 <tpepper> sameo: other way around...it's an hour earlier than normal
16:07:22 <tpepper> 8am PST instead of 9am
16:07:27 <kristenc> https://calendar.google.com/calendar/embed?src=0bfvtgeodivn9qnsv867ojlv68                                       0roup.calendar.google.com&ctz=America/Los_Angeles
16:07:50 <sameo> #info 2016/06/23 ciao weekly meeting at  8am PST instead of 9am (not 9am instead of 8am)
16:08:02 <sameo> #link https://calendar.google.com/calendar/embed?src=0bfvtgeodivn9qnsv867ojlv68                                       0roup.calendar.google.com&ctz=America/Los_Angeles
16:08:14 <tpepper> alternatively, iCal usable google #link https://calendar.google.com/calendar/ical/0bfvtgeodivn9qnsv867ojlv68                                       0roup.calendar.google.com/public/basic.ics
16:08:19 <sameo> thanks tpepper
16:08:28 <sameo> #link https://calendar.google.com/calendar/ical/0bfvtgeodivn9qnsv867ojlv68                                       0roup.calendar.google.com/public/basic.ics
16:09:28 <sameo> Next topic then...
16:09:35 <sameo> #topic bug scrub
16:09:47 <sameo> AmyLee7: How do you want to proceed here ?
16:10:02 <AmyLee7> lets go through P1 and see if we have time for P2
16:10:12 <kristenc> how many minutes are we allocating?
16:10:31 <AmyLee7> 15?
16:10:52 <sameo> Ok.
16:10:53 <tpepper> are we going from the list at https://waffle.io/01org/ciao
16:11:07 <sameo> #link https://waffle.io/01org/ciao
16:11:08 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://waffle.io/01org/ciao> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:11:12 <AmyLee7> its hard for me to sort them on there
16:11:20 <AmyLee7> #link https://github.com/01org/ciao/issues?q=is0X0P+0open+is0X0P+0issue+label0X0P+0bug+label0X0P+0P1
16:11:36 <tpepper> I haven't figured a good way to sort on github...is there a trick there?
16:11:45 <AmyLee7> now we have labels
16:11:57 <sameo> tpepper: It's gerrit-like afaiu
16:12:04 <AmyLee7> I sorted by label bug and label P1
16:12:15 <sameo> AmyLee7: Leoswaldo is working on issue #209
16:12:26 <tpepper> more select than sort, but ok...I wanted to select by label bug and sort by label P*
16:12:32 <tpepper> not seeing how to do that
16:12:34 * kristenc would like to note that there are some issues not labelled either bug or enhancement.
16:12:48 <sameo> #info leoswaldo is working on https://github.com/01org/ciao/issues/209
16:13:22 <sameo> markusry: What's your status on the other 2 P1s ?
16:13:29 <kristenc> should we be using the "in progress" tag to indicate that someone is working on a bug?
16:13:33 <markusry> They're both related
16:13:40 <AmyLee7> kristen: yes
16:13:47 <markusry> It's work that never got finished when I was implementing docker
16:13:57 <sameo> #info some issues not labelled either bug or enhancement
16:14:01 <markusry> right now launcher ignores the resources it's passed when starting a docker container
16:14:01 <tpepper> if you shift it to in progress on waffle does it add that tag?
16:14:19 <markusry> And I'm not sure the cpu resource usage for containers is correct if that container has mulitple processes
16:14:19 <AmyLee7> tpepper: good question
16:14:24 <sameo> #info issues #16 and #17 are related
16:14:29 <AmyLee7> markusry: are they stoppers?
16:14:30 <markusry> That's what these bugs are.  I haven't started yet
16:14:43 <markusry> No.  You can still launch containers
16:14:44 <sameo> #info markusry has not started yet
16:14:55 <sameo> markusry: should we downgrade to P2 ?
16:15:03 <markusry> sounds good to me.
16:15:08 <sameo> #info #16 and #17 are not blockers
16:15:10 <kristenc> I can't shift anything - maybe I only have read access to the waffle board.
16:15:29 <sameo> #action markusry or AmyLee7 to downgrade #16 and #17 to P2
16:15:44 <AmyLee7> sameo: done
16:16:16 <sameo> thanks AmyLee7
16:16:35 <sameo> AmyLee7: Should we look at P2s ?
16:16:36 <AmyLee7> lets go through P2
16:17:04 <AmyLee7> #link https://github.com/01org/ciao/issues/163
16:17:16 <AmyLee7> markusry: this one is yours as well
16:17:43 <sameo> #link https://github.com/01org/ciao/issues?utf8=0.000000E+002    16:17:44 <markusry> Yes, that's a quick fix.
16:17:57 <markusry> One for the don't do this in go presentation as well
16:18:21 <markusry> Doesn't block but means we can't profile launcher until it's fixed
16:18:56 <markusry> Maybe a P3 then?
16:18:57 <sameo> #info issue #163 is a quick fix. Doesn't block but means we can't profile launcher until it's fixed
16:19:06 <kristenc> sounds like a p3 to me.
16:19:16 <sameo> yep.
16:19:22 <AmyLee7> updated
16:19:35 <sameo> #info issue #163 downgraded to P3
16:20:20 <AmyLee7> #link https://github.com/01org/ciao/issues/158 kristenc
16:20:58 <sameo> AmyLee7: Leoswaldo is working on #158
16:21:02 <kristenc> AmyLee7, this is one I don't have the bandwidth for. I expect this to be a problem if we are trying to be correct wrt the compute api expected responses.
16:21:24 <sameo> kristenc: Leo has a fix for it, it seems.
16:21:36 <sameo> I wish we could assign issues to other people..
16:21:37 <AmyLee7> what is leoswaldo's name in git
16:21:47 <kristenc> sameo: all the error values returned from all the compute endpoints needs to be audited and fixed.
16:21:55 <kristenc> as we very commonly return just 500
16:22:13 <sameo> kristenc: Agreed. Do we have an issue for that ?
16:22:16 <obedmr> AmyLee7: it's leoswaldo
16:22:19 <kristenc> should I enter a generic issue for that, or just let them come up as they get discovered?
16:22:26 <sameo> AmyLee7: I don't know. Maybe obedmr knows ?
16:22:36 <obedmr> leoswaldo
16:22:42 <sameo> #info Leoswaldo is leoswaldo in github
16:22:43 <AmyLee7> sameo: we can re-assign, but leoswaldo is not showing up
16:23:03 <obedmr> maybe it's because we're not added as team members in the github project
16:23:04 <sameo> AmyLee7: Only people with write access show up ?
16:23:14 <AmyLee7> I can only assign to 10 people
16:23:24 <sameo> kristenc: A generic issue would make sense.
16:23:49 <sameo> #action kristenc to open an issue for compute endpoints return values
16:23:54 <kristenc> #link https://github.com/01org/ciao/issues/234
16:23:54 <tpepper> a generic issue...for compute api compatibility?
16:24:26 <kristenc> this one was just for error value returns.
16:24:29 <tpepper> that's a __broad__ one, but ok
16:24:30 <sameo> #info compute endpoints most often return 500 while they should comply with openstack compat for returned values.
16:24:53 <tpepper> arguably if we either return compatible data or a compatible error value...that's compatibility right?
16:25:12 <tpepper> ie: getting all the non-data-backed bits to return a reasonable error is first level compatibility
16:25:13 <sameo> tpepper: Sure. Error values would be a subset of it.
16:25:41 <kristenc> I can edit it if you want it to be more broad than just the error value auditing. I called it out specifically because it's something that's easy to ignore.
16:25:52 <kristenc> (obviously - since we did :) )
16:25:52 <sameo> #info leoswaldo has a potential fix for issue #163
16:26:06 <tpepper> is there a spec option besides 500?  something less than error?  to represent no-data but success?
16:26:23 <kristenc> tpepper, the error values returned are somewhat defined.
16:26:25 <tpepper> or is that part of what's going on in these...eg: the return an empty list instead of nill?
16:26:27 <AmyLee7> #action Amy look into how we can re-assign issues to other team members
16:26:47 <kristenc> for example - 401 for non authorized or what have you.
16:26:50 <sameo> tpepper: Yes, they're more precisely defined than 'always 500' :)
16:26:51 <tpepper> anyway we should move on for time
16:26:58 <markusry> Do any of the compliance tools check the errors?
16:27:30 <AmyLee7> time check
16:27:32 <tpepper> hola leoswaldo we're just talking about compute api error returns
16:27:51 <AmyLee7> we are at 15min for bug scrub
16:27:51 <tpepper> we have 5 more P2's to run through
16:27:53 <sameo> leoswaldo: Actually we started talking about issue #163
16:27:56 <leoswaldo> sorry, I was checking something about my care and insurance
16:28:10 <AmyLee7> ok lets go through them quickly
16:28:17 <sameo> AmyLee7: We can scrub a few more.
16:28:33 <leoswaldo> s/care/car
16:28:34 <AmyLee7> #link https://github.com/01org/ciao/issues/98 kristenc
16:29:50 <kristenc> that is one that I again don't have bandwidth for right now - I noticed it while I was reviewing code that there were some cases where compute api didn't check correctly for valid role. I think a more thorough testing of the apis for inappropriate usage would catch them. there might be more than one.
16:30:26 <kristenc> the unit test could be improved to catch this.
16:30:35 <AmyLee7> Does anyone want to take this one on?
16:30:37 <kristenc> test(s)
16:30:58 <sameo> #info kristenc noticed some cases where compute api didn't check correctly for valid role.
16:31:16 <sameo> AmyLee7: Maybe leoswaldo could work on it next ?
16:31:34 <AmyLee7> leoswaldo: ?
16:32:12 <leoswaldo> I could take look at it
16:32:27 <leoswaldo> I expect to complete 209 by today
16:32:36 <leoswaldo> so I'll have time to invest on that
16:32:40 <sameo> #action leoswaldo to look at issue #98
16:32:55 <kristenc> thanks leoswaldo - I think the compute_test.go tests are very perfunctory and could be improved on to catch things like this.
16:33:22 <leoswaldo> okas, may ping you if needed kristenc, thanks
16:33:29 <sameo> AmyLee7: Another P2 ?
16:33:30 <kristenc> yes - feel free.
16:33:43 <AmyLee7> #link https://github.com/01org/ciao/issues/26 markusry
16:33:46 <tpepper> re: https://github.com/01org/ciao/issues/26 iirc we'd meant to open an issue to add -race to .travis.yml.  In theory it's an easy 5character add, but I suspect we break merge criteria until we fix any existing races.  so...new issue for .travis.yml add gated on existing race fixes?
16:33:47 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://github.com/01org/ciao/issues/26> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:34:04 <tpepper> I can take that on since it somewhat meshes with races I've been spotting in my testutil/ work
16:34:07 <markusry> There's a PR for this
16:34:19 <markusry> https://github.com/01org/ciao/pull/225
16:34:24 <markusry> tpepper: Could you merge?
16:34:32 <sameo> #info a PR is opened for issue #26
16:34:54 * kristenc notes that tim and mark are now the gatekeepers
16:35:02 <tpepper> ok.  I'll do that.  and open a sep. ticket for the .travis.yml change
16:35:11 <tpepper> are people ok with having -race in the there?
16:35:19 <sameo> #info tpepper and markusry are the gatekeepers for the next 2 weeks.
16:35:39 <markusry> tpepper: It's more than a five character fix.   We'd need to add --race to test-cases
16:35:55 <tpepper> it doesn't pass the flags thru?
16:36:01 <markusry> Not all of them
16:36:05 <tpepper> ah ok
16:36:05 <sameo> tpepper: We can experiment and see how many breakages we get.
16:36:07 <AmyLee7> #action tpepper will merge https://github.com/01org/ciao/pull/225 and open a sep. ticket for the .travis.yml change
16:36:07 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://github.com/01org/ciao/pull/225> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:36:24 <tpepper> #action tpepper to experiment with -race in travis and test-cases
16:36:28 <kristenc> one of these days I'll implement that mute button for ciaoslackbridge.
16:36:49 <AmyLee7> #link https://github.com/01org/ciao/issues/17 markusry
16:37:17 <markusry> We already covered this
16:37:35 <markusry> It used to be a P1 15 minutes ago
16:37:42 <AmyLee7> ok #16 and #17 covered?
16:37:46 <markusry> Yep
16:37:47 <AmyLee7> #4?
16:37:53 <sameo> AmyLee7: yes, they used to be P1
16:38:05 <markusry> Haven't started on #4
16:38:06 <AmyLee7> yeah I thought it was the last two in the link, my bad
16:38:23 <sameo> #info markusry has not started on issue #4
16:38:36 <AmyLee7> ok thats all the P2's!
16:38:39 <sameo> markusry: Want to keep it as P2 ?
16:39:07 <markusry> It's probably a P3.  It's basically a file leak
16:39:19 <markusry> not file descriptor but disk space leak
16:39:47 <sameo> #info issue #4 downgraded to P3
16:40:03 <sameo> Let's move on then.
16:40:09 <sameo> #topic release process
16:40:23 <sameo> Do we agree we are going for daily, incremental tags ?
16:40:32 <kristenc> yes.
16:40:50 <sameo> #info ciao will do daily releases with incremental tags
16:40:57 <tpepper> yes.  [incremental tags ==>  "integer" (ala systemd)  1, 2, .. 158 .. n]
16:41:04 <kristenc> yes. an integer.
16:41:25 <sameo> #info ciao will do daily releases with incremental, integer tags (1, 2, ...n)
16:41:53 <sameo> So no major releases ?
16:42:08 <kristenc> not for now IMO.
16:42:22 <sameo> I'd agree.
16:42:40 <sameo> We can build a major release process if ever needed.
16:42:44 <tpepper> there may eventually be a need for some sort of promotion for users who demand a 6mo cadence, but we can cross that bridge if/when there's user demand
16:42:44 <kristenc> yep.
16:43:06 <kristenc> yes - we don't have hoards of people wishing we had 6 mo releases right now :).
16:43:16 <tpepper> in the meantime we have precedent elsewhere that shows it's possible to be successful without that :)
16:43:19 <sameo> #info No need for a major release process atm. Will define depending on user demand
16:43:26 <markusry> Will we add a found in release to our bugs going forward?
16:43:29 <tpepper> ci/cd ftw
16:43:48 <arjan_work> modern development practices ftw
16:43:56 <arjan_work> (and no waterscrumfall please)
16:44:04 <arjan_work> this is why people want cloud and containers anyway ;-)
16:44:18 <kristenc> markusry, we could - we will be adding which bugs were fixed to our release notes.
16:44:35 <kristenc> I could automate updating the bug with the release as well.
16:44:49 <tpepper> markusry: I prefer post-tagging the fixed-in-release
16:45:06 <tpepper> that's the more conclusive actionable one, imho
16:45:08 <sameo> markusry, kristenc: We should enforce using the 'Fixes:' commit tag to help us with that.
16:46:03 <kristenc> agree. none of this automation will work if we don't have good discipline around this.
16:46:26 <kristenc> I can find which bugs are closed. and which pull requests are merged. but to relate them will require a human.
16:46:43 <sameo> tpepper: How do you post tag ? Change the release note and commit after the fact ?
16:47:46 <sameo> #action kristenc to add as much information as possible about closed bugs in the release notes.
16:47:59 <tpepper> I'm assuming the release not is for a build and is looking at what is in that build vs. the prior.  Ie: it doesn't need to search for commits that say the have fixes targetted at the current release.  it simply finds what's there.  so the release notes are orthogonal.
16:48:34 <kristenc> sameo: I completed the release notes automation earlier in the week. it finds the closed issues and merged pull requests from last release to current.
16:48:43 <tpepper> in github, closed issues, once code is released with the fix, can be observed as fixed by the release and tagged as such.
16:48:58 <kristenc> it also includes a full changelog (one line commit msg)
16:49:05 <sameo> tpepper: so there would not be any need for post actions ?
16:49:07 <kristenc> of all changes from one to the other.
16:49:54 <sameo> #info kristenc completed the release notes automation. It finds the closed issues and merged pull requests from last release to current.
16:50:01 <kristenc> tpepper, we don't search for targetted by anything, just what actually made it.
16:50:02 <tpepper> sameo: it would be automatable.  I don't want to have to tag things up front with the release number I suspect will include the fix.  That would be manual and speculative.
16:50:11 <sameo> #info kristenc release notes automation also includes a full changelog
16:50:29 <kristenc> we can update the issue with the release it was closed in if we want to at the time the release was made.
16:50:38 <kristenc> the github api lets you modify the issue.
16:50:48 <kristenc> we can easily add a label.
16:50:48 <sameo> tpepper: Oh, I fully agree with that. But I wouldn't enjoy doing post tagging changes neither, even to release notes/changelog.
16:50:49 <tpepper> that's useful imho
16:51:16 <tpepper> closed issues can programmatically be tagged with the release that included their code
16:51:20 <sameo> kristenc: That would be neat.
16:51:30 <sameo> tpepper: That's great.
16:51:55 <tpepper> as a user when google finds a closed issue like mine, I want to see which newer release included the fix.  ie: motivation to test and move forward.
16:51:59 <sameo> #info closed issues should be tagged with the release that closed them.
16:52:06 <kristenc> ok - I will add this functionality. It might delay the release till monday. I was hoping to get it done by friday, but things are looking tight. I'm slowly making progress, but I'm trying to be thorough and it's taking time.
16:52:08 <tpepper> in a finite way versus always saying "retest on latest"
16:52:22 <tpepper> kristenc: go ahead and release now. this is a minor incremental improvement
16:52:25 <sameo> kristenc: You can add that as a second step.
16:52:49 <kristenc> ok, good. I'll add it after we successfully release release #1 :)
16:52:50 <tpepper> "can you try on latest" is a horrible thing to tell users.  it's synonymous with "we're unstable" and "go away"
16:52:52 <sameo> kristenc: Until you have that done, we can manually tag.
16:53:07 <kristenc> sameo: the first release is going to be horrible to do manually.
16:53:15 <kristenc> it has a *lot* of issues and pull requests.
16:53:36 <kristenc> I can tag it after the release process is over with a special script.
16:53:50 <sameo> kristenc: Ok with me.
16:53:54 <kristenc> it just doesn't have to be done as part of the release for the first release.
16:54:04 <sameo> Yes.
16:54:18 <sameo> folks, I have a meeting in 5mn...
16:54:19 <kristenc> but after that, that functionality will be part of my release automation.
16:54:41 <sameo> that leaves you with one day to implement that feature :)
16:55:02 <kristenc> no - I'll do it *after* the first release just this time :).
16:55:20 <kristenc> (rather than during the release)
16:55:42 <kristenc> in a nutshell, next week :)
16:55:42 <sameo> #info kristenc to push release automation scripts and add the closed issues tagging later on
16:55:59 <sameo> fair enough.
16:56:15 <sameo> tpepper: Do you want to go ahead with the testutil package ?
16:56:20 <tpepper> sure
16:56:26 <tpepper> lemme do a quick brain dump:
16:56:33 <sameo> #topic testutil package
16:56:38 <tpepper> my topic branch is underway at https://github.com/tpepper/ciao/tree/unittests/testutil
16:56:47 <sameo> tpepper: You have the last 4 minutes :)
16:56:57 <sameo> #link  https://github.com/tpepper/ciao/tree/unittests/testutil
16:56:58 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://github.com/tpepper/ciao/tree/unittests/testutil> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:57:09 <tpepper> there is an agent implementation there which knows how to be a basic AGENT, a NETAGENT, and I think (need to verify) an AGENT|NETAGENT
16:57:13 <tpepper> there is a controller implementation
16:57:19 <tpepper> and server
16:57:25 <tpepper> and...the gravy...a client-server test which runs a serve with a controller, agent and netagent passing ssntp commands/events from various sources and verifying the correct entities processed the commands/events along the way
16:57:33 <tpepper> This gives nearly 90 0.000000e+00st coverage in testutil/
16:57:41 <tpepper> It's not quite ready (I have a bug currently that causes ciao-controller to fail 'go test')
16:57:45 <tpepper> Once that's fixed, I'll use it to add full coverage to ciao-scheduler/scheduler.go and hopefully get 900sh coverage there too.
16:58:05 <tpepper> Then on to moving launcher and networking shifting to use this library test code instead of local similar test code.
16:58:14 <tpepper> which likely will need some help from mcastelino and markusry
16:58:28 <sameo> #info there is an agent implementation there which knows how to be a basic AGENT, a NETAGENT, and I think (need to verify) an AGENT|NETAGENT
16:58:29 <tpepper> oh and adding docu
16:58:41 <tpepper> I need a README.md describing the usage
16:58:46 <tpepper> it's fairly straight forward
16:58:48 <sameo> #info tpepper to use testutil  to add full coverage to ciao-scheduler/scheduler.go and hopefully get 900sh coverage there too.
16:58:52 <mcastelino> tpepper: One question.. how do we verify operations where there is currently no response
16:58:59 <kristenc> thanks - this is going to be super useful..
16:59:09 <tpepper> mcastelino: can you describe more what you need?
16:59:21 <markusry> I don't really understand what would need to change in launcher.
16:59:55 <sameo> #info tpepper needs to add docu, README and then migrate networking and launcher to use testutil
17:00:04 <mcastelino> tpepper: In case of https://github.com/tpepper/ciao/blob/master/payloads/tenantadded.go for example... there is response back from the CNCI agent saying it processed the message
17:00:04 <tpepper> markusry: depends on if you start writing something for a test driver on top of launcher, or wait a few days. :)
17:00:39 <markusry> tpepper: So in launcher's unit tests I'm abstract the ssntp interface
17:00:56 <markusry> So there is not ssntp done in the unit tests right now.
17:01:02 <tpepper> ok
17:01:04 <kristenc> you only need it if you want to use ssntp at all in your unit testing.
17:01:35 <kristenc> for example - I can't get very good code coverage without using my ssntp client code.
17:01:36 <tpepper> correct.  though there's also a set of constants and yaml's for shared usage.
17:02:08 <mcastelino> tpepper: I will switch to your code to test the CNCI Agent... I have my own fake scheduler for testing now
17:02:09 <tpepper> so even if you don't use ssntp to deliver it in your test, you don't need to define a START yaml (or every other one)
17:02:11 <markusry> Okay, I see.
17:02:42 <tpepper> so the way it works..if your test is sending something, you open a channel.  the test receiver will reply back via the channel, synchonously.
17:02:46 <tpepper> so you know it worked or not
17:02:52 <tpepper> despite ssntp being async
17:03:01 <sameo> #info testutil mostly useful if one needs to use ssntp in unit testing
17:03:02 <tpepper> kristenc implemented that nicely in her test code
17:03:11 <tpepper> thus me starting with hers
17:03:21 <tpepper> so:
17:03:26 <tpepper> 1) make channel
17:03:33 <tpepper> 2) call your function that does something
17:03:43 <tpepper> 3) await channel response from reciever of your function's something
17:03:52 <tpepper> where the receiver is in testutil/
17:04:01 <tpepper> and your function is...your function to be unit tested
17:04:09 <kristenc> you can force it fail as well - so you can make a failure response to your operation.
17:04:23 <kristenc> to make your error handling path be exercised.
17:04:36 <sameo> tpepper: That sounds like something I may be able to use in ssntp tests as well.
17:04:54 <tpepper> the 10    17:05:05 <tpepper> sameo: yes...I was saddened when I looked at your unit tests :)
17:05:12 <tpepper> and all of them
17:05:20 <sameo> tpepper: saddened ?
17:05:22 <tpepper> mine is bad, because I didn't have this
17:05:33 <tpepper> sameo: in terms of thorougness yes
17:05:56 <tpepper> we might have good code coverage, but I don't think it's good in terms of meaningfulness of the testing
17:06:15 <sameo> tpepper: the ssntp tests ?
17:06:18 <tpepper> yeah
17:06:30 <tpepper> from a unit test perspective ok
17:06:43 <sameo> Yes, I see what you mean.
17:07:09 <sameo> I guess ssntp functional testing is what other components unit tests do...
17:07:35 <sameo> folks, I really have to go, I'm already 7mn late for my next meeting.
17:07:42 <tpepper> I'm done!
17:07:49 <sameo> tpepper: Thanks a lot.
17:08:06 <markusry> tpepper: Thanks.
17:08:12 <sameo> tpepper: I'll send an email to the ml to descirbe what we're doing with configuration.
17:08:23 <tpepper> sounds good!
17:08:31 <sameo> #action sameo to send an email to the ml about configuration

Weekly Meetings

Development

Architecture

Clone this wiki locally