14:00:47 <EmilienM> #startmeeting tripleo
14:00:47 <openstack> Meeting started Tue Oct 18 14:00:47 2016 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:49 <dtrainor> :)
14:00:51 <openstack> The meeting name has been set to 'tripleo'
14:00:55 <EmilienM> #topic agenda
14:00:56 <adarazs> \o
14:00:57 <ccamacho> xD Hola
14:00:57 <EmilienM> * one off agenda items
14:00:59 <d0ugal> o/
14:00:59 <EmilienM> * bugs
14:01:01 <EmilienM> * Projects releases or stable backports
14:01:03 <EmilienM> * CI
14:01:05 <EmilienM> * Specs
14:01:07 <EmilienM> * open discussion
14:01:09 <EmilienM> who is here today?
14:01:12 <EmilienM> ccamacho: and also "jajajajajajajaja"
14:01:13 <cdearborn> \o
14:01:15 <akrivoka> \o
14:01:18 <mwhahaha> hola
14:01:18 <mandre> o/
14:01:19 <beagles> oo/
14:01:20 <jpich> o/
14:01:21 <dprince> hey
14:01:22 <EmilienM> which is the thing I usually write after too much beers
14:01:24 <rhallisey> hi
14:01:26 <dtrainor> howdy.
14:01:26 <shadower> hey
14:01:37 <hrybacki> o/
14:01:37 <trown> o/
14:01:38 <shardy> o/
14:01:39 <ccamacho> EmilienM LOL
14:01:52 <marios> \o
14:01:57 <EmilienM> ok let's do a quick meeting today
14:01:59 <panda> no roll call ? ok \o/
14:02:08 <EmilienM> #topic one off agenda items
14:02:22 <EmilienM> akrivoka: o/ please go ahead
14:02:27 <matbu> o/
14:02:43 <akrivoka> so, we need post-deployment config for the ui
14:02:59 <EmilienM> do we need a blueprint/specs?
14:03:03 <shardy> akrivoka: I added a comment to the bug, do we know what exactly we're missing?
14:03:07 <akrivoka> we were hoping to have a mistral workflow for this, and not have to manually do it in the ui
14:03:15 <shardy> the plan was always to remove the os-cloud-config postconfig stuff
14:03:19 <EmilienM> oh cool
14:03:29 <shardy> so if possible, it'd be better to do that than perpetuate it in mistral
14:03:39 <akrivoka> https://bugs.launchpad.net/tripleo/+bug/1634505
14:03:40 <openstack> Launchpad bug 1634505 in tripleo "Post-deployment config for UI" [Critical,Triaged] - Assigned to Ana Krivokapić (akrivoka)
14:03:46 <d0ugal> shardy: +1
14:03:47 <saneax> o/
14:04:24 <EmilienM> ok it sounds like we need a spec to discuss about the problem to solve here
14:04:24 <bandini> \o
14:04:30 <rbrady> shardy: where would the init tasks end up?
14:04:34 <shardy> akrivoka: context is we moved a bunch of stuff e.g endpoint and user creation into puppet, so in theory there shouldn't be a lot of stuff left in the postconfig
14:04:41 <shardy> rbrady: what init tasks?
14:04:54 <akrivoka> shardy: oh, I see, I didn't know that
14:05:04 <shardy> that's my question, exactly what's missing when you don't run the postconfig, and can we do it somewhere else
14:05:07 <rbrady> shardy: https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L712
14:05:14 <shardy> without wiring os-cloud-config in via mistral
14:05:54 <shardy> rbrady: yeah but we should be hitting https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L731
14:05:57 <EmilienM> there is no postconfig anymore, we manage endpoints with puppet right?
14:05:58 <shardy> that stuff is deprecated
14:06:03 <shardy> or at least it's supposed to be
14:06:04 <EmilienM> indeed
14:06:21 <EmilienM> we could remove this postconfig i think and see how it works
14:06:31 <shardy> IMO we don't need a spec, but we do need some analysis in the bug about what exactly the CLI post config is still doing
14:06:50 <rbrady> shardy: ack
14:06:52 <shardy> then we can either add it via puppet, heat or mistral
14:07:02 <akrivoka> shardy: +1
14:07:28 <EmilienM> shardy: AFIK it's only about keystone endpoints right?
14:07:50 <shardy> EmilienM: we moved all that into puppet tho didn't we?
14:07:52 <dprince> EmilienM: the keystone endpoints patch got reverted because it broke upgrades initially. Did we add back all that functionality?
14:08:03 <dprince> a long time back...
14:08:07 <shardy> I thought we did but could be mistaken
14:08:12 <EmilienM> shardy: right so we don't need that stuff anymore
14:08:21 <EmilienM> me too
14:08:24 <EmilienM> ok let's check it
14:08:38 <shardy> EmilienM: well, according to akrivoka we do, hence my saying we need to firstly figure out why :)
14:08:51 * dprince thinks this got lost in the revert shuffle
14:09:17 <akrivoka> to be fair, I haven't been able to test it at all still, as I haven't been able to deploy successfully
14:09:18 <shardy> yeah, entirely possible we missed a patch somewhere and that tripleoclient stuff has hidden it
14:09:26 <EmilienM> ok
14:09:28 <marios> i think for the liberty to mitaka upgrade we had to explicitly re-run postconfig fot the keystone endpoints after the (I think) ceilometer migration... but for right now/master I think it is what shardy says we do it but in puppet ... need to check though
14:09:39 <dtrainor> akrivoka, i can help you with deployments today
14:09:56 <shardy> maybe we can push a patch which disables the postconfig in the CLI and see what breaks
14:10:12 <shardy> Doing that testing locally is probably a good first step
14:10:13 <EmilienM> #action investigate if whether or not postconfig actions (keystone endpoints management) is still run in tripleo/master
14:10:17 <akrivoka> dtrainor: thanks, that would be awesome
14:10:19 <EmilienM> shardy: right
14:10:46 <EmilienM> I would rather work on removing those postconfig things rather than moving them
14:10:54 <marios> for the *aodh* migration correction http://docs.openstack.org/developer/tripleo-docs/post_deployment/upgrade.html#upgrading-the-overcloud
14:10:59 <EmilienM> shardy: is that what you thought too?
14:12:36 <shardy> EmilienM: yes, definitely
14:12:45 <EmilienM> ok. akrivoka: good for you too?
14:12:49 <akrivoka> sounds good
14:12:54 <EmilienM> excellent
14:13:08 <EmilienM> I guess, depending on the results we'll have a different set of actions
14:13:37 <EmilienM> 1) if we find out that yes, postconfig is still run and we manage keystone endpoints with tripleoclient, we'll need to work on moving it to puppet like other resources and manage upgrade workflow
14:13:38 <akrivoka> I'll try to get a deployment working and investigate the necessity of post-deploy config
14:13:47 <EmilienM> 2) if no, let's remove this code in tripleoclient and close the bug
14:13:53 <EmilienM> we good?
14:14:00 <akrivoka> EmilienM: sounds good to me
14:14:06 <EmilienM> ok
14:14:10 <EmilienM> dtrainor: go ahead
14:14:11 <akrivoka> thanks guys
14:14:16 <dtrainor> hi EmilienM, thanks.  since we now install ui by default, and ui now requires undercloud ssl, i wanted to ask if it's appropriate yet to start enabling ssl on the undercloud by default as well.  i believe we'd be safe just defaulting generate_service_certificate to True.
14:15:02 <EmilienM> dtrainor: enabling SSL by default sounds good to me, as long as we provide a good user experience by making things working by default (ie: generate certs, etc)
14:15:04 <dtrainor> ...in the most simple basic case
14:15:21 <EmilienM> do we have objections?
14:15:32 <dtrainor> i've had ample experience working with an ssl-enabled undercloud as a requirement to making ui work and my experience has been pleasant
14:15:35 <dprince> dtrainor: seems to me we'd have to if UI is on by default. We might consider making the UI opt-in though
14:15:50 <dprince> dtrainor: having a lighter weight initial install that you build up seems reasonable too to me
14:15:58 <dtrainor> dprince, worth bringing up as well, yes
14:15:59 <dtrainor> agreed
14:16:01 <EmilienM> to me, enabling SSL improves security and I like being the default
14:16:15 <shardy> Unless it uses a lot of resources, I think we should have the UI enabled by default
14:16:17 <dprince> but if the UI is on by default and it requires SSL we have no choice to enable it too
14:16:23 <EmilienM> shardy: +1
14:16:25 <slagle> i will just grumble about how we keep  making everything slower in CI by default
14:16:31 <dtrainor> heh
14:16:36 <shardy> IMO the target audience of the UI will want to do the absolute minimum of customizations to deploy
14:16:45 <EmilienM> afik it's a webservice, I'm not sure how it will make things slower
14:16:46 <dtrainor> shardy++ exactly
14:17:00 <EmilienM> (except the puppet catalog on undercloud that might takes a few seconds longer to configure a single vhost)
14:17:01 <shardy> we could disable it in some CI jobs tho
14:17:02 <slagle> EmilienM: just the addition to the catalog will make things slower
14:17:18 <slagle> we used to be able to install the uc in < 10 minutes
14:17:20 <dprince> my take is, if we enable it in CI we should test it. Otherwise...perhaps it should be off to keep the jobs quicker/leaner
14:17:22 <slagle> now we are 20
14:17:25 <EmilienM> ok
14:17:35 <shardy> yeah, we don't have to test everything in every job tho
14:17:37 <d0ugal> EmilienM: Yeah, given it is entirely client side, unless a browser is viewing the UI it shouldn't do anything
14:17:38 <dtrainor> part of that testing may involve the ui which will break if ssl is disabled
14:17:46 <shardy> like we could apply the scenario model to undercloud testing
14:17:47 <EmilienM> enabling SSL is a good idea though, as we keep testing it.
14:18:05 <EmilienM> shardy: right
14:18:10 <EmilienM> we have a CI job for undercloud-only
14:18:12 <EmilienM> we could use it
14:18:15 <dtrainor> excellent
14:18:18 <EmilienM> and deploy UI on it
14:18:22 <EmilienM> I can help you with details
14:18:45 <dtrainor> it was nice to see this developed and tested btw
14:18:51 <dtrainor> and improved
14:18:55 <dtrainor> ssl on undercloud, that is
14:19:11 <EmilienM> so any objection to use undercloud-only CI job to deploy SSL and UI ?
14:19:12 <dtrainor> *golf clap*
14:19:50 <bnemec> EmilienM: So we would turn off the UI in the regular jobs?
14:19:59 <bnemec> And maybe ceilometer too since we defaulted that to on again?
14:20:03 <EmilienM> bnemec: well, as it is right now, no?
14:20:21 <jpich> It's enabled by default
14:20:27 <EmilienM> bnemec: I would ask pradk about ceilometer, a bit out of topic now
14:20:38 <EmilienM> maybe separate ceilometer & UI topics
14:21:07 <dtrainor> cool, i'll work on enabling ssl on the undercloud by default.  thanks EmilienM shardy slagle dprince for your feedback.
14:21:07 <shardy> well it's all part of the same requirement, build a matrix of CI coverage for optional undercloud pieces
14:21:17 <bnemec> Right
14:21:21 <shardy> IMO there's no need to enable UI or ceilometer on all jobs
14:21:24 <EmilienM> I saw lot of moves recently around ceilo on undercloud. I would sync with pradk
14:21:26 <pradk> in master we do yea
14:21:29 <shardy> only one job for each would be OK IMO
14:22:06 <EmilienM> right ^
14:22:25 <bnemec> Okay, sounds like we all agree. :-)
14:22:35 <EmilienM> good
14:22:48 <EmilienM> #topic CI
14:23:04 <EmilienM> ok so slagle is currently working hard on bringing our multinode jobs alive
14:23:12 <EmilienM> he has a patch here: https://review.openstack.org/#/c/387750/
14:23:27 <EmilienM> other than that, all other CI jobs should be ok
14:23:29 <slagle> i'm not working that hard :)
14:23:31 <EmilienM> OVB is working well
14:23:37 <bandini> lol
14:23:43 <EmilienM> I also have a FYI, thanks to bnemec we now have Mitaka jobs green again
14:23:52 <EmilienM> "makes Mitaka great again"
14:23:56 <EmilienM> ok sorry.
14:23:59 <slagle> EmilienM: i think all jobs are actually failing now
14:23:59 <beagles> :)
14:24:02 <bnemec> EmilienM: You should be. :-P
14:24:09 <slagle> on this pycparse issue
14:24:16 <slagle> pycparser
14:24:16 <EmilienM> anyway, CI is not in its best shape at this time
14:24:24 <EmilienM> I would ask our reviewers to carefuly merge patches
14:24:33 <EmilienM> and we need https://review.openstack.org/#/c/387750/ anyway
14:24:48 <EmilienM> probably it's the best time to go to the beach
14:24:54 <panda> and the strange thing is that periodic job are not that bad at the moment.
14:25:08 <EmilienM> panda: are they failing?
14:25:15 <slagle> https://github.com/eliben/pycparser/issues/151
14:25:20 <EmilienM> panda: why didn't we have a promotion in 6 days? https://dashboards.rdoproject.org/rdo-dev
14:25:23 <panda> EmilienM: only nonha is failing, for that haproxy error
14:25:25 <EmilienM> slagle: thx
14:25:31 <EmilienM> panda: ok the ceilo stuff?
14:25:53 <panda> EmilienM: the ceilo stuff combined with the bug on haproxy
14:26:08 <EmilienM> panda: is it reported somewhere?
14:26:21 <panda> EmilienM: https://bugs.launchpad.net/tripleo/+bug/1634468
14:26:24 <openstack> Launchpad bug 1634468 in tripleo "periodic nonha job fails to install undercloud" [High,Confirmed]
14:27:01 <EmilienM> ok
14:27:10 <EmilienM> panda: seems like you got it covered
14:27:20 <bnemec> Do we have a tag for promotion-blocking bugs?
14:27:22 <EmilienM> the haproxy thing is weird
14:27:41 <panda> EmilienM: yes, but I dont' understand why gates are acting so badly if periodic jobs are good
14:27:56 <EmilienM> panda: did we fix the ceilometer/haproxy thing?
14:28:01 <EmilienM> bnemec: not afik
14:28:04 <bnemec> EmilienM: It sounds like ceilometer needs to bind on a specific ip instead of 0.0.0.0.  This has been a common problem.
14:28:15 <bnemec> Okay, I'll add one.
14:28:35 <panda> bnemec: yes, we already have a patch for it
14:28:45 <EmilienM> and we merged it AFIK
14:28:50 <EmilienM> it's even in backport process now, right?
14:28:51 <panda> bnemec: the other problem is haproxy is failing to report failure correctly
14:29:59 <panda> EmilienM: I don't see as backport
14:30:02 <EmilienM> panda: this one right ? https://review.openstack.org/388035
14:30:18 <EmilienM> panda: or was it another patch?
14:30:32 <panda> EmilienM: that one, ye
14:30:35 <panda> s
14:30:36 <EmilienM> panda: please keep the bug updated with the maximum of infos in there
14:30:57 <panda> EmilienM: ok
14:31:02 <bnemec> Ugh, I hate moving services to WSGI this late in the cycle.
14:31:05 <EmilienM> anything else outstanding about bugs?
14:31:09 <bnemec> It has gone badly in the past.
14:31:19 <EmilienM> bnemec: on overcloud right. Undercloud is fine
14:31:24 <panda> I have a request about CI, please comment here http://lists.openstack.org/pipermail/openstack-dev/2016-October/105934.html
14:31:37 <bnemec> I'm pretty sure it wasn't for ironic.
14:31:42 <EmilienM> about CI I meant
14:31:54 <EmilienM> panda: thanks
14:32:09 <EmilienM> #action team to look at Gabriele's proposal on http://lists.openstack.org/pipermail/openstack-dev/2016-October/105934.html
14:32:45 <EmilienM> panda: do you want to discuss it here now?
14:33:09 <panda> EmilienM: if there are comment from anyone, sure
14:33:31 <EmilienM> panda: my only comment is about liberty. We don't care much about this release anymore, since it's EOL in less than 2 weeks.
14:34:40 <panda> EmilienM: ok, I think I can remove IPv6 config for that release then
14:34:48 <EmilienM> yep
14:34:54 <EmilienM> anything else about CI?
14:34:57 <panda> EmilienM: great, thanks.
14:35:32 <EmilienM> cool
14:35:36 <EmilienM> #topic bugs
14:35:48 <EmilienM> do we have outstanding bugs that are not in our radar already?
14:36:24 <EmilienM> I guess we have a bunch on ongoing work
14:36:51 <EmilienM> tag bugs *newton-rc-potential* if we want them backported
14:37:00 <EmilienM> err not the right tag
14:37:16 <EmilienM> : newton-backport-potential
14:37:27 <EmilienM> i'll go ahead with next topic if nothing outstanding
14:37:32 <EmilienM> #topic release management
14:37:38 <EmilienM> so we release tripleo RC3 today, it's done
14:37:57 <EmilienM> we still have a bunch of bugs open, but because of CI issues we can't land the fix
14:38:10 <EmilienM> final release in on Thursday
14:38:30 <EmilienM> dhellmann: I won't be here on Thursday, neither shardy
14:38:45 <EmilienM> dhellmann: if you need a point of contact for TripleO, maybe you can ask on #tripleo channel
14:38:51 <EmilienM> trown is also our release contact
14:39:16 <trown> I am? :) wfm
14:39:52 <EmilienM> once we close our current critical bugs that are still ongoing, I'll propose a new subrelease, probably  within the next 2 weeks
14:39:59 <EmilienM> trown: you are now. Welcome!
14:40:17 <EmilienM> any question / feedback about release?
14:40:42 <EmilienM> #topic specs
14:40:51 <EmilienM> #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
14:41:31 <EmilienM> I'm a little sad to see https://review.openstack.org/#/c/387631/ coming late
14:41:41 <EmilienM> as we already prepare our sessions
14:42:09 <shardy> fultonj: I know you were keen to get feedback on this
14:42:13 <EmilienM> but I hope we can find time at the Summit to discuss about this one
14:42:14 <fultonj> EmilienM: sorry about that
14:42:29 <EmilienM> fultonj: we'll deal with it ;-)
14:42:31 <fultonj> EmilienM: thanks !
14:42:46 <fultonj> if there's any feedback on it I'd welcome it and be happy to update
14:43:01 <EmilienM> does anyone want to talk about a specs?
14:43:08 <shardy> I think this is part of a broader discussion about how to handle interfacing with external tools, e.g not puppet or heat orchestrated deployments
14:43:19 <EmilienM> a last reminder for people who own specs: make them ready to discuss for the Summit
14:43:37 <EmilienM> shardy: right, that's why i'm a little sad to see it so late, as it might require some time
14:43:57 <EmilienM> shardy, fultonj: also, I would like to see some discussion (maybe on the ML) about it
14:44:10 <fultonj> EmilienM: ok, i'll start a thread.
14:44:17 <EmilienM> cool
14:44:19 <shardy> sounds good, thanks fultonj
14:44:24 <EmilienM> #topic Summit
14:44:39 <EmilienM> so we have an agenda www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=TripleO%3A
14:44:40 <EmilienM> #link www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=TripleO%3A
14:44:50 <EmilienM> I need to polish it this week
14:45:01 <EmilienM> but mostly done
14:45:22 <EmilienM> please let me know asap if you have a timing conflict
14:45:50 <EmilienM> don't tell me you have conflict in Barcelona, it will be too late.
14:45:51 <shardy> Last time I checked there were two conflicts with heat sessions, but I did request anti-affinity when the initial draft schedule was posted some time ago
14:45:56 <shardy> so I assume there's nothing we can do about it
14:46:01 <EmilienM> shardy: damn
14:46:12 <EmilienM> shardy: there is nothing I can do between tripleo/heat sessions :(
14:46:15 <shardy> we've had worse overlaps in the past, we'll manage it
14:46:24 <EmilienM> shardy: what heat sessions?
14:46:55 <EmilienM> shardy: maybe we can make change our sessions schedule?
14:47:04 <EmilienM> I know containers session was tricky
14:47:10 <EmilienM> I made sure flaper87 and rhallisey can join
14:47:31 <panda> ugh, they're actually on a different building than the main conference :( commute time.
14:47:42 <EmilienM> dprince, trown, marios: you ok with schedule? you are chairs, so...
14:47:55 <marios> EmilienM: unless upgrades on thursday has changed then yeah am good
14:48:00 * marios checks again
14:48:05 <trown> EmilienM: +1 for me
14:48:17 <EmilienM> marios: no change
14:48:24 <EmilienM> excellent
14:48:30 <marios> thanks
14:48:34 <shardy> Fri 28  9:50am-10:30am actually looks to be the only heat->tripleo conflict int he final schedule
14:48:35 <EmilienM> shardy: let me know how can I help but I guess it's late now to change heat sessions
14:48:37 <trown> I am flexible too if things need to be shuffled
14:48:52 <EmilienM> shardy: ok, which topic is in heat session?
14:49:00 <dprince> EmilienM: schedule seems fine to me
14:49:17 <shardy> API microversions, so probably not essential to have all the TripleO folks there
14:49:49 <EmilienM> ok
14:49:56 <EmilienM> sorry for conflict :-(
14:50:06 <EmilienM> any feedback/question about summit?
14:50:30 <saneax> is there a list of folks attending the tripleo sessions?
14:50:59 <EmilienM> saneax: not afik
14:51:07 <shardy> saneax: No, they are open to everyone
14:51:18 <saneax> ok
14:52:21 <EmilienM> #topic open discussion
14:52:30 <EmilienM> fantastic, we have 8 min for open discussion
14:52:43 <EmilienM> please go ahead if you have any question or feedback about anything
14:52:49 <EmilienM> even a joke. Go ahead.
14:52:52 <shardy> I'd appreciate ideas on https://bugs.launchpad.net/tripleo/+bug/1633090
14:52:53 <openstack> Launchpad bug 1633090 in tripleo "composable roles and network isolation" [Medium,Triaged] - Assigned to Steven Hardy (shardy)
14:53:10 <shardy> mcornea raised the idea of automatically generating the nic templates based on the networks enabled for each role
14:53:16 <shardy> calculated from the ServiceNetMap
14:53:33 <shardy> which is a nice idea, but I don't think we can do it without creating a versioned interface to the nic templates
14:53:42 <shardy> e.g OS::TripleO::Controller::Net::SoftwareConfigv2
14:53:44 <shardy> or something
14:53:57 <shardy> I'll start a ml thread with some ideas, but happy to get feedback on the bug also
14:54:20 <shardy> the problem is we need to pass the list of enabled networks into OS::TripleO::Controller::Net::SoftwareConfig
14:54:32 <shardy> which is not possible without breaking all existing users of that interface
14:54:38 <EmilienM> shardy: right
14:54:54 <EmilienM> we'll need a versioning, indeed
14:55:04 <EmilienM> or an API transition between cycles
14:55:17 <shardy> we could do it via j2 rendering so folks opt in to the new interface on a per-role basis
14:55:22 <shardy> via roles_data.yaml
14:55:36 <shardy> but perhaps there's a cleaner approach
14:56:58 <EmilienM> shardy: good
14:57:06 <EmilienM> I'll close the meeting in 30s
14:57:18 <EmilienM> I'm on PTO from now until Monday
14:57:27 <EmilienM> I'll check emails every day and IRC sometimes.
14:57:29 <shardy> enjoy EmilienM
14:57:34 <jrist> +1
14:57:39 <EmilienM> please don't break CI more than it's broken now :)
14:57:55 <shardy> I'm also out for the rest of this week
14:57:55 <EmilienM> and see you on the other side (don't worry I'm not the pilot)
14:58:02 <EmilienM> shardy: enjoy too
14:58:02 <beagles> lo
14:58:10 <EmilienM> #endmeeting