[Bug 1271144] Re: br0 not brought up by cloud-init script with MAAS provider
Thanks for the reply. I'm willing to try anything that is recommended. The primary NIC on Trusty come up as em1, not eth0. Therefore, I've been assuming that the fix for #1337091 will, at least, be required to address this issue. Whether it will be sufficient is an open question, but I'm skeptical for the reasons explained in comment #32. Note that #1337091 is targeted to 1.21 alpha and is apparently unreleased. So #1337091 would not be included in 1.20.1 would it? If that's the case, I think it is unlikely that 1.20.1 will work. That said, I'm still willing to try it. Version 1.20.1 is not a version I've heard of before. Is it available now? Where can I get it and how can I install it? Thanks! -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to juju-core in Ubuntu. https://bugs.launchpad.net/bugs/1271144 Title: br0 not brought up by cloud-init script with MAAS provider To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1271144/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1271144] Re: br0 not brought up by cloud-init script with MAAS provider
There has been a lot of activity on this bug with more than one issue involved and so I just wanted to confirm: This problem still exists with maas 1.5.2+bzr2282 and juju 1.18.1 (the current stable releases) when you bootstrap a node with trusty. Therefore, it breaks Canonical's OpenStack "Golden Happy Path". What I mean by that is, if you went to Canonical's web site and followed the instructions for deploying OpenStack using the latest stable, updated software (trusty, maas, and juju), then you will fail due to this bug. Right? Or is there anyone out there who is able to bootstrap juju correctly (br0 comes up) on Trusty via MaaS right now with the latest software? Also, it's very difficult to know what software component is at fault so you can report the problem or look for existing bugs. Even if you guessed it was juju, this bug doesn't even show up on the default list of bugs because it's marked "Fix Released" as it primary status. BTW, I doubt that the fix for #1337091 will fix this issue with trusty because even if I force my new trusy NIC names (em1, etc) back to eth0 using biosdevname=0 boot option and manually configure /etc/network/interfaces and reboot, then br0 is still not brought up when it should. The result is that cloud-init-nonet complains about the network not being up. Note that immediately after cloud-init-nonet gives up, ifup -a is run (by whom is a total mystery as the parent process is 1) and then br0 finally comes up but its too late. I tried to debug the problem but I cannot find any documentation as to what the boot sequence for networking is supposed to be when juju/cloud- init is involved. I notice that some hardware interfaces are brought up due to udev events, but the software bridges are not brought up until later. I guess that's why the cloud init scripts try to bring up br0 on their own. Except its not happening. Are the cloud-init scripts supposed to bring up br0 on every boot or just after the first boot when it munges the network config? Since this bug involves different issues, it's not clear whether anyone is still working on this (the Trusty target is Unassigned) or is even aware that a problem still exists. For all these reasons, this bug is very frustrating. It would be very helpful if someone could provide status as to what is being or will been done to resolve it. If folks are still not convinced that a real problem is still outstanding, I have equipment and time and can provide whatever information and will follow whatever instructions are necessary to change their minds. If I've done something wrong, I'm eager to determine what it was. Also, if it is unreasonable to expect 14.04 deployments to work anytime soon, please let me know and I'll go back to deploying 12.04 for now. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to juju-core in Ubuntu. https://bugs.launchpad.net/bugs/1271144 Title: br0 not brought up by cloud-init script with MAAS provider To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1271144/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1321885] Re: IMPI detection and automatic setting fail in ubuntu 14.4 maas
Please fix the typos in the title of this bug (IMPI/IPMI and 14.4/14.04); they make it hard to find. The root cause of this issue is that a least one type of BMC does not report back at least one setting (Enable_User) that has been configured correctly. This was not a problem in 12.04 because earlier versions of maas do not attempt to verify that the BMC settings have been set correctly after configuring them. Previously, it just set the values and moved on. Now that the maas_ipmi_autodetect.py code attempts to read back the values, it is failing, even though the correct values appear to be in effect. This issue is affecting Dell PowerEdge SC1435 and Dell 2970 models and probably others that use the same BMC. Note that these are fairly popular models. This was reproduced on a Dell SC1435 with 2.2.5 BIOS, which I believe is the latest. This is reproducable on multiple machines. Other Dell models (710s and 620s) do not exhibit this issue. Here is an example on an SC1435: manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User1:Username Section User1 ## Give Username ## Username NULL EndSection manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User2:Username Section User2 ## Give Username Username root EndSection manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User3:Username Section User3 ## Give Username Username maas EndSection manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User2:Enable_User Section User2 ## Possible values: Yes/No or blank to not set ## Enable_User EndSection manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User3:Enable_User Section User3 ## Possible values: Yes/No or blank to not set ## Enable_User EndSection manager@maas-ctrl-2:~$ sudo bmc-config --commit --key-pair="User2:Enable_User=Yes" manager@maas-ctrl-2:~$ sudo bmc-config --checkout --key-pair=User2:Enable_User Section User2 ## Possible values: Yes/No or blank to not set ## Enable_User EndSection manager@maas-ctrl-2:~$ Note that if you disable the verification by commenting it out, then everything works fine. Steps to perform the workaround on the maas server: sudo vi /etc/maas/templates/commissioning-user- data/snippets/maas_ipmi_autodetect.py Change this function to comment out the last line as shown: def apply_ipmi_user_settings(user_settings): """Commit and verify IPMI user settings.""" username = user_settings['Username'] ipmi_user_number = pick_user_number(username) for key, value in user_settings.iteritems(): bmc_user_set(ipmi_user_number, key, value) #verify_ipmi_user_settings(ipmi_user_number, user_settings) While it seems clear the BMC should return the proper values, even if that got fixed (which I'll guess won't happen anytime soon), upgrading IPMI firmware is not an easy task for the casual user with Dell machines. See http://www.yellow-bricks.com/2011/06/27/dell-firmware-updates. Therefore, please consider this a request for MaaS to work with this behavior. Perhaps the verification should be disabled by default or that the BMC model be detected beforehand to determine (perhaps against a blacklist) whether verification should be attempted. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openipmi in Ubuntu. https://bugs.launchpad.net/bugs/1321885 Title: IMPI detection and automatic setting fail in ubuntu 14.4 maas To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1321885/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
