VERSION:
mirantis: "yes"
production: "docker"
release: "5.0"
build_number: "155"
build_id: "2014-04-29_01-00-26"
astute_sha: "3cffebde1e5452f5dbf8f744c6525fc36c7afbf3"
api: "1.0"
fuellib_sha: "68b11620e7b0d42eafde375ef4992cadc8b0d10e"
api: "1.0"
ostf_sha: "134765fcb5a07dce0cd1bb399b2290c988c3c63b"
api: "1.0"
nailgun_sha: "43fdef4393e64a7c23df844a11ad3f8fc820283b"
api: "1.0"
fuelmain_sha: "b33adfc3a17377415bf0fc80b7b8419fc5fb7176"
Steps to Reproduce:
1. Start deploy of master node with ip ranges differ from 10.20.0.0/24(I use our system tests - sow it was 10.108.0.0/24)
2. Enter to the fuel menu
3. Do not change data and just leave it without saving
4. When deploy finish looking for service state(nailgun/ ostf etc)
5. look at the /etc/astute.yaml, /etc/fuel/astute.yaml and one astute.yaml from conteiner
6. reqquest ip a to see net on node
7. Look at the bootstrap_admin_node log
Actual result:
1. success
2. success
3. Deploy of master node finishes but naigun, ostf failed to start with message that it could not connect to DB
4. look athe astude files and there appears wrong data about admin network
ADMIN_NETWORK:
interface: "eth0"
ipaddress: "10.20.0.2"
netmask: "255.255.255.0"
cidr: "10.20.0.0/24"
size: "256"
static_pool_start: "10.20.0.10"
static_pool_end: "10.20.0.120"
dhcp_pool_start: "10.20.0.130"
dhcp_pool_end: "10.20.0.254"
But currently net info should looks like:
[root@nailgun log]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 64:ff:8f:cb:d0:d6 brd ff:ff:ff:ff:ff:ff
inet 10.108.0.2/24 brd 10.108.0.255 scope global eth0
inet6 fe80::66ff:8fff:fecb:d0d6/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 64:3e:c5:a3:5a:38 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 64:5e:7a:63:b2:39 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 64:7b:c0:c7:20:a8 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 64:fa:26:16:32:d4 brd ff:ff:ff:ff:ff:ff
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether fe:11:b4:50:9f:f8 brd ff:ff:ff:ff:ff:ff
inet 172.17.42.1/16 scope global docker0
inet6 fe80::803a:a4ff:fe6a:705/64 scope link
If we run deploy without entering in fuel menu astute data looks fine and service start without problems
Tatyana, it looks like you've hit an edge case that is hard to combat:
1 - User modified default fuel network values in grub
2 - User did not skip fuelmenu (if you skip, it generates new config and saves it)
3 - User entered fuelmenu but didn't save (therefore fuelmenu didn't generate new astute.yaml)
You're seeing the default astute.yaml that is provided by fuelmenu RPM, so no new file is being generated at any point. How do you propose we avoid this? Exit without saving and force the user to acknowledge that their settings aren't saved and deployment will fail? Or we could add a 5s delay by doing a fuelmenu --saveonly as a precaution first, then run fuelmenu.
Others, feel free to let me know which option (or a new one) would be well met by our users?