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

Weekly Meeting 2016 10 20

Jump to bottom
Kristen Carlson Accardi edited this page Oct 20, 2016 · 2 revisions

Agenda

##Minutes

#ciao-project: Weekly_meeting

Meeting started by kristenc at 16:00:46 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-10-20-16.00.log.html .

Meeting summary

Meeting ended at 16:42:53 UTC.

Action Items

Action Items, by person

  • UNASSIGNED
    • (none)

People Present (lines said)

  • kristenc (80)
  • rbradford (25)
  • markusry (23)
  • jvillalo (14)
  • tcpepper1 (12)
  • ciaomtgbot (3)
  • david-lyle_ (1)
  • obedmr (1)

Generated by MeetBot_ 0.1.4

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

###Full IRC Log

16:00:46 <kristenc> #startmeeting Weekly_meeting
16:00:46 <ciaomtgbot> Meeting started Thu Oct 20 16:00:46 2016 UTC.  The chair is kristenc. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:46 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:46 <ciaomtgbot> The meeting name has been set to 'weekly_meeting'
16:00:54 <kristenc> #topic role call
16:01:06 <kristenc> 0/
16:01:09 <jvillalo> o
16:01:17 <markusry> o/
16:01:33 <tcpepper1> o/
16:01:35 <obedmr> o/
16:01:42 <david-lyle_> o/
16:01:47 <rbradford> o/
16:03:50 <kristenc> ok, let's get started now.
16:03:55 <kristenc> #topic opens
16:04:01 <kristenc> anyone?
16:04:42 <jvillalo> Hi, just one
16:04:55 <kristenc> jvillalo, go ahead
16:05:11 <jvillalo> I was looking into pagination earlier, and noticed we don't pagination enabled for listing volumes functionality
16:05:27 <kristenc> yes, true.
16:05:52 <jvillalo> today is not a big deal, however in use cases that a user might create a lot of volumes it will start affecting the experience badly in the ui
16:05:52 <kristenc> not because we hate pagination, but because its just yet another not done yet item.
16:06:20 <kristenc> jvillalo, agree - can you file an issue to remind us to get this done?
16:06:28 <jvillalo> understood, anyways I created an issue to keep track of it it's #702
16:06:37 <kristenc> oh - great, you are on top if it.
16:07:06 <kristenc> jvillalo, it will get prioritized along with all the other stuff we're doing this sprint.
16:07:24 <kristenc> is there anything else?
16:07:40 <jvillalo> Of course, thanks kristenc, just wanted to let everyone know, no more opens from me
16:08:25 <kristenc> jvillalo, will you do me a favor and also file one for images if it's not done yet?
16:08:49 <jvillalo> Sure, I can do that
16:09:12 <kristenc> ok - let's move on.
16:09:24 <rbradford> fyi, i've been having with issues with github this afternoon. changes being really slow and right now i just got a 404 on PR i had just commented on. so we might have issues during bug scrub
16:09:40 <kristenc> #info - pagination needs to be supported for all our -list commands.
16:10:02 <kristenc> rbradford, ok, let's see how it goes.
16:10:07 <kristenc> #topic bug triage
16:10:13 <kristenc> #link https://github.com/01org/ciao/issues?utf8=0.000000E+002    16:11:10 <kristenc> markusry, 670 is the oldest not prioritized.
16:11:34 <markusry> Right this is an old one.
16:11:46 <kristenc> markusry, I read this as performance related, which I think makes it a p3?
16:11:50 <markusry> Not actively working on it right now
16:11:51 <markusry> Agreed.
16:12:17 <markusry> I have a patch but haven't found a limit that works well on all clusters
16:12:34 <kristenc> next non-prioritized one is 673
16:12:36 <kristenc> https://github.com/01org/ciao/issues/673
16:13:29 <tcpepper1> feels like it could be quick (I could be naive) and is one I'd like to get done in the next two weeks
16:13:33 <kristenc> my opinion is that it's a p2. I make it not a p3 because although it's really just about how long we have to wait for a command to complete, it's very noticable.
16:14:16 <kristenc> tcpepper1, i am not sure it will be quick - the main tricky part will be how to handle errors properly in this case.
16:14:49 <markusry> Also, will it effect the UI
16:14:50 * tcpepper1 assumed initial implementation punts to the user
16:15:08 <tcpepper1> for error recovery...the thing doesn't come available, they delete it and retry
16:15:16 <kristenc> markusry, the impact will be that we can fail asynchronously.
16:15:17 <tcpepper1> how to give them actionable failure data though...
16:15:28 <kristenc> which we already can of course due to launcher.
16:15:31 <markusry> But does that require extra code in the UI to cope with this?
16:15:42 <kristenc> it's just now we can fail asynchronously inside of controller as well.
16:16:25 <kristenc> markusry, I don't think so - it already anticipates failures from launcher.
16:16:38 <kristenc> and we will just need to make sure to use the event log for failure messages.
16:16:40 <markusry> Okay, great
16:17:06 <kristenc> I'll make a note of wanting error messages in the event log and mark it p2.
16:18:31 <kristenc> https://github.com/01org/ciao/issues/674
16:18:41 <kristenc> I think there's something wrong with our event logs somehow.
16:18:58 <kristenc> in this particular case, launcher would have failed to launch, and sent back a failure message.
16:19:08 <kristenc> indeed, I've duplicated this problem and seen the error being reported.
16:19:20 <kristenc> but asking for the event logs from ciao-cli results in nothing.
16:19:30 <markusry> I think maybe the confusion is with the asynchronous nature of the instance start
16:19:55 <kristenc> yes - the start is asynchronous and can fail.
16:20:03 <markusry> Maybe we just need to change the output from ciao-cli
16:20:07 <rbradford> are failed instances show in ciao-cli instance list ?
16:20:19 <kristenc> we did on master have an issue where storage creation could fail and was not acted upon. but that is addressed in PR #700
16:20:21 <markusry> From instance created to instance creation scheduled
16:20:43 <tcpepper1> we have "pending"
16:20:52 <kristenc> tcpepper1, no - pending isn't failed.
16:20:53 <tcpepper1> in the webui anyway...I forget what the cli shows
16:21:06 <kristenc> the flow for failure is that we delete the instance and log the failure.
16:21:18 <kristenc> there should be a log entry for it.
16:21:22 <tcpepper1> pending == creation scheduled markusry was saying?
16:21:24 <kristenc> but I think there's something wrong.
16:21:38 <kristenc> yes - pending means creation scheduled.
16:22:03 <kristenc> the possible states are listed in the payloads package I believe.
16:22:05 <markusry> The thing is pending instances may never get created
16:22:17 <markusry> If launcher doesn't like them it deletes them
16:22:20 <rbradford> i think failed instances might have to appear in ciao-cli instance list otherwise the user might feel that their instance has evaporated
16:22:35 <kristenc> markusry, if launcher deletes them, it sends controller an event.
16:22:40 <kristenc> then controller deletes them.
16:22:42 <markusry> Yes, it sends an error
16:23:08 <kristenc> rbradford, we had this discussion many months ago and decided not to leave them there.
16:23:13 <tcpepper1> does controller delete them so they no longer list?  or do they move from pending to some dead state?
16:23:16 <rbradford> kristenc, okay
16:23:19 <kristenc> which is why we have the error log.
16:23:20 <tcpepper1> aaah I recall that
16:23:41 <markusry> But I think the bug still has a point
16:23:48 <tcpepper1> so if the error log isn't complete, the instance seems to have evaporated
16:23:49 <rbradford> but there is no way to a user to know that the instance creation has failed
16:23:52 <kristenc> markusry, yes - I think there's a problem with the error log.
16:23:53 <markusry> ciao-cli is claiming that an instance has been created, when it hasn't
16:24:06 <markusry> yet
16:24:12 <rbradford> maybe the API should be async BUT ciao-cli should spin waiting for a response or not
16:24:13 <kristenc> markusry, ciao-cli doesn't know the instance has failed to be created.
16:24:25 <kristenc> it's the nature of the cli
16:24:27 <markusry> I know, so it shouldn't say instance created
16:25:00 <tcpepper1> (/me must depart)
16:25:45 <kristenc> markusry, do you want to just change the wording on the message from ciao-cli?
16:26:10 <markusry> Assuming that the error gets logged into the event log, that might be okay.
16:26:31 <kristenc> markusry, yes - I think that's the real bug, but we'd need to redo the test and confirm that no error was logged.
16:26:48 <markusry> I'm not sure what else we could do apart from having ciao-cli wait until the instance actually appears in stats
16:26:57 <kristenc> markusry, I don't think we should do that honestly.
16:27:05 <markusry> No me neither.
16:27:15 <rbradford> what do the Amazon/Google command line tools do?
16:27:27 <kristenc> let me make a note to change the wording and mark this one a p3?
16:27:58 <rbradford> maybe it needs a pointer to run "ciao event list" to check for a response ?
16:28:56 <kristenc> rbradford, we can leave the implementation details for later.
16:28:59 <kristenc> let's move on.
16:29:02 <rbradford> ok
16:29:04 <kristenc> next bug is https://github.com/01org/ciao/issues/675
16:29:23 <kristenc> there is an outstanding work item for controller called "workload validator"
16:29:40 <kristenc> it's a larger feature that is on our roadmap, but not prioritized right now.
16:30:00 <kristenc> this issue probably is asking for a workload validator.
16:30:02 <kristenc> right?
16:30:33 <rbradford> *nod*
16:31:01 <kristenc> ok - so in this case it will be resolved as part of the larger scoped project we have in the nebulous future.
16:31:02 <rbradford> but in particular with storage there are more complexities we can check earlier and error out to the user earlier
16:33:03 <kristenc> in the meanwhile, we are designed to fail asynchronously and so imo this is a p3 bug.
16:34:14 <rbradford> ack
16:35:07 <kristenc> ok - 676
16:35:41 <kristenc> i seem to remember solving instance ordering issues for jvillalo
16:35:49 <kristenc> let me see if I can remember what we did.
16:36:27 <jvillalo> yeah I think that was around march
16:36:33 <kristenc> ah - they are returned sorted by instance ID.
16:37:28 <rbradford> kristenc, nope they come staright from the map
16:37:38 <rbradford> kristenc, so no sorting and it can change between runs
16:37:48 <kristenc> rbradford, which api are you talking about?
16:38:24 <kristenc> sort.Sort(types.SortedInstancesByID(instances))
16:38:33 <rbradford> kristenc, ah, sorry, it was volumes that were unstable
16:38:41 <rbradford> kristenc, i've written patches for both today
16:39:07 <markusry> I'm afraid I need to drop out too.
16:39:11 <markusry> Sorry.
16:39:25 <kristenc> rbradford, ok - just by default can you discuss with jvillalo whether he wants to keep the current sorting behavior for instances?
16:39:36 <rbradford> kristenc, i sort client side
16:39:39 <rbradford> so it doesn't matter.
16:39:48 <kristenc> ah - ok, that's easier.
16:40:03 <rbradford> shall we stop. no mark or tim
16:40:18 <kristenc> rbradford, agreed - we should reschedule this to a time when we have everyone here.
16:40:32 <jvillalo> One comment, I think we will need backend sorting in volumes also
16:40:42 <jvillalo> not sorting might impact on paging
16:40:56 <kristenc> jvillalo, yes - probably anything we do for instances needs done for volumes.
16:41:09 <kristenc> jvillalo, can you file an issue to remind us to take care of that?
16:41:16 <rbradford> jvillalo, in ciao-cli i sort after merging the pages, which is what the cli does anyway but yes makes sense
16:41:44 <jvillalo> I'll file one for images to
16:41:47 <jvillalo> sure
16:41:50 <kristenc> rbradford, I'm going to just mark this a p2 even though you've worked on it already.
16:41:55 <kristenc> jvillalo, thank you.
16:42:10 <rbradford> jvillalo, how does the UI present the data, does it sort it again?
16:42:10 <jvillalo> yw
16:42:21 <kristenc> this way we know we discussed it.
16:42:22 <rbradford> jvillalo, or present it in instance name sort order?
16:42:26 <rbradford> kristenc, ack
16:42:39 <rbradford> jvillalo, /me confesses he's not tried the webui yet
16:42:49 <kristenc> #info - meeting ending early due to lack of participation.
16:42:50 <jvillalo> rbradford, no, UIs usually show it as they come, so apis need to be provide consistent sorting when listing large amounts of data

Weekly Meetings

Development

Architecture

Clone this wiki locally