Re: [openstack-dev] [Fuel] version.yaml in the context of packages
2) production - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. This gets set to docker-build during fuel ISO creation because several tasks cannot be done in the containers during docker build phase. We can replace this by moving it to astute.yaml easily enough. 4) openstack_version - It is just an extraction from openstack.yaml [2]. Without installing nailgun, it's impossible to know what the repo directories should be. Abstracting it buried in some other package makes puppet tasks laborious. Keeping it in a YAML allows it to be accessible. The rest won't impact Fuel Master deployment significantly. On Fri, Jul 24, 2015 at 8:21 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) feature_groups - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. 2) production - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. 3) release - It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) openstack_version - It is just an extraction from openstack.yaml [2]. 5) api - It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) build_number and build_id - These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. 7) X_sha - This does not even require any explanation. It should be rpm -qa instead. I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
Vladimir, 2015-07-24 20:21 GMT+03:00 Vladimir Kozhukalov vkozhuka...@mirantis.com: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This parameter must be available in nailgun - there is code in nailgun and UI which relies on this parameter. 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. This parameter can be set to other values when used for fake UI and functional tests for UI and fuelclient. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. It is shown on UI. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
Vitaly, 1) feature_groups - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This parameter must be available in nailgun - there is code in nailgun and UI which relies on this parameter. Sure it must, but since it is runtime parameter, it should be defined in a config file, which is to be a part of rpm package. Let's say it will be /etc/sysconfig/fuel. 2) production - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. This parameter can be set to other values when used for fake UI and functional tests for UI and fuelclient. If so, then it is also runtime parameter and it should be moved into a config file. Again /etc/sysconfig/fuel seems fine. 3) release - It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. It is shown on UI. It is version of this package https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec Again let's put it into /etc/sysconfig/fuel. Matt, 4) openstack_version - It is just an extraction from openstack.yaml [2]. Without installing nailgun, it's impossible to know what the repo directories should be. Abstracting it buried in some other package makes puppet tasks laborious. Keeping it in a YAML allows it to be accessible. I think we can put openstack.yaml into a separate package. Other packages (including nailgun) will require this package. Andrew, 6) build_number and build_id - These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons Yes, we can copy it from the iso to /etc/fuel-build or something like this. 7) X_sha - This does not even require any explanation. It should be rpm -qa instead. We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place We certainly need to substitute it with rpm package versions. As far as I know we have plans to append sha to the name of a package. Something like this fuel-7.0.0-1.mos6065-a38b34.noarch.rpm will be fine. Ok, I think no one is against of deprecating this file and moving some parameters into package related files. I'll describe this in details in a spec. Vladimir Kozhukalov On Mon, Jul 27, 2015 at 1:57 PM, Matthew Mosesohn mmoses...@mirantis.com wrote: 2) production - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. This gets set to docker-build during fuel ISO creation because several tasks cannot be done in the containers during docker build phase. We can replace this by moving it to astute.yaml easily enough. 4) openstack_version - It is just an extraction from openstack.yaml [2]. Without installing nailgun, it's impossible to know what the repo directories should be. Abstracting it buried in some other package makes puppet tasks laborious. Keeping it in a YAML allows it to be accessible. The rest won't impact Fuel Master deployment significantly. On Fri, Jul 24, 2015 at 8:21 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca
[openstack-dev] [Fuel] version.yaml in the context of packages
Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
It looks like /etc/issue + an extraction from rpm db. On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward xar...@gmail.com wrote: Vladimir, I agree that the content of this file nearly completely depreciated, but slightly disagree with removing it entirely. I think the data should be moved from a single static file like you see here, to something that reads the data from the underlying packages and can still show all of the information in one place (/api/version). So we can, and should do away with this file but we need the data in the api response, and saved in the diag snapshot. So my comments below are about possibly keeping these around, but not in the file On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This should just be expressed as a value in the DB, it never made sense to store this in a file since it's runtime state 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. there is no longer not docker, so just drop it. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
Vladimir, I agree that the content of this file nearly completely depreciated, but slightly disagree with removing it entirely. I think the data should be moved from a single static file like you see here, to something that reads the data from the underlying packages and can still show all of the information in one place (/api/version). So we can, and should do away with this file but we need the data in the api response, and saved in the diag snapshot. So my comments below are about possibly keeping these around, but not in the file On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, Although we are focused on fixing bugs during next few weeks I still have to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file when all-inclusive ISO image was the only way of delivering Fuel. We had to have somewhere the information about SHA commits for all Fuel related git repos. But everything is changing and we are close to flexible package based delivery approach. And this file is becoming kinda fifth wheel. Here is how version.yaml looks like VERSION: feature_groups: - mirantis production: docker release: 7.0 openstack_version: 2015.1.0-7.0 api: 1.0 build_number: 82 build_id: 2015-07-23_10-59-34 nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113 python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1 astute_sha: b1f37a988e097175cbbd14338286017b46b584c3 fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4 fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39 Let's go through this file. 1) *feature_groups* - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file. This should just be expressed as a value in the DB, it never made sense to store this in a file since it's runtime state 2) *production* - It is always equal to docker which means we deploy docker containers on the master node. Formally it comes from one of fuel-main variables, which is set into docker by default, but not a single job in CI customizes this variable. Looks like it makes no sense to have this. there is no longer not docker, so just drop it. 3) *release *- It is the number of Fuel release. Frankly, don't need this because it is nothing more than the version of fuel meta package [1]. 4) *openstack_version *- It is just an extraction from openstack.yaml [2]. 5) *api *- It is 1.0 currently. And we still don't have other versions of API. Frankly, it contradicts to the common practice to make several different versions available at the same time. And a user should be able to ask API which versions are currently available. 6) *build_number *and *build_id *- These are the only parameters that relate to the build process. But let's think if we actually need these parameters if we switch to package based approach. RPM/DEB repositories are going to become the main way of delivering Fuel, not ISO. So, it also makes little sense to put store them, especially if we upgrade some of the packages. These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons 7) *X_sha* - This does not even require any explanation. It should be rpm -qa instead. We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place I am raising this topic, because it is kind of blocker for switching to package based upgrades. Our current upgrade script assumes we have this file version.yaml in the tarball and we put this new file instead of old one during upgrade. But this file could not be packaged into rpm because it can only be built together with ISO. [1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
