20:01:00 #startmeeting diskimage-builder 20:01:01 Meeting started Thu Jun 1 20:01:00 2017 UTC and is due to finish in 60 minutes. The chair is ianw. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:04 The meeting name has been set to 'diskimage_builder' 20:01:21 hello 20:01:32 Hello Ian! 20:01:58 #link https://wiki.openstack.org/wiki/Meetings/diskimage-builder 20:02:30 #topic Annoucements 20:03:30 ahh, nothing 20:03:47 #topic Actions from last meeting 20:03:59 I think we can skip this 20:04:20 Yep - Its quite a while... 20:04:58 #topic Testing 20:05:08 sorry, forgot to add this to the agenda 20:05:15 np 20:05:24 bit of movement on suse out there as it goes towards the gate 20:05:55 i think moving the nodepool jobs to voting is a good idea 20:06:09 So we'll get a voting suse? 20:06:17 #link https://review.openstack.org/#/c/469538/ nodepool jobs to voting 20:06:18 patch 469538 - openstack-infra/project-config - diskimage-builder/glean: Upgrade nodepool-src-* jo... 20:07:09 a voting job that boots it, at least. seeing as we broke it, also not the first time we've ignored the nodepool failures 20:07:54 Yes good point. 20:08:02 +1 20:08:06 it does mean we're co-gating a bit on glean, to bring the vm up in devstack, but i think that's ok for the benefit of knowing it boots 20:09:30 #agreed dib devstack/nodepool jobs to voting 20:09:47 any more immediate testing issues? 20:10:04 i've just woken up, but i'm presuming setuptools has unbroken itself 20:10:27 I don't know of any testing issues. 20:10:58 #topic Review review 20:11:21 I don't think there's anything out there particularly stuck at the moment? 20:11:35 except the UEFI ;-) 20:11:56 oh 20:11:58 #link https://review.openstack.org/#/c/468186/ 20:11:59 patch 468186 - diskimage-builder - Drop support for Ubuntu precise 20:12:31 I'm actually thinking we can think about dropping trusty 20:12:59 trusty might be in use. 20:13:06 I think it is not EOL. 20:13:30 EOL: April 2019 20:14:07 sorry, i meant as a build platform, really part of the previous topic, if nobody is using it in the wild. it would only be 3rd party ci i think now, as infra has moved builders to xenial 20:14:07 But on the other side, we also dropped support for RHEL 6 / Centos 6... 20:14:32 Ah, ok. 20:14:48 Does this mean some simplification / unification? 20:15:53 trusty? i don't know, maybe. but anyway, unless there's objections i'm ok with precise removal 20:16:42 Yes - let's remove precise now. 20:16:54 #agreed merge 468186 20:17:09 It looks that there are some dependencies for trusty: hpdsa element (never saw before). 20:18:48 my only thought really was that we could remove the -trusty- jobs from the gate, and leave python2.7 testing up to centos 20:19:39 we can probably wait until there is a problem, or infra starts to wind-down trusty node support 20:19:55 any more pressing review requests? 20:20:13 Ok - maybe I think I'm missing something: how are these (somewhat) special elements (like hpdas element) tested? 20:20:32 For me it looks that this works only under trusty. 20:20:46 So it we drop trusty, we should remove this element. 20:20:57 they are probably not, and have probably bit-rotted 20:21:09 see that dracut kernel one doing the patching 20:22:17 So maybe a more general question: what do to with those elements? 20:22:42 i think, these days, we would probably suggest any new like that don't belong in dib core but as elements as part of your project 20:23:01 officially dropping support for precise is probably wise anyway since we'll (soon) cease to have servers we can test that on 20:23:19 as we find stuff broken and unused, remove it 20:23:41 It's hard to say if it is unused. 20:23:48 Maybe some project uses it? 20:25:19 we just have to use our best judgement, do some code searches/archaeology and respond if it turns out we did the wrong thing 20:25:29 if it's a project in the openstack ecosystem, you can look on http://codesearch.openstack.org/ 20:26:04 though i think we don't index stable branches, recent stable branches should be using constraints anyway 20:26:42 Ack. 20:26:44 Currenly we have 99 elements - should check how many of them are tested or used. 20:27:02 (long term thingy...) 20:29:16 i'm happy to consider things on a case-by-case basis, like when it comes time to remove trusty looking at elements that only work there 20:30:24 i don't feel like going through everything is the best use of time; a broken but unused element doesn't really affect the core mission of getting a usable .qcow out 20:30:36 it just ... is 20:31:02 anyway, moving on 20:31:22 I guess everything else falls under 20:31:29 #topic Open Discussion 20:31:56 Yes. 20:32:03 andreas-f: what is your priority there? 20:32:19 UEFI boot: because it's open since 14 month. 20:33:00 and it is an element which is IMHO a step forward. 20:33:12 ok, do we have a consumer that needs it? 20:33:38 #link https://review.openstack.org/#/c/287784/ 20:33:39 patch 287784 - diskimage-builder - Add support for building images capable of UEFI 20:34:04 I personally don't know of one. 20:34:23 I know that HP uses it in one of the products. 20:34:38 And I don't know if Yonalda needs this for her security. 20:34:54 HP ... HP ... that's a company that used to exist, right? 20:35:37 so 287784 is not based on dib-block-device at all? 20:35:53 Yes, that the major problem. 20:36:02 And there are another two: 20:36:07 1) Missing GPT support 20:36:22 2) old bootloader element 20:37:04 so 1) ... writing our own mbr stuff is already super complex 20:37:17 do we need to actually implement gpt writing? 20:37:35 i did not understand why we did not just write out a parted/sfdisk script and get that to do all that 20:37:37 I know: do you know a usable library here? 20:38:12 os.system(parted) 20:38:16 not sure it's a library :) 20:38:36 parted *is* a library; but GPL. 20:39:15 Here are some more arguments: 20:39:17 https://github.com/openstack/diskimage-builder/blob/master/diskimage_builder/block_device/level1/mbr.py#L27 20:39:20 right, i kind of got that looking back in the history why we didn't link against it, but we can call it? 20:39:57 Yes; I used it in the first versions of block_device. 20:40:07 It does not do what you want... 20:40:18 ... but what it thinks you want ;-( 20:41:45 These tools want to 'optimize' things; and I did not find a way to switch this off. 20:42:28 ok, well i just think finding someone to write low-level, like byte-level GPT partitioning code is tough, and then to also have two people give it decent review, and maintain it is ... unlikely 20:44:25 how does guestfish do it's partitioning in the back end? 20:44:28 could we just use that? 20:46:10 I'm just looking.... 20:47:21 too big... will do this offline. 20:47:29 daemon/parted.c seems to be it 20:48:03 it's also GPL. 20:48:04 it is essentially system() calling out to parted, AFAICS 20:48:48 well, not copy it, but it suggests to me that probably getting an external tool to do it is going to be a better way forward than writing it from scratch 20:48:49 Yes - system() 20:50:08 Did not check parted for GPT until now. Maybe we could use it at least for GPT. 20:50:12 seems to have bits for parted/sfdisk/sgdisk all together 20:50:27 maybe it requires some combo 20:51:04 I checked all of them for MBR - all of them using some /sys-fs access to get some buffer infos. 20:51:16 ... which they will use for 'optimizations'. 20:52:35 So calling 'parted' might be a solution. 20:53:10 2) bootloader element refactoring is needed 20:53:51 IMHO we should split the bootloader into a grub and extlinux. 20:54:18 is this another case of who's using extlinux? 20:54:50 Yes ;-) 20:54:53 Then there is the need to get all the needed info from the block device layer and push it into the bootloader element. 20:55:41 Hmmmm.... 20:55:44 So thinking about this: 20:55:46 A lot of work - and maybe nobody really needs / uses it. 20:56:05 right, that was my next point, i presume you're wanting to drive all this? 20:56:11 Maybe we should ask Yolanda if this is needed for some kind of 'secure boot'? 20:56:28 yes, let's sync with her on this, and it's priority to LVM 20:56:45 Ack. 20:57:07 i think starting at the bottom would work best. there is quite a bit of unit testing templating going on in dib-block-device now 20:57:39 Yes - saw the patches (which currently all fail...) 20:57:40 i think any gpt implementation in there can be put in and relatively well tested 20:58:06 the current failures were setuptools related, that should be fixed now 20:58:28 then we can start building the elements ontop of it 20:58:34 Ok - will check tomorrow. 20:58:52 so, to summarise on this 20:59:02 1. sync with yolanda on relative importance 20:59:32 2. thoroughly investigate external tools for writing partitions, with reference to things like guestfish 20:59:46 Ack. 21:00:09 3. start at implementation within dib-block-device at least covered by unit testing 21:00:27 alright, well that feels like some progress 21:00:47 we've hit 1 hour 21:00:54 Yes saw this. 21:01:25 Ok - then: have a nice day. 21:01:28 Talk / mail / review in some hours. 21:01:50 (Here it is 23:00 and I need some sleep now....) 21:02:19 ok, thanks. 7am and i need some breakfast :) ttyl 21:02:31 #endmeeting