forked from ciao-project/ciao
-
Notifications
You must be signed in to change notification settings - Fork 0
Weekly Meeting 2016 05 26
Kristen Carlson Accardi edited this page May 26, 2016
·
6 revisions
- opens (5 minutes)
- bugs (10 minutes): pre-seed a list of new or priority up/down candidates into the agenda for meeting focus
- prioritize
- scrub
- update/assign
- QA (10 minutes): discuss QA proposal
- Release Process (15 minutes): follow up on Release-Process evolution
- QA flow
- gatekeeping
- changelog/NEWS edits
- Single Machine Setup (5 minutes): status check. Misc. enhancements across launcher/scheduler/ssntp/etc. to enable this have merged lately.
Meeting started by sameo at 16:00:54 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-05-26-16.00.log.html .
-
opens (sameo, 16:04:15)
- Most of openstack deployments have keystone endpoints ending with the service version, but not all... (sameo, 16:08:46)
- GET https://service/ to get the list of supported versions. (sameo, 16:11:41)
-
bugs (sameo, 16:12:52)
- LINK: https://github.com/01org/ciao/issues/166 (sameo, 16:15:03)
- Returning [] instead of nulls from the Ciao compute API would benefit OS tools and the webui. (sameo, 16:17:23)
- ACTION: jvillalo to comment on the issue as well. (sameo, 16:17:43)
- The CIAO compute API should not return nil lists (sameo, 16:18:27)
-
QA proposal (sameo, 16:20:18)
- LINK: https://github.com/01org/ciao/wiki/QA (sameo, 16:20:52)
- ACTION: fuentess to implement and automate (sameo, 16:21:35)
- mcastelino and sameo like the proposal (sameo, 16:21:59)
- IDEA: kristenc proposes QA reports to be included to the release notes (sameo, 16:22:30)
- IDEA: mcastelino proposes all QA tests to be run within the single VM setup (sameo, 16:23:02)
- IDEA: markus__ proposes to add cleanup tests (are all instances cleaned up) to the QA plan (sameo, 16:25:06)
- ACTION: fuentess: add cleanup tests (fuentess, 16:25:32)
- Travis VM is limited with networking and may not be able to run the single machine setup (sameo, 16:27:03)
- ACTION: mcastelino to check for travis VM capabilities (sameo, 16:27:22)
- fuentess QA plan proposal approved (sameo, 16:28:18)
- An actual VM is needed for the single machine setup. CNCI won't work in a ctr setup. (sameo, 16:30:00)
- ACTION: mcastelino to evaluate running Ciao's single machine setup on travis VM, with networking disabled. (sameo, 16:33:47)
-
Release process (sameo, 16:34:40)
- LINK: https://github.com/01org/ciao/wiki/Release-Process (sameo, 16:35:02)
- We have to define our standards for quality and security (sameo, 16:36:54)
- travis hits on quality at least (sameo, 16:37:28)
- But travis does not look at dependencies (sameo, 16:38:00)
- ACTION: work on reducing the number of deps (sameo, 16:39:12)
- ACTION: markus__ Create an issue for reducing dependencies (sameo, 16:39:43)
- yaml and netlink packages are the worst for quality (and security ?) (sameo, 16:40:54)
- LINK: http://go-proverbs.github.io/ (arjan_work, 16:41:47)
- IDEA: One issue per potential dependency removal (sameo, 16:45:01)
- QA is not ready yet (sameo, 16:48:21)
- We should start following the merge process (sameo, 16:50:10)
- We should also start generating change logs and release notes. (sameo, 16:50:30)
- We can start manually to see what's automatable (sameo, 16:51:15)
- IDEA: arjan_work proposes to add commit message tags to be automatically added to the release notes. (sameo, 16:51:43)
- ACTION: We have to start designating gatekeepers. (sameo, 16:52:12)
- ACTION: kristenc to designate gatekeepers for the next weeks. (sameo, 16:52:33)
- 2 gatekeepers will auto cover for component leads being out (sameo, 16:54:58)
- ciao-{cert,cli}: sameo (sameo, 16:55:27)
- ciao-controller: kristenc (sameo, 16:55:36)
- ciao-scheduler: tpepper (sameo, 16:55:45)
- networking: mcastelino (sameo, 16:55:53)
- ssntp: sameo (sameo, 16:56:03)
- vendor: markus__ (sameo, 16:56:15)
- ciao-{launcher,vendor}: markus__ (sameo, 16:56:26)
- testutil kristen (kristenc, 16:56:41)
- payloads sameo (sameo, 16:56:53)
- test-cases: markus__ (sameo, 16:57:01)
- kristenc to change the fake keystone service to implement a new endpoint to make ciao-cli happy. (sameo, 16:59:16)
-
single machine setup (sameo, 16:59:31)
- besides the fake keystone we are mostly ready (sameo, 16:59:46)
- ACTION: mcastelino to automate the whole process (sameo, 16:59:54)
Meeting ended at 17:02:01 UTC.
- jvillalo to comment on the issue as well.
- fuentess to implement and automate
- fuentess: add cleanup tests
- mcastelino to check for travis VM capabilities
- mcastelino to evaluate running Ciao's single machine setup on travis VM, with networking disabled.
- work on reducing the number of deps
- markus__ Create an issue for reducing dependencies
- We have to start designating gatekeepers.
- kristenc to designate gatekeepers for the next weeks.
- mcastelino to automate the whole process
- fuentess
- fuentess to implement and automate
- fuentess: add cleanup tests
- jvillalo
- jvillalo to comment on the issue as well.
- kristenc
- kristenc to designate gatekeepers for the next weeks.
- markus__
- markus__ Create an issue for reducing dependencies
- mcastelino
- mcastelino to check for travis VM capabilities
- mcastelino to evaluate running Ciao's single machine setup on travis VM, with networking disabled.
- mcastelino to automate the whole process
-
UNASSIGNED
- work on reducing the number of deps
- We have to start designating gatekeepers.
- sameo (117)
- markus__ (64)
- kristenc (50)
- tpepper (47)
- mcastelino (24)
- ciaoslackbridge (23)
- arjan_work (13)
- fuentess (12)
- jvillalo (9)
- obedmr (9)
- chamings (8)
- mrkz (3)
- leoswaldo (3)
- ciaomtgbot (2)
- _erick0zcr (1)
Generated by MeetBot_ 0.1.4
.. _MeetBot: http://wiki.debian.org/MeetBot
16:00:54 <sameo> #startmeeting
16:00:54 <ciaomtgbot> Meeting started Thu May 26 16:00:54 2016 UTC. The chair is sameo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:54 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:17 <mrkz> o/
16:01:28 <sameo> o/
16:01:29 <obedmr> o/
16:01:36 <markus__> o/
16:01:38 <jvillalo> o/
16:01:39 <mcastelino> o/
16:02:00 <_erick0zcr> o/
16:02:03 <leoswaldo> o/
16:03:06 <tpepper> o/
16:03:11 <kristenc> hi
16:03:11 <sameo> kristenc, mcastelino: Are you going to be able to join the meeting ?
16:03:22 <tpepper> we're all here ^^
16:03:30 <kristenc> i might be distracted, but I'll do my best
16:03:38 <mcastelino> o/
16:03:59 <sameo> So Amy can't make it today so I'll run this one.
16:04:15 <sameo> #topic opens
16:04:19 <sameo> Let's start with opens...
16:04:52 <sameo> Anyone has any opens ?
16:04:53 <fuentess> o/
16:04:54 <sameo> blockers ?
16:05:03 <chamings> o/
16:05:04 <mrkz> no opens/blockers from me
16:05:47 <tpepper> nothing from me
16:06:06 <jvillalo> nope
16:06:22 <sameo> I have an open for openstack experts in this room: When creating keystone endpoints, do you typically append the service endpoint to it or not ?
16:06:48 <sameo> e.g. when creating a glance endpoint, is it https://glance/ or https://glance/v2/ ?
16:06:55 <chamings> the latter
16:07:03 <kristenc> sameo: ime it depends.
16:07:19 <kristenc> most of them have the version.
16:07:25 <kristenc> keystone itself does not.
16:07:27 <chamings> every API is different, that's the beauty of it
16:07:45 <kristenc> yes - no consistency unfortunately.
16:08:00 <tpepper> beauty
16:08:08 <sameo> So when building a service URL from a keystone endpoint, you should basically check what's trailing and look for v* ?
16:08:40 <kristenc> to determine the api version that is supported?
16:08:46 <sameo> #info Most of openstack deployments have keystone endpoints ending with the service version, but not all...
16:09:02 <obedmr> it's just the server_name:port
16:09:06 <obedmr> like http://controller:9292
16:09:23 <sameo> obedmr: How do I know which version is supported ?
16:09:29 <kristenc> if I were implementing, I'd get the name, port - then try the version I wanted and if I got a 404 I'd know it wasn't supported.
16:10:08 <sameo> kristenc: gophercloud for example assumes all endpoint have their version in the URL definition.
16:10:30 <obedmr> you usually use it from your openrc, as far I remember, some projects have a way for getting the available versions
16:10:31 <chamings> that is 'typical'
16:10:41 <kristenc> ah.
16:11:05 <sameo> Looking at the openstack APIs, you can GET https://service/ and it will return the supported API it seems...
16:11:17 <sameo> or the list of supported ones...
16:11:21 <obedmr> yep
16:11:41 <sameo> #info GET https://service/ to get the list of supported versions.
16:12:02 <sameo> obedmr: Then you'd have to cut the endpoint URL from keystone if it comes with a vN suffix...
16:12:08 <sameo> oh well, this is messy.
16:12:32 <obedmr> yes, in keystone, we dont put versions
16:12:33 <sameo> Let's move on
16:12:52 <sameo> #topic bugs
16:13:33 <sameo> We have not built a list of hot bugs yet, but we can discuss about some of them if people feel there's a need to look at any particular issue.
16:14:39 <sameo> I guess not...
16:14:43 <jvillalo> I actually wanted to talk about https://github.com/01org/ciao/issues/166
16:14:44 <ciaoslackbridge> <>
16:15:03 <sameo> #link https://github.com/01org/ciao/issues/166
16:15:04 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://github.com/01org/ciao/issues/166> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:15:26 <sameo> ciaoslackbridge: You're chatty :)
16:15:33 <sameo> jvillalo: please go ahead.
16:15:44 <jvillalo> Only that returning a list instead of nulls, would probably hit the UI, in a positive way.
16:16:25 <jvillalo> In error handling it would be better to work with iterables
16:16:28 <jvillalo> instead of nulls
16:16:32 <leoswaldo> yeap, thats somethin I found when trying to use rally to list servers, and also happens when using the openstack client
16:16:50 <leoswaldo> both uses novaclient, and it expects iterable
16:17:23 <sameo> #info Returning [] instead of nulls from the Ciao compute API would benefit OS tools and the webui.
16:17:33 <sameo> jvillalo: Can you add that comment to the issue, please ?
16:17:43 <sameo> #action jvillalo to comment on the issue as well.
16:17:59 <sameo> jvillalo: I was actually concerned that it might break the webui...
16:18:01 <jvillalo> Was thinking also that in fact we should never return nulls, in other endpoints, in fact I hink null's is not very "json" standard.
16:18:02 <sameo> But I guess not.
16:18:06 <jvillalo> sameo: sure
16:18:23 <kristenc> btw I found a lot of inconsistencies in what our compute api returns for error codes vs. the api definition. I filed one bug. I expect there are many.
16:18:27 <sameo> #info The CIAO compute API should not return nil lists
16:18:38 <sameo> kristenc: Very likely.
16:18:56 <kristenc> we tend to use 500 for everything :)
16:18:58 <jvillalo> sameo: right now the UI shouldn't crash, if it does, then I will raise another issue to fix that
16:19:00 <sameo> Yep :)
16:19:18 <sameo> jvillalo: Ok, good.
16:19:58 <sameo> No more bugs to talk about ?
16:20:18 <sameo> #topic QA proposal
16:20:41 <sameo> fuentess proposal looks good in my opinion.
16:20:47 <fuentess> good :)
16:20:52 <sameo> #link https://github.com/01org/ciao/wiki/QA
16:20:53 <ciaoslackbridge> <>
16:20:58 <mcastelino> I reviewed it too and it looks good
16:21:02 <mrkz> ah, was about to ask for the link, thanks sameo
16:21:11 <fuentess> so next step is automate all that stuff
16:21:20 <tpepper> ah fuentess pushed it...I missed it
16:21:35 <sameo> #action fuentess to implement and automate
16:21:40 <fuentess> I have some tests that are already automated, but I need to work on some other
16:21:56 <fuentess> and as you know, I am ~3weeks on clear-containers
16:21:59 <sameo> #info mcastelino and sameo like the proposal
16:22:09 <kristenc> I did a quick review, I think it looks good. I would like the QA report included in daily release notes.
16:22:19 <tpepper> I've been thinking about this: I think the action is not so much on fuentess, but each of us
16:22:30 <sameo> #idea kristenc proposes QA reports to be included to the release notes
16:22:34 <tpepper> as we decompose big functions and make unit tests, a lot of this is on each of us
16:22:36 <mcastelino> it will be good if the QA tests can be run in the single VM setup...
16:22:44 <kristenc> agree
16:22:56 <tpepper> as mcastelino's single machine test gets bulked up, we'll each still be testing things ourselves
16:23:02 <sameo> #idea mcastelino proposes all QA tests to be run within the single VM setup
16:23:15 <mcastelino> i.e. the scripting checked in into the main repo itself so that PR submitters can attest that they have run those minimal tests
16:23:23 <kristenc> where are the QA tests stored? Can we push them to a separate github repo or keep them with our repo?
16:23:23 <chamings> still skeptical about 'all'?
16:23:24 <fuentess> mcastelino: I think we can run them on VM, but the original idea was to run them on physical clusters
16:23:36 <chamings> fuentess++
16:23:45 <mcastelino> yes. but we cannot expect all PR submitters to have a cluster...
16:23:51 <fuentess> kristenc: right now I have them on an internal git repo
16:24:01 <chamings> no, but our own QA must comprehend physical hardware and configs
16:24:09 <mcastelino> chamings: agree...
16:24:13 <tpepper> I think QA tests end up in _test.go next to the code they're testing, or in testutil/ and .travis.yml for integrated tests
16:24:15 <markus__> What about some tests to check everything is cleaned up correctly?
16:24:15 <chamings> and some QA will only be able to run on that
16:24:16 <kristenc> fuentess: if we are going to run them on the single machine setup, we need them in an open github.
16:24:18 <sameo> fuentess: We should consider open sourcing them.
16:24:29 <markus__> When you delete an instance, or all the instances in a tennant
16:24:37 <fuentess> kristenc, sameo: sure, that would be great
16:24:57 <fuentess> markus__: I can add them
16:25:02 <mcastelino> All PR submitter should have a easy way to do quick and dirty test
16:25:06 <sameo> #idea markus__ proposes to add cleanup tests (are all instances cleaned up) to the QA plan
16:25:16 <sameo> mcastelino: A very easy one.
16:25:32 <fuentess> #action fuentess: add cleanup tests
16:25:51 <markus__> For example, the docker container should be gone, the docker network should be gone, when all tennant is deleted our tunnels should go (actually I don't remember the precise rules)
16:25:57 <sameo> mcastelino: Is the final plan to add the single machine VM to travis ?
16:26:00 <markus__> But you get the idea
16:26:15 <mcastelino> sameo: Travis VM is very restricted without network access or interfaces
16:26:28 <mcastelino> need to look to see if we can have a better travis VM
16:26:33 <fuentess> markus__: yeap, will add those tests
16:26:35 <mcastelino> with minimal networking
16:26:53 <markus__> fuentess: Great. Thanks
16:27:03 <sameo> #info Travis VM is limited with networking and may not be able to run the single machine setup
16:27:18 <obedmr> I have been working with a Docker based environment for CIAO development, not sure it it could be easier to use in Travis
16:27:22 <sameo> #action mcastelino to check for travis VM capabilities
16:28:18 <sameo> #info fuentess QA plan proposal approved
16:28:20 <mcastelino> obedmr: networking will not work in that setup
16:29:20 <obedmr> mcastelino: I havent tested it (network part), will take a look
16:29:32 <obedmr> thanks for the notice
16:29:34 <mcastelino> obedmr: it will not work as the CNCI cannot work in that setup
16:30:00 <sameo> #info An actual VM is needed for the single machine setup. CNCI won't work in a ctr setup.
16:30:11 <markus__> So what can we do in travis? Run without networking and try to send some commands all the way through the system?
16:31:01 <tpepper> we'd be able to test that all of the components can talk localhost to each other over ssntp...integration test for ssntp clients/servers
16:31:29 <tpepper> perhaps not start vm and config network and stop vm and delete vm, but validate the flow from top to bottom aside from that final action
16:31:30 <markus__> And maybe launch an instance (docker container) without networking?
16:31:38 <sameo> markus__: Yes.
16:31:39 <tpepper> yes
16:31:39 <arjan_work> do we need fake vm starts?
16:31:43 <mcastelino> markus__: yes
16:31:54 <arjan_work> like a qemu-fake
16:32:02 <sameo> We can do a lot of regression testing without networking
16:32:08 <markus__> It's already there. sameo added a simulation mode
16:32:13 <sameo> arjan_work: We sort of have that already.
16:32:30 <markus__> But we might be able to launch a docker container in travis
16:32:43 <mcastelino> markus__: you had network=false... the only other place networking comes into the picture is controller waiting for CNCI
16:33:08 <mcastelino> if we disable that we should be able to do full network disabled testing
16:33:13 <sameo> mcastelino: Would you mind looking at how feasible it would be to run that setup on travis' VM ?
16:33:24 <mcastelino> sameo: I will
16:33:47 <sameo> #action mcastelino to evaluate running Ciao's single machine setup on travis VM, with networking disabled.
16:34:34 <sameo> Ok, let's move to the next topic
16:34:40 <sameo> #topic Release process
16:35:02 <sameo> #link https://github.com/01org/ciao/wiki/Release-Process
16:35:02 <ciaoslackbridge> <>
16:35:37 <sameo> Here again, kristenc proposal looks good to me, we still need to discuss about format
16:35:40 <kristenc> I think we are agreed in principle to have a changelog that is autogenerated from git logs, and release notes that show user visibile changes.
16:35:43 <markus__> About the merge checklist
16:35:46 <markus__> How do we do
16:36:09 <markus__> Verify that the package meets our standards for quality and security.
16:36:21 <kristenc> we have to define our standards.
16:36:28 <markus__> Okay, fair enought
16:36:30 <markus__> I see
16:36:31 <tpepper> they're partly defined in travis right now
16:36:44 <tpepper> and coveralls
16:36:54 <sameo> #info We have to define our standards for quality and security
16:36:59 <tpepper> travis/coveralls fail/pass criteria hit on quality
16:37:01 <markus__> Actually, we don't run any of those static analysis tools on the vendor sub directory
16:37:09 <kristenc> for example, we wouldn't want to accept a package with no unit test coverage or a crappy goreportcard score.
16:37:22 <mcastelino> or run their go tests
16:37:28 <sameo> #info travis hits on quality at least
16:37:39 <kristenc> yeah - tim ran some of the stuff on some of our current packages and they didn't look good.
16:37:42 <markus__> sameo: But not for dependencies
16:37:43 <kristenc> (yaml)
16:37:56 <tpepper> but we already _have_ accepted vendor packages with crappy goreportcard metrics
16:38:00 <sameo> #info But travis does not look at dependencies
16:38:13 <tpepper> travis is configured right now to ignore vendor. it could look at it
16:38:14 <kristenc> I think we should revisit those packages personally.
16:38:20 <tpepper> but we'd be horrifically failing right now :)
16:38:33 <markus__> But we only need to run tests and checks on this packages once
16:38:36 <tpepper> which is a sign to revisit those package dep's
16:38:40 <markus__> when we add or update a dependency
16:38:45 <sameo> And there's not much we could do, except grow a huge technical debt that we have very little control about.
16:38:51 <markus__> So not sure it makes sense to do it in travis
16:38:52 <tpepper> we need a special revendor process
16:38:53 <arjan_work> we in general need to spend some time to see if we can reduce the number of external deps
16:39:12 <sameo> #action work on reducing the number of deps
16:39:22 <tpepper> +1 reducing towards mostly std lib
16:39:28 <markus__> We should make than an issue and assign it to someone
16:39:43 <sameo> #action markus__ Create an issue for reducing dependencies
16:39:50 <sameo> markus__: :)
16:39:51 <markus__> I'm sure there's some low hanging fruit here.
16:39:58 <sameo> For sure.
16:39:59 <kristenc> i think it's going to be hard.
16:40:00 <tpepper> the yaml and netlink deps are our worst currently. the prior is _relatively_ easy to get away from. the latter will make mcastelino's life unhappy.
16:40:08 <markus__> sameo: Sure.
16:40:22 <kristenc> you have to trade off the goodness of no dependency with the badness of having to reimplement a lot of functionality
16:40:39 <kristenc> yaml is a no brainer to get rid of.
16:40:40 <arjan_work> go paradigm "better a bit of copy than a dependency"
16:40:53 <kristenc> the "a bit" is key.
16:40:54 <sameo> #info yaml and netlink packages are the worst for quality (and security ?)
16:41:12 <markus__> Here's the current list
16:41:13 <markus__> Package Root Repo Version License
16:41:13 <markus__> github.com/Sirupsen/logrus https://github.com/Sirupsen/logrus.git v0.9.0 MIT
16:41:13 <markus__> github.com/boltdb/bolt https://github.com/boltdb/bolt.git 144418e MIT
16:41:13 <markus__> github.com/coreos/go-iptables https://github.com/coreos/go-iptables.git fbb7337 Apache v2.0
16:41:13 <markus__> github.com/davecgh/go-spew https://github.com/davecgh/go-spew.git 5215b55 MIT
16:41:14 <ciaoslackbridge> <>
16:41:14 <ciaoslackbridge> <>
16:41:14 <ciaoslackbridge> <>
16:41:15 <ciaoslackbridge> <>
16:41:17 <markus__> github.com/docker/distribution https://github.com/docker/distribution.git v2.4.0 Apache v2.0
16:41:18 <ciaoslackbridge> <>
16:41:19 <markus__> github.com/docker/docker https://github.com/docker/docker.git v1.10.3 Apache v2.0
16:41:20 <ciaoslackbridge> <>
16:41:21 <markus__> github.com/docker/engine-api https://github.com/docker/engine-api.git v0.3.3 Apache v2.0
16:41:21 <ciaoslackbridge> <>
16:41:23 <markus__> github.com/docker/go-connections https://github.com/docker/go-connections.git 5b7154b Apache v2.0
16:41:23 <ciaoslackbridge> <>
16:41:25 <markus__> github.com/docker/go-units https://github.com/docker/go-units.git 651fc22 Apache v2.0
16:41:25 <ciaoslackbridge> <>
16:41:28 <markus__> github.com/docker/libnetwork https://github.com/docker/libnetwork.git dbb0722 Apache v2.0
16:41:29 <ciaoslackbridge> <>
16:41:29 <markus__> github.com/golang/glog https://github.com/golang/glog.git 23def4e Apache v2.0
16:41:29 <ciaoslackbridge> <>
16:41:31 <markus__> github.com/gorilla/context https://github.com/gorilla/context.git 1ea2538 BSD (3 clause)
16:41:32 <ciaoslackbridge> <>
16:41:33 <markus__> github.com/gorilla/mux https://github.com/gorilla/mux.git 0eeaf83 BSD (3 clause)
16:41:33 <ciaoslackbridge> <>
16:41:35 <markus__> github.com/mattn/go-sqlite3 https://github.com/mattn/go-sqlite3.git 467f50b MIT + Public domain
16:41:35 <ciaoslackbridge> <>
16:41:37 <markus__> github.com/mitchellh/mapstructure https://github.com/mitchellh/mapstructure.git d2dd026 MIT
16:41:37 <ciaoslackbridge> <>
16:41:39 <markus__> github.com/opencontainers/runc https://github.com/opencontainers/runc.git v0.1.0 Apache v2.0
16:41:39 <ciaoslackbridge> <>
16:41:41 <markus__> github.com/rackspace/gophercloud https://github.com/rackspace/gophercloud.git c54bbac Apache v2.0
16:41:42 <ciaoslackbridge> <>
16:41:43 <markus__> github.com/tylerb/graceful https://github.com/tylerb/graceful.git 9a3d423 MIT
16:41:44 <ciaoslackbridge> <>
16:41:47 <markus__> github.com/vishvananda/netlink https://github.com/vishvananda/netlink.git a632d6d Apache v2.0
16:41:47 <arjan_work> #link http://go-proverbs.github.io/
16:41:48 <ciaoslackbridge> <>
16:41:49 <markus__> golang.org/x/net https://go.googlesource.com/net origin/release-branch.go1.6 BSD (3 clause)
16:41:51 <markus__> gopkg.in/yaml.v2 https://gopkg.in/yaml.v2 a83829b LGPL v3.0 + MIT
16:41:53 <markus__> Ah, didn't format nicelt
16:41:55 <markus__> sorry
16:41:57 <markus__> And I think I upset the bot
16:42:11 <kristenc> hopefully the bot will live :)
16:42:35 <kristenc> the bot was busy making pretty links on slack :)
16:42:39 <tpepper> logrus, glog and spew are all "logging". logrus is pulled in from a dep, not us, iirc. spew I think is us.
16:43:00 <markus__> Oh wow.
16:43:01 <arjan_work> anyway better to reduce than to add at this point
16:43:08 <markus__> Sorry, won't do that again
16:43:25 <sameo> spew I can probably get rid of.
16:43:33 <markus__> A lot of these come from docker.
16:43:38 <sameo> I wish glog was part of go...
16:43:44 <arjan_work> we can't avoid docker obviously
16:43:49 <markus__> No.
16:44:16 <markus__> I think we could get rid of
16:44:17 <markus__> github.com/tylerb/graceful
16:44:20 <markus__> though
16:44:30 <tpepper> let's open a ticket for each we think we can remove
16:44:46 <sameo> I think markus__ will do that.
16:45:01 <sameo> #idea One issue per potential dependency removal
16:45:03 <markus__> Yep. Leave this with me. I'll come back you next week with a list
16:45:09 <kristenc> there's already an issue open to remove yaml and use json.
16:45:20 <kristenc> this was due to performance issues with yaml.
16:45:27 <tpepper> spew can be removed imho
16:45:27 <kristenc> but now we can add quality issues as well.
16:45:39 <arjan_work> markus__: don't wait just do as well
16:45:56 <sameo> tpepper: spew can be removed.
16:46:10 <markus__> arjan_work: Okay
16:46:16 <sameo> Guys, could we please get back to the release process for a moment ?
16:46:18 <markus__> getting rid of yaml will be a big change
16:47:06 <sameo> We need to list what's preventing us from following that process.
16:47:16 <sameo> Now that we have mostly agreed about it...
16:47:53 <kristenc> I think QA is not ready.
16:47:54 <tpepper> this is the part we were going to have fuentess implement...the automation to checkout/test/generatereport/tag-if-pass
16:48:05 <kristenc> and now he's busy for a few weeks.
16:48:21 <sameo> #info QA is not ready yet
16:48:23 <fuentess> right, I will be able to start in about 3 weks :(
16:48:25 <kristenc> we could however, move to the new merge process.
16:48:32 <sameo> kristenc: Yes.
16:48:43 <kristenc> I had an idea for how we can autogenerate release notes in the future.
16:48:50 <sameo> kristenc: Have you checked that locking the repo will still allow us to create branches ?
16:48:56 <tpepper> if you ignore my mis-push two days ago, I've been trying to practice not merging my PR's
16:49:14 <sameo> tpepper: I've been doing that as well.
16:49:18 <sameo> or trying at least.
16:49:42 <kristenc> sameo: I have not, but I can't think of why locking master would prevent branches. remember that "locking" master doesn't actually prevent anything when you do it manually (other than force push)
16:49:45 <sameo> kristenc: We could start building changelog and release notes, even if QA is not ready.
16:49:55 <kristenc> yes - we can practice the process without them.
16:50:10 <sameo> #info We should start following the merge process
16:50:29 <kristenc> I was thinking that perhaps there's a way to intelligently tag stuff in git issues and use it to group information in the release notes.
16:50:30 <sameo> #info We should also start generating change logs and release notes.
16:50:31 <tpepper> if we manually do changelog and release notes for a bit, it will highlight what is automatable and whether any of it is not
16:50:39 <markus__> So does this mean no more integrating your own PRs from now on?
16:50:48 <kristenc> yes.
16:50:59 <kristenc> we should start designating gatekeepers.
16:51:00 <arjan_work> is there a way to mark up commit messages for extraction into release notes
16:51:01 <arjan_work> like
16:51:04 <sameo> # We can start manually to see what's automatable
16:51:08 <arjan_work> relnote: <sentence>
16:51:15 <sameo> #info We can start manually to see what's automatable
16:51:34 <mcastelino> till fuentess is able to spend time I have a simple script for a quick and dirty cluster test in single machine mode.. I will publish to this list
16:51:37 <kristenc> arjan_work: if we have issues associated with commits, you could add a tag maybe. We can see if there's an api to get by tag.
16:51:43 <sameo> #idea arjan_work proposes to add commit message tags to be automatically added to the release notes.
16:52:01 <kristenc> we already tag "enhancements" and "bugs"
16:52:12 <sameo> #action We have to start designating gatekeepers.
16:52:18 <kristenc> you could use this to separate out new functionality from bug fixes.
16:52:24 <kristenc> (in release notes)
16:52:33 <sameo> #action kristenc to designate gatekeepers for the next weeks.
16:52:38 <kristenc> ok
16:52:42 <sameo> thx
16:52:54 <tpepper> sameo: there will be code gates and human gatekeepers ("merge masters")
16:52:58 <tpepper> which are we talking about?
16:53:00 <tpepper> the humans?
16:53:02 <kristenc> human
16:53:03 <sameo> yes
16:53:07 <tpepper> let's just make a MAINTAINERS file now
16:53:15 <kristenc> I can do the code gates stuff too.
16:53:17 <tpepper> there's obvious component owners today
16:53:31 <kristenc> I pasted some links on the release notes wiki page describing it.
16:53:50 <arjan_work> tpepper: we need at least 1 backup for each primary
16:53:55 <arjan_work> vacations and stuff ;-)
16:54:13 <kristenc> the plan is to have 2 gatekeepers for master.
16:54:14 <tpepper> the top level maintainer can auto-cover for component leads on vacation
16:54:20 <tpepper> we're too small otherwise
16:54:58 <sameo> #info 2 gatekeepers will auto cover for component leads being out
16:55:06 <tpepper> ciao-{cert,cli}: samuel
16:55:13 <tpepper> ciao-controller: kristen
16:55:27 <sameo> #info ciao-{cert,cli}: sameo
16:55:27 <tpepper> ciao-{launcher,vendor}: mark
16:55:35 <tpepper> ciao-scheduler: tpepper
16:55:36 <sameo> #info ciao-controller: kristenc
16:55:41 <tpepper> networking: manohar
16:55:45 <sameo> #info ciao-scheduler: tpepper
16:55:48 <tpepper> ssntp: samuel
16:55:53 <sameo> #info networking: mcastelino
16:55:54 <tpepper> vendor: mark
16:56:03 <sameo> #info ssntp: sameo
16:56:08 <tpepper> that leaves: payloads, test-cases, testutil
16:56:15 <sameo> #info vendor: markus__
16:56:26 <sameo> #info ciao-{launcher,vendor}: markus__
16:56:36 <sameo> I can take payloads
16:56:41 <kristenc> #info testutil kristen
16:56:47 <markus__> test-case is me
16:56:53 <sameo> #info payloads sameo
16:56:53 <markus__> test-cases
16:57:01 <sameo> #info test-cases: markus__
16:57:14 <markus__> It also leaves travis
16:57:37 <tpepper> travis is related to testutil
16:57:41 <sameo> I think that's something we can all look at...
16:57:42 <tpepper> imho
16:57:49 <markus__> Okay.
16:58:12 <sameo> Folks, 5mn left, can we quickly talk about the single machine setup ?
16:58:17 <tpepper> but yeah we should all have an eye on the common testutil/
16:58:28 <tpepper> I'm investing time to get it set up with more, but maintenance will be across us
16:58:56 <kristenc> sameo: I have to change the fake keystone service to implement a new endpoint to make ciao-cli happy. I'm going to work on it this afternoon.
16:59:16 <sameo> #info kristenc to change the fake keystone service to implement a new endpoint to make ciao-cli happy.
16:59:31 <sameo> #topic single machine setup
16:59:32 <mcastelino> sameo: besides the fake keystone we are mostly ready ... I need to automate the whole process
16:59:46 <sameo> #info besides the fake keystone we are mostly ready
16:59:54 <sameo> #action mcastelino to automate the whole process
16:59:56 <mcastelino> automate everything from cert creation to launching of all agents
17:00:00 <sameo> mcastelino: Nice, very nice.
17:00:29 <sameo> mcastelino: You're not blocked by anything ?
17:00:46 <sameo> mcastelino: i.e. all dependencies have been implemented ?
17:00:47 <mcastelino> no
17:00:51 <mcastelino> keystone is left
17:00:56 <mcastelino> otherwise I think we are good
17:00:56 <sameo> right.
17:01:04 <sameo> Ok then.
17:01:22 <sameo> I'm going to call that one a meeting unless someone has a last minute open...
17:01:58 <sameo> All right then:
17:02:01 <sameo> #endmeeting
Development
- Release Process
- QA
- Vendoring FAQ
- [Single VM Development Environment] (https://github.com/01org/ciao/wiki/Single-VM-Machine-Development-Environment)
Architecture
Usage