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

Weekly Meeting 2016 09 15

Jump to bottom
Kristen Carlson Accardi edited this page Sep 15, 2016 · 3 revisions

Agenda

##Minutes

#ciao-project: Weekly_Meeting

Meeting started by kristenc at 16:01:03 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-09-15-16.01.log.html .

Meeting summary

Meeting ended at 17:00:54 UTC.

Action Items

  • tcpepper to present on identity options by Oct. 6

Action Items, by person

  • UNASSIGNED
    • tcpepper to present on identity options by Oct. 6

People Present (lines said)

  • kristenc (94)
  • tcpepper1 (63)
  • markusry (53)
  • mcastelino (6)
  • sameo (5)
  • rbradford (3)
  • ciaomtgbot (3)
  • wdouglas (1)
  • david-lyle_ (1)

Generated by MeetBot_ 0.1.4

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

###Full IRC Log

16:01:03 <kristenc> #startmeeting Weekly_Meeting
16:01:03 <ciaomtgbot> Meeting started Thu Sep 15 16:01:03 2016 UTC.  The chair is kristenc. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:03 <ciaomtgbot> The meeting name has been set to 'weekly_meeting'
16:01:26 <kristenc> o/
16:01:50 <markusry> o/
16:02:16 <tcpepper1> o/
16:02:32 <david-lyle_> o/
16:02:54 <sameo> o/
16:03:15 <kristenc> it might be a short meeting today, as mexico is on holiday.
16:03:28 <kristenc> #topic Opens
16:03:33 <kristenc> anyone?
16:03:35 <markusry> I have one
16:03:39 <kristenc> go ahead.
16:03:46 <markusry> Gatekeeper schedule
16:04:00 <markusry> We need to update the wiki as there are currently no gatekeepers
16:04:02 <markusry> as of today
16:04:02 <kristenc> good one - I was going to bring this up.
16:04:08 <kristenc> markusry, I updated it this morning.
16:04:24 <kristenc> this week is Samuel and Manohar.
16:04:37 <kristenc> but I was going to check and see if sameo was still able to be a gatekeeper.
16:05:03 <sameo> kristenc: Not for now I'm afraid.
16:05:10 <tcpepper1> what do folks think about making the rotation a week longer?
16:05:10 <sameo> I wouldn't do a good job at it.
16:05:21 <tcpepper1> more time to get in the groove of the details of the current things flying by
16:05:35 <markusry> kristenc: Thanks
16:05:58 <kristenc> tcpepper1, I personally would not like an extra week. but we need to figure out what to do now that sameo can't be our second EU timezone gatekeeper.
16:06:05 <markusry> My neither.
16:06:21 <markusry> I've been spending about 200f my time on gatekeeping recently
16:06:33 <sameo> kristenc: rbradford could be my replacement ?
16:07:03 <kristenc> would he be familiar enough with the code to be able to be an effective gatekeeper?
16:07:45 <kristenc> another alternative is to abandon the plan of having a gatekeeper in EU timezone.
16:07:48 <tcpepper1> should at least start being an alternate...get stuck in
16:07:57 <tcpepper1> rbradford that is ^^
16:08:00 <sameo> kristenc: That's for him to tell, but it's a good forcing function...
16:08:10 * kristenc awaits rbradford comment.
16:08:30 <rbradford> my availability is going to be spotty next week at best, but i think this would a good learning experience.
16:08:32 <markusry> I can carry on doing it
16:09:36 <kristenc> we can have 3 people do it for the next 3 weeks - Rob, Manohar, and me.
16:09:47 <kristenc> 2 US, 1 EU (spotty at best).
16:10:06 <kristenc> markusry, you could tutor rbradford if needed.
16:10:10 <markusry> sure
16:10:24 <kristenc> are you in the same physical location?
16:10:42 <markusry> yes
16:10:50 <kristenc> great - then you can be his buddy :).
16:11:21 <markusry> I can indeed.
16:11:28 <kristenc> markusry, so do you want an extra US timezone person doing reviews, or would that be worthless to you?
16:12:15 <markusry> It might help.
16:12:27 <kristenc> ok - we'll do the 3 of us then.
16:12:46 <markusry> Okay.
16:12:50 <markusry> Great.
16:12:56 <kristenc> #agreed - Rob, Kristen, and Manohar will be gatekeepers next 2 weeks. Samuel will be removed from schedule.
16:13:09 <kristenc> Any other opens.
16:14:14 <markusry> We still have some random travis build failures
16:14:14 <kristenc> ok, let's get to our first agenda items, prioritizing new bugs.
16:14:31 <markusry> I entered a bug on one of them today
16:14:44 <kristenc> markusry, ok.
16:14:49 <markusry> related to the swagger stuff
16:14:55 <markusry> But there are still some unit test failures.
16:15:02 <markusry> Is anyone looking at these?
16:15:24 <kristenc> markusry, I am not - are the unit test failures captured in an issue somewhere?
16:15:25 <markusry> intermittent unit test failures I should say
16:15:41 <markusry> I don't think so.  Next time I see one I'll enter an issue
16:15:53 <kristenc> markusry, ok - that would be best.
16:16:15 <kristenc> #topic New Issues Prioritization
16:16:26 <kristenc> #link https://github.com/01org/ciao/issues?utf8=0.000000E+002    16:17:05 <kristenc> here are all the new issues entered this week. I thought maybe we should just make sure they are all labeled properly with bug or enhancement and have priorities and owners where applicable.
16:17:38 <kristenc> There's 14 - we had a busy week.
16:17:42 <tcpepper1> I added that query to the template agenda too...good to regularly do.  although the date will need updating
16:18:01 <kristenc> did you want to go oldest->newest or newest->oldest?
16:18:40 <tcpepper1> flip a coin :)
16:18:50 <kristenc> ok - I pick oldest->newest
16:18:55 <kristenc> #link https://github.com/01org/ciao/issues/537
16:19:39 * kristenc suggests P1 + enhancement
16:19:57 <tcpepper1> agree
16:20:46 <kristenc> I'm skipping the ones that already look complete.
16:20:53 <kristenc> #link https://github.com/01org/ciao/issues/543
16:20:59 <tcpepper1> k
16:21:23 * kristenc suggests P2 + bug
16:22:36 <tcpepper1> works for me
16:22:38 * kristenc takes silence as agreement.
16:22:45 * tcpepper1 adds note in the bug to add automation to watch these urls
16:22:57 <tcpepper1> would be nice to be informed that OpenStack has shifted
16:23:08 <kristenc> #link https://github.com/01org/ciao/issues/544
16:23:32 <tcpepper1> P1 bug
16:24:12 <tcpepper1> b/c we have as a fundamental that we're secure always
16:24:13 <kristenc> ok.
16:24:28 <tcpepper1> if we compromise on that...things creep in a negative way
16:24:49 <kristenc> as a P1 it needs an assignee.
16:24:59 <rbradford> enabling verification just worked when i turned it on against our cluster
16:25:19 <tcpepper1> the gap is in the single vm test scenario
16:25:28 <tcpepper1> that needs tweeked
16:25:46 <kristenc> who should own this bug.
16:25:52 <tcpepper1> rbradford: interested in taking it on?  w/ mcastelino1 guidance?
16:26:06 <rbradford> tcpepper1, yup
16:26:47 <mcastelino> rbradford: will work with you... we have to sort a TLS issue also with SSNTP with DNS resolution to really make things work cleanly on single VM
16:27:13 <kristenc> what component label should it get?
16:27:31 <tcpepper1> test-cases?
16:27:37 <tcpepper1> security?
16:27:54 <kristenc> I was going with configuration :).
16:28:01 <tcpepper1> ah that works too
16:28:06 <markusry> test-cases was intended to be for test-cases the exe that produces our nice unit tests logs
16:28:20 <tcpepper1> ooh indeed /me forgot about that
16:28:35 <kristenc> #link https://github.com/01org/ciao/issues/549
16:28:39 <tcpepper1> we ought to add a plain "testing" category
16:28:39 <markusry> Easily done.  The tool is badly named
16:28:53 * tcpepper1 proposed P3 / janitorial but it's markusry's to call
16:29:32 <kristenc> I'm with tcpepper1
16:29:38 <markusry> Yes, agreed.
16:29:58 <markusry> Everything still works without a fix for this.
16:30:10 <kristenc> #link https://github.com/01org/ciao/issues/554
16:30:18 <markusry> But if we do figure out how to fix it we can simplify the code and speed up hotplugged ceph volumes
16:30:37 <kristenc> I'm would do P2 enhancement for this one
16:30:51 <tcpepper1> 554's a performance / accuracy issue ...faster code, less races.  I'd go p1 or 2 enhancement
16:31:27 <tcpepper1> same with 555
16:31:41 <kristenc> I'm going to push for P2 simply for practicality sake - they have the required functionality, and I have a boatload of other stuff to work on that is actually *missing* functionality.
16:31:57 <tcpepper1> i hear you
16:33:42 <kristenc> #link https://github.com/01org/ciao/issues/559
16:34:05 <markusry> I think this needs to be fixed
16:34:15 <markusry> It's slowing down our builds and causing them to periodically fail
16:34:22 * kristenc votes bug + P1
16:34:26 <markusry> Me too.
16:35:02 <markusry> I assigned it to leoswaldo as he was working on the swagger stuff
16:35:08 <markusry> I'll work with him next week to get it fixed.
16:35:24 <kristenc> ok - I was just going to ask if next week was soon enough for you.
16:35:32 <tcpepper1> me too :)
16:35:51 <kristenc> #link https://github.com/01org/ciao/issues/560
16:36:01 <markusry> We could disable the swagger stuff until next week
16:36:14 <kristenc> markusry, ok - good idea.
16:36:22 <markusry> Okay, I'll send a PR for this.
16:36:35 * kristenc votes P1 for #560
16:37:22 <markusry> Couldn't they just upload smaller files in a loop?
16:37:27 <tcpepper1> do you see 560, 562, 563, 564 as a similar set? I was almost going to say janitorial, but p1 argues against that
16:38:02 <tcpepper1> markusry: they could
16:38:15 <kristenc> markusry, yes - I guess you are right.
16:38:21 <tcpepper1> but also depends on how we allocate...
16:38:24 <tcpepper1> do we reserve the space?
16:38:45 <tcpepper1> ie: could they just _start_ uploading 200G and "stall" and start more of those?
16:38:56 <tcpepper1> there's some pragmatic number we could assert is bigger than necessary
16:39:07 <tcpepper1> part of this is about the design thinking of evaluating inputs
16:39:26 <markusry> Okay.  No objections from me.  Would this be in the config file?
16:39:31 <mcastelino> tcpepper1: does the tenant not have a total image quota
16:39:43 <kristenc> mcastelino, it might, it might not.
16:39:52 <kristenc> limits are not enforced right now.
16:40:06 <mcastelino> vs defining a size per image... a total image limit may work better
16:40:07 <kristenc> but we can add them in - but the admin has to configure them.
16:40:24 <tcpepper1> we could do somethign as pragmatic, minimal as saying 40G with a BUG: notation next to it, open an issue to make it configurable/dynamic
16:40:33 <tcpepper1> draw the line in the sand as a starting point
16:40:55 <kristenc> just fyi - glance does have a max image size allowed.
16:41:04 <kristenc> not that we have to be the same, but just as an example.
16:41:06 <tcpepper1> the nicer thing about a simple limit is the code is quick
16:41:20 <kristenc> I wonder if ceph has a limit
16:41:32 <tcpepper1> would be nice to not have to do a query and maths to decide if there is space vs. the storage cluster current available and any quotas
16:41:54 <tcpepper1> ceph has at least an implicit limit by way of disk free
16:42:20 <kristenc> I was thinking a single block image limit.
16:42:59 <tcpepper1> i didn't see any when I looked a while back and some docu talked about it mostly depending on how much storage you pooled..ie: your physically available resources
16:43:17 <kristenc> well - we don't probably have time to solve the problem yet - let's focus on priority.
16:43:20 <tcpepper1> I was expecting to see them say there was a 2^32 or 2^64 or something limit
16:44:00 <tcpepper1> imho today the security / DoS impact is minimal
16:44:01 <kristenc> if you all feel this is more janitorial and not a security risk, I'll back off my P1 recommendation.
16:44:04 <tcpepper1> practically speaking
16:44:20 <tcpepper1> it is a security risk, but the impact versus our user base and overall storage usability is currently small
16:44:29 <tcpepper1> that will change over time if the bug remains in the backlog
16:45:23 <tcpepper1> P2 janitorial for now, and eventually bump it up if it hasn't been addressed as our storage implementation is flushed out
16:45:31 <kristenc> ok.
16:45:34 <tcpepper1> I'd put flushing out the implementation functionality as P1
16:45:43 <kristenc> how about a blanket statement on the input validation issues I entered?
16:46:10 <tcpepper1> yes..Imho P2 janitorial them for now
16:46:18 <kristenc> #562/563/564
16:46:26 <kristenc> these are specifically for uuid checking.
16:46:38 <kristenc> Note that I'm suggesting we accept only uuid v4 format.
16:46:51 <tcpepper1> I believe from glancing at the code we're coincidentally ok on the uuid ones currently, but better to enforce that we're always ok
16:47:06 <markusry> kristenc: There's a method in uuid that we can use
16:47:14 <markusry> to verify our UUIDs
16:47:24 <markusry> uuid.Parse
16:47:30 <tcpepper1> uuid v4 format looks fine to me
16:48:35 <tcpepper1> uuid.Parse doesnt' look like it checks v4 format specifically, but that's a trivial fix
16:49:01 <kristenc> markusry, I think we need to put the regex in the gorilla mux path definition.
16:49:27 <kristenc> that way it does the parsing for us - and will reject requests with the improper format with the correct http status code for free.
16:49:40 <markusry> kristenc: I see.
16:49:44 <markusry> fair enough
16:49:56 <markusry> But we still need to check the uuids in the payloads I guess
16:49:59 <kristenc> less code for us to maintain.
16:50:01 <tcpepper1> ah that's a nice approach...something bad is stopped earlier and with a http error response
16:50:30 <kristenc> markusry, I'm not sure.
16:50:53 <tcpepper1> in the payloads our data structures could be more strongly typed instead of just string type
16:51:24 <markusry> because none of this uuids are user specifiable?
16:51:28 <tcpepper1> I think they'd then unmarshall as the type's zero value if the yaml didn't include something that parsed as the type
16:51:43 <markusry> or the ones that are are already checked by the regexp
16:51:45 <markusry> ?
16:51:49 <kristenc> we have one last issue to triage: https://github.com/01org/ciao/issues/561
16:51:58 * wdouglas kicks rebase conflict
16:52:07 <kristenc> and a few ARs to check on, and only 10 minutes left in the meeting.
16:52:18 <tcpepper1> markusry: I think that depends on how we create the yaml.  today it's a mix of controller created (trustable) and user input in csv file.
16:52:27 <markusry> So this is similar to 549
16:52:37 <tcpepper1> when the workload definition is more "real"...we'll have to evaluate for trust level
16:52:50 <markusry> Basically, everything works but there's something in the implemenation I'm not happy about
16:52:53 <tcpepper1> 561 could be a P3 janitorial?
16:52:55 <kristenc> markusry, P3?
16:53:06 <markusry> I need to look closely into the QEMU code to see if we can do better
16:53:11 <markusry> Yes P3 is fine.
16:53:20 * tcpepper1 is hoping archana might find some useful tricks in qemu that we learn from
16:53:48 <markusry> Okay, I'll sync with her
16:54:05 <kristenc> ok, all our issues are scrubbed.
16:54:17 <kristenc> we have actions from last week to review.
16:54:22 <kristenc> #topic Prior week's actions
16:54:36 * tcpepper1 has not yet had time to look at identity.  and also noted the AR came w/o a due date.
16:54:45 <tcpepper1> when do we want this arch rough draft?
16:55:35 <kristenc> good question - imo I think if you could do it in the next 3 weeks that is soon enough. I would want us to have some time to discuss before the next sprint starts just in case we want to start on something then.
16:56:25 <kristenc> here's an easy one:
16:56:28 <kristenc> markusry to evaluate impact of moving to 1.7 and file issues
16:56:33 <kristenc> markusry, this is done, correct?
16:56:36 <markusry> Yes
16:56:38 <tcpepper1> ok I commit to Oct. 6 meeting presenting some on identity
16:56:40 <markusry> We're already on go 1.7
16:56:47 <markusry> and 1.6 is dropped
16:56:54 <tcpepper1> o/ :)
16:56:54 <kristenc> tcpepper1, thanks. I will update the action item.
16:57:14 <kristenc> #action tcpepper to present on identity options by Oct. 6
16:57:32 <kristenc> mcastelino to draft kubernetes architecture plan.
16:57:41 <kristenc> mcastelino, yours had no due date either.
16:57:45 <kristenc> what is reasonable?
16:59:06 <mcastelino> kristenc: I am still wading through kubenetes
16:59:11 <mcastelino> can we plan for end of next week
17:00:03 <kristenc> mcastelino, ok. 9/29 meeting for questions.
17:00:31 <mcastelino> I send out some notes earlier in the week on how to setup minikube... as a next step I will send a document that specifies how to setup kubernetes from scratch using ciao as the underlay (manual setup)
17:00:31 <kristenc> we are done then.
17:00:49 <kristenc> thanks.

Weekly Meetings

Development

Architecture

Clone this wiki locally