17:00:20 #startmeeting 17:00:20 Meeting started Mon Jan 20 17:00:20 2014 UTC. The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:28 #topic roll call and agenda 17:00:44 phrobb is here 17:00:44 #info Andrew Grimberg for infrastructure support 17:00:44 #info regXboi for opendove 17:00:45 hi all i'm here too today 17:00:45 if people can pound info their being here, it seems like we have more people than I'd thought originally, so this is good 17:00:54 #info phrobb is here 17:01:03 #info dkutenic for bgpcep 17:01:17 #info GiovanniMeo too here for release questions 17:01:17 #info dbainbri 17:01:17 #info oflibMichal for openflowjava 17:01:23 #info Konsta for defense4all 17:01:28 #info Prasanna for openflowplugin 17:01:29 #info goldavberg for lispflowmapping 17:01:30 #info shague for downloadable artifacts 17:01:31 #link https://wiki.opendaylight.org/view/File:Odl-release-sync-agenda-9a-01-20-2014.pdf I posted an agenda by scraping the spreadsheet for dates that were coming up and looking at per-project status 17:01:44 #info Anees here 17:01:50 #link https://docs.google.com/spreadsheet/ccc?key=0AoSzir1BfjyWdDQyVElWNG9mcWxhblREckZjbjFxUVE#gid=1 and this is the spreadsheet we're using as always 17:02:02 nice, thanks colindixon 17:02:11 #info Abhijit Kumbhare for openflowplugin here 17:02:20 I like having an agenda :) 17:02:38 ok, anyone else need to roll call? 17:02:44 otherwise, I'm going to dive into the agenda 17:02:48 but not necessarily in that order 17:02:49 #info rovarga for yangtools and bgpcep 17:02:55 edwarnicke: you here? 17:03:05 #info Ed Warnicke for controller 17:03:28 welcome michal_rehak and LuisGomez 17:03:33 want to pound info into the roll call? 17:03:43 #info michal_rehak / openflowplugin 17:03:53 #info Luis for Integration 17:04:07 so, I think the first topic is going to be the dry run for cutting release artifacts because there are people asking me questions about it 17:04:17 second 17:04:18 #topic dry run for cutting release artifacts 17:04:40 edwarnicke and/or GiovanniMeo did you want to go through what you thought this should entail? 17:04:41 so how does a project know if it passes the dry run? 17:04:49 I defer to GiovanniMeo on this 17:04:53 colindixon 17:04:55 and all 17:04:57 He knows things, I just read his Jenkin's jobs ;) 17:05:04 so the dry run is performed 17:05:07 welcome janmedved 17:05:11 is Madhu_offline around? 17:05:16 or can cdub find him? 17:05:19 by running the controller-bulk-release-prepare-only 17:05:24 for controller 17:05:29 others should do similar 17:05:37 so this job does pretty much all 17:05:39 except 17:05:44 deploying the release artifacts 17:05:50 to nexus sonatype 17:05:56 i have used this one 17:06:05 so that handles bundles 17:06:05 pound link it 17:06:06 to spot issues in gerrit permissions on tagging and so on 17:06:07 * tykeal makes note to self to verify that each jenkins silo has all the appropriate gerrit perms 17:06:12 but what about non-bundle artifacts? 17:06:25 welcome Madhu, we're talking about how to do a dry run for cutting release artifacts 17:06:26 non-bundle artifacts that does nothing 17:06:26 #info Madhu here. late 17:06:38 but if you are talking about RPMs 17:06:38 okay 17:06:51 we discussed last week. 17:06:52 then from few things i got from tykeal 17:06:57 I'm talking about RPMs and enunciation APIs 17:06:58 they are already released artifacts 17:07:02 by need 17:07:07 um 17:07:08 #info GiovanniMeo goes over how to do release artifact cutting with jenkins jobs at least for OSGi bundles 17:07:09 Non-budle artifacts that need REST connection to controller .... 17:07:18 ok, let me try again 17:07:23 #info regXboi want's to know how to cut things that aren't OSGi bundles 17:07:33 thanks colindixon 17:07:34 * colindixon takes notes 17:07:36 for that part the good news 17:07:37 No will the release artifacts be frozen for particular release once we cut artifacts for particular release...... 17:07:50 is that you don't need to stay under maven release plugin rules 17:08:02 and quite frankly i don't have a procedure for that one 17:08:11 as long as you can number them you can use 17:08:15 deploy-file 17:08:18 to upload them 17:08:23 Madhu: yes, but as you can see there are some outstanding questions, I'm hoping to get them resolves since doing this dry run is probably one of the best things we can do to try to stay on schedule 17:08:41 the release-prepareonly is to handle the 17:08:43 colindixon: yes. sorry i am late to catchup 17:08:46 releasing 17:08:48 can we link or info the controller jenkins job so I can find it later? 17:08:51 using the release plugin 17:08:52 but there is a --dry-run feature 17:08:56 which we can use. can't we GiovanniMeo 17:09:07 and it has to of course be done from yang tools on wards 17:09:09 Madhu that as we discussed is not going 17:09:12 to discover 17:09:14 all the issues 17:09:21 like missing git permission 17:09:24 can somebody pound link to the jenkins job and/or instructions for how to try a dry run at least for OSGi bundles? 17:09:25 yes. 17:09:37 GiovanniMeo: We know, that's why we are doing the grand cutting of artifacts on Jan 27 17:09:46 Which we should also probably schedule 17:09:49 yes, please on the link 17:09:56 one second for the link 17:10:12 https://jenkins.opendaylight.org/controller/job/controller-bulk-release-prepare-only/configure 17:10:27 #link https://jenkins.opendaylight.org/controller/job/controller-bulk-release-prepare-only/configure 17:10:35 #info note well this one if for maven artifacts 17:10:45 thanks 17:10:49 that's fine - we all have to do that too 17:10:49 for non-maven artifacts 17:10:51 you can put text after the link, just not before 17:11:10 you have a certain freedom there 17:11:10 GiovanniMeo: so here's a challenge :) 17:11:17 (sorry to put a lot of time into this, but I think it's really important) 17:11:29 up to you guys i can take also offline 17:11:31 if you need 17:11:44 no, no, resolving this here with notes for others to follow seems *really* useful 17:11:45 rovarga what's the challenge? 17:11:45 Please note, nobody should be pushing release artifacts to nexus as part of the dry run 17:11:54 yangtools does have a job up and running at #https://jenkins.opendaylight.org/yangtools/job/yangtools-bulk-release-prepare-only 17:12:00 #info edwarnicke points out "nobody should be pushing release artifacts to nexus as part of the dry run 17:12:09 edwarnicke 17:12:18 Or checking in new versions to gerrit 17:12:26 correct but also whould not be messing 17:12:29 with the master branch 17:12:36 only the master branch 17:12:44 the prepare-only i have created 17:12:46 GiovanniMeo: u think starting on 01/27 and do this job only for couple of days 17:12:53 we shud be able to cross the bridge correct ? 17:13:00 GiovanniMeo: I know you have it right in your Jenkin's job... just a friendly warning to folks :) 17:13:03 if not. we may have to start sooner :) 17:13:04 yes hopefully 17:13:13 I suggest this team here 17:13:18 edwarnicke no this is a very important point 17:13:19 but we do have a maven plugin, which we are integration testing by default -- which means that when release plugin runs tests, it does not update our testing data (pom.xmls referencing 0.6.0-SNAPSHOT) and thus the test fails 17:13:21 that we shud seriously start considering doing it sooner 17:13:27 which i want to make sure it's highlighted 17:13:34 the prepare-only 17:13:40 has to push to gerrit 17:13:41 and tag 17:13:45 so the question is: should IT be run during release preparation? 17:13:49 but only to make sure the git connection is fine 17:14:07 so all those operations are reversible as long as don't clobber master 17:14:11 rovarga 17:14:14 are people with questions like rovarga, regXboi, and Konstantin getting their questions answered? 17:14:16 all of it must be running 17:14:17 if not,r eask 17:14:23 GiovanniMeo: What is prepare-only pushing to gerrit? 17:14:24 I'm at 50% 17:14:35 edwarnicke 17:14:41 it's pushing two commits 17:14:44 also, everyone feel free to pound info important points 17:14:54 the commit that change from SNAPSHOT -> RELEASE 17:14:56 What are in the two commits? 17:15:07 and the commit that is pushing from RELEASE -> SNAPSHOT+1 17:15:16 this is because the maven release process 17:15:20 I'm not. I need to install 'dry-run' release on controller for our integration tests ... 17:15:26 Ah, so it changes to release artifacts and then back again to the previous snapshot? 17:15:36 no to the next iteration 17:15:44 regXboi and Konstantin 17:15:50 one second let me clear 17:15:56 what i'm more familiar with 17:16:10 then we can discuss about the other artifatcs 17:16:15 take care of Konstantin first 17:16:22 btw let me clarify one thing here 17:16:26 I'm pretty sure of the other 50% 17:16:31 (at least enough for today) 17:16:32 if something is generated 17:16:50 by a pom file should classify as an artifact subject 17:16:54 to maven release process 17:17:01 #info it appears as though we will need to have some offline discussion about how to cut non-OSGi-bundle artifacts as part of the release 17:17:06 so i'm discussing this process right now 17:17:20 correct colindixon 17:17:30 so edwarnicke 17:17:35 the prepare-only 17:17:41 must be able to push those commits 17:17:44 just not on master 17:17:51 the prepare-only autogenerate a branch 17:17:59 that can later on be disposed at will 17:18:03 and leaves no tracks 17:18:23 this is extremely important because this way the real thing 17:18:30 would almost surely work 17:18:40 GiovanniMeo: good, it seems like we have a good link and understanding of how to cut OSGi bundles 17:18:46 it seems like Konstantin has a question about IT 17:18:55 no that is rovarga 17:18:58 and i answered that 17:19:01 ok 17:19:06 all IT should be executed 17:19:19 as part of that jenkins job 17:19:21 good 17:19:26 yes 17:19:27 We don't have automative IT. 17:19:37 in that case no issue 17:19:43 We need to install controller for running IT. 17:19:44 in a nutshell 17:20:01 you just need to run the "mvn clean install" 17:20:02 ok, I'm going to ask for a last call on this topic and move on 17:20:06 during prepare phase 17:20:13 ok 17:20:15 sorry :) 17:20:20 it's important, but we have other things too, does anyone else have things they want to resolve on this right now? 17:20:31 (then answer can be yes) 17:20:54 going once 17:21:00 going twice 17:21:07 ok, next topic 17:21:09 Can the next topic be scheduling actual artifact cutting time for next Monday? 17:21:18 sure 17:21:26 #topic scheduling time for artifact cutting on monday 17:21:37 edwarnicke: floor is yours 17:21:37 I think we need to work out a start time 17:21:50 Expectations for around how long we expect it to take (best case and worst case) 17:21:53 is after the 9a sync a bad idea 17:22:07 And get specific folks signed up from each project, plus tykeal, plus some integration folks to rerun testing etc 17:22:20 plus GiovanniMeo :) 17:22:26 Totally :) 17:22:26 as soon as I know the time I'm sticking it on my calendar ;) 17:22:27 i cannot be there 17:22:44 sorry but there is Cisco Live on 17:22:55 ah. just give us ur cell phone # ;) 17:23:01 hehe 17:23:02 i will be there after 9am 17:23:21 So lets look at the times globally for 9am PST on Monday 17:23:24 Madhu you have my cell# 17:23:26 :) 17:23:39 j/k GiovanniMeo u know that 17:23:50 That's 6pm in Europe 17:23:56 2am in Tokyo 17:24:06 7pm in Tel Aviv 17:24:14 edwarnicke: the release cutting must go in sequence 17:24:21 with yang tools, controller,, etc... 17:24:29 if we schedule them appropriately, that will work 17:24:32 1am in Taipai 17:24:42 edwarnicke: ugh 17:24:51 do we really have to be that strict? 17:25:00 could we start releasing 17:25:04 as soon as possible 17:25:08 +1 17:25:10 see once you get this right 17:25:17 we have to release yang tools and controller asap. 17:25:17 you can try many times 17:25:20 in fact 17:25:23 this will also avoid breakages. 17:25:28 this should be done every week in my opinion 17:25:29 like the ones we are having now :( 17:25:30 ok all, I need to run to an 11:30 local time meeting - will come back and look at minutes later 17:25:43 this way we avoid last minute issue 17:25:49 thanks regXboi 17:25:57 because will be an all week long issue window 17:26:23 well we can dry-run it the same way prepare does it off master, can't we 17:26:27 so, do we have the dependency tree? can we try to get the bottom of the tree released this week? 17:26:30 except pushing the artifacts ... 17:26:36 and then have mostly/all leaves for 1/27? 17:26:39 question guys. how ready is yang tools ? 17:26:46 rovarga indeed 17:26:49 if it is ready, then we can start cutting a release of it right away 17:26:56 once you get prepare-only passed 17:26:58 the IT needs rework 17:27:00 colindixon: Latency is the enemy 17:27:01 you can also just release 17:27:06 and there's a slew of bugs I think 17:27:12 That's why it was decided to do it all on 1/27 17:27:14 that would be a re-release 17:27:16 Together 17:27:16 fair enough 17:27:23 the idea is that 17:27:29 edwarnicke: it sounding like it's going to be hard unless we can slot projects into time windows 17:27:34 we don't have to do a bing-bang approach 17:27:38 so the question is how willing are the projects seeing an interim release of yangtools 17:27:51 Except if anything goes wrong at all, we need everybody on hand for low latency fixing 17:27:52 rovarga i would love 17:27:55 (e.g. right now everybody is lined up for YT going for a 0.6.0 release) 17:28:05 see the normal behavior should be 17:28:07 interim releases are a very bad idea at this stage for the following reasons: 17:28:08 to have folks that 17:28:17 only depends inter-project on release 17:28:22 the more we have the better it's 17:28:24 1) It violates expectations set from the last few weeks at the last minute 17:28:44 2) It reintroduces version skew 17:28:46 edwarnicke: else.. we will be breaking controller till the last minute ? 17:28:53 am very disappointed today to see it broken 17:28:58 edwarnicke 17:29:00 and my integration with ovsdb is not working now 17:29:13 SNAPSHOT dependencies are the bad things 17:29:14 so, i need a stable version at least 2 weeks prior to the release 17:29:33 Which we cannot fix sanely till after Hydrogen 17:29:39 sorry i could not voice early but i have been telling this one since few months 17:29:40 As was previously discussed and agreed 17:29:53 GiovanniMeo: Which is how we wound up in version skew hell 17:29:57 #info trying to find a time and a plan to start cutting artifacts with people on IRC so that we can find who we need when things go wrong 17:30:04 edwarnicke: practical problems show up like these. 17:30:13 we need to address it. 17:30:19 if we wait till 01/27 17:30:19 skew hell is now covered 17:30:23 I think that 9am should work for everyone except Tokyo and Taipai 17:30:23 by the version-changes job 17:30:26 Taipei 17:30:30 that was not there before 17:31:05 anyway this is just my point 17:31:10 GiovanniMeo: edwarnicke i feel that we need a stabler version now. 17:31:17 to have any sort of integration to be successful 17:31:24 #info we'll start at 9a PST and will reach out to others to make sure that we can get people on hand. there are some worries about tokyo (where it will be 2a) and taipei (where it will be 1a) 17:31:25 else it is a wild goose chase 17:31:29 Guys... it is way to late in the release process to be changing to rules o engagement now 17:31:40 OK 17:31:57 I think we should set expectations at about 4 hours 17:32:02 edwarnicke we are only suggesting to run what you would do on 27th 17:32:02 edwarnicke: then what is ur proposal to break the integration issues ? 17:32:03 For duration 17:32:04 before 17:32:20 and then on 27th 17:32:47 #info edwarnicke thinks it should take ~4 hours from then 17:32:52 GiovanniMeo: do you have a dryrun job for the real release-cutting? 17:33:05 yes it's prepare-only job 17:33:08 i sent before 17:33:15 https://jenkins.opendaylight.org/controller/job/controller-bulk-release-prepare-only/configure 17:33:17 #action somebody needs to reach out to all projects and make sure that they will have a representative there during that time and if not, when they will and how will will make that work 17:33:27 And get the name of that person 17:33:32 phrobb: Could you do that? 17:33:48 yes, sign phrobb to do that wrangling 17:33:51 colindixon: edwarnicke are u guys getting my messages at all ? 17:33:56 Madhu: 17:33:57 and hear my lament ? 17:33:58 yes 17:34:00 I do 17:34:04 I'm thinking about how to put it here 17:34:06 it doesn't seem like it 17:34:27 Madhu: I almost completely agree with you 17:34:33 am so pissed test to see the integration completely broken 17:34:38 how are we going to tackle this 17:34:41 what I'm hearing from rovarga and edwarnicke is that they say they can't start before 1/27 17:34:45 which also worries me 17:34:48 if we change the base code so dramatically till the last minute ? 17:34:53 GiovanniMeo: but that does release:prepare ... do you have one that does release:perform? 17:35:08 you don't want the release:perform 17:35:17 that is the one that does the deploy 17:35:22 Madhu: I hear your lament, and am actually taking action to try to figure it out 17:35:29 once you do the deploy you have issues 17:35:30 edwarnicke: thanks for that. 17:35:37 Rather than pushing to rewrite the entire plan at the 11th hour 17:35:38 but there will be another issue tomorrow 17:35:43 and another next day 17:35:47 we cannot do integration like this. 17:35:50 #action phrobb will reach out to all projects to get somebody to be online for the release cutting event 17:35:51 Madhu: We don't even know what hte issue is 17:35:57 edwarnicke: that is the prpoblem 17:36:01 we don't even know the issue. 17:36:05 Until you know the root cause, you have no idea what is going on 17:36:11 colindixon: we'll go back and see when we can be ready for release cutting (with a reasonable bug backlog) 17:36:13 i know it was working last week 17:36:26 And I would point out, that historically, the issue at root has not been what you have pointed to at first pass 17:36:33 I know it was working last night 17:36:33 rovarga consider that you don't have to worry about what bugs are there 17:36:36 because on 1/27 17:36:41 we will re-release 17:36:43 I was running it 17:36:47 and get all the bugs in 17:36:48 rovarga: when u say we, which project is that ? 17:37:01 Madhu: yangtools ;-) 17:37:04 we can start the release projects per-project based on the dependency tree 17:37:08 ah yangtools. 17:37:13 shiat :( 17:37:16 wait, GiovanniMeo are we still fixing bugs up until 1/27? 17:37:40 that is a per-artifact question 17:37:49 I though there was a general consensus that things that weren't breaking tests in practice were mostly not being coded on anymore 17:37:51 maybe I'm wrong 17:38:00 not on the ones i'm working on 17:38:06 but otehr components are way more active 17:38:20 colindixon 17:38:26 this means that 17:38:32 starting to do some real release 17:38:35 before 1/27 17:38:38 should be possible 17:38:43 without loosing too many bugs 17:38:54 and avoid last minute big-bang effect 17:39:15 sorry not willing to hijack the plan 17:39:30 #info Madhu is worried that by still working on code and having versions in flux until 1/27 we may have trouble when it comes to doing integration then more than we expect. colindixon agrees, but there's a lot of discussion about what can be done to try to make this better. 17:39:34 just putting some point on the table 17:39:55 folks feel free to -1 -2 them 17:40:11 #info GiovanniMeo and Madhu suggest doing some real releases before 1/27 to try to reduce some of this pain 17:40:23 #info rovarga seems to be willing to see what can be done for yang tools 17:40:31 trying to summarize things 17:40:34 thx colindixon for summary 17:40:40 very accurate 17:40:43 in few words 17:40:55 colindixon: thanks 17:41:05 and sorry guys about my lament. its getting very frustrating 17:41:42 #info Madhu points out (and some others agree) that cutting release artifacts twice (once before 1/27 and once on 1/27) could be dangerous and so if we cut before, we'll need to (carefully) decide whether we allow bug fixes and another release on 1/27 17:41:47 What pain? The only report I have is of one bum Jenkins artifact 17:41:57 That is unreproducable on local build 17:42:03 And is failing to log on a bunch of other things 17:42:25 And points to a Jenkins level issue, not a a code level issue if you actually bother to investigate before pointing fingers 17:42:32 edwarnicke: 17:42:41 we will be releasing only from the jenkins build 17:42:44 not form the local builds 17:42:50 Madhu: Which means we need to debug it 17:42:53 and local builds are all not trust worthy 17:42:55 edwarnicke my point is different 17:42:56 I'm going to say that we've made as much productive progress as we can here, I think that GiovanniMeo, Madhu, rovarga and others can meet offline (hopefully today) to see if we can get some early releases of some artifacts going 17:43:10 and when 17:43:16 the release itself when done first time 17:43:20 may go wrong 17:43:20 Please also note, that the Jenkin's build Madhu is complaining about lacks indicative logs from lots of systems, many of which have not been touched recently 17:43:26 so doing twice would be better 17:43:34 GiovanniMeo: Which is why we are doing it togther 17:43:43 on 1/27 17:43:52 edwarnicke: when are we going to integrate ? 17:43:53 And as expectations project wide have been set there for weeks 17:43:55 but it may not be possible to do together 17:44:09 because there is a delta needed 17:44:13 Integration is ongoing (see continuous integration builds) 17:44:21 edwarnicke: it is failing every other day. 17:44:22 for a project to adapt to another releases versions 17:44:25 because of SNAPSHOTS 17:44:29 Madhu: When? 17:44:43 colindixon feel free to kick us out 17:44:47 i can send a list. 17:45:01 The only failure I am aware of in the last few weeks was because of the removal of the bgpcep dependency *you* insisted on 17:45:04 And was fixed within hours 17:45:07 Over a weekend 17:45:12 ok, this clearly needs to be resolved 17:45:22 but this isn't the most productive venue right now 17:45:23 A list where you actually bothered to figure out what happened rather than simply pointing fingers? 17:45:33 edwarnicke: that was a mistake to begin with 17:45:36 anyways. 17:45:48 * colindixon mutes Madhu and edwarnicke for a bit without judging 17:45:49 Because historically, the root cause is *not* what you pointed to (see the nexus stuff for an example) 17:45:50 am trying to get some ideas on releasing artifacts soooner 17:45:51 and why 17:46:06 * colindixon will mute with judging soon though :p 17:46:13 #topic documentation 17:46:15 * Madhu mute 17:46:28 can I mark the templates for user and developer guides as done? 17:46:30 I think I can 17:47:12 colindixon: Quick question on that topic 17:47:19 One question that has come up repeatedly 17:47:21 actually, it appears to nod be on the wiki 17:47:30 Is *where* to do the work based on those templates 17:47:39 You had looked into transclusion 17:47:39 I think the wiki 17:47:48 Right, but *where* on the wiki 17:47:49 In what way 17:47:54 are we using transclusion 17:48:13 transclusion is complicated since you have to include an entire page, so it results in lots of little pages 17:48:30 I think that, at least for now, having one set of docs per release is probably more sane 17:48:49 colindixon: Could you get that place up so folks can work on it? 17:48:57 #action colindixon to hunt down somebody to help him get the templates on the wiki and send an e-mail saying where they are and how to make those docs real 17:49:00 And pointed to from the Hydrogen Release Readiness page? 17:49:04 yup 17:49:11 #topic external versions 17:49:15 In the OpenFlow plugin meeting today - there was a concern raised that documentation may not be done till Jan 29 as most developers will be on bug fixing till 1/27 17:49:21 this is still not marked as done, Madhu are we up on this? 17:49:56 have we identified the key external dependencies and tried to get them as synced 17:49:57 colindixon: external versions i gave my comments the other day 17:50:10 I think few others wanted to pursue it still 17:50:15 ok 17:50:34 #info in the last meeting we largely agreed that we would try to avoid syncing external versions unless they were actively causing problems 17:51:03 #action Madhu will mark this as done until test failures on the spreadsheet 17:51:11 colindixon: when appropriate I have a conversation related to log levels I'd like to have 17:51:20 #topic download page 17:51:29 shague_ and phrobb, how are we doing on this? 17:51:41 in terms of both the actual page and identifying downloadable objects 17:52:07 I'm now beating on the marketing folks to have a mockup/template ready for our review… I should hear shortly 17:52:09 Posted wiki with current results: https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:DownloadableReleaseArtifacts 17:52:09 edwarnicke: noted, but I might push it to tonight/tomorrow b/c of times unless it's critical 17:52:23 Still investigating virtualization and service provider editions with projects like Defense4All, opendove and VTN 17:52:29 #link https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:DownloadableReleaseArtifacts shague_'s summary of what we're actually releasing 17:52:46 shague_: i will send you some info on opendove objects -- we have several 17:53:20 or can just update the wiki if that's better 17:53:23 #info shague_ is still following up with projects, Defense4All, OpenDOVE and VTN among them, but will ask for help if he's nog getting the responses he needs 17:53:44 Ashaikh: keep Chris Price in the loop - he is driving the virtualization and service provder parts. 17:53:47 #info phrobb is working with marketing people to get a mockup of the download page up, will give results when he has them 17:53:56 shague_: will do, thanks 17:54:04 ok 17:54:12 that all sounds like it's going well, but will need a few more days 17:54:44 do you guys think tomorrow or wed is a good date to set 17:54:58 ? 17:55:08 There are extra little things thatneed to installed or tweaked that we ahve not found yet. 17:55:25 so, is wednesday reasonable? or do you need more time 17:55:37 I need to get with Chris since he was driving these parts. But we can shoot for that as a date 17:56:07 #action shague_ to chat with chris price and see when a reasonable deadline is and mark it in the spreadsheet 17:56:20 #topic testing with -of13 (both integration and project) 17:56:33 LuisGomez: do we have the continuous IT with -of13 working? 17:56:52 LuisGomez: And if so, which are the jobs we should be looking at and what do they represent? 17:56:53 yes 17:56:59 at least for RESTCONF 17:57:15 also, I made a list of which projects had anything listed about testing with -of13 and none even had anyone assigned 17:57:15 we will include some NSF test this week 17:57:33 #link https://wiki.opendaylight.org/images/5/55/Odl-release-sync-agenda-9a-01-20-2014.pdf agenda showing the per-project status for testing with -of13 at the bottom 17:57:52 LuisGomez: can you mark that item as DONE in the spreadsheet then 17:57:54 ? 17:58:11 what projects are planning to integrate with of13? 17:58:19 and if so, have they started on test? 17:58:29 colindixon:still working on adding more tests to -of13 option 17:59:00 LuisGomez: Are we running the existing tests with the -of13 flag? 17:59:06 #info LuisGomez says that the continuous IT for -of13 are set up, but they are continuing to add more tests 17:59:20 yes 17:59:30 let me point the jenkins job 17:59:57 #link https://jenkins.opendaylight.org/integration/job/integration-csit-base-of13/ 18:00:13 edwarnicke, rovarga, michal_rehak, abhijitkumbhare, Madhu, ashaikh 18:00:16 it is running upon changes in controller master or ofplugin master 18:00:21 and all other project leads 18:00:27 if you're planning to integrate with -of13 18:00:34 LuisGomez: That looks like its passing all the tests so far? 18:00:35 please assign somebody to making sure it works and try testing 18:00:50 ed: yes 18:00:52 colindixon: that is exactly am running into issues 18:00:54 #info we are testing the controller with -of13 and all current tests though (see link above) 18:01:05 colindixon we are the -of13 option :-) 18:01:19 yes, sorry 18:01:34 yang tools, ofplugin and openflowjava I'm assuming are n/a 18:01:57 We have also plan to test -of13 option with VTN, OVSDB and Affinity before the end of the week 18:01:58 #info ovsdb (Madhu) is trying to integrate with -of13 and running into some issues 18:02:13 #info Ed Warnicke is on it 18:02:26 #info LuisGomez plans to test -of13 with VTN, OVSDB and Affinity before the end of the week 18:02:28 working with Madhu to drill down to root cause 18:02:31 for opendove, we are not planning to do -of13 testing since we don't have OF protocol dependency 18:02:42 ashaikh: can you mark it as n/a then? 18:02:50 yes, i think we did that last night 18:02:59 LuisGomez: can you update the spreadsheet with the status here? 18:03:07 marked "done , N/A" 18:03:20 ashaikh: sweet, I must have missed it 18:03:26 #info it would be good if projects like VTN, OVSDB and Affinity test with -of13 18:03:32 yes 18:03:44 colindixon:yes 18:03:57 #action LuisGomez to update the spreadsheet with an appropriate status for tracking this progress, but it sounds like it's good progress 18:04:01 ok, 18:04:12 I'm going to move on to artifact signing 18:04:21 #topic signing release artifacts 18:04:33 Madhu: I'm guessing this is on the back burner give other things? 18:04:44 I know tykeal was also looking into this 18:04:59 colindixon: yes. i didn't have the time to look @ this yet 18:05:14 colindixon: I did do some, but the k.org signing process won't work for us, at least not at present 18:05:27 #info this has been on the back burner because of other issues we're looking into 18:05:33 tykeal: Is it the web of trust vs root of trust thing? 18:06:00 #info it seems like we might start investigating the easiest possible way to do this which is just publishing hashes of artifacts on a non-editable webpage 18:06:04 edwarnicke: sort of, k.org actually has their releases signed by the person releasing. There is no central build like we've got 18:06:12 so the WoT is very much a requirement there 18:06:37 ok, is there anything else that people *have* to go over now 18:06:37 tykeal: Could it be adapted to a root of trust model? 18:07:13 edwarnicke, tykeal: is there any reason why we can't decide to punt here and try to do something easier with published secure hashes? 18:07:15 for us to do the signing, it needs to be signed before it goes into Nexus, which means Jenkins needs to sign it, which mean we've got to either a) have someone bang on manual job that requests the GPG key passphrase or B) have no passphrase on the GPG key 18:07:38 tykeal: Neither sound all that awesome 18:07:39 unless somebody wants to volunteer to do this 18:07:42 exacty 18:08:07 also, everyone else, if you have a topic you want to go over other than this, and you feel like it should be now, speak up 18:08:18 colindixon if i may say mine 18:08:20 else I'm going to call this meeting after this winds down (or maybe even a bit before) 18:08:25 i would skip GPG this time 18:08:36 i have tried and couldn't get much further 18:08:50 indeed openflowJ had the gpg section 18:08:58 but during deploy it hanged 18:09:00 so i did remove 18:09:02 yeah, the real problem is that we can't sign it after it goes into nexus... at least not in any sane fashion that I've found 18:09:13 right 18:09:28 #info some good discussion (mostly from tykeal) about possibilities and challenges 18:09:35 but my suggestion is one thing at the time 18:09:48 before lets get a release of artifact successful 18:09:53 #info GiovanniMeo and colindixon both suggest skipping signing for this release and relying on just published secure hashes if anything 18:09:56 then we learn how to sign 18:10:01 I agree 18:10:05 ok 18:10:08 I'm going to end the meeting 18:10:11 going once 18:10:22 going twice 18:10:29 #endmeeting