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

Weekly Meeting 2017 03 02

Jump to bottom
Kristen Carlson Accardi edited this page Mar 2, 2017 · 2 revisions

Agenda

  • Weekly summary
  • Opens

##Minutes

#ciao-project: weekly meeting

Meeting started by kristenc at 17:04:52 UTC. The full logs are available at ciao-project/2017/ciao-project.2017-03-02-17.04.log.html .

Meeting summary

Meeting ended at 18:12:37 UTC.

Action Items

  • albertom will update the ciao documentation on the clearlinux.org site to remove incorrect/stale instructions.

Action Items, by person

  • albertom
    • albertom will update the ciao documentation on the clearlinux.org site to remove incorrect/stale instructions.
  • UNASSIGNED
    • (none)

People Present (lines said)

  • kristenc (79)
  • albertom (63)
  • markusry (30)
  • mrkz (29)
  • rbradford (27)
  • Teresita-Warrior (10)
  • obedmr (10)
  • ciaomtgbot (3)
  • tcpepper (3)
  • mcastelino (3)
  • _erick0zcr (1)

Generated by MeetBot_ 0.1.4

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

###Full IRC Log

17:04:52 <kristenc> #startmeeting weekly meeting
17:04:52 <ciaomtgbot> Meeting started Thu Mar  2 17:04:52 2017 UTC.  The chair is kristenc. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:52 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:04:52 <ciaomtgbot> The meeting name has been set to 'weekly_meeting'
17:04:59 <kristenc> #topic role call
17:05:04 <kristenc> o/
17:05:11 <rbradford> o/
17:06:44 <markusry> o/
17:06:49 <mrkz> o/
17:07:33 <kristenc> ok, let's just get started.
17:07:39 <kristenc> #topic weekly summary
17:07:54 <kristenc> We continued to improve ciao’s usability by merging the next step in our custom workloads support - the ability to delete workloads. Users can now both create and delete their own workloads, and admins can create and delete public workloads. This allowed us to enable the workload BAT tests, since we can now clean up any workloads that are created as part of the test.
17:08:10 <kristenc> We continue to make progress towards our converged production/deployment scripts. The ansible deployment scripts were modified to detect whether or not launcher needs to be started in dual mode, such as is required for singlevm. The scripts were also changed to run ciao-controller as a normal user instead of as root.
17:08:23 <_erick0zcr> o/
17:08:32 <kristenc> The behavior of ciao-controller when bulk starting instances has been changed somewhat. Previously, if you encountered an error in starting any of the requested instances, your API call would receive an error response code. Now if even one of your instances is successfully created, you will receive a success response code, and other errors will be logged in the event log. Template support was added to the instance add ciao-cli command to make it
17:08:32 <kristenc> easier to write BAT tests to detect whether all of the requested instances were launched, and the instance add BAT tests were updated to use this new functionality.
17:09:01 <kristenc> The instance quotas tracking was updated to use the new quotas service & some new BAT tests were added to make sure this feature is tested.
17:09:14 <kristenc> We merged support for a new “services” package. This package contains common code that can be shared by various services. Currently it contains code to store information  about whether a requester of an HTTP route is a privileged user or not. Ciao-controller was modified to use this service to determine if a request of a route should be honored or not, depending on whether that route should be used by a privileged user or not. Since t
17:09:14 <kristenc> his checking has not been done in the past, there may be some routes that used to work for unprivileged users that will now need to be accessed only as a privileged user, or else they will return a 401.
17:09:39 <kristenc> and finally... We have new gatekeepers - Rob & Manohar
17:09:45 <mcastelino> oh...
17:09:51 <mcastelino> Time to review PRs
17:09:56 <mrkz> :)
17:09:57 <mcastelino> o/
17:10:15 <kristenc> i forgot to check on our bug status - hang on.
17:10:33 <kristenc> well, I should say this is an open for me.
17:10:48 <kristenc> if there are no questions on the weekly summary, we can move on to opens.
17:11:06 <mrkz> I have a question wrt to the workloads
17:11:11 <kristenc> go ahead.
17:11:33 <mrkz> have we updated the documentation about it (e.g: explain user how to create/delete a workload)
17:11:44 <kristenc> there's documentation in ciao-cli for it.
17:11:45 <mrkz> I mean explain how it deffers from previous handling of workloads
17:12:20 <kristenc> ciao-cli didn't used to support adding workloads, so no.
17:12:35 <kristenc> did have a specific place in mind where you feel the documentation needs updating?
17:12:45 <mrkz> should we create a wiki or some other doc to explain better that ?
17:13:11 <mrkz> do we even have a ciao-cli wiki?
17:13:13 * mrkz ponders
17:13:20 <kristenc> we have readme files in the code.
17:13:32 <kristenc> we don't have a "user guide" at all.
17:13:51 <mrkz> uh, should we add ^ as part of the usability effort for the next spring?
17:13:55 <markusry> The readme is good though and very detailed.
17:13:56 <mrkz> sprint, sorry
17:13:57 <mrkz> lol
17:14:12 <markusry> So maybe we just need to update this if it hasn't already been done
17:14:23 <kristenc> well - I'm not ready to commit to what we'll be doing in the next sprint yet.
17:14:33 <mrkz> markusry: that would work for now, but I'd +1 the idea of having an user guide
17:14:35 <markusry> It's even in markdown
17:14:36 <markusry> https://github.com/01org/ciao/blob/master/ciao-cli/README.md
17:14:58 <kristenc> the cli readme does have workload info in it already.
17:15:21 <kristenc> although now I can't remember if it's just in the "examples" directory or not.
17:15:49 <kristenc> mrkz, you can file an issue to add a ciao user guide. I think that's as far as we can go right now.
17:15:58 <mrkz> kristenc: will do, thanks
17:16:28 * tcpepper started a user guide a few weeks ago and got distracted
17:16:32 <tcpepper> should finish that
17:16:53 <kristenc> were there any other questions on the weekly summary?
17:17:01 <mrkz> that's all I had :), thanks
17:17:22 <Teresita-Warrior> I have a question regardong external ip documentation
17:17:31 <kristenc> go ahead.
17:17:46 <Teresita-Warrior> is there a place were we can find how to implement that endpoints?
17:18:08 <Teresita-Warrior> all we hace is a document with the parameters needed for some of them
17:18:13 <kristenc> Teresita-Warrior, are you looking for documentation on the HTTP API for external IPs?
17:18:21 <Teresita-Warrior> yes
17:18:37 <Teresita-Warrior> that's what I need
17:18:56 <kristenc> I have something we used for review that I can send you, but our API automatic documentation doesn't cover that code yet.
17:19:16 <Teresita-Warrior> great, that will be helpful
17:19:21 <Teresita-Warrior> :)
17:19:28 <kristenc> if you send me an email I'll send you what you what I have - it is likely fairly up to date with the implementation.
17:20:03 <kristenc> as I mentioned before, I don't want to do public documentation on apis that isn't automatically generated.
17:20:40 <Teresita-Warrior> sure
17:20:50 <kristenc> #topic opens
17:20:52 <Teresita-Warrior> I'll send you and email
17:20:56 <kristenc> ok.
17:21:49 <kristenc> Teresita-Warrior, the ultimate best way to implement the end points is to look at the ciao-cli code.
17:22:43 <kristenc> I have an open.
17:23:04 <Teresita-Warrior> kristenc: got it. let me take a look
17:23:36 <kristenc> we had discussed some time ago that we should distribute the load of bug triaging. I was wondering if for simplicity we could assign the gatekeepers the additional duty of triaging bugs during their reign of power.
17:24:05 <kristenc> I'm not doing a good job. It's not that it's hard or anything, we get very few bugs added.
17:24:15 <kristenc> but I forget to do it.
17:24:38 <kristenc> and I think if it were part of official job responsibility, it'd be easier to remember. Review PRs, check for new issues.
17:24:50 <kristenc> would people be ok with this?
17:26:01 <markusry> I thought we'd agreed that people who weren't gatekeeping would do it
17:26:13 <markusry> To reduce the burden on the gatekeepers
17:26:14 <mrkz> kristenc: IMHO bugs are also part of the gatekeeping task (e.g: you look at the horizon of the project for new code, but also new bugs or new feature requests)
17:26:55 <kristenc> we did talk about having separate bug triage team, however, just for example - there were only 3 bugs entered in the past 7 days.
17:28:04 <kristenc> it won't add much overhead to the gatekeepers to take a second to triage an issue at this point. if we do a bug triage rotation, it'll be more management overhead than it's worth imo, at least at this moment in time.
17:28:14 <markusry> Okay
17:28:32 <kristenc> we can revisit this if we start getting a lot of bugs and PRs to handle.
17:28:42 <markusry> Sounds good
17:30:37 <kristenc> ok, I will triage last weeks bugs right after this meeting, but then rbradford and mcastelino could just check out the issues once in a while and make sure they have a label and priority. If it's something super important (like a P1 bug comes in) then assign a person and ping them.
17:31:35 <kristenc> are there any more opens?
17:31:41 <mrkz> wouldn't be better for every component owner to know the priority if their component gets hit by the bug?
17:32:17 <markusry> Not all components have owners
17:32:40 <markusry> Some are group owned like ciao-cli, payloads
17:32:48 <markusry> ssntp
17:33:01 <kristenc> some bugs cross issues or are hard to tell which component they belong to.
17:33:10 <mrkz> so gatekeepers could tag the bug (if untagged) with the proper component and with the owner(s) can act/decide the priority it has (?)
17:33:21 * mrkz just thinking out loud an idea
17:34:50 <kristenc> we have so few emergency bugs right now, I don't think we need a more formal process just yet. P1 bugs the gatekeeper will definitely find the right person to assign.
17:35:09 <kristenc> but beyond that, I don't know that we need more.
17:36:00 <rbradford> sgtm
17:36:14 <rbradford> there is no need for a heavy weight process here
17:36:42 <rbradford> kristenc, i have an open
17:37:02 <kristenc> ok - one sec, I've not been telling meetingbot stuff.
17:37:13 <kristenc> #topic bug triage
17:37:21 <mrkz> was just looking at how other projects (e.g: ansible) do; where depending of the tag of the PR/issue certain github users are mentioned in there so they can take a look without a person having to tell them to :p
17:37:34 <kristenc> #agreed gatekeepers will triage bugs and if a P1 bug appears they will ping someone to start looking at it.
17:38:40 <kristenc> ok rbradford , what's your open.
17:39:01 <rbradford> kristenc, i'd like to propose the deletion of https://clearlinux.org/documentation/ciao-cluster-setup.html
17:39:18 <rbradford> it's very out of date
17:39:22 <obedmr> agree ^^
17:39:49 <markusry> Also, can we remove references to the container
17:39:50 <markusry> https://clearlinux.org/documentation/ciao-deploy.html
17:40:03 <rbradford> albertom, ^
17:40:12 <kristenc> #topic documenation on the clearlinux site is old
17:40:18 <markusry> and here
17:40:19 <markusry> https://github.com/01org/ciao/blob/master/_DeploymentAndDistroPackaging/ansible/README.md
17:40:23 <markusry> In fact maybe
17:40:29 <markusry> https://clearlinux.org/documentation/ciao-deploy.html
17:40:33 <markusry> should just point to
17:40:35 <albertom> markusry: i m just about to push a PR
17:40:39 <albertom> to remove it from the README.md
17:40:40 <albertom> file
17:40:44 <markusry> https://github.com/01org/ciao/blob/master/_DeploymentAndDistroPackaging/ansible/README.md
17:40:47 <albertom> and start working on the PR to remove it from clearlinux
17:40:54 <mrkz> albertom: awesome
17:41:08 <markusry> Maybe we should just have a link in clearlinux to the readme
17:41:42 <kristenc> albertom, great! so will your change remove the ciao-cluser-setup.html page?
17:41:54 <albertom> kristenc: no
17:42:10 <markusry> This is what we do for the simple setup case
17:42:14 <albertom> my change will update https://clearlinux.org/documentation/ciao-deploy.html
17:42:45 <rbradford> albertom, why not kill that and point to the readme
17:42:48 <rbradford> it's just duplication
17:43:26 <rbradford> at this point with things changing so much i'm not sure the overhead of having stuff on clearlinux.org is worth it
17:43:27 <albertom> rbradford: thats not up to me... I think for the ClearLinux project they wanted instructions specifically for ClearLinux
17:43:33 <albertom> the ones on the README.md are more agnostic
17:43:46 <albertom> but sure we can discuss it on #clearlinux
17:44:17 <kristenc> who do we need to talk to about removing things from the clearlinux site? I know we can submit PRs, but do we have to have someone ok it philosophically?
17:44:44 <rbradford> albertom, what is clearlinux specific about https://clearlinux.org/documentation/ciao-deploy.html
17:44:45 <kristenc> cause I'm with rbradford - I feel we should just try to keep our documentation on the ciao github site for now.
17:44:58 <albertom> markusry: https://github.com/01org/ciao/pull/1216
17:45:52 <kristenc> also - I don't think we need instructions on a manual setup any more.
17:46:02 <kristenc> so the whole page is just irrelevant.
17:46:20 <albertom> rbradford: with the new change were we dont use the container we tell the user to install ansible, gcc, go, keystone client
17:46:26 <albertom> so the clearlinux.org instructions will include
17:46:42 <albertom> swupd bundle-add go-basic c-basic sysadmin-hostmgmt openstack-pythonclients
17:46:47 <rbradford> albertom, pointless duplication
17:46:51 <albertom> i know
17:46:59 <markusry> And it might terrify people
17:47:00 <albertom> but is not up to me to delete documentation on clearlinux.org
17:47:01 <rbradford> when you add a new dep you have to have add two separate places
17:47:16 <rbradford> albertom, who wrote that file in the first place?
17:47:16 <albertom> i need to discuss it with #clearlinux folks
17:47:28 <albertom> mrkz and I :P
17:47:31 <mrkz> o/
17:47:34 <albertom> but there are procedures
17:47:56 <rbradford> albertom, will you take the AR to start them?
17:48:10 <albertom> rbradford: yes
17:48:22 <albertom> next week im on vacation tomorrow :)
17:48:50 <albertom> in the meantime
17:48:58 <kristenc> albertom, so you are agreeing to follow up with removing all the ciao documentation from the clearlinux site? or do I need to follow up separately to remove ciao-cluster-setup.html
17:49:01 <albertom> https://github.com/01org/ciao/pull/1216/files has tobe reviewed :)
17:49:22 <albertom> kristenc: ill take the lead on updating the clearlinux documentation to make sense
17:49:36 <kristenc> that sounds vague and politician like.
17:49:38 <albertom> im already familiar with the clearlinux documentation format and repository
17:49:44 <albertom> so yes
17:49:46 <mrkz> kristenc: our issue is not about having the docs in clearlinux site or not, it's about documenting the whole needs for ciao to be installed on CLR
17:49:52 <albertom> remove the manual configuration page
17:50:07 <mrkz> if we have that documented on ciao's side, clr would just point there
17:50:11 <albertom> update all references to the manual configuration page to point to ansible instructions
17:50:17 <albertom> (either on clearlinux or github)
17:50:24 <albertom> and update github documentation
17:50:33 <kristenc> mrkz, no documentation is better than incorrect documentation :).
17:50:37 <albertom> and update clearlinux.org documentation (in case desicion is made to not point to github)
17:50:47 <albertom> so first things first
17:50:52 <albertom> review and aprove https://github.com/01org/ciao/pull/1216/files
17:50:59 <albertom> that would help
17:51:10 <mrkz> kristenc: didn't get your comment, mind to elaborate a bit more please?
17:51:15 <albertom> to have it merged before touching clearlinux.org docs
17:51:37 <kristenc> mrkz, deleting the old/incorrect documentation shouldn't rely on updating docs in the ciao github.
17:51:54 <kristenc> because it's better to have nothing there, than the wrong things there.
17:52:16 <mrkz> kristenc: ah, yeah, I'm speaking of ciao-deploy content about swupd bundle-add bla blah part
17:52:22 <mrkz> prior to actually install ciao
17:52:44 <kristenc> ok - let me tell meetingbot what is agreed.
17:52:45 <mrkz> not about the large and old page which documents the whole manually process
17:52:55 <albertom> kristenc: as ciao team member, ciao documentation should be tracked on ciao's github page
17:53:27 <albertom> but as ciao team member you cannot ask everyone that has written about ciao before to remove their contents and point to your page
17:53:50 <albertom> i agree clearlinux.org doc is old and i will fix it next week
17:53:51 <kristenc> #action albertom will update the ciao documentation on the clearlinux.org site to remove incorrect/stale instructions.
17:54:26 <mrkz> that's accurate yes, stale and incorrect has to die
17:54:44 <tcpepper> I agree w/ kristenc and rbradford
17:55:36 <albertom> with the ciao hat on... i agree too
17:55:43 <albertom> witht he clealrinux hat on.. i do not
17:55:51 <kristenc> i only own one hat :).
17:56:20 <kristenc> are there additional opens?
17:56:31 <albertom> i wont remove the ceph documentation on clearlinux either to point to ceph.com  :{
17:56:53 <mrkz> no opens from my side
17:57:51 <rbradford> status update from obedmr on his project - re semaphore?
17:58:00 <kristenc> right!
17:58:08 <kristenc> #topic semaphore ci support
17:58:26 <obedmr> rbradford: yeah, semaphore's ubuntu 14.04 has been a pain to configure, many workarounds are required to make it work
17:58:33 <obedmr> and still not getting good results
17:58:41 <kristenc> #info semaphoreci is a PITA
17:59:12 <obedmr> I have contacted the Semaphore folks if they have plans for newer ubuntu and they say "no, no plans yet"
17:59:59 <obedmr> I tried to run ciao-down there, but it's too slow because, you now, it would be a VMs inside a VM inside another VM :)
18:00:11 <obedmr> s/you now/you know/g
18:00:14 <kristenc> is semaphoreci the only service that will work for us?
18:00:33 <obedmr> with nested-virtualization, it seems like the only one
18:00:43 <obedmr> at least when we're looking for free options
18:01:03 <obedmr> we could request a dedicated server, but, it will be expensive
18:02:51 <obedmr> so, semaphore seems like not the best option for us, at least for now, will continue checking if there are more options for us
18:03:04 <kristenc> #info we are going to have to look at other options.
18:03:21 <kristenc> ok, thanks obedmr
18:03:22 <rbradford> and one more open from me
18:03:36 <rbradford> i'd like to hear that status of albertom's ansible in singlevm project
18:03:59 <kristenc> #topic converged deployment scripts update
18:04:26 <albertom> with https://github.com/01org/ciao/pull/1208 merged
18:04:36 <albertom> ansible scripts are able to run everythin in a single machine
18:04:41 <albertom> I have only tested on bare metals
18:04:54 <albertom> but once merged i will start making it run inside ciao-down vm
18:05:07 <rbradford> albertom, could you test before we merge?
18:05:23 <albertom> im talking about different kind of testing
18:05:23 <rbradford> albertom, (in ciao-down)
18:05:48 <albertom> it does work on bare metals
18:06:06 <albertom> to make it work on ciao-down... i see the single-vm uses different configuration
18:06:21 <albertom> so i wouldn't like to hold this feature longer
18:06:42 <markusry> How long does it take on bare metal?
18:06:53 <albertom> hmm
18:07:02 <albertom> depends if the containers are already downloaded, the images...
18:07:08 <albertom> but i havent measured the time yet
18:07:20 <albertom> about ansible being slower than bash
18:07:21 <albertom> it will be
18:07:30 <albertom> take in mind it does ssh to the nodes (even itself)
18:07:38 <albertom> and transfers python files
18:07:40 <albertom> to execute them
18:07:41 <albertom> etc
18:07:58 <markusry> Is that significant though compared to the time it takes to start keystone and ceph?
18:08:00 <albertom> its a tradeoff for flexibility
18:08:34 <albertom> i think yes
18:08:34 <rbradford> currently singlevm setup.sh is just long enough for me to get a glass of water and not get distracted
18:08:42 <albertom> how long does singlevm takes ?
18:08:53 <rbradford> any longer then our productivity will tank :-)
18:09:02 <albertom> rbradford: assuming you have the containers cashed, pacakges already installed
18:09:05 <markusry> Probably about a minute if everything is downloaded.  I can check
18:09:05 <rbradford> i run ./setup.sh 5-10 times a day
18:09:07 <albertom> and images downloades
18:09:15 <albertom> so do i with ansible
18:09:22 <markusry> Well, ciao-down already downloads the images
18:09:31 <markusry> including the containers
18:09:34 <rbradford> the ciao-cli image upload to ceph is the slow bit
18:09:47 <markusry> So usually this isn't done when we run setup.sh
18:10:11 <rbradford> maybe we could reduce our image count from 3 -> 2
18:10:19 <rbradford> that would save time
18:10:35 <kristenc> right - we don't need a ton of test images. one vm, one container.
18:12:10 <kristenc> rbradford, we are a bit over our meeting time, did you want to take this discussion offline? did you get enough info on the status?
18:12:23 <rbradford> kristenc, i'm good thank you!
18:12:25 <markusry> Yes end meeting quick
18:12:26 <kristenc> (I should say, outside of meeting time, not offline)

Weekly Meetings

Development

Architecture

Clone this wiki locally