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

Weekly Meeting 2016 11 10

Jump to bottom
Kristen Carlson Accardi edited this page Nov 10, 2016 · 2 revisions

Agenda

##Minutes

#ciao-project: weekly meeting

Meeting started by kristenc at 17:03:36 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-11-10-17.03.log.html .

Meeting summary

Meeting ended at 18:08:57 UTC.

Action Items

  • albertom will be the component owner for the ansible scripts in ciao
  • kristen to update gatekeeper schedule today.
  • markusry and obedmr to clarify image service privileged vs. unprivileged api calls.
  • obedmr to sync with jorge on image api requirements for webui.

Action Items, by person

  • albertom
    • albertom will be the component owner for the ansible scripts in ciao
  • markusry
    • markusry and obedmr to clarify image service privileged vs. unprivileged api calls.
  • obedmr
    • markusry and obedmr to clarify image service privileged vs. unprivileged api calls.
    • obedmr to sync with jorge on image api requirements for webui.
  • UNASSIGNED
    • kristen to update gatekeeper schedule today.

People Present (lines said)

  • markusry (87)
  • kristenc (82)
  • tcpepper (62)
  • albertom (35)
  • obedmr (25)
  • mcastelino (11)
  • mrkz (9)
  • rbradford (5)
  • ciaomtgbot (3)
  • carlosag (1)
  • david-lyle (1)

Generated by MeetBot_ 0.1.4

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

###Full IRC Log

17:03:36 <kristenc> #startmeeting weekly meeting
17:03:36 <ciaomtgbot> Meeting started Thu Nov 10 17:03:36 2016 UTC.  The chair is kristenc. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:36 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:03:36 <ciaomtgbot> The meeting name has been set to 'weekly_meeting'
17:03:43 <kristenc> #topic role call
17:03:44 <tcpepper> `o
17:03:47 <kristenc> o/
17:03:48 <rbradford> o/
17:03:53 <david-lyle> o/
17:04:07 <mcastelino> o/
17:04:09 <mrkz> o/
17:04:11 <carlosag> o/
17:05:15 <albertom> o/
17:05:41 <kristenc> we have markusry on the agenda after opens to talk about gatekeeper schedule.
17:05:46 <kristenc> #topic opens
17:05:49 <markusry> o/
17:05:50 <kristenc> are there any other opens.
17:06:04 <markusry> I also have another gatekeeper open about the ansible stuff
17:06:35 <markusry> Whose authorization is needed to merge changes to the ansible scripts?
17:06:45 <obedmr> o/
17:06:57 <obedmr> I'd say albertom
17:07:04 <albertom> sup ?
17:07:25 <mrkz> I also purpose albertom :)
17:07:25 <kristenc> good question. as long as albertom is able to be responsive to pull requests and reviews, then I would agree.
17:07:34 <tcpepper> it would also be good for albertom to share some documentation on the design/architecture of the ansible deployment
17:07:44 <tcpepper> so we know where we should add things when we want to
17:07:45 <albertom> with great power comes great responsability :)
17:07:52 <tcpepper> or where to look when we have issues
17:08:01 <markusry> I'll update
17:08:02 <markusry> https://github.com/01org/ciao/wiki/Package-maintainers
17:08:09 <tcpepper> otherwise albertom's going to be the primary one pushing patches to the ansible code
17:08:15 <kristenc> thanks.
17:09:03 <albertom> So who will erview my patches to ansible stuff ?
17:09:25 <kristenc> albertom, the official gatekeeper will. And you will be responsible for reviewing everyone elses.
17:09:28 <tcpepper> you need to teach us to do that
17:09:34 <kristenc> patches into your component.
17:09:46 <albertom> oh ok
17:09:50 <albertom> thats better
17:10:33 <kristenc> #action albertom will be the component owner for the ansible scripts in ciao
17:10:49 <kristenc> #topic gatekeeper schedule
17:10:53 <kristenc> go ahead markusry
17:11:08 <markusry> Okay, well it's simple
17:11:19 <markusry> Who'd like to be gatekeeper for the next two weeks
17:11:21 <markusry> ?
17:11:28 <markusry> There's loads of lovely PRs to merge
17:11:32 <kristenc> let me take a look. there's an algorithm for this :).
17:12:10 <tcpepper> can we just cycle back around?  but maybe drop manohar in the first row
17:12:15 <kristenc> rbradford and kristenc would be the next ones
17:12:16 <tcpepper> and replace him with me in the last row?
17:12:25 <tcpepper> I can take slack for him since he's also doing containers work
17:12:43 <tcpepper> then for the core's we've each got two slots?
17:12:49 <kristenc> the next for weeks would normally go like this:
17:12:52 <kristenc> rob & kristen
17:12:56 <kristenc> mark & time
17:12:59 <kristenc> tim
17:13:04 <kristenc> rob & manohar
17:13:12 <kristenc> mark & kristen
17:13:18 <tcpepper> oh yeah the timezones splitting.../me forgot about that
17:14:09 <kristenc> is there a problem with this algorithm?
17:14:30 <kristenc> (other than poor europe has to cycle more often)
17:14:37 <markusry> fine for me
17:14:49 <tcpepper> I'm full time on Ciao, Manohar's not...I could take an extra cycle if he desires
17:14:49 <kristenc> you can blame samuel
17:15:22 <kristenc> well - he's not up for 2 more weeks, so I guess he could decide then.
17:15:33 <kristenc> 4 more weeks.
17:15:43 <kristenc> that is.
17:15:52 <markusry> We'll be finished ciao by then:-)
17:16:16 <kristenc> right. we'll all be roasting chestnuts by an open fire.
17:16:36 <tcpepper> at some point we should also start bringing some additional https://github.com/01org/ciao/graphs/contributors up into occasional gatekeeping
17:16:49 <kristenc> let me update the schedule.
17:17:18 <kristenc> after the meeting that is.
17:17:31 <kristenc> #action kristen to update gatekeeper schedule today.
17:17:39 <kristenc> ok, shall we move on?
17:17:44 <kristenc> #topic Bug Triage
17:18:09 <kristenc> #link https://github.com/01org/ciao/issues?utf8=0.000000E+002    17:18:38 <kristenc> we have a lot of new ones.
17:19:04 <kristenc> #775 - this is a cleanup / code improvement reminder.
17:19:07 <kristenc> I would make it a p3.
17:19:25 <tcpepper> ok
17:19:44 <tcpepper> I'd almost suggest janitorial, but locks isn't a good place for newcomers usually
17:20:16 <kristenc> #779 - I would make this a p2 and part of this sprint.
17:20:22 <kristenc> not having logs sucks.
17:20:25 <tcpepper> indeed
17:21:32 <markusry> Yep P2 sounds good
17:21:39 <markusry> Are we allowed to add things to the Sprint?
17:21:59 <kristenc> markusry, I think if it falls under a bucket of stuff we already agreed we'd do we should.
17:22:11 <kristenc> like - delivering a working image service we agreed we'd do.
17:22:14 <markusry> Okay.  Well it shouldn't take too long
17:22:42 <obedmr> markusry: I'm already adding more logging on my ciao-controller/ciao-image integration PR
17:22:52 <kristenc> #780 bug, p2 imo.
17:23:18 <tcpepper> I'm ok P3
17:23:29 <markusry> obedmr: Great
17:24:06 <kristenc> ok.
17:24:07 <rbradford> obedmr, is that PR merging soon, i will conflict with my PR?
17:24:11 <rbradford> *it
17:24:41 <obedmr> rbradford: the integration was really easy, you can start taking a look on it, just missing a few pieces, I'd hope that's complete Today
17:25:05 <obedmr> rbradford: https://github.com/01org/ciao/pull/807
17:25:39 <rbradford> okay
17:25:40 <kristenc> #782
17:26:12 <markusry> When we merge them there will be only one https cert for compute and image and volume right?
17:26:31 <kristenc> markusry, yes.
17:26:32 <obedmr> markusry: I'd say yes, I'm using the same
17:26:51 <markusry> Okay, so this will require some single vm changes as well
17:27:00 <markusry> I'll comment in the PR
17:27:06 <obedmr> yes, I'm also sending that
17:27:07 <markusry> obedmr one more quick question
17:27:10 <obedmr> sure
17:27:21 <markusry> Will yoiu still need to be admin to do everything?
17:27:32 <markusry> I ask as I'm wirting the BAT tests right now
17:27:49 <obedmr> at this moment, I'm using the credentials that uses controller to log into keystone
17:28:49 <kristenc> isn't that 2 separate things?
17:29:01 <kristenc> controller signs into keystone as a service user.
17:29:14 <kristenc> however, api requires admin vs. user rights for uploading images?
17:29:19 <markusry> Maybe we should discuss this later.  I don't want to hold up the scrub
17:29:49 <obedmr> markusry: for public images it needs admin, and yes, we can discuss private image  usage later
17:29:52 <kristenc> #action markusry and obedmr to clarify image service privileged vs. unprivileged api calls.
17:30:00 <obedmr> sure
17:30:23 <kristenc> 782 - markusry does this block you somehow, or can it be a p2 for albertom
17:30:51 <markusry> No not blocking at all
17:31:02 <tcpepper> I think the ansible failures should be P1.  we decided some time ago that ansible was our preferred deploy / mgmt route.
17:31:06 <markusry> I can edit the scripts manually which is what I did last time
17:31:10 <tcpepper> I think today the only way to actually run ciao is in single vm
17:31:18 <albertom> markusry: right now it fails because is the admin responsability to provide the ciao credentials
17:31:25 <markusry> This is more of an issue for developers
17:31:31 <albertom> and you can't have a ciao cluster without ceph
17:31:44 <markusry> But the issue is that I already have ceph on my cluster
17:31:52 <markusry> I'm just updating the ciao binaries
17:31:55 <albertom> so in the case the admin doesnt provide the credentials what should happen?
17:31:58 <markusry> and I want to leave ceph alone
17:32:19 <tcpepper> that seems quite reasonable
17:32:20 <markusry> It complains as I haven't created the ceph directory
17:32:31 <albertom> markusry: so keep the ciao credentials in your deployemnt host. It wont replace the files since they are the same
17:32:33 <markusry> on the deployment machine
17:32:41 <albertom> task is marked as unchanged (in green)
17:32:42 <markusry> ceph was not installed by ansible
17:32:43 <kristenc> I think the ansible stuff should be p1 too. at least the fact that bat tests dont work when ansible is used is a p1. if the bat tests dont work, the cluster wasn't installed correctly.
17:32:59 <markusry> on our cluster
17:33:24 <tcpepper> the ciao ansible scripts deploy ciao.  ceph comes from somewhere else.  period.  today.
17:33:29 <tcpepper> if that doesn't work, that's a P1
17:33:44 <markusry> The thing is that the ciao nodes need the ceph setup info
17:33:58 <markusry> The ansible scripts that install ciao copy that info to the ciao nodes
17:34:01 <albertom> and one requisite to deploy ciao is that the admin fetches the ceph credentials and puts them int he ceph directory in the deployment node
17:34:15 <albertom> yup
17:34:23 <tcpepper> ceph's a required config option.  the scripts need to take as input the ceph config that has been pre-provided
17:34:27 <albertom> you dont want to instruct the user to manually setup ceph on the 100 nodes
17:34:30 <albertom> i mean
17:34:32 <markusry> But can't we just change the scripts so it only does this if the dir is present
17:34:36 <albertom> manually copy ceph credentials to the 100 ciao nodes
17:34:54 <tcpepper> the only requirement in the ciao deploy should be the mon url, imho.
17:35:22 <albertom> tcpepper: so we leave to the admin copy the ciao config and cert to the 100 ciao nodes?
17:35:58 <tcpepper> albertom: ceph itself has deployment tools.  and there's https://github.com/clearlinux/clear-config-management also.
17:36:01 <albertom> mon url can be consulted from  ciao.conf provided by the admin
17:36:09 <markusry> albertom: I think the current behaviour is fine.  All I want is that it doesn't error out if ceph directory does not exist
17:36:29 <tcpepper> if those don't copy the keys around, there's a bug there.  given today (despite pending changes) we expect cephfs and cephfs requires the key to mount.
17:36:49 <albertom> tcpepper: ceph deplotment scripts shouldn't copy the files to ciao nodes
17:36:56 <albertom> ceph deplotment script deplot ceph
17:37:15 * tcpepper continues to assume a preferred implementation is a server based storage one
17:37:22 <tcpepper> albertom: assumes we all get 40G nices
17:37:41 <tcpepper> we need an agreed preferred implementation
17:37:44 <tcpepper> this should be a separate meeting
17:37:49 <albertom> sure
17:37:49 <tcpepper> what is a valid ciao deployment with ceph
17:38:03 <albertom> i think if we dont fail when the admin doesn'r provide ceph credentials...
17:38:14 <albertom> it means we can endup with a cluster where ciao nodes do not have ceph configured
17:38:25 <kristenc> we need to have a separate meeting to review the deployment plan. can we schedule that for monday?
17:38:25 <albertom> which means a non-working cluster
17:38:34 <kristenc> we still have a lot of bugs to triage.
17:38:41 <markusry> Can't you provide an override variable
17:38:50 <markusry> So that the default behaviour is to error out
17:39:00 <markusry> But if someone passes --ignore-ceph
17:39:01 <mrkz> so, should it be p1,p2,p3?
17:39:01 <albertom> markusry: that is something i can work with :)
17:39:09 <markusry> it doesn't complain
17:39:37 <markusry> P2 or P3.  I have a workaround
17:39:48 <markusry> P3 should be fine I think
17:39:49 <albertom> so i would say the current behaviour is fine... but adding that override var for developers is easy and p2 or p3
17:40:02 <albertom> leave more comments and thoughts on the issue
17:40:48 <kristenc> 787 - is this a p2 or p3?
17:41:16 <tcpepper> p3
17:41:21 <tcpepper> not gonna happen soon
17:41:24 <tcpepper> janitorial too
17:41:30 <obedmr> agree
17:42:11 <kristenc> 788 - is there a workaround this issue? if so, maybe p3?
17:42:26 <albertom> Ithere is a PR with the workaround
17:42:46 <albertom> https://github.com/01org/ciao/pull/803
17:43:16 <mcastelino> do we need touse clear containers?
17:43:24 <kristenc> ok - so p3 then imo since you can work around it.
17:43:26 <mcastelino> can we use regular runc containers for now
17:43:26 <albertom> well is the default in clearlinux
17:43:36 <mcastelino> you can run with --runtime=runc
17:43:46 <mcastelino> so you can switch away from the default
17:44:17 <mrkz> mcastelino: that'd require to change the playbooks to always use runc (which can be done) but then we're not catching up cc issues either
17:44:18 <albertom> that means not using docker_container ansible module and fall back to shell scripts =/
17:44:20 <mrkz> so yeah, p3
17:44:39 <kristenc> 790 - p2?
17:44:39 <albertom> but "do we want to use clear containers?" is a good question
17:45:02 <mrkz> kristenc: yeah, that should be easy
17:45:04 <mrkz> p2
17:45:07 <albertom> 790 has a PR too
17:45:17 <albertom> https://github.com/01org/ciao/pull/805
17:45:19 <markusry> DIdn't I merge that?
17:45:30 <markusry> Nope
17:46:01 <markusry> I did review it, and I thought I'd merged it.
17:46:11 <mrkz> markusry: hurry before they take the gatekeeper keys away :p
17:46:19 <markusry> Ah I remember
17:46:31 <markusry> There was an unrelated travis failure
17:46:41 <markusry> So I restarted the build but forgot to go back and merge
17:46:43 <markusry> I'll do this now
17:46:44 <mcastelino> one question... on the same lines I think we should try and run at least the setup.sh part of single VM in travis... any objections if I do that
17:47:16 <markusry> We don't need the CNCI as nothing gets launched
17:47:20 <tcpepper> I like that
17:47:29 <markusry> But there might still be some races
17:47:41 <kristenc> 792 - markusry does this block bat testing?
17:47:43 <tcpepper> today we've got three systems:  travis, singlevm/machine, and ansible deployed
17:47:48 <markusry> like uploading images before the image service starts
17:47:49 <tcpepper> would be nice to drop that to two over time
17:48:06 <markusry> integrating keystone will get rid of one race at least
17:48:16 <markusry> But there are still loads of sleeps that might not work as expected on travis
17:48:58 <mcastelino> markusry, I think we can fix the races by probing status... like how we did with ciao events
17:49:05 <mcastelino> hopefully in all places
17:49:13 <markusry> kristenc: No
17:49:30 <markusry> Well it prevents me from improving the BAT tests
17:49:35 <tcpepper> is 792 a bug or enhancement?
17:49:36 <markusry> But it doesn't break the existing ones
17:49:42 <kristenc> p2 then.
17:49:43 <markusry> Well I think it's a bug
17:49:50 <markusry> The current event log isn't really much use
17:49:56 <markusry> To programmatic consumers
17:50:22 <kristenc> it'd be easy to add, and I agree it'll add value. I put it as p2.
17:50:32 <tcpepper> ah from the "wait for" perspective in automation ok yes
17:50:46 * tcpepper was thinking human dev/test..poke, see event, poke next
17:50:55 <kristenc> #793 - sounds like a p3 to me.
17:51:01 <markusry> mcastelino: we might not want to do any image uploads in travis
17:51:42 <tcpepper> 793 could be a janitorial enhancement too
17:52:32 <kristenc> 794 seems like a p1.
17:52:36 <markusry> I have a PR for this
17:52:59 <kristenc> cool - so you will look more awesome when you close this p1 issue :).
17:53:03 <markusry> https://github.com/01org/ciao/pull/800
17:53:07 <markusry> P1 it is
17:53:13 <tcpepper> :)
17:53:18 <markusry> I need this for the BAT tests so it is a P1
17:53:35 <kristenc> 801 is also a p1 since it blocks deployment.
17:54:20 <obedmr> yeap, initial PR is in place https://github.com/01org/ciao/pull/807
17:54:48 <obedmr> working on minimal missing pieces, it's already working, just shaping it
17:55:31 <kristenc> 802 - btwarden needs to determine if upstream gophercloud (note the repo move) addresses the issue. I would put this as a p3.
17:55:41 <tcpepper> 802 I'd say P2 or 3 since auth failure to me implies a config/deploy error?
17:55:55 <tcpepper> not that this isn't an ugly problem :(
17:56:07 <kristenc> yes - that was my reasoning behind p3. it would only trigger in an improperly configured cluster.
17:56:17 <tcpepper> make sense
17:56:59 <tcpepper> 806 looks like user error?  or deploy error? cert mgmt...
17:57:37 <markusry> Yep.
17:57:48 <markusry> I worked for me when I installed using ansible
17:57:57 <tcpepper> it's worked for me too
17:58:00 <markusry> But I built ciao from source
17:58:08 <markusry> And didn't install from release packages
17:58:10 <tcpepper> me too
17:58:54 <kristenc> well - needs more info to really tell whats going on.
17:59:24 <kristenc> let's mark it as p3 since it works for the rest of us.
17:59:27 <tcpepper> I wonder if there might be an errant proxy in the play.  should consult with is local LAN / IT admin.
17:59:49 <albertom> I can help carlosag debug the issue :)
18:00:13 <kristenc> albertom, good - I was just going to suggest we assign it to you since it is possible deploy related.
18:00:53 <kristenc> 808 - markusry does this block you with bat tests?
18:01:08 <markusry> Not really.  It's like the event log issues
18:01:14 <kristenc> so p3?
18:01:15 <mcastelino> kristenc, we can work around it
18:01:18 <markusry> It prevents me from enhancing the existing tests
18:01:18 <mcastelino> P3
18:01:32 * mrkz has to drop
18:01:55 <markusry> An mcastelino from simplifying verify.sh
18:01:59 <markusry> And
18:02:16 <markusry> 809 and 810 are related
18:02:17 <tcpepper> it's a minor/easy change, or?
18:02:21 <kristenc> #809 - obedmr I think that's a p2. it's bad to have a command that doesn't work, but probably not your top priority.
18:02:37 <markusry> tcpepper: I need to check to see why I put the notification where I did
18:02:42 <tcpepper> 808: sounds easy or?  ah ok
18:02:46 <mcastelino> markusry, yes... also once we address the other Issue of events having more info (which is probably more important) we can look at this
18:02:46 <markusry> On the face of things it seems like an easy change
18:02:53 <tcpepper> 808 sounds easy...punny punny
18:03:19 <tcpepper> tough crowd..no edm fans? ;)
18:03:22 <markusry> 808 and 809 are similar
18:03:25 <kristenc> personally I would remove any feature that we don't have a direct use case for right now. we can always add later if it becomes apparent we need it.
18:03:39 <markusry> The feature is implemented in ciao-cli but not in the image service
18:03:43 <obedmr> 809, It should be easy, not implemented yet
18:03:59 <tcpepper> 809/810 could be stubbed out of the cli for the time being while we focus on core storage flows
18:04:00 <kristenc> we don't need to implement things that we don't think we'll use.
18:04:01 <markusry> download might make things tricky for rbradford
18:04:04 <tcpepper> ie: upload and use
18:04:17 <kristenc> it was likely implemented in cli just because glance does it.
18:04:20 <tcpepper> comes before download or modify in place
18:04:20 <markusry> upload is actually implemented
18:04:22 <kristenc> that doesn't mean we have to.
18:04:56 <markusry> So what should we do?
18:05:03 <markusry> Disable the features in ciao-cli for now?
18:05:09 <obedmr> I can do the download one, once we have the integration with ciao-controller, what you think?
18:05:13 <kristenc> anyway, a p2 to resolve - I would delete the code from cli and add it back in later if needed.
18:05:14 <tcpepper> i agree with markusry's suggestion
18:05:39 <tcpepper> obedmr: I'd put solid deploy and integration of all of this ahead of adding things like download/modify
18:05:50 <obedmr> tcpepper: sure
18:05:55 <kristenc> agree.
18:05:59 <obedmr> that's be first
18:06:05 <obedmr> *that'd
18:06:09 <markusry> Okay, so the bugs become disable the functionality in ciao-cli
18:06:37 <markusry> ?
18:06:41 <tcpepper> affirmative
18:07:07 <rbradford> o/
18:07:16 <obedmr> thumps up
18:07:26 <markusry> Does the web ui use these endpoints?
18:07:42 <tcpepper> if it does, it fails, or?
18:07:44 <markusry> I guess not or they would have entered a bug
18:07:48 <obedmr> markusry: ciao-image ?
18:07:57 <tcpepper> image mod / download
18:08:08 <obedmr> oo
18:08:12 <markusry> These endpoints are not implemented in ciao-image
18:08:14 <kristenc> ok, we are obviously way past time. obedmr can you check with jorge to make sure all the endpoints they need are implemented?
18:08:22 <kristenc> for image
18:08:22 <obedmr> kristenc: sure
18:08:33 <obedmr> I 'll with Jorge
18:08:42 <obedmr> * I''ll talk with Jorge
18:08:51 <kristenc> #action obedmr to sync with jorge on image api requirements for webui.
18:08:51 <tcpepper> almost on time...not bad for the amount of new issues opened

Weekly Meetings

Development

Architecture

Clone this wiki locally