16:00:30 <mnaser> #startmeeting openstack_ansible_meeting
16:00:35 <mnaser> #topic office hours
16:00:35 <openstack> Meeting started Tue Jun 25 16:00:30 2019 UTC and is due to finish in 60 minutes.  The chair is mnaser. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:43 <mnaser> o/
16:00:53 <chandankumar> \o/
16:00:55 <mnaser> (sorry all, i've been knee deep in octavia...
16:00:59 <mnaser> not a fun time
16:02:24 <guilhermesp> o/
16:02:59 <mnaser> so release stuf
16:03:25 <evrardjp> o/
16:04:12 <mnaser> so
16:04:16 <mnaser> unfortunately the rc didnt go out?
16:04:18 <mnaser> https://review.opendev.org/#/c/666721/
16:04:29 <mnaser> evrardjp: you removed the +w .. anything to note?
16:05:03 <evrardjp> Nope it's convention I am not +w on release right now. It was a mistake I added the +w.
16:05:11 <evrardjp> It's all good
16:05:49 <noonedeadpunk[m]> o/
16:06:19 <evrardjp> thanks noonedeadpunk for stepping up and starting that work
16:09:33 <noonedeadpunk> we've got serious fix from jrosser forkeystone...
16:10:22 <mnaser> this feels never ending, but yes, that is quite serious
16:10:30 <noonedeadpunk> I mean https://review.opendev.org/#/c/667201/
16:10:34 <mnaser> every deploy will destroy all your fernet tokens and credentials.
16:11:12 <noonedeadpunk> and I think once we do release ppl will start their upgrades
16:11:21 <evrardjp> mnaser: this is why we have multiple rcs :)
16:12:53 <mnaser> well i guess we're going to get another one..
16:13:09 <noonedeadpunk> (however upgrade script missing things iirc, but we've decided to live with it until next minor version)
16:16:29 <mnaser> ok so do we feel okay after the keystone thing merges to do another one?
16:18:57 <evrardjp> i am fine with that
16:19:12 <noonedeadpunk> ++
16:19:56 <noonedeadpunk> do we make another one rc, or just directly release with the fresh bump without rc?
16:20:12 <guilhermesp> so is on they way https://review.opendev.org/#/c/667201/ noonedeadpunk has rehecked. Would be the case to just reckick to gate?
16:21:47 <evrardjp> noonedeadpunk: we can do either
16:21:48 <noonedeadpunk> Now there's some problem with infra I think - we're receiving retry limits for the patches
16:22:07 <guilhermesp> yeah noonedeadpunk I've noticed this too
16:22:19 <guilhermesp> and following up in #opentack-infra
16:35:03 <logan-> o/
16:35:24 <mnaser> so i guess that's pretty much it
16:35:27 <mnaser> for stein release
16:35:33 <mnaser> lets try and get those landed and we ..should be ok
16:35:54 <logan-> ++
16:37:03 <evrardjp> I have nothing to add, we can iterate later
16:37:08 <evrardjp> (on that topic)
16:37:48 <logan-> following on the keystone issue, I really question whether smart sources is a pattern we want to stick with. versioning configs on the target nodes doesn't make sense to me, that's what versioned config management is for. and the only way to do a "rollback" to a prior smart sources version is with a bunch of manual operator work; ansible will never use it. even if you check out the earlier tag and run playbooks, ansible is just going to
16:37:48 <logan-> template a new config.
16:38:57 <evrardjp> logan-: what do you propose?
16:38:58 <logan-> we have a pretty straight forward way to back out the smart sources stuff thanks to jrosser's work. is there any reason we shouldn't apply this to all roles so we don't end up with a snowflake keystone role w/o smart sources and <everything else> with it
16:40:26 <logan-> and then, of course, do we backport that to stein or do we convert everyone to smart sources for one release and then back it out in train? i'd lean towards backporting it to stein
16:40:49 <evrardjp> mmm
16:42:11 <evrardjp> my experience with "half baked" (I don't like calling this one like that, but bear with me) is that it was always a pain to deal after the fact, so reverting and backporting is better
16:42:26 <evrardjp> but I am not sure what the problem is
16:43:11 <mnaser> honestly
16:43:20 <mnaser> i would be in favour of reverting all smart sources patches imho.
16:43:31 <mnaser> its overly complex.  and like i explained
16:43:40 <mnaser> if you want to rollback, you would need to rollback your OSA version too
16:43:49 <mnaser> and at that point, you'll get a template generated with the older template too
16:43:52 <mnaser> so the end result is the same..
16:43:52 <logan-> ^
16:43:55 <logan-> yep
16:44:55 <mnaser> i'm in favour of that, but i'd like to hear what others think
16:46:23 <evrardjp> just to know what we want to really revert -- is the location, or the fact  it's from upstream files?
16:47:45 <mnaser> to me the problem that we had was: we maintained a copy of files that were not very dynamic in nature
16:47:49 <mnaser> like rootwrap config, policy, etc
16:47:52 <mnaser> that we always were out of sync
16:47:59 <evrardjp> I am asking that because we'll have to have bump tools in repos now
16:48:16 <evrardjp> so we are at a state where things need to happen in repo regularily anyway
16:48:31 <mnaser> the solution would be to grab those 'static' files from the repo, use "our" overrides, throw them in /etc/$service
16:48:37 <evrardjp> (but not in the backported branches)
16:48:46 <logan-> pretty much everything has moved to policy in code so smart sources doesn't have any bearing on that anymore afaik
16:49:01 <mnaser> logan-: rootwrap rules
16:49:10 <mnaser> but we can still work around those or do a simple cp when venv changes..
16:49:12 <logan-> mnaser: gotcha yep
16:49:12 <evrardjp> logan-: correct, but the policy in code is not the hardest things to maintain
16:49:27 <mnaser> i mean
16:49:33 <mnaser> we dont allow overriding rootwrap rules anyways
16:49:38 <mnaser> so it can just be a task to do a sync with remote_src
16:50:01 <logan-> yep
16:50:15 <evrardjp> I think it makes sense for me to continue shipping things in the role if it's easier and remove some tasks
16:50:33 <evrardjp> because we'll need to have a tooling for taking care of those
16:51:04 <mnaser> evrardjp: so you're saying we continue to maintain a copy inside rather than just cp-ing it from the pkg?
16:51:10 <logan-> i don't mind consuming them from the venv, but we can do it a lot simpler as mnaser by using copy + remote_src when a venv is deployed
16:51:41 <mnaser> i rather maintain tasks that sync these things than maintain jobs and tooling (and responsibility) of syncing them
16:52:05 <evrardjp> mnaser: I am saying that the door is opened to anything
16:52:06 <admin0> guys ..  where do i get data to bill projects in openstack .. is data from openstack usage list reliable
16:52:13 <admin0> or if anyone is selling cloud .. how do you generate billing stuff
16:52:30 <mnaser> admin0: hire people and write code :)
16:52:38 <mnaser> we're in an OSA meeting fyi :)
16:52:44 <admin0> oops .. sorry
16:52:48 <evrardjp> logan-: I am fine with that
16:52:52 <mnaser> jrosser: noonedeadpunk guilhermesp .. thoughts ?
16:52:58 <admin0> they hired me to write code .. i need directions :D
16:52:58 <evrardjp> since we have that in the venv
16:53:29 <evrardjp> if it's not shipped as data files, I suppose we extend the pattern, and we are good
16:53:49 <evrardjp> packagers gonna hate us but it's fine, we did that in the past already :)
16:54:19 <evrardjp> so to summarize: remove smart sources, copy files from venv
16:54:31 <evrardjp> (for those who aren't to customize)
16:55:38 <evrardjp> is that what you are proposing logan-?
16:55:44 <logan-> yes that makes sense to me
16:55:57 <evrardjp> fine for me too
16:57:15 <noonedeadpunk> I think that there might be more files, than just rootwrap and policies
16:57:26 <noonedeadpunk> It was the case for the ceilometer at least
16:57:36 <evrardjp> yes the paste files for example
16:58:01 <evrardjp> and heat stuff iirc
16:58:21 <logan-> noonedeadpunk: yeah, i'm thinking we could make a common task file like we do for db/rabbit which knows how to copy a list of files defined in the role from the venv into somewhere on the system
16:58:22 <guilhermesp> I'm only concerning to the fact we keep those static files out of sync
16:59:13 <noonedeadpunk> I thought we decided to take them from venv, so they are not static, are they?
16:59:18 <evrardjp> guilhermesp: well, if those aren't from the data files of the venv, then we need to carry them. And maintain them. I suppose a bump script would beed to happen then
16:59:36 <evrardjp> noonedeadpunk: maybe not everything is shipped in the venv
16:59:42 <evrardjp> (to be verified)
16:59:50 <noonedeadpunk> yep, not everything for sure
16:59:50 <logan-> then it is probably out of scope in the context of a smart sources revert right?
17:00:06 <evrardjp> well the smart sources did a bunch of things
17:00:49 <noonedeadpunk> And I have concerns about backporting reverts to stein... Isn't it too late for this?
17:01:10 <evrardjp> I am fine for that tbh. If it's bugged...
17:01:40 <evrardjp> logan-: I meant that the revert of the smart sources should be smart and thought of. Not blindly revert all the patches in that topic
17:02:02 <logan-> evrardjp: yeah a straight revert is not possible because we already rm -rf the /etc/<service>
17:02:11 <evrardjp> yeah, on top of that :)
17:02:32 <logan-> right
17:02:56 <evrardjp> but I mean that leveraging the data_files from the venv and the fact to not carry (but template) the policy files are good.
17:03:16 <evrardjp> as far as I can see, all the files we care about are in date_files
17:03:21 <evrardjp> data files
17:05:11 <evrardjp> except ceilometer so it seems
17:05:46 <evrardjp> oh no ceilometer seems fine too
17:07:05 <evrardjp> I am off now
17:07:43 <evrardjp> I just wanted to add the fact I didn't progress as I would like on the OSA jobs using the integrated, but it's looking slowly better
17:08:01 <evrardjp> I will need some help on distro packages stuff
17:08:42 <evrardjp> and my other topic for today was 42.3 removal, and 15.0 to 15.1 move, which are both in progress
17:09:02 <noonedeadpunk> evrardjp: do you have the list of roles that are missing distro installs?
17:09:44 <noonedeadpunk> btw, don't we want to add bionic distro install for integrated checks (non voting) and work on it?
17:10:29 <logan-> noonedeadpunk: i think we did that at one point but no one worked on it so it got removed
17:12:40 <noonedeadpunk> I'll try to spend some of my free time for that, I think then...
17:12:43 <evrardjp> correct that's experimental. But I would like to be consistent everywhere, so it's easier to understand, and expectations are consistent
17:13:45 <logan-> ah yeah I think it got moved from nv check pipeline to the experimental pipeline. so to poke at it you should be able to 'check experimental' in a patch and it will run the job
17:14:14 <noonedeadpunk> oh, great.
17:14:19 <evrardjp> noonedeadpunk: https://docs.google.com/spreadsheets/d/1coiPHGqaIKNgCGYsNhEgzswqwp4wedm2XoBCN9WMosY/edit#gid=752070695 should also help
17:14:22 <evrardjp> see what's red
17:15:00 * noonedeadpunk should finally save this link to some reliable place
17:15:28 <mnaser> #endmeeting