14:00:07 <gcb> #startmeeting oslo
14:00:10 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'oslo'
14:00:21 <gcb> courtesy ping for amotoki, amrith, bknudson, bnemec, crushil, dansmith, dhellmann
14:00:21 <gcb> courtesy ping for dims, dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb
14:00:21 <gcb> courtesy ping for GheRivero, haypo, jd__, jecarey, johnsom, jungleboyj, kgiusti
14:00:21 <gcb> courtesy ping for kragniz, lhx_, lifeless, lxsli, Nakato, ozamiatin, rbradfor
14:00:21 <gcb> courtesy ping for redrobot, rpodolyaka, sergmelikyan, sileht, spamaps, sreshetnyak, sreshetnyak
14:00:23 <gcb> courtesy ping for stevemar, therve, thinrichs, toabctl, viktors, zhiyan, zzzeek
14:00:30 <amrith> ./
14:00:53 <kgiusti> o/
14:00:59 <dims> o/
14:01:02 <daidv_> o/
14:01:07 <namnh> o/
14:01:40 <gcb> amrith, kgiusti ,dims, daidv_, namnh  \o/
14:01:46 <gcb> #topic Red flags for/from liaisons
14:02:28 <amrith> nothing from trove
14:03:10 <gcb> amrith, ack, thanks
14:03:12 <lhx_> o/
14:03:52 <gcb> hi lhx_
14:04:06 <lhx_> hi, gcb
14:04:10 <gcb> 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 <gcb> will check it later
14:04:39 <lhx_> gcb, I will try it later
14:04:54 <gcb> lhx_: thanks
14:04:58 <gcb> #topic Releases for Pike
14:05:36 <gcb> master: https://review.openstack.org/479823
14:05:37 <gcb> stable/ocata: https://review.openstack.org/479116
14:05:37 <gcb> stable/newton: https://review.openstack.org/476017
14:08:20 <gcb> will release for stable branch at least one time each month
14:08:41 <gcb> #topic Stuck Reviews
14:09:21 <gcb> 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 <gcb> dims: dhellmann has many patches which need +A :-)
14:10:11 <dims> ouch, that's a lot
14:11:16 <gcb> dims: it's easy to review if you follow the instructions in https://etherpad.openstack.org/p/doc-migration-tracking
14:11:24 <dims> ah it's everything (all projects). added  is:watched to get a subset of them
14:11:37 <dims> thanks gcb
14:12:11 <gcb> namnh, around ?
14:12:27 <namnh> gcb: yes, I am here
14:12:49 <namnh> can I start our topic?
14:12:52 <gcb> 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 <gcb> please go ahead
14:13:28 <namnh> gcb: I and daidv_ come from the upgrade team of Fujitsu, we are interested in skip release upgrade
14:13:37 <namnh> especially how to generate new compatible configuration for (N+2) release from exist our system (N release).
14:13:59 <namnh> 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 <namnh> 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 <namnh> 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 <namnh> 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 <daidv_> how do u think about it?
14:17:51 <gcb> namnh, that's is an interesting function. I think I get your point
14:18:39 <namnh> gcb: great, so how do you think about this idea?
14:20:51 <gcb> 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 <daidv_> 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 <daidv_> #link https://github.com/openstack/keystone/blob/43362700d8c52b2af0ebae8593cad57c968df377/keystone/conf/eventlet_server.py#L26-L37
14:23:08 <namnh> gcb: I and daidv_ are colleague
14:24:26 <gcb> we also have been doing some related work like https://review.openstack.org/384559 , which can collect deprecated config options
14:25:05 <gcb> just make sure we can leverage existing function :-)
14:25:34 <gcb> namnh: do you have the link of ML about the discussion
14:27:23 <gcb> dhellmann, around, what do you think namh and daidv_ 's idea ?
14:28:09 <namnh> 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 <daidv_> 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 <daidv_> in case we want to generate new configurations (from M to P for instance), we can loss some configs.
14:31:45 <namnh> s/loss/lose/
14:32:08 <gcb> daidv_: please check https://review.openstack.org/#/c/451081/, its blueprint describes will list deprecated options
14:34:33 <daidv_> gcb: I have tryed it to gen yaml file for some projects.
14:34:58 <gcb> 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 <gcb> then, we can discuss the details in the review.  In general , I like your ideas ,need more input
14:36:10 <gcb> to decide how to implement it :-)
14:37:23 <daidv_> 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 <namnh> gcb: let me overview this idea. we will create a config-mapping for each project, it's formal maybe is yaml
14:39:31 <namnh> and the config-file can be maintained by each projects
14:39:58 <namnh> that they are expert in the project
14:40:43 <namnh> and another input is config file like keystone.conf at old release
14:40:51 <namnh> gcb:
14:42:35 <gcb> the import thing is the config options' value, which version of code your tools will scan ? N+2 or N code ?
14:43:27 <daidv_> gcb: N+2
14:43:59 <gcb> we always got the config options list for each version with oslo-config-generator
14:44:50 <gcb> how the config-file will be used ?
14:46:45 <namnh> 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 <gcb> namnh, I didn't read the ML discussion before.  the problem is  got N+2 config options' values ,right ?
14:49:54 <gcb> namnh, "we can lose some configurations." means  the values of configurations, right ?
14:52:35 <namnh> 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 <namnh> gcb: to generate a new config file for new release
14:54:24 <gcb> 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 <daidv_> gcb: config-mapping is the same idea with yaml file which generated by oslo-config-generator
14:56:38 <daidv_> but oslo-config-generator depend on deprecated configuration name in each Opt()
14:59:12 <gcb> hmm...,  the meeting time is over, let's discuss at  #openstack-olso
14:59:39 <gcb> #endmeeting