#maas 2013-03-04
<roaksoax> allenap: ping
#maas 2013-03-05
<roaksoax> allenap: howdy!! so the cluster_host thing didn't really work unfortunately :(
<allenap> roaksoax: Hi there. Because of the get_managed_interface() thing?
<roaksoax> allenap: yeah, it wont get the address of the cluster
<allenap> roaksoax: Look at the implementation of get_managed_interface(). You can use a similar approach to getting the address of the cluster, i.e. get any interface of the cluster.
<roaksoax> allenap: right, but the thing is that it seems that if we are not managing any interface, it wont return the address
<roaksoax> allenap: so from what I udnerstood, if we dont configure DHCP/DNS, then it wont return the address
<roaksoax> but we still need itr
<roaksoax> regardless of whether we manage it or not
<allenap> roaksoax: http://pastebin.ubuntu.com/5588071/
<roaksoax> allenap: ack, i'll look into that
<allenap> roaksoax: Yeah, get_managed_interface() won't work then, but I meant for you to follow its approach. Afaik, all interfaces are recorded.
<roaksoax> allenap: yeah, the difficulty is finding out what interface it PXE booted from
<roaksoax> allenap: but the difficulty is really finding out what interface it PXE booted from.
<roaksoax> allenap: and thanks btw :)
<allenap> roaksoax: Okay, so I could update lp:~allenap/maas/preseed-cluster-host to find an interface on the cluster that's on the same network as the node. I guess that would be better?
<roaksoax> bigjools: let me know when around :)
<bigjools> roaksoax: o/
<roaksoax> bigjools: howdy!! so I think i found an issue with maas and nodegroups :(
<bigjools> go on ...
<roaksoax> bigjools: so while trying to work on the cluster_host thing, I first did this:http://pastebin.ubuntu.com/5589024/ to basically obtain all the interfaces of a cluster, instead of the 'managed' interface
<roaksoax> (extending what allenap did)
<bigjools> roaksoax: that won't do that
<bigjools> it's returning the first
<roaksoax> bigjools: right :)
<roaksoax> bigjools: i guess I should have said get any of the interfaces
<bigjools> there's a better way of doing it as well :)
<bigjools> but go on
<roaksoax> bigjools: but anyways, that's not really the issue though
<roaksoax> bigjools: the thing is that I installed 2 cluster controllers
<roaksoax> one in the region, and one external
<roaksoax> 1 first enlisted/commissioned node01 with external cluster in 192.168.123.3. Then node02 with local (in region) cluster in 192.168.123.2
<roaksoax> bigjools: and then I noticed this: http://pastebin.ubuntu.com/5589031/
<roaksoax> bigjools: both nodes seem to be in the same nodegroup, when they enlisted/commissioned in a different nodegroup
<roaksoax> bigjools: note that the local cluster running in the region was registered to maas *after* the external
<roaksoax> but I;ve tested the other way around (local cluster registered first, then external), and the adddress returned there is 192.168.123.2.
<bigjools> let me lool, I think your code is buggy
<bigjools> look
<roaksoax> this leads me to believe that all nodes are said to belong to the same nodegroup
<bigjools> check in the DB
<roaksoax> bigjools: http://pastebin.ubuntu.com/5589038/
<roaksoax> bigjools: unless my logic is incorrect, how else would I check to what nodegroup the node belogs to
<bigjools> hmmm
<roaksoax> bigjools: this is what I did to get the cluster_host btw: http://paste.ubuntu.com/5589041/ (in get_node_preseed_context)
<bigjools> roaksoax: multi clusters were tested in the lab and worked ok, so either something regressed recently or your setup is not doing what you think it is
<bigjools> are you sure your nodes are on separate lans?
<bigjools> and cluster controllers
<roaksoax> bigjools: my nodes are in the same lan, but they do register themselves with a different cluster controller. I tell it where to PXE boot from so I know they are pxe booting from different clusters
<bigjools> roaksoax: are you sure? :)
<roaksoax> bigjools: 100%. It is a controlled environment and DHCP is managed by libvirt, which tells it where to pxe boot from
<roaksoax> let me re-test
<bigjools> roaksoax: if you disable the DHCP that you think it is using, does it still boot?
<roaksoax> bigjools: nope
<bigjools> ok
<roaksoax> bigjools: it is a clean environment with no DNS/DHCP being managed by maas
<roaksoax> nor dhcp is running in any nore
<bigjools> roaksoax: ok file a bug
<bigjools> not sure we'll get to it right away quite frankly
<roaksoax> right
<roaksoax> this does affect the FPI though
<bigjools> we're getting the FPI done
<bigjools> roaksoax: what's the cutoff for raring?
<roaksoax> bigjools: FF is this thursday :)
<bigjools> yay
<bigjools> when you say "final" ...
<roaksoax> bigjools: so I'm planning on uploading and then just doing FFe's for what's important
<roaksoax> bigjools: so yeah we have like 1 extra month to request FFe;s
<bigjools> ok
#maas 2013-03-06
<shang> bigjools: ping
<roaksoax> win 18
<roaksoax> rvba: howdy!!
<rvba> roaksoax: Hi
<roaksoax> rvba: dont mean to bother you but any updates on the critical bug for multi environment juju
<rvba> roaksoax: branch is about to be landed.  I've just built a package with it (yes, *before* it's actually landed) and I'm testing it.
<roaksoax> rvba: awesome!!!
<roaksoax> rvba: so re on the nodegroup, if you havent eeen my comments yet, there are not managed intrfaces on any of the cluster. but that doesn't change the fact that a node belongs to a cluster/nodegrop
<rvba> roaksoax: I've seen your comments.  I've even replied :).  We need to think about it a little.  One of us will get back to you shortly about this.
<roaksoax> rvba: cool thanks. either way we still have time for this one :)
<rvba> Good :)
<roaksoax> rvba: let meknow when he storage fixes and please
<roaksoax> thanks :)
<rvba> roaksoax: I will.
<roaksoax> rvba: still around?
<roaksoax> allenap: around?
<allenap> roaksoax: Hello.
<roaksoax> allenap: howdy! so I just saw a branch landing to trunk, does that contain all the fixes for the storage issue?
<allenap> roaksoax: I saw your comment, and I'm thinking about it now. Is my latest comment in https://bugs.launchpad.net/maas/+bug/1085823 relevant?
<ubot5> Launchpad bug 1085823 in MAAS 1.2 "The cluster controller detection algorithm considers all the interfaces (and not only the managed interfaces)." [Critical,Fix committed]
<allenap> roaksoax: Yes, should do.
<roaksoax> allenap:  are you guys planning to backport that to 1.2?
<allenap> roaksoax: We may need to update the documentation too, but that should be it for documentation. We have not finished QA yet though.
<allenap> roaksoax: Yes.
<roaksoax> allenap: ack! please let me know as soon as it gets backported so I can start preparing the packages
<allenap> roaksoax: Should I wait until we're happy with QA in trunk first?
<roaksoax> allenap: what ever works best for you guys, if you want to wait fro trunk QA first
<allenap> roaksoax: I'm asking rvba, but I think he's gone for the day now. I'll prepare proposals for 1.2 anyway, so we can land quickly.
<roaksoax> allenap: cool thanks. If they are ready that would be helpful for me as I could work on the SRU packages today, and have them uploaded tonight/tomorrow morning
#maas 2013-03-07
<Bobby_V> Just a quick reminder - the NebOps Admins will be participating in a team outing tomorrow 11:00-18:30.  The CI Engineers have graciously offered to staff the phones so our Huntgroups will be covered.  We will return to normal coverage at 22:00 when 3rd Shift starts.  As always, we will be available should an incident arise needed our attention.
<rvba> roaksoax: Hi.  We've fixed the bug.  Code is landed on trunk and 1.2.  allenap will give you a tiny text that we would like to see included in the changelog or someplace else where the user will be able to find it.
<roaksoax> rvba: cool thanks
<allenap> roaksoax: I've emailed it.
<roaksoax> allenap: cool. i can include that in the changelog, but tht wouldn't be seen  bypeoplewho just dist-upgrade
<roaksoax> we do need to provide an upgradepath documentation which this should be specified
<allenap> roaksoax: Right, I wasn't aware of that. Is that text sufficient, or do you need something with more depth to it?
<roaksoax> allenap: is there and upstream readme,probablyt that's a better place
<roaksoax> allenap: but for the upgrade path documentation should be enouhg,which is something we wil have to take care of in the upcoming days after this gets accepted for SRU
<allenap> roaksoax: Okay. Let one of us know if you need some more text about this.
<allenap> rvba: Are we happy now that the 1.2 branch is ready for SRU?
<roaksoax> allenap: sure thing. thanks
<rvba> allenap: very much so :)
<allenap> roaksoax: What rvba said :)
<roaksoax> allenap: cool thanks guys
<roaksoax> preparing packages now
<jderose1> so i'm just getting started with MAAS... i'm wonder where the code is that generates the ephemeral images like the ones here: http://maas.ubuntu.com/images/ephemeral/daily/raring/20130307/
<jderose1> is that found in the maas source tree, or elsewhere?
<jderose1> smoser: is the code for the fast path installer available publicly?
<smoser> jderose1, fast path installer is lp:~smoser/+junk/xinstall.maas
<smoser> code that generates daily images is at https://code.launchpad.net/~smoser/maas/maas.ubuntu.com.images-ephemeral
<roaksoax> jderose1: https://code.launchpad.net/~andreserl/maas/trunk-fpi
<jderose1> smoser: okay, thank you very much. so System76 interested in using maas to provision desktop systems, and it making that something useful to others well. and then internally, we plan to use the same foundations for system imaging at our distribution centers
<jderose1> (also, thanks roaksoax)
<roaksoax> jderose1: smoser's branch is what he initially did, my branch is the actual work to get it integrated with maas. However, this is very early support. We have only tested deployments of server not desktop though (for the FPI_
<jderose1> smoser: you're fast installer work caught our eye... for us, it's important to image a system as quickly as possible :)
<jderose1> roaksoax: okay, thank you... i'll poor over it. i just jumped into this, so fire hose and all :)
<smoser> jderose1, well, the fast path installer will really be targetted at putting a root filesystme tar file donw, and thne doing whatever necessary to make it boot.
<smoser> the key is in having the tar  root filesystem that you want ready to go
<jderose1> smoser: right, that's the exact same thing we want to do, just it's going to be a bigger rootfs based on our desktop golden image
<smoser> right.
<jderose1> how does the idea of provisioning desktop systems with maas strike everyone? seems like stuff like provisioning a room full of workstations at a button push, enrolling them with landscape would be a good show :D
<jderose1> right now i'm just trying to figure out where the common ground is, if this makes sense. obviously it would need to be done with zero impact on standard server provisioning
<racedo> hi guys, question: juju deploy --constraints maas-name=node.domain is trying to deploy in a new non-existent machine that gets created
<racedo> plus i get all the time ProviderError: No matching node is available. from the juju logs
<roaksoax> racedo: and I'm guessing that if you don't use the .domain, only node it works?
#maas 2013-03-08
<haitao> I have some questions related to setting up MAAS on virtual box, is this the right place?
<lifeless> haitao: yes
<racedo> roaksoax: no, I've seen what you say in the past (not specifying the domain in the maas-name constraint fixing it)
<racedo> roaksoax: in this case it never matches and creates an additional machine that doesn't exist
<AskUbuntu> Why doesn't the nova-cloud-controller charm properly set up openstack networking? | http://askubuntu.com/q/265489
<roaksoax> racedo: has the backport of django in ppa fixed your issue?
<racedo> hey roaksoax
<racedo> i did it before updating
<racedo> roaksoax: i ended up not using constraints as i needed it up and running but i think i can reproduce it easily
<racedo> i can try now if you want and have it 15 mins
<roaksoax> racedo: nothing in the logs?
<racedo> yeah, i'll show you
<racedo> i need to rebuild it now because i destroyed everything
<racedo> roaksoax: i did it today and it just works, the only difference is that i have updated python-django
<racedo> roaksoax: so i fortunately cannot reproduce it... that's weird, yesterday i had the old python-django from the ppa anyway
<roaksoax> racedo: that's probably it
<roaksoax> racedo: the problem really was that a security update landed with the same ubuntu revision as the package we had prepared for maas, and since it hasn't yet been released, it obviously took the version of the security fix
<roaksoax> so since Daviey already backported it, we should be good to go
<roaksoax> rvba: howdy!! So I just saw two more branches were landed in lp:maas/1.2
<roaksoax> rvba: are those realted to the file storage thing?
<rvba> roaksoax: Hi!  Yes, these are cleanup branches.  If you can include them in the SRU great, if not, that's not the end of the world.
<roaksoax> rvba: ok cool :)
<roaksoax> i think i might be able to
<rvba> Cool :)
<racedo> roaksoax: yeah i noticed, thanks for having fixed it so quick, maas-developers/stable is now the one we use
<roaksoax> racedo: cool! the sru should be comming soon too
<Bobby_V> REMINDER:  At 11:00 CT, the NebOps admins will be departing for their team outing.  Our huntgroup will be monitored by the CI Engineers.  We will be having team fun until 18:30 CT.  Our On Call admin will cover from then until 3rd shift is on line at 22:30.  As always, should emergencies arise, we will be available to handle incidents/outages.
<mross> Hi, I'm trying to setup maas-dhcp to pixeboot a cluster
<mross> My nodes aren't picking up the dhcp server
<mross> [mezeoadmin@maas]~â¯  service maas-dhcp-server status
<mross> maas-dhcp-server start/running, process 2747
<mross> So it is running, but what would prevent the nodes from finding the dhcp server
<mross> ??
#maas 2013-03-09
<physicalsrv> hello everybody
#maas 2013-03-10
<mattrae> hi, when i destroy-environment and then redeploy to the same machines they aren't reinstalled. I have to delete the machines and re-enlist to get a fresh installation.
<mattrae> i couldn't find a bug for this. sounds like a bug though
<mattrae> i think whenever i terminate a machine, it should be reinstalled when that hardware is used again
<bigjools> mattrae: I have seen one other person say this too, however I can't re-create it.  Which version of maas are you using?
<mattrae> hi bigjools i'm using 1.2+bzr1360+dfsg-0ubuntu1~ppa1 from http://ppa.launchpad.net/maas-maintainers/stable/ubuntu/
<bigjools> mattrae: which version of juju, and what do you see happening on the machines' consoles that's different to normal?
<mattrae> bigjools: i'm using juju 0.6.0.1+bzr618-0juju2~precise1. for example i do juju destroy-environment. then when i do juju bootstrap ubuntu is not reinstalled. i can do juju status and see my old environment
<bigjools> sounds like a bug in juju?
<mattrae> i see the machines being returned to 'ready' when i terminate the environment
<bigjools> can you see the destroy request in the maas log?
<mattrae> sure i'll check for the request in the log
<bigjools> so the machines are ready, yet when you do a status, you see them in use?
<mattrae> bigjools: i'm looking in maas.log and i see a number of these errors from around the time i destroyed the environment: "PermissionDenied: Not authenticated as a known node."
<bigjools> ew
<bigjools> can you paste the log somewhere for me plesae
<bigjools> please
<mattrae> the machines are ready, then i do juju bootstrap, the machine starts but doesn't reinstall. then i do juju status and i see my previous environment
<bigjools> what does it do instead of re-installing?
<mattrae> it appears to just boot the machine with whatever was on it previously
<bigjools> what state does maas show it in at that point?
<mattrae> since i see my old environment
<mattrae> at that point its allocated
<bigjools> the machine will do a local boot if anything goes wrong with the pxe boot
<bigjools> so I suspect your PermissionDenied errors have got something to do with this
<mattrae> here's the error i see a few times i the log. yeah i don't know whether it is related or not http://pastebin.com/zu16ETvW
<mattrae> that error could be related to me trying to re-enlist the machines. re-enlisting doesn't seem to be working
<mattrae> only worked for one node :/
<bigjools> yeah it's a metadata server error
<mattrae> sounds like i need to reinstall maas :/
<bigjools> the metadata server IDs the requesting node so it knows which data to send it
<bigjools> don't re-install, let's investigate
<mattrae> ok cool :)
<bigjools> ok this will take a while, sorry, but can you remove all your nodes, shut down maas, wipe your logs and start again
<bigjools> then re-enlist, bootstrap
<mattrae> now it seems that even though i deleted the machines from maas. then rebooted them, they aren't re-inlisting. only one node re-inlisted.. the rest just booted up with whatever they had on them previously
<bigjools> send me the log
<mattrae> i'll try rebooting them again
<bigjools> then destroy-env and send me the log again
<mattrae> ok sounds good
<bigjools> this will get me a clean log
<mattrae> bigjools: hrm, so i deleted all nodes from maas and shut down the machines. i power on one machine and it boots up with what it had previously and I get that same "permissionDenied: Not authenticated as a known node" error
<mattrae> the nodes never show up in the maas web interface
<bigjools> hmm
<bigjools> so there's 0 nodes registered?
<mattrae> yeah "0 nodes in maas"
<bigjools> ok
<bigjools> can you send me the pserv log
<mattrae> sure, want the whole thing? the most recent message in pserv.log is 40 min ago
<bigjools> oh
<bigjools> darn
<bigjools> that's odd
<bigjools> you don't have more than one dhcp server on your network do you?
<mattrae> would it make sense to try restarting the maas server?
<mattrae> or is there a way to check the health?
<mattrae> i see maas-pserv, maas-cluster-celery, maas-txlongpoll, maas-region-celery, and maas-dhcp-server are running
<mattrae> i can try reinstalling maas too and report if i see this issue again
<mattrae> normally deleting nodes works, so i wonder if something got corrupted
<mattrae> deleting/re-inlisting works i mean
<mattrae> nope
<bigjools> when you boot the node, can you see it pxe booting from maas?
<bigjools> or does it time out?
<bigjools> it looks to me like it is not pxe booting, and the previous installation boots and tries to contact the metadata server with predictable results
<mattrae> hmm i'll check
<bigjools> the most obvious reason for that is usually that there's another dhcp server
<mattrae> bigjools: ahh yeah looks like my vm's are set to boot from the hd. that is weird because i'm not sure how i would have got them deployed previously
<bigjools> aha
<mattrae> these are libvirt vms.. does maas set a node to not pxe once there is an installation?
<bigjools> yes
<bigjools> oh wait
<bigjools> no, sorry
<mattrae> or maybe it was pxeing because there was no installation
<mattrae> cool, i should at least be able to set these back to pxe
<bigjools> the tftp server gives a different config based on what state we think it's in
<bigjools> quite likely, yes
<bigjools> maas does not touch bios boot order
<bigjools> you need to make sure pxe is first
<bigjools> great, good luckj
<mattrae> great, thanks for the help
<bigjools> welcome
#maas 2014-03-03
<rvba> bigjools: the doc is back to revision 1930 (i.e. before the rename).
<Lord_Set> Any devs around?
<jtv> Hi Lord_Set
<bigjools> no, none :)
<Lord_Set> lol hey bigjools
<Lord_Set> Was gonna bring up an enlistment issue but just did a update and upgrade and will see if it resolves the issue.
<Lord_Set> Have a good weekend?
<Lord_Set> Any fix available for https://bugs.launchpad.net/maas/+bug/1285607
<ubot5> Ubuntu bug 1285607 in MAAS "maas_ipmi_autodetect mistakes empty slot for taken slot" [Critical,Fix committed]
<jtv> Lord_Set: jhobbs fixed that one IIRC.
<jtv> The daily builds PPA should have the fix already.
<Lord_Set> Hmm alright
<Lord_Set> I just updated and it didn't fix it. I will restart the server and recomission the nodes.
<Lord_Set> errr re-enlist
<Lord_Set> Same issue... getting "No Power Type Defined"
<Lord_Set> I will rerun the script to see what errors I receive
<Lord_Set> http://pastebin.ubuntu.com/7026720/
<Lord_Set> I am removing MAAS and going to reinstall it fresh
<Lord_Set> ip a
<Lord_Set> oops lol
<Lord_Set> One of those nights
<Lord_Set> mmm wild turkey
<Lord_Set> Are there any good instructions on manually removing MAAS if purge failed?
<Lord_Set> http://pastebin.ubuntu.com/7027370/
<Lord_Set> Error after purging MAAS and attempting to reinstall.
<mgz> maas sprinters, do you have your networking plans written down anywhere I can read 'em?
<Lord_Set> Is anyone around?
<Lord_Set> MAAS failed to uninstall properly and am having difficulty removing the pieces and reinstalling it...
<Lord_Set> Anyone?
<bigjools> Lord_Set: hi
<Lord_Set> Hello
<Lord_Set> bigjools: Did you see my previous question about manually uninstall MAAS after a failed uninstall?
<bigjools> I did
<bigjools> apt-get purge should remove everything
<Lord_Set> It didn't
<bigjools> but a more specific description would help anyone listening to offer advice
<Lord_Set> http://pastebin.ubuntu.com/7030332/
<Lord_Set> That is the error that I receive when trying to remove MAAS
 * bigjools looks
<bigjools> oh ha
<bigjools> it looks like you had a previously failed install
<Lord_Set> Was a failed uninstall but yes
<bigjools> and dpkg tries to finish that before purging
<bigjools> roaksoax: can you help here please? ^
<bigjools> he knows packaging better than I
<Lord_Set> Ok
<bigjools> your dpkg database is in a bad state i think
<Lord_Set> :(
<Lord_Set> I am just trying to avoid reinstalling ubuntu as the server is in Vegas and I am about a 5 hour flight away lol. I can do a ILO based install but virtually mounting the install disk is SUPER slow and prone to issues.
<bigjools> it will be recoverable, it just needs someone with the know-how
#maas 2014-03-04
<rvba> gmb: ping
<gmb> rvba: Did you just ping me and then ask me out loud?
<jtv> Yes.  Yes, he did.
<rvba> gmb: ping!
<gmb> rvba: bzr shelve --all; bzr pull; bzr unshelve
<rvba> rvb@leaf:~/canonical/api-power-type$ bzr pull ../maas
<rvba> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<rvba> Use the merge command to reconcile them.
<rvba> ^ lie
<roaksoax> rvba: o/
<roaksoax> bigjools: o/
<roaksoax> bigjools: how are things going? How's the progress?
<roaksoax> anything I can look at?
<bigjools> roaksoax: slow
<rvba> \o roaksoax
<roaksoax> bigjools: can you or one of the team please review the UEFI stuff?
<bigjools> roaksoax: gavin did
<rvba> roaksoax: question for you: why isn't this returning anything? http://paste.ubuntu.com/7030441/.  Looks like the beta1 ephemeral for trusty hasn't been released yetâ¦?
<roaksoax> bigjools: ok great
<roaksoax> rvba: looking
<rvba> Ta
<roaksoax> rvba: can you try daily;'s? that's weird trusty ephemeral were available
<roaksoax> smoser: ?
<roaksoax> /query/win 10
<rvba> roaksoax: I tried with the daily url but I still get no results.
<roaksoax> rvba: maybe there's an error somewhere
<roaksoax> or maybe something happened
<rvba> I don't know. http://maas.ubuntu.com/images/ephemeral/releases/trusty/ says alpha-2 is there but not beta-1
<roaksoax> rvba: so images have not yet been generated then
<rvba> roaksoax: any idea when this is supposed to happen then?
<roaksoax> rvba: nope, but will lookinto that tomorrow
<rvba> Okay, ta.
<Settite> jtv? roaksoax? either of you around?
<jtv> Settite: hi, just out getting lunch.  We're a bit pressed for time on this end.
<Settite> I know. Just need quick help manually uninstalling MAAS
<bigjools> Settite: you might want to ask in #ubuntu-server as this is a dpkg problem not a maas problem
<Settite> Alright
<bigjools> although
<Settite> Didn't realize that
<bigjools> the  maas package has a problem, but the result of the problem is a dpkg problem :)
<bigjools> basically the failed install is preventing removal
<Settite> I will hit up #ubuntu-server first and see where i can get
<mwhudson> bigjools: has anyone talked about running maas on arm64 yet?
<bigjools> mwhudson: not that I heard
<bigjools> are you talking deploying or running on?
<mwhudson> bigjools: deploying on
<mwhudson> bigjools: is that even a sensible question, or does it depend on how a particular device boots/does ipmi/whatever
<mwhudson> ?
<bigjools> mwhudson: well AFAIC there's no difference to arm
<bigjools> uboot has to tftp a specific location to get the right loader
<mwhudson> right
<Settite> So in #ubuntu-server they told me to remove the entries in /var/lib/dpkg/status for MAAS and just install it again... to me that doesn't seem right.
<Settite> Or am i missing something/
<Settite> ?
<bigjools> uhm
<bigjools> I am no expert so try it
<Settite> I will and report the results
<Lord_Set2> bigjools: That method worked FYI to reinstall.
<Lord_Set2> The MAAS installer found some of the old stuff but regenerated passwords fine and migrated everything else
<Lord_Set2> No issues yet
<Lord_Set2> So I got some new dell blade servers to play around with and test with MAAS
<Lord_Set2> Will be interesting to see how they enlist and commission
<Lord_Set2> They are Dell C6100s
<Lord_Set2> 2 of them with all intel quad core 5600 series processors, 3 of them with AMD 6-core processors. 192GB of ram in each.
<jtv> all otp here :)
<Lord_Set2> otp?
<jtv> On The Phone.
<Lord_Set2> Oh
<jtv> Reference for TLAs: http://xs4all.nl/~jtv/gtf/
<Lord_Set2> fml, with a fresh install of the daily maintainers build of MAAS it is still having ilo/ipmi detection problems
<Lord_Set2> I watched the boot of one of the servers and it isn't able to open the device at /dev/ipmi0 or /dev/ipmi/o or /dev/ipmidev/0
<Lord_Set2> But I am able to access to control the servers via ipmipower manually
<Lord_Set2> *access and controll
<Lord_Set2> control
<bigjools> Lord_Set2: good to hear
<bigjools> the first thing, not the recent thing :)
<Lord_Set2> lol
<bigjools> so the ipmi things are actively getting looked at, they will get a fix soon, maybe in a day or two
<Lord_Set2> Alright. I guess for now I will manually boot the servers between installation phases. Should this cause any issues in the OS install?
<bigjools> no
<Lord_Set2> Awesome and thanks.
<bigjools> https://bugs.launchpad.net/bugs/1287512 is prob the bug
<ubot5> Ubuntu bug 1287512 in MAAS "OCPv3 roadrunner detects IPMI as 1.5, which isn't supported." [Critical,In progress]
<Lord_Set2> I don't think so. This isn't detecting any IPMI at all at the end of the enlistment.
<Lord_Set2> Current errors in maas.log
<Lord_Set2> http://pastebin.ubuntu.com/7032086/
<bigjools> Lord_Set2: what client is connecting when it does that?
<bigjools> it's basically not authed
<Lord_Set2> I am logged in with 2 different current API keys
<bigjools> is this the api cmd line client?
<bigjools> you need to re-login
<Lord_Set2> Yes
<bigjools> you deleted your install and lost the auth keys
<Lord_Set2> I did logout of the old logins and re-logged in with the newly generated keys
<Lord_Set2> Those are the ones currently logged in
<bigjools> right we're all EODing
<Lord_Set2> I am just trying to figure out if it is a configuration issue or a bug I should report
<bigjools> you need to log in again
<Lord_Set2> Ok I will
<Lord_Set2> More good news... MAAS loves the Dell C6100 blades.
<Lord_Set2> No issues with ipmi detection or enlistment at all
<Lord_Set2> If anyone is still available... how difficult is to to modify the installation of Ubuntu via MAAS to install LAMP as part of the base install?
<smoser> rvba, why do you care about something called "beta1" ?
<smoser> please don't get stuck on names. i'm sure we can/should get a newer thing there, but why are you explicitly looking for something named 'beta-1' ?
<smoser> :q
<manjiri> hello. I replaced /var/lib/maas/tftp/amd64/generic/precise/install/* by passing a different MAIN_ARCHIVE to import-pxe-files. The intent was to install Ubuntu 12.04.3 (3.8.0-29-generic). MAAS still install 12.04.4 (3.2.0-59-generic). Any idea what I need to do differently?
<Lord_Set2> So... any specific reason why nodes are prompting for a password when I have had a ssh key generated and trying to ssh from the maas controller?
<bigjools> Lord_Set2: you need to alter preseeds or pass cloud-init userdata for post-install actions
<roaksoax> manjiri: 12.04.4 is now default so there's really nothing you can do there
<bigjools> hey roaksoax
<bigjools> Lord_Set2: is your key registered in maas for the same account that you used to start the node and are now sshing with?
<roaksoax> bigjools: howdy!
<roaksoax> bigjools: early start today?
<bigjools> meeting
<bigjools> that is if the other party shows up :)
<roaksoax> haha
<Lord_Set2> bigjools: yes, I ended up modifying the preseed master for now to use a static user/pass across all nodes
<bigjools> urgh
<bigjools> that's horrible
<Lord_Set2> I agree but no choice right now
<bigjools> roaksoax/jhobbs: is this related to any of your recent work? https://bugs.launchpad.net/bugs/1287828
<ubot5> Ubuntu bug 1287828 in MAAS "IPMI power driver setting is reset/overriden by commissioning" [Undecided,New]
<bigjools> Lord_Set2: can you check that once you are in, you can see the public key in they ubuntu user dir?
<bigjools> the*
<bigjools> you *are* sshing with ubuntu@ right?
<bigjools> as that is the default user name
<jhobbs> bigjools: i don't think so, i think that's always been the behavior
<jhobbs> bigjools: ipmi autodetect, when it runs during commissioning, will supply all of the settings it applies/discovers back to metadataserver
<jhobbs> bigjools: bigjools i think the bug they reference as the underlying reason for needing to do so (autodetect doesn't work) should be fixed by recent work though
<bigjools> jhobbs: well we autodetct in enlistment, but didn't think we did it during commissioning
<bigjools> so I am surprised at the behaviour
<jhobbs> bigjools: yup, runs both times.  i'm still not 100% sure why it has to run during commissioning. roaksoax explained it at one point but it's not coming to the top of my head
<bigjools> jhobbs: yeah it doesn't seem right to me at all
 * bigjools waits for roaksoax too :)
<jtv> Maybe because the "commissioning snippets" infrastructure got re-used for enlistment?
<jhobbs> it's good that it runs during enlistment, so we have the power parmeters to use to turn it on for commissioning
<manjiri> roaksoax: is the preseed config used with the "fast installer"?
<jhobbs> i guess one case autodetect in commissioning is useful is if the user manually added the nodes, but didn't add power info, and then manually powered on?
<jhobbs> maybe commissioning ipmi autodetect should only run if power isn't configured for the node
<bigjools> maybe
<roaksoax> manjiri: there are different preseeds used
<roaksoax> bigjools: me what how when?
<bigjools> roaksoax: que?
<bigjools> :)
<roaksoax> bigjools: thge bug above should be fixed with the recent changes that just landed
<bigjools> roaksoax: elmo's bug about overwriting power settings?
<bigjools> https://bugs.launchpad.net/bugs/1287828
<ubot5> Ubuntu bug 1287828 in MAAS "IPMI power driver setting is reset/overriden by commissioning" [High,Triaged]
<roaksoax> bigjools: yeah, since commissioning does the discovery again regardless
<bigjools> roaksoax: so what changed?
<manjiri> roaksoax: Which preseed config should I modify to see if I can specify a particular kernel-image during fast-installation?
<roaksoax> bigjools: we removed the aut0o-detect option
<roaksoax> bigjools: and improved the lan_2_0 detection
<roaksoax> bigjools: so it will either be lan_2_0 or lan
<roaksoax> and in this case, enlistment will detect lan_2_0 and he wont need to change it manually
<bigjools> roaksoax: in either case I think we should not overwrite user settings
<roaksoax> bigjools: there's no way for us to determine that
<bigjools> there's always a way :)
<roaksoax> manjiri: /etc/maas/preseeds/user_data
<roaksoax> bigjools: not really, so enlistment and commissioning both modify and update IPMI settings regardless of the user manually changing the setting
<manjiri> roaksoax: curtin_userdata?
<roaksoax> bigjools: i.e. enlistment happens, then the user manually enters user/password, and in commissioning, whatever was entered by user, gets overwritten if maas can create user/pass
<roaksoax> makes sense?
<roaksoax> manjiri: yes! sorry
<jhobbs> roaksoax: what if commissioning only made IPMI changes if the node didn't already have IPMI configuration?
<bigjools> roaksoax: right, so I am saying we need to change that, we should never overwrite what the user put in unless they ask for it
<bigjools> that is the crux of elmo's bug
<bigjools> see my last comment on it
<manjiri> roaksoax: What format is that? How can I effectively add base-installer/kernel/image config?
<roaksoax> bigjools: so how can we determine wether e user changed this settings or not?
<roaksoax> manjiri: it copies the kernel image being loaded
<roaksoax> so that would be 12.04
<roaksoax> no .01/02
<roaksoax> you woul,d need to upgrade kernel
<roaksoax> in postinst
<roaksoax> i guess
<bigjools> roaksoax: we can detect it on the server if we are able to see that the api request came from commissioning
<roaksoax> jhobbs: we cant.. it is based -on the sabe assumption. say IPMI user was created during enlistment, and user manually changes the password of the maas user, then on commissioning, it has no way of knowing that, and will generate new user/pass combination.
<roaksoax> jhobbs: and covers cases where things fail during enlistment
<manjiri> roaksoax: what is a source of information that will help me understand the sentence "you would need to upgrade kernel in postinst". What context is postinst - so that I may google for more info
<jhobbs> bigjools: it's too late then, the ipmi settings have actually changed then, and if the API doesn't update, the saved settings will be wrong
<bigjools> roaksoax: perhaps you can comment on the bug then please, because it seems simple enough to me :)
<bigjools> jhobbs: point
<bigjools> so the preseed needs to prevent this in the first place
<bigjools> I need to make coffee for the sprinters, back in 10m
<roaksoax> bigjools: hold on. If enlistment creates user/password, it works, but user changes these settings manually, how can commissioning successfully say "don't try to detect IPMI again because the user has changed user/password"?
<bigjools> they are looking at me like they are about to kill
<jhobbs> roaksoax: we have to change the commissioning script to not call ipmi-autodetect if there is already ipmi credentials for the node
<bigjools> that ^
<jhobbs> roaksoax: that way, no matter where they came from - enlistment or manual user entry - they aren't changed except via another enlistment, or via another manual user edit
<bigjools> +1
<roaksoax> jhobbs: right, but we *want* to change the password if it came from enlistment
<bigjools> +1 again
<jhobbs> roaksoax: why?
<bigjools> this just affects commissioning
<roaksoax> jhobbs: because enlistment is unsecure
<bigjools> with enlistment, there is no node in maas
<roaksoax> it is anynomous add
<roaksoax> jhobbs: the noed was added to maas withpower parameters anonymously
 * bigjools goes barista-ing
<manjiri> roaksoax: I was able to specify the specific kernel by modifying the preseed_master config. How can I get the same functionality for fast installer?
<roaksoax> in commissioning it actually authenticates with the server and we can trusty that the accepted the node, and new credentials are being generated
<roaksoax> manjiri: i don't know unfortunately. this might help astokes.org/using-fastpath-installer-maas
<jhobbs> roaksoax: ok - i think that makes sense
<roaksoax> manjiri: see related posts / configuring vlans in MAAS node deployment or customizing fast path (curtin) installations in MAAS
<roaksoax> jhobbs: so the problem is, what if the user manually changes the password on the BMC and updates MAAS< and then it breaks things?
<jhobbs> hmm, maybe not, i don't really get where we can start trusting vs. where we can't
<jhobbs> we can trust from commissioning because it has the API key that we gave via the PXE boot process, whereas anyone with IP access to MAAS can spam and enlist nodes
<roaksoax> jhobbs: correct
<roaksoax> jhobbs: this is why we generate a second set of credentials (another password) during commissioning, because those are the credentials that we know will be used for deployment
<manjiri> roaksoax: http://maas.ubuntu.com/docs/development/preseeds.html says that there is a preseed_xinstall. But my MAAS controller does not have that file. (Only preseed_master is present). Any idea?
<bigjools> docs are probably for a newer version than what you have installed
<manjiri> bigjools: ah! thanks
<roaksoax> manjiri: that has changed in latests
<roaksoax> curtin is more recent than xinstall
<roaksoax> bigjools: so back on the above... I don't think we can effectively determine what to trust or not on enlistment/commissioning
<roaksoax> bigjools: i don't mind having commissioning not trying to re-do ipmi discovery
<bigjools> roaksoax: I think that is best
<roaksoax> bigjools: but that would defeat the purpose of not trusting what came from enlistment to trusting what came from commissioning
<bigjools> although we may have a certain dictator arguing the opposite at some point
<roaksoax> bigjools: well, we went thorugh this long ago with smoser
<roaksoax> and we both agreed it was better to do this
<roaksoax> in both cases
<bigjools> well elmo has a valid point don't you think?
<jhobbs> there's nothing secure about ipmi and pxe booting
<roaksoax> bigjools: i do believe he does
<roaksoax> bigjools: wouldn't it be better to have someone to determine whether the changes were made by a user or by enlistment?
<roaksoax> to have something*
<bigjools> my thoughts are that the preseed template can turn on the commissioning detection if it knows there's no power set yet
<bigjools> anyway - I'll let you guys talk it over, we have to sprint here!
<roaksoax> i'll wait for smoser  to chip in
<roaksoax> i'
<roaksoax> i'm out for lunch ... or should I say dinner
#maas 2014-03-05
<manjiri> curtin experts: What mod to curtin_userdata will have the same effect as "d-i     base-installer/kernel/image     string  linux-image-3.8.0-29-generic" in preseed_master?
<Lord_Set2> What fixes were in the maitenance release a few hours ago?
<jtv> Daily builds are a bit fine-grained to track...  one thing you can do is look at the revision log for trunk.
<jtv> See https://code.launchpad.net/~maas-maintainers/maas/trunk
<bigjools> "release" is a strong word.  It's an autobuild of trunk.
<Lord_Set2> Oh
<Lord_Set2> I will test the IPMI changes
<Lord_Set2> Well, test everything that I run across
<jhobbs> Lord_Set2: let me know if you have any IPMI issues :)
<Lord_Set2> I will
<Lord_Set2> I am tired of having to manually use ipmipower lol. Though I kind of have it down to a science now with notepad and my hostname list and username and password.
<jhobbs> Lord_Set2: why do you have to manually use ipmipower?
<Lord_Set2> Because MAAS enlistment wasn't detecting IPMI at all previously
<jhobbs> ahh
<Lord_Set2> On my servers
<jhobbs> in that case, let me know if it fixes it :)
<Lord_Set2> I will for sure
<Lord_Set2> It worked!
<Lord_Set2> You rock jhobbs
<jhobbs> cool!
<Lord_Set2> Oh, I am also super happy to see with 14.04 my 10g Brocade CNA are working flawlessly and are being detected by MAAS.
<Lord_Set2> My MAAS controller is using a 10g nic as its primary currently.
<Lord_Set2> jhobbs: So I have bad news... MAAS does detect the IPMI controller but still won't power the servers on or off.
<Lord_Set2> Also have another new shitty bug... there is no timer on the grub boot selection screen. It just stays there until you manually select an option such as Ubuntu or memtest86, etc...
<marcoceppi> roaksoax bigjools you guys around?
<marcoceppi> maas createadmin doesn't seem to work anymore, it seems maas is now pointed to maas-cli
<marcoceppi> nvm, sudo maas-region-admin createsuperuser
<Lord_Set> Yeah things have changed
<marcoceppi> need to update my scripts
<Lord_Set> I am trying to get Virtualmin and Cloudmin to deploy with Juju and properly install on trusty right now
<Lord_Set> Not fun at all
<marcoceppi> Lord_Set: so you're charming both up in addition to trying to get themto deploy with maas and juju on trusty?
<Lord_Set> Yes
<marcoceppi> You are a brave soul, that's a lot of moving parts ;)
<Lord_Set> Too many
<Lord_Set> It is making me drink
<marcoceppi> Lord_Set: why not target precise for the time being?
<Lord_Set> Because trusty has features I need
<Lord_Set> Like support for my 10g CNA
<marcoceppi> Lord_Set: ah, in that case, carry on
<Lord_Set> And some of my SSD
<Lord_Set> and various other server components
<Lord_Set> It has been fun trying to get production ready with trusty, maas dailies and now juju development
<Lord_Set> Oh yeah, and I am learning python as we speak
<marcoceppi> Lord_Set: well, I'm in the process of spinning up my MAAS cluster so if you've got questions about maas+juju+charms feel free to let me know
<marcoceppi> I can't seem to get my servers to register in the DHCP server for MAAS
<marcoceppi> Is nodegroup the same as the physical zone?
<matsubara> marcoceppi, nope, node group is the same as a cluster controller. See http://maas.ubuntu.com/docs/physical-zones.html and https://bugs.launchpad.net/maas/+bug/1287452
<ubot5> Ubuntu bug 1287452 in MAAS "API has methods like "node-group" instead of "cluster" which is confusing to users" [High,Triaged]
<marcoceppi> matsubara: I ended up just saying screw you and doing autodetect_nodegroup
<marcoceppi> screw you, being node-group, not you in particular
<matsubara> heh ok
<marcoceppi> things are looking good in maas on trusty
<roaksoax> marcoceppi: here now.. what's up?
<marcoceppi> roaksoax: I've been able to power through, I messed up a few things along the way using older "automatically set up maas" scripts
<marcoceppi> roaksoax: the last piece I need to do is virsh stuff,but that seems pretty straight forward
<roaksoax> ok cool
<marcoceppi> roaksoax: do you know if this is still the correct proceedure for virsh? http://askubuntu.com/a/295976/41
<roaksoax> marcoceppi: yeah pretty much
<marcoceppi> roaksoax: cool
<marcoceppi> when doinng virsh, will it pxe boot the KVM?
<jhobbs> yep
<matsubara> jhobbs, roaksoax: bug 1288297
<ubot5> bug 1288297 in MAAS "MAAS ipmi auto detection defaults to 2.0 in the lenovo lab" [Undecided,New] https://launchpad.net/bugs/1288297
<jhobbs> matsubara: ok, i'll look into that
<matsubara> thanks jhobbs. Let me know, if you need help testing in the lab
<marcoceppi> So, trying to get a virtual machine commisioned in maas, I created one using ubuntu-create-vm , I can verify as the maas user that virsh can see it, but it never moves from commisioning or starts up the VM
<bigjools> marcoceppi: http://maas.ubuntu.com/docs/nodes.html#virtual-machine-nodes
<marcoceppi> bigjools: yeah, I did that, and I tested the virsh command from the maas user on the maas master
<marcoceppi> bigjools: I'm going to steal a bunch of the scripts in maas-libvirt-utils to see if that simplifies things
<gmb> jtv https://bugs.launchpad.net/maas/+bug/1288222
<ubot5> Ubuntu bug 1288222 in MAAS "test_macaddresses_are_sorted is flaky" [High,In progress]
#maas 2014-03-06
<gmb> jtv: https://code.launchpad.net/~gmb/maas/fix-bug-1288222/+merge/209561
<rvba> bigjools: in src/maasserver/power_parameters.py, get_power_type_choices looks redundant now (since we have get_power_types).
<gmb> jtv: bin/test.maas -v3 src/maasserver/tests/test_api_enlistment.py
<Lord_Set> Jhobbs, are you around?
<jhobbs> Lord_Set: hey
#maas 2014-03-07
<Lord_Set> Bigjools? jtv? eiter of you around?
<jtv> Hi Lord_Set â final push today!
<Lord_Set> yay!
<Lord_Set> so I have another interesting bug with enlistment since this last update via development release
<Lord_Set> Enlistment errors out and says AMD/64 is not a valid architecture.
<Lord_Set> "amd64/generic is not a valid architecture. It should be one of the following. amd64, i386, armd, etc..."
<Lord_Set> and then enlistment stops
<Lord_Set> http://pastebin.ubuntu.com/7047729/
<Lord_Set> Copy of the the errors in maas.log
<zchander> Good morning/afternoon/evening/night (it's morning where I am right now)
<zchander> May I ask a MAAS/Juju noob question?
<bigjools> !ask
<ubot5> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<zchander> :) I have set up a MAAS environment (using regular PCs as this is a test setup). I installed Juju. After the install of Juju I deployed juju-gui, but somehow  I am not able to connect to the juju-gui charm. I always get to the default apache landing page on my MAAS controller(s)
<bigjools> the juju gui will be installed on one of the maas nodes, so you need to browse there
<bigjools> not the maas controllers
<bigjools> which are at /MAAS BTW
<zchander> My current setup for the network right now is like: Schoolnetwork <---> MAAS controller(s) <---> nodes. Do the nodes also have access to the school network? Or should they all reside in the school network? I made a separate class C network for the cluster
<bigjools> separate networt is correct
<bigjools> network*
<zchander> Do the nodes also have to have access to the schoolnetwork?
<zchander> Sorry, but we are experiencing some network/firewall problems at the moment... Will be back later (over 3G)
<bigjools> only if you set it up that way
<zchander> bigjools: I might have lost some part of one or more answers, due to the network outage we are experiencing right now....
<tych0> are the maas tests only running on trusty now?
<tych0> i'm seeing stuff like
<tych0>     from twisted.internet.endpoints import (
<tych0> ImportError: cannot import name connectProtocol
<tych0> i guess htat is a version thing on saucy?
<tych0> hi all, i'm getting http://paste.ubuntu.com/7050909/ when running dev maas
<tych0> i realize you guys are sprinting this week, i'm mostly just leaving brain dumps :-)
<zchander> Does anyone know of any irc log availability for #maas? I asked a question this morning, but due to a router outage at work (school), I wasn't able to read/receive anything. (Had too much at hand to solve the outage)
#maas 2015-03-02
<mup> Bug #1427160 was filed: MAAS allocates all disk space to /home (d-i installer) <MAAS:New> <https://launchpad.net/bugs/1427160>
<ubot5> Launchpad bug 1427160 in MAAS "MAAS allocates all disk space to /home (d-i installer)" [Undecided,New]
<mup> Bug #1427164 was filed: curtin fast installer tries to match swap with memory <MAAS:New> <https://launchpad.net/bugs/1427164>
<ubot5> Launchpad bug 1427164 in MAAS "curtin fast installer tries to match swap with memory" [Undecided,New]
<mup> Bug #1427164 changed: curtin fast installer tries to match swap with memory <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1427164>
<ubot5> Launchpad bug 1427164 in curtin "curtin fast installer tries to match swap with memory" [High,Triaged]
<mup> Bug #1427164 was filed: curtin fast installer tries to match swap with memory <curtin:Triaged> <MAAS:Triaged> <https://launchpad.net/bugs/1427164>
<mup> Bug #1427164 changed: curtin fast installer tries to match swap with memory <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1427164>
<ubot5> Launchpad bug 1427164 in curtin "curtin fast installer tries to match swap with memory" [High,Triaged]
<mup> Bug #1427325 was filed: 404 file note found <MAAS:New> <https://launchpad.net/bugs/1427325>
<ubot5> Launchpad bug 1427325 in MAAS "404 file note found" [Undecided,New]
#maas 2015-03-03
<mup> Bug #1427469 was filed: Link to "import boot images" page links to incorrect location <papercut> <MAAS:New> <https://launchpad.net/bugs/1427469>
<ubot5> Launchpad bug 1427469 in MAAS "Link to "import boot images" page links to incorrect location" [Undecided,New]
<bmorriso> Is there any possible way to have a preseed per server "type" or even per server? It seems the preseed is more global
<mup> Bug #1427492 was filed: Firefox is unreliable in karma tests <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1427492>
<ubot5> Launchpad bug 1427492 in MAAS "Firefox is unreliable in karma tests" [Critical,Triaged]
<mup> Bug #1389631 changed: maasserver.models.tests.test_bootsource.TestBootSource.test_calls_cache_boot_sources_on_create sometimes fails spuriously <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1389631>
<ubot5> Launchpad bug 1376317 in MAAS "duplicate for #1389631 Spurious test failure: TestBootSource.test_calls_cache_boot_sources_on_create" [High,Triaged]
<mup> Bug #1427573 was filed: Node powered off after PXE power off request during deployment, is not marked as failed and goes from Deploying to Allocated state <oil> <oil-bug-1375244> <MAAS:New> <https://launchpad.net/bugs/1427573>
<ubot5> Launchpad bug 1427573 in MAAS "Node powered off after PXE power off request during deployment, is not marked as failed and goes from Deploying to Allocated state" [Undecided,New]
<mup> Bug #1399775 changed: new 1.7.1 install, front page does not show "0 nodes in this MAAS" text until mouse-over on the pie chart <trivial> <ui> <MAAS:Invalid> <MAAS 1.7:Triaged> <https://launchpad.net/bugs/1399775>
<ubot5> Launchpad bug 1399775 in MAAS 1.7 "new 1.7.1 install, front page does not show "0 nodes in this MAAS" text until mouse-over on the pie chart" [Low,Triaged]
<mup> Bug #1427628 was filed: MAASServerTestCase.setUp() is overly broad <tech-debt> <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1427628>
<ubot5> Launchpad bug 1427628 in MAAS "MAASServerTestCase.setUp() is overly broad" [High,Triaged]
<mup> Bug #1427629 was filed: Trunk: Inaccurate filter when editing search query <ux> <MAAS:New> <https://launchpad.net/bugs/1427629>
<ubot5> Launchpad bug 1427629 in MAAS "Trunk: Inaccurate filter when editing search query" [Undecided,New]
<mup> Bug #1427631 was filed: Trunk: display of RAM is incorrect <ux> <MAAS:New> <https://launchpad.net/bugs/1427631>
<ubot5> Launchpad bug 1427631 in MAAS "Trunk: display of RAM is incorrect" [Undecided,New]
<mup> Bug #1427635 was filed: Trunk: filters and search functionality missing <MAAS:New> <https://launchpad.net/bugs/1427635>
<ubot5> Launchpad bug 1427635 in MAAS "Trunk: filters and search functionality missing" [Undecided,New]
<mup> Bug #1427644 was filed: Can't see which version of MAAS I am running <ux> <MAAS:New> <https://launchpad.net/bugs/1427644>
<ubot5> Launchpad bug 1427644 in MAAS "Can't see which version of MAAS I am running" [Undecided,New]
<mup> Bug #1427644 changed: Trunk: Can't see which version of MAAS I am running <ux> <MAAS:New> <https://launchpad.net/bugs/1427644>
<ubot5> Launchpad bug 1289158 in MAAS "duplicate for #1427644 The version of the package is not displayed on the MAAS UI" [Low,Triaged]
<caribou> Hi, is there a trick to get Maas to use a proxy (i.e. squid) to cache the d/l of the boot images ?
<bmorriso1> morning folks! I'm wondering if there is a way to customize the preseed per host? Or perhaps per host type? I need my installs a bit unique per server/type and it seems like the maas preseed is more global/universal.
<kiko> bmorriso1, I think we can't quite do that today, but roaksoax or blake_r could confirm -- and we are in the process of redesigning that
<j^2> kiko: !
<jhobbs> bmorriso1: https://maas.ubuntu.com/docs/development/preseeds.html
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<ubot5> Launchpad bug 1427810 in MAAS "node view does not refresh after commissioning" [Undecided,New]
<mup> Bug #1427810 changed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 changed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<ubot5> Launchpad bug 1427810 in MAAS "node view does not refresh after commissioning" [Undecided,New]
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 changed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<ubot5> Launchpad bug 1427810 in MAAS "node view does not refresh after commissioning" [Undecided,New]
<mup> Bug #1427810 changed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 changed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<mup> Bug #1427810 was filed: node view does not refresh after commissioning <confusing-ui> <node-lifecycle> <ui> <MAAS:New> <https://launchpad.net/bugs/1427810>
<ubot5> Launchpad bug 1427810 in MAAS "node view does not refresh after commissioning" [Undecided,New]
<jhobbs> which bug was that?
<bmorriso1> jhobbs: that looks like exactly what I want!
<bmorriso> Is there a release schedule for MAAS? Is there any way to say when this https://maas.ubuntu.com/docs/development/preseeds.html might exit in GA?
<kiko> bmorriso, the 1.7.1 release which is out already features that
<kiko> bmorriso, it is available through the PPA
<kiko> and it will be SRU'd to Trusty in the next 30 days
<bmorriso> Pretty sure I'm running 1.7.1 -- I'll have to look further. I guess the docs I was looking at were outdated.
<jhobbs> the preseed feature has been in maas for a long time
<jhobbs> but the path for the preseeds keeps changing
<jhobbs> and it's a pita to figure it out
<jhobbs> i *think* the doc posted up there is correct now for 1.7.1
<jhobbs> bmorriso: ^^
<bmorriso> I'll check it out. This is great news! Thank you very much!
<kiko> https://maas.ubuntu.com/docs1.7/development/preseeds.html
<kiko> bmorriso, let me know tomorrow if you still have any issues -- I'll be back early
<bmorriso> Will do. Thanks!
<kiko> thanks
<kiko> ttyt
<bmorriso> what's the method to restart maas-pserv?
#maas 2015-03-04
<mup> Bug #1427969 was filed: Upgrading to MAAS 1.7.1 to 1.7.2 causes migrations to fail <MAAS:New> <https://launchpad.net/bugs/1427969>
<ubot5> Launchpad bug 1427969 in MAAS "Upgrading to MAAS 1.7.1 to 1.7.2 causes migrations to fail" [Critical,New]
<mup> Bug #1427969 changed: Upgrading to MAAS 1.7.1 to 1.7.2 causes migrations to fail <MAAS:Invalid> <https://launchpad.net/bugs/1427969>
<ubot5> Launchpad bug 1427969 in MAAS "Upgrading to MAAS 1.7.1 to 1.7.2 causes migrations to fail" [Critical,Invalid]
<mup> Bug #1428041 was filed: Invalid choice configure-maas-url when upgrading to 1.7.2rc1 <landscape> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1428041>
<ubot5> Ubuntu bug 1428041 in maas (Ubuntu) "Invalid choice configure-maas-url when upgrading to 1.7.2rc1" [Undecided,New]
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:New> <https://launchpad.net/bugs/1428042>
<ubot5> Ubuntu bug 1428042 in MAAS "Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,New]
<mup> Bug #1428041 was filed: Invalid choice configure-maas-url when upgrading to 1.7.2rc1 <landscape> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1428041>
<allenap> I think we probably only need one of ubot5 or mup telling us about every bug.
<allenap> I have no preference though.
<allenap> Does anyone know who maintains these bots?
<nerash> hello
<nerash> where is maas index file placed?
<nerash> please help
<mup> Bug #1428142 was filed: Node listing page - custom checkboxes <MAAS:New> <https://launchpad.net/bugs/1428142>
<mup> Bug #1428143 was filed: Design: node listing page - row selection <MAAS:New> <https://launchpad.net/bugs/1428143>
<ubot5> Ubuntu bug 1428142 in MAAS "Node listing page - custom checkboxes" [Undecided,New]
<mup> Bug #1428144 was filed: Design: Power state progress icon <MAAS:New> <https://launchpad.net/bugs/1428144>
<ubot5> Ubuntu bug 1428143 in MAAS "Design: node listing page - row selection" [Undecided,New]
<ubot5> Ubuntu bug 1428144 in MAAS "Design: Power state progress icon" [Undecided,New]
<mup> Bug #1428147 was filed: 'Check power state' button <MAAS:New> <https://launchpad.net/bugs/1428147>
<mup> Bug #1428149 was filed: 'The node has been asked to start up' notification <MAAS:New> <https://launchpad.net/bugs/1428149>
<ubot5> Ubuntu bug 1428147 in MAAS "'Check power state' button" [Undecided,New]
<ubot5> Ubuntu bug 1428149 in MAAS "'The node has been asked to start up' notification" [Undecided,New]
<mup> Bug #1428147 changed: 'Check power state' button <MAAS:New> <https://launchpad.net/bugs/1428147>
<mup> Bug #1428149 changed: 'The node has been asked to start up' notification <MAAS:New> <https://launchpad.net/bugs/1428149>
<ubot5> Ubuntu bug 1428147 in MAAS "'Check power state' button" [Undecided,New]
<ubot5> Ubuntu bug 1428149 in MAAS "'The node has been asked to start up' notification" [Undecided,New]
<mup> Bug #1428147 was filed: 'Check power state' button <MAAS:New> <https://launchpad.net/bugs/1428147>
<mup> Bug #1428149 was filed: 'The node has been asked to start up' notification <MAAS:New> <https://launchpad.net/bugs/1428149>
<ubot5> Ubuntu bug 1428147 in MAAS "'Check power state' button" [Undecided,New]
<ubot5> Ubuntu bug 1428149 in MAAS "'The node has been asked to start up' notification" [Undecided,New]
<dimitern> mup, say bug
<mup> dimitern: Unknown commands are unknown.
<dimitern> LOL
<dimitern> these two bots can't get enough of each other :)
<dimitern> rvba, hey are you around?
<mup> Bug #1428041 changed: Invalid choice configure-maas-url when upgrading to 1.7.2rc1 <landscape> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1428041>
<ubot5> Ubuntu bug 1428042 in Ubuntu "duplicate for #1428041 Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Confirmed]
<mup> Bug #1428041 changed: Invalid choice configure-maas-url when upgrading to 1.7.2rc1 <landscape> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1428041>
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<ubot5> Ubuntu bug 1428042 in Ubuntu "Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Fix released]
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<jhobbs> which bug was that mup?
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<ubot5> Ubuntu bug 1428042 in Ubuntu "Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Fix released]
<jhobbs> thanks
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
 * jhobbs emails gustavo
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<mup> Bug #1428042 was filed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<ubot5> Ubuntu bug 1428042 in Ubuntu "Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Fix released]
<mup> Bug #1428042 changed: Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1 <landscape> <MAAS:Fix Released> <Ubuntu:Fix Released> <https://launchpad.net/bugs/1428042>
<niemeyer> jhobbs: Hey
<jhobbs> howdy niemeyer
<jhobbs> it's stopped now
<jhobbs> bug 1428041
<ubot5> bug 1428042 in Ubuntu "duplicate for #1428041 Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Fix released] https://launchpad.net/bugs/1428042
<niemeyer> jhobbs: It doesn't look like they are fighting
<niemeyer> jhobbs: Looks like mup is reporting the same bug multiple times instead
<jhobbs> ah ok niemeyer
<niemeyer> jhobbs: It could indicate a bug in mup, or that Launchpad is misbehaving with cached content somehow
<niemeyer> jhobbs: I'm having a look
<jhobbs> niemeyer: thanks
<niemeyer> jhobbs: I'm betting on the latter option, since mup correctly identified the shift back and forth
<niemeyer> jhobbs: filed/changed/filed/changed
<niemeyer> jhobbs: Note the interactions here: https://bugs.launchpad.net/maas/+bug/1428042
<ubot5> Ubuntu bug 1428042 in Ubuntu "Migration hang with defunct process when upgrading from 1.7.1 to 1.7.2rc1" [Undecided,Fix released]
<niemeyer> jhobbs: At the far bottom
<jhobbs> niemeyer: ahh
<niemeyer> jhobbs: jhobbs: new => released; confirmed => released; released => invalid; invalid => released
<niemeyer> jhobbs: People were dancing around, and mup was following along
<jhobbs> niemeyer: is it really useful to display all of that in IRC?
<niemeyer> jhobbs: Is it really useful to do all of that? :-)
<jhobbs> people are human - mup can rise above
<niemeyer> jhobbs: You know mup stands for "muppet" right?
<niemeyer> jhobbs: ;)
<jhobbs> niemeyer: alright well at least it's not something that happens for every update
<jhobbs> niemeyer: thanks for looking into it so quickly
<niemeyer> jhobbs: More seriously, if people start to do that kind of silly back and forth, we'll to improve the plugin to stop it from bothering
<niemeyer> jhobbs: Please do let me know if that's the case
<jhobbs> niemeyer: here's another one
<jhobbs> https://pastebin.canonical.com/126891/
<jhobbs> that bug doesn't appear to have the dancing around in it
<niemeyer> jhobbs: Indeed.. there's something more awkward going on there
<niemeyer> jhobbs: This is more likely Launchpad providing diverging answers for updates
<niemeyer> jhobbs: Likely due to caching+balancing
<niemeyer> jhobbs: We can probably fix both issues by increasing the refresh delay
<niemeyer> jhobbs: Alright, delay increased
<niemeyer> jhobbs: Please let me know if it bothers again
<jhobbs> niemeyer: awesome thanks
<jhobbs> niemeyer: any idea who runs ubot5?
<niemeyer> jhobbs: No idea
<kiko> thanks niemeyer
#maas 2015-03-05
<mup> Bug #1428647 was filed: regiond service crashes with "the database system is starting up" <MAAS:Triaged> <https://launchpad.net/bugs/1428647>
<ubot5> Ubuntu bug 1428647 in MAAS "regiond service crashes with "the database system is starting up"" [Critical,Triaged]
<unused_PhD> how does it typically take for a server to be commissioned?  I'm new to maas so have no idea how long this should take
<unused_PhD> how long that is
<kiko> unused_PhD, a few minutes normally
<kiko> unused_PhD, it can depend a bit on what server you're commissioning
<unused_PhD> hmm, what should I look at to trouble shoot if it's slow.  I've been waiting hours at this point
<kiko> can you look at the node console?
<kiko> unused_PhD, what version of maas?
<unused_PhD> just installed yesterday from a 14.04 live disc
<unused_PhD> ran the updates, so it should be the latest
<kiko> unused_PhD, you are on 1.5; you should try out 1.7 (which is about to be SRU'd to 14.04)
<kiko> unused_PhD, see https://launchpad.net/~maas-maintainers/+archive/ubuntu/stable
<kiko> or https://launchpad.net/~maas-maintainers/+archive/ubuntu/testing if you are brave :)
<unused_PhD> will do.  I should be safe to add the ppa, and run upgrade?
<catbus1> unused_PhD: yes, add the ppa, then apt update, apt install maas.
<unused_PhD> thank you
<mup> Bug #1428705 was filed: Race condition with caching DNS servers downstream from MAAS DNS <oil> <MAAS:New> <https://launchpad.net/bugs/1428705>
<ubot5> Ubuntu bug 1428705 in MAAS "Race condition with caching DNS servers downstream from MAAS DNS" [Undecided,New]
<unused_PhD> did the trick!
<kiko> unused_PhD, rock on!
<kiko> thanks to hear
<kiko> great to hear I meant :)
<mup> Bug #1428831 was opened: Trunk: USB drive tagged "rotary" <ux> <MAAS:Triaged> <https://launchpad.net/bugs/1428831>
<ubot5> Ubuntu bug 1428831 in MAAS "Trunk: USB drive tagged "rotary"" [Medium,Triaged]
<mup> Bug #1428871 was opened: AMT deployments sometimes fail late with wrong IP address <MAAS:New> <https://launchpad.net/bugs/1428871>
<ubot5> Ubuntu bug 1428871 in MAAS "AMT deployments sometimes fail late with wrong IP address" [Undecided,New]
#maas 2015-03-06
<mup> Bug #1428871 changed: AMT deployments sometimes fail late with wrong IP address <MAAS:Invalid> <https://launchpad.net/bugs/1428871>
<ubot5> Ubuntu bug 1428871 in MAAS "AMT deployments sometimes fail late with wrong IP address" [Undecided,Invalid]
<mup> Bug #1429059 was opened: Design: Add Hardware button <MAAS:New for ricgard> <https://launchpad.net/bugs/1429059>
<ubot5> Ubuntu bug 1429059 in MAAS "Design: Add Hardware button" [Undecided,New]
<dimitern> rvba, hey
<rvba> dimitern: hey
<dimitern> rvba, are you guys sprinting?
<rvba> dimitern: no
<dimitern> rvba, ok, I was wondering if you plan to release a more recent 1.8 experimental package in your ppa
<rvba> dimitern: yeah, I think the plan is to release another alpha next week.
<dimitern> rvba, cool, please let me know when you do
<rvba> dimitern: sure, will do.
<dimitern> rvba, thanks
<mup> Bug #1429060 was opened: Filtering by selected machines <MAAS:New for ricgard> <https://launchpad.net/bugs/1429060>
<mup> Bug #1429061 was opened: Errors notification <MAAS:New for ricgard> <https://launchpad.net/bugs/1429061>
<ubot5> Ubuntu bug 1429060 in MAAS "Filtering by selected machines" [Undecided,New]
<mup> Bug #1429063 was opened: Add Hardware page: Deleting MAC address <MAAS:New for ricgard> <https://launchpad.net/bugs/1429063>
<mup> Bug #1429066 was opened: ADD Hardware page: MAC address text  <MAAS:New for ricgard> <https://launchpad.net/bugs/1429066>
<ubot5> Ubuntu bug 1429061 in MAAS "Errors notification" [Undecided,New]
<ubot5> Ubuntu bug 1429063 in MAAS "Add Hardware page: Deleting MAC address" [Undecided,New]
<ubot5> Ubuntu bug 1429066 in MAAS "ADD Hardware page: MAC address text " [Undecided,New]
<caribou> How can I restart the pserver in maas 1.7 ?
<caribou> nevermind I rebooted maas
<mup> Bug #1371399 changed: power failure events excessively placed <papercut> <robustness> <MAAS:Triaged> <https://launchpad.net/bugs/1371399>
<ubot5> Ubuntu bug 1374478 in MAAS "duplicate for #1371399 Node event log contains thousands of invalid password entries" [High,Triaged]
#maas 2016-03-07
<bdx> core, dev: how can I modify the pxe boot interface of a node?
<bdx> ^^within the context of maas
<bdx> per ^ I'm not finding any entries in the db for pxe interface ... where is this set?
<mup> Bug #1553848 opened: [2.0a1] TFTP back-end crashes <MAAS:New> <https://launchpad.net/bugs/1553848>
<mup> Bug #1553855 opened: [2.0a1] Enlistment results in bad IPMI passwords <MAAS:New> <https://launchpad.net/bugs/1553855>
<mup> Bug #1553841 opened: [2.0a1] MAAS should ensure that BMC password is correct before saving <MAAS:New> <https://launchpad.net/bugs/1553841>
<mup> Bug #1553841 changed: [2.0a1] MAAS should ensure that BMC password is correct before saving <MAAS:New> <https://launchpad.net/bugs/1553841>
<mup> Bug #1553841 opened: [2.0a1] MAAS should ensure that BMC password is correct before saving <MAAS:New> <https://launchpad.net/bugs/1553841>
<voidspace> hey, what's the best way to install 2.0 for testing?
<voidspace> From source?
<Hvis> hey , i'm trying to setup openstack/cloud in a box. So can anyone help how can i proceed
<voidspace> hey, what's the best way to install 2.0 for testing?
<voidspace> From source?
<roaksoax> voidspace: ppa:maas/next-proposed
<roaksoax> voidspace: although, ew haven't yet made an annoucement
<voidspace> roaksoax: thanks
<voidspace> frobware: creating a new clone just worked....
<voidspace> frobware: go figure
<voidspace> frobware: hmmm... although network config may be screwed.
<voidspace> frobware: nope, working fine
<mag009_> hi guys
<mag009_> as always I have more questions .. what is the best practice to scale out maas and for the redundancy
<mag009_> for the db having a master-master is fine but what about the front end (since it's just) web request I suppose I can just put a vip and load-balance across multiples instances of maas that share the same db ?
<mup> Bug #1554152 opened: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment <amd64> <apport-bug> <uec-images> <xenial> <cloud-init:New> <MAAS:New> <cloud-init (Ubuntu):New> <pollinate (Ubuntu):New> <https://launchpad.net/bugs/1554152>
<mup> Bug #1554152 changed: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment <amd64> <apport-bug> <uec-images> <xenial> <cloud-init:New> <MAAS:New> <cloud-init (Ubuntu):New> <pollinate (Ubuntu):New> <https://launchpad.net/bugs/1554152>
<roaksoax> mag009_: MAAS <=1.10 does not support HA, so you wont be able to add redundancy other than the DB
<roaksoax> mag009_: scale out, more cluster controllers
<mag009_> but more cluster controllers that mean each cluster have their own db
<mag009_> am i correct /
<mag009_> ?
<roaksoax> mag009_: no
<roaksoax> mag009_: the cluster controllers dont have a DB
<roaksoax> they connect to the region
<roaksoax> the region is where the DB would normally be
<mag009_> ok and how do link cluster to a single region ?
<mag009_> I haven't found anything in the doc :)
<mag009_> nvm i can figured
<mag009_> out*
<mup> Bug #1554152 opened: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment <amd64> <apport-bug> <uec-images> <xenial> <cloud-init:New> <MAAS:New> <cloud-init (Ubuntu):New> <pollinate (Ubuntu):New> <https://launchpad.net/bugs/1554152>
<mup> Bug #1039701 opened: Wrong RAM memory size <lshw:New> <MAAS:New> <landscape-client (Ubuntu):Invalid> <lshw (Ubuntu):New> <https://launchpad.net/bugs/1039701>
<timello> hey folks! Using Xenial with MaaS 1.10... when commissioning P8 boxes, it creates netboot ethX (pxelinux.0) entry, but it does not creates the 'exec' entry which actually fires the boot
<timello> anything am I missing?
<roaksoax> timello: can you explain a bit more as I don't quite understand what you mean
<timello> roaksoax: sure!
<timello> roaksoax: I'm using MaaS 1.10 from Xenial to commission/deploy Ubuntu on Power 8 boxes. I setup the IPMI, it boots correctly, the netboot shows up in the petitboot menu... the kernel points to tftp://<IP>/pxelinux.0
<timello> older versions I used to see another entry in the petitboot menu, which was 'exec' with kernel, initrd and boot args
<timello> roaksoax: s/boots/powers on
<roaksoax> timello: right, so 1.10 is actually really only 1.9 running on django 1.8/python3
<roaksoax> timello: the exec, IIRC, was created by petiboot automatically to exect the kernel
<timello> yeah... that is not being created and I thought the information comes from MaaS...
<timello> dhcp is working
<timello> nic gets the ip
<timello> just missing the exec entry
<roaksoax> timello: right, so MAAS 1.10 should provide the exact same PXE information as 1.9, becuase MAAS 1.10 is just MAAS 1.9 running on python3/django1.8
<timello> roaksoax: ok, I haven't tried 1.9 to be honest... my maas controller was running 14.04 with 1.7.X or something... not even 1.8.
<roaksoax> timello: right... I'd suggest you try 1.9 for now, since 1.10 is just a transitional release and will be suprseeded by 2.0
<timello> roaksoax: ok, let me try a downgrade
<timello> roaksoax: thanks
#maas 2016-03-08
<param> how to set servers to pxe boot
<param> hello anyone there
<voidspace> how do you edit the cluster interface in maas 2.0?
<mup> Bug #1554494 opened: Preparation of RegionAdvertisingService failed: MultipleObjectsReturned: Got more than one node <MAAS:Triaged> <https://launchpad.net/bugs/1554494>
<roaksoax> voidspace: http://maas.ubuntu.com/docs2.0/rack-configuration.html
<roaksoax> voidspace: you don't
<roaksoax> at least not in the same way people used to
<voidspace> roaksoax: ah, ok - I'm trying to enlist nodes
<voidspace> will read these docs, I was reading the development trunk ones... which are obviously for 1.9 then
<roaksoax> voidspace: http://maas.ubuntu.com/docs2.0/rack-configuration.html#enabling-a-rack-controller-to-provide-dhcp-on-a-vlan
<voidspace> roaksoax: great
<voidspace> roaksoax: the nodes page says "maas maas nodes accept-all" to enable auto-enlist
<voidspace> roaksoax: the command line tool says that accept-all is an invalid choice
<voidspace> roaksoax: ah, they have appeared
<voidspace> they were just slow, sorry
<roaksoax> np!
<roaksoax> voidspace: the 2.0 docs are ebing updated
<roaksoax> so you will definietely find places wher eit doens't match or is incorrect
<voidspace> roaksoax: I figured :-)
<mup> Bug #1554514 opened: system_controller.py: AttributeError: 'NoneType' object has no attribute 'addBoth' <MAAS:Triaged> <https://launchpad.net/bugs/1554514>
<mup> Bug #1554530 opened: Failed to update this region's process and endpoints: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554530>
<mup> Bug #1554532 opened: Database error during start-up: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554532>
<mup> Bug #1554530 changed: Failed to update this region's process and endpoints: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554530>
<mup> Bug #1554532 changed: Database error during start-up: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554532>
<mup> Bug #1554530 opened: Failed to update this region's process and endpoints: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554530>
<mup> Bug #1554532 opened: Database error during start-up: deadlock detected <MAAS:Triaged> <https://launchpad.net/bugs/1554532>
<mup> Bug #1554566 opened: [2.0a1] PXE interface is incorrectly determined <MAAS:New> <https://launchpad.net/bugs/1554566>
<mup> Bug #1554568 opened: [2.0a1] Can't look at full node event log: No item with pk: events <MAAS:New> <https://launchpad.net/bugs/1554568>
<mimizone> is there a changelog of what maas 2.0 brings, at least the main features and the change of architecture and underlying technologies?
<mimizone> and will it be an LTS release too?
<voidspace> when I try to commission a KVM instance with 2.0 I get "modproble: ERROR: could not insert ipmi_si: no such device"
<voidspace> The requested URL returned error: 400 BAD REQUEST
<voidspace> failed to enlist system maas server
<voidspace> any ideas why?
<roaksoax> mimizone: have you looked into maas.ubuntu.com/docs2.0/changelog.html ?
<voidspace> ah, maybe I need libvirt on the maas controller
<mimizone> roaksoax: thanks. I couldn't find that page by just browsing the maas web page somehow.
<voidspace> no, that didn't fix it
<voidspace> roaksoax: blake_r: any idea about the ipm_si / BAD REQUEST problem above?
<roaksoax> voidspace: ipmi_si, is that a IPMI based machine ?
<voidspace> roaksoax: the maas controller and the nodes I'm enlisting are KVM instances
<voidspace> roaksoax: which is another way of saying, I have no idea...
<roaksoax> voidspace: ok, so the ipmi_si is just saying that you dont have IPMI
<roaksoax> voidspace: which is correct
<roaksoax> voidspace: the 400 BAD REQUEST, is the rack controller up and running successfully ?
<voidspace> roaksoax: as far as I can tell - how would I check? The web ui seems to indicate everything is ok as far as I can see.
<roaksoax> voidspace: check the log /var/log/maas/*.log
<voidspace> ooh - rackd.log
<voidspace> 2016-03-08 17:36:15+0000 [HTTPPageGetter,client] Starting TFTP back-end failed.
<voidspace> quite a few of that
<roaksoax> voidspace: check the rack controller page, and check the interfaces section and see if they are all correct and keep disappearing
<voidspace> roaksoax: there a traceback in regiond.log as well
<voidspace> pastebinning
<voidspace> roaksoax: http://pastebin.ubuntu.com/15329173/
<voidspace> rack controller page looks good
<voidspace> there is an unused interface on the KVM image which apears there as an "unconfigured" interface
<voidspace> maybe I should delete that
<voidspace> roaksoax: so a vanilla install had set the maas-rack-controller api url to localhost
<voidspace> roaksoax: I suspect that was the cause of the error, I've done dpkg-reconfigure and am trying again
<voidspace> not sure though
<mup> Bug #1554636 opened: maas serving old image to nodes <MAAS:New> <https://launchpad.net/bugs/1554636>
<mup> Bug #1554636 changed: maas serving old image to nodes <MAAS:New> <https://launchpad.net/bugs/1554636>
<mup> Bug #1554636 opened: maas serving old image to nodes <MAAS:New> <https://launchpad.net/bugs/1554636>
<roaksoax> v1k0d3n: that may be it
<mup> Bug #1554710 opened: MAAS 2.0alpha doesn't show imported images for commissioning <MAAS:New> <https://launchpad.net/bugs/1554710>
<mup> Bug #1554747 opened: CPU Utilization of postgresql thread reaches 100% for deleting a node from MaaS <MAAS:New> <https://launchpad.net/bugs/1554747>
<roaksoax> 4/win 4
#maas 2016-03-09
<mup> Bug #1554811 opened: [MAAS 2.0 Alpha 1]: Rack Controller Summary page hit back button on browser should take me back to the list of Rack Controllers <MAAS:New> <https://launchpad.net/bugs/1554811>
<mup> Bug #1554814 opened: [MAAS 2.0 Alpha 1]: Can't auto enlist with two Rack Controllers, works with one <MAAS:New> <https://launchpad.net/bugs/1554814>
<imranh_> openstack auopilot install seems to have hung on "Add Juju machine in an LXC on ..."
<imranh_> where do i even start debugging
<mup> Bug #1554999 opened: Can't deploy a node after upgrade to 2.0.0~alpha1+bzr4736-0ubuntu1 from 1.10 <MAAS:New> <https://launchpad.net/bugs/1554999>
<mup> Bug #1555022 opened: Web API: special_filesystems inexplicably missing from rendered Machine <api> <tech-debt> <MAAS:Triaged> <https://launchpad.net/bugs/1555022>
<imranh_> huh so virbr0 has been given 192.168.122.1
<imranh_> 192.168.122.0/24 is an actual range on our network
<imranh_> i wonder if this is why the install has been failing
<mup> Bug #1547276 changed: [2.0a1] "No rack controllers can access the BMC of node: <node>" with wake onlan <MAAS:Triaged> <https://launchpad.net/bugs/1547276>
<mup> Bug #1555178 opened: Spurious failure in TestMachineBlockDeviceListener.test__calls_handler_with_update_on_update <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1555178>
<mup> Bug #1554710 changed: [2.0a1] doesn't show imported images for commissioning <MAAS:New> <https://launchpad.net/bugs/1554710>
<mup> Bug #1554152 changed: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment <amd64> <apport-bug> <landscape> <uec-images>
<mup> <xenial> <cloud-init:Fix Committed> <cloud-init (Ubuntu):Confirmed> <pollinate (Ubuntu):Fix Released by kirkland> <https://launchpad.net/bugs/1554152>
<mup> Bug #1555236 opened: Spurious test failure in TestRegionServer.test_register_calls_refresh_when_needed <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1555236>
<mup> Bug #1555251 opened: [2.0] Missing region-controller API <api> <MAAS:Triaged> <https://launchpad.net/bugs/1555251>
<mup> Bug #1555269 opened: Commissioning yields in BMC password not being updated <MAAS:New> <https://launchpad.net/bugs/1555269>
<mup> Bug #1555308 opened: [2.0a1] Need to add sudoers file for maas-regiond. <packaging> <MAAS:Triaged> <https://launchpad.net/bugs/1555308>
<mup> Bug #1555335 opened: Failure to get custom image root.tgz causes image sources to not update <cdo-qa> <MAAS:New> <https://launchpad.net/bugs/1555335>
<mup> Bug #1555363 opened: "No storage information." commissioning PowerVM (Power 8) <blocks-hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1555363>
<mup> Bug #1555373 opened: MAAS 2.0alpha doesn't show correct amount of memory or # of cores after commissioning <MAAS:New> <https://launchpad.net/bugs/1555373>
#maas 2016-03-10
<mup> Bug #1555392 opened: [2.0a1] python3-maas-client needs to send data as bytes() <MAAS:New> <https://launchpad.net/bugs/1555392>
<mup> Bug #1555393 opened: [2.0a1] python3-maas-client API 2.0 seems to no longer use op but MAASClient.post requires it and incorectly passes it along <MAAS:New> <https://launchpad.net/bugs/1555393>
<mup> Bug #1539739 changed: Memory size reported by MAAS less than actual memory size by 1GB for commissioned VM <oil> <MAAS:Confirmed> <https://launchpad.net/bugs/1539739>
<mup> Bug #1555406 opened: API needs to report what images have been sync to what rack controllers <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1555406>
<mup> Bug #1555570 opened: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1555570 changed: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1555595 opened: Changes in the UI between versions are not detected unless you clear browser cache <MAAS:Confirmed> <https://launchpad.net/bugs/1555595>
<mup> Bug #1555597 opened: My previously managed network in 1.10 was migrated to 2.0 with DHCP disabled <MAAS:New> <https://launchpad.net/bugs/1555597>
<imranh_> going to assume an autopilot install of openstack shouldn't take 24hours+
<mup> Bug #1555597 changed: My previously managed network in 1.10 was migrated to 2.0 with DHCP disabled <MAAS:New> <https://launchpad.net/bugs/1555597>
<imranh_> found an error message in my install logs
<imranh_> "465 error fetching public address: "public no address""
<voidspace> roaksoax: you marked my bug as a duplicate
<voidspace> roaksoax: it's not *obviously* a duplicate of the one you linked it to
<voidspace> roaksoax: do you think when that bug is fixed I'll be able to commission nodes - or is there something else going on?
<roaksoax> voidspace: you are running MAAS on the host system
<roaksoax> voidspace: err
<roaksoax> and KVM's on that host system
<roaksoax> and trying to get MAAS to manage them right?
<voidspace> roaksoax: no, I'm running MAAS in a KVM too
<voidspace> roaksoax: maas controller and maas nodes on the same KVM defined network
<voidspace> with maas running dhcp
<roaksoax> voidspace: right, so I think it may still be related bug
<voidspace> ok
<roaksoax> voidspace: so does the rack have interfaces ? If so, are any of those interfaces the same as the IP fo the BMC ?
<roaksoax> voidspace: i.e, the gateway maybe ?
<roaksoax> or and actualy interface ?
<voidspace> roaksoax: maas rack controller is running on a machine with a single nic - ip is 172.16.0.2, gateway is 172.16.0.1
<roaksoax> voidspace: the BMC of the VM's you are trying to manage, what's the IP ?
<voidspace> roaksoax: BMC?
<roaksoax> voidspace: how are you trying to power manage the VM's ?
<voidspace> roaksoax: ah, I'm not - manually starting them
<voidspace> roaksoax: if I was power managing them I'd put virsh connection strings into the power type
<voidspace> so no bmc
<roaksoax> voidspace: right, so virsh -> BMC in maas terms
<roaksoax> voidspace: ok, if you can share with me a console log I could probably try to discover why it is happening
<voidspace> roaksoax: ok, I've diverted to looking at another bug - I'll come back to you on this
<voidspace> roaksoax: I really appreciate your help
<imranh_> well i'm giving up on using maas/landscape/autopilot
<mup> Bug #1555673 opened: [2.0a1] Rack Controller interfaces UI appears greyed out. <MAAS:Confirmed> <https://launchpad.net/bugs/1555673>
<voidspace> roaksoax: ok, what sort of console log do you want - I do most things through the ui
<voidspace> roaksoax: I can get you any of the maas log files though
<roaksoax> voidspace: the consolo log from the commissioning process..
<voidspace> roaksoax: ah
<voidspace> roaksoax: ok
<voidspace> roaksoax: the "Settings" tab says "
<voidspace> One rack controller is not yet connected to the region. Visit the rack controllers page for more information."
<voidspace> roaksoax: yet the rack controller page shows no error
<voidspace> Interesting, on the settings page the Commissioning section is showing "No Usable Release" for default release used for commissioning
<voidspace> same for deploy
<voidspace> and now I can't enlist, time to reinstall again I think
<mup> Bug #1555679 opened: [2.0a1] bridges with same mac as physical interfaces prevent rack interface discovery <MAAS:New> <https://launchpad.net/bugs/1555679>
<mup> Bug #1555703 opened: [2.0a1] network provisioningserver code fails to parse ipv6 routes <MAAS:New> <https://launchpad.net/bugs/1555703>
<mup> Bug #1555703 changed: [2.0a1] network provisioningserver code fails to parse ipv6 routes <MAAS:New> <https://launchpad.net/bugs/1555703>
<mup> Bug #1555703 opened: [2.0a1] network provisioningserver code fails to parse ipv6 routes <MAAS:New> <https://launchpad.net/bugs/1555703>
<mup> Bug #1555715 opened: [2.0a1] changing a subnet's space does not cause a refresh in networks/spaces tab in the UI <MAAS:New> <https://launchpad.net/bugs/1555715>
<mag009_> i just upgraded to 2.0 anyone have having issue with tftp not being able to bind to port 69 ? permission denied which is normal since it's running as maas user
<mag009_> ok i found out
<mag009_> you guys use... authbind but it seem the package isn't configuring the port...
<mup> Bug #1555736 opened: [2.0a1] Need to release all DHCP leases at the end of commissioning <MAAS:Triaged> <https://launchpad.net/bugs/1555736>
<mup> Bug #1555759 opened: [2.0a1] If no VLAN has DHCP enabled, MAAS should notify the user. <MAAS:Triaged> <https://launchpad.net/bugs/1555759>
<stormmore> is there an easy way to reset the maas db?
<stormmore> or is a better way to put it, is there a way to reinitialize the db?
<dbainbri> Running into a situation with MAAS where on restart it looses the association between a node and its IP address and thus wipes it from the zone file. an if down/up of the interface on the node doesn't seem to get MAAS to realize the association. Anyway to get the association back and into the zone file?
<roaksoax> dbainbri: is this DHCP ?
<dbainbri> yes
<dbainbri> roaksoax: yes
<roaksoax> dbainbri: is this < 1.8 ?
<dbainbri> from the UI: MAAS Version 1.9.1+bzr4543-0ubuntu1 (trusty1)
<dbainbri> roaksoax: ^
<roaksoax> dbainbri: so you set the interface as DHCP in the web ui ?
<dbainbri> roaksoax: yes
<roaksoax> dbainbri: for a subnet where MAAS is providing DHCP for?
<dbainbri> yes
<roaksoax> dbainbri: interesting.. but that's probably why this happens since the interface is being set to dhcp, so it really is not static
<roaksoax> dbainbri: can you please file a bug and we'll look into it
<dbainbri> soaksoax: so a variable in the equation is i have a host, fixed-address entry in DHCP for this host.
<dbainbri> soaksoax: i don't expect it to be static, but i am surprised that MAAS isn't picking up when a lease is renewed. it may be that with ISC DHCP a fixed-address is treated differently than a real lease.
<roaksoax> dbainbri: hold on, so you are manually making a hostmap in dhcpd for the IP of that interface?
<roaksoax> dbainbri: if that's the case then that'ds the bug
<roaksoax> dbainbri: you can tell MAAS what IP address you want for the interface without having to manually modify that
<mup> Bug #1555363 changed: "No storage information." commissioning PowerVM (Power 8) <MAAS:Invalid> <https://launchpad.net/bugs/1555363>
<dbainbri> soaksoax: it is somewhat temporary (the fixed mapping). if i assign it in MAAS as a "fixed" address with MAAS assign it via DHCP?
<roaksoax> dbainbri: dbainbri if it is sent to dhcp it will dhcp from the dynamic range
<roaksoax> which is not ensure to give you dns mappeins
<roaksoax> dbainbri: if you select an IP for the interface, it will give you the IP you want
<dbainbri> and it will end up in DNS
<roaksoax> dbainbri: yes
<roaksoax> dbainbri: static ip assigments in MAAS (either Auto-assign, or Static, for the PXE interface, will end up in DNS)
<roaksoax> dbainbri: 2.0 adds supports for PTR records for the rest of the IP's
<roaksoax> but the DNS A record will always be given to the PXE interface
<dbainbri> roaksoax: ok thanks. eventually i want all DHCP and don't care about assigning fixed-address, but for now i need more static addresses because of some other software. guess i will change to static IPs in MAAS
<dbainbri> roaksoax: thx
<mup> Bug #1553261 changed: [FFe] Standing FFe for MAAS 2.0 <maas (Ubuntu):Fix Released> <https://launchpad.net/bugs/1553261>
<stormmore> Hey any chance someone could have a quick look at my vlan config https://bpaste.net/show/5b5c65b1d5b3 and make sure I donât have any glaring mistakes?
#maas 2016-03-11
<bradm> anyone seen maas lie about power state?  I've got some HP kit that maas says it powers on, the web ui says its on, but the ilo says its off
<bradm> this only seems to happen when its being deployed, the commissioning worked fine, so I know the power settings are right
<bradm> and its not consistantly doing it, its only since upgrading to 1.9.1+bzr4543-0ubuntu1
<mup> Bug #1555864 opened:  [2.0a1] UI Nodes page shows 'ascii' codec can't decode byte <MAAS:New> <https://launchpad.net/bugs/1555864>
<mup> Bug #1555901 opened: Number of regiond process is not determined <MAAS:Triaged> <https://launchpad.net/bugs/1555901>
<BlackDex> i get the following error during boot in dmesg: [  132.794959] init: maas-regiond-worker (3) main process (4763) terminated with status 1
<BlackDex> [  132.794979] init: maas-regiond-worker (3) main process ended, respawning
<BlackDex> And that happens a lot
<mup> Bug #1556085 opened: adding boot-source keyring_data fails silently <sts> <MAAS:New> <https://launchpad.net/bugs/1556085>
<voidspace> roaksoax: ping
<voidspace> roaksoax: when commissioning fails I can login - how do I disable poweroff?
<voidspace> roaksoax: and what logfiles would be helpful, there's no console.log - there's cloud-init and cloud-init-output
<voidspace> amongst other things
<voidspace> cloud-init-output.log has the error 400s in it
<voidspace> I'll attach those two to my bug
<voidspace> done
<roaksoax> voidspace: can you send me the link of yoiur bug again please
<roaksoax> voidspace: and if you are using 1.9, when you commission there's an option to disable power off
<voidspace> roaksoax: yeah, I selected that... it still powers off
<voidspace> roaksoax: I'll try again to confirm I did it right
<voidspace> roaksoax: https://bugs.launchpad.net/maas/+bug/1555570
<roaksoax> voidspace: interesting, then cloud-init might be doing something it should...
<roaksoax> voidspace: oh, you ar enot commissioning, you are enlisting
<voidspace> roaksoax: no, I'm commissioning
<voidspace> roaksoax: enlisting works, it's commissioning that doesn't
<voidspace> trying again, *definitely* selected disable power off
<roaksoax> voidspace: failed to enlist system maas server
<roaksoax> sleeping 60 seconds then poweroff
<roaksoax> voidspace: the cloud-init-output you attached is not for commissioning, it is for enlistment
<voidspace> well, I commssion and then reboot the machine manually
<voidspace> ah yes, indeed it says that
<voidspace> but I'm *trying* to commission
<roaksoax> voidspace: based on the log, that doesn't seem a commissioning
<voidspace> so it seems the bug then is "maas doesn't commission but tries to re-enlist"
<roaksoax> voidspace: questions:
<roaksoax> 1. does the machine in MAAS have *all* mac addresses of the system?
<roaksoax> 2. is the system trying to PXE boot from a mac address/interface that's not in MAAS ?
<roaksoax> voidspace: i'd say: 1. delete the machine in maas. 2. let it auto-enlist. 3. once the machine is in 'New' state, try to commission and see what happens
<voidspace> roaksoax: that machine has one interface (one mac) and is pxe booting from maas
<voidspace> roaksoax: that is exactly what I've been doing, repeatedly
<voidspace> roaksoax: I have deleted and re-enlisted multiple times with multiple fresh installs
<roaksoax> voidspace: the only reason why I'd think the machine is trying to enlist even though it should be commissioning, it is because MAAS is detecting a different MAC address than the one it has stored
<voidspace> roaksoax: I can provide maas logs
<roaksoax> voidspace: please do
<voidspace> roaksoax: regiond, rackd and maas logs attached
<voidspace> roaksoax: this same setup behaves fine with maas 1.9
<roaksoax> voidspace: thanks
<roaksoax> voidspace: : http://pastebin.ubuntu.com/15347930/
<roaksoax> voidspace: can you show /etc/maas/regiond.conf and /etc/maas/rackd.conf ?
<voidspace> ok
<mup> Bug #1555570 opened: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1556138 opened: maas regiond upgrade from 1.8.2 to 1.9.1 silently failed <MAAS:New> <https://launchpad.net/bugs/1556138>
<voidspace> roaksoax: done
<voidspace> roaksoax: rackd.conf shows localhost as the url - which is what I get after a default install
<voidspace> roaksoax: if I reconfigure maas-rack-controller and put in the url http://172.16.0.2:5240/MAAS then the rack controller reports it can't connect to the region
<roaksoax> voidspace: what version of 1.2 ?
<roaksoax> 2.0
<roaksoax> err 2.0
<voidspace> roaksoax: whatever is in next-proposed as of a couple of hours ago
<roaksoax> voidspace: is 172.16.0.2 inside a network that the machines can commitcate with ?
<voidspace> yes
<roaksoax> voidspace: are you willing to try something even more bleeding edge ?
<voidspace> roaksoax: yes, but after I go collect my daughter from school
<voidspace> roaksoax: if you pastebin instructions on how to install from source (or link to them) then I'll try after I get back
<roaksoax> voidspace: ppa:maas-maintainers/experimental3
<voidspace> roaksoax: I'm installing on disposable VMs
<voidspace> roaksoax: ah, cool
<voidspace> thanks
<mup> Bug #1532935 opened: Nodes stuck at grub menu when attempting to Autopilot deploy <cdo-qa> <MAAS:Confirmed> <https://launchpad.net/bugs/1532935>
<mup> Bug #1555570 changed: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1556153 opened: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <MAAS:New> <https://launchpad.net/bugs/1556153>
<roaksoax> voidspace: also, please attach maas <maas-user> interfaces read <node-system-id> the output of that to your bug
<roaksoax> voidspace: i think it si related to other thing
<voidspace> roaksoax: ok, cloning a vm right now
<roaksoax> voidspace: https://bugs.launchpad.net/maas/+bug/1555570/comments/11
<mup> Bug #1556153 changed: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <MAAS:New> <https://launchpad.net/bugs/1556153>
<mup> Bug #1555570 opened: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1556153 opened: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <MAAS:New> <https://launchpad.net/bugs/1556153>
<mup> Bug #1556158 opened: Spurious test failure in TestRegionProtocol_SendEvent.test_send_event_does_not_fail_if_unknown_type <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1556158>
<mup> Bug #1555570 changed: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1556158 changed: Spurious test failure in TestRegionProtocol_SendEvent.test_send_event_does_not_fail_if_unknown_type <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1556158>
<mup> Bug #1555570 opened: Problem commissioning nodes (2.0) <MAAS:New> <https://launchpad.net/bugs/1555570>
<mup> Bug #1556158 opened: Spurious test failure in TestRegionProtocol_SendEvent.test_send_event_does_not_fail_if_unknown_type <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1556158>
<mup> Bug #1556185 opened: TypeError: 'Machine' object is not iterable <MAAS:New> <https://launchpad.net/bugs/1556185>
<mup> Bug #1556188 opened: Spurious test failure in TestMachinePartitionListener.test__calls_handler_with_update_on_update <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1556188>
<Free99> Hey everyone, new to MaaS. I'm having an issue where I deploy 14.04 to my IPMI nodes, but I get "Deployment Failed"
<Free99> I can't seem to find any details in maas.log, regiond.log or clusterd.log as to why this step fails
<Free99> Interestingly, I think the system properly installs
<Bofu2U> Free99: have you looked at the screen or watched it through IPMI when it's deploying?
<Free99> Bofu2U, yeah, only thing that shows up is an sr0 error..
<Free99> what would the CD drive have to do with this though?
<Bofu2U> nothing that I can think of
<Bofu2U> you're talking about a server you're trying to boot into maas through discovery, right?
<Bofu2U> not the head node/master/whatever
<Free99> right.. I got it registered properly with maas, it booted the tftp image.. but then the webui jumps to "deployment failed after about 5-10 minutes
<Free99> only complication here: DHCP is provided by my gateway
<Bofu2U> does the image load/boot properly ?
<Bofu2U> (in other words does it start booting through PXE, TFTP, etc)
<Bofu2U> only times I've run into something like that was when the node couldn't access something at some point (yes, vague as hell) - I deleted it from maas entirely and rebooted it so it went back through discovery, etc
<Free99> crud I hope I don't need to do that
<Bofu2U> also note I'm talking about
<Bofu2U> deleted the node from maas
<Bofu2U> not maas as it's entirety
<Free99> no I know, but still... 10 nodes
<Bofu2U> oh it's on all 10?
<Bofu2U> err
<Bofu2U> May want to wait around and see if anyone else has any ideas then :(
<Free99> ok, so the one node I directly watched boot gets all the way to the login screen
<Free99> but... maas still says "deploying"
<Bofu2U> and is this on commissioning
<Bofu2U> or deploying
<Free99> just deploying
<Bofu2U> on the prompt is the server name ubuntu
<Bofu2U> or the correct name set in MAAS
<Free99> commissioning worked, it figured out the disk layout and blah blah
<Free99> coreect name, node-7
<Bofu2U> go back to your MAAS properties on that server, make sure the IP is set
<Free99> can't modify it unless ready or broken
<Bofu2U> is there an IP set at all?
<Bofu2U> it sounds like it gets to the prompt and then can't connect back to the headnode to let it know it's finished deploying
<Free99> seems like it, DHCP lease list on my gateway indicates the right FQDN has an ip, and it responds to ping
<Free99> can't ssh in though in spite of the public key
<Free99> *in spite of adding my public key
<Bofu2U> but SSH does get through?
<Bofu2U> aka it connects properly, but then fails due to auth
<Free99> auth fails but I can ssh from the maas control server
<Bofu2U> ok so it can talk then
<Bofu2U> hm
<Bofu2U> nothing else comes up on the login screen? like apt-get randomly or anything like that
<Free99> nope, not even that sr0 error
<Bofu2U> ok do you have any nodes still in "deploying" state
<Bofu2U> aka haven't failed yet
<Free99> no
<Bofu2U> This is going to sound a bit ... weird but, sometimes it worked for me and I have absolutely no idea why
<Free99> I only tried deploying to this one node which I have a display connected to... figure if I can get this one working I'll get all of them
<Bofu2U> go through the process again with 1 node
<Bofu2U> discovery, then commission
<Bofu2U> then deploy
<Bofu2U> every time you see it boot up, hit the F<whatever> key to forcibly select the boot sequence into PXE
<Bofu2U> there's also ways to "backdoor" your image to put a user/pass so you can login but I wasn't able to make that work :-/
<Free99> yeah I saw
<Free99> sheesh... this software seems a little rough around the edges
<Free99> can't add an ECDSA or ed25519 key
<Bofu2U> heh
<Bofu2U> yeah there's a few quirks that would be nice if they were different
<Bofu2U> like not taking almost 2 weeks to figure out how to add centos images to it
<Bofu2U> you know, small things :P
<Free99> they mention windows image support, but no docs!
<Free99> I'll write to docs, no problem, but I gotta get it to work at all
<Bofu2U> I know the feeling
<Bofu2U> :)
<Free99> Bofu2U, another question: does the system install to local disk at all?
<Bofu2U> yes
<Free99> it doesn't seem to though
<Bofu2U> that's the problem you're running into then
<Free99> but how did it boot?
<Bofu2U> PXE
<Free99> it's just ram resident?
<Bofu2U> yeah the curtain installer
<Bofu2U> that's what the final reboot is on the deploy
<Bofu2U> it hits PXE, PXE tells it to boot off local disk
<Free99> how do I watch what curtain is doing?
<Bofu2U> through the IPMI
<Bofu2U> so, the first is the initial boot and info gathering
<Bofu2U> that won't touch the disk, just gets it into MAAS. Doesn't get RAM/CPUs, but will pull IPMI specs
<Bofu2U> then you commission and it gathers more information such as the RAM, CPU, etc.
<Bofu2U> then deploy, and it writes to disk, does all of that, and then reboots and PXE tells it to boot from that disk
<Bofu2U> hopefully that makes sense - just going off of what I remember from the process overall
<Free99> sure does, I've gotten to the deploy stage.. and that's it
<Bofu2U> yeah
<Bofu2U> just because I think it would be an interesting test
<Bofu2U> have you tried hitting the bios and disabling the CD ROM?
<Free99> I'll try that if this deploy fails
<Free99> got back to the login screen, correctly named node-7
<Free99> latest event is PXE request - curtin install
<Free99> but no visible disk activity
<Free99> hmm... I did set to install with LVM, maybe I ought to revert to flat disk layout..
<Bofu2U> worth trying
<Free99> Bofu2U, I'm going to recommission this one node.. should I allow SSH? retain network?
<Bofu2U> I did that just so I could try to test it
<Bofu2U> I think the login is ubuntu/ubuntu
<Free99> the network is DHCP, with dhcp registering hostnames in dns automatically
<Free99> I love linux
<Free99> and bsd too
<Free99> sometimes the software is really cranky though
<mup> Bug #1556219 opened: maas enlistment of power8 found ipmi 1.5 should do ipmi 2.0 <MAAS:New> <https://launchpad.net/bugs/1556219>
<Free99> weird, it just denies my logging in due to publickkey
<Free99> doesn't even prompt for a pass :-/
<Bofu2U> try from ipmi?
<Free99> Bofu2U, I've never used SOL before. do I need to add a kernel line to redirect to com1?
<Bofu2U> what kind of servers?
<Free99> it's a dell with iDrac 5 I think
<Free99> ipmi 2
<Bofu2U> login to the web, and try to load ... usually called "virtual console"
<Bofu2U> don't need actual SOL
<Free99> think they added that webconsole thing in idrac 6
<Bofu2U> ah crap
<Free99> any way to increase verbosity on all this stuff?
<Bofu2U> don't know :(
<Bofu2U> sorry
<Free99> ubuntu/ubuntu doesn't work as a login here
<Free99> ah ha! with the key I added in the Maas dashboard, I have to login to the nodes with ubuntu@hostname and use the same key I added to my dashboard login
<Bofu2U> ahhh ok
<Free99> ok so check it: cloud-init-output.log says error encountered setting up postfix
<Bofu2U> o.O
<Free99> ok, what logs would help figure this out?
<Free99> I've got em all
<voidspace> roaksoax: so the version from that experimental ppa certainly behaves *differently*
<voidspace> roaksoax: with that version the nodes don't enlist
<Free99> why can't I set an FQDN?
<Free99> http://paste.ubuntu.com/15349884/ <-- my setup fails because of this
<Free99> I think there's a bug here folks
<Free99> can anyone please help with this cloud-init issue?
<mup> Bug #1556258 opened: boot source keyring data is sometimes outputted as memoryview object <MAAS:Triaged> <https://launchpad.net/bugs/1556258>
<Free99> dang it :[
<Free99> I wish I could figure out why maas 1.9.7 is adding an extraneous period to my postfix file which borks the whole deployment
<mpontillo> Free99: can you file a bug? I think it's maybe a postfix bug TBH; that is a valid and proper FQDN
<mpontillo> See http://tools.ietf.org/html/rfc1034 section 3.1
<roaksoax> voidspace: i have managed to enlist machines with the one on experimental, howeve,r I hit your issue
#maas 2016-03-12
<mup> Bug #1554814 changed: [2.0a1]: Can't auto enlist with two Rack Controllers, works with one <MAAS:Invalid> <https://launchpad.net/bugs/1554814>
<mup> Bug #1554814 opened: [2.0a1]: Can't auto enlist with two Rack Controllers, works with one <MAAS:Invalid> <https://launchpad.net/bugs/1554814>
<mup> Bug #1554814 changed: [2.0a1]: Can't auto enlist with two Rack Controllers, works with one <MAAS:Invalid> <https://launchpad.net/bugs/1554814>
<mup> Bug #1554814 opened: [2.0a1]: Can't auto enlist with two Rack Controllers, works with one <MAAS:Incomplete> <https://launchpad.net/bugs/1554814>
<mup> Bug #1556343 opened: [2.0a1] Service tracking of rackd broken rack registration <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1556343>
<mup> Bug #1556345 opened: django.db.utils.ProgrammingError: relation "maasserver_bmcroutablerackcontrollerrelationship" does not exist <MAAS:New> <https://launchpad.net/bugs/1556345>
<mup> Bug #1556345 changed: django.db.utils.ProgrammingError: relation "maasserver_bmcroutablerackcontrollerrelationship" does not exist <MAAS:Invalid> <https://launchpad.net/bugs/1556345>
<mup> Bug #1556354 opened: [2.0a1] maas-dhcpd and maas-dhcpd6 should use KillMode=SIGKILL <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1556354>
<mup> Bug #1550435 changed: boot sector signature not found on first boot after deploy on raid array <MAAS:Incomplete> <https://launchpad.net/bugs/1550435>
<mup> Bug #1556358 opened: [2.0prea2] django.core.exceptions.ValidationError: {'mac_address': ["'74:d4:35:89:bb:c' is not a valid MAC address."]} <MAAS:New> <https://launchpad.net/bugs/1556358>
<mup> Bug #1556360 opened: [2.0pre-a2] MAAS dhcp keeps dying <MAAS:New> <https://launchpad.net/bugs/1556360>
<mup> Bug #1556366 opened: [2.0a1] PXE interface incorrectly displayed on the UI <MAAS:New> <https://launchpad.net/bugs/1556366>
<mup> Bug #1556431 opened: [2.0a2] MAAS should give an appropriate error if the BMC password is incorrect <MAAS:New> <https://launchpad.net/bugs/1556431>
<pete_> gi
<pete_> hi
<pete_> can anyone tell me where images are saved whilst they are being downloaded ( or where I can see some sort of progress indicator )
<Free99> hey pete_ the images default to being saved in /var/lib/maas/boot<something or other>
<Free99> depends on your version of MAAs too, be aware the files aren't saved as ISOs or anything, they're gzipped clones of a disk (at least, that's what it looks like)
<pete_> Thanks Free99
<krypto> hi is there a way to specify a different tftp server for a particular MAC?
<krypto> i am adding new servers which should get a differnt Operating system
<krypto> and that is available in office TFTP server only
<krypto> any idea?
#maas 2016-03-13
<nzcarrick> just curious if I can build a custom build image which is for windows, rather than upgrade to professional to get the windows build?
<nzcarrick> when i say Professional i mean "Ubuntu Advantage - Professional" level
#maas 2017-03-06
<mup> Bug #1617195 opened: Cannot collapse commissioning script <MAAS:New for ricgard> <MAAS 2.0:Won't Fix> <MAAS trunk:New for ricgard> <https://launchpad.net/bugs/1617195>
<mup> Bug #1670326 opened: [2.2] Event log page gets unformatted when browsing all events <MAAS:New> <https://launchpad.net/bugs/1670326>
<mup> Bug #1670337 opened: Toggling between Name/MAC in Interfaces section doesn't work <MAAS:New> <https://launchpad.net/bugs/1670337>
<Braven> hello
<junaidal1> Hi roaksoax , what is the difference between ephemeral v2 and v3 in maas images?
<junaidal1> There is only daily stream in v3 as compared to v2 where release stream is also available. Will release stream be put in v3 as well in near future?
<mup> Bug #1670429 opened: Cannot navigate away from device discovery <MAAS:New for ricgard> <https://launchpad.net/bugs/1670429>
<mup> Bug #1670444 opened: MAAS ephemeral boot environments should include the system hostname in /etc/hosts <MAAS:New> <https://launchpad.net/bugs/1670444>
<mup> Bug #1670479 opened: [2.1.4] maas discards space after upgrade to 2.2 beta3 and moves subnet under separate space in same fabric <oil> <MAAS:New> <https://launchpad.net/bugs/1670479>
<mup> Bug #1670479 changed: [2.1.4] maas discards space after upgrade to 2.2 beta3 and moves subnet under separate space in same fabric <oil> <MAAS:New> <https://launchpad.net/bugs/1670479>
<mup> Bug #1670479 opened: [2.1.4] maas discards space after upgrade to 2.2 beta3 and moves subnet under separate space in same fabric <oil> <MAAS:New> <https://launchpad.net/bugs/1670479>
<mup> Bug #1670484 opened: [2.2 beta3] can't I detach subnet from space using the UI <oil> <MAAS:New> <https://launchpad.net/bugs/1670484>
<mup> Bug #1670484 changed: [2.2 beta3] can't I detach subnet from space using the UI <oil> <MAAS:New> <https://launchpad.net/bugs/1670484>
<mup> Bug #1670484 opened: [2.2 beta3] can't I detach subnet from space using the UI <oil> <MAAS:New> <https://launchpad.net/bugs/1670484>
<mup> Bug #1570407 changed: Unable to shut node down errors causing failures on client side <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1570407>
<crazik> hi
<mup> Bug #1670479 changed: [2.1.4] maas discards space after upgrade to 2.2 beta3 and moves subnet under separate space in same fabric <oil> <MAAS:Won't Fix> <https://launchpad.net/bugs/1670479>
<roaksoax> junaidal1: no, v3 stream introduces newer descriptions for various new things (i.e bootladers, the new HWE kernel convention naming, etc). There will only be 'daily' for v3 streams
<mup> Bug #1670484 changed: [2.2 beta3] can't I detach subnet from space using the UI <oil> <MAAS:Invalid> <https://launchpad.net/bugs/1670484>
<mup> Bug #1670499 opened: maas 2.1.3 kvm nodes do not deploy, Juju reports 'started but not deployed'  <cdo-qa-blocker> <MAAS:Incomplete> <https://launchpad.net/bugs/1670499>
#maas 2017-03-07
<mup> Bug #1667574 opened: default gateway not set when deploying a machine with two interfaces in same network <sts> <MAAS:New> <https://launchpad.net/bugs/1667574>
<junaidal1> Thanks roaksoax , understood.
<mup> Bug #1670614 opened: Unable to change static ip in API interfaces link_subnet <MAAS:New> <https://launchpad.net/bugs/1670614>
<mup> Bug #1670614 changed: Unable to change static ip in API interfaces link_subnet <MAAS:Invalid> <https://launchpad.net/bugs/1670614>
<mup> Bug #1670821 opened: [2.2 beta3] System with single disk fails to commission - smarctl-validate() fails <cdo-qa-blocker> <oil> <MAAS:New> <https://launchpad.net/bugs/1670821>
<mup> Bug #1668703 changed: Use external NTP servers only option has no effect <MAAS:Invalid> <https://launchpad.net/bugs/1668703>
<mup> Bug #1668703 opened: Use external NTP servers only option has no effect <MAAS:Invalid> <https://launchpad.net/bugs/1668703>
<mup> Bug #1668703 changed: Use external NTP servers only option has no effect <MAAS:Invalid> <https://launchpad.net/bugs/1668703>
<mup> Bug #1670886 opened: BIND config should include option "empty-zones-enable no" <MAAS:New> <https://launchpad.net/bugs/1670886>
#maas 2017-03-08
<mup> Bug #1670886 changed: BIND config should include option "empty-zones-enable no" <MAAS:New> <https://launchpad.net/bugs/1670886>
<mup> Bug #1670886 opened: BIND config should include option "empty-zones-enable no" <MAAS:New> <https://launchpad.net/bugs/1670886>
<Hetfield> good morning. i think i have an issue with maas networking, i'm using latest 2.1.3 version
<Hetfield> i have a machine with 2 eth ports, on different spaces
<Hetfield> with juju i try: juju deploy ceph-osd --constraints spaces=management
<Hetfield> where management is the primary space
<Hetfield> in maas.log i see
<Hetfield> Mar  8 07:57:52 maas maas.api: [info] Request from user admin to acquire a machine with constraints <QueryDict: {'interfaces': ['0:space=1'], 'zone': ['CDM'], 'agent_name': ['acc01708-cf3b-4970-826e-37422930d18f']}>
<Hetfield> so space=1 is invoked, but i see that juju gets the public ip from the secondary interface.
<Hetfield> which should be a private one and not accessible from juju machine. the strange thing is that machine hostname resolves to the primary "management" space, so i'm really curious why it gets the secondary address
<mup> Bug #1671048 opened: [2.1.4]Expecting object recived tuple in get_default_dns_servers <MAAS:New> <https://launchpad.net/bugs/1671048>
<cnf> how do i get the MAAS proxy to allow ports that are not 443?
<kukacz> hi, I got troubles with PXE booting UEFI image from MAAS 2.1.4 - it ends in Grub commandline
<kukacz> from Grub I can exit, confirm BIOS prompt asking for continue, then it loads and boots that discovery image correctly
<kukacz> any first attempt after server reboot fails, however
<kukacz> any ideas what could be wrong?
<kiko> the last time this happened we concluded it was a problem with grub
<kiko> does typing normal at the grub prompt boot the system?
<kiko> are you deploying 14.04 or 16.04?
<kukacz> kiko: deploying 16.04
<kukacz> kiko: I haven't tried that "normal", will do
<kiko> references:
<kiko> https://bugs.launchpad.net/maas/+bug/1532935
<kiko> https://bugs.launchpad.net/maas/+bug/1437353
<kukacz> "normal" did not help, it just returned to prompt
<kukacz> however "exit" and "continue" (BIOS menu) always successds
<kukacz> succeeds
<kiko> kukacz, I wonder if you could easily capture a video of that including firmware revisions etc and attach that to a bug?
<kiko> it should always work, but there are known firmware issues that we may not yet work around
<kukacz> I'll go through those bugs to identify which one might be related and attach that video possibly
<kukacz> firmware - you mean NIC firmware? I may give it a try - it's intel x520 in Dell servers
<kiko> kukacz, great I suggest putting it into a new bug as those are a bit stale -- we can easily dupe if necessary
<tychicus> is it possible to change the maas default domain?
<tychicus> default domain only appears on the web interface it does not appear in the CLI
<kiko> kukacz, both NIC and system firmware if possible
<kiko> tychicus, from ".maas" to something else?
<kiko> tychicus, that would be a bug
<kiko> could you file it?
<tychicus> @kiko correct from .maas to something else
<kiko> you can change the domain from the UI for sure
<tychicus> it seems like you can add a domain, but not change the default
<tychicus> ok, just verified that you can update the default domain from the cli
<tychicus> kiko bugs should be filed here https://bugs.launchpad.net/maas
<kiko> tychicus, yep
<tychicus> to clarify the we ui displays something like maas (default), there is no such concept in the cli, my guess (without looking at the code) is that the default domain is inferred from the domain id of 0
<tychicus> either way, I'll write up a bug report, thanks!
<kiko> thanks tychicus
<tychicus> sure, loving maas so far, glad to help out in any way I can
<kiko> tychicus, wow, that's great to hear -- what are you using it for?
<tychicus> kiko, currently testing openstack deployments and playing with juju
<tychicus> I have not attempted to deploy windows using maas yet, but that is on my list of things to do
<kiko> cool, keep me posted on your progress
<tychicus> I really like the new features in 2.0 and 2.1 that allow you to setup networking and disk layouts, once the machine has been commissioned
<mup> Bug #1671201 opened: juju bootstrap maas maas-controller: No available machine matches constraints <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1671201>
<mup> Bug #1671242 opened: [2.1.3] maas cli  does not indicate which domain is default <MAAS:New> <https://launchpad.net/bugs/1671242>
<mup> Bug #1671275 opened: MAAS rescue mode cannot run snap binaries <maas (Ubuntu):New> <https://launchpad.net/bugs/1671275>
<mup> Bug #1671274 opened: network interface doesn't come up after installation in VM <cdo-qa-blocker> <MAAS:New> <https://launchpad.net/bugs/1671274>
#maas 2017-03-09
<mup> Bug #1671320 opened: MaaS should set /etc/environment with appropriate proxy settings for rescue mode <maas (Ubuntu):New> <https://launchpad.net/bugs/1671320>
<mup> Bug #1671320 changed: MaaS should set /etc/environment with appropriate proxy settings for rescue mode <maas (Ubuntu):New> <https://launchpad.net/bugs/1671320>
<mup> Bug #1671320 opened: MaaS should set /etc/environment with appropriate proxy settings for rescue mode <maas (Ubuntu):New> <https://launchpad.net/bugs/1671320>
<bryanb229> hello
<bryanb229> is anyone having issues w/ the centos 7 install hanging after deployment?
<mup> Bug #1671415 opened: [2.2] Cannot edit or delete container interfaces <MAAS:Triaged> <https://launchpad.net/bugs/1671415>
<mup> Bug #1671275 changed: MAAS rescue mode cannot run snap binaries <maas (Ubuntu):New> <https://launchpad.net/bugs/1671275>
<mup> Bug #1671274 changed: network interface doesn't come up after installation in VM <cdo-qa-blocker> <cloud-init:New> <curtin:New> <MAAS:Invalid> <https://launchpad.net/bugs/1671274>
<mup> Bug #1671517 opened: Wrong ordering of ranges <MAAS:New> <https://launchpad.net/bugs/1671517>
<mup> Bug #1671517 changed: Wrong ordering of ranges <MAAS:New> <https://launchpad.net/bugs/1671517>
<mup> Bug #1671517 opened: Wrong ordering of ranges <MAAS:New> <https://launchpad.net/bugs/1671517>
<mup> Bug #1671520 opened: Discoveries are never forgoten <MAAS:Triaged> <https://launchpad.net/bugs/1671520>
<pathompongh> can maas has a single nic
<pathompongh> ?
<roaksoax> pathompongh: yes
<mup> Bug #1671605 opened: Unbootable system after installation <MAAS:New> <https://launchpad.net/bugs/1671605>
<mup> Bug #1671605 changed: Unbootable system after installation <MAAS:New> <https://launchpad.net/bugs/1671605>
<mup> Bug #1671605 opened: Unbootable system after installation <MAAS:New> <https://launchpad.net/bugs/1671605>
<mup> Bug #1671616 opened: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
<mup> Bug #1671616 opened: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
<mup> Bug #1671616 changed: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
<mup> Bug #1671616 opened: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
<mup> Bug #1671651 opened: [2.2 beta3] multiple machines allocated and do not transition to Deploying <cdo-qa-blocker> <oil> <MAAS:New> <https://launchpad.net/bugs/1671651>
<mup> Bug #1671616 changed: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
<mup> Bug #1671616 changed: UI cannot change fabric and subnets in the same operation <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1671616>
#maas 2017-03-10
<mup> Bug #1671672 opened: Default routes on multiple networks (including public Internet) are not honoured <networking> <MAAS:New> <https://launchpad.net/bugs/1671672>
<mup> Bug #1671672 changed: Default routes on multiple networks (including public Internet) are not honoured <networking> <MAAS:Invalid> <https://launchpad.net/bugs/1671672>
<mup> Bug #1671672 opened: Default routes on multiple networks (including public Internet) are not honoured <networking> <MAAS:Invalid> <https://launchpad.net/bugs/1671672>
<mup> Bug #1671672 changed: Default routes on multiple networks (including public Internet) are not honoured <networking> <MAAS:Invalid> <https://launchpad.net/bugs/1671672>
<mup> Bug #1664698 opened: No documented way to set the MAC for a bridge or bond <maas> <MAAS:Triaged> <netplan:In Progress by cyphermox> <https://launchpad.net/bugs/1664698>
<mup> Bug #1671453 opened: Some ifupdown/ifenslave parameters have no netplan equivalent <maas> <MAAS:Triaged> <netplan:New> <https://launchpad.net/bugs/1671453>
<mup> Bug #1664698 changed: No documented way to set the MAC for a bridge or bond <maas> <MAAS:Triaged> <netplan:In Progress by cyphermox> <https://launchpad.net/bugs/1664698>
<mup> Bug #1671453 changed: Some ifupdown/ifenslave parameters have no netplan equivalent <maas> <MAAS:Triaged> <netplan:New> <https://launchpad.net/bugs/1671453>
<mup> Bug # opened: 1664698, 1664806, 1671453, 1671756
<mup> Bug #1664844 opened: No distinction between link-up and link-down interfaces <maas> <MAAS:Triaged> <netplan:Incomplete by cyphermox> <https://launchpad.net/bugs/1664844>
<kklimonda> I'm testing maas 2.2b2, and it seems to be losing network configuration for nodes, is this a know issue?
<roaksoax> kklimonda: maybe something change in cloud-init/curtin
<roaksoax> kklimonda: but no, we have been testing b3 for release right now
<roaksoax> nothing of that sorts
<cnf> so if MAAS assigned a wrong IP to a server, how can I change this?
<cnf> it tries to assign a static ip to a machine, instead of a dynamic, and I don 't understand why
<roaksoax> cnf: becuase you configured the interface that way
<roaksoax> cnf: if your interface is configured to 'Auto Assign', maas will chose the IP
<roaksoax> cnf: if you select 'Static', you can select the IP and will be statically confiured in e/n/i
<cnf> i didn't, i let it auto discover
<cnf> yeah, it's set to auto assign
<cnf> and it's wanting to give it an ip NOT in the dynamic pool
<roaksoax> cnf: if you select 'DHCP' the interface will be configured as 'dhcp' in e/n/i
<roaksoax> cnf: that's correct
<roaksoax> cnf: the dynamic pool is for a different purpose
<roaksoax> cnf: so if you subnet is 10.10.10.0/24
<roaksoax> cnf: and you define dynamic pool as  .10 - .100
<roaksoax> cnf: and the free range is .101 to .245
<roaksoax> cnf: maas will auto assign ips on the "free range"
<roaksoax> and use the dyanmic pool for randomg stuff, like commissioning
<roaksoax> or enlistment
<roaksoax> or other devices that pxe boot from maas
<cnf> i only have interfaces beiung pxe booted off
<cnf> atm
<cnf> i don't think i understand the difference between free and dynamic...
<roaksoax> cnf: so for example, when you commission a machine, the machine PXE boots of the 'dynamic' range
<roaksoax> cnf: once the machine is Ready , and you deploy it
<roaksoax> cnf: maas auto-assigns an IP from the 'free' range, pxe boots the machine with the IP, and e/n/i results using that IP
<cnf> what is e/n/i ?
<roaksoax> cnf: /etc/network/interfaces
<cnf> ah
<cnf> so my other machines use the same IP as they pxe boot off
<cnf> it doesn't change after that
<cnf> is that not what is supposed to happen?
<pmatulis> cnf, yes, if the node is set to 'DHCP'
<cnf> pmatulis: i didn't set any node, i left them as discovered?
<pmatulis> cnf, the node shows up as 'Deployed'?
<pmatulis> in the web UI ('Nodes' page)
<cnf> yes
<pmatulis> cnf, when you click on that node what value shows up under the 'IP Address' column?
<cnf> ok, so i have basically before my entire range locked as "dynamic"
<cnf> so i think maas was just using the last IP it got in dhcp and reusing it?
<cnf> i have a bunch of free ip's now
<cnf> see how things change
<pmatulis> ohh, you selected your entire subnet as 'dynamic'?
<cnf> pretty much
<pmatulis> interesting
<cnf> i thought that was what it was for
<cnf> and it worked, at first
<cnf> so i didn't get this was a problem
<pmatulis> cnf, curious, did you follow the docs at all?
<pmatulis> maybe that can be made much clearer
<cnf> i did, but i ran in a lot of problems, so i had to jump around a lot
<cnf> there is no direct link between me and the MAAS setup, so i am jumping through a lot of ssh tunnels
<pmatulis> cnf, i would love to get your overall feedback on the docs
<cnf> that took me a while to get working
<pmatulis> cnf, do you think you could put together some notes?
<pmatulis> and then create a docs bug?
<cnf> uhm, i think i have one open already
<cnf> on the use of proxies
<pmatulis> recently opened?
<cnf> a week or so ago?
<cnf> +-
<pmatulis> in GitHub or Launchpad?
<cnf> i think it was on github
<cnf> the maas doc wasn't too bad, the juju docs on the other hand...
<cnf> pmatulis: my biggest problem with maas was there are a lot of assumptions that are not communicated, and which are not true in my setup :P
<pmatulis> cnf, i cannot locate your bug :(
<cnf> hmm
<cnf> what was the repo url again?
<pmatulis> for the maas docs?
<cnf> yeah
<pmatulis> https://github.com/CanonicalLtd/maas-docs
<cnf> hmm
<pmatulis> or maybe
<pmatulis> https://bugs.launchpad.net/maas
<pmatulis> (for software bugs)
<cnf> i can't remember where it was filed...
<pmatulis> darn
<pmatulis> cnf, if you want to add details to your experience with the docs you can put them here: https://github.com/CanonicalLtd/maas-docs/issues/new
<cnf> k
<cnf> well, i did totally miss i was supposed to keep a free range
<cnf> i read the docs on static and dynamic, and then understood to have a dynamic range as large as possible
 * cnf sighs
<cnf> HP servers take so long to boot :P
<cnf> so how large should your dynamic pool be?
<pmatulis> it depends how many nodes you intend on having. and whether you will ever use 'DHCP' for deployed nodes
<cnf> uhm, unknown... i'm evaluating maas/juju for deploying openstack
<pmatulis> if not for the latter (DHCP), just remember that the addresses will only be used temporarily (enlistment and commissioning)
<pmatulis> and them be available for re-use
<cnf> right, so just enough to cover booting machines
<pmatulis> yeah, booting machines until they get to the 'Ready' state
<cnf> ah, if they boot from ready, they don't get one of those ip's either?
<cnf> so it's only for on-boarding, basically?
<pmatulis> unless you've set them to 'DHCP' like i said
<cnf> right
<pmatulis> right, on-boarding
<cnf> ok
<cnf> yeah, it might be nice to state that machine ip's should be free here https://docs.ubuntu.com/maas/2.1/en/intro-concepts
<cnf> it is explained if you click through, it seems
<cnf> i missed that
<cnf> so can juju configure network settings on different interfaces separate from maas? or does maas need to be aware of it?
<pmatulis> what sort of network settings?
<cnf> so all my machines have a 2 x 10G LAG
<cnf> which carries a bunch of tagged vlans
<cnf> depending on what functionality gets deployed, you need one of those vlans to connect to things
<cnf> but i don't want all machines to always have an IP in every vlan
<cnf> maas is on a separate link (tried pxe booting on the LAG, but never got that working)
<pmatulis> cnf, i'm not sure. i suggest asking in #juju
<cnf> i did :P
<cnf> but people only become active there when my workday is done
<myra> hello, I want to know if there's anyway I could deploy a raw image that I made with MaaS
<myra> I mean I made it with openstack and I want to deploy it with maas
<mup> Bug #1671839 opened: ssh keys view needs improvement <MAAS:New> <https://launchpad.net/bugs/1671839>
<pmatulis> cnf, mailing list?
<cnf> hmm
<mup> Bug #1671844 opened: [UI, 2.1.3] MAAS API key name not exposed in the UI. <MAAS:Triaged> <https://launchpad.net/bugs/1671844>
<mup> Bug #1671891 opened: [2.2 beta3] Node failed to be deployed, because of the following error: {"gateway_link_ipv4": ["Static IP Address instance with id 248066 does not exist."]} <cdo-qa-blocker> <oil> <MAAS:New> <https://launchpad.net/bugs/1671891>
<mup> Bug #1671897 opened: ui to browse combos of tags is inconsistent with juju's notion of combos of tags <ui> <uosci> <MAAS:New> <https://launchpad.net/bugs/1671897>
<Guest67780> hello I created a raw image and I want to deploy it with maas, is there a command line or something to do so? because in the web interface I couldnt find anything.
<stormmore> anyone seen kiko today?
<stormmore> I really hate inconsistent failures :-/
<Guest67780> I created a raw image and I want to deploy it with maas, is there a command line or something to do so? because in the web interface I couldnt find anything.
<kukacz> kiko: some days ago I've reported failing PXE UEFI boot - stuck in Grub - on Dell servers
<kukacz> kiko: just wanted to share that BIOS (for Dell R630 servers) update fixed that. NIC firmware (Intel X520) was latest already
<kukacz> kiko: thanks for help!
<stormmore> kiko, so far today I haven't been able to reproduce the problem I have been having. I am wondering if it is bandwidth related somehow
 * stormmore is graham in case you didn't know
<stormmore> OK maybe, just maybe my intermittent issue might be resolved and we will never know what it was :-/
#maas 2017-03-11
<stormmore> oh it is suspiciously looking like a bandwidth related "bug", anyone seen kiko today?
<stormmore> I know that sounds crazy and it is probably just coincidence that the first install of MaaS after I get home failed in the way that I mention inte bug # 1669548
<mup> Bug #1672054 opened: MAAS does not detect RAM size on Supermicro blade SBA-7141A-T <MAAS:New> <https://launchpad.net/bugs/1672054>
<mup> Bug #1672088 opened: [2.1] MAAS should not set bond-lacp_rate in active-backup mode <MAAS:New> <https://launchpad.net/bugs/1672088>
#maas 2017-03-12
<ybaumy> hi. how to i set a new space for a group of machines or machines in a zone
<mup> Bug #1672220 opened: [2.x] User gets no control over @ RRset in DNS domains <MAAS:New> <https://launchpad.net/bugs/1672220>
#maas 2018-03-05
<mup> Bug #1738261 changed: Cannot commission machine in pod <MAAS:Expired> <https://launchpad.net/bugs/1738261>
<mup> Bug #1621615 changed: network not configured when ipv6 netbooted into cloud-init <maas-ipv6> <verification-done> <verification-done-xenial-cloud-init> <cloud-init:Fix Released> <MAAS:Invalid> <cloud-init (Ubuntu):Fix Released> <cloud-initramfs-tools (Ubuntu):Fix Released> <cloud-init (Ubuntu
<mup> Xenial):Fix Released> <cloud-initramfs-tools (Ubuntu Xenial):Fix Released> <cloud-init (Ubuntu Yakkety):Fix Released> <cloud-initramfs-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1621615>
<sipior> howdy. i'd like to enable dynamic dns on the zone managed by maas. any way to inject a snippet into the named.conf file, like there is for dhcp?
<morty> Hey, I have a VM running MaaS, but it is a bit buggy atm. I see that a process called "twistd3" is taking most of the cpu and ram - what is this?
<mup> Bug #1753486 opened: maas-region-api should depend on maas-dns <MAAS:New> <https://launchpad.net/bugs/1753486>
<utking> Hey guys!
<utking> anyone have any clue on the twistd3 and postgres cpu usage?
<utking> We also get deploy errors when deploying with juju, in the sense that juju waits for machines
<utking> also i get connection lost when connecting to maas, but my mate over here morty connects just fine :S
<kiko> utking, tell us a bit more about what your MAAS setup looks like -- single machine?
<utking> maas is a vm running on an R710
<utking> controlling a c6100 with 4 nodes
<utking> dual cpu's and 48gb ram each
<utking> it used to work, but now it doesn't
<kiko> okay, so a separate node with a VM in it, and a blade chassis
<utking> so i'm a bit clueless tbh
<kiko> okay, what changed?
<utking> yep :)
<utking> nothing, haha
<utking> just haven't used it for a couple of weeks
<kiko> okay, what fails?
<kiko> can you get to the MAAS API?
<utking> well i for once can't connect, i can log in, and see the settings pane, but anything else gives me connection lost
<utking> also when deploying with juju only one node gets deployed
<kiko> you can or can't connect?
<utking> well juju can connect
<utking> i can't
<kiko> how can you log in if you can't connect?
<utking> https://gyazo.com/a501eb8464345d8f9d2e2a71291b0ec4
<kiko> gotcha
<kiko> you can connect, but the WS is failing
<utking> we are a team of three people working on this, morty which is in here too
<utking> he can connect though
<utking> but maas still fails with the deployment
<kiko> yep
<utking> WS?
<kiko> the websocket
<utking> ah ok, how can i fix it? haha :)
<kiko> let's look at the MAAS logs
<kiko> any tracebacks or obvious errors?
<utking> maas.log?
<utking> https://pastebin.com/6VdmVSiB
<utking> some of the nodes are a bit sleepy, so they use some time to boot. as in powers up and down for a while
<mup> Bug #1753493 opened: [2.4a1] DHCP does not offer all DNS servers <MAAS:Triaged> <https://launchpad.net/bugs/1753493>
<mup> Bug #1753496 opened: [2.4a1] DHCP does not offer all NTP servers <MAAS:Triaged> <https://launchpad.net/bugs/1753496>
<utking> can't see anything that points to the errors we're having :/
<kiko> sorry, otp so lagged
<utking> otp? ^^
<utking> https://gyazo.com/a473f4d4eccdd58195de8ff46133f4ef
<utking> here you can see maas
<utking> cpu usage i mean
<roaksoax> q/win 4
<mup> Bug # changed: 1665476, 1718561, 1732390, 1741302
<kurt_> Hi guys - just looking for the information on how DNS is handled by maas.  I'm happy to RTFM, but was looking for something to actually read.  Thanks
<chuckD> I have a question regarding MAAS with pxe boot over VLANs and was wondering if anyone had any ideas
<chuckD> I have a JUMP server running MAAS
<chuckD> I have 5 bare metal servers to be deployed
<chuckD> Previously I had everything working using FLAT networks.
<chuckD> MY PROBLEM IS:
<chuckD> I've changed to VLANs on my networks (IPMI & brAdmin).
<chuckD> My Servers receive VLAN Tag 141 IPMI packets from the JUMP server and act accoringly. This is expected as the serever BIOS allows for VLAN tags to be configured.
<chuckD> Upon powerup/rest oer IPMI, My servers send unTagged (nonVLAN) BOOTP requests and I have verified that the packets make it to the IFACE of my brAdmin bridge.
<chuckD> The packets are not passed up the the brAdmin bridge as it is on VLAN tag 148.
<chuckD> How do I go about resolving this?
<kurt_> maas appears to be set up correctly other than not being able to deploy.  there appears to be no internet access from the VMs to the outside world.  Any hints on what I should check?  postrouting iptables or something?
<kurt_> and yes, I have these rules active:
<kurt_> sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
<kurt_> sudo iptables -A FORWARD -i eth0 -o br1 -m state \
<kurt_>     --state RELATED,ESTABLISHED -j ACCEPT
<kurt_> sudo iptables -A FORWARD -i br1 -o eth0 -j ACCEPT
<kurt_> echo 'net.ipv4.ip_forward=1' | sudo tee -a /etc/sysctl.conf
<kurt_> any help is appreciated
#maas 2018-03-06
<mup> Bug #1753667 opened: Feedback on LACP bonding status on machine deployment <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1753667>
<mup> Bug #1753721 opened: clicking on "logs" fo a deploying machine shoud bring you automatically to the "installation output" section <MAAS:New> <https://launchpad.net/bugs/1753721>
<xygnal> roaksoax: glad to see networking for centos in 2.3, when is LVM coming?
#maas 2018-03-07
<mup> Bug #1753874 opened: machine can be compose in a full pool because  of typo  <MAAS:New> <https://launchpad.net/bugs/1753874>
<mup> Bug #1753874 changed: machine can be compose in a full pool because  of typo  <MAAS:New> <https://launchpad.net/bugs/1753874>
<mup> Bug #1753874 opened: machine can be compose in a full pool because  of typo  <MAAS:New> <https://launchpad.net/bugs/1753874>
<mup> Bug #1754012 opened: wsman dependency on older curl will cause issues in bionic for maas <MAAS:New> <https://launchpad.net/bugs/1754012>
<cnf> how do you make a maas setup multi region?
<roaksoax> cnf: https://docs.maas.io/2.3/en/manage-ha
<roaksoax> xygnal: lvm for centos is not within our plans atm
<cnf> roaksoax: isn't that one region in a redundant setup?
<roaksoax> cnf: ah so you want to setup a single maas for multiple site locations ?
<cnf> yes
<roaksoax> cnf: we recommend a MAAS per DC
<cnf> yeah, we don't look forward to 35 maas instances and UIs
<cnf> we have a meeting with canonical people on this in about 2 hours for our MVP, but i want to get some ideas checked before we go into that one
<cnf> atm, we are considering "abusing" zones as DC locations
<cnf> so run one HA region controller, and put each DC rackd's into a separate zone
<cnf> roaksoax: why do you not support this, btw?
<cnf> hmm
<mup> Bug #1754034 opened: improvements for UI around users <MAAS:New> <https://launchpad.net/bugs/1754034>
<mup> Bug #1754041 opened: [2.4]  /run/lock/maas:networks-monitoring prevents discovery of networks <MAAS:Triaged> <https://launchpad.net/bugs/1754041>
<mup> Bug #1754045 opened: [2.4] MAAS sometimes fails to insert subnets in maas-proxy.conf <MAAS:Triaged> <https://launchpad.net/bugs/1754045>
#maas 2018-03-08
<tasker> hello. I'm trying to upgrade `maas-rack-controller` and the installation is complaining that it can't import a module, "no module named chardet", even though it is installed. my pythonpath does include the directory where chardet is installed. any ideas?
<tasker> nevermind. I figured it out by hacking out the `maas-rack-controller` dependency for `maas`, installing `python3-chardet` again, reapplying the depends line, and running the install again.
<mup> Bug #1754304 opened: Reduce code duplication between Python and JavaScript <MAAS:Triaged> <https://launchpad.net/bugs/1754304>
<neferty> hey, i'm trying out MAAS in a virtual environment, so i installed the controller in a VM. i added a second virtual network interface (on a specific) VLAN to my controller where i want to make it manage the network (DHCP) but even though i set a static address for that interface for the controller in the web UI, the controller doesn't actually assign that address to the interface
<roaksoax> neferty: you cannot configure interfaces of the controller in maas, you need to configure that in ubuntu and the controller will automatically take that
<roaksoax> there's a bug that the controller interface sections
<roaksoax> that is giving the impression you can configure it through there
<neferty> ohh, i figured it was, since in Nodes -> Controller i can click on the node just fine, and then go to interfaces, and set it to e.g. static assignment
<neferty> but so just to make sure i understand correctly, this is considered a bug (being able to change interface settings of a controller) and you're meant to configure this yourself?
<ltrager> neferty: That is correct. You need to configure the network setting on the controller manually, MAAS will detect the settings
<mup> Bug #1754334 opened: [2.4, UI, vanilla] Errors when loading the storage tab <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1754334>
<mup> Bug #1754335 opened: [2.4, UI] Node action form takes a long time to disappear <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1754335>
<mup> Bug #1754484 opened: maas creates separate fabrics for each interface on a rack controller <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1754484>
<mup> Bug #1750884 changed: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution <cloud-init:Confirmed for raharper> <https://launchpad.net/bugs/1750884>
<mup> Bug #1754493 opened: images never finish syncing to rack controller <cdo-qa> <cdo-qa-blocker> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1754493>
#maas 2018-03-09
<seffyroff> Hello folks!  I'm in early stages with my discovery project to spin up MaaS inside a Docker container, right now I'm seeing some errors related to the tgt service not starting, and some ntp resolution socket errors too - as I'm running in a containerized snap, I theorized that there's some additional channels I could connect for a more relaxed runtime environment
<seffyroff> the tgt service being the main roadblock as my rackd won't sync images
<seffyroff> i wondered if I'm hitting the OOM issue that tgt (once) had?
<parlos> I'm hoping to use MAAS as a orchestrator in a lab environment. Hence; I under stood that the way to go is to have multiple user accounts, and then acquire hosts to that user. Now; can I as an admin assign nodes to a user, or can this only be done from the user account?
<parlos> Good Morning
<seffyroff> hmm, looks like the tgt changes for 2.4.0 might help me here
<seffyroff> i guess there's no snap for that?
<roaksoax> seffyroff: not yet
<roaksoax> snas in 18.04 are currently broekn
<seffyroff> ok thanks for the heads up.
<seffyroff> I'll try some other approaches to getting this working
<roaksoax> seffyroff: you should probably look at 2.3.1
<roaksoax> it had a tgt fix running in containers (lxc)
<seffyroff> yup, db migrations happening as we speak
<seffyroff> thanks!
<roaksoax> parlos: there's no suhc way to assign a machine to a user. Users/admins have acces to a machine pool, and they can allocate themselves a machine
<parlos> roaksoax: so, if I want to limit what nodes a user can use, I have to login as user an acquire the nodes as that user... any plans for that?
<seffyroff> actally roaksoax i do see a 2.4.0 snap, but I guess it'll sulk if I try to install it on a Xenial host?
<seffyroff> channels:
<seffyroff>   stable:          2.3.0-6434-gd354690-snap        (1349) 101MB -
<seffyroff>   candidate:       2.3.1-6470-g036d646-snap        (1868) 100MB -
<seffyroff>   beta:            2.3.1-6470-g036d646-snap        (1868) 100MB -
<seffyroff>   edge:            2.4.0~alpha2-6630-gc925539-snap (1857) 97MB  -
<seffyroff> hm, tgt still wouldn't start from 2.3.1 snap inside a docker container.  It does start if I snap install to the host itself though.
<roaksoax> seffyroff: the 2.4 snap requires ubuntu core 18
<aln> is anyone able to answer a basic question about the API?
<roaksoax> seffyroff: which is still in development
<seffyroff> noted, thanks
<seffyroff> looks like i'll go for package install, which I was leaning towards anyway so I can apply a downstream WOL patch
<seffyroff> although possibly similar could be accomplished with snap scriptlets
<roaksoax> aln: sure, just ask your question and if soneone knows the answerm, they will reply
<seffyroff> it'll potentially produce a cleaner container also.  So much low level hackery to get snap running in the contaienr first, then maas requires several additional hacks to work within snap within a container >.<
<aln> i want to deploy a machine with the api using `/machines/{system_id}/?op=deploy`. i would have expected it to take boot-resource ID as a parameter but instead it takes distro_series and hwe_kernel.
<aln> i tried to fetch information about the boot-resource from `/boot-sources/{id}/`, but this does not return any information that seems to fit into distro_series or hwe_kernel.
<aln> how can i issue a deploy via the api and specify the boot-resource/image i want to use?
<aln> (deploy works, i just can't get it to use anything other than the default image)
<aln> oops - second url should be `/boot-resource/{id}/` of course
<roaksoax> aln: deploy distro_series=xenial
<roaksoax> aln: hwe_kernel=hwe-16.04
<roaksoax> aln:         "name": "ubuntu/xenial",
<roaksoax> aln:         "subarches": "generic,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t,hwe-u,hwe-v,hwe-w,ga-16.04,hwe-16.04,hwe-16.10"
<aln> u'name': u'ubuntu/xenial',
<aln> u'subarches': u'generic,hwe-p,hwe-q,hwe-r,hwe-s,hwe-t,hwe-u,hwe-v,hwe-w,ga-16.04'
<aln> yeah, sorry haha
<roaksoax> aln: yeah, although the subarches you can only use ga-16.04, hwe-16.04, etc
<roaksoax> at least that's on ym streams
<aln> okay
<aln> and this works with custom non-linux images too?
<aln> so, u'name': u'windows/win2012r2'
<aln> u'subarches': u'generic',u'name': u'windows/win2012r2'
<aln> i can specify win2012r2 and generic?
<roaksoax> aln: for non-ubuntu deployments, you dont need to set the hwe_kernel
<roaksoax> aln: the hwe_kernel is only really valid for ubuntu, because that's the kernle the machine will be running post deployment
<aln> yes of course, thanks
<roaksoax> aln: as for windows, distro_series=win2012r2
<roaksoax> aln: it should workt distro_series=windows/win2012r2
<roaksoax> but doens't necessarily
<aln> yeah, it didn't for me
<roaksoax> but it is not necessary
<roaksoax> ok, yeah that seems like a bug
<aln> roaksoax: thanks for the help, but afraid this didn't work
<aln> issuing request with distro_series=windows2012r2 makes it deploy xenial
<roaksoax> aln: it doens't deployxenial, it pxe boots into xenial to deploy windows
<aln> status: Deploying Ubuntu 16.04 LTS
<roaksoax> aln: ah1 that's stranger
<roaksoax> strange
<roaksoax> what version you using ?
<aln> of maas?
<aln> 2.3.0
<roaksoax> aln: so I'm looking at our CI, and we use maas <user> machine deploy distro_series=win2012hrv2
<roaksoax> win2012hvr2
<roaksoax> so aln we test that path
<aln> Deploying Ubuntu 16.04 LTS
<aln> but presumably that's what is after the slash in your boot-resource's name
<roaksoax> right, so if boot-resource's name is <os>/<series> on distro_series= just use the <series>
<aln> yeah
<aln> Deploying Ubuntu 16.04 LTS
<roaksoax> aln: also, if you are talking directly to the API, not via the CLI
<roaksoax> aln: you should look at: https://github.com/maas/python-libmaas
<aln> i did have a look at this, but we decided just to interface directly, as we don't need to use it much (='my boss told me to do it this way')
<roaksoax> gotcha
<aln> looking though the library for an example of the call being made for deploy, but it's pretty abstracted
<aln> if anyone reads my messages above and think they can help, i made a post here: https://askubuntu.com/questions/1013371/specifying-boot-resource-for-maas-api-deploy
<ipat8> Quick question for you guys
<ipat8> Is there a newer version of the maas-image-builder?
<ipat8> I can't seem to BZR branch it
<ipat8> ChanServ Who is allive?
<ipat8> *allive
<ipat8> *alive
<neferty> i set up some VMs with manual power management and it seems like they never become ready, is this intentional?
<wiro> neferty: they should be ready after commisioning, then you have to turn them off manualy
<neferty> i have turn them off? eh, alright
<wiro> no necessary, it should be on byt after commisioning it reched ready state, if not then there should be some error
<wiro> in test or commision
<neferty> oh hold on, i think i misunderstood when a machine is considered ready, my mistake
<mup> Bug #1754697 opened: [FFe] Standing FFe for MAAS 2.4 <maas (Ubuntu):New> <https://launchpad.net/bugs/1754697>
#maas 2018-03-10
<mup> Bug #1754822 opened: maas dependency on wsmancli is b0rked <MAAS:New> <https://launchpad.net/bugs/1754822>
<mup> Bug #1754835 opened: Test-in-progress indicators should be vertically aligned <MAAS:New> <https://launchpad.net/bugs/1754835>
<mup> Bug #1754835 changed: Test-in-progress indicators should be vertically aligned <MAAS:New> <https://launchpad.net/bugs/1754835>
<mup> Bug #1754835 opened: Test-in-progress indicators should be vertically aligned <MAAS:New> <https://launchpad.net/bugs/1754835>
<mdih> hi guys, is it possible to install old version of maas? like maybe 2.2? it seems that in the repo, only 2.3 is available? http://ppa.launchpad.net/maas/stable/ubuntu/pool/main/m/maas/
<parlos> mdih; cant you just checkout the branch matching the version you wanted?
<mdih> parlos: ah okay,  cool thanks thanks
<parlos> mdhi: Have not tested!!!!
<parlos> Good bye!
#maas 2018-03-11
<seffyroff> hey guys.  I am sure I already know the answer is 'no' for 'reasons
<seffyroff> but i wanted to check: is there any plans to re-add WOL support in power management to MAAS?  before I endeavour on a lenthy patching process?
<mup> Bug #1754950 opened: [2.3] No clear documentation how to get test results through API <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1754950>
<mup> Bug #1754950 changed: [2.3] No clear documentation how to get test results through API <cpe-onsite> <MAAS:Invalid> <https://launchpad.net/bugs/1754950>
<mup> Bug #1755043 opened: MAAS first run config should give an example with multiple forwarders <MAAS:New> <https://launchpad.net/bugs/1755043>
#maas 2020-03-02
<mup> Bug #1865440 opened: MAAS is unusable with "update_neighbour" method failing: "django.db.utils.OperationalError: could not serialize access due to concurrent update" <MAAS:New> <https://launchpad.net/bugs/1865440>
<mup> Bug #1865446 opened: duplicated ssh keys could be imported with different key comments and cause maas shows connecting for ever <MAAS:New> <https://launchpad.net/bugs/1865446>
<mup> Bug #1864123 changed: traceback when creating user using existing email <MAAS:Invalid> <https://launchpad.net/bugs/1864123>
<mup> Bug #1864123 opened: traceback when creating user using existing email <MAAS:Invalid> <https://launchpad.net/bugs/1864123>
<mup> Bug #1864123 changed: traceback when creating user using existing email <MAAS:Invalid> <https://launchpad.net/bugs/1864123>
<mup> Bug #1865515 opened: MAAS can't deploy to a server with Secure Boot active <MAAS:New> <https://launchpad.net/bugs/1865515>
<mup> Bug #1865545 opened: Rack Controllers not configured for NTP correctly when ntp_external_only is false <sts> <MAAS:New> <https://launchpad.net/bugs/1865545>
<mup> Bug #1865545 changed: Rack Controllers not configured for NTP correctly when ntp_external_only is false <sts> <MAAS:New> <https://launchpad.net/bugs/1865545>
<mup> Bug #1865545 opened: Rack Controllers not configured for NTP correctly when ntp_external_only is false <sts> <MAAS:New> <https://launchpad.net/bugs/1865545>
#maas 2020-03-03
<mup> Bug #1865841 opened: Set NODE_ENV for snap UI builds <MAAS:Triaged> <https://launchpad.net/bugs/1865841>
<mup> Bug #1865841 changed: Set NODE_ENV for snap UI builds <MAAS:Triaged> <https://launchpad.net/bugs/1865841>
<mup> Bug #1865841 opened: Set NODE_ENV=PRODUCTION for snap UI builds <MAAS:Triaged> <https://launchpad.net/bugs/1865841>
<mup> Bug #1865841 changed: Set NODE_ENV=PRODUCTION for snap UI builds <MAAS:Triaged> <https://launchpad.net/bugs/1865841>
<mup> Bug #1865841 opened: Set NODE_ENV=PRODUCTION for snap UI builds <MAAS:Triaged> <https://launchpad.net/bugs/1865841>
<mup> Bug #1865844 opened: Add KVM/LXD host id to machine payload in WS API <MAAS:Triaged> <https://launchpad.net/bugs/1865844>
<mup> Bug #1865859 opened: HTTP Error 415 with iDRAC 9 using Redfish power type <MAAS:New> <https://launchpad.net/bugs/1865859>
<mup> Bug #1865859 changed: HTTP Error 415 with iDRAC 9 using Redfish power type <MAAS:New> <https://launchpad.net/bugs/1865859>
<mup> Bug #1865859 opened: HTTP Error 415 with iDRAC 9 using Redfish power type <MAAS:New> <https://launchpad.net/bugs/1865859>
<mup> Bug #1865859 changed: HTTP Error 415 with iDRAC 9 using Redfish power type <MAAS:New> <https://launchpad.net/bugs/1865859>
<mup> Bug #1865859 opened: HTTP Error 415 with iDRAC 9 using Redfish power type <MAAS:New> <https://launchpad.net/bugs/1865859>
<mup> Bug #1865866 opened: MAAS  attempts creation of ZFS partition without sanity checking the partition table <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1865866>
<mordkoff> Hi..fresh install of MAAS 2.7 -- PXE boot net is IPv6 only. Tried to add my first machine (IPMI is IPv4) and there is no response from MAAS to the bootp from the new machine
<mordkoff> in controller summary I see dhcp6 is not green :(
<mordkoff> can someone reply so I know this is working at all
<mordkoff> sigh
<mordkoff> is there anybody out there?
<mordkoff> why does snap require apparmor ?
<mordkoff> sorry wrong group
<mordkoff> Hi all
<mordkoff> maas 2.7 installed fresh today, I cannot get my images to sync -- All I get is Waiting for rack controller(s) to sync
<mordkoff> Is this a known issue?
<mordkoff> tap, tap, tap. Is this thing on?
<mordkoff> guess I should do my best Billy Idol imitation.....
#maas 2020-03-04
<mup> Bug #1866118 opened: 2.6.2 new nodes always are calculated as ephemeral deploys <MAAS:New> <https://launchpad.net/bugs/1866118>
#maas 2020-03-05
<mup> Bug #1866234 opened: [Feature] Remote rackd <MAAS:New> <https://launchpad.net/bugs/1866234>
#maas 2020-03-06
<shadowphax> Hi all, I am deploying Ubuntu 18.04LTS onto a bunch of supermicro nodes which have Intel VROC and x2NVME disks. I've configured the Intel VROC bits already but when commissioning the node it shows both NVME disks and not the RAID1 mirror
<shadowphax> I am not sure this point if I am meant to see both disks or the one. Surely I would expect to see the one RAID1 mirror disk instead of both
<shadowphax> any thoughts ?
<shadowphax> booting off a standard Ubuntu 18.04 LTS iso shows this correctly
<shadowphax> any ideas?
<v92> shadowphax: I'd use software raid, not sure what Intel VROC is but if I see two disks in MaaS I'd create mdraid from them
<mup> Bug #1866325 opened: MAAS KVM (Pods) on Power wasn't able to spawn VMs <ppc64el> <MAAS:New> <The Ubuntu-power-systems project:New for maas> <https://launchpad.net/bugs/1866325>
