On 01/13/2018 05:01 AM, Jeremy Stanley wrote: > On 2018-01-12 17:54:20 +0100 (+0100), Marcin Juszkiewicz wrote: > [...] >> UEFI expects GPT and DIB is completely not prepared for it. I made >> block-layout-arm64.yaml file and got it used just to see "sorry, >> mbr expected" message. > > I concur. It looks like the DIB team would welcome work toward GPT > support based on the label entry at > https://docs.openstack.org/diskimage-builder/latest/user_guide/building_an_image.html#module-partitioning > and I find https://bugzilla.redhat.com/show_bug.cgi?id=1488557 > suggesting there's probably also interest within Red Hat for it as > well.
Yes, it would be welcome. So far it's been a bit of a "nice to have" which has kept it low priority, but a concrete user could help our focus here. >> You have whole Python class to create MBR bit by bit when few >> calls to 'sfdisk/gdisk' shell commands do the same. > > Well, the comments at > http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/block_device/level1/mbr.py?id=5d5fa06#n28 > make some attempt at explaining why it doesn't just do that instead > (at least as of ~7 months ago?). I agree with the broad argument of this sentiment; that writing a binary-level GPT implementation is out of scope for dib (and the existing MBR one is, with hindsight, something I would have pushed back on more). dib-block-device being in python is a double edged sword -- on the one hand it's harder to drop in a few lines like in shell, but on the other hand it has proper data structures, unit testing, logging and config-reading abilities -- things that all are rather ugly, or get lost with shell. The code is not perfect, but doing more things like [1,2] to enhance and better use libraries will help everyone (and notice that's making it easier to translate directly to parted, no coincidence :) The GPL linkage issue, as described in the code, prevents us doing the obvious thing and calling directly via python. But I believe will we be OK just making system() calls to parted to configure GPT; especially given the clearly modular nature of it all. In terms of implementation, since you've already looked, I think essentially diskimage_builder/block_device/level1.py create() will need some moderate re-factoring to call a gpt implementation in response to a gpt label, which could translate self.partitions into a format for calling parted via our existing exec_sudo. This is highly amenable to a test-driven development scenario as we have some pretty good existing unit tests for various parts of the partitioning to template from (for example, tests/test_lvm.py). So bringing up a sample config and test, then working backwards from what calls we expect to see is probably a great way to start. Even if you just want to provide some (pseudo)shell examples based on your experience and any thoughts on the yaml config files it would be helpful. -- I try to run the meetings described in [3] if there is anything on the agenda. The cadence is probably not appropriate for this, we can do much better via mail here, or #openstack-dib in IRC. I hope we can collaborate in a positive way; as I mentioned I think as a first step we'd be best working backwards from what we expect to see in terms of configuration, partition layout and parted calls. Thanks, -i [1] https://review.openstack.org/#/c/503574/ [2] https://review.openstack.org/#/c/503572/ [3] https://wiki.openstack.org/wiki/Meetings/diskimage-builder _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
