14:00:07 #startmeeting oslo 14:00:10 Meeting started Mon Jul 3 14:00:07 2017 UTC and is due to finish in 60 minutes. The chair is gcb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:13 The meeting name has been set to 'oslo' 14:00:21 courtesy ping for amotoki, amrith, bknudson, bnemec, crushil, dansmith, dhellmann 14:00:21 courtesy ping for dims, dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb 14:00:21 courtesy ping for GheRivero, haypo, jd__, jecarey, johnsom, jungleboyj, kgiusti 14:00:21 courtesy ping for kragniz, lhx_, lifeless, lxsli, Nakato, ozamiatin, rbradfor 14:00:21 courtesy ping for redrobot, rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak 14:00:23 courtesy ping for stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek 14:00:30 ./ 14:00:53 o/ 14:00:59 o/ 14:01:02 o/ 14:01:07 o/ 14:01:40 amrith, kgiusti ,dims, daidv_, namnh \o/ 14:01:46 #topic Red flags for/from liaisons 14:02:28 nothing from trove 14:03:10 amrith, ack, thanks 14:03:12 o/ 14:03:52 hi lhx_ 14:04:06 hi, gcb 14:04:10 I found there is only one failure for cinder in http://logs.openstack.org/periodic/periodic-cinder-py27-with-oslo-master/7e3a366/testr_results.html.gz 14:04:22 will check it later 14:04:39 gcb, I will try it later 14:04:54 lhx_: thanks 14:04:58 #topic Releases for Pike 14:05:36 master: https://review.openstack.org/479823 14:05:37 stable/ocata: https://review.openstack.org/479116 14:05:37 stable/newton: https://review.openstack.org/476017 14:08:20 will release for stable branch at least one time each month 14:08:41 #topic Stuck Reviews 14:09:21 we have many doc-migration patches ready for approval, just check https://review.openstack.org/#/q/status:open+branch:master+topic:doc-migration 14:09:51 dims: dhellmann has many patches which need +A :-) 14:10:11 ouch, that's a lot 14:11:16 dims: it's easy to review if you follow the instructions in https://etherpad.openstack.org/p/doc-migration-tracking 14:11:24 ah it's everything (all projects). added is:watched to get a subset of them 14:11:37 thanks gcb 14:12:11 namnh, around ? 14:12:27 gcb: yes, I am here 14:12:49 can I start our topic? 14:12:52 namnh, It's your turn :-) " How to generate a new configuration for (N+n) (n>=2) relase from the exist configuration at N release" 14:13:05 please go ahead 14:13:28 gcb: I and daidv_ come from the upgrade team of Fujitsu, we are interested in skip release upgrade 14:13:37 especially how to generate new compatible configuration for (N+2) release from exist our system (N release). 14:13:59 gcb: so our idea is to develop a tool in oslo.config that can generate a new configurations for (N+2) release from old config (N release) and a config-mapping file 14:14:29 No matter where our configurations is locating (file or etcd) and no matter how we are managing config version (Confd or so on). 14:14:42 We have read the malling-list that discuss about etcd and confd but even when we have multi backend support or not, have plugable driver like confd or not, we should support operator generate reliable new configuration from old release 14:15:05 For instance, we have config-mapping file at *Pike* release and keystone.conf at *Newton* release, with this tool, we can generate keystone.conf for Pike. 14:16:12 how do u think about it? 14:17:51 namnh, that's is an interesting function. I think I get your point 14:18:39 gcb: great, so how do you think about this idea? 14:20:51 namnh: what' s your plan to implement it, I think we have some existing functions to support your idea like config-genrator 14:21:40 we knew that we can use yaml file is created by oslo-config-generator instead of config-mapping file in the near future in case we can declare full info about what options is replaced by something else like below link. 14:21:58 #link https://github.com/openstack/keystone/blob/43362700d8c52b2af0ebae8593cad57c968df377/keystone/conf/eventlet_server.py#L26-L37 14:23:08 gcb: I and daidv_ are colleague 14:24:26 we also have been doing some related work like https://review.openstack.org/384559 , which can collect deprecated config options 14:25:05 just make sure we can leverage existing function :-) 14:25:34 namnh: do you have the link of ML about the discussion 14:27:23 dhellmann, around, what do you think namh and daidv_ 's idea ? 14:28:09 gcb: for the malling-list, I am reading this malling-list: http://lists.openstack.org/pipermail/openstack-dev/2017-June/117943.html , is that your link? 14:29:06 gcb: For "related work like https://review.openstack.org/384559", we also thought about that. But I think we have not have completely list Opts for deprecated config. 14:31:13 in case we want to generate new configurations (from M to P for instance), we can loss some configs. 14:31:45 s/loss/lose/ 14:32:08 daidv_: please check https://review.openstack.org/#/c/451081/, its blueprint describes will list deprecated options 14:34:33 gcb: I have tryed it to gen yaml file for some projects. 14:34:58 daiv_, namh: have you any details about how to implement the function ? I suggest post a commit to oslo-specs to describe the proposal 14:35:40 then, we can discuss the details in the review. In general , I like your ideas ,need more input 14:36:10 to decide how to implement it :-) 14:37:23 gcb: but as I said "we can lose some configurations." if we want to upgrade from N to N+5 or more. 14:38:23 gcb: let me overview this idea. we will create a config-mapping for each project, it's formal maybe is yaml 14:39:31 and the config-file can be maintained by each projects 14:39:58 that they are expert in the project 14:40:43 and another input is config file like keystone.conf at old release 14:40:51 gcb: 14:42:35 the import thing is the config options' value, which version of code your tools will scan ? N+2 or N code ? 14:43:27 gcb: N+2 14:43:59 we always got the config options list for each version with oslo-config-generator 14:44:50 how the config-file will be used ? 14:46:45 gcb: sorry for my mistable. I mean this sentence "and the config-file can be maintained by each projects" is "and the config-mapping can be maintained by each projects" 14:48:40 namnh, I didn't read the ML discussion before. the problem is got N+2 config options' values ,right ? 14:49:54 namnh, "we can lose some configurations." means the values of configurations, right ? 14:52:35 gcb: yes, you are right, that why we need two inputs: one is config-mapping at new release and one is config-file at old release. 14:53:31 gcb: to generate a new config file for new release 14:54:24 what's information in config-mapping ? the values of config options should depend on each deployment, I don't think one config-mapping can handle it 14:55:31 gcb: config-mapping is the same idea with yaml file which generated by oslo-config-generator 14:56:38 but oslo-config-generator depend on deprecated configuration name in each Opt() 14:59:12 hmm..., the meeting time is over, let's discuss at #openstack-olso 14:59:39 #endmeeting