<div dir="ltr"><div>Vitaly, </div><div><br></div><div>>>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.</div><div>>This parameter must be available in nailgun - there is code in nailgun and UI which relies on this parameter.</div><div><br></div><div>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.</div><div><br></div><div>>>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.</div><div>>This parameter can be set to other values when used for fake UI and functional tests for UI and fuelclient. </div><div><br></div><div>If so, then it is also runtime parameter and it should be moved into a config file. Again /etc/sysconfig/fuel seems fine.</div><div><br></div><div>>>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].</div><div>>It is shown on UI.</div><div><br></div><div>It is version of this package <a href="https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec">https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec</a> Again let's put it into /etc/sysconfig/fuel.</div><div><br></div><div>Matt, </div><div><br></div><div><div>>> 4) openstack_version - It is just an extraction from openstack.yaml [2].</div><div>>Without installing nailgun, it's impossible to know what the repo</div><div>>directories should be. Abstracting it buried in some other package</div><div>>makes puppet tasks laborious. Keeping it in a YAML allows it to be</div><div>>accessible.</div></div><div><br></div><div>I think we can put openstack.yaml into a separate package. Other packages (including nailgun) will require this package.</div><div><br></div><div>Andrew,</div><div><br></div><div><div>>>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.</div><div>>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 </div><div><br></div><div>Yes, we can copy it from the iso to /etc/fuel-build or something like this.</div><div><br></div><div>>>7) X_sha - This does not even require any explanation. It should be rpm -qa instead.</div><div>>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 </div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Mon, Jul 27, 2015 at 1:57 PM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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.<br>
</span>This gets set to docker-build during fuel ISO creation because several<br>
tasks cannot be done in the containers during "docker build" phase. We<br>
can replace this by moving it to astute.yaml easily enough.<br>
<span class="">> 4) openstack_version - It is just an extraction from openstack.yaml [2].<br>
</span>Without installing nailgun, it's impossible to know what the repo<br>
directories should be. Abstracting it buried in some other package<br>
makes puppet tasks laborious. Keeping it in a YAML allows it to be<br>
accessible.<br>
<br>
The rest won't impact Fuel Master deployment significantly.<br>
<div><div class="h5"><br>
On Fri, Jul 24, 2015 at 8:21 PM, Vladimir Kozhukalov<br>
<<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br>
> Dear colleagues,<br>
><br>
> Although we are focused on fixing bugs during next few weeks I still have to<br>
> ask everyone's opinion about /etc/fuel/version.yaml. We introduced this file<br>
> when all-inclusive ISO image was the only way of delivering Fuel. We had to<br>
> have somewhere the information about SHA commits for all Fuel related git<br>
> repos. But everything is changing and we are close to flexible package based<br>
> delivery approach. And this file is becoming kinda fifth wheel.<br>
><br>
> Here is how version.yaml looks like<br>
><br>
> VERSION:<br>
> feature_groups:<br>
> - mirantis<br>
> production: "docker"<br>
> release: "7.0"<br>
> openstack_version: "2015.1.0-7.0"<br>
> api: "1.0"<br>
> build_number: "82"<br>
> build_id: "2015-07-23_10-59-34"<br>
> nailgun_sha: "d1087923e45b0e6d946ce48cb05a71733e1ac113"<br>
> python-fuelclient_sha: "471948c26a8c45c091c5593e54e6727405136eca"<br>
> fuel-agent_sha: "bc25d3b728e823e6154bac0442f6b88747ac48e1"<br>
> astute_sha: "b1f37a988e097175cbbd14338286017b46b584c3"<br>
> fuel-library_sha: "58d94955479aee4b09c2b658d90f57083e668ce4"<br>
> fuel-ostf_sha: "94a483c8aba639be3b96616c1396ef290dcc00cd"<br>
> fuelmain_sha: "68871248453b432ecca0cca5a43ef0aad6079c39"<br>
><br>
><br>
> Let's go through this file.<br>
><br>
> 1) feature_groups - This is, in fact, runtime parameter rather then build<br>
> one, so we'd better store it in astute.yaml or other runtime config file.<br>
> 2) production - It is always equal to "docker" which means we deploy docker<br>
> containers on the master node. Formally it comes from one of fuel-main<br>
> variables, which is set into "docker" by default, but not a single job in CI<br>
> customizes this variable. Looks like it makes no sense to have this.<br>
> 3) release - It is the number of Fuel release. Frankly, don't need this<br>
> because it is nothing more than the version of fuel meta package [1].<br>
> 4) openstack_version - It is just an extraction from openstack.yaml [2].<br>
> 5) api - It is 1.0 currently. And we still don't have other versions of API.<br>
> Frankly, it contradicts to the common practice to make several different<br>
> versions available at the same time. And a user should be able to ask API<br>
> which versions are currently available.<br>
> 6) build_number and build_id - These are the only parameters that relate to<br>
> the build process. But let's think if we actually need these parameters if<br>
> we switch to package based approach. RPM/DEB repositories are going to<br>
> become the main way of delivering Fuel, not ISO. So, it also makes little<br>
> sense to put store them, especially if we upgrade some of the packages.<br>
> 7) X_sha - This does not even require any explanation. It should be rpm -qa<br>
> instead.<br>
><br>
> I am raising this topic, because it is kind of blocker for switching to<br>
> package based upgrades. Our current upgrade script assumes we have this file<br>
> version.yaml in the tarball and we put this new file instead of old one<br>
> during upgrade. But this file could not be packaged into rpm because it can<br>
> only be built together with ISO.<br>
><br>
><br>
> [1] <a href="https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec" rel="noreferrer" target="_blank">https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec</a><br>
</div></div>> [2]<br>
<span class="">> <a href="https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml" rel="noreferrer" target="_blank">https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml</a><br>
><br>
> Vladimir Kozhukalov<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
</span>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<span class="">><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
</span>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>