14:00:15 <shardy> #startmeeting tripleo
14:00:16 <openstack> Meeting started Tue Jul 19 14:00:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'tripleo'
14:00:24 <shardy> #topic rollcall
14:00:26 <EmilienM> bonjour :)
14:00:30 <panda> o/
14:00:31 <sshnaidm> o/
14:00:32 <shardy> Hi all, who's around?
14:00:35 <weshay_mtg> o/
14:00:35 <dprince> hi
14:00:37 <coolsvap> o/
14:00:39 <skramaja> hello
14:00:41 <hrybacki> o/
14:00:48 <marios> \o
14:00:48 <trown> o/
14:00:55 <ccamacho> hi o/
14:01:00 <saneax> o/
14:01:11 <jokke_> o/
14:01:20 <gfidente> o/
14:01:24 <derekh> o/
14:01:32 <beagles> o/
14:01:34 <jaosorior> o/
14:01:57 <rbrady> \o
14:02:21 <shardy> #link https://wiki.openstack.org/wiki/Meetings/TripleO
14:02:37 <shardy> #link https://etherpad.openstack.org/p/tripleo-meeting-items
14:02:49 <shardy> #topic agenda
14:02:49 <shardy> * one off agenda items
14:02:50 <shardy> * bugs
14:02:50 <shardy> * Projects releases or stable backports
14:02:50 <shardy> * CI
14:02:52 <shardy> * Specs
14:02:54 <shardy> * open discussion
14:03:06 <shardy> So I see one one-off item from EmilienM, anyone have anything else to add?
14:03:32 <shardy> #topic one off agenda items
14:03:47 <EmilienM> my item should be quick, I just want people interested by service validation to read my email and give feedback about the proposal.
14:04:05 <EmilienM> the idea is to "stop a deployment if something fails in a step"
14:04:17 <EmilienM> so we save time for deployers and give feedback on what failed
14:04:24 <ccamacho> shardy I added the item in the last meeting.
14:04:31 <ccamacho> sorry..
14:04:53 <ccamacho> EmilienM++ I like that idea to save time
14:05:09 <rhallisey> hi
14:05:24 <shardy> EmilienM: I like the idea of fail-fast, but it'd be kinda nice if the validation steps weren't combined with the puppet configuration?
14:05:40 <EmilienM> I made it on purpose
14:05:46 <shardy> I thought that was the approach SpinalStack took with serverspec, or am I remembering incorrectly?
14:05:48 <EmilienM> so the validation is as close as possible with our profiles
14:06:02 <EmilienM> shardy: we used another approach in SpinalStack with serverspec
14:06:09 <ccamacho> might at least a --fail-fast option work?
14:06:10 <EmilienM> the idea here is to make the validation within our profiles
14:06:28 <shardy> EmilienM: Ok, I guess I was thinking about it differently, where a given service template has an expected validation, regardless of the tool used
14:06:30 <EmilienM> so we don't have to wire validation scripts with our roles
14:06:36 <dprince> EmilienM: I think I would like to consider keeping the validations within the heat composable services
14:07:01 <shardy> EmilienM: I'm thinking particularly of folks interested in plugging in non-puppet tools (such as ceph-ansible which I know some folks have interest in reusing)
14:07:16 <shardy> I guess that's all dependent on containers anyway, just thinking ahead
14:07:18 <EmilienM> they can write their validation in ceph-ansible itself!
14:07:24 <EmilienM> my PoC is just for Puppet profiles
14:07:32 <dprince> EmilienM: https://review.openstack.org/#/c/174150/
14:07:36 <EmilienM> but anyone plugged to TripleO (ie: ceph-ansible) could validate their own way
14:07:37 <dprince> shardy: ^^
14:07:52 <dprince> that was our initial attempt at generic "script" style validations a while back...
14:08:01 <jokke_> EmilienM: ++
14:08:08 <EmilienM> I think we should make validation as close as possible from our profiles
14:08:14 <EmilienM> whatever tool (puppet ansible, etc)
14:08:21 <gfidente> yeah I was a bit confused as well about how this can work togeher with the tooling shadower is working on
14:08:24 <EmilienM> we just need to fail fast
14:08:26 <shardy> dprince: Yeah, that was the pattern I was thinking of
14:08:33 <jokke_> EmilienM: makes sense that the component that defines what and how also validates that the outcome was what intended
14:08:35 <EmilienM> gfidente: it's different, post deployment
14:08:40 <dprince> EmilienM: that works for single node validation framework I think. But what about multi-node stuff?
14:08:41 <EmilienM> and this is not the same validation
14:08:50 <shardy> gfidente: Yeah, I don't think it can, because the ansible based validations aren't integrated with the heat deployment steps
14:08:53 <EmilienM> my stuff is really low level validation
14:09:00 <shardy> that's more about pre-flight-checks I think
14:09:23 <EmilienM> I don't aim to test APIs
14:09:25 <EmilienM> or boot a VM
14:09:28 <EmilienM> etc
14:09:28 <dprince> a validations "framework" will have all of the above. pre-during-and post validations
14:10:17 <EmilienM> anyway, I produced a PoC based on operators feedback
14:10:27 <EmilienM> feel free to use the ML thread to comment and give feedback
14:10:36 <EmilienM> and if you have a better idea, please submit it
14:10:36 <shardy> EmilienM: ack, thanks, lets follow up on the ML :)
14:10:42 <EmilienM> shardy: yup
14:10:47 <shardy> ccamacho: you had a question about tripleo-ui?
14:10:56 <shardy> jtomasek: Can you provide an update on the status there?
14:10:57 <dprince> EmilienM: do we think validations is more important right now than finishing the composable services work and composable roles?
14:10:59 <ccamacho> yeahp, a quick one. Is anyone using it?
14:11:11 <EmilienM> dprince: not at all. I just implemented a 5min idea
14:11:15 <dprince> EmilienM: perhaps this is a next release feature
14:11:24 <EmilienM> dprince: as you can see, the patch is 10LOC
14:11:26 <shardy> ccamacho: AFAIK it's blocked on the mistral API landing, which is still in-progress, but hopefully jtomasek can confirm
14:11:33 <EmilienM> dprince: for sure, at this stage of the cycle.
14:11:51 <EmilienM> dprince: I'm preparing next Summit ;-)
14:12:04 <ccamacho> shardy ack, I was reading docs and found lot of empty spots there.. That's why I was asking
14:12:14 <jtomasek> shardy: I am happy to answer anything about TripleO UI, I am currently at the meeting, so I am slow to respond. Which part specifically is the concern?
14:12:33 <shardy> jtomasek: when folks can start using it on upstream builds
14:12:52 <shardy> jtomasek: e.g when can we get it integrated with the undercloud install, are we blocked on the remaining mistral patches?
14:13:04 <shardy> e.g the actions/workflows going into tripleo-common
14:13:16 <ccamacho> jtomasek, about using it and testing it in in upstream tripleo
14:13:22 <jtomasek> shardy: no blockers really, biggest obstacle now is resolve the rdo packaging of GUI
14:13:42 <jtomasek> shardy: the work on integrating it with undercloud starts this week too
14:13:47 <ccamacho> jtomasek, but from source, should work right?
14:13:51 <dprince> jtomasek: do you have someone working on a puppet module to install it?
14:13:59 <jtomasek> ccamacho: yes
14:14:28 <jtomasek> dprince: flfuchs is about to start on it, but any help is welcome and would deffinitely speed up the process
14:14:37 <ccamacho> jtomasek, ack as should be nice to have some puppet automation for that, nice!
14:14:44 <dprince> jtomasek: cool.
14:14:47 <shardy> jtomasek: Ok, sounds good, shout if we can provide any help and/or test/review things
14:14:57 <ccamacho> shardy++
14:15:12 <jtomasek> shardy, ccamacho, dprince: thanks!
14:15:20 <shardy> Any other one-off items before we move on?
14:15:42 <shardy> #topic bugs
14:16:08 <shardy> So, related to bugs, jpich started a discussion on the ML about the various launchpad projects
14:16:19 <EmilienM> dprince: can you add the tag for your hieradata bugs ? https://bugs.launchpad.net/tripleo/+bugs?field.tag=composable-roles
14:16:22 <shardy> in particular there seems to be a redundant one related to tripleo-common we can probably remove
14:16:31 <gfidente> sorry guys, one step back to one-off, is anybody looking into why mitaka/ci fails?
14:16:46 <EmilienM> gfidente: wasn't it the gnocchi thing?
14:17:10 <shardy> gfidente: shall we cover that in the CI section?
14:17:24 <gfidente> ack
14:17:33 <shardy> Do folks have any opinions about the launchpad tracking?
14:17:50 <EmilienM> gfidente: nevermind it looks like something else, it fails after 15 min
14:17:56 <dprince> EmilienM: tag should be 'composable-services' but whatever
14:18:02 <shardy> Personally I'd rather have one for most tripleo things, e.g https://bugs.launchpad.net/tripleo
14:18:23 <shardy> vs lots and lots of LP projects to manage
14:18:36 <dprince> shardy: I fine to file bugs for things
14:18:39 <shardy> it's easier from a release tracking/milestones perspective if we're going to release everything each milestone IMO
14:18:46 <EmilienM> dprince: yeah, please add it to the 2 bugs
14:19:04 <jokke_> shardy: taken the number of repos, I'd prefer single track with tags
14:19:16 <EmilienM> dprince, shardy: +1 for launchpad/bugs
14:19:18 <dprince> EmilienM; already done
14:19:21 <EmilienM> dprince: ++
14:19:58 <shardy> https://bugs.launchpad.net/tripleo-common https://bugs.launchpad.net/tripleo-ui https://bugs.launchpad.net/tripleo-validations https://bugs.launchpad.net/tripleo-quickstart all also exist
14:20:14 <shardy> I'd suggest we remove the tripleo-common one, and probably the tripleo-validations one?
14:20:14 <gfidente> yeah I was going to say that we probably want something in between
14:20:36 <shardy> It's probably fine to have a separate one for the UI at this point though I think
14:20:38 <gfidente> a few projects seem better tracked with their own project but I wouldn't split all
14:20:58 <jokke_> shardy: what's in on those two? (sorry for my ignorance still)
14:21:22 <shardy> jokke_: Not much, hence my proposal to remove them :)
14:21:29 <shardy> shadower: any thoughts re the validations one?
14:22:13 <shardy> Ok, well we can follow up on the ML anyway
14:22:15 <dprince> shardy: +1 on removing the tripleo-common and tripleo-validations bugs
14:22:29 <shardy> any other bugs related things to mention today?
14:23:04 <shardy> #topic Projects releases or stable backports
14:23:20 <shardy> So, we had the n2 release, but I was thinking we're probably overdue a release of the stable branches
14:23:35 <EmilienM> shardy: we can take care of it this week
14:23:38 <shardy> coolsvap: Were you planning to propose those, or shall I go ahead and do it?
14:24:01 <coolsvap> shardy: i can do that
14:24:41 <shardy> coolsvap: Ok, thanks - perhaps you can ping me and EmilienM when you've posted the patch and we can review
14:24:52 <coolsvap> shardy: sure
14:24:59 <EmilienM> but we need to make sure Mitaka jobs are working
14:25:04 <EmilienM> (currently broken)
14:25:16 <shardy> Yeah, obviously we'll need to get a good promote before we can release
14:25:28 <EmilienM> yup we'll take care of it ^
14:25:42 <shardy> ++ Ok, sounds good, thanks :)
14:25:49 <shardy> #topic CI
14:25:54 <EmilienM> so Mitaka job looks broken
14:25:57 <EmilienM> http://logs.openstack.org/25/342725/3/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha/3dd5eb0/console.html#_2016-07-19_13_48_29_492778
14:26:06 <EmilienM> ERROR:dlrn:cmd failed. See logs at: /opt/stack/new/delorean/data/repos/f1/13/f113c9e4103b7ed593c74c2c8517363843e99ed0_969c6c49/
14:26:08 <sshnaidm> One issue is with building delorean rpms for THT mitaka and liberty - asked apevec to look at it, but still haven't received a response from him yet: https://bugs.launchpad.net/tripleo/+bug/1604039
14:26:08 <openstack> Launchpad bug 1604039 in tripleo "CI: delorean build of tripleo-heat-templates fails because wrong spec" [High,Triaged]
14:26:11 <EmilienM> INFO:dlrn:Skipping notify email to ['jslagle@redhat.com', 'dprince@redhat.com']
14:26:18 <sshnaidm> EmilienM, ^^
14:26:20 <EmilienM> slagle and dprince must have received an email :)
14:26:26 <weshay_mtg> can we add folks to that list?
14:26:43 * dprince isn't getting emails about this
14:26:45 <bnemec> *Skipping* notify email...
14:26:48 <EmilienM> yeah :)
14:26:53 <shardy> I guess we can try reproducing this locally with STABLE_RELEASE=mitaka tripleo.sh --delorean-build openstack/foo
14:27:21 <sshnaidm> shardy, for tht
14:27:23 <shardy> Actually we'll need to do --repo-setup with REPO_PREFIX set too
14:27:35 <panda> why is it skipping ?
14:28:05 <shardy> https://dashboards.rdoproject.org/rdo-dev
14:28:13 <derekh> panda: it skips in CI because we don't have a mail server configured, and we don't want it in CI
14:28:30 <shardy> current-tripleo promoted 2d ago, but it's been 13 days since RDO promotion, some of which look tripleo related
14:28:32 <derekh> but it should be configured on the trunk server running delorean
14:28:42 <shardy> e.g the gnocci db sync issue and a couple of others
14:29:33 <sshnaidm> And all periodic jobs failed tonight because: https://bugs.launchpad.net/tripleo/+bug/1604380
14:29:33 <openstack> Launchpad bug 1604380 in tripleo "CI: nodes registrtion in periodic jobs fail because of bug in old pecan (fixed in 1.0.5)" [High,New]
14:29:45 <EmilienM> yeah, same for Puppet CI
14:29:52 <EmilienM> we have the same issue, good to know :)
14:29:56 <trown> the new build of pecan is wating on sync in RDO
14:29:57 <shardy> sshnaidm: ack, thanks for pointing that out
14:30:04 <trown> will hit at 16:12 UTC
14:30:06 <weshay_mtg> ya. and rdo ci :)
14:30:07 <EmilienM> trown: excellent news
14:30:08 <shardy> can we add a periodic_cistatus page to tripleo.org?
14:30:13 <shardy> I would find that useful
14:30:39 <shardy> weshay_mtg: Do you have any updates re the status of third-party CI?
14:31:04 <shardy> IIRC you were looking to enable upgrades and trunk deployments on RHEL?
14:31:17 <derekh> shardy: sshnaidm might be able to get his status page there
14:31:33 <shardy> (If we're getting RHEL coverage I'll abandon https://review.openstack.org/#/c/340503/)
14:31:46 <shardy> derekh: Yeah that'd be good
14:31:48 <jokke_> it might be helpful to sync with the work harlowja is doing with the oslobot
14:31:50 <weshay_mtg> shardy, ya.. apetrich has a few patches required merged as of yesterday, now we're testing and getting some inconsistent installs atm..
14:32:22 <jokke_> that's providing status of all periodic oslo integration tests to the channel
14:32:27 <weshay_mtg> attila also just went on pto, so that wil slow down the 3rd party rhel gate.. by a few days
14:32:51 <shardy> weshay_mtg: ack, Ok no worries, thanks for the update :)
14:33:12 <shardy> derekh: So, what's up with rh1, have you OVB-ified it yet?
14:33:58 <derekh> shardy: zoli is working on it, he only started on thursday and is hitting problems with foreman (don't ask)
14:34:25 <shardy> derekh: Ok - anything you need help with, or is it just a matter of more time?
14:34:33 <derekh> shardy: anyways I've been helping him work through them, progress is been made but still at the early stages
14:35:34 <derekh> shardy: time at the moment but if he hits any brick walls others can assist we'll pick people
14:35:46 <shardy> derekh: Ok, sounds good, thanks for the update :)
14:35:57 <EmilienM> yeah, pick us if needed
14:36:44 <derekh> EmilienM: will do
14:37:08 <shardy> Ok, anything else re CI before we continue?
14:37:16 <sshnaidm> However, can anybody from RDO people help with mitaka/liberty delorean fails of tht? it's already 2 days long https://bugs.launchpad.net/tripleo/+bug/1604039
14:37:16 <openstack> Launchpad bug 1604039 in tripleo "CI: delorean build of tripleo-heat-templates fails because wrong spec" [High,Triaged]
14:37:38 <sshnaidm> I'd like to be sure that somebody cares about it
14:38:01 <shardy> sshnaidm: I'd jump into #rdo and chat with apevec and trown about it
14:38:26 <shardy> #topic Specs
14:38:33 <sshnaidm> shardy, great, thanks
14:39:10 <shardy> https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
14:39:44 <shardy> It'd be good to review the dpdk, sr-iov, Ironic, lightweight-HA and validations specs if anyone has time
14:40:02 <shardy> It'd be good to land them if we expect the features to get done for newton
14:40:42 <shardy> https://launchpad.net/tripleo/+milestone/newton-3
14:40:52 <bnemec> Would like more feedback on the idea of having a policies section: https://review.openstack.org/339236
14:40:53 <shardy> That's the feature list I'm working to planning for the n-3 release
14:41:49 <shardy> bnemec: +1, I'm fine with it, and I see you replied to my comment re -docs vs -specs
14:42:10 <bnemec> shardy: Cool, thanks
14:43:03 <shardy> #link http://osdir.com/ml/openstack-dev/2016-07/msg00724.html
14:43:06 <EmilienM> bnemec: will look after the meeting
14:43:16 <shardy> I sent that re the feature-freeze process after we disussed it last week
14:43:27 <shardy> feel free to reply on the ML if there are any comments
14:44:05 <shardy> basically we can probably land some things as FFEs but we can't rely on it for the big backlog of n-3 targetted features
14:44:37 <shardy> #topic open discussion
14:44:48 <shardy> Anyone have anything else they would like to add?
14:44:56 <trown> I have a question
14:45:18 <trown> who would like to be the package maintainer for os-*-config repos in RDO? :)
14:45:32 <EmilienM> I have an FYI: I dropped the weekly composable-roles meeting since we moved all puppet code. Remaining work does not require meeting imho, let me know if you disagree
14:45:44 <trown> currently there is nobody listed in https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml
14:46:44 <dprince> EmilienM: no need for a meeting now I think. Lets drop it
14:46:45 <trown> nobody?
14:46:56 <shardy> trown: I'm happy to do it if nobody else is keen
14:47:00 <EmilienM> dprince: done
14:47:03 <jokke_> I'd like to poke a bit of people's feelings
14:47:46 <trown> shardy: k, I am getting pinged by people to merge https://review.rdoproject.org/r/#/c/1678/1 but wanted to have an actual maintainer for those because I do not totally understand them
14:48:02 <jokke_> The ceph-ansible work towards Ocata. Are folks comfy with that or is there something we should consider on that work?
14:48:25 <jokke_> I know there is quite a bit of push from the Ceph folks to move to that ansible blop
14:48:38 <EmilienM> I'm really curious about this work, is it going to kill puppet-ceph usage in tripleo?
14:48:40 <shardy> jokke_: It's not even been properly discussed yet, I think we'll need a summit session to consider how non-puppet deployments can be integrated into tripleo
14:48:58 <shardy> EmilienM: There are folks who don't want to maintain both puppet-ceph and ceph-ansible
14:49:04 <EmilienM> right
14:49:06 <jokke_> shardy: That's why I wanted to bring the discussion to people's minds
14:49:08 <trown> shardy: so in the short term if you wanted to do a sanity check on that review, that will be great... and maybe I can put you down in rdoinfo until you can appoint a replacement?
14:49:25 <bnemec> trown: slagle and I are the maintainers of the fedora package.
14:49:25 <shardy> so they want to wire in ceph-ansible to tripleo - which I think will be possible only after we've got a way to isolate the puppet and ansible configuration (e.g containers)
14:49:46 <trown> bnemec: ok, can I put you guys down for RDO then?
14:50:14 <gfidente> I think that finishing our abstraction to use ansible would be nice, ceph-ansible could be a first consumer of that
14:50:15 <trown> bnemec: and could you review https://review.rdoproject.org/r/#/c/1678/1 :)
14:50:16 <bnemec> trown: I would be fine with that.
14:50:28 <dprince> trown: I would like to talk with steve baker on https://bugs.launchpad.net/tripleo/+bug/1603144
14:50:28 <openstack> Launchpad bug 1603144 in tripleo "older os-collect-config can't be updated or upgraded via heat" [High,Invalid] - Assigned to Marios Andreou (marios-b)
14:50:31 <ccamacho> guys quick question, are CI jobs taking ~+2 hours?
14:50:50 <ccamacho> maybe it's just me
14:50:52 <dprince> trown: specifically the implication there might be that we have some os-collect-config code for the reexec that isn't being used I think
14:50:58 <gfidente> so I'd like a summit session about the more general introduction of ansible as well
14:50:58 <EmilienM> ccamacho: ~1h40
14:51:03 <dprince> trown: and I'd like to get rid of that code anyways...
14:51:05 <trown> dprince: ya he is on PTO, and people are bugging me to merge that... I dont totally understand what is going on and so I am not comfortable merging it myself
14:51:07 <EmilienM> ccamacho: see http://tripleo.org/cistatus.html
14:51:14 <ccamacho> EmilienM ack, thanks!
14:51:16 <shardy> FWIW I did a little PoC with one of ceph-ansible folks: https://github.com/hardys/heat-ceph-templates/blob/master/mon_cluster.yaml#L61
14:51:31 <shardy> It shows that we can wire in ansible roles in a similar way to how we deploy puppet modules
14:51:40 <EmilienM> so we're going to mix puppet & ansible within a same deployment? interesting
14:51:40 <shardy> but it doesn't solve how we drive a mixture of two tools in t-h-t
14:51:53 <shardy> EmilienM: I would prefer that we didn't, but it's what some users are asking for
14:52:07 <trown> dprince: so as long as we dont think it is totally broken, I think we should merge it, and discuss with sbaker when he is back from PTO
14:52:12 <shardy> I think it only really makes sense when we have a fully containerized overcloud tho tbh
14:52:25 <dprince> shardy: I'd like to treat the Ceph ansible as perhaps an opt-int (3rd party) feature
14:52:36 <shardy> so we probably need to focus on that, and ensure the abstractions around puppet are sufficient to enable alternative tooling to plug in
14:52:53 <shardy> dprince: Sure, I don't think anyone is proposing changing any defaults at this point
14:52:59 <jokke_> EmilienM: that's why I wanted to ask if people are confortable with the idea in principle ... 'cause there is definitely push for it but I'd like to keep the expectations realistic
14:53:04 <marios> dprince: do you disagree with the packaging fixup there?
14:53:04 <shardy> only figuring out if/how this may be possible to integrate
14:53:05 <dprince> shardy: specifically because it may cost some integration features. Specifically, the ability to configure advanced things with extra_config
14:53:15 <marios> dprince: i mean for sbaker SIGKILL on occ
14:53:24 <shardy> dprince: Yeah, I think it's understood that all *ExtraConfig hieradata overrides will break
14:53:28 <dprince> marios: I haven't tried it. It just made me curious
14:53:37 <EmilienM> what is missing in puppet-ceph (existing setup), that we have in ceph-ansible?
14:53:51 <EmilienM> I think the goal here is to "make Ceph deployment better"
14:54:00 <EmilienM> so let's figure why we need ceph-ansible?
14:54:31 <marios> dprince: ok. apparently it was done downstream k already. but we can discuss on the bug/offline if you like
14:54:34 <dprince> EmilienM: exactly, I'm not sure there is anything that can't be done with puppet-ceph as well. Perhaps both implementations can live with parity
14:54:38 <bnemec> EmilienM: It's because that's where the ceph team is making all of their improvements, so unless we want to duplicate them we have to use it.
14:54:47 <marios> dprince: (downstream _in_ K, kilo i mean)
14:54:52 <shardy> EmilienM: folks are invested in ceph-ansible as "the" tool, they're not willing to contribute to puppet-ceph as well AFAICT
14:54:55 <jokke_> EmilienM: iiuc the push is mostly just about the maintenance overhead of two of them
14:55:14 <jokke_> reasoning why there is the ceph-ansible in first place is something I can't answer
14:55:16 <EmilienM> ok
14:55:22 <dprince> I still think there may be a community around puppet-ceph though
14:55:36 <EmilienM> after all our efforts in puppet-ceph
14:55:37 <gfidente> well there is one for sure, fuel
14:55:42 <EmilienM> lol we'll just kill it
14:56:01 <gfidente> but I suggest we don't look at the two things together
14:56:07 <dprince> perhaps even a larger one than the ansible-ceph thing. I don't know... but I think pulling the rug on puppet-ceph would be premature
14:56:08 <jokke_> the last thing I want to see is that we spend lots of time to get it integrated and receive -2 for principle reasons
14:56:12 <EmilienM> gfidente: right, they overlap a lot
14:56:16 <gfidente> testing tripleo ability to use ansible can be done as a pre-requisite
14:56:48 <gfidente> risks of migration to ceph-ansible has pros and cons I suppose and it's not same problem
14:56:50 * bnemec thinks we should just let the Ceph installer install Ceph and drop the tripleo deployment of it entirely
14:56:50 <dprince> jokke_: As a replacement for puppet-ceph at this point I would likely -2 it
14:57:00 * bnemec also wants a unicorn for his birthday
14:57:08 <dprince> jokke_: as an opt-in (live beside) it may be okay though
14:57:10 <EmilienM> bnemec: yes - 100% agree
14:57:23 <shardy> bnemec: The problem is folks want hyper-converged deployments, not only standalone external ceph clusters
14:57:36 * trown gets bnemec a hornless unicorn for his birthday
14:57:36 <shardy> if it was all external we could just drive ansible via a mistral action or something
14:57:40 <EmilienM> bnemec: we have this integration with nova/cinder/glance/gnocchi that we don't need puppet-ceph or ceph-ansible
14:57:51 <jokke_> dprince: thanks ... I'll get that feedback to the expectations loop
14:58:04 <gfidente> EmilienM, well that's the point of ceph-ansible
14:58:14 <gfidente> we don't need puppet-ceph to configure ceph, we can use ceph-ansible for that
14:58:17 <EmilienM> gfidente: what, it also configure nova.conf, etc?
14:58:27 <gfidente> but we'll continue to use puppet-nova for the nova configuration
14:58:32 <shardy> Ok, well I guess this is the start of a longer discussion - jokke_ do you want to start a ML thread or shall I?
14:58:48 <jokke_> shardy: either way is fine by me
14:58:53 <EmilienM> my point is: we could use ansible-ceph to configure Ceph and puppet-nova,glance,cinder,... to configure services like nova,glance,cinder,... to use ceph backend
14:58:58 <jokke_> I can add it to my todo list
14:59:02 <gfidente> this said, don't misinterpret me as I would myself push back ceph-ansible only to when we discussed the integration of ansbile successfully
14:59:06 <shardy> Ok, I'll do it after the meeting & people can add their thoughts
14:59:08 <EmilienM> shardy: 1 min left
14:59:08 <gfidente> as I don't see technical reasons for ceph-ansible today
14:59:33 <shardy> Ok, out of time, thanks all!
14:59:38 <shardy> #endmeeting