Re: [openstack-dev] [dib] diskimage-builder v2 RC1 release; request for test
Hello! Thanks for the bug report. Can you please file this as a bug? There is a very high probability that I introduced a change that leads to the failure [1] - even if this is fixed now there is a high probability that it will fail again when [2] is merged. The reason is, that there are no test cases because there is no nodepool CI job running on PPC. (Or do I miss something here?) We are only a very few people at diskimage-builder with limited resources and had to concentrate on the 'main-line' (i.e.: that what can be tested by us). A discussion about what to support or test was already started some time ago [3]. Looks that you are from IBM: would it be possible to provide PPC hardware for testing and the man-power to integrate this into the CI? This would really help finding such problems during development phase and would put me into the situation to be able to fix your problem. Kind regards Andre [1] https://review.openstack.org/#/c/375261/ [2] https://review.openstack.org/#/c/444586/ [3] https://review.openstack.org/#/c/418204/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder
Hello! Thanks Greg for sharing your thoughts. The idea of splitting off DIB from OpenStack is new for me, therefore I collect some pros and cons: Stay in OpenStack: + Use available OpenStack infrastructure and methods + OpenStack should include a possibility to create images for ironic, VMs and docker. (Yes - there are others, but DIB is the best! :-) ) + Customers use DIB because it's part of OpenStack and for OpenStack (see e.g. [1]) + Popularity of OpenStack attracts more developers than a separate project (IMHO running DIB as a separate project even lowers the low number of contributors). + 'Short Distances' if there are special needs for OpenStack. + Some OpenStack projects use DIB - and also use internal 'knowledge' (like build-, run- or test-dependencies) - it would be not that easy to completely separate this in short term. As a separate project: - Possibly less organizational overhead. - Independent releases possible. - Develop / include / concentrate also for / on other non-OpenStack based virtualization platforms (EC2, Google Cloud, ...) - Extend the use cases to something like 'DIB can install a wide range of Linux distributions on everything you want'. Example: DIB Element to install Raspberry Pi [2] (which is currently not the core use-case but shows how flexible DIB is). In my opinion the '+' arguments are more important, therefore DIB should stay within OpenStack as a sub-project. I don't really care about the master: TripleO, Infra, glance, ... I want to touch an important point: Greg you are right that there are only a very few developers contributing for DIB. One reason is IMHO, that it is not very attractive to work on DIB; some examples: o The documentation how to set up a DIB development environment [3] is out of date. o Testing DIB is nightmare: a developer has no chance to test as it is done in the CI (which is currently setup by other OpenStack projects?). Round-trip times of ~2h - and then it often fails, because of some mirror problem... o It takes sometimes very long until a patch is reviewed and merged (e.g. still open since 1y1d [6]; basic refactoring [7] was filed about 9 month ago and still not in the master). o There are currently about 100 elements in DIB. Some of them are highly hardware dependent; some are known not to work; a lot of them need refactoring. It is important to work on these topics to make DIB more attractive and possible have more contributors. Discussions about automated development environment setup [4] or better developer tests [5] started but need more attention and discussions (and maybe a different setting than a patch / review). In addition we should concentrate on the core functionalities: block device setup, minimal system installation, bootloader, kernel and ramdisk creation and a stable extensible element interface; drop non-core elements or move them to the projects where they are used. Kind regards Andre [1] https://imagefactory.otc.t-systems.com/ [2] https://github.com/florath/dib-element-raspberrypi3 [3] https://docs.openstack.org/developer/diskimage-builder/developer/index.html [4] https://review.openstack.org/#/c/419655/ [5] https://review.openstack.org/#/c/414347/ [6] https://review.openstack.org/#/c/287784/ [7] https://review.openstack.org/#/c/319591/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [dib] diskimage-builder v2 RC1 release; request for test
Hello Ian, I think I found a regression: since [1] only the first package specified using '-p' is picked up. You can find a proposal for a fix under [2]. Maybe it's worth to include this in V2? Kind regards Andre [1] https://review.openstack.org/#/c/396702 [2] https://review.openstack.org/#/c/438010 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!
Hello! > The end result of this would be we have distro-minimal which depends on > kernel, minimal-userspace, and yum/debootstrap to build a vm/baremetal > capable image. We could also create a distro-container element which > only depends on minimal-userspace and yum/debootstrap and creates a > minimal container. The point being - the top level -container or > -minimal elements are basically convenience elements for exporting a few > vars and pulling in the proper elements at this point and the > elements/code are broken down by the functionality they provide rather > than use case. This sounds awesome! Do we have some outline (etherpad) around where we collect all those ideas? Kind regards Andre __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] diskimage-builder Package grub-pc is not available error running on Fedora 25 AArch64
Hello! Looks that you are testing a somewhat uncommon combination ;-) The error points into the direction that Ubuntu Xenial for arm does not supply a 'grub-pc' package [1]. Would be good if you could file a ticket. Kind regards Andre [1] http://packages.ubuntu.com/search?suite=xenial=arm64=names=grub-pc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!
Hello Paul, thank you very much for your contribution - it is very appreciated. You addressed a topic with your patch set that was IMHO not in a wide focus: generating images for containers. The ideas in the patches are good and should be implemented. Nevertheless I'm missing the concept behind your patches. What I saw are a couple of (independent?) patches - and it looks that there is one 'big goal' - but I did not really get it. My proposal is (as it is done for other bigger changes or introducing new concepts) that you write a spec for this first [1]. That would help other people (see e.g. Matthew) to use the same blueprint also for other distributions. One possibility would be to classify different element sets and define the dependency between them. E.g. to have a element class 'container' which can be referenced by other classes, but is not able to reference these (e.g. VM or hardware specific things). There are additional two major points: * IMHO you addressed only some elements that needs adaptions to be able to used in containers. One element I stumbled over yesterday is the base element: it is always included until you explicitly exclude it. This base element depends on a complete init-system - which is for a container unneeded overhead. [2] * Your patches add a lot complexity and code duplication. This is not the way it should be (see [3], p 110, p 345). One reason is, that you do everything twice: once for Debian and once for Ubuntu - and both in a (slightly) different way. Please: factor out common code. Please: improve code as you touch it. And three minor: * Release notes are missing (reno is your friend) * Please do not introduce code which 'later on' can / should / will be cleaned up. Do it correct right from the beginning. [4] * It looks that this is a bigger patch set - so maybe we should include it in v2? Kind regards Andre [1] https://review.openstack.org/#/c/414728/ [2] https://review.openstack.org/#/c/417310/ [3] "Refactoring - Improving the Design of Existing Code", Martin Fowler, Addison Wesley, Boston, 2011 [4] https://review.openstack.org/#/c/414728/8/elements/debootstrap-minimal/root.d/99-clean-up-cache [5] https://review.openstack.org/#/c/413221/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [DIB] [TripleO] Should we have a DIB meeting?
Hi! Very good proposal. Like to join. Hopefully we find a time slot - I have no idea where in the world (and in which timezone) you are all living. I personally would go for a separate meeting and not be part of the TripleO meeting - at least for the first some times. Kind regards Andre __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install
Hello Jay, Yes - the partition alignment is a problem: grub2 needs at least 63 blocks between the MBR and the first partition. Here for you the partition directly starts at block 1, therefore grub has no way to put its data on the disk. The root cause is, that all the partitioning tools I found (like parted or sfdisk) make some 'optimization': they do not what you state but what they think you want. (And I have the impression that their 'thinking' includes the moon phases and the biorhythm of the user :-) .) Example in your case: sfdisk called with '1 - - *' creates on Ubuntu Xenial a partition starting from block 1. On Debian 8.4 (my development machine) it creates a partition starting from 2087. This gives some room for grub, but it horrible when it comes to alignment. Some possible workarounds: o Use another host for creating the Ubuntu VM (and hope, that sfdisk behaves 'better'.) o Use a more recent version of diskimage-builder: some time ago 'sfdisk' was replaced by 'parted' (and hope, that 'parted' does a 'better' job for you). o Under Ubuntu Xenial execute with 1.0.0 installed: $ sudo vi /usr/share/diskimage-builder/elements/vm/block-device.d/10-partition In line 23 replace 1 - - * with 2048 - - * (Note that this really only works on Ubuntu Xenial.) Hope this works and helps - was not able to test these things. If you are interested in some more background information: I stumbled over the mostly random behavior of these tools last week. One aspect is, that they optimize things for the current system (e.g. reading some kernel parameters; especially IO buffer sizes). These sizes can be completely different on the target system - which might lead to very poor disk performance. During the last days I reworked my patch (which originally used parted) to directly write the needed info to the boot records. [1] More details can be found in the comments of MBR.py [2]. Kind regards Andre [1] https://review.openstack.org/#/c/322671/ [2] https://review.openstack.org/#/c/322671/7/diskimage_builder/block_device/level1/MBR.py __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [diskimage-builder] ERROR: embedding is not possible, but this is required for cross-disk install
Hi! Before things getting said twice (looks that there is some public interest here ;-) ): Can you please rerun and skip the partition part of the loop device for fdisk -l? E.g. instead of /dev/loop0p1 just /dev/loop0? (This was my original intend but maybe not correctly described.) Also can you please send the parameters passed to parted? (When running with trace enabled this should be written to the logs. Please run something like export DIB_DEBUG_TRACE="255" disk-image-create -o /tmp/ubuntu.qcow2 --image-size=10 ubuntu vm | tee o.log and send the output of grep parted o.log ) === To be on the same page, here are the other infos Jay send: > o Can you please provide the DIB version? ii python-dib-utils 0.0.6-1 ii python-diskimage-builder 1.0.0-1 > o Are you using UEFI on the host system? >(For me your command works and this question is about > a possible difference: '--target=i386-pc' appears > not in my logs) Yes, it's a UEFI-enabled host: jaypipes@brix-1:~$ sudo efibootmgr BootCurrent: Timeout: 1 seconds BootOrder: ,0002,0001 Boot* ubuntu Boot0001* Hard Drive Boot0002* ubuntu === Kind regards Andre __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [DIB] Adding GPT support
Hello Tony, it's already implemented twice :-) [1] is mostly exactly what your propose (except of the removal of sfdisk). The problems with this kind of patches: * If you want to do it somewhat general (i.e. allow more than one disk partition) the changes are getting (too) big. * It is not possible to add things like LVM, MD or encryption - because of some basic problems handling parameters with dib-run-parts. [2] is the more general approach: it is completely independent of the used tool, but describes the partition table as a JSON structure. An example can be found in [3]: to use GPT you just need to change 'msdos' to 'gpt' in line 26 (already tested this). A proposal how to handle block device setup can be found in [4]. Because also [2] is a somewhat big change, we currently try to split off some general usable things first, like python logging [5], move hook generation to python [6], or introduce exit phase [7]. As soon as these patches get merged, the original patch needs to be rebased (and reworked). Maybe there is the need to extract additional things, so that in the end, it's small and does exactly one thing. Would be great if you'd support this refactoring / migration phase: it's some work. Kind regards Andre [1] https://review.openstack.org/#/c/313938/ [2] https://review.openstack.org/#/c/322671/ [3] https://review.openstack.org/#/c/322671/6/elements/block-device/environment.d/07-block-device-config [4] https://etherpad.openstack.org/p/C80jjsAs4x [5] https://review.openstack.org/325409 [6] https://review.openstack.org/271139 [7] https://review.openstack.org/324811 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [diskimage-builder] Howto refactor?
Hi! > ++, but one clarification: We do have a spec process which is to use the > tripleo-specs repo. Since this is obviously not super clear and there is > a SnR issue for folks who are only dib core maybe we should move specs > in to the dib repo? Good to know! I'd really love to use the dib repo for this: IMHO the spec, requirements, design and source code should go together. > Splitting these out would help a lot. This whole set of features is > going to take a while to iterate on (sorry! - reviewer capacity is > limited and there are big changes here) and a few of these are pretty > straightforward things I think we really want (such as the cleanup > phase). There's also a lot of risk to us in merging large changes since > we are the poster child for how having external dependencies makes > testing hard. Making smaller changes lets us release / debug / > potentially revert them individually which is a huge win. Of course I tried smaller parts; but for some changes the source code other parts must be changed which again needs changes. Is like sticky spaghetti: you start with a single noodle polling out but when you finished you have the whole pot. Will have a detailed look again. > As for what to do about the existing and potentially conflicting changes > - that's harder to answer. I think there's a very valid concern from > the original authors about scope creep of their original goal. We also, > obviously, don't want to land something that will make it more difficult > for us to enhance later on. A general remark here: I do not want to block features. I just try to give my opinion - which might be wrong. If you think, the patches are fine: let them go. > I think with the LVM patch there actually isn't much of risk to making > your work more difficult - the proposed change is pretty small and has a > small input surface area - it should be easy to preserve its behavior > while also supporting a more general solution. If you are really talking about 'preserving the behavior' and not 'preserving the user experience' (like how to use and configure LVM) I'm on your side. I'm somewhat careful with this patch: For me the use case (the WHY behind) is still completely unclear - and questions about this are not answered [1]. The only small hint (building docker images) make completely no sense to me: docker files are (more or less) tar files; LVM just cannot be used. [2] I'm missing the 'Big Picture' here ;-) > For the EFI change there > are some issues you've hit on that need to be fixed, but I am not sure > they are going to require basing the change off a more general fix. It > might be as easy as copying the element contents in to a new dir when a > more general solution is completed in which case getting the changes > completed in smaller portions is more beneficial IMO. My opinion here is that this patch adds to the stickiness of the spaghetti :-) It adds more places where assumptions are made about names of block device or partition names. Of course it's possible to clean up afterwards - maybe this is a strange attitude of me - I try to clean up things before doing the work. One more technical detail here: the partitions are currently organized in the way, that the boot partition is the second one. Did you ever saw a system like this? I asked me, why this was done in this way and came to the conclusion: because other parts of the source code assume, that the first partition is the root partition. So you get a running EFI system, but it is not longer possible to enlarge the root partition... But again: these are only my opinions - it's you who decide. > I also wanted to say thanks a ton for the work and reviews - it is > extremely useful stuff and we desperately need the help. :) Thank you all for your support and explanations! I have not that much time - because I do everything in my spare time here. Unfortunately looks like I need to spend more time writing mails and documentation instead of source code :-) Kind regards Andre [1] https://review.openstack.org/#/c/252041/ [2] https://docs.docker.com/engine/userguide/eng-image/baseimages/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [diskimage-builder] Howto refactor?
Hi! Created a first draft of a 'Big Picture' document including an overview and a technical breakdown [1]. I'm not sure if this is what you expect or if still something is missing? Maybe we can start with etherpad - and do the first some iterations there. Later on I'd like to see it moved to the dib repo (IMHO requirements, design documents and source code should live together :-) ). I'll have a detailed look at your suggestions about splitting things apart and will come up with a proposal. Kind regards Andre [1] https://etherpad.openstack.org/p/C80jjsAs4x __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [diskimage-builder] Howto refactor?
Hello! Currently I'm working on diskimage-builder. My long term goal is, to add some functionality to the DIB's block device layer, like to be able to use multiple partitions, logical volumes and mount points. Initially I created a general partitioning element [1] and based on this an experimental lvm element [2]. During the implementation I realized, that it 'works somehow', but there are a lot of drawbacks implementing things as separate elements. Because of this, I started to refactor the block device layer - i.e. the portions of the DIB where the block devices for the VM image are created and prepared. [3] [4] [5] Currently I'm working on the file system and mount layers. I have the feeling, that patches from other persons - like [6] or [7] - are somewhat blocked, because of the uncertainty how to continue here (please correct me, if I'm wrong). Because I'm a newbie here, I ask you for help, support and consultation how to continue. I see the following possibilities: 1. Start a discussion about the requirements Problem here: the requirements will not change during the refactoring phase - but maybe it's a good starting point. 2. Start a discussion about design 3. Continue the implementation and hope that the whole patch set gets accepted some time But maybe there are more possibilities? Any comment or review is welcome! Kind regards Andreas P.S.: The technical details are described in the documentation of the appropriate patches. [1] "New Element: partitioning" https://review.openstack.org/#/c/313938/ [2] "New Element: lvm" https://review.openstack.org/#/c/316529/ [3] "Refactor: Infrastructure" https://review.openstack.org/#/c/319591/ [4] "Refactor: Image creation" https://review.openstack.org/#/c/322397/ [5] "Refactor: Partitioning" https://review.openstack.org/#/c/322671/ [6] https://review.openstack.org/#/c/252041/ [7] https://review.openstack.org/#/c/287784/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [diskimage-builder] LVM in diskimage-builder
Hi All! AFAIK the diskimage-builder started as a testing tool, but it looks that it evolves more and more into a general propose tool for creating docker and VM disk images. Currently there are ongoing efforts to add LVM [1]. But because some features that I need are missing, I created my own prototype to get a 'feeling' for the complexity and a possible way doing things [2]. I contacted Yolanda (the author of the original patch) and we agreed to join forces here to implement a patch that fits our both needs. Yolanda made the proposal before starting implementing things, we could contact Open Stack developers via this mailing list and ask about possible additional requirements and comments. Here is a short list of my requirements - and as far as I understood Yolanda, her requirements are a subset: MUST be able to o use one partition as PV o use one VG o use many LV (up to 10) o specify the mount point for each of the LVs o specify mount points that 'overlap', e.g. /, /var, /var/log, /var/spool o use the default file system (options) as specified via command line o survive in every day's live - and not only in dedicated test environment: must be robust and handle error scenarios o use '/' (root fs) as LV o run within different distributions - like Debian, Ubuntu, Centos7. NICE TO HAVE o Multiple partitions as PVs o Multiple VGs o LVM without any partition Or: why do we need partitions these days? ;-) Problem: I have no idea how to boot from a pure LVM image. Every idea or comment will help! Please feel invited to have a (short) look / review at the implementation [1] and the design study [2]. Kind regards Andre [1] https://review.openstack.org/#/c/252041/ [2] https://review.openstack.org/#/c/316529/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
