)]}'
{"doc/source/specs/v1/approved/dib-debootstrap-minimal-element.rst":[{"author":{"_account_id":10035,"name":"greghaynes","email":"greg@greghaynes.net","username":"greghaynes"},"change_message_id":"f5440a1e5d3a36df4f647b7f41abbd28c2eb7874","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Split the debootstrap element into debootstrap / debootstrap-minimal. Where the"},{"line_number":27,"context_line":"debootstrap-minimal element will invoke debootstrap with the --variant\u003dminbase"},{"line_number":28,"context_line":"flag. Only support root.d phase to avoid pulling in diskimage-builder"},{"line_number":29,"context_line":"dependencies."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Alternatives"},{"line_number":32,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a3c09a3_bb88fee8","line":29,"updated":"2017-01-14 00:09:04.000000000","message":"Our current debootstrap element uses --varian\u003dminbase, so I am not sure why that is being pointed out here. The actual difference AIUI is you don\u0027t want the element-deps because they pull in extra packages? Firstly, this should probably be reworded to say that.\n\nWe spoke about this a bit on the ML but its probably better to move the convo here so I am going to repeat a bit of what I said there - Is this purely to save space from installing the python packages? How much space is this and what all packages are we trying to prevent from being installed? The issue is that dib as is depends on python in chroot for a lot of things (anything using package-installs). I can think of some ways we might be able to fix that but my two concerns are:\n\n* if this is a few 10\u0027s of MB as I suspect, I\u0027m surprised thats worth the effort (although if someone wants to put in the effort to fix it properly I certainly wont stop them) and 2)\n* if there are other packages that dib depends on (such as find/apt/various unit utils) which you desire to not have installed then there\u0027s no solution in which this element can sanely integrate with the other elements (and much of the value of it existing in DIB is lost).\n\nIOW, I\u0027d really like us to find a way to make the element-deps of debootstrap work for containers, not reimplement debootstrap so we can have a two nearly identical code paths we need to maintain for debootstrap. For python + package-installs I believe this could be fixed by better integrating package-installs and dib allowing us to run package-installs from outside of the chroot at the appropriate parts of each phase. Again though, I\u0027m dubious this is worth the dev cost.","commit_id":"a0bc660ad7cd1a77ffe70d13044b9ec73f68000a"},{"author":{"_account_id":4162,"name":"Paul Belanger","email":"pabelanger@redhat.com","username":"pabelanger"},"change_message_id":"7828550ce3d3c35a5779d4493e92e8f343650bde","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Split the debootstrap element into debootstrap / debootstrap-minimal. Where the"},{"line_number":27,"context_line":"debootstrap-minimal element will invoke debootstrap with the --variant\u003dminbase"},{"line_number":28,"context_line":"flag. Only support root.d phase to avoid pulling in diskimage-builder"},{"line_number":29,"context_line":"dependencies."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Alternatives"},{"line_number":32,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a3c09a3_6c941a37","line":29,"in_reply_to":"7a3c09a3_bb88fee8","updated":"2017-01-14 03:31:35.000000000","message":"I can reword to mention the elements-deps pulling in DIB required packages.\n\nI\u0027d say, yes a few MBs is part of the motivation, I know everything I\u0027ve read about containers, size matters.  Same goes with the apt.conf / dpkg settings, etc.  There is no easy way to opt out of them with DIB.  You are right, much of the value of it existing in DIB is lost, with the debootstrap-minimal element I am suggesting.  However, the parts that are not lost are the creating of the chroot, compression of the image and various steps that happen with the root.d phase.\n\nI\u0027ll defer to what everybody agrees about the maintenance of an additional code path, I don\u0027t see it as much of a burden now that we\u0027ve expanded our testing coverage to include nodepool dsvm jobs.\n\nI agree that moving package-installs outside of the chroot is a good step forward.  This is the biggest downside of using DIB to create a container, then a raw Dockerfile, left over bits inside the container for configuration (ansible has this issue too).","commit_id":"a0bc660ad7cd1a77ffe70d13044b9ec73f68000a"},{"author":{"_account_id":10035,"name":"greghaynes","email":"greg@greghaynes.net","username":"greghaynes"},"change_message_id":"f5440a1e5d3a36df4f647b7f41abbd28c2eb7874","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Not use diskimage-builder to create debootstrap chroot. For example, a simple"},{"line_number":35,"context_line":"bash script to invoke debootstrap directly would be another way to achieve"},{"line_number":36,"context_line":"this."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Security Impact"},{"line_number":39,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a3c09a3_7b65b643","line":36,"updated":"2017-01-14 00:09:04.000000000","message":"Can we remove this? I think alternatives are meant for alternative solutions.\n\nAn alternative solution might be: remove the packages after they are installed.","commit_id":"a0bc660ad7cd1a77ffe70d13044b9ec73f68000a"},{"author":{"_account_id":4162,"name":"Paul Belanger","email":"pabelanger@redhat.com","username":"pabelanger"},"change_message_id":"7828550ce3d3c35a5779d4493e92e8f343650bde","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Not use diskimage-builder to create debootstrap chroot. For example, a simple"},{"line_number":35,"context_line":"bash script to invoke debootstrap directly would be another way to achieve"},{"line_number":36,"context_line":"this."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Security Impact"},{"line_number":39,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a3c09a3_ec1d6a10","line":36,"in_reply_to":"7a3c09a3_7b65b643","updated":"2017-01-14 03:31:35.000000000","message":"I was actually referring to the mkimage.sh[1] script that ships with docker.\n\n  sudo ./mkimage.sh -d /var/tmp/docker-mkimage.cwjsknUbqY/rootfs debootstrap --variant\u003dminbase trusty\n\nThis actually provides all the current functionality I am looking for. I\u0027m hoping we can expose the same functionality for diskimage-builder.\n\n[1] https://github.com/docker/docker/blob/master/contrib/mkimage.sh","commit_id":"a0bc660ad7cd1a77ffe70d13044b9ec73f68000a"}]}