16:00:26 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:00:27 <openstack> Meeting started Tue Mar 17 16:00:26 2020 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:30 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:00:34 <noonedeadpunk> #topic office hours
16:00:40 <noonedeadpunk> o/
16:06:02 <jrosser> o/ hello
16:06:18 <jralbert> Hi all
16:06:21 <jrosser> chandankumar: i still can't make dnf do what i want :)
16:10:09 <noonedeadpunk> So, the question raised today was if we can backport and should backport new features to previous branches
16:11:10 <noonedeadpunk> Since we do need to backport centos8 to train, then prohibition for smaller patches (esp non breaking and not changing defaults) looks not logic
16:11:36 <noonedeadpunk> jrosser: I can recall you've abandoned some of such backports lately
16:12:33 <jrosser> yes we proposed a backport for os_keystone and OIDC which we shouldnt have
16:12:36 <noonedeadpunk> Also I think mnaser is not against of backporting patches that add new functionality to previous branches
16:13:33 <jrosser> wrt centos 8 i'm not so sure
16:13:47 <jrosser> *sooo* much change on master for all sorts of py3 things
16:13:54 <jralbert> Running a somewhat older release as we do, our site would be very appreciative of backports to older but still supported releases
16:14:13 <noonedeadpunk> I have not fixed opinion on this as from one side it's convenient to be able to use things right now, but it some sort of risk imo
16:14:34 <guilhermesp> o/
16:14:38 <noonedeadpunk> jrosser: yeah, that's true... But otherwise we won't have upgrade release for centos?
16:14:41 <jrosser> jralbert: do you mean OSA things, or openstack itself?
16:15:07 <jralbert> OSA things particularly, although openstack features backported would be lovely in some cases
16:15:29 <noonedeadpunk> Yeah, opensatck is pretty strict on backporting...
16:15:36 <jrosser> ^ that
16:15:59 <noonedeadpunk> The question is if we should stick to the same rules or we can step down from them from times to times
16:16:36 <mnaser> So I’ll clarify
16:16:51 <mnaser> Openstack is strict on backpprts if your project asserts that it follows the stable policy
16:17:19 <mnaser> OSA does not actually make that assertion therefore if we were to backport a complete breaking change, it’s not nice, but it’s “okay”
16:17:31 <jralbert> My personal view is that OSA's best value is OSA itself, and while I'd love to get later-release openstack features without an upgrade, that's not as valuable to me as fixes in OSA itself being consistent back through supported releases where possible
16:18:22 <mnaser> I think to me my policy is: “if X can take advantage of this without them affecting any other users because the default behaviour doesn’t change”
16:18:27 <mnaser> Then that’s ok
16:19:45 <openstackgerrit> Merged openstack/openstack-ansible-os_placement master: Refactor memcached_servers  https://review.opendev.org/713251
16:19:55 <mnaser> and yeah, like the oidc stuff merging is probably ok with me as long as it didn't change default behaviour
16:20:19 <mnaser> and if it fundamentally broken then you get points to do whatever the heck you want to it :)
16:20:31 <noonedeadpunk> Ok, so we can backport new features unless it changes default behaviour.
16:20:52 <noonedeadpunk> And we actually trying to avoid changing defaluts wherever possible
16:22:33 <openstackgerrit> Merged openstack/openstack-ansible-os_barbican master: Refactor memcached_servers  https://review.opendev.org/713227
16:27:54 <mnaser> noonedeadpunk: that's my opinion personally, that way, we're being pretty accomodating to operators but also not breaking our users
16:28:03 <openstackgerrit> Merged openstack/openstack-ansible-os_octavia master: Refactor memcached_servers  https://review.opendev.org/713248
16:28:03 <mnaser> thoughts jralbert, jrosser
16:28:04 <mnaser> ?
16:28:39 <jralbert> Sounds perfect to me
16:29:37 <jrosser> yeah - though i'd like to see more eyes on stuff to review
16:30:07 <openstackgerrit> Merged openstack/openstack-ansible-os_sahara master: Refactor memcached_servers  https://review.opendev.org/713252
16:31:08 <jrosser> and in general some of the larger pieces of work could really use some co-development - there's two of us have had a stab but for various reasons it's stalled
16:33:44 <jrosser> jralbert: were you looking to get more involved with work on OSA?
16:33:59 <openstackgerrit> Merged openstack/openstack-ansible-os_ironic master: Refactor memcached_servers  https://review.opendev.org/713239
16:35:16 <jralbert> Yes, our site would like to discuss how we can contribute to the project
16:35:34 <jrosser> mnaser: ^
16:36:12 <mnaser> jralbert: sure!  i mean, all contributions are open, are you thinking of dedicating some times/resources or special areas you wanna get involved in?
16:37:39 <jralbert> Well, we're very heavily invested in OSA as both an install/upgrade and operations tool, so our big priority is features around the OSA procedures themselves: scaling, rebuilding nodes, etc
16:39:02 <jralbert> So right now I'm sad about tags like nova-config not working Rocky; but I'd love to see some improvements to the docs as well, and to general operations support improvements
16:39:42 <jralbert> All that said, I want our site to help the project however it needs help; I know that all this stuff gets better if the overall workload can be spread out a bit
16:40:16 <jralbert> What I'm interested in figuring out is what kinds of contributions you'd find useful, and rough idea of how many hours a week we can realistically contribute to that
16:40:51 <noonedeadpunk> jralbert: tags are fixed in stein:)
16:40:59 <jralbert> So I saw :(
16:41:23 <jralbert> Stein's on our roadmap for sure, but we're a fairly big installation relative to our team size, so we can't move that fast
16:41:30 <noonedeadpunk> it was too much of backport work to do, and not so many ppl cared about it... And now once rocky is EM...
16:41:52 <jralbert> Yep, I understand we're a bit behind the curve
16:41:57 <jralbert> We just got to Rocky in Novemver
16:42:14 <noonedeadpunk> Yeah, that's ok
16:42:44 <noonedeadpunk> So actually right now we have our hands mostly in supporting rather than bringing new features
16:43:01 <noonedeadpunk> So if you see any bugs, or feature missing - feel free to contribute it
16:43:11 <noonedeadpunk> Really every help is appreciated
16:43:32 <jralbert> Well, the tags issue is a good example of this: I'm not sure how to make a contribution to improve that
16:43:43 <jralbert> But it breaks our workflow pretty badly
16:43:47 <noonedeadpunk> Also right now we ahve a lot of deprecated params in configs that needs cleaning up and more stuff...
16:45:49 <noonedeadpunk> jralbert: at this point, when no releases to rocky can be done, it might be a bit late. But, you can try to backport topic https://review.opendev.org/#/q/static_imports
16:46:12 <noonedeadpunk> after we can make rocky bump and you can use stable/rocky isntead of some tag...
16:46:42 <mnaser> jralbert: it just mostly needs effort for someone to go ahead and backport those changes and test them out.
16:46:42 <jralbert> Hm, okay
16:46:42 <noonedeadpunk> but we won't be able to release new tag because of EM
16:47:59 <jralbert> I wonder if maybe our team should start out with triaging bugs as a way to get into the project and get the lay of the land
16:48:00 <noonedeadpunk> once you need reviews don't hesitate to ping cores here :p
16:48:30 <noonedeadpunk> oh, our launchpad nowadays... is a bit let down
16:48:40 <jralbert> There was a bit of concern from our management that untriaged bugs that hurt us badly might imply the project wasn't still being actively maintained
16:49:09 <noonedeadpunk> but help with it is really very appreiated
16:50:02 <jralbert> Okay, well I think maybe that's how we'll start: some bug triage, and some proposed changes to help us out with things we'd like fixed in Rocky
16:50:08 <jralbert> Does that sounds reasonable to you?
16:50:40 <jrosser> we had huge success last time we did a bug squash day
16:50:45 <mnaser> jrosser: i think some bug triage is helpful but mostly proposing changing is the _most_ valuable thing
16:50:47 <jrosser> maybe nearly 100 dealt with in 24hours
16:51:57 <jrosser> mnaser: i guess that comment is for jralbert but i'd have to add that review effort has to be available to match contributions
16:52:28 <mnaser> jrosser: i agree. i have personally not been very good at actively doing it, but i think if we maybe try to ping each other
16:52:52 <jralbert> I hope that once we are a part of things for a while, we'll be able to contribute a team member that you'd be willing to include as a reviewer
16:54:16 <mnaser> jralbert: i think we all would welcome new cores, we're not a picky bunch.  or i like to think at least :)
16:55:50 <jralbert> So there's two main contributors at my site, including me; my colleague has much more experience contributing to large open source projects as a core member, so I will encourage him to come here and introduce himself in the next few days. I will start out with bug triage and proposing backports. I think we can probably contribute 2-4 hours a week,
16:55:51 <jralbert> but I don't want to promise anything too firm just yet
16:58:27 <jrosser> jralbert: having some kind of always on irc presence is very handy - also outside the meeting times there is a shortened URL to the review dashbaord in the IRC topic, keeping a regular (daily?) view on that is a good way to keep across whats going on
16:58:50 <jrosser> and thats the route in to start doing reviews, which anyone can leave a +1/-1 on
17:00:32 <jralbert> Okay, that's where we'll get started
17:00:55 <jralbert> When my colleague has got a freenode name I'll ask him to come by and introduce himself
17:08:32 <jrosser> ooh time is up
17:08:37 <jrosser> #endmeeting