14:00:07 <shardy> #startmeeting tripleo
14:00:08 <openstack> Meeting started Tue Aug 30 14:00:07 2016 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:11 <openstack> The meeting name has been set to 'tripleo'
14:00:16 <shardy> #topic rollcall
14:00:23 <EmilienM> o/
14:00:24 <shardy> Hi all, who's around?
14:00:24 <panda> o/
14:00:26 <dtantsur> o/
14:00:29 <dprince> hi
14:00:29 <qasims> o/
14:00:35 <thrash> o/
14:00:37 <cdearborn> o/
14:00:51 <saneax> o/
14:00:55 <derekh> o/
14:00:56 <shadower> hey
14:01:02 <marios> \o
14:01:10 <d0ugal> \o/
14:01:39 <rhallisey> hi
14:01:43 <mandre> o/
14:01:52 <rbrady> o/
14:02:05 <shardy> Ok, well hello all, let's get started :)
14:02:08 <jrist> o/
14:02:12 <shardy> #topic agenda
14:02:16 <shardy> #link https://wiki.openstack.org/wiki/Meetings/TripleO
14:02:25 <shardy> #link https://etherpad.openstack.org/p/tripleo-meeting-items
14:02:26 <myoung> o/
14:02:36 <shardy> please add any one-off items to the etherpad, we currently have two
14:02:53 <weshay> o/
14:02:54 <shardy> Also, I wanted to say thanks to EmilienM for running these meetings the last two weeks while I was on PTO
14:03:04 <trown> o/
14:03:05 <jrist> +1 thanks EmilienM
14:03:08 <coolsvap> o/
14:03:16 <sshnaidm> o/
14:03:36 <EmilienM> cool
14:04:28 <shardy> #topic one-off items
14:04:37 <adarazs> o/
14:04:41 <shardy> #info What features to add to Tripleo-CI tests for newton (panda)
14:04:52 <shardy> panda: care to provide some more details on this one?
14:04:53 <EmilienM> I'm actually already working on that
14:05:05 <EmilienM> but sure, details first :)
14:05:24 <shardy> Ok, so it's about defining the test matrix, sounds good
14:05:33 <EmilienM> https://review.openstack.org/#/c/362504/
14:05:54 <EmilienM> it's experimental now but really close to be ready
14:06:06 <EmilienM> I c/p matrix from puppet Ci for more consistency
14:06:08 <panda> well, I don't have much more detail to add, I know we are not testing everything, and I'd like to know what to add for newton, composable roles for example
14:06:22 <pabelanger> o/
14:06:33 <shardy> panda: Ok, well it sounds like we'll have to continue to expand the test matrix via scenarios
14:06:44 <shardy> and that will eventually include tests related to composable roles
14:06:48 <EmilienM> panda: can you tell if my patch is related?
14:07:13 <shardy> right now we're testing some aspects of composable services just by enabling/disabling various services, full composability isn't quite landed yet
14:07:25 <EmilienM> shardy: example of run: https://review.openstack.org/#/c/362506/
14:07:38 <shardy> what is the status of testing M->N upgrades in CI?
14:07:43 <EmilienM> if you try to change cinder composable service, it run scenario002 job
14:07:48 <EmilienM> shardy: stalled
14:07:49 <weshay> matbu, ^
14:07:50 <shardy> that and IPv6 are my main concerns prior to the newton release
14:07:57 <EmilienM> shardy: undercloud was working but now fail
14:07:58 <panda> EmilienM: yes, partially, jobs that use those scenarios need to be added of course
14:08:00 <weshay> upgrades and ipv6?
14:08:01 <hrybacki> o/
14:08:04 <EmilienM> shardy: overcloud is not testing it yet
14:08:13 <EmilienM> panda: there are already added dude
14:08:29 <gfidente> +1 on upgrades/ipv6 to start with
14:08:35 <shardy> EmilienM: ack, Ok perhaps we can discuss that more in the CI topic then
14:08:38 <weshay> k.. cool
14:08:45 <EmilienM> panda: I added the jobs here https://review.openstack.org/#/c/361433/
14:09:05 * beagles barges in late
14:09:12 <shardy> anything else on this topic, or shall we continue?
14:09:33 <EmilienM> I guess it's good we can continue later in Ci topic
14:09:42 <shardy> #info newton-3 release status and FFEs (shardy)
14:09:52 <shardy> #link https://bugs.launchpad.net/tripleo/+milestone/newton-3
14:10:09 <shardy> So I added this as a one-off topic, so we can all sync up on the status
14:10:09 <EmilienM> weshay: I'll give detailed status on upgrade/update jobs later
14:10:37 <shardy> we're planning to tag newton-3 tomorrow, so we need to land as many of the remaining "Needs Code Review" blueprints as possible today
14:10:57 <shardy> please ensure your blueprint status is correctly set, and help with reviews to push the last few things in before EOD
14:11:04 <EmilienM> shardy: are we going to tag even if CI is not to latest trunk?
14:11:16 <marios> shardy: hey, i see the manila-generic stuff isn't in the newton-3 list i should file a bug for it i guess, but thanks to ben who posted to list last week ( I was away). just making sure you're aware/agree.
14:11:24 <marios> shardy: sorry, manila-netapp
14:11:35 <shardy> EmilienM: unless we're confident we'll get a promote so we can release on Thursday, I don't think we have much choice?
14:11:46 <EmilienM> right
14:11:46 <weshay> EmilienM, ok.. from what I've heard from matbu is that we have the CI in place, we're just waiting on some patches to land to unblock the overcloud upgrade
14:12:22 <shardy> marios: Yeah please raise a bug or bp as we lost track of it because there's nothing in LP
14:12:44 <marios> shardy: ack, will do. ftr: tht https://review.openstack.org/#/c/354019/ and puppet-tripleo @ https://review.openstack.org/#/c/354014
14:12:56 <shardy> So, I created https://launchpad.net/tripleo/+milestone/newton-rc1
14:13:22 <shardy> my plan is to defer all FFE BPs, and any remaining bugs targetted to newton-3 when we tag the newton-3 release
14:13:52 <dprince> shardy: should we try to land the non-FFE stuff today if possible then?
14:13:52 <shardy> we then have a couple more weeks where we can land the remaining things, do testing/bugfixing and get ready to declare newton final
14:14:35 <shardy> dprince: Yeah, basically it'd be good to minimize the number of FFE's we're tracking by landing stuff today, but if that's not possible, we'll just have to add things to the FFE list and move the target to rc1
14:15:03 <shardy> hopefully then we can get more folks focussed on the few remaining features, then switch into bugfix mode for the final push ahead of the release
14:15:05 <beagles> shardy: to reiterate and emphasize for myself and others - if you have patches in-flight that you want to be considered, you need to have a bug or blueprint associated with the patches and that they need to be appropriately target and if appropriate a FFE for, correct?
14:15:06 <shardy> sound reasonable?
14:15:28 <EmilienM> shardy: it sounds safe
14:15:35 <shardy> beagles: Yes, otherwise there's a high risk the patches will get missed
14:15:56 <beagles> shardy, ack thanks
14:16:36 <shardy> beagles: closer to the release (particularly after we branch a release candidate) nothing will get onto stable/newton without a bug reference
14:17:08 <shardy> beagles: for now, it's about knowing when we can sanely branch, and launchpad is what I'm tracking to evaluate that :)
14:17:15 <beagles> shardy, makes sense, thanks :)
14:17:23 <shardy> Ok, any more questions re the release before we move on?
14:17:37 <saneax> shardy, in the newton-rc1, sriov/dpdk are missing>?
14:17:54 <shardy> saneax: they are still targetted at newton-3 because I'm hoping they will land todauy
14:17:57 <shardy> today
14:18:04 <saneax> OK shardy thanks
14:18:07 <shardy> if that doesn't happen, I'll move them to rc1 tomorrow
14:18:13 <jrist> shardy: my topic is sort of related, so it can segway
14:18:20 <shardy> jrist: Ok, go for it! :)
14:18:25 <jrist> ok so two things
14:18:40 <jrist> tripleo-ui has not been upstream integrated with tripleo
14:18:50 <jrist> so I've been sort of struggling along trying to track both
14:18:59 <jrist> I would like to propose getting tripleo-ui into tripleo proper
14:19:04 <jrist> launchpad, bugs, everything
14:19:19 <shardy> So we currently have a separate UI LP project here: https://launchpad.net/tripleo-ui
14:19:24 <jrist> was wondering how to do that since it's a pretty big project
14:19:45 <shardy> I'm Ok with keeping that if you'll find it useful, or tracking everything in lp/tripleo
14:20:00 <shardy> but I'd like us to start tagging tripleo-ui releases coordinated with all the other tripleo things
14:20:04 <jrist> mostly I want to make sure that we're getting stuff in for tripleo and workflows that we need for the UI
14:20:11 <shardy> e.g, starting from tomorrow for newton-3 if you're ready for that?
14:20:12 <jrist> shardy: that was the segway
14:20:14 <jrist> exactly
14:20:24 <jrist> we're extremely close. that's what we're targeting too
14:20:32 <jrist> jtomasek, florianf ^
14:20:34 <jrist> right?
14:20:34 <jrist> :)
14:20:44 <shardy> jrist: I'd say lets coordinate manually until the end of newton, then for ocata, we'll get the launchpad tracking better aligned
14:21:00 <jrist> shardy: ok thanks. we can talk more about the details of that in #tripleo
14:21:10 <jrist> as for release, I'll coordinate with EmilienM to do a patch for releases
14:21:15 <shardy> I don't really care if it's in tripleo or tripleo-ui on LP, but we'll need to have per-milestone deliverables and track everything aligned with the rest of tripleo
14:21:27 <jrist> that's the idea. so we can make sure we're tracking within milestones
14:21:36 <jrist> and coordinate with stuff in tripleo for the UI
14:21:41 <shardy> jrist: yup, either EmilienM or I will ping you tomorrow to agree the SHA to release from
14:21:44 <jrist> thanks shardy that's it from me
14:21:46 <shardy> then we'll tag it with everything else
14:21:52 <EmilienM> yep
14:21:56 <shardy> woohoo, first integrated tripleo-ui! :)
14:22:02 <jtomasek> shardy, jrist +1
14:22:46 <shardy> Ok, thanks, lets move on
14:22:50 <shardy> #info TripleO CI for proprietary vendors (qasims)
14:22:53 <shardy> qasims: Hi!
14:22:57 <qasims> Hey
14:23:00 <EmilienM> qasims: hey
14:23:23 <qasims> I wanted to discuss possible ideas for this
14:23:28 <shardy> so this is a follow-up to the ML thread EmilienM posted, and it'd be great to agree the best integration point for third-party CI, such that the various backends can be better tested
14:23:45 <EmilienM> third party or not
14:23:56 <EmilienM> some vendors could run their plugins in our multinode jobs
14:24:09 <EmilienM> as they don't require specific hardware or proprio soft
14:24:21 <shardy> EmilienM: Yeah, agreed, that may work in some cases
14:24:29 <EmilienM> my scenario work fits in this
14:24:36 <EmilienM> we could have more scenarios for each vendor
14:24:44 <EmilienM> and call the jobs when required thx to wuul
14:24:47 <EmilienM> zuul err
14:24:58 <shardy> qasims: So I guess the question is how we handle non-free components, as I don't think we can use infra resources to deploy/test proprietary pieces
14:25:09 <EmilienM> the pb with plumgrid is that its proprio
14:25:15 <shardy> in those cases, I guess that third-party jobs would be a better fit?
14:25:22 <qasims> exactly
14:25:24 <EmilienM> exactly
14:25:25 <shardy> similar to what is done for some other projects, e.g Ironic?
14:25:41 <trown> how will a third-party use tripleo-ci though?
14:25:54 <shardy> weshay: you've been looking into setting up third-party CI jobs against tripleo, right?
14:26:18 <weshay> shardy, aye
14:26:38 <adarazs> we have a third party CI trigger with "rdo-ci-check"
14:26:42 <shardy> weshay: would it be possible to document how that's all wired up, perhaps in a patch to tripleo-docs?
14:26:54 <weshay> it's in place from ci.centos, it's not ready from internal ci systems.  We need a file server for logs that is public.  That is in progress
14:26:57 <shardy> that may prove a useful starting point for qasims and other vendors?
14:27:13 <adarazs> shardy: I'm working on a doc about it.
14:27:14 <qasims> yes
14:27:19 <weshay> shardy, the docs for 3rd party are also in progress under review atm.. adarazs ^
14:27:30 <shardy> trown: I guess that's the question, so getting the high-level integration points defined is probably the first step
14:27:35 <adarazs> shardy, qasims: https://review.openstack.org/360007 WIP change
14:27:50 <adarazs> that includes doc
14:27:59 <EmilienM> so we want to deploy plumgrid in rdo ci?
14:28:16 <weshay> maybe internal
14:28:32 <shardy> EmilienM: No, I think vendors would probably have to set up their own jobs?
14:28:45 <shardy> Or perhaps capacity could be made available on an ovb cloud somewhere?
14:28:46 <EmilienM> in their infra?
14:29:23 <shardy> qasims: what are your thoughts on running the tests, what would be the best fit from your perspective?
14:29:43 <EmilienM> honestly i would have been happy if someone from midokura or contrail could also reply to this thread, they are open source and it would be easier for a first iteration
14:29:53 <EmilienM> the case of non-free soft is more complex
14:30:12 <qasims> for now it seems that we will have to set this up on our own infra
14:30:29 <shardy> EmilienM: sure, but we need to address both requirements, so it's good to start the conversation :)
14:31:34 <weshay> shardy, maybe we can help by adding the doc required and infra required for running third party and how to customize the deployment
14:31:35 <pabelanger> adarazs: please do not use rdo-ci-check, 3rd party CI should only respond to recheck
14:31:48 <pabelanger> adarazs: http://docs.openstack.org/infra/system-config/third_party.html
14:32:05 <adarazs> pabelanger: we're not triggering without this word for now for capacity reasons.
14:32:22 <shardy> qasims: Ok, well it sounds like some further discussion on how that will work is needed, but I think the main message is lets keep discussing it, and try to document things as we go to simplify subsequent integration efforts
14:32:38 <qasims> sounds good.
14:33:02 <adarazs> pabelanger: so this is just a magic word that you can use to trigger the third party ci for a patch you want to check, so we don't do 'recheck' either
14:33:02 <shardy> Ok, thanks qasims!
14:33:15 <shardy> #topic bugs
14:33:18 <EmilienM> qasims: thx for replying to the proposal
14:33:26 <qasims> I will come shoot proposals to ML if any
14:33:34 <pabelanger> adarazs: patch in review.openstack.org?
14:33:41 <shardy> #link https://bugs.launchpad.net/tripleo
14:34:00 <adarazs> pabelanger: yes. -- it's kind of in stealth mode for now. :)
14:34:02 <shardy> So, my main request is please ensure all release impacting bugs are targetted at rc1 from now on
14:34:18 <shardy> we'll need to track release blockers carefully between now and the final release
14:34:29 <shardy> anyone have any other bug related things to discuss?
14:34:36 <pabelanger> adarazs: yes, please do not do that. We have policies in place for 3rd-party CI. Please read: http://docs.openstack.org/infra/system-config/third_party.html and follow that.
14:35:29 <pabelanger> adarazs: we can discuss it more in #tripleo after the meeting
14:35:46 <EmilienM> shardy: nothing on my side
14:35:50 <adarazs> pabelanger: okay.
14:36:28 <sshnaidm> https://bugs.launchpad.net/tripleo/+bug/1618418
14:36:28 <openstack> Launchpad bug 1618418 in tripleo "CI: periodic jobs fail on undercloud install because "AttributeError: 'module' object has no attribute 'RegionInvalidationStrategy'"" [High,Triaged]
14:36:37 <EmilienM> its fixed in RDO
14:36:38 <sshnaidm> have anyone seen such problem in his jobs?
14:36:44 <EmilienM> the package is in buildlogs now
14:36:44 <shardy> We do have a lot of New untriaged bugs, so any help triaging those over the next few days would be appreciated
14:37:01 <EmilienM> sshnaidm: yes, fixed last night it was a python dogpile problem
14:37:11 <sshnaidm> EmilienM, great, thanks
14:37:13 <EmilienM> shardy: will do later today
14:37:23 <EmilienM> sshnaidm: fyi it also blocked puppet ci promotion
14:37:34 <shardy> #topic Projects releases or stable backports
14:37:36 <EmilienM> sshnaidm: testing now again with new package in puppet ci and will let you know
14:37:45 <shardy> So, not much to add on this, we already discussed newton-3
14:37:54 <shardy> EmilienM proposed a mitaka release, so thanks for that
14:38:01 <shardy> do we need a liberty release too?
14:38:05 <EmilienM> shardy: cool, i'll try to get it merged asap
14:38:21 <EmilienM> shardy: i haven't seen much backports
14:38:26 <EmilienM> i dont thing we need
14:38:31 <shardy> Ok, lets just go with mitaka for now then
14:38:42 <shardy> Anything else re releases/backports?
14:38:50 <EmilienM> yeah we're already super busy with newton and mitaka
14:39:33 <shardy> #topic CI
14:39:45 <shardy> So, earlier we mentioned upgrade coverage, and IPv6
14:39:47 <EmilienM> so I have somme updates
14:40:00 <EmilienM> regarding coverage of services, we are working on this with scenarios
14:40:23 <EmilienM> i have some blockers with gnocchi but pradk will help later today
14:40:44 <EmilienM> otherwise the jobs are in place. once they are working i'll move them from experimental queue to check
14:40:48 <EmilienM> in non voting of course
14:41:00 <EmilienM> https://review.openstack.org/#/c/362504/
14:41:08 <EmilienM> example with https://review.openstack.org/#/c/362506/
14:41:12 <bnemec> Please don't move them to check right now.
14:41:18 <shardy> One thing related to this, is ramishra implemented a new heat feature which will help when manipulating the *Services lists
14:41:20 <EmilienM> bnemec: why?
14:41:21 <shardy> https://review.openstack.org/#/q/status:merged+project:openstack/heat+branch:master+topic:bp/environment-merging
14:41:30 <bnemec> Oh wait, these don't run in our cloud though, do they?
14:41:35 <EmilienM> bnemec: in non voting, and they run only if you try to modify their env
14:41:38 <EmilienM> bnemec: no
14:41:42 <EmilienM> bnemec: they run in osinfra
14:41:46 <EmilienM> bnemec: multinode ftw
14:41:51 <shardy> we may want to move towards that to make it easier to compose the different scenarios without hard-coding e.g ControllerServices
14:41:54 <bnemec> nm, carry on then. :-)
14:41:58 <EmilienM> bnemec: k
14:42:09 <EmilienM> another thing: upgrades
14:42:11 <shardy> Yeah, to be fair multinode is working out really well
14:42:26 <EmilienM> i've heard RDO ci had successful results in RDO CI to test upgrades
14:42:30 <shardy> Does anyone have any insight into why our ovb jobs have gotten so slow?
14:42:36 <EmilienM> it would be great to have help to make it working in upstream CI first
14:42:45 <shardy> I think it's a combination of things, but we're seeing a lot of jobs hit the infra timeout
14:42:47 <EmilienM> as a reminder for everyone here: RDO CI is not Upstream CI
14:42:51 <bnemec> shardy: Yes.  We think it's a hardware problem.
14:42:57 <shardy> which is kinda sad given all the hardware upgrades
14:43:15 <bnemec> The new memory was installed incorrectly and seems to be hurting performance on those boxes.
14:43:20 <shardy> bnemec: Ok, great - any details or timeline for a fix?
14:43:31 <EmilienM> anyway, regarding upgrades / updates, last time i checked last week, jobs were not passing... multiple problems
14:43:58 <bnemec> shardy: We have a ticket open with dcops to get one of the nodes fixed to verify that is the problem.  Not sure what the turnaround time on that is.
14:44:09 <matbu> shardy: EmilienM i'll take care of this jobs (upgrade M to N)
14:44:10 <EmilienM> if any volunteer to help on upgrade/update jobs UPSTREAM please let me know
14:44:17 <EmilienM> matbu: thank you
14:44:19 <matbu> EmilienM: ^
14:44:21 <shardy> bnemec: ack, ok, well good to hear we're en-route to a fix
14:44:36 <matbu> I got good result, i think we are close
14:44:37 <bnemec> shardy: Assuming that works, we'll need to discuss when we can afford to pull a bunch of compute nodes out and get them fixed.
14:44:44 <EmilienM> matbu: upstream?
14:45:12 <matbu> EmilienM: the blockers review has been merged (latest yesterday)
14:45:16 <shardy> matbu: to clarify, is this an RDO upgrade job, where the plan was to make it test upstream code via third-party CI?
14:45:19 <EmilienM> please stop saying you guys have results when it's not in upstream CI. Both systems are different
14:45:45 <shardy> EmilienM: they are different, but third-party feedback would still be valuable provided it's testing upstream code
14:45:52 <matbu> shardy: i'm mean upstream (tripleo-ci)
14:45:56 <EmilienM> i didnt say its not valuable
14:46:06 <EmilienM> its just not voting and not run everytime.
14:46:20 <weshay> EmilienM, matbu is working in both ci systems atm
14:46:28 <matbu> shardy: EmilienM in the lifecycle team, I has been working with rdo for major upgrade
14:46:42 <shardy> matbu: Ok, thanks, lets sync up after the meeting, could you perhaps start an etherpad with a list of patches so we can see what needs help w/reviews etc?
14:46:46 <EmilienM> cool, I would like the jobs out of experimental queue asap
14:47:10 <EmilienM> even the update job was broken, a problem in Heat. I havent checked if it pass now
14:47:31 <matbu> shardy: EmilienM ack
14:47:33 <shardy> So, gfidente mentioned we removed ipv6 from CI when we switched to ovb
14:47:50 <shardy> does anyone have any details on what work is needed to add that back in?
14:47:53 <dprince> shardy: yep
14:48:09 <bnemec> We need to re-enable the updates job.  That's where we were testing ipv6.
14:48:20 <dprince> shardy: should be similar to IPv4, just different heat environments
14:48:21 <EmilienM> bnemec: it's broken now afict
14:48:22 <weshay> panda, is familiar w/ ipv6, is that something he can drive?
14:48:22 <bnemec> Also, we'll need an ipv6 version of the OVB net-iso templates.
14:48:42 <EmilienM> bnemec: the update job is failing because Heat could not update the stack
14:48:51 <EmilienM> afik zaneb fixed it
14:48:59 <gfidente> also I think the update job is using multinode where we don't have os-net-config
14:49:07 <EmilienM> but we havent promoted tripleo repo for 6 days
14:49:11 <shardy> Yeah that update bug is fixed, but we need to promote current-tripleo to get it
14:49:13 <gfidente> so we can't as easily bring network isolation to the updates job
14:49:14 <bnemec> gfidente: Two different updates jobs.
14:49:35 <bnemec> We still have the old updates job defined, we just aren't running it in the check queue.
14:49:45 <EmilienM> right
14:49:52 <gfidente> then +1 on thd old updates job back to life
14:50:09 <EmilienM> do we have the res to run it in check again?
14:50:10 <shardy> I think we need ipv6 coverage before we declare newton final as we've touched a bunch of stuff which might have broken it
14:50:37 <shardy> Ok then, sounds like we have a plan :)
14:50:56 <shardy> Anything else related to CI before we move on?
14:50:56 <weshay> so who is going after ipv6 in ci?
14:50:58 <EmilienM> hopefully it works in RDO CI </troll>
14:51:06 <sshnaidm> As you know we have a problem with periodic job duration, here we have a discussion what to include there, please comment: https://review.openstack.org/#/c/361429/ Also I proposed a patch to split the features: https://review.openstack.org/362904
14:51:08 <weshay> helping :)
14:51:16 <bnemec> EmilienM: Back under the bridge with you. :-P
14:51:44 <bnemec> Maybe we could just switch the ha job to ipv6?
14:51:51 <bnemec> For now at least.
14:51:56 <EmilienM> bnemec: it sounds an excellent proposal
14:52:08 <bnemec> It's already using net-iso, so it would just be a question of switching to ipv6.
14:52:34 <shardy> weshay: I think we need a volunteer, the plan is to re-enable the old update job w/ipv6, and if panda is available to help, that would be good
14:52:42 <dprince> bnemec: then we won't cover Ipv4?
14:53:12 <panda> shardy: yep, I'll do it
14:53:43 <EmilienM> i think its a one line patch
14:54:35 <shardy> dprince: we have the two ovb jobs, so I guess the idea is run one ipv6 and one ipv4?
14:54:48 <shardy> I would prefer not to lose coverage of HA w/ipv4 though
14:54:55 <bnemec> Yeah, but nonha doesn't use net-iso, so it's a different kind of ipv4.
14:55:06 <dprince> exactly, that is my only point
14:55:12 <shardy> as there's a bunch of stuff which might break with multiple nodes (all the list manipulation in allNodesConfig is a good example)
14:55:14 <bnemec> I'm just looking at alternatives in case we can't get the updates job working quickly.
14:55:37 <EmilienM> maybe can we have a periodic job for ha-ipv6 ?
14:55:41 <bnemec> Also, adding another job to the check queue is going to suck, given our existing performance issues.
14:55:51 <shardy> Yeah, a periodic job would certainly be better than nothing
14:56:01 <EmilienM> i can hack on project-config to add it
14:56:05 <shardy> at least then we can work to make it pass before we release
14:56:10 <EmilienM> if everyone agrees
14:56:15 <shardy> Alright, 4 mins left
14:56:18 <bnemec> Or experimental, so we can trigger it on patches we think might affect ipv6?
14:56:22 <EmilienM> bnemec: right
14:56:30 <shardy> I'll skip Specs, but just a reminder folks can start raising ocata specs now
14:56:37 <shardy> would be good to have some for discussion at summit
14:56:39 <EmilienM> #action EmilienM to create exp job for ipv6-ha
14:56:44 <shardy> #topic open discussion
14:56:51 <dprince> yeah, we don't have resources for another "gating" check job yet... pending performance improvements
14:56:57 <EmilienM> dprince: right
14:57:09 <EmilienM> experimental job will be ok
14:58:52 <shardy> Ok, does anyone have anything else to raise, or shall we wrap things up?
14:59:17 <shardy> I'll take that as a no, thanks all! :)
14:59:23 <saneax> Thanks folks
14:59:25 <beagles> o/ cheers
14:59:25 <shardy> #endmeeting