14:00:06 <zhaochao> #startmeeting trove
14:00:07 <openstack> Meeting started Wed Apr 11 14:00:06 2018 UTC and is due to finish in 60 minutes.  The chair is zhaochao. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:10 <openstack> The meeting name has been set to 'trove'
14:00:22 <zhaochao> #topic roll call
14:00:40 <songjian> o/
14:00:46 <fanzhang> o/
14:00:49 <Yao> hi~
14:02:33 <zhaochao> hi, wait for a while to see whether others will show up
14:04:07 <zhaochao> OK, let's start
14:04:13 <Yao> seems zhanggang can't connected to meeting channel, there are some problems in his network
14:04:38 <zhaochao> O, sorry for that
14:04:48 <zhaochao> #topic Rocky goal updates
14:05:40 <kumarmn> hi
14:05:54 <zhaochao> hi, kumarmn
14:06:53 <fanzhang> long time no see from last meeting, lately it seems the trove team is sort of inactive :)
14:07:04 <zhaochao> I was kind of busy in last two weeks, so mox removal from trove-dashboard continues from this week, I submitted two patches yesterday and today
14:07:41 <Yao> Lack of test environment and busy work, slow progress with osc migration
14:07:52 <fanzhang> about nova file injection deprecation, I've submitted the spec for awhile.
14:07:53 <Yao> sorry for that
14:08:18 <kumarmn> I reviewed your proposal for the file injection deprecation.
14:08:20 <zhaochao> Chuck Short also submitted one patch under this topic, so mox removal from trove-dashboard may be completed soon
14:08:53 <fanzhang> yeah, thanks for your big +1 kumarmn  :)
14:09:26 <zhaochao> Yao: that's fine, slow progress is also progress, :)
14:10:17 <zhaochao> fanzhang: for file injection, user data seems to be the solution, detecting existing cloud.init configuration is still not easy
14:10:31 <songjian> There are some gnocchi jobs that need to be processed,there is not much time yet. sorry
14:11:09 <fanzhang> I guess zhaochao is right, I ignored the scenario that maybe we have to support different type of user data for cloud-init. I've committed an update, although I did not have accomplished that yet, but I think it's possible.
14:11:30 <fanzhang> I mean I don
14:11:49 <fanzhang> I mean I don't try it out with code, but I think it would work
14:13:19 <zhaochao> songjian: :) it's fine, we could only participate when we have time and resource,
14:14:14 <fanzhang> all the scripts should start with one line like #!, #cloud-config etc. We can map it with content-types like text/x-shellscript, text/cloud-config. More details here http://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive
14:15:26 <zhaochao> fanzhang: I took a quick look through about the update, the problem is if we don't know the format of the existing config, we need to reimplement how cloud-init parses files
14:16:11 <zhaochao> fanzhang: existing config could be any format cloud-init supports, e.g. it's could also be in MIME multipart format ?
14:16:31 <fanzhang> Then we can use some modules to squash all the existing scripts into one mine multi-part file, like this one https://paste.ubuntu.com/p/Cj6dSHNhdp/
14:16:53 <fanzhang> yes, it could happen
14:17:56 <fanzhang> but IMHO, we can do step by step
14:18:38 <fanzhang> I'd like to hear more from kumarmn and Yao since you all give me +1 earlier. :)
14:20:18 <fanzhang> and as for current *.cloudinit script, I think most operators would just write some #bin/bash script, maybe it's unusual to write a MIME multipart file directly
14:21:32 <kumarmn> https://docs.openstack.org/trove/latest/admin/building_guest_images.html indicates there are 3 ways of injecting files. use_heat, use_nova_server_config_drive and nova_create.
14:21:42 <kumarmn> Are all three getting deprecated?
14:22:38 <zhaochao> heat supporting has been removed already
14:23:23 <songjian> yes,Should the o version be removed?
14:23:37 <songjian> or pike
14:24:10 <fanzhang> I am not sure with use_nova_server_config_drive, but using parameter "files" when doing nova create is deprecated
14:25:37 <zhaochao> use_nova_server_config_drive seems used for userdata, if true, use config-drive, else use metadata service, but I'm not sure about this
14:26:52 <fanzhang> no, me neither.
14:27:44 <fanzhang> but, even if this parameter is existed, it only tells we can pass userdata into instance via config driver, not metadata service
14:28:06 <fanzhang> user data is still passed through --user-data I guess
14:28:27 <fanzhang> by --user-data
14:28:58 <Yao> fanzhang: I received a phone call just now. You mean this one ?https://review.openstack.org/#/c/557583/
14:29:10 <fanzhang> yes
14:30:09 <Yao> I have not seen yet^_^. Will do later
14:30:15 <zhaochao> yes, it's not related to the guest_info and guestagent.conf, these two files are injected by the 'files' parameter of novaclient, i.e. using the personality way of file injection
14:31:39 <zhaochao> fanzhang: so, what about adding a new configuration about cloudinit-format, i.e. asking the operators to specify which cloud-init configuration format they're using
14:34:13 <fanzhang> it can work, but IMHO, we can read the file then process it by program. And we can support only simple format at first, I mean don't support mime multipart file
14:36:52 <zhaochao> fanzhang: OK, this could also be acceptable by now, I also think this bp should be proved asap
14:37:30 <fanzhang> sure, I'd like we're all on the same page :)
14:38:42 <fanzhang> I thought about add Matt, core developer of nova, to help review this spec, too afraid of being mocked 🤣
14:39:52 <fanzhang> another thing is http://lists.openstack.org/pipermail/openstack-dev/2018-April/129254.html
14:40:30 <zhaochao> fanzhang: and another one, although "use_nova_server_config_drive" is not related to this before, but after we switch to user-data, this configuration may do affect, i.e. 'force_config_drive' in the bp may not needed
14:40:53 <zhaochao> fanzhang: but I'm not sure by now, should do more investigation about this config
14:41:30 <fanzhang> kumarmn should we submit a revert patch of  https://review.openstack.org/#/c/527755/ to test if oslo.service is fixed?
14:42:14 <kumarmn> we could try it as a test, and that would be feedback to dims
14:42:32 <fanzhang> zhaochao yes, I am sure about use_nova_server_config_drive, never saw it before. If it could work, the force_config_drive is no long needed
14:42:46 <fanzhang> kumarmn, cool :) will do tomorrow
14:42:53 <fanzhang> I am not sure about
14:44:40 <zhaochao> I also read about discussion today, but this may not be tested easily,  In the gate, we install oslo.service by pip, not by source, and the previous problem seems in senario tests
14:45:35 <fanzhang> so I should or someone else should test it locally?
14:46:07 <zhaochao> I personally think oslo.service could just merge the patch first, and then we could do more investigations about what's failing
14:46:39 <zhaochao> fanzhang: If you have the resource, please try to test it locally
14:46:59 <fanzhang> just run functional test, right?
14:47:22 <fanzhang> functional tests and unit tests
14:47:56 <zhaochao> fanzhang: any of the scenario tests should be OK, unittests may not be affected, but you could try unittests first
14:48:53 <fanzhang> sure, I can do that.
14:49:23 <zhaochao> trove-functional-mysql seems also an scenario test, just like trove-scenario-mysql-single, and trove-scenario-mysql-multi
14:49:49 <fanzhang> so a revert patch is also needed?
14:50:24 <dims> kumarmn : fanzhang : https://review.openstack.org/#/c/558206/ has not merged yet, so not released.
14:50:31 <zhaochao> fanzhang: no, oslo.service in global-requirement has been bumped up for many times
14:51:59 <fanzhang> I am confused. It's not merged yet, then how can I test if it works fine?
14:52:24 <zhaochao> dims: yes, so I personally would like to see the patch merged in oslo.service first, and then try to do some more investigations on how it fails trove gate jobs
14:52:42 <dims> zhaochao : i would love to do that too if you all are ok
14:53:01 <dims> zhaochao : fanzhang : just leave a note on the review that it's ok to do that :)
14:53:42 <zhaochao> fanzhang: for unittests, you could manually merge the patch in oslo.service, and use pip development install mode to install oslo.service in the unittest tox env
14:54:01 <zhaochao> dims: OK, I'll add a review later, :)
14:55:19 <zhaochao> So do we have any other topics today?
14:55:31 <fanzhang> nothing more from my side. Oh, I am sort of curious about maciej and the ocatavia way bp things, is the progress good? LOL
14:56:35 <kumarmn> I will be talking to the folks at Scylla later this week. Not sure whether they have enough skills to write a guestagent.
14:56:56 <kumarmn> If anyone has gone through the process of writing a guestagent let me know.
14:57:16 <kumarmn> Also let me know who all are planning to go to the summit in Vancouver.
14:57:24 <zhaochao> huntxu may be busy on the other project and the internal work these days, I'll talk about the bp with him when appropriate
14:57:32 <kumarmn> zhaochao, I have booked a 'Project update' session for trove.
14:57:39 <fanzhang> why do you want to write a guest agent kumarmn
14:58:09 <kumarmn> I do not. Trying the db developers of scylla to write a guestagent.
14:58:35 <zhaochao> kumarmn: O, I didn't plan for Vancouver summit, sorry for that
14:58:46 <fanzhang> oh, all right, don't know what is scylla
14:59:12 <zhaochao> O, just forget to mention, the next week the rock milestone-1
14:59:20 <kumarmn> also wanted to make you aware that luke browning has written a tool to test patches before merging.
14:59:22 <kumarmn> https://github.com/lukebrowning/tools/tree/master/trove
14:59:41 <kumarmn> So this is one way to test dims patch
14:59:43 <zhaochao> please help to review the current opening patches
14:59:56 <fanzhang> cool kumarmn, thanks
15:00:05 <fanzhang> zhaochao  will do
15:00:06 <zhaochao> kumarmn: got that, thanks
15:00:14 <zhaochao> OK, time is up
15:00:19 <fanzhang> bye :)
15:00:19 <kumarmn> ciao!
15:00:25 <zhaochao> Good night!
15:00:35 <zhaochao> #endmeeting