19:02:13 <slagle> #startmeeting tripleo
19:02:13 <openstack> Meeting started Tue Jun 30 19:02:13 2015 UTC and is due to finish in 60 minutes.  The chair is slagle. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:17 <openstack> The meeting name has been set to 'tripleo'
19:02:26 <slagle> hello everyone
19:02:35 <slagle> or maybe hello jdob i should say :)
19:02:58 <jdob> :)
19:03:07 <jdob> shit, my chances of getting stuck with releases are super high then, aren't they
19:03:38 <slagle> heh
19:03:51 <slagle> #topic agenda
19:03:51 <slagle> * bugs
19:03:51 <slagle> * reviews
19:03:51 <slagle> * Projects needing releases
19:03:51 <slagle> * CI
19:03:53 <slagle> * Specs
19:03:56 <slagle> * open discussion
19:03:58 <slagle> #topic bugs
19:04:05 <slagle> #link https://bugs.launchpad.net/tripleo/
19:04:05 <slagle> #link https://bugs.launchpad.net/diskimage-builder/
19:04:05 <slagle> #link https://bugs.launchpad.net/os-refresh-config
19:04:05 <slagle> #link https://bugs.launchpad.net/os-apply-config
19:04:05 <slagle> #link https://bugs.launchpad.net/os-collect-config
19:04:08 <slagle> #link https://bugs.launchpad.net/os-cloud-config
19:04:10 <slagle> #link https://bugs.launchpad.net/os-net-config
19:04:13 <slagle> #link https://bugs.launchpad.net/tuskar
19:04:15 <slagle> #link https://bugs.launchpad.net/python-tuskarclient
19:06:04 <slagle> dprince: is there any update on this one? https://bugs.launchpad.net/tripleo/+bug/1464239
19:06:04 <openstack> Launchpad bug 1464239 in tripleo "mount: special device /dev/sdb does not exist" [Critical,In progress] - Assigned to Dan Prince (dan-prince)
19:06:22 <slagle> do we still have that nova change reverted in tripleo-ci?
19:07:48 <slagle> dprince: ditto for https://bugs.launchpad.net/tripleo/+bug/1463107
19:07:48 <openstack> Launchpad bug 1463107 in tripleo "Fedora seed fails to build due to python-ipaddress package requirement" [Critical,In progress] - Assigned to Dan Prince (dan-prince)
19:08:00 <d0ugal> o/
19:10:23 <slagle> alright i don't see anymore untriaged bugs
19:10:39 <slagle> #topic reviews
19:10:51 <slagle> are there any reviews anyone would like to ask for attention on?
19:11:12 <jdob> not from me
19:11:53 <slagle> #topic releases
19:12:29 <slagle> i think we can probably release on demand this week if anyone asks for it
19:12:46 <slagle> greghaynes posted to the ML about releasing a dib 1.0
19:12:51 <greghaynes> :)
19:12:51 <jdob> what was the verdict on-- ya, that
19:13:02 <slagle> fine by me
19:13:10 <jdob> do we want to bump everything up to 1.x following the RHOS release?
19:13:16 <jdob> it'll be on the tail end of a pretty big ass QE cycle from our end
19:13:25 <d0ugal> I'd like to request reviews for https://review.openstack.org/#/c/195592/
19:13:37 <d0ugal> bit I see I missed the segmet, sorry
19:13:41 <jdob> d0ugal: jeez, you're late showing up and you're late to the reviews section
19:13:42 <greghaynes> slagle: You made some good points, I want to dig in the code a bit to see where the get-kernel is being used and map-packages
19:13:44 * d0ugal waits until the end
19:13:51 <jdob> d0ugal: /me looks
19:14:05 <d0ugal> jdob: thanks
19:14:23 <slagle> jdob: possibly we could bump everything to 1.0.0. but we set ourselves up to maintain the interfaces at that point
19:14:29 <slagle> which i guess is probably the right thing to do
19:15:12 <jdob> not if we're looking to swap in the instack stuff
19:15:17 <jdob> or we call that 2.x
19:15:52 <slagle> that uses the same libraries/repos
19:16:02 <slagle> unless you're talking about something else?
19:16:07 <slagle> maybe i'm not following what you're saying
19:16:53 <jdob> i suppose it depends on what you mean by "interfaces"
19:17:06 <jdob> i was thinking that also included the devtest* scripts
19:17:15 <slagle> just whatever we consider to be the public api's of these repos
19:17:17 <jdob> evne if the underlying commands were the actual product
19:17:31 <slagle> ah, so we wouldn't release anything from tripleo-incubator which is where devtest lives
19:17:36 <jdob> gotcha
19:17:52 <jdob> and i'd say skip tuskar API for now too given that i'm trying to jam most of that into Heat anyway :)
19:18:00 <jdob> regardless, we can table this for now, its a few weeks away
19:18:08 <slagle> ok
19:18:08 <jdob> and we can take it to the ML and finish there
19:19:45 <slagle> #topic CI
19:20:28 <slagle> hmm, looks like all the precise jobs are failing
19:21:28 <slagle> oh, that's for the revert that derek was testing yesterday
19:21:57 <slagle> https://review.openstack.org/#/c/196659/
19:22:45 <slagle> #topic open discussion
19:23:36 <jdob> just a quick nudge to check out the thread crossposted with heat about tuskar's future
19:23:43 <slagle> d0ugal: i looked at that review, but i tend to agree with jdob
19:23:54 <jdob> especially those of you who have worked with the THT templates in the past few months
19:24:08 <jdob> and on top of that, especially the UI peoples
19:24:10 <slagle> i need to check out that heat spec
19:24:20 <slagle> from shardy
19:24:23 <jdob> its going to end up being a few closely related ones
19:24:37 <jdob> and IMO you'll need that big picture to make sure its going to fully answer what we need
19:24:57 <jdob> there will also likely be tuskar/tripleo specs spinning up as a result
19:25:21 <d0ugal> jdob: "What I don't understand is why it's not saved in the plan prior to deploying" not sure I follow this
19:25:23 <jdob> and some discussion on if we think we need a service to manage the storage of in progress overcloud configs or if thats just a user detail
19:25:31 <jdob> d0ugal: so tuskar workflow
19:25:33 <jdob> - create plan
19:25:35 <jdob> - add roles
19:25:36 <d0ugal> jdob: is that comment related to the patch or generally?
19:25:40 <jdob> - save config to tuskar
19:25:43 <jdob> - get templates from tuskar
19:25:47 <jdob> - send templates to heat
19:25:59 <jdob> IMO, none of the "save config" part should be done at image time
19:26:16 <jdob> that control plane should be saved in tuskar prior to the first deployment
19:26:27 <jdob> and should be there for the subsquent delete/updates
19:26:38 <d0ugal> jdob: So you want users to manually add all that?
19:27:15 <d0ugal> jdob: This is just a way of setting the defaults that instack has led everyone to expect
19:27:17 <jdob> we can provide a script to initialize the plan, which feels a bit better than hard coding it into install
19:27:44 <jdob> ya, but you even said it right there
19:27:51 <jdob> instack expects that, not necessarily TIE
19:27:58 <jdob> all that said, I'm not -1ing it
19:28:07 <d0ugal> jdob: well, users expect that because instack did it
19:28:11 <d0ugal> is what I mean
19:28:17 <d0ugal> instack doesn't know what we are doing
19:28:33 <jdob> its where things are now, so adding one more config value isn't going to crush us
19:28:39 <d0ugal> jdob: sure
19:28:53 <slagle> wait, instack doesn't expect anything
19:28:57 * bnemec wanders in halfway through the meeting
19:29:00 <slagle> it doesn't do anything with tuskar
19:29:03 <jdob> i think its just his phrasing
19:29:07 <jdob> he means it set expectations
19:29:09 <slagle> and has no expectations on it working
19:29:13 <jdob> with how instack-deploy-overcloud used to work
19:29:20 <d0ugal> slagle: I think jdob just miss-understood me
19:29:35 <slagle> ok, so...then that makes the argument that this should be in the cli then
19:29:38 <d0ugal> or I badly worded it :)
19:29:41 <slagle> b/c the cli replaces instack-deploy-overcloud
19:30:00 <d0ugal> slagle: We originally went to put it in openstack undercloud install. I think bnemec objected
19:30:01 <slagle> the cli should save the tuskar plan parameters the first time it deploys the cloud
19:30:21 <dprince> slagle: the update for https://bugs.launchpad.net/tripleo/+bug/1464239 is actually that someone needs to update Ironic to adopt Nova's change
19:30:21 <openstack> Launchpad bug 1464239 in tripleo "mount: special device /dev/sdb does not exist" [Critical,In progress] - Assigned to Dan Prince (dan-prince)
19:30:31 <bnemec> I objected to the fact that the code was going into the cli and not instack-undercloud, where the rest of the undercloud install code goes.
19:30:41 <bnemec> Which I tried to explain about 3 different times.
19:30:50 <d0ugal> slagle: The problem with doing it on the first CLI deploy is that the UI is missing the defaults the CLI has
19:31:17 <d0ugal> bnemec: ah, sorry - I wasn't fully following that.
19:31:22 <slagle> d0ugal: but the neutron network id might change, if someone were to recreate it, etc
19:31:33 <d0ugal> slagle: sure
19:31:39 <slagle> d0ugal: so just doing it once at install time doesn't seem right
19:31:51 <d0ugal> FWIW, I am not an advocate of doing it in t-i-e
19:31:58 <bnemec> It's just setting the default though, right?
19:32:09 <bnemec> You can always change it later if you recreate the neutron network.
19:32:09 <d0ugal> Yeah, it could be changed
19:32:18 <slagle> this feels different to me
19:32:22 <slagle> than setting a default
19:32:32 <slagle> whats' there now, sure those are defaults
19:32:42 <slagle> but asking neutron for the uuid of the ctlplane network? that's not a defult
19:33:09 <d0ugal> hmm, true
19:33:20 <d0ugal> Should we move all of this to instack-undercloud then?
19:33:37 <d0ugal> actually, ignore that
19:33:47 * d0ugal doesn't process well at this time
19:34:07 <d0ugal> Maybe the NeutronControlPlaneID should still be set in the CLI
19:34:08 <slagle> i actually think that this should be initial data for tuskar
19:34:16 <d0ugal> and then we need to make sure the UI does it too?
19:34:23 <slagle> why does some other installer have to configure tuskar with initial data so that it's actually usable?
19:34:29 <slagle> (the network id aside)
19:34:31 <d0ugal> +1
19:35:01 <slagle> as for setting the network id...i think the CLI should do it, and thus the UI needs to do it itself as well
19:35:07 <slagle> it's part of "deployment logic"
19:35:11 <d0ugal> I don't understand the templates enough, but why can't these defaults go there? or are they very specific to our workflow?
19:35:23 <slagle> "i need to tell heat what network i want to use for my deployment"
19:35:32 <slagle> that shouldn't happen at install time
19:35:45 * bnemec notes that this is why this code shouldn't live in the cli
19:36:02 <bnemec> It should have been a separate library that both the cli and ui call.
19:36:09 <d0ugal> bnemec: we know we know, it will be sorted
19:36:11 <d0ugal> :)
19:36:13 <bnemec> Then we could fix it there and everyone benefits.
19:36:16 <slagle> bnemec: them's fighting words!
19:36:21 <bnemec> d0ugal: Yeah, I know it's because of time constraints.
19:36:33 <bnemec> Which is why I haven't been pitching a fit about it up to now. :-)
19:36:36 <d0ugal> bnemec: Let me know when the patch is ready, I'll happily review ;)
19:36:58 <d0ugal> bnemec: it is the first thing I am going to do when I get the chance
19:37:17 <bnemec> d0ugal: It's on my list for when the "OMG drop everything and fix this blocker bug" phase ends.  If it ever does. ;-)
19:37:32 <d0ugal> Anyway, I'll comment on the review and speak with Lennart about moving that back to the deploy command
19:37:50 <d0ugal> bnemec: If it never ends, I probably will ;)
19:38:01 <d0ugal> or :(
19:38:04 <slagle> ok, i don't want to stall too long bickering on where the "right" place is
19:38:12 <bnemec> I think we're all in agreement though?
19:38:14 <slagle> but if it's an easy cli/ui fix, that's where i think it belongs
19:38:31 * bnemec apologizes for the tangent
19:38:31 <d0ugal> Yeah - leave them where they are, add this new one to the deploy command. Seems easy enough
19:38:33 <slagle> if that proves too difficult for now, we shall accept hacks as appropriate :)
19:38:41 <jdob> +1 to what d0ugal said
19:38:43 <d0ugal> slagle: Thanks
19:39:16 <slagle> alright, cool
19:39:22 <slagle> anything else before we end it?
19:39:54 * d0ugal has nothing
19:39:55 <slagle> thx folks!
19:39:57 <dprince> slagle: about the bugs you asked about.
19:40:11 * slagle ctrl-w's #endmeeting
19:40:28 <dprince> slagle: I think the ability to boot Ironic instances w/ ephemeral drives is still broken
19:40:29 * bnemec scratches a record
19:40:59 <dprince> slagle: that doesn't effect the package/puppet deployments... but it is concerning to me that Nova broke Ironic's interface in this regard
19:41:33 <slagle> shall we file an ironic bug as well?
19:41:42 <dprince> I sort of think baremetal got treated as a second class citizen in this regard
19:41:51 <dprince> slagle: yeah, that would probably help
19:42:10 <dprince> I did mention to them on IRC though (in #openstack-ironic)
19:43:17 <dprince> I was actually abit disappointed the revert wasn't accepted for this issue in Nova. The decision was like.... break the Ironic interface... or fix obscure Nova feature for VMs... VMs won
19:44:15 <dprince> Anyway. I could rant on about things but that is all for now.
19:44:28 <bnemec> We have not historically had good luck getting reverts in when they break us. :-/
19:44:41 <slagle> dprince: yea, agreed there
19:45:11 <slagle> i guess they stand by the "if it's not tested, it's not working (or broken)"
19:46:13 <slagle> dprince: thx for the update
19:46:36 <slagle> that's all folks!
19:46:39 <slagle> #endmeeting