15:02:30 <hogepodge> #startmeeting loci
15:02:31 <openstack> Meeting started Fri Mar  1 15:02:30 2019 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:34 <openstack> The meeting name has been set to 'loci'
15:02:59 <evrardjp> o/
15:03:59 <hogepodge> #topic self-signed certs
15:04:10 <evrardjp> I guess that one is for me
15:04:57 <evrardjp> when browsing the fetch_wheels code, I realised the protocol_detection is quite brittle
15:05:24 <evrardjp> Would you be okay if I just remove it, and replace it with a variable?
15:05:50 <hogepodge> that should be fine
15:06:16 <evrardjp> That could default to http, the current behaviour, and be updated by the user to https if required. The rest is unchanged.
15:06:23 <hogepodge> I don’t know if anyone is depending on using local files
15:06:33 <evrardjp> that's for registries
15:06:41 <hogepodge> ah, ok
15:07:03 <evrardjp> local files fetching is not impacted
15:07:24 <evrardjp> and registries like dockerhub provide http redirection to valid certificates, so that doesn't matter to them too
15:07:36 <evrardjp> http redirection to https + valid certificates*
15:08:02 <evrardjp> so basically the detection is... quite broken, because it spits http everywhere even if http doesn't work
15:08:04 <hogepodge> ok
15:08:25 <evrardjp> what would be the name of said variable we expose?
15:08:30 <evrardjp> REGISTRY_USE_SSL ?
15:08:37 <evrardjp> REGISTRY_PROTOCOL ?
15:08:50 <evrardjp> REGISTRY_PROTOCOL http by default seems clear to me
15:08:56 <hogepodge> I would probaly say the latter
15:09:02 <hogepodge> yup
15:09:04 <evrardjp> ok
15:09:35 <evrardjp> I will also add another key, REGISTRY_SSL_NOVERIFY, for those pesky self-signed certs :p
15:09:48 <evrardjp> if everyone agrees :)
15:09:59 <hogepodge> I just learned yesterday that starlingx is adopting loci, so since we have adoption across two large projects now we should publish these changes to the mailing list to give everyone a fair heads up
15:10:14 <evrardjp> oh really?
15:10:15 <evrardjp> cool
15:10:17 <evrardjp> yeah will do
15:10:18 <hogepodge> I might just use INSECURE to match the rest of the community
15:10:30 <hogepodge> but I have not strong opinion on that either way
15:10:31 <evrardjp> right
15:10:33 <evrardjp> yeah
15:10:35 <evrardjp> that's fine for me
15:10:50 <evrardjp> it's clearer
15:10:51 <hogepodge> or REGISTRY_INSECURE
15:10:59 <evrardjp> yeah
15:11:05 <evrardjp> +1 on REGISTRY_INSECURE
15:11:29 <evrardjp> will do the cleanup of the function in a different patch.
15:12:18 <hogepodge> that sounds great, thanks
15:12:19 <evrardjp> so that people have time to react on the ML
15:12:32 <evrardjp> thanks for your time and opinions hogepodge :)
15:13:04 <hogepodge> Of course: :-)
15:13:13 <hogepodge> #topic testing
15:13:24 * evrardjp giggles
15:13:46 <hogepodge> testing is still an issue in my mind. I have to remove some tests, and figure out a solution for making sure our packages actually work
15:14:19 <hogepodge> We’ve moved to a sprint model of working, so I’m. going to make this one of my items to address to make sure I carve out time for it
15:14:30 <evrardjp> ok
15:15:19 <hogepodge> I’m trying to decide if the best route is to do something like project individual testing, like running keystone tests against keystone, or be more ambitious and test against an AIO deployment (which i have, but right now it only supports centos)
15:16:05 <hogepodge> you have any opinions on that?
15:16:18 <evrardjp> hogepodge: I think we should not have another deployment tool, but we lack testing, so what you have, even if it _only_ supports centos, is better than nothing
15:16:26 <evrardjp> and I would not go further in fact :p
15:17:09 <evrardjp> the alternative is smoke tests per image, which is fine -- but how will you test nova?
15:17:16 <evrardjp> that's harder to test.
15:17:32 <hogepodge> It’s what I use to deploy in my home lab, so it’s maintained, and I do want to add leap and ubuntu support, but it’s been very low priority (getting it to work at all has taken most of my time)
15:17:49 <hogepodge> yeah
15:18:09 <hogepodge> just run nova unit tests for example
15:18:25 <hogepodge> but integrated would simplify things a lot
15:18:50 <hogepodge> I would need to pull my tooling into infra, which should be easy enough. I’m just calling it locistack
15:20:16 <evrardjp> I am not sure if I can invest time into maintaining it though -- do you want it to be voting, nv, experimental or a periodic?
15:23:10 <hogepodge> maybe start non-voting
15:23:49 <hogepodge> I can start by running tempest against a local installation and see if it even works
15:23:58 <evrardjp> : )
15:24:07 <hogepodge> Thanks
15:24:12 <hogepodge> #topic open discussion
15:24:15 <hogepodge> anything else?
15:24:41 <evrardjp> nothing for me -- portdirect?
15:24:54 <hogepodge> hehe I was wondering if I should out out portdirect
15:24:58 <evrardjp> hogepodge: I learned from the best :p
15:26:08 <hogepodge> hearing nothing, thanks, and have a great weekend!
15:26:17 <hogepodge> #endmeeting