16:04:37 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:04:38 <openstack> Meeting started Tue Mar 31 16:04:37 2020 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:41 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:04:42 <noonedeadpunk> #topic office hours
16:04:44 <arxcruz> o/
16:05:57 <jrosser> o/
16:06:07 <noonedeadpunk> o/
16:08:29 <noonedeadpunk> ok, so, arxcruz, take a world:)
16:08:38 <noonedeadpunk> *word
16:08:40 <noonedeadpunk> lol
16:08:47 <arxcruz> hehe
16:08:59 <arxcruz> so, we are working in consolidate our skip list in one single repository
16:09:01 <arxcruz> https://opendev.org/openstack/openstack-tempest-skiplist
16:09:22 <arxcruz> the idea is have a tool that will give you a list of tests to be skiped based on job, release, and installer (tripleo, osa, etc)
16:09:37 <arxcruz> also, a ansible module to call it directly on ansible
16:09:53 <arxcruz> we want it integrated with os_tempest as much as possible as well
16:10:17 <arxcruz> the idea is call something like tempest-skip --release master --job bla
16:10:27 <arxcruz> and it return the skipped tests that we can pass to tempest
16:11:00 <arxcruz> if anyone is interested in help, you are more than welcome, we are now in phase of discuss what the tool will do, and how
16:11:06 <arxcruz> so it's a good start point :)
16:11:31 <arxcruz> we are doing this, because now, tripleo have jobs per component
16:11:37 <arxcruz> tripleo-component-compute
16:11:41 <arxcruz> tripleo-component-network
16:12:05 <arxcruz> and sometimes we see tests failing in one job, but not in the other, because the component have a bug or whatever other reason
16:12:18 <arxcruz> so we need now to be able to have a skip list per job/release
16:12:32 <arxcruz> and we were for a long time wanting to have the skip list in their own repository
16:12:53 <arxcruz> instead of use the one we are using right now, that is from our now deprecated validate-tempest role
16:13:16 <arxcruz> if osa are interested on this approach, it would be nice to coordinate collaboration :)
16:13:35 <arxcruz> that's it :)
16:14:01 <noonedeadpunk> ok, I see. Not really sure I got how ansible module should act. Like what it should do except running that command and what output it will provide?
16:14:35 <arxcruz> the mvp is call this command, and it return a list of the tests to be skipped, that can be saved in a txt file and pass to tempest
16:15:00 <arxcruz> as we are doing today
16:15:22 <arxcruz> have an ansible module is just an idea if that will be done, or it would be easier to just call the command we are discussing
16:15:25 <jrosser> vars_files: "{{ release ~ '/' ~ job '/' skiplist.yml }}"
16:15:27 <noonedeadpunk> Ok, so it's output can be registered and passed to tempest role include as a variable?
16:16:01 <arxcruz> yes
16:16:05 <arxcruz> probably can be done
16:16:16 <arxcruz> as i said, we are in the beginning
16:16:28 <arxcruz> planning everything
16:16:37 <noonedeadpunk> actually yes, I like jrosser's way of thinking...
16:16:51 <jrosser> this can probably be an ansible role that is called with branch/job and a var name
16:17:03 <jrosser> it then set_fact that var name
16:17:09 <jrosser> then everything is nicely decoupled
16:18:19 <arxcruz> yup, can be done in this way
16:18:33 <arxcruz> but i really looking for more integration between tripleo and osa :D
16:18:33 <jrosser> maybe these can all co-exist
16:18:43 <arxcruz> and have it integrated in os_tempest role
16:18:49 <arxcruz> not only for us, but to osa
16:18:50 <jrosser> i expect OSA would prefer something natively ansible in preference to a cli tool
16:19:16 <arxcruz> and that's why I wanted to have an ansible module or role
16:19:27 <jrosser> sure
16:19:57 <jrosser> is there anything you would like to specifically integrate in os_tempest?
16:20:07 <jrosser> roles calling roles can get messy
16:20:21 <arxcruz> I would like that the skip list used by osa be there as well :)
16:20:28 <arxcruz> of course cores would be by both groups
16:20:44 <jrosser> right - so if we could set a var with a role that generated the skip list we can pass it to os_tempest today
16:21:06 <arxcruz> yup
16:21:13 <arxcruz> we can work in this direction
16:21:45 <jrosser> and that would get wired in somewhere like this https://github.com/openstack/openstack-ansible/blob/master/playbooks/os-tempest-install.yml#L31-L33
16:22:14 <jrosser> i have to be afk for a while
16:22:16 <arxcruz> sure
16:22:22 <jrosser> noonedeadpunk maybe you have some thoughts too?
16:23:20 <arxcruz> anyway, we are working now in how the tool, so it might take a while until we are in a position to make everything work together
16:23:27 <arxcruz> so, all help are welcome :)
16:23:30 <arxcruz> that's all from me
16:24:09 <noonedeadpunk> Yeah, I actually think that roles should remain as lightweight as possible. As we have option to write blacklists it's good to use it. IF somesthing needs to be adjusted in os_tempest regarding format of passed variables it it - it's good
16:24:28 <noonedeadpunk> But not sure that we should add this module as a requirement to the role
16:24:46 <noonedeadpunk> As it will influence not so well in case of role standalone usage
16:24:54 <arxcruz> I see
16:25:04 <arxcruz> yeah, we can think about it in the future
16:25:10 <arxcruz> when we have something to show :D
16:26:44 <noonedeadpunk> actually even if we make such dependendy - another var should be passed to notify whether use it or not
16:27:32 <noonedeadpunk> But I think that we also may be using your blacklisting role for our CI jobs as well
16:29:51 <noonedeadpunk> so I probably pretty interested to have such tooling
16:30:22 <arxcruz> cool :)
16:30:27 <arxcruz> glad to hear :)
16:39:21 <velmeran> So I got everything up and running last night, could login to the web interface and even uploaded an image.  This morning looking at things I found my compute node is not there.
16:39:45 <velmeran> looking at the system, the service for the neutron agent crashing/restarting constantly
16:39:53 <velmeran> neutron-linuxbridge-agent: 2020-03-31 09:38:10.766 18509 ERROR neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] Interface eth12 for physical network flat does not exist. Agent terminated!
16:40:00 <noonedeadpunk> velmeran: sorry we have kinda meeting here :p
16:40:06 <noonedeadpunk> at least trying to have:)
16:40:06 <velmeran> ah no problem
16:40:43 <noonedeadpunk> Ok, so another thing I wanted to say is that our rocky finally entered EM
16:41:06 <noonedeadpunk> and I hope that train bump will be merged soon as well
16:41:35 <noonedeadpunk> btw, openstack seems not to be supporting python 3.5 which comes with debian stretch
16:41:58 <noonedeadpunk> however, we deploy venvs on py3.5 there and CI says it's wrking
16:42:36 <noonedeadpunk> so we can kinda continue doing that or can actually rollback to py2...
16:42:59 <noonedeadpunk> which will be kinda regression for users
16:53:32 * jrosser back
16:59:16 <noonedeadpunk> jrosser: do you have some thoughts on this?
16:59:57 <jrosser> the easiest thing would be to not deploy rally, on stretch
17:00:47 <noonedeadpunk> In terms of rally, it can be deployed on py3 I believe
17:01:14 <jrosser> so the issue there is the lack of py3 support on train
17:01:24 <noonedeadpunk> the thing is that py3.5 has not been tested according to https://governance.openstack.org/tc/reference/runtimes/train.html#python-runtime-for-train
17:01:49 <jrosser> hrrm well yes then the whole business of deploying on stretch is not supported on that basis?
17:02:07 <noonedeadpunk> smth like that
17:02:13 <noonedeadpunk> despite it works now
17:02:16 <jrosser> maybe we start small
17:02:18 <noonedeadpunk> (probably)
17:02:32 <jrosser> backport the necessary changes to python_venv build, which are are going to need anyway
17:02:41 <jrosser> and then switch over just the utility host stuff
17:02:58 <jrosser> but it will still fail though?
17:03:01 <jrosser> becasue 3.5
17:03:21 <noonedeadpunk> nope. but we don't run tempest against all projects tbh
17:03:47 <jrosser> i thought the main issue was the installation of rally requiring >= py3.6
17:03:54 <noonedeadpunk> what do you what to backport for python_venv_build?
17:04:08 <noonedeadpunk> jrosser: yeah, in case it's from master
17:04:24 <jrosser> i fear we may be talking about different things :)
17:04:30 <noonedeadpunk> but I think we can bump rally to 1.7 and live with it
17:05:14 <noonedeadpunk> Also we maybe should do it in better way but currently it's not easy without circullar dependency
17:05:41 <noonedeadpunk> ok. so I think we have 2 problems now. Rally that's support only py3.6+
17:06:00 <noonedeadpunk> and openstack not tested with 3.5 (but it seems to work as for now)
17:08:25 <noonedeadpunk> I think between not being able to deploy rally and deploy <3.0.0 it's better to chose deploy <3.0.0?
17:08:50 <jrosser> yes i would agree
17:08:55 <noonedeadpunk> And actually https://review.opendev.org/#/c/715215/ passes for debian
17:09:24 <jrosser> and that patch also fixes centos
17:09:32 <noonedeadpunk> yeah
17:09:35 <noonedeadpunk> it's a bit messy
17:09:51 <noonedeadpunk> but can't imagine another cleaner patch without disabling half of the ci
17:10:11 <jrosser> it's ok - these are all external things that have changed underneath us
17:10:42 <jrosser> i think we would better spend the time getting the backlog of patches in good shape than worry too much about stretch
17:11:00 <jrosser> unless there are some deployments that are depending on something we are missing
17:11:32 <noonedeadpunk> yeah, agree
17:12:26 <noonedeadpunk> so I think we almost have clean branches then
17:12:30 <jrosser> i need to go AFK again (TZ changed this is now an hour later for me)
17:12:34 <noonedeadpunk> except lxc thing
17:12:46 <noonedeadpunk> changed for me as well...
17:12:53 <noonedeadpunk> ok, then I think we've done
17:12:57 <noonedeadpunk> #endmeeting