20:03:19 <ianw> #startmeeting diskimage-builder
20:03:20 <openstack> Meeting started Thu Jul 21 20:03:19 2016 UTC and is due to finish in 60 minutes.  The chair is ianw. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:23 <openstack> The meeting name has been set to 'diskimage_builder'
20:03:42 <greghaynes> Maybe a good first agenda item is - what would we like to see in our agendas? :)
20:04:21 <anteaya> ianw: you can add the meeting chairs with #chair greghaynes cinerama
20:04:49 <ianw> #chair greghaynes cinerama
20:04:50 <openstack> Current chairs: cinerama greghaynes ianw
20:05:05 <ianw> so i guess word isn't quite out about the meeting yet, that's fine
20:05:33 <ianw> there was some confusion if it was weekly or bi-weekly, personally i think probably bi-weekly is fine
20:05:40 <greghaynes> bi-weekly works for me
20:05:51 <ianw> not sure we have *that* much to talk about :)
20:05:52 <greghaynes> although lets shoot for one next week
20:06:02 <ianw> sure
20:06:18 <ianw> #agreed do this for real next week
20:06:29 <greghaynes> #agreed meetings are bi-weekly
20:06:43 <greghaynes> wow voting is efficient with two people
20:07:16 <greghaynes> It looks like the meeting wiki page isn't created yet
20:07:39 <ianw> i guess the agenda is mostly just pushing on those reviews that are hard to merge
20:08:24 <greghaynes> Yea, I'd like to have some time for folks to call out things that may need attention in reviews - whether it is 'please let me move forward on this patch', or theres some disagreement we need some talk about
20:09:23 <greghaynes> because ive seen a few sides of it - proposers feeling like they cant get any traction and us going back and forward on what we think about a design
20:09:50 <ianw> i was wondering if maybe we should cut a 2.0 branch for a few things out there that are big changes
20:10:11 <ianw> but, in a way, that feels a bit like admitting defeat that we can't merge stuff
20:10:29 <greghaynes> #agreed one agenda item should allow us to talk about things that may be currently going on in our review queue
20:10:35 <ianw> we merge with less care into the branch probably, but it just comes back to bite you later
20:10:55 <greghaynes> I kind of want us to tag a handful of things we want out of a 2.0
20:11:01 <greghaynes> and then knock it out at once
20:11:17 <greghaynes> which I think is what youre proposing
20:11:50 <greghaynes> branching now seems a bit scary though - I think we really want to minimize the time where you can have the two sets of code drift
20:12:46 <ianw> for mine that list would be:
20:12:47 <ianw> -
20:12:56 <ianw> ... umm, hang on, getting reviews :)
20:13:05 <greghaynes> So, the biggest thing I want to avoid with a 2.0 is cutting it and then very quickly afterwards wanting to do a 3.0
20:13:33 <greghaynes> so I think its worth taking a bit of time upfront to get some confidence in the exact featureset we want our of a 2.0, then trying to stick with it
20:14:08 <greghaynes> and yea, just getting a list of features is the thing to do
20:14:13 <ianw> - https://review.openstack.org/319591 - local loop image build rewrite by andreas.  i feel like that's probably ready to go, i think we can interate on that
20:14:21 <greghaynes> I'd need a bit to remember what all I want
20:14:41 <greghaynes> hrm, is that going to break backwards compat?
20:14:47 <greghaynes> I thought it didnt need to
20:15:51 <ianw> - https://review.openstack.org/#/c/335308/ - my stack below this that clears up what happens with duplicate images
20:16:30 <ianw> - the specs dir stuff
20:16:37 <ianw> (can probably just do that now)
20:16:49 <greghaynes> Maybe the thing to do here is to make a spec or some kind of document outlining what all reviews / backwards compat changes were hoping to have happen in a 2.0?
20:17:35 <greghaynes> I have a really hard time remembering all of these...
20:17:59 <ianw> what was the compat issue with 319591 ?
20:19:23 <greghaynes> its pretty exclusive to our current user-pluggable block-device.d phase AIUI
20:19:27 <ianw> - https://review.openstack.org/#/c/344532/ - my latest stack about moving disk-image-builder into an entry point, which is really about making dib a "real" (or realer) python package
20:20:00 <greghaynes> I don't think that had any compat issues?
20:20:23 <greghaynes> there was the minor rename deal but I thought you fixed it
20:21:17 <greghaynes> Yea, so I definitely need some time to re-read a bunch of these reviews with a 2.0 in mind
20:21:19 <ianw> there is a big rename in 344017 moving top-level elements to diskimage_builder/elements , i feel like it's motivated pretty well in the change description
20:21:33 <greghaynes> are you up for doing a spec that just lists them off then we have a place to comment?
20:21:40 <greghaynes> and potentially add other features and whatnot
20:21:58 <ianw> sure, how about an etherpad and we can just sync on that
20:22:03 <greghaynes> that works
20:22:28 <ianw> #action ianw to do 2.0 etherpad page
20:23:05 <ianw> i've been meaning to catch lifeless and double check about data_files and their behaviour under "pip -e"
20:23:48 <greghaynes> I think it just symlinks?
20:23:52 <greghaynes> or something like that
20:24:18 <greghaynes> One other meeting question I have is how to do the whole 'office hours' thing
20:25:06 <greghaynes> itd be nice to ask folks to add an item to the agenda, but theres a sort of chicken and the egg where that probably wouldnt happen without being explicitly asked to at a meeting
20:25:19 <ianw> re: data_files ... it doesn't symlink.  so basically you don't know where data_files is.  whereas you *do* know where diskimage_builder/* is (i.e. __file__ , but there's a pkg_resources interface too)
20:25:37 <ianw> as in when people are awake?
20:26:21 <greghaynes> Im thinking that as a dib user how would you know that we'd like you do add an agenda item about a potential issue
20:26:50 <greghaynes> so I kind of think just having a weekly open discussion at the end of our meeting would be good and say that is a good time for users to show up and get help / some info
20:27:19 <greghaynes> re: data_files - sounds like you might just need to do the trick where you have an entrypoint that prints out __file__ or somesuch
20:27:26 <ianw> oh ... right, yeah that's fine.
20:27:57 <greghaynes> #agreed lets have an open discussion at meeting end which is also for users to get info / help
20:29:18 <greghaynes> to totally change topic - I have a pretty odd idea I've been playing around with and i'm not sure if it should live in dib
20:29:19 <ianw> yeah, that's the idea of 344017.  move the elements to diskimage_builder/elements , and then the elements are always relative to __file__.  i've added diskimage_builder.paths with a little helper to do what you say -- print out the element path for disk-image-create to use
20:30:22 <greghaynes> one issue a lot of projects have is theres not a good way to add 'dib entrypoints'. So say I am octavia, I have a set of elements and potentially more than one kind of image you can build. as a user I dont want to have to know I need to run CONFIG=foo disk-image-create <repo>/element1 <repo>/element2 ...
20:30:43 <greghaynes> I really want to run disk-image-create octavia-repo some_image_name and let octavia supply some sane defaults
20:30:48 <greghaynes> and same for other projects
20:31:20 <greghaynes> so ive been playing with making a diskimages.yaml file that dib can read and can live in these repos and point to relative element paths
20:32:39 <greghaynes> kind of trying to figure out if thats a thing dib should do or whether that should be a dib runner
20:32:47 <greghaynes> since the config is basically nodepool's diskimages: section
20:32:49 <ianw> i think that probably sounds ok, basically a config file rather than command line args
20:32:53 <greghaynes> yea
20:33:22 <ianw> this is really what i think 344532 is good for
20:33:47 <ianw> by making disk-image-create be a python function that calls the shell script in the background, you could do that runner idea right there
20:34:30 <greghaynes> yep. So when playing with this I have a thing that builds images and tracks them asynchronously
20:34:34 <greghaynes> in a simlar fashion
20:34:47 * cinerama is here
20:34:52 <greghaynes> so yea, maybe ill copy some of that code in to a dib review
20:35:04 <greghaynes> cinerama: ohai
20:35:09 <ianw> o/
20:35:21 <cinerama> ianw: is this time at least sort-of tolerable?
20:35:24 <ianw> what do you mean tracks them asynchronously?
20:35:50 <greghaynes> ianw: basically it lets you run an image build then returns, and lets you ask for status on currently running builds
20:35:55 <ianw> cinerama: yeah, it's 6am in sydney, which is fine
20:35:57 <greghaynes> it was just me messing around mostly
20:36:16 <greghaynes> but it ends up being nice for a 'what images do I have, what are their statuses'
20:36:18 <ianw> ahh.  yeah i guess that sounds like nodepool-builder :)
20:36:20 <greghaynes> yep
20:36:42 <cinerama> (backscrolling) i want to get block device patch series + the svc-map stuff in for a new major release
20:37:21 <greghaynes> seems like a lot of projects have a use case for something very similar - a lot of folks need to make some images in CI / during deploy then upload them to a cloud. Doing that by having a long shell command is not as nice as having a config file supplied by the project where you just override some defaults
20:38:15 <ianw> cinerama: ok, today i'll create an etherpad and we can group specific reviews to focus on
20:38:17 <greghaynes> cinerama: Ya, It seems like were about due for a major release
20:39:17 <greghaynes> oh, I remember now, I want to change root.d semantics
20:39:21 <greghaynes> as part of a major bump
20:39:54 <greghaynes> I can write up in more detail, but basically I was playing with making image builds cache better and the sane thing IMO is to make it so root.d can be cached as a whole
20:40:15 <greghaynes> but thats sort of a big interface change so itd need a major bump
20:41:13 <greghaynes> https://review.openstack.org/#/c/339730/3 shows why, basically
20:41:45 <greghaynes> theres no sane way to add extra stuff in to the root.d cache other than to cram all sorts of logic in to the single script that untar's the rootfs unless dib gets smarts about caching the whole phase
20:42:42 <ianw> hmm, fair enough.  the yum-minimal root.d caching is pretty bad too
20:42:56 <ianw> another thing on my list to look at
20:43:25 <greghaynes> Yea, I have some thoughts on how we can actually be pretty smart about caching if we do this - it should work across elements and all
20:43:33 * greghaynes will await etherpad
20:43:34 <ianw> so if you can cover both, and i can get rid of the tar create stuff in there, all the better
20:44:33 <ianw> the other thing i'd like to do is get the nodepool-dsvm test running.  it doesn't build much but it will give us some confidence that we won't have too many issues there
20:44:49 <greghaynes> to get a boot test?
20:44:55 <ianw> yep
20:45:07 <greghaynes> so, I have https://review.openstack.org/#/c/204639/ I need to revive
20:45:18 <greghaynes> but first I wanted to get https://review.openstack.org/#/c/181162/ in
20:46:30 <ianw> ok, the minimal test should be cool, will review
20:46:53 <greghaynes> :)
20:47:16 <greghaynes> ok, I don't really have anything else to mention, we should try and work up an agenda for next week though based on notes + other chat
20:47:21 <cinerama> i had one other thing
20:47:50 * greghaynes awaits
20:47:55 <cinerama> wrt communication - should we standardize on (say) hanging out in #tripleo for questions, user comments, etc?
20:48:13 <cinerama> i feel like people would like to be able to find us
20:48:14 <greghaynes> we should standardize on somewhere...
20:48:23 <greghaynes> so I guess I could mention this
20:48:28 <cinerama> we could make our own but tbh it might be dead a lot of the time
20:48:41 <greghaynes> I was planning to send an email today or tomorrow about proposing us moving out of tripleo
20:48:53 <ianw> i am in #tripleo, but i'm more closely watching #openstack-infra
20:48:54 <cinerama> in which case, having our own makes more sense
20:49:07 <cinerama> i watch infra & tripleo but mostly by highlighting
20:49:08 <greghaynes> but I think that discussion will have some effect on where we hang out
20:49:28 <greghaynes> It is really not great that we dont have a clear channel we live in though
20:50:05 <greghaynes> I'd be fine making our own channel...
20:50:21 <greghaynes> ianw: you fine with another channel?
20:51:02 <ianw> i guess so, do we think #openstack-infra is too busy?
20:51:26 <cinerama> it's not terrible but it's also not super obvious to someone whose main point of context is just using dib
20:52:03 <greghaynes> Agreed, I think it'd work but its probably more beneficial to have something we can try and make painfully obvious to random users where we live
20:53:08 <cinerama> yep we can add that to our homepage, readme, etc
20:53:12 <ianw> ok, np
20:53:25 <greghaynes> #openstack-dib?
20:53:29 <cinerama> ++
20:53:41 <ianw> +1
20:54:12 <greghaynes> #agreed We will make #opensack-dib our official channel
20:54:21 <greghaynes> ok, lots of decisions for a meeting
20:54:30 <greghaynes> we have about 5mins...
20:55:09 <greghaynes> anything else or we all get 5mins back?
20:55:43 <cinerama> greghaynes, who's going to take the setup for the new channel?
20:56:05 <cinerama> i can do it but i have ironical things to do this week so i might need to be poked
20:56:45 <greghaynes> I think its fine if we wait a bit, I'd kind of like to send the tripleo email first since I think part of the setup relates to what program the project is under
20:56:46 <ianw> i vote cinerama :)  no rush
20:56:58 <cinerama> sounds good
20:57:03 <greghaynes> awesome
20:57:20 <greghaynes> cinerama: TY for getting us set up with a meeting!
20:57:37 <greghaynes> #endmeeting