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 i
> 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 t
Vladimir,
2015-07-24 20:21 GMT+03:00 Vladimir Kozhukalov :
> 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 deliveri
It looks like /etc/issue + an extraction from rpm db.
On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward 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
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
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 fo
