16:01:35 #startmeeting OPNFV Release 16:01:35 Meeting started Tue Jan 10 16:01:35 2017 UTC. The chair is dmcbride. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:35 The meeting name has been set to 'opnfv_release' 16:01:44 #topic roll call 16:01:51 #info David McBride 16:02:18 #info Trevor Bramwell 16:02:52 #info Maryam Tahhan 16:03:24 #info Justin 16:03:39 #info Uli 16:04:23 Meeting ID? 16:04:33 The one in the GTM app is not working for me 16:04:40 775-124-285 16:04:57 #info Jack Morgan (IRC only - have a conflict) 16:05:23 #info Fatih Degirmenci 16:05:31 #info Gerald Kunzmann 16:05:31 #info Frank Brockners 16:06:01 #info Tapio Tallgren 16:06:06 #info Mark Beierl 16:06:16 #info Stuart Mackie 16:06:23 https://www.gotomeeting.com/join/775124285 16:06:48 dmcbride, Thanks 16:06:59 #info Dave Neary 16:08:21 #info Trevor Cooper 16:10:15 http://testresults.opnfv.org/test/swagger/spec.html#!/spec 16:10:53 #topic Movie status 16:11:32 #info jose_lausuch believes that link to swagger is working 16:11:50 http://testresults.opnfv.org/test/swagger/spec.html 16:11:50 login: opnfv 16:11:51 pwd: api@opnfv 16:13:59 #info jose_lausuch provides credentials on IRC 16:14:29 #action jose_lausuch provide credentials for swagger to prakash via email 16:17:36 #topic followup on MS3 - Installer integration with OpenStack 16:19:00 #info rprakash 16:19:03 dmcbride: I don't know if we don't support v3, I just know it is set to v2 right now...will check 16:23:10 #info uli-k believes that using a common keystone API is necessary for scenario consolidation 16:26:29 functest tries to support v2 and v3 16:26:58 we never know which software people running on our openstack and which API this software requires, we should not only consider our project or official openstack projects 16:27:18 #info dneary concerned that using a common API will lead to using the oldest version, which is contrary to OPNFV goals 16:29:51 #info sergmelikyan says: "we never know which software people running on our openstack and which API this software requires, we should not only consider our project or official openstack projects" 16:29:55 it looks like in keystone, if users are assigned to default domain they use v2, other domains would use v3. I think for Apex our admin user is in default domain. 16:31:47 #info jose_lausuch says: "functest tries to support v2 and v3" 16:32:28 Can we deploy mistral then in an Apex deployment? 16:33:43 #link https://releases.openstack.org/teams/keystone.html 16:33:59 I just have a suggestion that we can list the OpenStack configurations differences automatically. 16:34:12 Mark Beierl: ping 16:34:28 Agree with chigang 16:35:56 #info chigang: "I just have a suggestion that we can list the OpenStack configurations differences automatically." 16:36:13 #info uli-k agrees with chigang 16:37:20 #info trozet says: " it looks like in keystone, if users are assigned to default domain they use v2, other domains would use v3. I think for Apex our admin user is in default domain." 16:39:38 #link https://gerrit.opnfv.org/gerrit/#/c/26769/1/functest/ci/config_functest.yaml 16:39:38 either we do this for *all* or for none of the components 16:39:51 documenting which components and versions are used does make sense 16:40:07 for all scenarios - so we need to run that 58 times. 16:40:20 frankbrockners: for now, we've only agreed to use a common version of OpenStack 16:40:26 API compatibility is a difficult topic. API differences between installers will limit the compatibility of applications running on top. Just like Java, write once, test and debug every where. But installers are simply packaging commercial efforts and delivering them to the community, it is not possible to deviate in a major way. So we will have to live with a degree of uncertainty 16:40:31 trying to harmonize all the components for a release does *not* make sense, because it would be a race to the lowest common denominator and hence stop progress 16:41:37 frankbrockers +1 16:42:15 Greg_E_: for fuel it says that v3 is the default. Do you place your default user in a different domain than default? 16:43:23 #info frankbrockners says: "trying to harmonize all the components for a release does *not* make sense, because it would be a race to the lowest common denominator and hence stop progress" 16:43:40 #link http://docs.openstack.org/releasenotes/keystone/newton.html 16:44:06 #info tallgren agrees with frankbrockners 16:45:13 #info Greg_E_ says: "API compatibility is a difficult topic. API differences between installers will limit the compatibility of applications running on top. Just like Java, write once, test and debug every where. But installers are simply packaging commercial efforts and delivering them to the community, it is not possible to deviate in a major way. So we will have to live with a degree of uncertainty" 16:45:27 Hi Tim, I’ll double check, I know there are some install time options on keystone, I just never bothered to play with them 16:45:44 wondering what is a release, if there is no harmonization, but each scenario has different versions. 16:48:53 #info we should support upgrade to minimum usable version of API supported by OpenStack version say if its Newton supports use 2.0 and move up o 2.1 or 3 as will be supported by Ocata 16:49:31 uli-k: if you are developing new code,you want to start with the latest release. If you do not, you just want something that works. Its not easy.. 16:50:15 exactly i agree 16:50:32 tallgren: but when we release? Should we release scenarios with different versions? 16:51:32 #topic Danube schedule 16:53:13 #info MS5 moved to January 27 16:53:35 #info MS6 moved to February 17 16:54:06 sorry to put the burden on the feature/mano projects, but perhaps minimum API version which they need and a preferred API version would be good 16:55:28 #info fdegir suggests for future releases we have a map of projects to resources so that we can see which projects are impacted by resource disruptions 16:57:47 fdegir: https://wiki.opnfv.org/display/pharos/Huawei%27s+munich+Lab 16:58:18 fdegir: there are available pod in huawei munich lab 16:58:44 #info fdegir and uli-k say that we should allocate critical processes to resources in a way that provides redundancy, so that we don't lose all capability during a resource disruption 17:01:09 #action fdegir propose how to improve lab redundancy and identify gaps and a plan to accomplish 17:02:00 need to leave for another meeting 17:02:11 #info jmorgan1 expects to have all Intel resources back online by the end of the week 17:02:41 #endmeeting