focher
04-14-2008, 05:29 PM
Hi,
I don't think this classifies as a bug, but maybe this scenario can be developed around to avoid in the future. Essentially, when making a custom class you can potentially run into the issue that the network configuration is incorrect until you move the custom class back into the catalog and rebuild the boot volumes of the components.
If you do the following:
1) Create an application with a LUX5 appliance along with IN and OUT / NET components.
2) Save the application.
3) Build the application (app build app_name). The creates the boot volumes, among other things.
4) Edit the application and Branch the LUX5 class.
5) Delete the OUT / NET component and then add it back. This is what seems to corrupt the network configuration of the application.
6) Start the application.
The network configuration is now incorrect. In my scenario, the /etc/resolv.conf showed a nameserver that was different than the IP address of the NET component. I guess the initial build in step #3 had a different dynamic network configuration between the appliances and this was "corrupted" by step #5. In fact, the whole routing between the appliances doesn't work anymore.
The fix is to move the LUX5 appliance back into the catalog then issue an app rebuild app_name. This will rebuild the boot volume for the custom appliance and correct the network configuration.
Granted, this is an unusual scenario. However, I am left wondering if there is a method (or maybe a feature to add in the future) to force a rebuild of the boot volume(s) when the class is branched but not moved back yet to the catalog.
I don't think this classifies as a bug, but maybe this scenario can be developed around to avoid in the future. Essentially, when making a custom class you can potentially run into the issue that the network configuration is incorrect until you move the custom class back into the catalog and rebuild the boot volumes of the components.
If you do the following:
1) Create an application with a LUX5 appliance along with IN and OUT / NET components.
2) Save the application.
3) Build the application (app build app_name). The creates the boot volumes, among other things.
4) Edit the application and Branch the LUX5 class.
5) Delete the OUT / NET component and then add it back. This is what seems to corrupt the network configuration of the application.
6) Start the application.
The network configuration is now incorrect. In my scenario, the /etc/resolv.conf showed a nameserver that was different than the IP address of the NET component. I guess the initial build in step #3 had a different dynamic network configuration between the appliances and this was "corrupted" by step #5. In fact, the whole routing between the appliances doesn't work anymore.
The fix is to move the LUX5 appliance back into the catalog then issue an app rebuild app_name. This will rebuild the boot volume for the custom appliance and correct the network configuration.
Granted, this is an unusual scenario. However, I am left wondering if there is a method (or maybe a feature to add in the future) to force a rebuild of the boot volume(s) when the class is branched but not moved back yet to the catalog.