15:00:49 #startmeeting OPNFV Infra Working Group 15:00:49 Meeting started Wed Jun 8 15:00:49 2016 UTC. The chair is jmorgan1. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:49 The meeting name has been set to 'opnfv_infra_working_group' 15:00:57 #info Jack Morgan 15:01:33 waiting for Dan to join GTM 15:02:11 #info Trevor Cooper 15:02:25 #info Mark Beierl 15:02:42 o/ 15:02:53 attempting to join GTM from my linux box... not sure if this is going to work 15:03:02 mbeierl: worked for me in theory 15:03:09 waiting on organizer 15:03:11 ah there it goes 15:03:14 oooh. It's starting 15:03:21 but I had to call in. 15:05:04 is the infra call on todaY? 15:05:11 yes 15:05:18 bryan_att: yes, it's started on GTM 15:05:20 "waiting for the organizer" 15:05:25 #link https://global.gotomeeting.com/join/647390853 15:05:30 should be started 15:05:37 #info Julien 15:05:53 #info Yujun Zhang 15:06:39 #info Yolanda Robla 15:06:47 #info Leif Madsen 15:06:52 #info Bryan Sullivan 15:07:32 please add 1400 UTC to the time info on the page 15:08:03 #info Pharos JIRA scrub on Friday 7am (PST) 15:10:17 CENGN 15:13:55 #info status update for harware requirements for senario owners - David Mcbride 15:18:43 #info David asks for senario owners to define hardware requirments on Colorado scenrio and dependencies page - top table 15:18:56 sorry I lost the voice 15:19:32 #info chris price, late as usual. 15:36:45 #info discussed what needs to be done for preparation of OPNFV Summit 15:37:29 ChrisPriceAB: https://wiki.opnfv.org/display/SWREL/Test+Release+Criteria 15:38:16 #info discussed CENGN lab status - its operational and what needs to be done 15:43:18 +1 on the usefulness of the lab for dev testing even if not ready for CI. I think it's great that new labs come online - we need them. 15:43:58 I'm interested in this question also. shall we make these rules and all the lab owner can find the gap and deal with it. 15:46:00 how to define a CI lab? what's the requirement 15:47:24 Julien-z_: 24x7 availability for a pod to become CI POD 15:47:35 Julien-z_: hands off 15:47:45 Hi, I work for Orange Lab Paris and i search some good example of rst files to describe our platform 15:48:04 you can't take it offline on your will, without advance notification 15:48:22 fdegir, ZTE labs has been working for CI for half a year:) 15:48:30 and obviously jenkins connection 15:48:40 besides upgrade or troubleshooting 15:48:56 Julien-z_: but you are running certain stuff 15:49:19 Julien-z_: fuel + yardstick with a certainscenario 15:49:25 we have several PoDs, one of them is dedicated for CI 15:49:33 ci pids run any scenario for an installer 15:49:47 #agreed Criteria for listing a lab on Pharos page at this stage 1) CI POD - must be connected to Jenkins and visible on dashboard 2) Dev POD - must have clearly documented procedure for remote access and be willing to have community connect with agreed schedule 15:50:06 please comment Lincoln and Fatih (and otehrs) 15:50:08 Julien-z_: then we can definitely have that pod in candidate 15:50:11 thanks trevor_intel_ 15:50:39 and mark it as ci pod 15:50:43 thanks for fdegir for clearance. 15:50:52 will ping you back 15:51:30 #info discussed signing artifacts - opnfv key or not? 15:51:47 which pod it is? 15:51:56 on jenkins? 15:52:07 last one:) 15:52:21 #info agreed that we don't need opnfv master key at this point 15:52:29 fdegir: and mark it as CI ... means how is it marked ... means dedicated 24/7? 15:52:53 trevor_intel_: adding to table 15:53:06 fdegir: ok 15:53:07 and reserving it for an installer 15:53:14 another 2 are on the road to the community 15:53:23 and running any scenario full time 15:53:27 #info 5th installer discussion from TSC meeting 15:53:35 we are preparing the resources required by community. 15:53:52 PoDs have been setup. 15:54:19 #agreed In addition criteria for CI POD is that it is marked as CI (Wiki table) and should be dedicated for CI (available 24/7) 15:54:44 fdegir: did I get it right? 15:56:18 OPNFV needs to be careful not to block the integration of new key tech, e.g. Kolla as a deployment tool, just because we have a grandfathered set of installers with POD reservations. Containerized OpenStack etc is a key evolutionary step that will happen. OPNFV needs to be part of the solution, not a blocker. 15:59:09 #info TSC readout discussion on hardware and software resources 15:59:11 I would encourage the existing installer projects to propose an alternative, e.g. developing Kolla support vs bare metal as an option, if they want us to continue to reserve POD space for them. It wont work to say "we have no lab space, you can't evolve the infra management process" 16:01:25 +1, I got also the same feedback 16:06:37 I also suggest automation is the mininum requirement. the iso must been tested by CI 16:10:51 have to go .. bye 16:12:18 it's too late to change the rules that we have been operating under since Arno. In order to make progress, we need to be able to support post-install features as part of the release. 16:14:52 no question about post install features bryan_att. In fact no question about developmental work, but in Brahmaputra we discussed labeling of features quite a lot in the context of our delivery and this likely needs to be revisited/refined. 16:15:24 At the end of the day we did not capture that in our documentation, but we have a good chance to do so for Colrado. 16:15:24 I'm not sure what labelling features means. 16:17:05 well if a feature is not enabled in CI, and has no supporting test cases that are integrated in our test reporting systems it is not handled on stable in the same way as CI integrated features and as such does not receive the same level of support. 16:17:19 What I object to is the assertion that quality work cannot be verified unless its part of CI. The installer projects and Pharos should not be a barrier to the collaborative process in OPNFV. Certainly CI is a goal, but we have to make incremental progress toward it in some cases. 16:17:41 #endmeeting