)]}'
{"goals/proposed/container-images.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d51d1a9c7c6c5a116c30d2276e7e182111651b49","unresolved":false,"context_lines":[{"line_number":8,"context_line":"infrastructure that focuses on containerizing as much infrastructure as"},{"line_number":9,"context_line":"possible."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"The majority of open source projects currently have an easy way to to get"},{"line_number":12,"context_line":"them up and running, primarily due to the fact that they container within"},{"line_number":13,"context_line":"their repositories a ``Dockerfile`` which you can use or published images"},{"line_number":14,"context_line":"that you can pull and deploy."},{"line_number":15,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_9098226b","line":12,"range":{"start_line":11,"start_character":0,"end_line":12,"end_character":20},"updated":"2020-04-20 22:47:05.000000000","message":"i agree with this","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d51d1a9c7c6c5a116c30d2276e7e182111651b49","unresolved":false,"context_lines":[{"line_number":9,"context_line":"possible."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"The majority of open source projects currently have an easy way to to get"},{"line_number":12,"context_line":"them up and running, primarily due to the fact that they container within"},{"line_number":13,"context_line":"their repositories a ``Dockerfile`` which you can use or published images"},{"line_number":14,"context_line":"that you can pull and deploy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"There are several benefits for these container images.  First of all, it"},{"line_number":17,"context_line":"will actually increase the likeliness of using OpenStack components for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d06bca1c","line":14,"range":{"start_line":12,"start_character":21,"end_line":14,"end_character":29},"updated":"2020-04-20 22:47:05.000000000","message":"but not with this.\n\nthat is one way to achive that for applications or services with no external dependicies, it breaks down when you start looking at distibuted systems which openstack is.\n\none thing that might be a worthey first step which coudl then lead to a goal like the current one later would be to enable all services withing a project to run in a monoloth executable. e.g. like busybox\n\nin k8s world this is provided by hyperkube.\n\nin nova functional test we create a tests that execute the distibuted componets of nova all in one process.\n\nso if we had a hypernova entrypoint that ran the nova api, conductor, compute serivce and schduler all in one process with an sqlight db and the oslo in memory rpc backend we could deploy a fully working nova by starting a singel command\n\n\ne.g. sudo hypernova --config nova.conf\n\nwe could futhter reduse the depencies by not only useing the nova fake driver as teh default removing the need for libvirt or openvswitch.\n\nthat said if you wanted to use both you could you jsut need to enable the libvirt virt driver in the nova.conf as normal.\n\n\n\nif we did the same thing for neutron cinder cyborg and heat? i think that then allow us to  package and subsequelty run all opentack projects with a singel binay per project with no depency on mysql or rabbit.\n\nthen you could have a singel docker file or even a tox env\ne.g. tox -e hyper\u003cproject\u003e to run the hyperconverd version of the poejct.\n\ni think the tox approch is partically nice as the workflow would basically be\n\ngit clone https://portject/url\ntox -e hyper\u003cproject\u003e\n\nwith out having to install anything other then git and tox and maybe the bindeps.\n\ni say maybe the bindeps as if you used the fake driver most if not all the bindeps beyond python should not be needed in novas case.\n\n\nif the goal is really to provide \"an easy way to to get\nthem up and running,\"\n\ni think exploing a hyper\u003cproject\u003e or hyperstack binay is a vaild alternitive which would not compete with andy of the existing project.\n\nhyperstack might be over reaching as while im sure we could make it plugable so that you can run all installed opetack service from one projcess if we wanted too like you can do with hypercube outside of demos im not sure you woudl ever want to do that.\n\nthat said i dont see why we coudl not create a hyperstack binary that actully did just that if we really wanted too.\n\nall we woudl need to achive that is 1\nmake sure all serivce can run with \nthe oslo messaging fake driver\nhttps://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_fake.py\n\n2 ensure that all service can run with sqlight3 as the db backend\n\n3 update all sercice to provide an entry point that runs them in a singel process using both of the above\n\nand finally 4  tie all of the above into one applciation that loads the other sercices via steavadore and execurts them in there  own process using python multi procssing so that it actully performs well enough to use.\n\n\nthat would evenutaly allow you to do\n\"sudo hyperstack\" and have a working openstack for dev and test use.\n\nif we did that i would probably use it in my day today dev as an alternitve to devstack or via devstack as i could still pip install -e the project and just edit the files on disk and restart 1 process to pick up the changes.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"9599e6a3b69f614bf8fb3ba712e6f54bb2e9b1a1","unresolved":false,"context_lines":[{"line_number":9,"context_line":"possible."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"The majority of open source projects currently have an easy way to to get"},{"line_number":12,"context_line":"them up and running, primarily due to the fact that they container within"},{"line_number":13,"context_line":"their repositories a ``Dockerfile`` which you can use or published images"},{"line_number":14,"context_line":"that you can pull and deploy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"There are several benefits for these container images.  First of all, it"},{"line_number":17,"context_line":"will actually increase the likeliness of using OpenStack components for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d84a7a25","line":14,"range":{"start_line":12,"start_character":21,"end_line":14,"end_character":29},"in_reply_to":"1f493fa4_d06bca1c","updated":"2020-04-24 07:45:53.000000000","message":"1) hyperkube is being phased out. It was not a great idea in the first place.\n2) reducing the number of components might be beneficial, but not as much as trimming them down/making them simpler, as you expressed (no messaging, sqlite). This is key. I doubt it\u0027s the scope of this goal though.\n3) I like the concept of your hyperstack though. That deserve a post in the \"ideas\" repo, don\u0027t you think?\n4) The bindep is indeed key IMO, for user experience.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":9,"context_line":"possible."},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"The majority of open source projects currently have an easy way to to get"},{"line_number":12,"context_line":"them up and running, primarily due to the fact that they container within"},{"line_number":13,"context_line":"their repositories a ``Dockerfile`` which you can use or published images"},{"line_number":14,"context_line":"that you can pull and deploy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"There are several benefits for these container images.  First of all, it"},{"line_number":17,"context_line":"will actually increase the likeliness of using OpenStack components for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d698d86b","line":14,"range":{"start_line":12,"start_character":21,"end_line":14,"end_character":29},"in_reply_to":"1f493fa4_d06bca1c","updated":"2020-04-21 13:14:48.000000000","message":"\u003e but not with this.\n \u003e \n \u003e that is one way to achive that for applications or services with no\n \u003e external dependicies, it breaks down when you start looking at\n \u003e distibuted systems which openstack is.\n \nI don\u0027t think we\u0027re aiming at solving the deployment story right now, I don\u0027t want us to try and take leaps 10 steps forward without us having walked the basic path of having a Dockerfile for a project, nothing more..\n\n \u003e one thing that might be a worthey first step which coudl then lead\n \u003e to a goal like the current one later would be to enable all\n \u003e services withing a project to run in a monoloth executable. e.g.\n \u003e like busybox\n \u003e \n \u003e in k8s world this is provided by hyperkube.\n \u003e \n \u003e in nova functional test we create a tests that execute the\n \u003e distibuted componets of nova all in one process.\n \u003e \n \u003e so if we had a hypernova entrypoint that ran the nova api,\n \u003e conductor, compute serivce and schduler all in one process with an\n \u003e sqlight db and the oslo in memory rpc backend we could deploy a\n \u003e fully working nova by starting a singel command\n \u003e \n \u003e \n \u003e e.g. sudo hypernova --config nova.conf\n \u003e \n \u003e we could futhter reduse the depencies by not only useing the nova\n \u003e fake driver as teh default removing the need for libvirt or\n \u003e openvswitch.\n \u003e \n \u003e that said if you wanted to use both you could you jsut need to\n \u003e enable the libvirt virt driver in the nova.conf as normal.\n \u003e \n \u003e \n \u003e \n \u003e if we did the same thing for neutron cinder cyborg and heat? i\n \u003e think that then allow us to  package and subsequelty run all\n \u003e opentack projects with a singel binay per project with no depency\n \u003e on mysql or rabbit.\n \u003e \n \u003e then you could have a singel docker file or even a tox env\n \u003e e.g. tox -e hyper\u003cproject\u003e to run the hyperconverd version of the\n \u003e poejct.\n \u003e \n \u003e i think the tox approch is partically nice as the workflow would\n \u003e basically be\n \u003e \n \u003e git clone https://portject/url\n \u003e tox -e hyper\u003cproject\u003e\n \u003e \n \u003e with out having to install anything other then git and tox and\n \u003e maybe the bindeps.\n \u003e \n \u003e i say maybe the bindeps as if you used the fake driver most if not\n \u003e all the bindeps beyond python should not be needed in novas case.\n \u003e \n \u003e \n \u003e if the goal is really to provide \"an easy way to to get\n \u003e them up and running,\"\n\nI think a Dockerfile is something that might help and simplify usage of containers but I don\u0027t think that I want us to push as far as this.  I do think this idea is very legitimate and I like it a lot, it\u0027s something that others have pushed on by saying \"let\u0027s have a single agent\".\n\n \u003e i think exploing a hyper\u003cproject\u003e or hyperstack binay is a vaild\n \u003e alternitive which would not compete with andy of the existing\n \u003e project.\n \u003e \n \u003e hyperstack might be over reaching as while im sure we could make it\n \u003e plugable so that you can run all installed opetack service from one\n \u003e projcess if we wanted too like you can do with hypercube outside of\n \u003e demos im not sure you woudl ever want to do that.\n \u003e \n \u003e that said i dont see why we coudl not create a hyperstack binary\n \u003e that actully did just that if we really wanted too.\n \u003e \n \u003e all we woudl need to achive that is 1\n \u003e make sure all serivce can run with\n \u003e the oslo messaging fake driver\n \u003e https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_fake.py\n \u003e \n \u003e 2 ensure that all service can run with sqlight3 as the db backend\n \u003e \n \u003e 3 update all sercice to provide an entry point that runs them in a\n \u003e singel process using both of the above\n \u003e \n \u003e and finally 4  tie all of the above into one applciation that loads\n \u003e the other sercices via steavadore and execurts them in there  own\n \u003e process using python multi procssing so that it actully performs\n \u003e well enough to use.\n \u003e \n \u003e \n \u003e that would evenutaly allow you to do\n \u003e \"sudo hyperstack\" and have a working openstack for dev and test\n \u003e use.\n \u003e \n \u003e if we did that i would probably use it in my day today dev as an\n \u003e alternitve to devstack or via devstack as i could still pip install\n \u003e -e the project and just edit the files on disk and restart 1\n \u003e process to pick up the changes.\n\nThat would really be awesome, but yeah, that\u0027s a little out of the scope of the goal, we\u0027re just trying to have Docker images, we can totally look into this (and I think if we do this, it should be containerized _or_ not, as it has benefits for both).","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":29,"context_line":"To facilitate tracking, commits related to this goal should use the"},{"line_number":30,"context_line":"gerrit topic::"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"  goal/container-images"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Completion Criteria"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_4a626b18","line":32,"range":{"start_line":32,"start_character":7,"end_line":32,"end_character":16},"updated":"2020-04-20 22:06:16.000000000","message":"nit:docker \n\nthe rest of the file is spcifying \"Dockerfile\" and docker-compose locking in a specific container technology so the goal should be more specific.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":29,"context_line":"To facilitate tracking, commits related to this goal should use the"},{"line_number":30,"context_line":"gerrit topic::"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"  goal/container-images"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Completion Criteria"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_b69d4c5b","line":32,"range":{"start_line":32,"start_character":7,"end_line":32,"end_character":16},"in_reply_to":"1f493fa4_4a626b18","updated":"2020-04-21 13:14:48.000000000","message":"The only problem is Dockerfile is the standard but the goal is to build OCI compliant images really.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":34,"context_line":"Completion Criteria"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_95ff7466","line":37,"range":{"start_line":37,"start_character":37,"end_line":37,"end_character":51},"updated":"2020-04-20 22:06:16.000000000","message":"a singel docker file per project will not work for many project like nova where we have multiple services. you would need one docker file for each of the console scirpt entrypoint in the setup cfg\n\nhttps://github.com/openstack/nova/blob/master/setup.cfg#L69-L82\n\neach entry point is a seperate applicaiton.\nsome are daemons some are console apps.\n\nyou could create a monolitic container that has all of them and have no default entry point in the container then leave it to the user/automation to select the application to run but that will ballon the contaienr size if you try to supporit all the backends.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"9599e6a3b69f614bf8fb3ba712e6f54bb2e9b1a1","unresolved":false,"context_lines":[{"line_number":34,"context_line":"Completion Criteria"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_58602aa6","line":37,"range":{"start_line":37,"start_character":37,"end_line":37,"end_character":51},"in_reply_to":"1f493fa4_56c5e83b","updated":"2020-04-24 07:45:53.000000000","message":"Yes multi-stage can solve the multiple entrypoints, and I suppose the rest can be solved by user/automation.\n\nI think it\u0027s clear enough as a goal.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":34,"context_line":"Completion Criteria"},{"line_number":35,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_56c5e83b","line":37,"range":{"start_line":37,"start_character":37,"end_line":37,"end_character":51},"in_reply_to":"1f493fa4_95ff7466","updated":"2020-04-21 13:14:48.000000000","message":"That\u0027s already solved by those images if you see the example that I posted.  We actually build the whole thing out and have multiple targets, check out how Zuul does it:\n\nhttps://opendev.org/zuul/zuul/src/branch/master/Dockerfile","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Stretch goals"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_9534944c","line":40,"range":{"start_line":39,"start_character":3,"end_line":40,"end_character":13},"updated":"2020-04-20 22:06:16.000000000","message":"with what distro?\nwhit what architecure?\nsource or binary? both?","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"9599e6a3b69f614bf8fb3ba712e6f54bb2e9b1a1","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Stretch goals"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_f8681688","line":40,"range":{"start_line":39,"start_character":3,"end_line":40,"end_character":13},"in_reply_to":"1f493fa4_76e104d1","updated":"2020-04-24 07:45:53.000000000","message":"So that\u0027s debian x86: https://github.com/docker-library/python/blob/21d2ab0a50100ebdaf32f4bbb214bf21f857d1da/3.8/buster/slim/Dockerfile . Debian is not on the PTI. It\u0027s more risky as a first step, but I am fine for that.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"#. All projects should have a simple ``Dockerfile`` in the root directory of"},{"line_number":38,"context_line":"   their repositories."},{"line_number":39,"context_line":"#. All projects should be running the build/upload/promote jobs in their Zuul"},{"line_number":40,"context_line":"   pipelines."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Stretch goals"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_76e104d1","line":40,"range":{"start_line":39,"start_character":3,"end_line":40,"end_character":13},"in_reply_to":"1f493fa4_9534944c","updated":"2020-04-21 13:14:48.000000000","message":"We\u0027re using\n\n  FROM python:3-slim\n\nequivilant with a few things from opendev, the goal isn\u0027t to provide a specific distro, but I think we can probably initially aim for x86 images, \"source\" only (binary distros can ship their own images if they\u0027d like).  Think of this as pypi wheels.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":42,"context_line":"Stretch goals"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The improvement of DevStack to support the ability to run using the"},{"line_number":46,"context_line":"   containerized images."},{"line_number":47,"context_line":"#. Simple documentation on how to get started using ``docker-compose`` inside"},{"line_number":48,"context_line":"   each project."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_f544f8b9","line":46,"range":{"start_line":45,"start_character":2,"end_line":46,"end_character":24},"updated":"2020-04-20 22:06:16.000000000","message":"so if we did that then we are nolonger testing co installablity which would be a pretty major regression.\n\nisolation of  services in containers is greate in many respects but requiring it to have openstack enven function is not and if we only use devstack + container in the gate that is a regression in my opipion and not something we shoudl strive for as a goal.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":42,"context_line":"Stretch goals"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The improvement of DevStack to support the ability to run using the"},{"line_number":46,"context_line":"   containerized images."},{"line_number":47,"context_line":"#. Simple documentation on how to get started using ``docker-compose`` inside"},{"line_number":48,"context_line":"   each project."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_762f44f6","line":46,"range":{"start_line":45,"start_character":2,"end_line":46,"end_character":24},"in_reply_to":"1f493fa4_f544f8b9","updated":"2020-04-21 13:14:48.000000000","message":"Sure, I think this is why I clarified \"support the ability\" as I think using plain o\u0027l pip installs is still valuable and easy for development.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The improvement of DevStack to support the ability to run using the"},{"line_number":46,"context_line":"   containerized images."},{"line_number":47,"context_line":"#. Simple documentation on how to get started using ``docker-compose`` inside"},{"line_number":48,"context_line":"   each project."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d5545c57","line":47,"range":{"start_line":47,"start_character":53,"end_line":47,"end_character":68},"updated":"2020-04-20 22:06:16.000000000","message":"\"docker compute up\" would be nice but we would have to be very opinionated as docker compose does not really allow extensive customisation. im not sure if its widely availabel on all distros anymore. i belive it was droped form centos/rhel although it is available via the docker.com rpm repos if you use docker-ce.\n\nalso many projects require other projects to work so the nova docker-compose would need to setup keystone, glance and neutron to get a minium deployment working.\n\ni think kolla-ansible is a much more reasonable apporch to that or maybe osa. im much more familar with kolla so that would be my default go to containerised openstack.\n\nfor you example https://review.opendev.org/713975\nkeysonte like placment has very few deps and could use sqlite for its db if required.\n\nnova would need many many other service depnecys both at the operating system level and openstack level.\n\nwe could not take the same approach of using sqlight3 for nova as both conductor and the api need to acess the db directly which would lead to db currption with sqlight\nso at a minium we would need the compose file to deploy mysql\n\nwe would need rabbitmq and realistically openvswitch and libvirt.\n\nthat leads to another issue openvsiwtch or the neutron linux bridge backend could be used but unlike a normal docker container we woudl need to run thos with --netns\u003dhost, for libvirt it would also need to have --netns\u003dhost and --pid\u003dhost. if they are running in multiple contaier then you also need to set up volume mounts between them. you run them in a singel container you dont really need docker compose and you need to use a pid 1 like supervisord.\n\nfiguring out how to run distitbute service with operating system dep in a container is one of the benifts that kolla ansible has already done which all proejcts would have to reinvent and maintain.\n\ni would want to see an a more compleing example then https://review.opendev.org/713975 to show how more complex service can be built and used as service like keystone are much simpler to run in a container then nova, neutron or cinder.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The improvement of DevStack to support the ability to run using the"},{"line_number":46,"context_line":"   containerized images."},{"line_number":47,"context_line":"#. Simple documentation on how to get started using ``docker-compose`` inside"},{"line_number":48,"context_line":"   each project."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_f6235404","line":47,"range":{"start_line":47,"start_character":53,"end_line":47,"end_character":68},"in_reply_to":"1f493fa4_d5545c57","updated":"2020-04-21 13:14:48.000000000","message":"\u003e \"docker compute up\" would be nice but we would have to be very\n \u003e opinionated as docker compose does not really allow extensive\n \u003e customisation. im not sure if its widely availabel on all distros\n \u003e anymore. i belive it was droped form centos/rhel although it is\n \u003e available via the docker.com rpm repos if you use docker-ce.\n \nRight, the idea is that if someone wants a really really really really simple way of getting started, they should just use what\u0027s available.  We decide what\u0027s the easiest way to do that.\n\n \u003e also many projects require other projects to work so the nova\n \u003e docker-compose would need to setup keystone, glance and neutron to\n \u003e get a minium deployment working.\n \nYeah, we can probably figure out a way to tie all that together\n\n \u003e i think kolla-ansible is a much more reasonable apporch to that or\n \u003e maybe osa. im much more familar with kolla so that would be my\n \u003e default go to containerised openstack.\n \u003e \n \u003e for you example https://review.opendev.org/713975\n \u003e keysonte like placment has very few deps and could use sqlite for\n \u003e its db if required.\n \u003e \n \u003e nova would need many many other service depnecys both at the\n \u003e operating system level and openstack level.\n \u003e \n \u003e we could not take the same approach of using sqlight3 for nova as\n \u003e both conductor and the api need to acess the db directly which\n \u003e would lead to db currption with sqlight\n \u003e so at a minium we would need the compose file to deploy mysql\n \u003e \n \u003e we would need rabbitmq and realistically openvswitch and libvirt.\n \u003e \n \u003e that leads to another issue openvsiwtch or the neutron linux bridge\n \u003e backend could be used but unlike a normal docker container we woudl\n \u003e need to run thos with --netns\u003dhost, for libvirt it would also need\n \u003e to have --netns\u003dhost and --pid\u003dhost. if they are running in\n \u003e multiple contaier then you also need to set up volume mounts\n \u003e between them. you run them in a singel container you dont really\n \u003e need docker compose and you need to use a pid 1 like supervisord.\n \u003e \n \u003e figuring out how to run distitbute service with operating system\n \u003e dep in a container is one of the benifts that kolla ansible has\n \u003e already done which all proejcts would have to reinvent and\n \u003e maintain.\n \u003e \n \u003e i would want to see an a more compleing example then\n \u003e https://review.opendev.org/713975 to show how more complex service\n \u003e can be built and used as service like keystone are much simpler to\n \u003e run in a container then nova, neutron or cinder.\n\nExactly.  We don\u0027t want to re-invent the wheel, we don\u0027t want to support a whole frame of OS, or build big images.  When using those images, you might have to keep some logic in the base OS (like maybe run libvirt there still), or maybe you\u0027ll use the libvirt image provided by Kolla.  That\u0027s your choice to make.  This is _literally_ just the equivilant of uploading to pypi","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"OpenDev has created a set of jobs and base container images which allow us to"},{"line_number":54,"context_line":"very easily build images for software with a very simple ``Dockerfile`` and"},{"line_number":55,"context_line":"the usage of ``bindep.txt``.  The jobs are all ready and used in production"},{"line_number":56,"context_line":"by OpenDev, which makes the work behind building those images very trivial."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"An example of a change that added support to build images for Keystone"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_35cb001f","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":25},"updated":"2020-04-20 22:06:16.000000000","message":"i do think using bindeps more extensivly woudl be a good goal.\n\ni would love if devstack or kolla could realy on bindeps supplying all of the package requirements for a project and only install what is listed in bindeps.\n\nit would also be usefaul for downstream testing as we could use the same mechanisum.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"9599e6a3b69f614bf8fb3ba712e6f54bb2e9b1a1","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"OpenDev has created a set of jobs and base container images which allow us to"},{"line_number":54,"context_line":"very easily build images for software with a very simple ``Dockerfile`` and"},{"line_number":55,"context_line":"the usage of ``bindep.txt``.  The jobs are all ready and used in production"},{"line_number":56,"context_line":"by OpenDev, which makes the work behind building those images very trivial."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"An example of a change that added support to build images for Keystone"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d8cf1a7d","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":25},"in_reply_to":"1f493fa4_35cb001f","updated":"2020-04-24 07:45:53.000000000","message":"That was why I proposed this as a first step for the containers SIG (which dit not really took off). Lack of time and all that. I think having a consistent bindep usage for all the projects (outside just testing) would be beneficial, as _all_ the deployment projects could simply use that.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"OpenDev has created a set of jobs and base container images which allow us to"},{"line_number":54,"context_line":"very easily build images for software with a very simple ``Dockerfile`` and"},{"line_number":55,"context_line":"the usage of ``bindep.txt``.  The jobs are all ready and used in production"},{"line_number":56,"context_line":"by OpenDev, which makes the work behind building those images very trivial."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"An example of a change that added support to build images for Keystone"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_967810f9","line":55,"range":{"start_line":55,"start_character":15,"end_line":55,"end_character":25},"in_reply_to":"1f493fa4_35cb001f","updated":"2020-04-21 13:14:48.000000000","message":"Yes, so this brings a benefit of being able to leverage this!","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"f6f63886b949005574b86582b27134956d9495c3","unresolved":false,"context_lines":[{"line_number":70,"context_line":"  issues, primarily that it requires building all wheels into a common middle"},{"line_number":71,"context_line":"  image, making it impossible to simple run a ``docker build`` without that"},{"line_number":72,"context_line":"  middle layer.  It also relies on creating images based on specific operating"},{"line_number":73,"context_line":"  systems."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ff570b3c_e4451845","line":73,"updated":"2020-05-13 15:27:04.000000000","message":"I think it\u0027s a good idea to allow building images based upon a specific distro.  We shouldn\u0027t be picking and forcing a specific distro on someone that wants to use our official images.   Some people that deploy like ubuntu, others like RH.   The loci requirements wheels should be built by loci when a project does a release anyway.\n\nWe just migrated off of kolla to loci images internally at SAP.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"b43630235898179ce674e53e5ed414ecc8290198","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_cd08042f","line":78,"updated":"2020-04-16 14:23:22.000000000","message":"Indeed, the common-base does help but it makes the Kolla images very unique to Kolla only and special in their way.  Also, the build tools being inside is something we\u0027d like to avoid from the perspective of making those images lighter.\n\nThe thing is I don\u0027t want us to focus on providing images for all services alongside a deployment tool for it, the goal is to ship images for OpenStack, nothing more.\n\nThe goal here is focusing on using the base Python image provided by DockerHub (library/python) more specifically.  We do not intend to start shipping per-operating-system images.\n\nHowever, the idea is that the Dockerfile should be easy for a down-stream distro shipper to create a similar Dockerfile as long as it has the same entrypoint (if they want to use debs or rpms).\n\nThe problem with the Kolla images is that you can\u0027t just do:\n\n  docker build .\n\nThat\u0027s a problem, the fact that you\u0027re asking someone to install a whole bunch of dependnecies that are based on Python which pull other things \"just to build an image\" does not seem like it\u0027s the right way.  The \"normal way\" that things work is that Dockerfile\u0027s live inside the repository, that\u0027s the way it works everywhere, let\u0027s not be a unicorn..\n\nThis doesn\u0027t actually cater for standalone, someone can mesh all of these, we may even decide to even make a container-image mode of DevStack, the idea isn\u0027t to provide deployment tooling, but just an image.  Think how we upload PyPI images.\n\nI think we will be able to work through theseout, I think the issue of extra plugins in someting that has been actually solved as these images will automatically install everything that\u0027s inside extras, the idea is to have one-service-per-container, not launching multiple in a single one.\n\nI don\u0027t think that this is an effort that will go in vain, I think this is a net positive, the biggest reason we don\u0027t have in-repo Dockerfile\u0027s made it seem never \u0027official\u0027, we also didn\u0027t have the system that are being used by others like OpenDev.\n\nIf we ditch the Dockerfile format makes it even worse, I know we want to build cool things using new tools, but peple want to just run `docker build` .. we can do these other things orthogonally, I agree, but our basic fundamental images should be built as easily as possible","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"21fe76edee8f2eb12d71a163af47d33c7c453365","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  middle layer.  It also relies on creating images based on specific operating"},{"line_number":73,"context_line":"  systems."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_b527c012","line":78,"range":{"start_line":75,"start_character":0,"end_line":78,"end_character":8},"updated":"2020-04-16 12:10:11.000000000","message":"This is true. Kolla relies on common bases to reduce image sizes, but it has all build tools inside the images so it adds bulk. Another pain point is templating of all Dockerfiles - it gets unwieldy at some points.\n\nOne point to note is that Kolla does more than OpenStack, delivering all the prereqs as well as helper services. We would gladly benefit from having a coordinated OpenStack way to do OpenStack though.\n\nAnother point to note is that Kolla supports multiple distros (CentOS, Ubuntu and Debian). Is this goal only about building upon Ubuntu? It\u0027s OK if it is but let\u0027s not make it constrain us from supporting other major players.\n\nI generally don\u0027t like that we are reinventing the wheel here without adding benefits possible via other means, including marketing ones (as in \u0027try Kolla for easy to use images\u0027). Based on the keystone PoC above, similar result is obtainable from Kolla by asking for the Keystone image, the location of Keystone sources can be chosen at will so it\u0027s a no-brainer. I certainly agree with the paragraph just below - Kolla tooling does not currently use Zuul tooling efficiently. I think we should work for some middle ground here.\n\nAnother negative case is that the proposed solution by definition caters only for standalone usecase. The truth is that a typical, traditional OpenStack deployment has several services with similar requirements and having many copies of them is inefficient as well.\n\nYet another thing to have in mind is that Keystone is actually simple. Consider Nova, Ironic, Neutron or Cinder which consist of multiple services, depending on plugins/backends/drivers which have their reqs etc. It\u0027s clumsy the way it is done in Kolla now (where we throw everything at them) but it is important to consider future-wise for any attempt at containerization of something more than basic WSGI services.\n\nMy main worry is that we end up with a new way to containerize that will give us a toy experience but no real level of usefulness, i.e. repeat the \"success\" of LOCI but in a distributed way (so more things to clean afterwards).\n\nFinal remarks: I will be doing some writeup on ML later this week (which includes weekend) on how to achieve Kolla way in a less ugly way that might be interesting in scope of this but possibly orthogonal. A part of it is that we should ditch the Dockerfile format which is clumsy for any autogeneration and instead go for more buildah-like approach or just about any other. After all, image is just a packed up directory structure with some metadata.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d068eabb","line":78,"in_reply_to":"1f493fa4_0a77c33c","updated":"2020-04-20 22:06:16.000000000","message":"i think kolla is a strong candiade for this goal honestly and need more discussion before discounting it.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_3673fc17","line":78,"in_reply_to":"1f493fa4_0ae4e3ab","updated":"2020-04-21 13:14:48.000000000","message":"Alll of this should eventually go into bindep (hopefully)","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"b8633648707671a6741db0788b63236d227ff817","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_aa61583c","line":78,"in_reply_to":"1f493fa4_414a4455","updated":"2020-04-21 19:08:14.000000000","message":"\u003e You\u0027ve alluded to this a few times but I didn\u0027t pick up on it\n \u003e because I thought you had worked on the kolla project previously\n \u003e and so knew otherwise.\n \u003e \n \u003e Kolla does *not* run multiple services per container (with the\n \u003e exception of the bifrost image, soon may it die).\n\nMy apologies, in that case I think I was in the wrong.\n\n \u003e If that\u0027s the premise upon which this goal is based, I\u0027d suggest\n \u003e reevaluating.\n \u003e \n \u003e In terms of being a tool, kolla is a python package. You pip\n \u003e install it and run \u0027kolla-build\u0027. You could define your Dockerfile\n \u003e templates in each project separately, and pull them in via\n \u003e \u0027kolla-build --docker-dir /path/to/keystone/\u0027, to build images for\n \u003e a specific project, as I suggest in http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014304.html\n \u003e (at the end).\n \nI\u0027ll respond to that ML post shortly :)","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"55b035645225117689db692da50b722615a4703c","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_e556f306","line":78,"in_reply_to":"1f493fa4_aa61583c","updated":"2020-04-21 19:30:28.000000000","message":"ya sorry about that. when i created the bifrost image using systemd it was wit the intention of replacing it with smaller singel serivce iamges.\n\nit is the only kolla iamge that is built that way and while it work the intent was never to do that long term.\n\nkolla uses dumb init in some? all? image just to get a pid 1 that will reap child process and handel singnels properly for services that neeed that but in general its one executable per image and even things like ovs are decomosed so the ovs-db runs in one conatianer while the ovs-vswitchd runs in another.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_f6519464","line":78,"in_reply_to":"1f493fa4_d068eabb","updated":"2020-04-21 13:14:48.000000000","message":"Kolla provides nice images.  The problem is that Kolla has it\u0027s own build tools, creates images that are aiming to run multiple services in a single container, that\u0027s just not the way to run things in containers.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"d0b890e7ffbe66b54684231182722ab0da715ef5","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_414a4455","line":78,"in_reply_to":"1f493fa4_f6519464","updated":"2020-04-21 13:30:47.000000000","message":"You\u0027ve alluded to this a few times but I didn\u0027t pick up on it because I thought you had worked on the kolla project previously and so knew otherwise.\n\nKolla does *not* run multiple services per container (with the exception of the bifrost image, soon may it die).\n\nIf that\u0027s the premise upon which this goal is based, I\u0027d suggest reevaluating.\n\nIn terms of being a tool, kolla is a python package. You pip install it and run \u0027kolla-build\u0027. You could define your Dockerfile templates in each project separately, and pull them in via \u0027kolla-build --docker-dir /path/to/keystone/\u0027, to build images for a specific project, as I suggest in http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014304.html (at the end).\n\n\nAn example of a running kolla-ansible aio system:\n\nCONTAINER ID        IMAGE                                                                    COMMAND                  CREATED             STATUS              PORTS               NAMES\n2facbacb9f31        192.168.33.5:4000/kolla/centos-binary-horizon:master                     \"dumb-init --single-…\"   6 days ago          Up 6 days                               horizon\n1313df0ba866        192.168.33.5:4000/kolla/centos-binary-heat-engine:master                 \"dumb-init --single-…\"   6 days ago          Up 6 days                               heat_engine\ncf225b4cdfb4        192.168.33.5:4000/kolla/centos-binary-heat-api-cfn:master                \"dumb-init --single-…\"   6 days ago          Up 6 days                               heat_api_cfn\nef4857543ca5        192.168.33.5:4000/kolla/centos-binary-heat-api:master                    \"dumb-init --single-…\"   6 days ago          Up 6 days                               heat_api\nf88aefa42d30        192.168.33.5:4000/kolla/centos-binary-neutron-metadata-agent:master      \"dumb-init --single-…\"   6 days ago          Up 6 days                               neutron_metadata_agent\n8b3d89728a67        192.168.33.5:4000/kolla/centos-binary-neutron-l3-agent:master            \"dumb-init --single-…\"   6 days ago          Up 6 days                               neutron_l3_agent\nb89081cf3e2b        192.168.33.5:4000/kolla/centos-binary-neutron-dhcp-agent:master          \"dumb-init --single-…\"   6 days ago          Up 6 days                               neutron_dhcp_agent\n163f2cd3afa5        192.168.33.5:4000/kolla/centos-binary-neutron-openvswitch-agent:master   \"dumb-init --single-…\"   6 days ago          Up 6 days                               neutron_openvswitch_agent\nad98afa8ba80        192.168.33.5:4000/kolla/centos-binary-neutron-server:master              \"dumb-init --single-…\"   6 days ago          Up 6 days                               neutron_server\n48cb24c2dbac        192.168.33.5:4000/kolla/centos-binary-openvswitch-vswitchd:master        \"dumb-init --single-…\"   6 days ago          Up 6 days                               openvswitch_vswitchd\n2dc5784a99a2        192.168.33.5:4000/kolla/centos-binary-openvswitch-db-server:master       \"dumb-init --single-…\"   6 days ago          Up 6 days                               openvswitch_db\nd15ef67c2735        192.168.33.5:4000/kolla/centos-binary-nova-novncproxy:master             \"dumb-init --single-…\"   6 days ago          Up 6 days                               nova_novncproxy\n67b390efb40c        192.168.33.5:4000/kolla/centos-binary-nova-conductor:master              \"dumb-init --single-…\"   6 days ago          Up 6 days                               nova_conductor\n9ce59bc17a16        192.168.33.5:4000/kolla/centos-binary-nova-api:master                    \"dumb-init --single-…\"   6 days ago          Up 6 days                               nova_api\n1d8ad2684288        192.168.33.5:4000/kolla/centos-binary-nova-scheduler:master              \"dumb-init --single-…\"   6 days ago          Up 6 days                               nova_scheduler\n24f2d6dad35c        192.168.33.5:4000/kolla/centos-binary-placement-api:master               \"dumb-init --single-…\"   6 days ago          Up 6 days                               placement_api\n888a6f541394        192.168.33.5:4000/kolla/centos-binary-glance-api:master                  \"dumb-init --single-…\"   6 days ago          Up 6 days                               glance_api\nb533ae7930c6        192.168.33.5:4000/kolla/centos-binary-keystone-fernet:master             \"dumb-init --single-…\"   6 days ago          Up 6 days                               keystone_fernet\nc84290437766        192.168.33.5:4000/kolla/centos-binary-keystone-ssh:master                \"dumb-init --single-…\"   6 days ago          Up 6 days                               keystone_ssh\n07b296bf1bcc        192.168.33.5:4000/kolla/centos-binary-keystone:master                    \"dumb-init --single-…\"   6 days ago          Up 6 days                               keystone\n537c84bc8809        192.168.33.5:4000/kolla/centos-binary-rabbitmq:master                    \"dumb-init --single-…\"   6 days ago          Up 6 days                               rabbitmq\n637735fdddd3        192.168.33.5:4000/kolla/centos-binary-memcached:master                   \"dumb-init --single-…\"   6 days ago          Up 6 days                               memcached\n66bb1b19ce2c        192.168.33.5:4000/kolla/centos-binary-mariadb:master                     \"dumb-init -- kolla_…\"   6 days ago          Up 6 days                               mariadb\n9a360bdfc08c        192.168.33.5:4000/kolla/centos-binary-keepalived:master                  \"dumb-init --single-…\"   6 days ago          Up 6 days                               keepalived\n5c2d22d0b5c1        192.168.33.5:4000/kolla/centos-binary-haproxy:master                     \"dumb-init --single-…\"   6 days ago          Up 6 days                               haproxy\n960e7b00371b        192.168.33.5:4000/kolla/centos-binary-chrony:master                      \"dumb-init --single-…\"   6 days ago          Up 6 days                               chrony\n34b6bd940c1d        192.168.33.5:4000/kolla/centos-binary-cron:master                        \"dumb-init --single-…\"   6 days ago          Up 6 days                               cron\nde84bf7a943f        192.168.33.5:4000/kolla/centos-binary-kolla-toolbox:master               \"dumb-init --single-…\"   6 days ago          Up 6 days                               kolla_toolbox\n411cef658e6d        192.168.33.5:4000/kolla/centos-binary-fluentd:master                     \"dumb-init --single-…\"   6 days ago          Up 6 days                               fluentd","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":24072,"name":"Marcin Juszkiewicz","email":"mjuszkiewicz@redhat.com","username":"hrw"},"change_message_id":"4c2130ec483f47170787643f42794801d9e5474e","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_b6ff9fff","line":78,"in_reply_to":"3f4c43b2_184ea16e","updated":"2020-04-18 22:29:06.000000000","message":"\u003e \u003e Let me pick a more concrete example. The kolla nova-compute\n \u003e \u003e container installs the following RPMs on RHEL distros:\n \u003e \u003e\n \u003e \u003e ceph-common\n \u003e \n \u003e ceph-common is probably not needed, ceph-devel is probably needed\n \u003e as a build-time dependency to build the rbd package\n\nI have a feeling that you never tried to build an image where each Python module needs to be built from source. Try one day. Wait for grpcio, numpy, scipy and all those fancy Python packages which need to be built on all !x86 architectures.\n\nOr that mess called \u0027package dependencies\u0027 (including which \u0027recommended\u0027 packages needs to be installed for your case).","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"42cf8006c2c665442b3f8163ffcc49b57e674dc6","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_f00dd33e","line":78,"in_reply_to":"3f4c43b2_5092c74c","updated":"2020-04-16 15:11:17.000000000","message":"\u003e \u003e Indeed, the common-base does help but it makes the Kolla images\n \u003e \u003e very unique to Kolla only and special in their way.  Also, the\n \u003e \u003e build tools being inside is something we\u0027d like to avoid from the\n \u003e \u003e perspective of making those images lighter.\n \u003e \n \u003e Agreed. The building tools is my primary concern. Common base, as\n \u003e OpenStack is a common effort, actually makes sense, so I would not\n \u003e rule it out entirely.\n \nI mean, we could look into it, but then we\u0027d have an extra dependency of an image that you\u0027d have to rebuild, which I\u0027m hoping to avoid as much as we can.\n\n \u003e \u003e The thing is I don\u0027t want us to focus on providing images for all\n \u003e \u003e services alongside a deployment tool for it, the goal is to ship\n \u003e \u003e images for OpenStack, nothing more.\n \u003e \n \u003e Yeah, I got that. But they should be good enough to run basic\n \u003e scenarios. Otherwise it is art for art. I am pretty sure you\n \u003e already plan this for a multi-cycle megagoal but I don\u0027t find it\n \u003e mentioned here.\n \nI think that should be stage #2 -- I agree that we need to continue to work on actually making them work and showing them as a real functional thing.  But for the start, we should just try and get them packaged up in an image as step 0.\n\n \u003e \u003e The goal here is focusing on using the base Python image provided\n \u003e \u003e by DockerHub (library/python) more specifically.  We do not\n \u003e intend\n \u003e \u003e to start shipping per-operating-system images.\n \u003e \n \u003e OK, that makes it clear, could be mentioned directly.\n \u003e \n \u003e \u003e However, the idea is that the Dockerfile should be easy for a\n \u003e \u003e down-stream distro shipper to create a similar Dockerfile as long\n \u003e \u003e as it has the same entrypoint (if they want to use debs or rpms).\n \u003e \n \u003e Well, if we make it a plain Dockerfile, then it\u0027s just a source of\n \u003e inspiration. Still better than none.\n \nYep.  I think it is a start of a base right now, we can ship a plain Dockerfile that is FROM library/python but the distros can pick and do what they want.\n\n \u003e \u003e The problem with the Kolla images is that you can\u0027t just do:\n \u003e \u003e\n \u003e \u003e docker build .\n \u003e \u003e\n \u003e \u003e That\u0027s a problem, the fact that you\u0027re asking someone to install\n \u003e a\n \u003e \u003e whole bunch of dependnecies that are based on Python which pull\n \u003e \u003e other things \"just to build an image\" does not seem like it\u0027s the\n \u003e \u003e right way.  The \"normal way\" that things work is that\n \u003e Dockerfile\u0027s\n \u003e \u003e live inside the repository, that\u0027s the way it works everywhere,\n \u003e \u003e let\u0027s not be a unicorn..\n \u003e \n \u003e Valid point. Under no-python assumption this is very important but\n \u003e see discussion at the bottom.\n \u003e \n \u003e \u003e This doesn\u0027t actually cater for standalone, someone can mesh all\n \u003e of\n \u003e \u003e these, we may even decide to even make a container-image mode of\n \u003e \u003e DevStack, the idea isn\u0027t to provide deployment tooling, but just\n \u003e an\n \u003e \u003e image.  Think how we upload PyPI images.\n \u003e \n \u003e Yeah, I got that. I mentioned standalone because of no sharing\n \u003e assumption being made here.\n \n++. Nope, lightweight per-service images.\n\n \u003e \u003e I think we will be able to work through theseout, I think the\n \u003e issue\n \u003e \u003e of extra plugins in someting that has been actually solved as\n \u003e these\n \u003e \u003e images will automatically install everything that\u0027s inside\n \u003e extras,\n \u003e \u003e the idea is to have one-service-per-container, not launching\n \u003e \u003e multiple in a single one.\n \u003e \n \u003e This is another point against completely static Dockerfile. It\n \u003e limits flexibility (or put bluntly - it has none). What if we made\n \u003e some tooling based on providing proper metadata to actually\n \u003e generate the Dockerfile. Dockerfiles could be lying pregenerated in\n \u003e repos (just like etc files sometimes do).\n \nWe could do that, but to be honest, that seems like an overengineering effort right now, we have the tooling that OpenDev put in place, it\u0027s a very simple (near static) Dockerfile which relies proper setup.cfg and bindep.txt -- which indirectly makes our pypi wheels better :)\n\n \u003e \u003e I don\u0027t think that this is an effort that will go in vain, I\n \u003e think\n \u003e \u003e this is a net positive, the biggest reason we don\u0027t have in-repo\n \u003e \u003e Dockerfile\u0027s made it seem never \u0027official\u0027, we also didn\u0027t have\n \u003e the\n \u003e \u003e system that are being used by others like OpenDev.\n \u003e \n \u003e True that but let\u0027s seriously avoid images for images. Let this\n \u003e goal assume some applicability of them as an important part of\n \u003e success.\n \u003e \n \u003e \u003e If we ditch the Dockerfile format makes it even worse, I know we\n \u003e \u003e want to build cool things using new tools, but peple want to just\n \u003e \u003e run `docker build` .. we can do these other things orthogonally,\n \u003e I\n \u003e \u003e agree, but our basic fundamental images should be built as easily\n \u003e \u003e as possible\n \u003e \n \u003e People ARE running away from Dockerfiles (not massively but still),\n \u003e so it\u0027s not something that would be frowned upon. That said, this\n \u003e way one must assume some baseline tooling available for image\n \u003e building. Also, if we provide prebuilt images then interested\n \u003e parties can just consume them - if they are interested more, they\n \u003e can grab the tools to build. I am just trying to think long-term.\n \u003e Maybe it\u0027s an overkill, my mind is just wired weirdly. ;-)\n \u003e \n \u003e Let\u0027s think BIG.\n\nI think so, but if we find a way to solve things the simple way, let\u0027s do that.  I\u0027m all for engineering some really cool way of building images, but I worry that will paralyze us because we\u0027ll never agree on the \"best final thing\".  Let\u0027s use something workable for now, and see it work, and then we can push the boundaries and start innovating more in the space.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"168bec1a99f2dcc9af0ae356eb35c3df0505eb21","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_a3f3070a","line":78,"in_reply_to":"3f4c43b2_5092c74c","updated":"2020-04-16 15:20:31.000000000","message":"I don\u0027t particularly like this \u0027write off kolla project in a sentence\u0027.\n\nI agree with many of Radoslaw\u0027s points. Kolla is certainly unusual in how it builds images, but its approach does have some advantages.\n\nIt supports different distros, meaning you can maintain one base OS image.\n\nIt supports building from source or distro packages. The latter making it consumable by Tripleo.\n\nIt provides quite a range of drivers \u0026 plugins out of the box, and if you need any more (which more often than not you will because Openstack), it has a configuration mechanism to add \u0026 remove packages. This seems preferable to maintaining a fork of each project and modifying the dockerfile, or extending the image.\n\nIt can build all images in a single command. While the per-repo approach works well for upstream CI, setting up something similar downstream for every project would be a reasonable undertaking. There are various good reasons for wanting to build images locally.\n\nOf course it has disadvantages too, as has been mentioned. In particular the images are large. There is a PoC for using multi-stage builds, which can save some space, but only for source images.\n\nIf this effort gets traction, the various hurdles discussed are overcome and we end up with images with equivalent functionality to kolla\u0027s, I\u0027d be happy to reduce some maintenance burden.\n\nUltimately though, I doubt that the inability to run \u0027docker build .\u0027 is really a blocker for many.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"ff2a97c39ff167a91e5bc84a137183e60127f4ab","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_184ea16e","line":78,"in_reply_to":"3f4c43b2_72e0a3fb","updated":"2020-04-16 20:56:51.000000000","message":"\u003e Let me pick a more concrete example. The kolla nova-compute\n \u003e container installs the following RPMs on RHEL distros:\n \u003e \n \u003e ceph-common\n\nceph-common is probably not needed, ceph-devel is probably needed as a build-time dependency to build the rbd package\n\n \u003e device-mapper-multipath\n \u003e e2fsprogs\n \u003e genisoimage\n \u003e iscsi-initiator-utils\n \u003e nfs-utils\n \u003e nvme-cli\n\nRun-time dependency which we can install\n\n \u003e openstack-nova-compute\n \u003e openvswitch\n\nNone of those need to be inside the image.\n\n \u003e parted\n\nRun-time dependency to install \n\n \u003e python3-libguestfs\n\nRun-time dependency to install (but possibly could be also built with development headers)\n\n \u003e python3-oslo-vmware\n\nIs that a binary lib?  Sounds like it could be pulled in from extras:\n\nhttps://github.com/openstack/oslo.vmware\n\n \u003e python3-rtslib\n\nCan we added into extras and built from pypi.\n\n \u003e sysfsutils\n \u003e targetcli\n \u003e xfsprogs\n \nThose are probably some run-time dependencies \n\n \u003e Now I\u0027m sure some of these are unnecessary in some environments,\n \u003e but many are not included in nova\u0027s bindep.txt. Should they be\n \u003e added?\n \nIf they are binary run-time dependency, why not?\n\n \u003e Let\u0027s also use a project other than keystone as our example, since\n \u003e most projects have multiple services in a single repo. Should they\n \u003e share an image? Surely at a minimum the entrypoint should differ.\n \u003e \n \u003e bindep.txt applies to the entire repo. Should it contain\n \u003e per-service profiles?\n \u003e \n \u003e I guess my point is that OpenStack does not in general follow the\n \u003e microservice per repo model, nor can you class all of the services\n \u003e as simple web apps.\n\nWe can have multiple targets inside the same Dockerfile, the goal is that all these different targets exist in that image","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"9599e6a3b69f614bf8fb3ba712e6f54bb2e9b1a1","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_588f8a22","line":78,"in_reply_to":"3f4c43b2_72e0a3fb","updated":"2020-04-24 07:45:53.000000000","message":"Totally agree with Mark!\n\nI think the first step would be to determine what bindep.txt means, what profiles should exists for a consistent, across project, behaviour. That\u0027s why I create the containers SIG, because it\u0027s not only a community goal, but a long term maintenance thing. \"Should we have this target/profile?\" -\u003e If yes, modify the bindeps -\u003e Deployment projects can use them.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_0ae4e3ab","line":78,"in_reply_to":"3f4c43b2_72e0a3fb","updated":"2020-04-20 22:06:16.000000000","message":"i think ceph-common is an optional dep when using the ceph imagebackend in nova for the qemu ceph storage driver.\n\ndevice-mapper-multipath i dont think is a direct depency of nova either but is need for multipath iscsic and os-brick\n\ngenisoimage is need for config drive\n\niscsi-initiator-utils needed for os brick wiht iscsi cinder volumes\n\nnfs-utils needed by os-brick\n\nnvme-cli needed by so-brick\n\nopenstack-nova-compute this is nova\n\nopenvswitch used to be needed by os-vif but is still needed by libvirt i 1 edgcase where it plugs interface instead of os-vif\n\n\ne2fsprogs, xfsprogs, parted and python3-libguestfs are both need for resizeing guest image in the libvirt driver. libvirt use libguestfs which uses parted i think.\n\n\npython3-oslo-vmware only need when using the vmware backend\n\n\npython3-rtslib not sure what this is\n\nsysfsutils i think this is ues via the libvirt dirver\n\ntargetcli need when using cinder iscis drviers.\n\n\nso im most of the above the are often need with the defualt nova libvir backend and cinder backedns","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"8a944fbe6936b5bae1ed0acfe3b1b411f47ebe62","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_52ff6700","line":78,"in_reply_to":"3f4c43b2_7712550b","updated":"2020-04-16 19:30:00.000000000","message":"Not that I want to make it a competition, but Ceph containers are equally weird: https://github.com/ceph/ceph-container","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"1988bd62c85aabc4aaf5a488ab58544ef94711cd","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_d23b77ce","line":78,"in_reply_to":"3f4c43b2_7712550b","updated":"2020-04-16 19:33:25.000000000","message":"opendevorg/python-base is based on python:slim - it is 181MB\n\nThe point isn\u0027t that there\u0027s no distro - is that for this context the distro is not the important thing. python-base is an image into which a python application can be installed. the python app is the important thing. Indeed, the app and its depends are pip installed (just like in the gate) - so for those for whom distro specifics are important, these images would not be for them for prod. BUT - they do serve to show a very simple \"this image has one and only one python application in it\" model.\n\nIf people like that but don\u0027t like the pip part - or don\u0027t like the buster part - making an alternate image of the exact same shape would be a pretty easy. For intsance, if we made openstack/keystone based on python-base, it would be python-base + bindep deps + pip depends. If Red Hat or SuSE like the \"this image gives me keystone and only keystone\" single-process image model, they could easily make a redhat/keystone or suse/keystone image that also had a keystone executable but with the software installed via rpm. To the consumer of the image, the consumption of it would be identical.\n\nWhich is all to say - we\u0027ve been out of teh \"make distro packages\" business for about 8 years now. As a result we\u0027ve been firmly in the \"as an upstream we focus on pip and we let the distros focus on doing things that are packaging related as their value add to their customers\" Making some simple images that are in that model - with the same tradeoffs as the pip packages we already publish - could be useful to some people.\n\nFor the same reasons we do not publish rpms or debs of our software, I don\u0027t think we should endeavor to make openstack/keystone:centos and openstack/keystone:opensuse and openstack/keystone:bionic and and and and - because from a single-process container model it does not and should not matter.\n\nObviously we can also choose to not do that.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"d2e5ad5d90fa2ec766da3cf1b7a04abb1042f27a","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_bc3684e6","line":78,"in_reply_to":"3f4c43b2_a3f3070a","updated":"2020-04-16 17:26:38.000000000","message":"\u003e I don\u0027t particularly like this \u0027write off kolla project in a\n \u003e sentence\u0027.\n \nI think we can both agree that Kolla is not \"usual\" Docker images.  They\u0027re very unusual in terms of nature and size, starting from the build process to their very heavy way of functioning.\n\n \u003e I agree with many of Radoslaw\u0027s points. Kolla is certainly unusual\n \u003e in how it builds images, but its approach does have some\n \u003e advantages.\n \u003e \n \u003e It supports different distros, meaning you can maintain one base OS\n \u003e image.\n \nThis is a good feature for Kolla, for those who care about it, they should use Kolla.  These images are going to be:\n\n  FROM python:3\n\nThose will be images that have no specific base distro.\n\n \u003e It supports building from source or distro packages. The latter\n \u003e making it consumable by Tripleo.\n \nI also think this is why Kolla should remain around to do fulfill it\u0027s needs, for those who want to build docker images using distro packaging.  We\u0027re aiming at shipping the equivalent of pypi wheels.\n\n \u003e It provides quite a range of drivers \u0026 plugins out of the box, and\n \u003e if you need any more (which more often than not you will because\n \u003e Openstack), it has a configuration mechanism to add \u0026 remove\n \u003e packages. This seems preferable to maintaining a fork of each\n \u003e project and modifying the dockerfile, or extending the image.\n \nHowever, it\u0027s configuration mechanism brings a lot a lot of kolla-isms, and for the most part, people will just run the service as is.  While we have some unicorns, most of our code is just Python code.  You don\u0027t need to a lot of black magic.\n\n \u003e It can build all images in a single command. While the per-repo\n \u003e approach works well for upstream CI, setting up something similar\n \u003e downstream for every project would be a reasonable undertaking.\n \u003e There are various good reasons for wanting to build images locally.\n \nI think this is something that is more of a delivery issue.  I will go back and stress my pypi wheels idea, it\u0027s up to users to deal with them the way that they want.  If they want to a pre-existing buildset or build infrastructure, Kolla is there.\n\n \u003e Of course it has disadvantages too, as has been mentioned. In\n \u003e particular the images are large. There is a PoC for using\n \u003e multi-stage builds, which can save some space, but only for source\n \u003e images.\n \nGotcha.  Yes, the images are large and I think mainly the lack of `docker build` means the inheritance of all the openstack-y bits that not everyone might be excited to run locally just to build an image (but there will always be those that will).\n\n \u003e If this effort gets traction, the various hurdles discussed are\n \u003e overcome and we end up with images with equivalent functionality to\n \u003e kolla\u0027s, I\u0027d be happy to reduce some maintenance burden.\n \nAbsolutely, I think that where we get a lot of benefit in this case is the improvement of \u0027extras\u0027 inside our setup.cfg\u0027s, the improvement of our bindep.txt which you could rely on when building your images as well.\n\n \u003e Ultimately though, I doubt that the inability to run \u0027docker build\n \u003e .\u0027 is really a blocker for many.\n\nI think it is to an extent, the more we simplify things and make them feel like \"any other open source projects\", the more likely we can increase our adoption.  The more we introduced our own systems onto others, the less likely they\u0027ll want to take a bite out of them.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"fbc4fca37684ef655fdd537ac24a8fcac15647fe","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_0a77c33c","line":78,"in_reply_to":"3f4c43b2_b6ff9fff","updated":"2020-04-20 19:53:45.000000000","message":"\u003e I have a feeling that you never tried to build an image where each\n \u003e Python module needs to be built from source. Try one day. Wait for\n \u003e grpcio, numpy, scipy and all those fancy Python packages which need\n \u003e to be built on all !x86 architectures.\n\nI have had the blessing of PTL-ing OpenStack Ansible that does exactly this.  We don\u0027t have to build everything from scratch, as we can just download the wheels that we need if they\u0027re published.  As a fact, OSA builds all OpenStack projects from source.\n\n \u003e Or that mess called \u0027package dependencies\u0027 (including which\n \u003e \u0027recommended\u0027 packages needs to be installed for your case).\n\nIn this case, similar dealing with OSA, and we disable recommended packages in the base image too when building.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"01694d3897858d32c8b427439f4c0bc5e14ecbb2","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_7712550b","line":78,"in_reply_to":"3f4c43b2_bc3684e6","updated":"2020-04-16 18:40:40.000000000","message":"I was curious about the python:3 image. It\u0027s 933MB! That\u0027s bigger than most kolla images.\n\nAnd of course it has a distro - it\u0027s Debian buster. There are other tags with different distros available:\n\nhttps://hub.docker.com/_/python","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":30491,"name":"Radosław Piliszek","display_name":"Radek","email":"radek@piliszek.it","username":"yoctozepto","status":"self-employed techologist, collaborating mostly with 7bulls.com"},"change_message_id":"79a41f96ae7ad00b445f529583a67c1b5d175474","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_5092c74c","line":78,"in_reply_to":"3f4c43b2_cd08042f","updated":"2020-04-16 14:52:37.000000000","message":"\u003e Indeed, the common-base does help but it makes the Kolla images\n \u003e very unique to Kolla only and special in their way.  Also, the\n \u003e build tools being inside is something we\u0027d like to avoid from the\n \u003e perspective of making those images lighter.\n\nAgreed. The building tools is my primary concern. Common base, as OpenStack is a common effort, actually makes sense, so I would not rule it out entirely.\n\n \u003e The thing is I don\u0027t want us to focus on providing images for all\n \u003e services alongside a deployment tool for it, the goal is to ship\n \u003e images for OpenStack, nothing more.\n\nYeah, I got that. But they should be good enough to run basic scenarios. Otherwise it is art for art. I am pretty sure you already plan this for a multi-cycle megagoal but I don\u0027t find it mentioned here.\n\n \u003e The goal here is focusing on using the base Python image provided\n \u003e by DockerHub (library/python) more specifically.  We do not intend\n \u003e to start shipping per-operating-system images.\n\nOK, that makes it clear, could be mentioned directly.\n\n \u003e However, the idea is that the Dockerfile should be easy for a\n \u003e down-stream distro shipper to create a similar Dockerfile as long\n \u003e as it has the same entrypoint (if they want to use debs or rpms).\n\nWell, if we make it a plain Dockerfile, then it\u0027s just a source of inspiration. Still better than none.\n\n \u003e The problem with the Kolla images is that you can\u0027t just do:\n \u003e \n \u003e docker build .\n \u003e \n \u003e That\u0027s a problem, the fact that you\u0027re asking someone to install a\n \u003e whole bunch of dependnecies that are based on Python which pull\n \u003e other things \"just to build an image\" does not seem like it\u0027s the\n \u003e right way.  The \"normal way\" that things work is that Dockerfile\u0027s\n \u003e live inside the repository, that\u0027s the way it works everywhere,\n \u003e let\u0027s not be a unicorn..\n\nValid point. Under no-python assumption this is very important but see discussion at the bottom.\n\n \u003e This doesn\u0027t actually cater for standalone, someone can mesh all of\n \u003e these, we may even decide to even make a container-image mode of\n \u003e DevStack, the idea isn\u0027t to provide deployment tooling, but just an\n \u003e image.  Think how we upload PyPI images.\n\nYeah, I got that. I mentioned standalone because of no sharing assumption being made here.\n\n \u003e I think we will be able to work through theseout, I think the issue\n \u003e of extra plugins in someting that has been actually solved as these\n \u003e images will automatically install everything that\u0027s inside extras,\n \u003e the idea is to have one-service-per-container, not launching\n \u003e multiple in a single one.\n\nThis is another point against completely static Dockerfile. It limits flexibility (or put bluntly - it has none). What if we made some tooling based on providing proper metadata to actually generate the Dockerfile. Dockerfiles could be lying pregenerated in repos (just like etc files sometimes do).\n\n \u003e I don\u0027t think that this is an effort that will go in vain, I think\n \u003e this is a net positive, the biggest reason we don\u0027t have in-repo\n \u003e Dockerfile\u0027s made it seem never \u0027official\u0027, we also didn\u0027t have the\n \u003e system that are being used by others like OpenDev.\n\nTrue that but let\u0027s seriously avoid images for images. Let this goal assume some applicability of them as an important part of success.\n\n \u003e If we ditch the Dockerfile format makes it even worse, I know we\n \u003e want to build cool things using new tools, but peple want to just\n \u003e run `docker build` .. we can do these other things orthogonally, I\n \u003e agree, but our basic fundamental images should be built as easily\n \u003e as possible\n\nPeople ARE running away from Dockerfiles (not massively but still), so it\u0027s not something that would be frowned upon. That said, this way one must assume some baseline tooling available for image building. Also, if we provide prebuilt images then interested parties can just consume them - if they are interested more, they can grab the tools to build. I am just trying to think long-term. Maybe it\u0027s an overkill, my mind is just wired weirdly. ;-)\n\nLet\u0027s think BIG.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":14826,"name":"Mark Goddard","email":"markgoddard86@gmail.com","username":"mgoddard"},"change_message_id":"1b54995e2b9f4d6c434e7bc0f96fdbddf57e3fbe","unresolved":false,"context_lines":[{"line_number":75,"context_line":"* **Kolla**: Kolla creates very heavy containers, similar to system containers"},{"line_number":76,"context_line":"  and it need custom tooling in order to generate the ``Dockerfile`` which is"},{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f4c43b2_72e0a3fb","line":78,"in_reply_to":"3f4c43b2_d23b77ce","updated":"2020-04-16 20:00:06.000000000","message":"Let me pick a more concrete example. The kolla nova-compute container installs the following RPMs on RHEL distros:\n\nceph-common\ndevice-mapper-multipath\ne2fsprogs\ngenisoimage\niscsi-initiator-utils\nnfs-utils\nnvme-cli\nopenstack-nova-compute\nopenvswitch\nparted\npython3-libguestfs\npython3-oslo-vmware\npython3-rtslib\nsysfsutils\ntargetcli\nxfsprogs\n\nNow I\u0027m sure some of these are unnecessary in some environments, but many are not included in nova\u0027s bindep.txt. Should they be added?\n\nLet\u0027s also use a project other than keystone as our example, since most projects have multiple services in a single repo. Should they share an image? Surely at a minimum the entrypoint should differ.\n\nbindep.txt applies to the entire repo. Should it contain per-service profiles?\n\nI guess my point is that OpenStack does not in general follow the microservice per repo model, nor can you class all of the services as simple web apps.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a4d546f80f7e50c9f669a02ebeb1582795969b2","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"},{"line_number":82,"context_line":"multi-stage builds and the work done by the Zuul team to support speculative"},{"line_number":83,"context_line":"image jobs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_50369ab6","line":83,"range":{"start_line":80,"start_character":0,"end_line":83,"end_character":11},"updated":"2020-04-20 22:06:16.000000000","message":"i think both zuul teams and kolla temas have had different\ndesign requirements and one is not nessacialy better then the other.\n\nas far back as 2017 we did some experiment with replaceing kolla build system remove docker build and instead build with python allowing removing build deps https://review.opendev.org/#/c/503882/\n\nthis can now be be done with a multi stage build but it did not significantly speed up the gate so we never continued with that but i rememeber hacking on that with ian well at the ptg when we were disucssion creting a dsl for kolla instead fo jusing jinja2 to generate docker files.\n\nspecultie image building could be done using kollas build system as in souce mode you can just provide a git url and ca comit/branc/tag so it would not be hard to make it work with gerrit.\n\nalternively if zuul premerges the repos you can just poing kolla-build to use those local git repos.","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"},{"author":{"_account_id":1004,"name":"Mohammed Naser","email":"mnaser@vexxhost.com","username":"mnaser"},"change_message_id":"65f6cbe095e53c30c9a04995f5a18b03e0827685","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  then fed into the ``docker build`` command, making it not very simple for"},{"line_number":78,"context_line":"  usage."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"It\u0027s important to note that these projects were created in a time where many"},{"line_number":81,"context_line":"of the features we have access to today did not exist back then, such as"},{"line_number":82,"context_line":"multi-stage builds and the work done by the Zuul team to support speculative"},{"line_number":83,"context_line":"image jobs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1f493fa4_d6e9f880","line":83,"range":{"start_line":80,"start_character":0,"end_line":83,"end_character":11},"in_reply_to":"1f493fa4_50369ab6","updated":"2020-04-21 13:14:48.000000000","message":"It\u0027s a lot more than this, I\u0027ll try to find a good doc about this...","commit_id":"748d44ead3edc8de7017fdd0c7d5dec9d8e8c1ea"}]}