#maas 2013-01-14
<aberdine> Hello. I'm having a bit of trouble with MAAS provisioned VMware VMs not booting from disk. Where are the logs for each build kept (and is there documentation on where logs & such is? )
<roaksoax> rvba: howdy! wwhat was the IPMI bug again?
<roaksoax> (the versions and stuff)
<rvba> roaksoax: Hi, it was 1086162.
<roaksoax> rvba: were you able to look at it and merge it?
<roaksoax> bug #1086162
<ubot5> bug 1086162 in maas (Ubuntu) "IPMI based power management default to IPMI 1.5 based authentication" [High,Triaged] https://launchpad.net/bugs/1086162
<rvba> roaksoax: I'm waiting for your confirmation that the fix I suggest fixes the problem :)
<roaksoax> rvba: alright, I'm testing this today :)
<rvba> roaksoax: cool.
<roaksoax> rvba: i think that for the ipmi version we should default to 2.0
<roaksoax> rvba: and whomever is using 1.5 should manually change it
<roaksoax> or is it like that already?
<rvba> roaksoax: the doc for ipmipower says: http://paste.ubuntu.com/1531116/.  So I think we should keep the "auto selection" by default.
<rvba> i.e. not pass anything in "--driver-type=" by default.
<roaksoax> right, good point
<rvba> roaksoax: btw, not sure you have time for this, but if you have, there is another critical bug in MAAS: #1081660
<roaksoax> bug #1081660
<ubot5> bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Critical,Triaged] https://launchpad.net/bugs/1081660
<roaksoax> rvba: alright, will look into that
<rvba> ta
<roaksoax> rvba: i will upload maas 1.2 to raring
<roaksoax> and I'll test that
<roaksoax> and see how it goes
<rvba> roaksoax: speaking of raring, any idea on bug #1092265 ?
<ubot5> bug 1092265 in MAAS "Nodes fail to boot from local disk on raring" [Critical,Triaged] https://launchpad.net/bugs/1092265
<roaksoax> rvba: that's what i'm gonna test now too :)
<rvba> roaksoax: great :)
<roaksoax> rvba: so I don't expect that bigjools told you guys anything about the version changes i was planning to make for the upload right?
<rvba> roaksoax: does not ring a bell
<roaksoax> rvba: alright, so according to the branchs maas/1.2 and maas (trunk). I was thinking on releasing the package as maas-1.2~bzrXYZ for SRU
<roaksoax> rvba: and trunk as maas-1.2+bzrXYZ
<roaksoax> makes sense?
<roaksoax> makes sense to use that versioning?
<rvba> roaksoax: isn't it a bit bizarre to have trunk released with a name that contains '1.2'?
<roaksoax> rvba: right so we are currently releasing as maas-0.1
<roaksoax> :)
<roaksoax> rvba: still around?
<roaksoax> mat/win 13
<roaksoax> err
#maas 2013-01-15
<roaksoax> bigjools: around?
<bigjools> roaksoax: in body, perhaps
<roaksoax> bigjools: heh :) just coming back to life?
<lifeless> bigjools: the flesh is here the spirit is lacking
<lifeless> ?
<bigjools> I am sat at my desk but nobody is home!
<bigjools> sleepless nights do that :(
<roaksoax> boomer
<roaksoax> bigjools: so there's a bug in packaging
<bigjools> annoying, because it's the first night in ages where it's not been roasting hot
<bigjools> roaksoax: /o\
<bigjools> A BUG, OH NOES!
<roaksoax> bigjools: when cluster controller puts MAAS_URL as http://localhost/MAAS
<roaksoax> which breaks
<roaksoax> pxe booting
<bigjools> that would yes
<roaksoax> (enlistment, commissioning)
<roaksoax> bigjools: other than that tested maas/1.2 in raring
<roaksoax> and works like a charm
<bigjools> woohoo
<bigjools> did syslinux get fixed?
<roaksoax> bigjools: nah
<bigjools> you used quantal's :)
<roaksoax> bigjools: nah
<bigjools> heh
<roaksoax> bigjools: :) the only thing is that it didn't localboot
<roaksoax> which is external from maas
<bigjools> you used magic pixie dust
<bigjools> ah
<roaksoax> bigjools: which im gonna look at tomorrow
<roaksoax> bigjools: now im gonna upload that to raring
<roaksoax> bigjools: as soon as what i proposed for merging gets uploaded
<bigjools> roaksoax: nice
<bigjools> when's the next techboard meeting?
<roaksoax> bigjools: now since lp:maas/1.2 is 1.2, does it make sense to upload as maas-1.2~bzrXYZ?
<roaksoax> bigjools: yes after I upload, wait for tech board meeting
<bigjools> roaksoax: +1 on the version
<roaksoax> bigjools: so when I upload trunk, i was thinking on maas-1.2+bzrXYZ
<bigjools> mmmmm
<bigjools> I don't know
<bigjools> you were talking about a version bump for raring
<roaksoax> bigjools: yeah so i thought about this ~|+ since you mentioned you werent sure about the version bump
<roaksoax> bigjools: we could call it 1.3~
<bigjools> sounds ok
<bigjools> we can make a 1.3 branch when releasing into 13.04
<roaksoax> ok cool
<roaksoax> i'll do that then
<roaksoax> bigjools: so I'd just like https://code.launchpad.net/~andreserl/maas/ipmi_versioning_support_lp1086162 and https://code.launchpad.net/~andreserl/maas/ipmi_versioning_support_lp1086162_1.2 in
<roaksoax> to upload to raring :)
<bigjools> one sec!
<roaksoax> bigjools: alright so it iwll be 1.2+ (instead of 1.2~)
<bigjools> yeah makes sense
<roaksoax> cool
<roaksoax> alright so TB is next :)
<roaksoax> bigjools: and if they accept we will make it before 12.04.2
<bigjools> roaksoax: both approved with a small change
<roaksoax> cool thanks
<roaksoax> bigjools: the hjenkings issue seems unrelated
<roaksoax> WebDriverException: Message: u'Message: \'Can\\\'t load the profile. Profile Dir: /tmp/tmpcmDMBI Firefox output: Xlib:  extension "RANDR" missing on display ":1014".\\n*** LOG addons.xpi: startup\\n*** LOG addons.xpi: checkForChanges\\n*** LOG addons.xpi: No changes found\\n\' \n-------------------- >> begin captured stdout << ---------------------\n    \n    Starting Firefox\n\n--------------------- >> end captured stdout << ----------------------'
<bigjools> roaksoax: yeah
<bigjools> it's broken yet again
<roaksoax> there was a jenkins breakeage due to a security update (or so i heard)
<roaksoax> bigjools: do you want me to fix the formatting issue?
<bigjools> roaksoax: please
<bigjools> I don't think this is related to that, it's having trouble starting an X frame buffer
<roaksoax> bigjools: to the security update?
<bigjools> I think so
<roaksoax> yeah that's what I mean,t it might be related to the security update
<roaksoax> bigjools: this has already been merged btw: https://code.launchpad.net/~andreserl/maas/ipmi_versioning_support_lp1086162_1.2/+merge/143194
<bigjools> ok
<roaksoax> bigjools: https://code.launchpad.net/~andreserl/maas/fix-formatting-issue-1.2/+merge/143226
<roaksoax> https://code.launchpad.net/~andreserl/maas/fix-formatting-issue/+merge/143227
<roaksoax> i'm approving them myself
<bigjools> no worries
<bigjools> I wonder what the heck jenkins and tarmac are doing then?
<roaksoax> yeah
<roaksoax> did it fail in trunk? or unle in 1.2?
<bigjools> waaaat
<bigjools> wtf
<bigjools> it said it wasn't merging it, and then did!
<roaksoax> yeah it did merge it
<bigjools> not good
<roaksoax> indeed
<roaksoax> things went crazy
<bigjools> I emailed matsubara
<roaksoax> ack
<roaksoax> rvba: howdy!! I was wondering what's that "generator" option in pserv.yaml
<rvba> roaksoax: hi, let me check.
<rvba> roaksoax: it's the url used by the TFTP server to contact the MAAS API to fetch the PXE configs.
<roaksoax> rvba: ok cool
<roaksoax> so there's a bug in packaging
<roaksoax> on upgrade it replaces maas_cluster and sets MAAS_URL as localhost
<roaksoax> localhost/MAAS
<roaksoax> which cases PXE to break
<rvba> roaksoax: Looks like a bug indeedâ¦ I'm surprised that Julian did not witness that when he did the upgrade testingâ¦
<roaksoax> rvba: so this should help: http://paste.ubuntu.com/1534585/ makes sense?
<roaksoax> argh didn't work
<roaksoax> i know why!
<spideyman> Hi
<spideyman> where does the config template path come from? /usr/share/provisioningserver/pxe?
<roaksoax> spideyman: huh?
<roaksoax> spideyman: i think you want /usr/share/pyshared/provisioningserver/pxe
<roaksoax> rvba: still around?
<rvba> roaksoax: yep
<roaksoax> rvba: could you pelase review: https://code.launchpad.net/~andreserl/maas/update_maas_url_on_upgrade_raring/+merge/143352
<roaksoax> https://code.launchpad.net/~andreserl/maas/update_maas_url_on_upgrade_precise.sru/+merge/143350
<roaksoax> https://code.launchpad.net/~andreserl/maas/update_maas_url_on_upgrade_quantal/+merge/143351
<roaksoax> same change on all
<roaksoax> has been tested works as expected
<rvba> ok
<roaksoax> rvba: thanks!! :)
<spideyman> roaksoax: ah, thanks sorry
<rvba> roaksoax: when does the bug manifests itself exactly?
<rvba> roaksoax: simply when the cluster package gets upgraded?
<roaksoax> rvba: yes
<rvba> k, ta
<roaksoax> rvba: say you have raring installed, and then you upgrade, maas_cluster.conf ends uip with MAAS_URL=http://localhost/MAAS
<roaksoax> so when a node PXE boots
<roaksoax> it tells it look for your preseed in url=http://localhost/MAAS
<roaksoax> which is wrong :)
<roaksoax> rvba: so the fix is basically 1. "update MAAS_URL always (install and upgrade from the debconf db)" or if nothing is set in 1. check whether the cluster has been installed alongisde the region, and use the value set in MAAS_DEFAULT_URL
<rvba> All right, your fix seems sane but I'll recreate the problem first just for safety.
<roaksoax> sure
<roaksoax> rvba: the package that fixes this is in ppa:maas-maintainers/experimental
<roaksoax> rvba: and I saw this after upgrading all my MAAS systems (2) and being unable to enlist
<rvba> roaksoax: why did the upgrade change the original value?
<roaksoax> rvba: the root cause of this is that in 1.2 branch and trunk the url used for the preseeds is the value in maas_cluster.conf (MAAS-URL), however in previous versions (currently released) thius is obtained from DEFAULT_MAAS_URL
<roaksoax> rvba: this is the commit http://bazaar.launchpad.net/~maas-maintainers/maas/1.2/revision/1332
<rvba> roaksoax: so if we're upgrading and the region controller is on another machine, the value of the url will be in te debconf db right?
<roaksoax> rvba: yes
<roaksoax> rvba: so on upgrade, it will be upgraded correctly
<rvba> k
<rvba> roaksoax: I'm sorry but I don't really understand the problemâ¦ if the cluster is installed alongside the region, then http://localhost/MAAS is a valid url to use to reach the MAAS server.
<roaksoax> rvba: yes, now try to enlist a node
<roaksoax> rvba: it will PXE boot, then it will fail to find the meta-data server
<roaksoax> because the argument that passes the url for the metadata
<roaksoax> will be http://localhost/MAAS/metadata/XYZ
<rvba> I've installed a 1.2 package from scratch and I still have MAAS_URL=http://localhost/MAAS in /etc/maas/maas_cluster.conf
<rvba> (I can't test enlistment just new because there is a problem with the lab)
<roaksoax> rvba: ok so add ppa:maas-maintainers/experimental and sudo apt-get update && sudo apt-get upgrade
<roaksoax> that should upgrade MAAS
<roaksoax> and MAAS_URL should be http://XYZ/MAAS
<rvba> roaksoax: it's really weird, the url passed to the node is still computed using DEFAULT_MAAS_URL for the nodes in the master cluster's network.
<rvba> roaksoax: I'm sorry but I need to think a little bit more about the bug you've fixed, I've summarized what I think about the problem on the MP but I need to step out now.  I'll have another look at this tomorrow.
<rvba> roaksoax: sorry for the delay but maybe we will find a more elegant way to fix this.  I have to talk to Julian tomorrow morning about something else also we will have a look at your MP too.
<roaksoax> rvba: cool, but i'm gonna upload this regardless
<roaksoax> cause this "fix" only works when region controller is installed
<rvba> roaksoax: ok
<roaksoax> otherwise
<roaksoax> upgrades will be broken
<roaksoax> rvba: i'll catch up with julian about this tonight
<roaksoax> rvba: but thanks for taking a look at it :)
<spideyman> Hi
<spideyman> I just updated from the latest quantal maas-maintainers daily build archive and I can no longer set kernel_opts for nodes
<bigjools> spideyman: can you file a bug describing it please
<spideyman> bigjools: I'm not sure if it's something I missed, I also don't see the global kernel paramaters Web UI option anymore
<spideyman> bigjools: was there a change to this?
<spideyman> bigjools: sure, although I'm not sure if it's a bug, or something I didn't update/install
<bigjools> what version did you upgrade from?
<spideyman> well, both before and after said 1.4.1
<bigjools> the option is there somewhere, I can't remember offhand where though!
<spideyman> it was here: http://localhost:8080/MAAS/settings/
<spideyman> and tag.create(kernel_opts="<whatever>") isn't excepted
<bigjools> if you are around later I can take a look
#maas 2013-01-16
<roaksoax> bigjools: howdy!
<roaksoax> bigjools: https://code.launchpad.net/~andreserl/maas/update_maas_url_on_upgrade_raring
<roaksoax> bigjools: so I proposed a branch for packaging that fixes the issues i found
<roaksoax> the issue is that maas_cluster.conf has MAAS_URL=http://localhost/MAAS
<roaksoax> this causes that the url passed on kernel parameters to be http://localhost/MAAS/metadata/etc/etc
<roaksoax> (for example)
<roaksoax> so the branch does two things
<roaksoax> 1. Allows reconfiguration of MAAS_URL (becuase it only configures it in new installs and doesn't chagne it on dpkg-reconfigure)
<roaksoax> 2. If no MAAS_URL has been set in dbconfig common, and the cluster-controller is installed in the same place where the maas-region-controller, then we obtain the MAAS_URL from DEFAULT_MAAS_URL (/etc/maas/maas_local_settings.py). Makes sense?
<bigjools> I don't understand why this is a problem for you, we tested this before and didn't have any problems
<bigjools> but either way I can't stop to look at this right now, sorry
<bigjools> I'll go through it with rvb later
<roaksoax> bigjools: this is a problem that i experienced in two different upgrades
<roaksoax> bigjools: which broke MAS
<roaksoax> MAAS
<roaksoax> i installed a clean raring from archives and upgraded and the issue was preseny
<roaksoax> i upgraded a quantal MAAS and problem was present
<roaksoax> bigjools:  and did you guys test upgrades only or also test enlistment/commisioning
<bigjools> I remember testing both
<bigjools> can you chase this up with rvb
<roaksoax> this was seen due to failing to enlist because the metadata url passed to cloud-init in kernel command line was http://localhost/MAAS/metadata
<bigjools> I'll make sure he has time to look at it
<roaksoax> ack
<roaksoax> ill upload the package with my worksround either way
<bigjools> I really don't understand how it's a problem - I know it worked for me :/
<bigjools> don't upload anything yet
<roaksoax> this fix is a packaging fix
<roaksoax> which is minor
<roaksoax> 1. is fixing dpkg-reconfigure (unrelated to thijs bug) 2. fixing this issue seen
<roaksoax> and I need to move on
<roaksoax> and get things done
<roaksoax> and until I don't have anything in the archives then i'm blocked
<roaksoax> either way, this can be removed, it is a 3 line change to fix this
<roaksoax> i'll get you screenshots so you guys can figure out what went wrong inside MAAS
<julianwa_> bigjools: hi
<bigjools> roaksoax: ok thanks
<bigjools> julianwa_: hi, so ...
<bigjools> what do you need to customise exactly?
<julianwa_> since 12.04 has ghes failed problem in kernel. I want to add  ghes.disable=1 there
<bigjools> ok
<bigjools> julianwa_: it's been a while since I touched the 12.04 code, but there's a pxe template that you can alter
<bigjools> look under provisioningserver/pxe/
<julianwa_> looks pxelinux.cfg/default is generated by cobbler.
<bigjools> oh crap I forgot about cobbler
<julianwa_> bigjools: that's ok. seems we found it in cobbler/config/profile.d/maas-enlist json file
<bigjools> sorry - it's been a long time since I even thought about the cobbler code, it's just a bad memory
<bigjools> let me know how you get on
<julianwa_> yes. I'm trying
<julianwa_> bigjools: it is done by change 'kernel options' in cobbler cmdline
<bigjools> ah ok
<bigjools> julianwa_: bear in mind that we're doing an SRU soon that completely removes the Cobbler part
<julianwa_> bigjools:  sure, I'd like to try the new MaaS and Juju :)
<spideyman> bigjools: Hi
<spideyman> can anyone have a look at: https://bugs.launchpad.net/maas/+bug/1100091
<ubot5> Launchpad bug 1100091 in MAAS "Kernel opts tagging feature missing completely" [Undecided,New]
<roaksoax> rvba: howdy
<roaksoax> rvba: so I just tested an upgrade with your fix on it
<roaksoax> rvba: and the same issue ramins
<roaksoax> remains
<rvba> roaksoax: did you upgrade from a 'broken' server?  My fix can't fix a broken server, but it's prevent it from getting broken.
<roaksoax> nope not broken server
<roaksoax> upgrade from an archive one
<roaksoax> let me test again
<rvba> roaksoax: can you run something like: http://paste.ubuntu.com/1538064/
<roaksoax> ok, just destroyed my environment
<roaksoax> re testing
<roaksoax> rvba: weird. It works this time
<roaksoax> rvba: so I confirm it is fixed
<roaksoax> rvba: thanks for your work on it :)
<rvba> roaksoax: cool, I'm relieved.  Thanks for testing it.
<roadmr> hey folks, kernel_opts is not working suddenly, what happened to it? :( got renamed?
<bitwiz> good afternoon, I just installed 12.10 maas and I am up to the point where I need to add an ssh key to the maas superuser account 'root'. I generate a key set using "ssh-keygen -t dsa -f root" afterwhich i cut and paste the key in the dashboard and it informs me that it is invalid. so what am i missing?
<roadmr> bitwiz: are you pasting the contents of root.pub in the dashboard?
<bitwiz> yes, and that is when i get the error
<roadmr> bitwiz: ok, try removing the -t dsa parameter
<bitwiz> i do a more root.pub on a putty term, and copy and paste the output
<roadmr> bitwiz: can you do this right now? I'd like to know if that works
<bitwiz> yes i can
<roadmr> awesome, thanks
<roadmr> bitwiz: if you omit "-t dsa" it will generate a rsa key by default
<roadmr> bitwiz: btw I don't promise it will work, it's just a stab in the dark :)
<bitwiz> same error without "-t dsa"
<roadmr> bitwiz: ok, let's have a look at the key itself then
<bitwiz> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCrKwLGTe1DCfF1u+lq/YeOl4y0YLPMIv7KYR6yhzFFJLfC0uiZHaGe596W4/gKxygPJ7xyK9kxmn90fPqFh6ms4NT/rZk20Foifuu3N06C/zhWyh4OUDomMnF/W MJfvq+lYr/Gq2DEYaij8/irMleB3TVanRimjv1rP3AjfzlE0VSBSWMlAYyD+dsB3QdqKUo1VqE90kcwfWCyIn/H1oR5b1HDNuCNWhJ/iPra7AinLJ2KH6wXOQ+rot7vfBq+HZdqy/TtjsKVlQW7kkQ1HixdJzMQ2l ddTps9q8ev8eDIv2Lv7XfFaj+oS6nl7az8ux1xTd4ihvrXs2rE7kZr3R33 root@cloud-controller
<roadmr> bitwiz: can you paste your .pub key here? (just as if you were going to paste it in the maas console)
<roadmr> http://paste.ubuntu.com/
<bitwiz> ok it is pasted
<roadmr> bitwiz: when you pasted it, it gave you a url http://paste.ubuntu.com/<some number>
<roadmr> can you put that url here?
<bitwiz> http://paste.ubuntu.com/1538666/
<roadmr> fantastic, thanks
<roadmr> ok as you can see, your key is split into three lines
<bitwiz> is that the issue
<roadmr> bitwiz: yes, what you need to do is this
<roadmr> paste it in the maas panel but before clicking "add key", delete the stray spaces at the end of each line
<roadmr> bitwiz: there's one after F/W
<bitwiz> ok, let me try that
<roadmr> and another after Q2l
<roadmr> bitwiz: the spaces are what's throwing it off, mostly
<bitwiz> you are correct.. it took the key this time. thank you
<roadmr> bitwiz: awesome, glad it worked :)
<bitwiz> i would have never thought of that. Now i know to look for multilines in keys
<roadmr> bitwiz: it's probably an issue with copying it from the terminal, maybe putty somehow inserts those spaces
<roadmr> bitwiz: I *think* multilines are fine, but once you squash them, the spaces cause the key string to be invalid
<bitwiz> that makes sense
<dsb> dannf: why...hello there.  ;)
<dannf> hey dsb
#maas 2013-01-17
<rvba> jam: mgz Hey guys, would you mind having a look at bug #1100091 ?
<ubot5> bug 1100091 in MAAS 1.2 "Kernel opts tagging feature missing completely" [Undecided,New] https://launchpad.net/bugs/1100091
<mgz> rvba: indeed, we were putting it on 1.2 but you guys were trying to do a release from that so we took it off
<mgz> if it's now wanted in a 1.2 release, it will need backporting
<rvba> mgz: Thanks for having a look.  What's weird is that the support is partially implemented (the db migration to add the new field is there for instance).
<rvba> mgz: I guess we need to clarify if it's a 1.2 or not.
<mgz> the db migration stuff is there because migrations only work in a linear fashion
<mgz> so, you can't backport one db change, but not the parts previous to it, without messing stuff up
<rvba> Right
<jam> mgz, rvba: last word I heard was that bigjools didn't want it to land in 1.2 at all.
<rvba> jam: well, Julian is the one who asked me to have a look at that bug.  I added a comment on it; I guess we will see what he has to say about it.
<rvba> mgz, jam thanks for your input guys.
<rvba> roaksoax: Hi Andres, do you manage to get nodes enlisted in your environment?  Because we're having trouble doing this in the lab and we're wondering if there isn't a problem with the ephemeral imagesâ¦
<roaksoax> rvba: howdy!! yeah im enlisting just fine. is this precise you are using?
<rvba> roaksoax: yes
<rvba> roaksoax: the nodes end up with an empty /etc/resolve.conf and the cannot do much.
<roaksoax> rvba: is there a screenshot of the failure?
<rvba> roaksoax: not really, but I can send you a log file if you want.
<roaksoax> rvba: adam_g reported yesterday a failure after a cloud-init update
<roaksoax> so might be related
<roaksoax> smoser: ^^
<smoser> ephemeral images have not changed.
<smoser> and should not be affected  by cloud-init in -updates
<roaksoax> smoser: whats the bug thst adam_g reported yesterday?
<roaksoax> rvba: logs would be helpful
<rvba> roaksoax: the failure itself is simple: in the logs, I see lots of "unable to resolve archive.ubuntu.com" and then the node gets enlisted with a stupid name because of bug #1081660.
<ubot5> bug 1081660 in maas-enlist (Ubuntu) "If maas-enlist fails to reach a DNS server, the node will be named ";; connection timed out; no servers could be reached"" [Critical,Triaged] https://launchpad.net/bugs/1081660
<roaksoax> rvba: check squid-deb-proxy maybe?
<rvba> Logs looks fineâ¦
<rvba> We're trying with an old ephemeral imageâ¦
<rvba> Just to be sure smoser ;)
<roaksoax> ack
<smoser> rvba, ephemeral images have not been updated to my konwledge
<smoser> shoot.
<smoser> if you're using dailies, something could be wrong
<rvba> Damnit, it worked
<smoser> rvba, were you using dailies ?
<rvba> We're using the daily images in the lab indeed.
<smoser> yeah. ok. so there is work to fix there then. i'm not sure what :-(
<rvba> The symptom was: the image was dhcp booting ok but ended up with an empty /etc/resolve.conf
<smoser> rvba, are you easily able to test quantal daily ?
<smoser> wait. not woth it.
<rvba> all right
<rvba> (but the answer would have been 'yes')
<roaksoax> rvba: the kernel opts stuff was removed from 1.2?
<roaksoax> rvba: as in the stuff that allows us to specify extra kernel opts?
<roaksoax> with tags
<roaksoax> jam: ^^
<rvba> roaksoax: it was removed from 1.2 because Julian told jam the 1.2 was supposed to contain only bugfixes and no new features. Apparentlyâ¦
<roaksoax> -_-
<roaksoax> -_-'
<rvba> roaksoax: maybe we will revise that but we're waiting for Julian to decide :)
<roaksoax> ack!
<roaksoax> thanks for the info
<rvba> (ã)
<bitwiz> does this error have anything to do with the error WARNING **: mirror does not support the specified release (precise)? I am also getting that error when a node pxe boots the inital install
<bitwiz> the console log also show INFO: mirror does not have any suite symlinks. When i run the wget command on a virtual console one the node, i get a line for both Suite and Codename
<roaksoax> smoser: so simply said, the fastpath installer is different kernel opts with different user-data right?
<smoser> are there different kernel opts ?
<smoser> wait.
<smoser> ok. so what it is ...
<roaksoax> http://bazaar.launchpad.net/~smoser/+junk/xinstall.maas/view/head:/maas.changes.diff
<smoser> roaksoax, it is possible that i could have changed that else on line 51 btter
<smoser> roaksoax, yea... so really the only additional prameter to the ephemeral environment is 'ds=nocloud-net
<smoser> '
<roaksoax> smoser: ack
<smoser> which convinces cloud-init it should just use the stuff from cloud-config-url= and not expect a datasource.
<roaksoax> smoser: so in this case cloud-config-url is the contents of the /etc/maas/FAST-PATH-INSTALLER file
<smoser> no.
<smoser> that is an empty file. that just indicates if it should be taken or not
<smoser> the payload is in 'preseed_fastpath' (see first hunk)
<smoser> htat file is wrtten by the command listed in http://bazaar.launchpad.net/~smoser/+junk/xinstall.maas/view/head:/README.maas
<smoser> we might be able to get rid of the different kernel param
<smoser> and that is probably the correct fix.
<smoser> as it maas's life much simpler.
<roaksoax> yeah i'm just trying to visualize how to do this
<roaksoax> rvba: so we have an issue, maas doesn't support raring
<roaksoax> rvba: and it doesn't really makes sense to hardcode stuff
<smoser> "maas doesn't support raring"
<smoser> a.) that needs to be fixed
<smoser> b.) why does that matter here
<smoser> c.) what does that mean (doesnt support installing?)
<roaksoax> smoser: yeah
<roaksoax> smoser: raring is not a 'supported' release within MAAS
<roaksoax> smoser: since it is being hardcoded
<roaksoax> it was automatically detected before but was decided to not use that and hardcode it for the time being
<roaksoax> smoser: we will not be using this right? # this line just says to use a different url (with -root.tar.gz)
<smoser> roaksoax, well, the end goal is that we'll be using a -root.tar.gz to install from.
<smoser> but we only have available on maas.ubuntu.com/images partition images.
<smoser> elsehwere in that doc README.maas it explains it (see line 55)
<roaksoax> smoser: ok, so we need 1. create the -root images (i'm guessing with maas-import-pxe-files)
<roaksoax> 2. create /usr/share/maas/preseeds/preseed_fastpath on the fly
<roaksoax> 3. have a tag that tells a system to fastpath
<roaksoax> 4. have a tag that tells a system extra user-data
<roaksoax> to be integrated with 2
<smoser> 1 should happen on the server side. tthe client should not need to create those. although it is sufficiently easy, so maybe that makes sense. it does require root though :-(, so maybe not.
<smoser> anyway. .. .one way or another we need to have -root.tar.gz files availble for the installer to get at.
<smoser> i might generalize 3 and 4 into one thing from maas perspective.
<smoser> basically:
<roaksoax> smoser: yeah i already have the tags stuff
<roaksoax> (r partially)
<smoser>  if a node has a tag (through inheritance or directly) named 'install_preseed', then use that preseed.
<roaksoax> smoser: the -root needs to be created on server side once maas-import-pxe-files is invoked though
<smoser> this can probably be done in the existing preseed manner.
<smoser> ideally, maas's knowledge of "fast path" should come down to
<roaksoax> smoser: i'f the tag is fastpath=True, then I tell that the purpose is fastpath (which could be 'commissioning', or 'install')
<smoser> a.) allow tag data to affect preseed data
<smoser> b.) boot ephemeral image as the installer
<smoser> c.) (if we have to) allow tag data "fastpath_install_kernel_opts='ds=nocloud'" to affect kernel options to 'b'
<smoser> that make sense ?
<smoser> then maas really is completely unaware of "fastpath"
<roaksoax> smoser: yeah
<roaksoax> smoser: this is what I was thinking: http://paste.ubuntu.com/1542176/
<smoser> done use the string fast path
<smoser> and decouple "preseed_input" from "should_install_use_ephemeral_environment"
<roaksoax> smoser: so tag would be ephemeral_install
<roaksoax> or similar
<smoser> right.
<smoser> and then... the preseed templates
<smoser> when theyu're rendered, do they have access to the node ? and its tags ?
<smoser> carp. i thought tags had values. that sucks.
<smoser> a tag as "kernel_opts"
<smoser> :-(
<roaksoax> smoser: they should yes
<smoser> no. i'm saying tags do not have values. its not key-value.
<smoser> its just key.
<smoser> which sucks.
<smoser> and its limited to 256 chars
<smoser> which also sucks
<smoser> you'll have to ask the maas devs about this. i dont udnerstand it really.
<roaksoax> yeah
<smoser> oh.. ok. re-using the kenelopts stuff. we can just override that. here..
<smoser> we add maas awareness of one tag:
<smoser>  installer_ephemeral_kernel_opts
<smoser> if that is set, then it uses the 'kernel_opts' for that and uses the ephemeral environment for install
<smoser> err... i guess you can cut the 'kernel_opts' part off the name
<smoser> hten, to allow the user to atually put useful *DATA* into the preseed path, we will need to put another field in.
<smoser> into the tags, but lets just call it "value" or something.
<smoser> that make sense?
<smoser> why oh why does a tag not have a value *and* be limited to 256 chars
<roaksoax> smoser: right, that's similar to what I;m doing
<smoser> heh. i guess we could just use tag names like:
<smoser>  installer_opts=http://place.where.my.opts.are
<smoser> i dont know.
<roaksoax> uhmm
<smoser> ha. funny.
<smoser> we just overload 'comment' with data
<smoser> base64 encoded data.
<smoser> then, if the preseed templates have access the currently executing node's tags, we can base64 decode there.
<roaksoax> yeah
<roaksoax> that too
<smoser> jtv, anyone here able to explain to me why a tag would be so limited value ?
<smoser> roaksoax, the more long term fi for this would be to have maas know about some "installer_input" and actually handle that specifically
<roaksoax> yeah
<roaksoax> i guess i'll have to discuss this with the MAAS team
<smoser> do you know if we can get at node's tags in the preseed?
<roaksoax> smoser: if we add them to the context we can
<smoser> they shoudl definitely be part of the context
<roaksoax> yeah
<roaksoax> so I'll first work on getting the boot stuff, kernel params, image, etc, working as expected
<roaksoax> then will deal with the preseed that
<roaksoax> preseed data
<roaksoax> smoser: Hold on
<roaksoax> smoser: so we can do this: maas-cli tag create --name=00-default-console --definition=true \ --kernel_opts=console=ttyS0
<roaksoax> err
<roaksoax> maas-cli tag create --name=ephemeral_install --definition=true  --ephemeral_install_data=XYZXYZXYZXYZ
<roaksoax> mgz: ping
<smoser> roaksoax, ephemeral_install_data ?
<smoser> you're saying we'd have to add that.
<roaksoax> smoser: so if I do this: http://paste.ubuntu.com/1542262/, that means that we can define a tag with *any* name
<smoser> definition is not that though. defnition describes the nodes that it applies to
<roaksoax> smoser: right, forget about definition :)
<roaksoax> so we owuld be adding another attribubte to the tag
<smoser> overload comment
<smoser> :)
<roaksoax> so the tag would have a name, definition, and ephemeral_install_data attribute
<roaksoax> and comment
<smoser> oh wait. that might not work because tag is probably unique
<smoser> maybe it is id ont now.
<roaksoax> right so we can create a tag  name=ephemeral, comment='ephemeral install', definition='whatever', ephemeral_install_data='data to use at install time'
<smoser> right. i get what you're saing. we could do that. but i'd say that it shouldn t be "ephemeral_install_data"
<smoser> it should just be "value"
<roaksoax> smoser: you mean this?: http://paste.ubuntu.com/1542272/
<roaksoax> smoser: so the 'name' would *always* have to be say 'ephemeral_install' and we would have to check for that
<smoser> tags dont work here i dont think.
<smoser> 'name' is unique
<roaksoax> smoser: so if someone defines: name='ephemeral_installer' value='blob' it wouldn't work
<smoser> not unique per-node, but unique.
<smoser> right.
<roaksoax> so we would have to check for the name of the tag
<roaksoax> smoser: now the problem is how to pass the user data
<roaksoax> say we create a tag with --value=/path/to/filename we would need to modify the cli
<roaksoax> to open the file, convert it in a base64 blob
<roaksoax> etc etc
<smoser> --value wont work
#maas 2013-01-18
<Baribal> Hi. IS there a way to set up an already installed machine as a node without having to reinstall?
<Baribal> Also, is it possible to use a machine both as region-controller and a node? 'Cause, why waste a good machine? (Especially if you only have one...)
<bigjools> Baribal: no that's not possible
<bigjools> you can share a machine for region and cluster controller though
<jtv> Small consolation, perhaps.  :)
<bigjools> well it's a bit chicken and egg isn't it :)
<Baribal> Depends on what MAAS does exactly... But are you considering to lift that limitation?
<Baribal> Also, what about making an already installed machine a node?
<jtv> As far as I know, that's not under consideration, no.
<bigjools> it's not a limitation that we have any control over
<bigjools> you have to provision nodes before you can use them - that's what maas does
<Baribal> How about running a VM on the host which is used as a node?
<jtv> You mean use the VM as a node?
<lifeless> you can do that, but its not a MAAS task to provision VMs
<bigjools> also tools such as juju assume exclusive access
<Baribal> Inhowfar exclusive?
<jtv> It's assumed that the entire install is basically disposable.
<jtv> When you allocate a machine through juju, it normaly assumes that that machine is only used for the application that juju puts on it.
<Baribal> Just for clarity: That'd be the units juju deploys?
<jtv> Yes...  I guess a unit is both an instance of an application on the one hand, and an entire machine on the other.
<Baribal> Wait, so per machine, only one unit gets deployed?
<bigjools> normally yes, but you can override that
<bigjools> but the point I am making is that this is one application that assumes that it has total control of nodes
<Baribal> Okay... How do I override it? 'Cause all I have to run MAAS on is two 8right now one :( ) VM.
<bigjools> are you using juju?
<Baribal> Yes.
<bigjools> I can't remember the config offhand
<bigjools> let me see if I can find it
<bigjools> unless jtv remembers
<jtv> Don't even know what config you're referring to...  doesn't juju also need a bootstrap node?
<bigjools> yes but you can make juju dispatch charms to the bootstrap node
<jtv> Ah!  Don't know the config for that then.
<bigjools> Baribal: in the maas section in environments.yaml, add this:
<bigjools> placement: local
<bigjools> and charms get dispatched to the bootstrap node
<Baribal> Not exactly what I'd prefer, but definitely what I need right now. Thanks. :)
<Baribal> So... Is installation time the only one I can make a machine a prospective MAAS-node?
<bigjools> yes, maas is designed to provision bare metal from scratch
<jtv> That's what it amounts to...  You make it a node first, and installation follows.
<Baribal> Okay... Too bad, I have no control over the machine at installation time.
<bigjools> maas is responsible for installing the OS that the API client requests
<Baribal> So I guess I'm back to using Openstack for the moment.
<bigjools> yeah you don't want MAAS then
<bigjools> maas can do VMs but it's more of a testing feature
<jtv> No creation or destruction â you create them and then basically have maas believe that they're physical machines.
<Baribal> I'll try again when I'm building my cluster... But if I understand correctly, my choices are to deploy all units to the bootstrap node or I need one machine per unit? Not quite what I expected.
<bigjools> there may be more to it, but you should ask on the juju channel about that
<Baribal> Will do.
<bigjools> I believe there's a plan
<Baribal> "Going away and buggering the OpenStack people"? :)
<jtv> "bugging"
<jtv> Because "buggering" means something completely different.  :)
<bigjools> well, maybe they ...
<Baribal> Oops...
 * jtv laughs
<lifeless> Baribal: being one of those openstack people...
<lifeless> Baribal: I'd rather you nag us than bugger us.
<Baribal> Don't worry, I'm great at nagging. :)
<Baribal> But, right now, I'll go sleep, I think. I've tried the whole day to get my cloud running...
<Baribal> lifeless, just one quick question: Is Essex still the current OpenStack release?
<Baribal> 'Cause I'm hunting for setup tutorials.
<lifeless> folsom
<lifeless> grizzly coming up
<Baribal> Thanks; so http://docs.openstack.org/folsom/basic-install/content/ is probably what I'll want to read. Except if there's a good shortcut?
<lifeless> no shortcuts :)
<lifeless> not if you want to understand what you're turning on
<Baribal> I do, but not right now.
<lifeless> well for that case you can just install the openstack packages on both nodes
<lifeless> one controller + compute, one compute
<lifeless> I recommend reading a bit though, its useful to know
<lifeless> ...
<bitwiz> has this question been resolved? https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/207347 I am having the same results on my new install of 12.10 maas
<roaksoax> allenap: around by any chance?
<roaksoax> matsubara: around?
<matsubara> roaksoax, yes
<roaksoax> matsubara: had a question for you which you miht be able to help me with
<matsubara> shoot
<roaksoax> matsubara: in a multinode maas cluster, who holds the pxe images, the region or the cluster?
<roaksoax> s/holds/stores
<matsubara> I think the region is the first one to get but then when the cluster requests the images from the region, it then stores them itself
<roaksoax> matsubara: ack! thanks for the info
<matsubara> this is my understanding of it, not sure if it changed since the EOY break. didn't touch the cluster controller stuff
<matsubara> I'll know for sure next week when I resume working on the jenkins job to test the cluster controller
<roaksoax> cool
<roaksoax> thanks for the info though
<matsubara> np
<dpb_> Hi -- if a node is claimed by a user or allocated.  How do I release it, forcefully is fine.
<dpb_> nm, figured it out   maas cli -- node release
#maas 2013-01-19
<Guest76306> hello world
<krava> could anyone help me?
<Baribal> krava, just ask your question directly, only then people here will see if they can help you.
<krava> sorry, I've just not hit Enter...
<krava> for this time I've installed MAAS on other hardware, it's working
<krava> and ok, I have one node, it is in 'commisioning' state. on console I see login query
<krava> hmm... I can't login to node. What's next? Juju?
<AskUbuntu> Adding nodes to MAAS | http://askubuntu.com/q/245096
<dsb> Are the power parameters for virsh documented anywhere?
<dsb> google is failing me.
#maas 2013-01-20
<sam_one> anybody else in SFO waiting for the late UA flight?
<sam_one> grr, mischannel...
#maas 2014-01-13
<roaksoax> bigjools: howdy! when did the change to update-dns stuff landed and when did the integration tests start failing?
<bigjools> roaksoax: not sure, raphael did the investigation work
<bigjools> but before xmas at least
<roaksoax> bigjools: err upstream_dns stuff
<bigjools> I thought it was your changes for the charm?
<roaksoax> bigjools: nope, I never made that change
<bigjools> oh
<roaksoax> bigjools: oh it is the DNS forwarders stuff
<bigjools> don't think so, that's not changed in packaging
<bigjools> roaksoax: revno 215 on 2013-12-17 is the problem IIRC
<bigjools> your packaging change
<bigjools> "Split maas-region-controller into maas-region-controller-min"
<roaksoax> bigjools: i was talking about the DNS forwarders changes
<bigjools> roaksoax: oh sorry didn't understand what you were talking about
<bigjools> no, those are not even started yet
<roaksoax> bigjools: http://pastebin.ubuntu.com/6742345/
<bigjools> roaksoax: that's the upstream change - I thought you were talking about packaging changes?
<roaksoax> bigjools: so the issue hasn't really been a packaging change... thanks to the packaging change is that the issue was discovered
<bigjools> anyway that change didn't make the integration tests start failing AFAIK
<bigjools> ah cool, you found out what's up?
<roaksoax> bigjools: the issue is that 'maas set_up_dns' is accessing the DB, when before it didn't use to do that
<bigjools> ah
<bigjools> makes sense
<roaksoax> bigjools: so, http://paste.ubuntu.com/6742346/ -> So this is a hack I use to "fix" this
<bigjools> do you have a recommendation?
<roaksoax> bigjools: combined with http://paste.ubuntu.com/6742350/ I think we can solve the problem
<bigjools> yeah we don't need it in postinst for sure, the job will deal with it
<roaksoax> bigjools: obviously for the upstream change, instead of a try/except, we can simply add a parameter to specify /'maas set_up_dns --upstream-dns=None
<bigjools> yeah I'd prefer that over a try/except
<bigjools> param to override it fetching from config
<bigjools> it's amazing what innocuous changes will break elsewhere ...
<bigjools> thanks for figuring it out dude
<roaksoax> bigjools: yeah! But anyways, adding the parameter (which should be fairly simply), and removing the line in maas-dns.postinst, we have things back to normal (without having to revert changes back)
<bigjools> +1
<bigjools> if that's definitely the cause, I'm good with it
<roaksoax> bigjools: yeah I installed maas-cluster-controller-min , and then started running DNS commands manually (those in the psotinst) and that's how I found out what was wrong
<bigjools> and bazinga
<roaksoax> indeed
<roaksoax> bigjools: so do we want maas set_up_dns to receieve a boolean parameter to not try to obtain the value from the DB, or do we want a parameter where we can actually set the forwarder?
<bigjools> roaksoax: set value is better
<roaksoax> bigjools: as in. 1. set_up_dns --no-upstream-dns or 2. set_up_dns --upstream-dns={None,1.1.1.1}
<roaksoax> ack
<bigjools> roaksoax: in fact do we need the code to fetch it from config at all?
<bigjools> the postinst is the only place that calls it IIRC
<roaksoax> bigjools: uhmmm I don't think so, cause celery tasks would also configure that, wouldn't they?
<bigjools> celery uses a different code path
<bigjools> this stuff is only a "maas XXX" command
<roaksoax> bigjools: right, but besides from maas set_up_dns, who sets the upstream_dns when found in the DB?
<bigjools> roaksoax: celery jobs
<roaksoax> bigjools: ok, so in reality, we don't really need it in set_up_dns, because the celery job will update that once it is manually added on maas then
<bigjools> roaksoax: indeed
<bigjools> that's what I was starting to think
<roaksoax> bigjools: ok, so this should do it: http://paste.ubuntu.com/6742417/
<roaksoax> bigjools: I'll get that tested alongside the packaging change
<bigjools> +1
<roaksoax> bigjools: ok it works : https://code.launchpad.net/~andreserl/maas/no_upstream_dns_on_setup/+merge/201332
<bigjools> jtv: super quick pre-imp?
<jtv> bigjools: sure...  firing up laptop.
<bigjools> jtv: plug it in this time? :)
<jtv> bigjools: any chance you could give this version of second DHCP detection a whirl?  https://code.launchpad.net/~jtv/maas-test/second-dhcp-check/+merge/201232
<jtv> This is meant to solve the problem you had detecting the DHCP server you were still running on the same machine you ran maas-test on.
<jtv> It should _also_ help with the case where the test interface has no IP address.
<rvba> jtv: I get a failure when I run maas-test (trunk)â¦
<rvba> it seems related to the DHCP stuff:
<rvba> http://paste.ubuntu.com/6743775/
<rvba> It looks (again, I might be wrong) as if we're running 'uvt-kvm ip <>' before the vm is even createdâ¦
<rvba> jtv: does that sound possible?
<jtv> It seems unlikely â AFAIK we do a "uvt-kvm wait" first.
<rvba> Ok, I'll investigateâ¦
<jtv> Looks like the problem you pasted is in get_maas_version, no?
<jtv> Ah!
<jtv> I think I know what it is.
<jtv> More or less.
<jtv> I made the install_maas() happen earlier than it used to.
<jtv> Shouldn't be before the "uvt-kvm wait" though.
<rvba> Looks like the MAAS fixture is setup before the KVM fixture :/
<jtv> No, but maas gets installed before the maas fixture is set up.
<jtv> Crossing changes.  :(
<rvba> (Revision 218 works)
<jtv> The exception seems to happen the second time install_maas runs.
<jtv> During MAASFixture.setUp().
<jtv> At any rate, if the traceback is correct, everything looks wrong.  Why would "uvt-kvm ip" fail that late in the game!?
<rvba> What second time?  install_maas should only be run once.
<jtv> Ah.  That is a change I made, but I guess it's still in the branch I'm working on.
<jtv> Note that we seem to be running "uvt-kvm ip" for every single command we run on the VM.  So you'd expect it to have succeeded at least once before this point.
<rvba> The vm doesn't seem to exist at all when we run this command.
<jtv> Missing sudo somewhere maybe?
<jtv> â desperate guess
<rvba> Frankly, I'm really confused by the reorganisation revision 119 introduced.
<jtv> It just removes some class fixtures and makes them variables in main().
<rvba> No, I put a debugging statement in run_command() and we simply don't create the VM at all.
<rvba> It's a bit more involved than that :).
<rvba> The result is that KVMFixture.setUp() is not called (or rather, we blow up in install_maas before it's even called).
<jtv> Ah!
<jtv> Now I remember.  This was a fix I had wanted to have landed, but it got held up by the current packaging trouble.
<jtv> It's a missing setUp call.
<rvba> gmb: btw, what I had in mind when I spoke about using run_command to include hardware information in the report is something along the lines of http://paste.ubuntu.com/6744069/
<rvba> gmb: of course, we'd want to format the output a bit better.
<gmb> rvba: Ah, thanks for the tip! I was looking for a way to do that as an API call in the mass-test code, but that seems straightforward enough (formatting notwithstanding).
<rvba> An API call will also work, but since we have everything setup to shell out on the VM, the solution above might be a bit more easier.
<rvba> s/more//
<gmb> Yep, that seems perfectly sane to me.
<rvba> gmb: for your viewing pleasure (I've always been very found of that expression), here is the result of that script on my test machine: http://paste.ubuntu.com/6744089/
<gmb> rvba: Lovely, thank you. Although when I say lovely I may actually mean "gaaaagh." But I'm not to worried about making it nice as I am about making it functional right now.
<rvba> Getting it to work sounds like a good first step to me :).
<rvba> gmb: actually, now that I think about it, it might be ever more simple to just do a "maas dumpdata."
<gmb> rvba: Does that basically give us the whole DB?
<rvba> Yeah.
<gmb> More data == more better.
<rvba> But the DB won't contain anything big so it's safe.
<gmb> Yep.
<gmb> Excellent.
<rvba> Plus we're sure we're not missing anything.
<rvba> self.maas.kvm_fixture.run_command(['sudo', 'maas', 'dumpdata'])
<gmb> Brill.
 * gmb does that.
<rvba> I'll give you an example of what you get back in a minuteâ¦
<rvba> (I killed my vm :/)
<rvba> gmb: http://paste.ubuntu.com/6744188/
<gmb> rvba: Why all the leading whitespace?
<rvba> gmb: don't knowâ¦ looks like it's an artifact created by paste of something, here is the file verbatim: http://people.canonical.com/~rvb/dump
<gmb> *eyebleed*
<gmb> rvba: My feeling is we should just dump it, attach it, and care about cleaning it up later. Thoughts?
<rvba> gmb: I agree.  It's pure JSON so it's easy to parse.
<rvba> gmb: as a second step, if we still want to do that, it's easy to exact identifiers from the lshw output.
<gmb> rvba: Okay. I'll finish this branch for gathering it, then I'll look at extracting stuff that's useful.
<rvba> Sounds good to me.
 * gmb -> lunch
<tomixxx> hi
<tomixxx> i have the problem that my nodes stay in state "commissioning"
<tomixxx> they never get "ready"
#maas 2014-01-14
<jtv> Why isn't the packaging building bin/maas-probe-dhcp!?
<jtv> bigjools: any ideas?  ^
<bigjools> jtv: where should it live do you reckon? cluster?
<bigjools> maas-dhcp?
<jtv> I was thinking maas-dhcp.
<bigjools> k
<jtv> I already have a branch installing it as part of that package.  The problem is getting it built.
<jtv> But feel free to write up your own branch; it's not exactly a lot of diff.
<bigjools> jtv: hmmm it needs to go in cluster controller
<bigjools> well doesn't *have* to but makes more sense to me
<bigjools> ah sod it maas-dhcp
<jtv> Well I had been wondering, but you weren't around: did we have a particular purpose in mind for it?
<jtv> Were we going to run it during install?  Or before starting our DHCP server..?
<bigjools> jtv: show me your diff
<jtv> I added to debian/maas-dhcp.install:
<jtv> debian/extras/maas-probe-dhcp /usr/sbin
<jtv> (Or various other things I tried).
<jtv> I also had a lintian-overrides, but I reverted that already.
<bigjools> well you need a bit more than that
<bigjools> MP coming
<bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/packaging-add-maas-probe-dhcp/+merge/201538
<jtv> Thanks.
 * jtv shall review forthwith
<bigjools> buildout scripts are a PITA
<bigjools> jtv: it's untested!
<bigjools> I figured since you were desperate ...
<bigjools> I can do it if you want
<jtv> I see that you managed to include bash.  :)
<bigjools> sadly
<bigjools> cargo culted existing ones
<jtv> What exactly do you mean by untested â "not covered by test suite" or "I haven't tried this yet"?
<bigjools> I haven't tried it
<jtv> Ah.  Well, it'll sort of come naturally with my manual testing, so don't worry about it.
<jtv> As long as the package builds...
<bigjools> ok
<bigjools> well let's do a test build first
<bigjools> I'll do it on cstack
<jtv> OK
 * jtv reminds self to write wrapper script for uvt-kvm
<jtv> bigjools: it's surprising to me that you can't just use the maas-prove-dhcp tool that buildout builds for us.
<bigjools> jtv: buildout doesn't run when packaging
<jtv> Ahhh.
<bigjools> it's a development convenience
<jtv> ...Because package-building prefers setup.py over make.
<jtv> If we didn't have setup.py, it'd have run "make," and then buildout would have run.
<jtv> Silly me.
<bigjools> jtv: nearly done testing, so far so good
<bigjools> jtv: and it works
<bigjools> jtv: branch merged
<jtv> Thanks bigjools
<rawang> hi anyone knows why I deploy service, every time I got "agent-state-info: '(error: cannot run instances: gomaasapi: got error back from  server: 409 CONFLICT)",   by looking at maas.log, I gotOAuthUnauthorized exception
<jtv> rawang: the two sound like they're different problems...  MAAS returns 409: Conflict in particular if no nodes are available that match your request.
<jtv> Unfortunately older versions of juju don't return the full error message.
<rawang> jtv, there are 3 available server in maas's pool
<jtv> And you specified no constraints?
<rawang> jtv, and i have use tag to bootstrap on one of them
<jtv> And the servers are all in Ready state, I guess...
<rawang> jtv, well for juju bootstrap, i have constais
<rawang> jtv, oh , you remind me maybe constraints is still there when boostrap the juju ...
<jtv> You could also try simulating juju's request directly against the MAAS API (e.g. using maas-cli) and seeing what the actual error message is.
<rawang> jtv, oh really, could you please give me a example? :)
<rawang> jtv, after I remove the constraints, it works, thanks :)
<jtv> Phew.  :)
<jtv> bigjools: any chance you could re-test my branch lp:~jtv/maas-test/second-dhcp-check against your hardware?
<jtv> I'd be particularly interested in these scenarios:
<jtv> 1. A regular, successful run (to see that nothing is broken).
<jtv> 2. There's a dhcpd running, but on the same interface you're running maas-test against.
<jtv> I'm trying it against scenarios where the network interface has no IP address.
<jtv> bigjools: scenario 2 needs your updated package inside the VM.  Easiest way to do that I suppose is to edit maastest/maasfixture.py and replace the apt-get with some other way of installing the package.
<rvba> jtv: you can test scenario 1 in the lab yourself, that's precisely why the manual job is made for.
<jtv> rvba: what is "the manual job"?
<rvba> jtv: I was referring to the email I sent yesterday "Manual maas-test Jenkins job in the lab"
<jtv> Ah, I'll have a look at that.
<rvba> jtv: with that you can get the lab to test a maas-test branch for you.
<jtv> Great.
<rvba> That will test your scenario 1.
<bjorne> I have a problem, i have try 12.04 and 13.10 and get same error
<bjorne> [21/Dec/2013:00:49:57 +0100] "GET /MAAS/metadata//2012-03-01/user-data HTTP/1.1" 404
<jtv> rvba: looks like that lab run failed...  Do we get the details that the tests attached anywhere?
<rvba> bigjools: when I comment out the broker's details (in the config), I still get a segfaultâ¦ so maybe the rabbit connection is not part of the problem after all.
<bigjools> rvba: interesting
<bigjools> rvba: can you run the celeryd itself up with minimal args?
<rvba> bigjools: that's precisely what I'm doing.
<bigjools> cool
<bigjools> so this smacks of a build/dependency problem
<bigjools> rvba: can I ssh into your machine?
<rvba> But it cannot run without some kind of configâ¦
<rvba> bigjools: sure, hang on.
<rvba> bigjools: ssh ubuntu@10.55.60.167
<bigjools> rvba: did you add my key?
<rvba> Yes
<bigjools> it won't let me in
<rvba> bigjools: ah, I'm logged in as root, just one sec.
<rvba> My bad
<rvba> bigjools: please try again
<bigjools> still can't get in
<rvba> humâ¦
<rvba> bigjools: can you try one more time (I'm watching the logs)
<rvba> ?
<bigjools> there
<rvba> Nothing
<bigjools> you gave me the right IP address?
<rvba> ssh ubuntu@10.55.60.167
<rvba> Yes
<bigjools> PEBKAC
<rvba> bigjools: when celeryd isn't configured to read MAAS' tasks, it doesn't blow up (!).
<bigjools> rvba: If I run "celeryd" on its own it crashes
<bigjools> no args
<bigjools> rvba: gah remind me how to remove core dump restriction
<jtv> bigjools: ulimit
<bigjools> jtv: tried it already
<bigjools> -bash: ulimit: core file size: cannot modify limit: Operation not permitted
<jtv> Hnyug
<rvba> bigjools: what core dump restriction
<jtv> Strange thing is, I can do that.
<rvba> ?
<bigjools> rvba: size
<bigjools> you don't get 'em by default
<jtv> Did you make it too big perhaps?  Unit of size is 512KB blocks.
<bigjools> jtv: "1" doesn't even work
<jtv> wha
<bigjools> I used "unlimited", doesn't work
<jtv> Are you sudo'ing it perhaps?  I guess that might refuse.
<bigjools> ulimit -S -c unlimited works
<bigjools> need the -S
<bigjools> gah no core file still
<bigjools> wtf
<bigjools> grah it's sending it to apport
<jtv>  /o\
<rvba> bigjools: I was wrong, it's just that sometimes it takes a long time to crash.
<bigjools> rvba: writing the core file no doubt
<rvba> bigjools: I noticed that python-celery (3.1.6-1ubuntu1) is now released in Trusty's cloud archive.  I started a new canonistack instance and installed python-celery.  When I run celeryd there is doesn't crash.  Maybe the package from our ppa is faulty?
<rvba> s/is doesn't/it doesn't/
<bigjools> rvba: quite likely, as I said, I suspect build or dependency problems
<rvba> Trying to install MAAS with python-celery from the cloud archive.
<rvba> (https://launchpad.net/ubuntu/trusty/+source/celery/3.1.6-1ubuntu1 says it was published 1 hour ago)
<bigjools> rvba: can I upgrade your other instance?
<rvba> bigjools: sure
<rvba> But I tweaked the configs.
<rvba> So it's better to start from a fresh instance.
<rvba> bigjools: arg, same crash with the python-celery from the cloud archive :/
<gmb> Why oh why oh why does Canonistack have the shits today?
<rvba> bigjools: it's really weird, look: http://paste.ubuntu.com/6749871/ vs http://paste.ubuntu.com/6749868/
<bigjools> rvba: did it work with the one in the main archive?
<bigjools> I still see a core
<rvba> bigjools: two similar Trusty machines, one one celeryd crahsed, on the other it does not.
<bigjools> !
<bigjools> this is python crashing
 * rvba installs maas on the machine where python-celery does not crashâ¦
<rvba> gmb: what do you mean?
<gmb> rvba: Instances keep dying on me. lcy01 must be out of RAM. Current one is staying up though, so far...
<bigjools> I gave up with 01
<rvba> gmb: hum, might be related to the problem we're seeing thenâ¦
<rvba> bigjools: these are all 01 machines
<gmb> rvba: Hmm, possibly. That said, if your instances are staying up, probably not. Nova is pretty proactive about pausing instances when it runs out of resources.
<gmb> So you'd know if it was affecting you.
<rvba>  ls
<rvba> Segmentation fault
<rvba> I think it's affecting me :)
<bigjools> rvba: I have a clue
<bigjools> it's falling over in librabbitmq
<bigjools> #0  0x00007fb4eef716ab in amqp_pool_alloc ()
<bigjools>    from /usr/lib/x86_64-linux-gnu/librabbitmq.so.1
<bigjools> so it's not celery's or python's fault at all
<rvba> bigjools: how did you find out?  In the code dump?
<bigjools> yep
<bigjools> it's rather annoying that someone bumped celery a whole major version
<bigjools> and didn't choose a new package name
<rvba> bigjools: did you see that running celeryd with strace?
<bigjools> rvba: no I analysed the core
<rvba> Ah okay, I see it now.
<rvba> bigjools: so, technically it blew up in librabbitmq1 but this doesn't tell us why exactly does it?  It might be a wrong interaction with another library.
<bigjools> rvba: amqp_pool_alloc
<bigjools> I suspect some esoteric part of rabbit changed
<rvba> bigjools: the most recent successful run we had in the lab is this: http://d-jenkins.ubuntu-ci:8080/view/MAAS/job/trusty-adt-maas-manual/4/console
<rvba> The console log gives us all the versions of all the packages used.
<bigjools> rvba: old celery?
<rvba> Yes
<rvba> An no trace of librabbitmq.
<rvba> bigjools: celery's changelog says (for the upgrade to 3.1.6-1 from 2.5.3-4ubuntu1): 'Drop depenceny on python-amqplib, it has been replaced by python-amqp/python-librabbitmq in python-kombu.'  And of course python-librabbitmq depends on librabbitmq1.
<bigjools> right
<bigjools> it needs a build with the -dbg library and then we can get which line of code blew up
<bigjools> my frantic googling is turning up nothing
<rvba> Same here.
<bigjools> I gotta sleep man
<bigjools> good luck and good night
<rvba> Yeah, I'll see if Andres can help us.  Maybe by creating debugging packages like you said.
<bigjools> you'll need andres
<rvba> bigjools: ^
<bigjools> just install -dbg ones
<bigjools> librabbitmq-dbg
<bigjools> and run again
<rvba> Oh, they exist already?
<bigjools> then when you get the core file:
<bigjools> gdb /usr/bin/python core
<bigjools> > bt
<rvba> Yeah, I know that part.
<bigjools> ok
<rvba> I'll try that.
<bigjools> ok I am going to bed
<bigjools> see you
<rvba> night
#maas 2014-01-15
<bigjools> hey roaksoax
<roaksoax> bigjools: howdy!!
<bigjools> roaksoax: hey - just wondered what the state of the rabbitmqlib stuff was?
<bigjools> regarding the crashes
<rawang> hello maas team, what does No PXE template found in u'/etc/maas/templates/pxe' means?
<rawang> i failed to deploy node the nodes is trying to install OS, and I got this error from pserve.log
<bigjools> rawang: are the templates there?
<rawang> bigjools, yes, they are all there
<bigjools> rawang: can you paste the pserv log and the maas log please
<rawang> bigjools, sure
<rawang> hi bigjools , i can paste the logs, but would you be happy to log in the the boston lab directly,  I can PM your creds, or you'd prefer to see the paste ? :)
<bigjools> rawang: logging in is nicer for sure :)
<rawang> bigjools, thank you
<rawang> bigjools, pserve.log http://pastebin.ubuntu.com/6754647/
<rawang> bigjools, maas.log http://pastebin.ubuntu.com/6754651/
<roaksoax> bigjools: so we are now default to use python-amqp, but that's set by maas
<bigjools> roaksoax: I saw, that's great, thanks
<bigjools> rawang: it looks for templates using this schema:
<bigjools>       config.{purpose}.{arch}.{subarch}.template
<bigjools>       config.{purpose}.{arch}.template
<bigjools>       config.{purpose}.template
<bigjools>       config.template
<roaksoax> bigjools: other than that, is the lander working fine? this afternoon it didn't seem so
<bigjools> rawang: are you sure nothing got removed?
<bigjools> roaksoax: the package lander is bust, I landed yours manually
<rawang> bigjools, i don't think so :)
<roaksoax> bigjools: ok cool, thanks!
<bigjools> roaksoax: it lives in the lab so I am going to move it to canonistack
<roaksoax> bigjools: ok, rvba also reported the trunk lander wasn't working either
<bigjools> rawang: can you tell me what arch you're booting, and prove an ls of the /etc/maas/templates/pxe dir
<rawang> bigjools, it's all there, 8 temples
<rawang> bigjools, amd64
<rawang> ubuntu@maas:~$ ls /etc/maas/templates/pxe/
<rawang> config.commissioning.armhf.template  config.install.armhf.template  config.local.amd64.template  config.local.template
<rawang> config.commissioning.template        config.install.template        config.local.i386.template   config.xinstall.template
<bigjools> roaksoax: yes it was broken earlier, all the canonistack instances had been shut off
<bigjools> roaksoax: so much for the freaking cloud
<rawang> lol
<bigjools> rawang: I'm afraid I have no idea what's up
<bigjools> it looks fine
<rawang> bigjools, i see, thanks for the help :)
<bigjools> rawang: I want to work out what's up though
<rawang> me too :)
<rawang> bigjools, maybe you can setup the routes, and connect to the box to see what's up if you have time right now? :)
<roaksoax> bigjools: hehe!!
<roaksoax> bigjools: nayway, i'm off to bed. Have a good one man
<bigjools> rawang: accessing the box is not a problem, it's the key
<bigjools> rawang: cheers, night!
<bigjools> errr
<bigjools> roaksoax: : cheers, night!
<rawang> bigjools, actually it's use username/password to login, but i have no idea why it's asking key
<rawang> bigjools, maybe you can try 10.230.167.2?
<rawang> bigjools, to see if login works?
<bigjools> rawang: ssh will be configured to disallow p/w auth
<bigjools> rawang: same problem with that IP
<rawang> hmm...
<rawang> bigjools, https://pastebin.canonical.com/102979/
<rawang> bigjools, it's trying public,password
<bigjools> rawang: gah, it's batuan that's kicking me out
<rawang> bigjools, oh lord :)
<rawang> bigjools, probably need to fix batuan issue first. :)
<bigjools> yep
<bigjools> jtv2: can you suggest why rawang gets this in his pserv? http://pastebin.ubuntu.com/6754647/
<bigjools> apparently the templates are there
<rawang> jtv2, yeah,  :)
<bigjools> rawang: what state is the node in that you're booting?
<rawang> bigjools, when I boot it, the server become from  "Ready" to "allocate to root",
<bigjools> rawang: so you're using juju or starting in the UI?
<rawang> bigjools, and the server boots, pending at "try to load  pxelinxu.conf/<mac>, and wait for time out
<rawang> bigjools, yes
<bigjools> ummm stumped
<rawang> bigjools, and when it's time out, it's loading   amd64/generica/commissioning/linux.gz etc
<bigjools> oh it starts loading the image?
<rawang> bigjools, and when the kernel / initrd loads, it's booted up ,and it's show  "maas-enlist-node" as the hostname....
<bigjools> as in, it gets past the pxe config?
<rawang> bigjools, yeah, when it's time out, it's loading linux.gz and initrd.gz from comissioning directory
<rawang> and end up with show "maas-enlist-node" , that confuse me :)
<bigjools> rawang: https://bugs.launchpad.net/maas/+bug/1064212
<ubot5> Ubuntu bug 1064212 in MAAS "If a machine is booted manually when in status "declared", TFTP server tracebacks" [Low,Triaged]
<rawang> bigjools, hm, it's still a open bug
<bigjools> rawang: exactly :)
<rawang> freeflying, ^^
<freeflying> rawang, we don't have any node in Declared
<bigjools> or Ready
<rawang> freeflying, yeah, it's a different, but someone also mentioned same applies in Ready state
<bigjools> did you manually power up something?
<rawang> bigjools, yes, manually power on the server after juju deploy something
<rawang> bigjools, as maas doesn't set up the ipmi correctly
<bigjools> rawang: in that case you are powering up the wrong one
<bigjools> I suggest that you set the ipmi properly
<rawang> bigjools, i don't think so, as i can see the hostname and IPMI ip of that server
<bigjools> rawang: that is the only reason you will get this message, can you double check
<rawang> bigjools, ok
<rawang> bigjools, yep, i have double checked that I started the correct server, and it keeps reporting the same error
<rawang> bigjools, output that error many times, exceptions.AssertionError: No PXE template found in u'/etc/maas/templates/pxe'!
<bigjools> rawang: can you set up the IPMI details properly and let it do its own thing
<rawang> bigjools, ok, let me try it
<rawang> bigjools, hmm, seems like this time it works,but maas didn't detect the IPMI, and didn't create maas user, i put the admin user in the nodes' configs
<bigjools> rawang: it only detects IPMI at enlistment time
<bigjools> otherwise you need to enter manually
<bigjools> if it worked this time then you were turning on the wrong one before :)
<rawang> bigjools, yes, what I mean is during the enlist stage, it didn't create maas user in server's IPMI,and didn't put the correct value in the node's config
<bigjools> rawang: what equipment?
<bigjools> rawang: ok can you report a bug about it and someone might fix it :)
<rawang> ok.
<rawang> bigjools, but it's not successfully install the OS using use-fastpath-install
<rawang> bigjools, when the server reboot, it stops "Can not get disk parameter \n boot: "
<bigjools> rawang: file a bug on curtin about that
<rawang> bigjools, ok
<freeflying> rawang, lets switch back to debian installer
<jtv> gmb: do you want your report-machine-info branch reviewed as it stands now?
<gmb> jtv: Nope, sorry. I'll make it WIP.
<jtv> OK
<jtv> I noticed there was a "### REMOVE" in there.
<bigjools> rvba: morning.
<bigjools> did you get this when building the dev env on trusty?
<bigjools> make: bin/pip: Command not found
<rvba> bigjools: yes
<bigjools> rvba: ok.  Only just got around to playing with it since I spent all freaking day dealing with broken landers
<rvba> (Plus the problem with postresql [make install-dependencies wants to install version 9.1])
<bigjools> rvba: yeah see my question on maas-devel
<rvba> Yep, saw that.
<rawang> hi bigjools, i have tried to use default install (preseed), but the OS installation, it stops at "boot: ", and only "local" is available, the error is "can no get disk parameters", do you have any idea?
<bigjools> rawang: no idea, sorry. You need a server guy.
<rawang> bigjools, i see, thanks :)
<freeflying> when pserv generate pxelinux.cfg for a node, it use one of the mac address or system_id of the node
<bigjools> freeflying: it uses the mac address that the pxe agent requests
<freeflying> bigjools, pxelinux.cfg/01-ac-f2-c5-ed-86-14 like this?
<bigjools> yes
<freeflying> bigjools, but why it has 7 numbers
<bigjools> the 01 is ignored, I forgot why it's there
<freeflying> bigjools, but why I saw the node request something like pxelinux.cfg/714ec577-d892-4e06-81c6-08674c9452bf
<bigjools> no idea what that is
<freeflying> bigjools, and turns out to not found such one, then the node try to get pxelinux.cfg/01-ac-f2-c5-ed-86-14
<bigjools> that's fine, it's designed to work like that
<freeflying> bigjools, btw, guess all the boot parameter will be generated by maas dynamically via chan.c32, am I right
* rvba changed the topic of #maas to: Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | Please read http://bit.ly/1j716Fc | MAAS documentation: http://bit.ly/1eIPFAg
* rvba changed the topic of #maas to: Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | Please read http://bit.ly/1j716Fc if you're having a problem with a MAAS instance | MAAS documentation: http://bit.ly/1eIPFAg
<tomixxx> hi i have a problem: after i have attached 2 nodes to my MAAS, they stay in the state "commissioning"
<tomixxx> i have already tried to synchronice HW clocks, but this does not solve the problem
<tomixxx> the 2nd suggested possibility, written here: Possible Cause: Network drivers http://maas.ubuntu.com/docs/troubleshooting.html, i dont know if this could be the problem and i dont know which steps i should do to install a "linux friendly network adopter".
<tomixxx> but i guess its sth else
<tomixxx> noone? :(
<tomixxx> a question: where can i find the "Global Kernel parameters" described here: http://maas.ubuntu.com/docs/kernel-options.html
<tomixxx> in my maas web interface i cannot see such a dialog...
<tomixxx> i have a problem: i have attached 2 nodes to my MAAS, but they stay in the state "commissioning"
<tomixxx> the never get to state "ready"
<gmb> tomixxx: Are these machines that you have physical access to?
<tomixxx> yes @ gmb
<gmb> tomixxx: Can you check whether they're PXE booting from the MAAS server?
<tomixxx> gmx: how exactly do i check this?
<gmb> tomixxx: Well, one way would be to attach a screen and see to the machine and see what it's actually doing at boot time.
<chris38> tomixxx, I encounter this problem from time to time, which is for me a problem with interface order detection, especially with the fast installer
<tomixxx> i have a screen attached to the computer
<tomixxx> normally, if i boot the node, windows starts ;)
<chris38> I alos had this behind of a firewall
<gmb> tomixxx: H
<gmb> sorry
<gmb> tomixxx: How did you get the node into MAAS in the first place? Did you do it manually?
<tomixxx> gmb: i have a usb boot stick with ubuntu server 12.04.03 lts on it
<tomixxx> so i go into boot options, select booting from usb stick and then i chose the option with MAAS and in the following dialoges i could enlist on the MAAS server
<tomixxx> gmb: that's how far i come so far...
<gmb> tomixxx: Okay, give me a second...
<tomixxx> gmb: ok
<chris38> I have cpu count to 0 after comissionning any suggestion  to fix this ?
<gmb> tomixxx: What happens if you boot from the USB stick again after you've enlisted the machines?
<tomixxx> @gmb: give me a second, i will try
<tomixxx> i come into the language selection screen
<tomixxx> @gmb: should i select a language and go on?
<tomixxx> @gmb: i mean its the same screen when installing ubuntu
<gmb> tomixxx: Did you get the language selection screen before you got to the enlist with MAAS stuff before?
<tomixxx> @gmb: yes
<gmb> tomixxx: Okay, then yes, carry on
<tomixxx> ok, selected "english"
<gmb> (I haven't used the Avahi stuff myself, and it's sadly not very well documented)
<tomixxx> @gmb: now i can "install ubuntu serveR", "multiple server install with maas" and so on.
<gmb> tomixxx: If you follow "multiple server install" what options does it present?
<tomixxx> @gmb: well, after clicking "multiple server install.." i get another language selection screen
<tomixxx> @gmb: but it differs now from style a bit
<gmb> ok
<tomixxx> @gmb: i guess i should select english again?
<gmb> Yes
<tomixxx> @gmb: btw: at this point, additionally, i have to open a 2nd console and mount the /dev/sdb to /cdrom
<tomixxx> @gmb: if i do not this, ubuntu gives an error, cannot boot from cdrom
<gmb> ?!
<gmb> How annoying.
<tomixxx> @gmb: its the problem described here: http://askubuntu.com/questions/127398/usb-drive-install-of-ubuntu-12-04-server-fails-cant-find-components-from-cd-r
<gmb> Ick.
<tomixxx> @gmb: however, applied the mount-fix, selected english as language and europe->austria as location
<gmb> ok
<tomixxx> @gmb: local settings united states - en_US.UTF-8
<gmb> k
<tomixxx> @gmb: after some init procedures, i come to the dialog where i can choose a hostname
<gmb> ok
<tomixxx> now, i have three options listed : "ubuntu MAAS Server - (xx.xx.xx.xx:80)", "Specify MAAS by name or address" and "create a new MAAS on this server"
<gmb> tomixxx: Are these the same options you saw before?
<tomixxx> @gmb: yes
<gmb> Hmm.
<tomixxx> in meanwhile: the node is still "commisionen" from the run before, if i refresh the web-interface on the MAAS-server-node
<gmb> tomixxx: Sadly, I don't know how to help you from here because I don't know the avahi-maas stuff at all. Can you file a question on http://askubuntu.com/questions/ask?tags=maas and someone with knowledge of it will lget back to you as soon as they can.
<gmb> tomixxx: A node can be "Commissioning" without MAAS actually being able to do anything with it (e.g. if MAAS doesn't know how to cycle change the power state of the node and the node is switched off).
<tomixxx> @gmb: ok
<tomixxx> @gmb: i have alrady set power type to "wake-on-lan" and set mac address
<gmb> Hmm.
<gmb> tomixxx: Okay. Ask the question anyway and we'll endeavour to get back to you quickly.
<tomixxx> @gmb: ok, thank you very much so far!
<tomixxx> ok, question is online so far, plz let me know if u need further details: http://askubuntu.com/questions/405937/2-added-nodes-to-maas-server-but-their-state-does-not-change-from-commissioning
<matsubara> tomixxx, Can you check, in the MAAS server, if the power_on task has been triggered? It's in /var/log/celery*.log. I'm not sure but it could be a bug using the wake-on-lan power option. Another thing to bear in mind is that MAAS will probably destroy the contents of your nodes disk, so if you're dual booting the nodes, your windows install might be gone.
<tomixxx> @matsubara: ok, i'll chekc the log
<matsubara> log line looks something like this: http://pastebin.ubuntu.com/6756972/
<tomixxx> hmm, i have no such file
<matsubara> tomixxx, oops, my bad, /var/log/maas/celery.log
<tomixxx> kk
<tomixxx> ok, i ve openend the file now
<tomixxx> and i can find similiar log entry like u have postet indicating "power_on succedded:None"
<matsubara> tomixxx, so, after the machine enlisted, it automatically turned off, right?  Then you accepted it in the MAAS web UI, it changed to commissioning. Did the machine turn on automatically?
<matsubara> so, that might be the reason (i.e. wake-on-lan not working)
<tomixxx> @matsubare: yes, machine turned off, but never turned on again
<tomixxx> log-file: pastebin.ubuntu.com/6757001/
<matsubara> tomixxx, so, what I'd suggest is to first test that wake-on-lan work between your machines. See https://help.ubuntu.com/community/WakeOnLan on how to test it.
<tomixxx> kk
<tomixxx> ok, iam an idiot, i have uploaded the full logfile to pastebin... sorry for long-loading times...
<matsubara> tomixxx, np, I'll take a look in a bit. I'm in a call right now
<matsubara> tomixxx, so, I took a look at the log you pasted and it seems to me the problem lies in MAAS trying to power on the node but failing (although the log says the task succeed). I think the code doesn't really check if the node has been power on and the succeed message means that the task has been run without errors.
<matsubara> tomixxx, so, my suggestion is to try to test wake on lan outside of MAAS first and make sure it works, and then retrying enlistment/commissioning in MAAS
<tomixxx> @matsubara: kk, at the moment, i try to establish "wake-on-lan". i follow this article, since i have only windows pre-installed on the nodes: http://windows7-issues.blogspot.co.at/2011/03/wake-on-lan-wol-for-windows-7-made-easy.html
<matsubara> tomixxx, you can use the live cd from the usb stick, I guess
<matsubara> tomixxx, https://help.ubuntu.com/community/Installation/FromUSBStick#live-usb
<tomixxx> ok, ty
<tomixxx> thanks for help so far, iam offline now but ill join this channel tomorrow again
#maas 2014-01-16
<rvba> jtv1: default zone branch is up for review https://code.launchpad.net/~rvb/maas/default-zone/+merge/200635
<rvba> jtv1: I'm reviewing your maas-test branch now
<jtv1> Thanks.  I'll have a look at yours.
<rvba> Ta.
<rvba> jtv1: gmb there is still something left to do with the AZ stuff: update the documentation (to account for the default zone thingy) and add a node saying this feature is only available in the version published in Trusty.
<rvba> s/node/note/
<jtv1> Ah great.
<tomixxx> hi regarding )<matsubara>tomixxx, https://help.ubuntu.com/community/Installation/FromUSBStick#live-usb from yesterday: does this mean i have to INSTALL ubuntu on my nodes ?
<jtv> tomixxx: no, you shouldn't have to do that.  Misunderstanding?
<jtv> On your servers though, yes please.  :-)
<jtv> roaksoax: turns out we got unlucky and cut the Trusty package just when we had that one script briefly in the wrong package.  What do I need to do to set that right?
<tomixxx> jtv: i have one server and 2 nodes. the server has both, windows 7 and ubuntu server tls 12.04.3 installed, the 2 nodes have only windows 7 installed
<roaksoax> jtv: i already have the fix for it. it is just a simple Conflicts/Breaks
<jtv> tomixxx: maas installs ubuntu on the nodes remotely (by netbooting them into install images)
<tomixxx> jtv: y, but woke-on-lan is not working correclty, so my maas-server cannot boot the nodes
<jtv> That's annoying.  If they can still netboot, you can turn them on manually â but it's not going to be as nice.
<jtv> (Wake-on-LAN also has the problem that it can't power nodes down again)
<tomixxx> but if i start the nodes manually, nothing happens, except windows 7 is starting
<tomixxx> and the nodes tay "commissioning" in maas web interface
<jtv> Are they set up to boot off PXE?
<tomixxx> good point
<jtv> What happens there is: MAAS has tried to power the node up, and expects the node to netboot off the server.
<tomixxx> i understand, i will check boot order of my nodes
<jtv> Very important.  :)
<jtv> BTW be aware that that will install the system right over the nodes' existing OS.
<jtv> So make sure there's nothing on those nodes' disks that you want to keep!
<tomixxx> kk
<tomixxx> hmm i cannot select booting from network in bios/boot options
<jtv> Ouch.
<jtv> Does it say why not?  Or is the option just not there?
<tomixxx> option is not there
<jtv> Maybe the BIOS has a separate option where you need to enable netbooting first, before it shows up in the boot order at all?
<tomixxx> kk, will check
<tomixxx> there is an option "onboard lan boot rom" -> "disabled"
<tomixxx> oh, sth going on here after "enabled" this option
<jtv> ?
<jtv> New entry in boot order?
<tomixxx> jtv: is it ok if i have now sth like the following: 1.) ubuntuI686nov10, 2.) ubuntuI686feb10,...5.) Acronis Partition.... boot:
<jtv> That's the boot loader?
<jtv> What matters is the boot order in the BIOS though.
<tomixxx> (btw, there was no new entry in boot order but i disabled all other and there is an option "enable other boots option"
<tomixxx> ok, so this does not come from maas?
<jtv> I don't think so...  Are you seeing that list in your BIOS?  Or in your boot loader?
<tomixxx> no, normally not
<tomixxx> btw: which power type i should select when i turn on the nodes manually?
<tomixxx> currently, i have "wake-on-lan" selected
<jtv> Keep that one.
<tomixxx> ok
<jtv> I'm still curious where you got that list... you said you have something like 1) ubuntuI686nov10, 2.) ubuntuI686feb10 etc.  Is that in the BIOS boot-order settings?  Or elsewhere?
<tomixxx> ah
<tomixxx> i just shut down the node, turn on again and now i can select "network: MBA v.12.2.5 slot 0200" in the screen "please select boot device"
<jtv> Ahh
<matsubara> tomixxx, nope, I was suggesting that you use the live usb stick to test the wake-on-lan in your network before you try again with MAAS
<tomixxx> matsubara: kk, but jtv told me that it might work with manually booting the nodes, so i try it now manually
<jtv> Which reminds me...  I bet there's a BIOS option for enabling wake-on-lan as well.
<tomixxx> when i choose booting from "network: MBA v.12.2.5 slot 0200" i come into the same selection than before:1.) ubuntuI686nov10, 2.) ubuntuI686feb10,...5.) Acronis Partition.... boot:
<tomixxx> but its not the "please select boot device" screen
<tomixxx> a screen that tells about the "SystemImager autoinstalls system v3.8.2"
<tomixxx> it seems these come from other servers of my university network
<jtv> You've got other DHCP servers on the same network?
<tomixxx> y
<tomixxx> in my maas i have the interface "unamanged"
<jtv> Then you also need to do some configuring on the DHCP server.
<tomixxx> so i have to configure DHCP in the maas-webinterface?
<jtv> Definitely the best option, yes.
<jtv> It does mean that your nodes have to be on a network of their own, where MAAS provides them with their DHCP.
<jtv> But if you're running multiple bootp servers for different purposes on the same network, I imagine things could get a bit confused.
<tomixxx> architecture is, that my 2 nodes are connected to my one maas-server with a SWITCH and the SWITCH is connected with the network of the university
<jtv> It should be possible to configure the DHCP server to say "when you netboot, please netboot from the maas server."  But it sounds as if that might interfere with your network setup.
<tomixxx> a question: which MAC address do i have to enter in the "wake-on-lan" dialoge when editing a node
<tomixxx> ?
<tomixxx> the mac address of the node or the mac address of the maas-server?
<jtv> tomixxx: the node's.
<tomixxx> ok
<tomixxx> so, should i try to set DHCP settings in maas-server?
<jtv> If you have a network that you can serve DHCP on, yes.  But be careful not to serve DHCP arbitrarily on the university network!
<jtv> Sysadmins don't take kindly to that sort of thing.  :)
<jtv> Everything may seem to work just fine, but then machines elsewhere start renewing their DHCP leases, and getting ones from your server instead of the one that's meant to manage the network.
<jtv> Or a machine that's meant to netboot off the departmental server tries to boot off the maas pxe server, and won't boot...
<tomixxx> ouch ok
<jtv> A "rogue" DHCP server (as it's called) is a really serious problem, unless the network is carefully managed to prevent it.
<tomixxx> so, i guess its better to let cluster interface "unmanaged" ?
<jtv> The best thing to do is to have the maas on a separate network, behind a router, and let maas manage the interface.
<jtv> If that's not possible, be aware that you'll need to tweak the configuration of the DHCP server that's already there.
<tomixxx> do i have to enable wake-on-lan in bios only on the nodes or also on the maas-server?
<jtv> You only need that on the nodes.
<tomixxx> ok...
<jtv> The server is really a pretty conventional thing.
<tomixxx> so, what could be the best next step now?
<jtv> Talk to the network admins.  What you need is either:
<jtv> (a) A network where your maas server can act as the DHCP server, without affecting the network.
<jtv> Or
<jtv> (b) *If* it isn't a problem for the network, a configuration change on the existing DHCP server, to tell clients that want to netboot that they should netboot off the maas server.
<tomixxx> kk
<jtv> Unfortunately you're in a kind of gap between two kinds of use: "private network" and "dedicated network."
<tomixxx> k
<tomixxx> ok, following hotfix idea:
<tomixxx> what is, if i remove the network cable which go out of my swith to the uni network?
<tomixxx> then i have my private network, not?
<jtv> The nodes will have to install packages.
<tomixxx> k
<tomixxx> and therefore, the need i-net connection...
<jtv> Now, if you could do it so that your maas server was still on the uni network, it'd work.
<jtv> Because the nodes should only talk to a proxy running on the maas server, never directly to the internet.
<tomixxx> and is it possible to pre-install the OS on the maas-server while internect connection is available, and then put away the outgoing network cable?
<jtv> In principle, yes.  But not easy yet.  There is something we could try.
<jtv> For commissioning, as I recall, the nodes only need some lldp packages.
<roaksoax> jtv: did you hit the upgrade bug?
<jtv> roaksoax: not me, but Raphers did.
<roaksoax> cool
<roaksoax> jtv: note that the file will now be present in both maas-region and maas-cluster i think (because python-maas-provisioning server will be isntalled in both)
<jtv> tomixxx: so, if on any machine you could set the http_proxy to be the MAAS server, and then install those same packages, you should be able at least to get through commissioning without hitting the internet...  In principle;
<jtv> roaksoax: that's fine, thanks.  We don't actually use it yet for anything inside maas itself, but we need it for maas-test.
<matsubara> tomixxx, how many network interfaces do you have in the MAAS server?
<tomixxx> matsubara: maas-webinterface is showing me one cluster-controller with two interface: eth0 and another one, without a name
<jtv> Ahh yes, good one!  The server could act as a bridge.
<matsubara> tomixxx, so, connect one of the interfaces to your uni network, the other to the switch and both nodes to the switch
<matsubara> that way you can test your MAAS stuff without breaking hell into the uni's network
<roaksoax> jtv: you moved it from maas-dhcp right?
<jtv> Yup.
<jtv> Thinking nobody would be releasing it juuuuust then.  :)
<tomixxx> matsubara: if i do  ifconfig in terminal, the second interface is called "lo" and link encap is local loopback
<tomixxx> so, is this really a interface?
<roaksoax> jtv: in reality this would only be a problem if someone installs what's currently in trusty and upgrades to something else (and technically, upgrades to something that's in trusty).
<roaksoax> since I'm not expecting anyone using trusty just yet... that shouldn't really be a problem
<roaksoax> but just in case, i'm adding this fix
<jtv> I figured there's probably a testing setup somewhere that could be hurt by this.
<jtv> If not, yes, I'm perfectly willing to forget the whole thing!  You'll know more about this than I do.
<roaksoax> jtv: https://code.launchpad.net/~andreserl/maas/packaging_upgrade_fix_dhcp/+merge/201937
<matsubara> tomixxx, ifconfig -a, I think will show you all the interfaces. even the ones that are down
<jtv> Grr... why do developers never listen to my suggestion for tab password completion?  It would save so much time!
<matsubara> you probably want eth0 and eth1 or something like that
<tomixxx> matsubara: i only have "eth0" and the mentioned "lo"
<tomixxx> after executing ifconfig -a
<jtv> So not enough to build your own private kingdom.  :/
<matsubara> tomixxx, yeah, only one interface then :-(
<tomixxx> kk
<jtv> Still, ethernet cards in a large network shouldn't be hard to get!
<matsubara> indeed, even an ethernet usb adapter should be pretty easy to find
<jtv> I'm not suggesting that you open the machine of a colleague who's not in right now and take one, but...
<tomixxx> in this room, there are only 3 nodes ^^ ofc, i additionally i have my laptop if this help sth...
<jtv> See if the admins have one lying around?
<tomixxx> ok, i have got a network interface card from my sysadmin
<tomixxx> i will plug it now into the maas-server
<tomixxx> ok, card is plugged in now
<tomixxx> ok, maas server and 2 nodes are now connected to the switch. the cable from the switch to the uni network is UNPLUGGED. a new cable goes from the 2nd interface of the maas-server to the university network
<ticking> tomixxx: hrhr, this is the exact same setup that we run as well
<ticking> nat all the things
<ticking> tomixxx: which university are you at?
<tomixxx> university of klagenfurt
<tomixxx> in austria
<ticking> cool, university bremen here (northern germany)
<tomixxx> hehe
<tomixxx> turned on the maas-server again, do i have to do sth when it says "waiting for network configuraiton" ?
<tomixxx> ah sorry
<tomixxx> if i do "ifconfig -a", i can see eth0 and eth1
<matsubara> tomixxx, you can run dpkg-reconfigure maas-region-controller to reconfigure MAAS. it'll ask what's the address of the pxe address, complete it with the value you get from the interface not connected to the uni network
<tomixxx> matsubara: it seems, network cards now have no IP so far
<matsubara> hmm but before you do that you might need t configure your internal network appropriately first
<tomixxx> i cannot connect to i-net
<tomixxx> but when i set dhcp settings in maas-server, i have already configrued my internal network, not?
<matsubara> tomixxx, right, so first you need to configure the network. Open /etc/network/interfaces and do something like this: http://pastebin.ubuntu.com/6762617/
<matsubara> assuming eth0 is the interface connected to the switch and eth1 is the interface connected to the uni network
<matsubara> tomixxx, then you sudo service networking restart and check with ifconfig if the IP is properly set for each interface.
<tomixxx> ok, first i have another problem: if i start windows i can see there is no driver installed for the new network card
<tomixxx> (i have both, windows and ubuntu installed on the maas-server ;)
<matsubara> tomixxx, Linux in general have pretty good support for network interfaces, so usually you don't need to install anything else.
<matsubara> tomixxx, so, booting up into windows doesn't really help configure the MAAS server
<tomixxx> kk
<tomixxx> i was a windows user all the time, so when things get unfamiliar, i tend to boot windows again
<matsubara> tomixxx, https://help.ubuntu.com/13.10/serverguide/networking.html has plenty of information on how to configure the network
<tomixxx> but a question: what is if i dont know if eth0 is the card which is connected to switch?
<matsubara> tomixxx, well, you can just try and if doesn't work, you reverse the order. The basic idea is to have the interface that's connected to the uni network set up to use dhcp and the interface connected to the switch with a static address
<tomixxx> hmm ok, currently i have edited /etc/network/interfaces and both set to dhcp
<tomixxx> but i-net not working so far
<matsubara> tomixxx, does it get an IP at all? Also, another thing to keep in mind is, if your uni dhcp server is serving IP address in the same range of the static address things won't work.
<tomixxx> i have started now sudo ifup eth1 resp. eth0
<tomixxx> i guess i need this?
<tomixxx> when i say sudo ifup eth0, response was: "interface eth0 already configured", sudo ifup eth1 still not finished...
<tomixxx> jesus, what about the promissed 20-minute-install time for the whole cloud as written on the ubuntu website ;)
<tomixxx> interesting: when i do ifconifg -a, i cann see sth like "eth0:avahi" and "eth1:avahi"
<tomixxx> additionally
<tomixxx> to the 2 interfaces
<tomixxx> but i have still no internet on my maas-server :( and it seems the interfaces only have ipv6 addresses
<matsubara> tomixxx, I'd suggest get some help from the sysadmin that got you the new interface card. The uni's admins knows how the uni network really works and once you get that configured we can get back to MAAS
<tomixxx> y, u are right, this has nothing to do with maas what iam posting here...
<tomixxx> interesting thing, if i plug network cable from the uni to the onboard-ethernet-card, internet works
<ticking> tomixxx: btw you might want to be carefull, when activating dhcp
<ticking> the sysadmins might come and hurt you if you break university wide dhcp, because you broadcast in the same range they do
<ticking> you want to set up nat
<ticking> https://help.ubuntu.com/community/Router
<ticking> you can check which card is which by calling ifconfig in the terminal
<tomixxx> at the moment, i have the problem that one of my two network cards does not find correct drivers
<tomixxx> ok guys
<tomixxx> eth0 ---- dhcp to uni, internet works
<tomixxx> eth1 ----- static ip as suggested 192.168.1.1
<tomixxx> in maas-web-interface,  i guess i have to delete eth0 from cluster-controller and add eth1, right?
<tomixxx> matsubara, jtv, someone online?
<matsubara> tomixxx, I'm here but a bit busy at the moment. Would you mind bringing this up in the maas mailing list or askubuntu? That way the solution will be archived and others might be able to jump in to help as well.
<matsubara> tomixxx, but you're right, delete eth0 from the cluster-controller and add eth1 and make it manage dhcp for you.
<CarlosC> greetings, I am going to be using maas for our deployments for our clusters and wanted to see if there is a more "architecture" friendly document for maas
<CarlosC> I really want to understand the regional controller / cluster/ cluster controller better
<roaksoax> CarlosC: this might help: http://www.roaksoax.com/2013/05/getting-started-with-maas-and-juju
<CarlosC> roaksoax: very nice, thanks
<CarlosC> let me digest this and I'm sure there will be more questions to follow ;-)
<CarlosC> ok...so a cluster is the smallest unit for managing nodes...how is HA achieved at the region controller level?
#maas 2014-01-17
<rvba> gmb: care to review: https://bugs.launchpad.net/maas/+bug/1270052 ?
<ubot5> Ubuntu bug 1270052 in MAAS "Adding an SSH key fails due to a UnicodeDecodeError" [Critical,In progress]
<gmb> rvba, allenap: Free to review a short one? https://code.launchpad.net/~gmb/maas-test/report-machine-info/+merge/201395
<allenap> gmb: Sure.
<gmb> Ta
<gmb> allenap: Just noticed that lines 9 and 10 of the diff are redundant now.
<allenap> gmb: I just posted my review, which mentions that, but itâs still a +1.
<gmb> Winner.
<gmb> allenap: Your 3rd point is a good one, and applies to a couple of bits of maas-test. cases.py is not tested much, and neither is main.py. Sadly, we're doing ZFDD now.
<allenap> gmb: Oh, you cynic :)
<gmb> allenap: Nah, I got this one from the horse's (well, bigjools's) mouth.
<gmb> A mighty voice spoke from the clouds.
<gmb> It said:
<gmb> "Where the fuck are you, shortarse? I can't see you 'cos I'm taller than any human being has a right to be."
<gmb> Thus was the message delivered unto his people.
 * gmb may be about to have a psychotic break. Apologies.
<allenap> gmb: I canât think of anything to reply. I think Iâm due a psychotic break now; youâve induced one.
<gmb> What the hell, it's nearly the weekend.
<allenap> rvba: I think I might have found a bug in WithMACAddressesMixin.is_valid(). If thereâs an error, it does not update the value of `valid` before returning it.
<rvba> allenap: definitely looks like a bug
<allenap> rvba: Okay, Iâll file it.
<rvba> allenap: you might as well fix it, it's going to be quick
<allenap> Or fix it. rvba: Does is_valid() just return a bool?
<rvba> Yes
<allenap> gmb: Got time for a short review? https://code.launchpad.net/~allenap/postgresfixture/trusty-compatibility/+merge/202151
<allenap> gmb: No worries; Iâll selfie it for now.
<stokachu> anyone around and could help me debug what is going wrong with http://paste.ubuntu.com/6770456/
#maas 2014-01-18
<stokachu> what version of maas does the /api/1.0/users/ work with?
<stokachu> im running 1.4 and it returns a 404 when doing GET request
#maas 2014-01-19
<ging> can anyone help me deploying some nodes on kvm through maas
<ging> i follow the instructions here
<ging> https://maas.ubuntu.com/docs/nodes.html#virtual-machine-nodes
<ging> but cannot get it to work, it asks for a mac address, so i tried giving it the mac address of the machine but i see in the logs a not about mac address in use after i try and boot it from the cd
<ging> so i tried changing the mac and got hostname is in use
<ging> i don't really understand what maas is able to do with a vm, i through by setting up passwordless login for the maas user and giving it the address of the vm host and power id it would go and boot it and commision it, but that didn't happen
<ging> i'm fairly certain it is connecting to the vm host ok, because when i add the node with the vm powered off, it powers on
<ging> i run through the manual maas setup from the boot cd, it finds the maas server, i press ok, it shutsdown and doesn't start back up, and i find an error about hostname or mac in use in the logs
<ging> i've managed to break my maas server somehow now
<ging> it ran out of space on /var
<ging> but now won't run after i gave it more space
<ging> the apache error logs look like this
<ging> http://pastebin.com/AbQBJGQt
<ging> dpkg-reconfigure on maas-region-controller throws up a lot of errors about rabbitmq
<ging> ls: cannot access /etc/rabbitmq/rabbitmq.conf.d: No such file or directory
<ging> and ends with invoke-rc.d: initscript maas-txlongpoll, action "start" failed.
#maas 2015-01-12
<TrXuk> Hi All, new to MaaS and running into the 'iSCSI root mount issue' documented here https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354 The MaaS 'images' page of the UI only allows download of 14.04 (which seems to have the issue) and 13.10 which, once downloaded, cannot be selected as a commissioning image.
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<TrXuk> So, I downloaded a 14.10 daily (as the bug report suggests this is now fixed upstream) and worked out howto upload it as a custom image via the MaaS API
<TrXuk> However, I still cant select this image as the commissioning image, so I still have no way to enroll nodes into MaaS
<TrXuk> how do I get around this?
<TrXuk> Hi
<TrXuk> How do I create a custom boot-resource which can be used for commissioning new nodes in MaaS?
<TrXuk> I want to make one from the latest daily's to get around this bug, which still breaks 14.04 maas images
<TrXuk> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<roaksoax> .win 9
<CoilDomain> didnt have any problem with 3/4 of the nodes, but one of them is having this issue, has anyone seen it?
<CoilDomain> never see it pop up in maas
<roaksoax> smoser: fyi: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<CoilDomain> thanks ill take a look at that
<CoilDomain> err
<CoilDomain> need to stop multitasking, didnt even post the picture http://i.imgur.com/EFOomHL.jpg
<roaksoax> blake_r: ^^ http://i.imgur.com/EFOomHL.jpg
<blake_r> CoilDomain: that looks like maybe a hardware issue
<CoilDomain> bleh
<blake_r> CoilDomain: udevadm doesnt settle after 120 seconds, which is a very long time
<blake_r> CoilDomain: that is waiting for all of the hardware devices on the system to be enumerated
<CoilDomain> wonder what piece could be broken, this had worked fine as an esxi box for the longest time
<blake_r> CoilDomain: looks to be a plug-and-play device
<CoilDomain> hmm all i have connected to it is a monitor and keyboard
<CoilDomain> guess i could boot it without the keyboard
<CoilDomain> thanks for the help, ill check it out further
#maas 2015-01-13
<TrXuk> Have tried putting new root-image, kernel and initrd into the MaaS boot locations on the MaaS server. Even tried the fix (updating the image to -proposed in a chroot env) suggested in the bug.. Nothing gets my nodes booted into MaaS properly! https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<TrXuk> Help?
<TrXuk> <TrXuk> Have tried putting new root-image, kernel and initrd into the MaaS boot locations on the MaaS server. Even tried the fix (updating the image to -proposed in a chroot env) suggested in the bug.. Nothing gets my nodes booted into MaaS properly! https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354 [12:26] <ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no I
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<blake_r> TrXuk: are you able to deploy trusty?
<TrXuk> @blake_r I'm not able to add any nodes to MaaS in the first place
<TrXuk> the netboot ends up dropping out to initramfs due to the bug in the link
<TrXuk> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<TrXuk> have tried the fix suggested on that bug without success. Have also tried placing newer initrd, kernels and root-images from maas daily builds into the MaaS server /var/maas locations
<blake_r> TrXuk: this is maas 1.7?
<TrXuk> @blake_r: yes 1.7
<TrXuk> installed last week on a utopic install
<TrXuk> Was initially following this: http://www.ubuntu.com/download/cloud/install-ubuntu-openstack
<blake_r> TrXuk: check that the tgtd server is running correctly
<blake_r> TrXuk: "service tgtd restart"
<TrXuk> yes, it appears to be
<TrXuk> The issue with the bug appears to be udev paths within the initrd from PXE due to a bad version of systemd/iscsi
<TrXuk> but newer builds still cause me the same issues
<TrXuk> @blake_r service tgt restart ?
<TrXuk> As tgtd doesnt exist
<TrXuk> but tgtd is running, just think it's service name is tgt
<blake_r> TrXuk: if your trying to enlist a node it will only trusty will be ran
<blake_r> TrXuk: i dont understand why Utopic would be running
<blake_r> TrXuk: "tgt" is fine, give it a restart and try again
<TrXuk> @blake_r yes, Trusty, so i've tried patching the bad trusty image without success as per the bug, and also tried putting newer maas image builds (boot-kernel, boot-initrd and root-image) into the /var/maas/etc/etc/etc/generic/x64/trusty directory
<TrXuk> so they get used instead of the broken trusty package
<TrXuk> neither helps
<blake_r> TrXuk: trusty is not broken that issue only occurs on utopic
<blake_r> TrXuk: if your dropping to an initramfs then that means your having a network issue connecting to the iscsi targer
<TrXuk> Sorry, my MAAS server's os us utopic, the enlist image/etc is indeed trusty
<TrXuk> which doesnt work, as per the bug
<blake_r> TrXuk: I dont believe that is the bug you are seeing, I think it is something else, can you provide a console output of the boot?
<TrXuk> It says it's using the trusty image (can see it) and have checked connectivity for iScsi
<TrXuk> but thanks for the interrupt, it looks exactly like this bug, but if you're saying trusty image is working for everyone else, i'll go back to the start
<TrXuk> @blake_r console output is exactly as shown in the bug, hard to display here as it's on a KVM so cannot pastebin out text
<TrXuk> @I'll start with a blank trusty MaaS again though and blow away all my changes, see where we stand then
<blake_r> TrXuk: okay let me know, we CI MAAS on both trusty and utopic
<TrXuk> @blake_r Thanks for your help
<TrXuk> @blake_r should I still be OK running MAAS (server) from a utopic-server OS?
<TrXuk> as thats's what i'm currently on. Was planning to go back to trusty for the re-install as thats the only thing I havent tried
<blake_r> It should work on utopic, are you using are stable ppa?
<TrXuk> yes
<blake_r> Yeah that stable ppa will work on trusty and utopic
<TrXuk> @blake_r installation path was Utopic > Install MaaS packages > MaaS UI > Download image > Chose 14.04 X64 > image downloaded > tried booting PXE nodes > failed
<TrXuk> Will triple check everything based on your info and check back!
#maas 2015-01-14
<piyush> Hello friends
<piyush> i am installing maas but when i run as localhost/maas and login then there is no "load image" option in images tab .
<piyush> how can i deal with this error or load image manually
<piyush> hello
<TrXuk> hi @blake_r Re-installed 10.14 from scratch as a new MaaS following the install documentation here: https://maas.ubuntu.com/docs1.7/install.html Same issue persists. Can see that the node to enlist does sucessfully connect to iSCSI tgtd on the MaaS server
<TrXuk> @blake_r tcp        0      0 0.0.0.0:3260            0.0.0.0:*               LISTEN      1322/tgtd        tcp        0   4144 10.0.52.5:3260          10.0.52.200:54088       ESTABLISHED 1322/tgtd
<TrXuk> @blake_r however, still seeing exactly the same issue
<TrXuk> @blake_r screenshot of dropping to initrd: https://www.dropbox.com/s/jezjjdhqplij5q9/Screenshot%202015-01-14%2019.00.14.JPG?dl=0
<TrXuk> @blake_r still looks very much like the bug @ https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1391354 . Just don't know why I'm the only one running into it from the default install
<ubot5> Launchpad bug 1391354 in maas-images "Failure to boot ephemeral image for Utopic Fast Installer deployment: no ID_PATH for iSCSI device any more" [Undecided,Confirmed]
<blake_r> TrXuk: what does this show "sudo tgtadm --lld iscsi --mode target --op show"
<TrXuk> @blake_r awesome, solaris command naming creeping into linux :P http://pastebin.com/AKXrKRav
<blake_r> TrXuk: do you have a firewall between the node and the cluster?
<TrXuk> Nope, physical Layer 2
<TrXuk> @blake_r MaaS IP: 10.0.52.5/24, DHCP given to node direct from MaaS: 10.0.52.200/24
<TrXuk>  tcp        0   4144 10.0.52.5:3260          10.0.52.200:54088       ESTABLISHED 1322/tgtd
<TrXuk> root@maas1:~# ping 10.0.52.200 PING 10.0.52.200 (10.0.52.200) 56(84) bytes of data. 64 bytes from 10.0.52.200: icmp_seq=1 ttl=64 time=0.134 ms 64 bytes from 10.0.52.200: icmp_seq=2 ttl=64 time=0.161 ms 64 bytes from 10.0.52.200: icmp_seq=3 ttl=64 time=0.146 ms ^C --- 10.0.52.200 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.134/0.147/0.161/0.011 ms root@maas1:~#  arp -a ? (10.0
<blake_r> TrXuk: its wierd that the node is not able to connect to that iscsi target
<TrXuk> @blake_r
<TrXuk> @blake_r i'm still not 100% sure it's unable to connect... The bug report still seems to match excatly... Ie, if i look right now in the (initramfs) shell, ls /dev/disk/by-path has no ip-* entries
<blake_r> TrXuk: no actually its alittle differnet
<blake_r> TrXuk: its a network issue with the node not able to connect to the iscsi target running on the cluster, not a missing permission or file issue in the image
<TrXuk> But MaaS shows an established TCP session from the Node's IP to TGTD
<TrXuk> and the TGT output you recommended shows connection 0 and the source IP of the PXEbooted node in question:  I_T nexus: 1             Initiator: maas-enlist alias: maas-enlist             Connection: 0                 IP Address: 10.0.52.200
<TrXuk> @blake_r is there anything in the initrd shell in terms of binaries that could help me debug further? like manually trying the iscsi initiator again?
<TrXuk> @blake_r or anything else you can suggest? from a TCP standpoint as above, it looks like it sucessfully contacted tgtd
<blake_r> TrXuk: yeah there, cant remember of the top my head
<blake_r> TrXuk: list the contents of /scripts in the initramfs
<TrXuk> local, functions, nfs
<TrXuk> then dir's init-top, local-bottom, panic, local-premount, init-bottom, init-premount and local-top
<blake_r> TrXuk: contents of local-top
<TrXuk> @blake_r sorry for the delay. cryptopensc, ORDER, crypto, iscsi
<blake_r> TrXuk: try /scripts/local-top/iscsi
<TrXuk> ./iscsi ... Logging in, 10.0.52.5:3620... initiator reported error 15 - session exists
<TrXuk> Tries twice
<TrXuk> @blake_r got d/c
<bmorriso> When I try and do an apt-get update, it uses the MAAS IP as a mirror, but in /etc/apt/sources.list it has archive.ubuntu.com -- after the box was provisioned, it no longer has access to MAAS, so how do I stop it from trying to use the MAAS box as an apt mirror?
<blake_r> bmorriso: /etc/apt/apt.conf you will see a reference to the maas server
<blake_r> as http proxy
<blake_r> TrXuk: not in front of PC at moment to provide support, I can look more into tomorrow
<bmorriso> I have /etc/apt.conf.d/90-curtin-aptproxy but no /etc/apt/apt.conf it has Acquire::HTTP::Proxy "http://ip.of.maas:8000/";
<blake_r> ah there you go
<blake_r> just delete that file
<bmorriso> beautiful
<bmorriso> Thank you very much!
<TrXuk> @blake_r works for me, thanks for your help on this one. Learning more about MaaS than I really wanted to ;)... but i guess thats never a bad thing!
#maas 2015-01-15
<TrXuk> Afternoon @blake_r I'm going to try and kill the existing iSCSI session the initramfs thinks it has, then re-run the iscsi script to see what happens from 'fresh'
<blake_r> TrXuk: okay let me know
<TrXuk> @blake_r struggling to kill the session, KVM isnt allowing paging control for more etc and low res which is making seeing required output pretty tricky
<voidspace> have you guys seen your api documentation?
<voidspace> I assume the retry wrapper is a new decorator
<voidspace> and someone didn't think about docstrings...
<voidspace> allenap: blake_r rvba: do you guys know about the api documentation issue or should I file a bug?
<blake_r> voidspace: i dont know about it, please file a bug about it
<voidspace> blake_r: http://maas.ubuntu.com/docs/api.html
<voidspace> Every API call is documented with "View wrapper that retries when serialization failures occur."
<blake_r> ah yeah thats bad
<voidspace> :-)
<rvba> voidspace: please file a bug, I know allenap is working on it but we don't have a bug yet.
<voidspace> https://bugs.launchpad.net/maas/+bug/1411363
<ubot5> Launchpad bug 1411363 in MAAS "Every api method documented as view wrapper" [Undecided,New]
<rvba> Thanks voidspace.
<rvba> Took the liberty to assign it to you allenap since you told me you were working on it.
<allenap> rvba: The recent change to transaction handling should resolve it.
<allenap> From last week.
<rvba> allenap: you mean the fix is already checked in?
<allenap> rvba: Yeah. I haven't checked that it has worked, but the retry wrapper is no more.
<allenap> (worked at fixing the API docs)
<voidspace> allenap: using functools.wraps inside the wrapper should solve the problem
<voidspace> it copies the docstring from the wrapped function
<rvba> allenap: can you generate the API doc and make sure it's fixed.
<rvba> ?
<rvba> If it is fixed, I'll publish the doc.
<allenap> rvba: Seems to be good.
<rvba> allenap: okay, cool.  Publishing the doc now.
<allenap> rvba: That's in trunk only right now. Is that going to work?
<allenap> At least, I haven't back-ported it.
<rvba> allenap: yes, the doc in question is the doc for trunk.
<voidspace> 1.7 is fine
<allenap> Okeydoke.
 * allenap goes to wash a dog.
<rvba> I just deployed the new documentation, it should be fixed as soon as the cache expiresâ¦
<infraerik> Running into an issue after a clean install where it's erroring on the image install.
<infraerik> When I try to import using the command line, I get error COMMAND that doesn't list boot-resources as an available option
<blake_r> infraerik: what version of MAAS?
<infraerik> @blake_r Installed from an 14.041.1 Server image as part of the install, followed by upgrade, but I didn't see any MAAS related updates fly by
<blake_r> infraerik: apt-cache policy maas
<infraerik> 1.5.4
<infraerik> might be worth a feature request for "maas --version"
<infraerik> maas upgrade from 1.5 to 1.7
<infraerik> ??
<infraerik> Adding the cloud archive repo
<roaksoax> maas 1.7 is not in the cloud archive
<blake_r> no
<infraerik> Errors out on the add anyway
<blake_r> infraerik: add ppa:maas-maintainers/testing
<roaksoax> ppa:maas-maintainers/stable for the latest 1.7.0
<roaksoax> testing for 1.7.1
<roaksoax> testing for 1.7.1rc3
<roaksoax> ppa:maas-maintainers/stable for the latest 1.7.0
<roaksoax> ppa:maas-maintainers/testing for the latest 1.7.1rc3
<infraerik> Recommandations? Testing is very bleeding edge or just medium rare?
<roaksoax> infraerik: testing right now has the Release Candidate number 3 for 1.7.1
<infraerik> Hmmm, will give it a shot
<blake_r> infraerik: not bleeding edge almost final release for 1.7.1
<infraerik> What's the process to force the maas upgrade to switch from the main repo to the other one? I've only used external repos for out of band software
<blake_r> sudo add-apt-repository ppa:maas-maintainers/testing
<blake_r> sudo apt-get update
<blake_r> sudo apt-get install upgrade
<infraerik> So far so good...except that I get 13 packages held back, including maas
<infraerik> Ah, OK, forcing the packages individually finds the testing versions
<infraerik> Oh, that's much better with a proper images tag and a minimum of useful feedback
<infraerik> Thanks! Now, just hoping the import goes OK...
#maas 2015-01-16
<caribou> Anything obvious would explain why my maas server (1.5 in a VM) only resolve the hostname with DSN and not the FQDN ?
<caribou> s/DSN/DNS/
<rvba`> caribou: hum, that's weird, can you please have a look at the generated DNS config in /etc/bind/maas/?
<caribou> rvba`: sure
<caribou> rvba: it might be how I did the DNS setup; I'm a total brain dead when it comes to DNS
<rvba> caribou: if you create a tarball of /etc/bind/maas/, I'm happy to have a look.
<caribou> rvba: http://people.canonical.com/~lbouchard/etc-bind-maas.tgz
<rvba> caribou: named.conf.maas says only the zone "example.com" is declared.
<rvba> caribou: is that expected?
<caribou> rvba: yep, just a small maas test environment; but maybe I did not set it up correctly
<rvba> caribou: looks all right to meâ¦ 192-168-122-1.example.com should resolve.
<caribou> rvba: thanks for checking; maybe I have something wrong on the client side
<rvba> I don't see a single node declared in example.com.
<rvba> fwiw
<caribou> rvba: when do nodes get their IP address allocated ? After commissionning ?
<rvba> caribou: if you're talking about static IP addresses, the nodes get them just before deployment.
<caribou> rvba: k
<caribou> hmm, tried maas 1.7 : now when I bootstrap, I get a DHCPNAK & the node does not boot
#maas 2015-01-17
<charlie__> hey guys, I am working with mmcc in #ubuntu-solutions, I need to add utopic images to maas. Can someone point me in teh right direction?
#maas 2016-01-18
<mup> Bug #1535080 changed: Please show /etc/network/interfaces in installation output <curtin:Triaged> <https://launchpad.net/bugs/1535080>
<mup> Bug #1532996 changed: Unmanaged NIC Nameservers Overwrite resolv.conf <MAAS:Invalid> <https://launchpad.net/bugs/1532996>
<mup> Bug #1533843 changed: Unable to find a node for ubuntu 15.10 <MAAS:Invalid> <https://launchpad.net/bugs/1533843>
<mup> Bug #1535481 opened: iDRAC7 IPMI enable not set by enlistment agent <MAAS:New> <https://launchpad.net/bugs/1535481>
#maas 2016-01-19
<mup> Bug #1535690 opened: [1.9.0] Need to recommission when upgrading from 1.8.3 <kanban-cross-team> <MAAS:Triaged> <https://launchpad.net/bugs/1535690>
<mup> Bug #1535690 changed: [1.9.0] Need to recommission when upgrading from 1.8.3 <kanban-cross-team> <MAAS:Triaged> <https://launchpad.net/bugs/1535690>
<mup> Bug #1535690 opened: [1.9.0] Need to recommission when upgrading from 1.8.3 <kanban-cross-team> <MAAS:Triaged> <https://launchpad.net/bugs/1535690>
<mup> Bug #1535698 opened: [1.9.0] Name | Model | Serial switcher changes both Available and Used disks and partitions <MAAS:New> <https://launchpad.net/bugs/1535698>
<mup> Bug #1535698 changed: [1.9.0] Name | Model | Serial switcher changes both Available and Used disks and partitions <MAAS:New> <https://launchpad.net/bugs/1535698>
<mup> Bug #1535698 opened: [1.9.0] Name | Model | Serial switcher changes both Available and Used disks and partitions <MAAS:New> <https://launchpad.net/bugs/1535698>
<mup> Bug #1535705 opened: [1.9.0] Selecting boot radio on Available disks can't be undone <MAAS:New> <https://launchpad.net/bugs/1535705>
<mag009_> on ubuntu.com it says that maas 1.9 is released but the ppa is still on 1.8.3 for LTS ubuntu
<mag009_> any eta when it will be available ?
<roaksoax> mag009_: ppa:maas/proposed
<roaksoax> mag009_: it will hit ppa:maas/stable
<mag009_> any eta when it will hit the stable repo ?
#maas 2016-01-20
<mup> Bug #1472268 changed: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:Expired> <https://launchpad.net/bugs/1472268>
<mup> Bug #1472268 opened: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:Expired> <https://launchpad.net/bugs/1472268>
<mup> Bug #1472268 changed: Interface with sticky IP gets prioritized dynamic IP address as well  <MAAS:Expired> <https://launchpad.net/bugs/1472268>
<student> im new never used linux and need help installing and getting rid of windows
<mup> Bug #1536039 opened: curtin fails install unexpected error while running apt-get command - Exit code 100 <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536039>
<mup> Bug # opened: 1536092, 1536094, 1536097, 1536099, 1536101, 1536102, 1536104
<mup> Bug #1536106 opened: [Node Network] PXE shouldn't be a radio button  <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536106>
<mup> Bug #1536109 opened: [Node Storage] Noticeable delay on boot disk <design> <ui> <MAAS:New> <https://launchpad.net/bugs/1536109>
<mup> Bug #1536122 opened: [Tables] Table sort style <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536122>
<mup> Bug #1536123 opened: [Tables] Make all table headings match <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536123>
<mup> Bug #1536125 opened: [Node network] Deactivate hover state for deactivated rows <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536125>
<mup> Bug # opened: 1536131, 1536132, 1536134, 1536137, 1536139, 1536142, 1536144, 1536145
<mup> Bug #1536146 opened: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug #1536146 changed: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug #1536146 opened: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug #1536146 changed: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug #1536146 opened: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug #1536146 changed: [Node Storage] Tooltip text <design> <ui> <MAAS:New for ricgard> <https://launchpad.net/bugs/1536146>
<mup> Bug # opened: 1536146, 1536147, 1536148, 1536153, 1536157
<mup> Bug #1536207 opened: bootstrap times out waiting for deployed state - curtin install > 27 minutes for amd ocp roadrunner system <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536207>
<mup> Bug #1536207 changed: bootstrap times out waiting for deployed state - curtin install > 27 minutes for amd ocp roadrunner system <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536207>
<mup> Bug #1536207 opened: bootstrap times out waiting for deployed state - curtin install > 27 minutes for amd ocp roadrunner system <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536207>
<mup> Bug #1536207 changed: bootstrap times out waiting for deployed state - curtin install > 27 minutes for amd ocp roadrunner system <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536207>
<mup> Bug #1536207 opened: bootstrap times out waiting for deployed state - curtin install > 27 minutes for amd ocp roadrunner system <oil> <curtin:New> <MAAS:New> <https://launchpad.net/bugs/1536207>
<mup> Bug #1536215 opened: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536215 changed: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536215 opened: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536215 changed: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536215 opened: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536215 changed: 1.25.0: deployment times out - system is deployed successfully by maas 1.9 but juju state never transitions from pending <oil> <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1536215>
<mup> Bug #1536233 opened: 1.9 new disks not discovered by maas during recommissioning <oil> <MAAS:New> <https://launchpad.net/bugs/1536233>
<bud> hi
<mup> Bug #1536262 opened: dns-* e/n/i are misplaced <uosci> <MAAS:New> <https://launchpad.net/bugs/1536262>
<mup> Bug #1536262 changed: dns-* e/n/i are misplaced <uosci> <MAAS:New> <https://launchpad.net/bugs/1536262>
<mup> Bug #1536262 opened: dns-* e/n/i are misplaced <uosci> <MAAS:New> <https://launchpad.net/bugs/1536262>
<mup> Bug #1536262 changed: dns-* e/n/i are misplaced <uosci> <MAAS:New> <https://launchpad.net/bugs/1536262>
<mup> Bug #1536262 opened: dns-* e/n/i are misplaced <uosci> <MAAS:New> <https://launchpad.net/bugs/1536262>
<mup> Bug #1536320 opened: Web UI: back button always returns user to view with a stale query - current query gone <oil> <MAAS:New> <https://launchpad.net/bugs/1536320>
<mup> Bug #1536346 opened: include maas resetMachine() API primitive <landscape> <MAAS:New> <https://launchpad.net/bugs/1536346>
<mup> Bug #1536354 opened: users' maas api kesy should have a name <MAAS:New> <https://launchpad.net/bugs/1536354>
<mup> Bug #1536368 opened: [xenial] _get_systemd_service_status fails to parse systemd "failed" state <xenial> <MAAS:Triaged> <https://launchpad.net/bugs/1536368>
<mup> Bug #1536368 changed: [xenial] _get_systemd_service_status fails to parse systemd "failed" state <xenial> <MAAS:Triaged> <https://launchpad.net/bugs/1536368>
<mup> Bug #1536368 opened: [xenial] _get_systemd_service_status fails to parse systemd "failed" state <xenial> <MAAS:Triaged> <https://launchpad.net/bugs/1536368>
<mup> Bug #1536395 opened: package maas-cluster-controller 1.8.3+bzr4053-0ubuntu1 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saÃ­da de erro 1 <amd64> <apport-package> <xenial> <maas (Ubuntu):New> <https://launchpad.net/bugs/1536395>
#maas 2016-01-21
<mup> Bug #1536395 opened: package maas-cluster-controller 1.8.3+bzr4053-0ubuntu1 failed to install/upgrade: sub-processo script post-installation instalado retornou
<mup> estado de saÃ­da de erro 1 <amd64> <apport-package> <xenial> <MAAS:Incomplete> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1536395>
<mup> Bug #1536395 changed: package maas-cluster-controller 1.8.3+bzr4053-0ubuntu1 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saÃ­da de erro 1 <amd64> <apport-package> <xenial> <MAAS:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1536395>
<mup> Bug #1536395 changed: package maas-cluster-controller 1.8.3+bzr4053-0ubuntu1 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saÃ­da de erro 1 <amd64> <apport-package> <xenial> <MAAS:Invalid> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1536395>
<mup> Bug #1536558 opened: [1.9.0] Cannot select the IP address on node details of a Deployed node <design> <MAAS:New> <https://launchpad.net/bugs/1536558>
<mup> Bug #1536604 opened: IntegrityError while uploading leases <MAAS:New> <https://launchpad.net/bugs/1536604>
<mup> Bug #1536604 changed: IntegrityError while uploading leases <MAAS:New> <https://launchpad.net/bugs/1536604>
<mup> Bug #1536604 opened: IntegrityError while uploading leases <MAAS:New> <https://launchpad.net/bugs/1536604>
<BlackDex> Hello there, i wonder if i can disable password login for ssh on the maas node and only use keys.
<mup> Bug #1536644 opened: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536644 changed: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536644 opened: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536644 changed: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536644 opened: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536644 changed: need boot image sync URL per-release (mix daily and released) <uosci> <MAAS:New> <https://launchpad.net/bugs/1536644>
<mup> Bug #1536741 opened: Network description is lost during 1.8 to 1.9 upgrade <kanban-cross-team> <MAAS:Triaged> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1536741>
<mup> Bug #1536741 changed: Network description is lost during 1.8 to 1.9 upgrade <kanban-cross-team> <MAAS:Triaged> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1536741>
<mup> Bug #1536741 opened: Network description is lost during 1.8 to 1.9 upgrade <kanban-cross-team> <MAAS:Triaged> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1536741>
<mup> Bug #1536754 opened: Upgrade from 1.8 to 1.9 lost connected macs in all but one network <kanban-cross-team> <MAAS:New> <https://launchpad.net/bugs/1536754>
<mup> Bug #1536754 changed: Upgrade from 1.8 to 1.9 lost connected macs in all but one network <kanban-cross-team> <MAAS:New> <https://launchpad.net/bugs/1536754>
<mup> Bug #1536754 opened: Upgrade from 1.8 to 1.9 lost connected macs in all but one network <kanban-cross-team> <MAAS:New> <https://launchpad.net/bugs/1536754>
#maas 2016-01-22
<mup> Bug #1536963 opened: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:New> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 changed: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:New> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 opened: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:New> <https://launchpad.net/bugs/1536963>
<mup> Bug #1537078 opened: [1.9.0] 500 error when deploying - KeyError amt <kanban-cross-team> <MAAS:New> <https://launchpad.net/bugs/1537078>
<mup> Bug #1537095 opened: [1.9.0] 400 Error juju bootstrapping missing images <kanban-cross-team> <MAAS:New> <https://launchpad.net/bugs/1537095>
<mup> Bug # changed: 1328588, 1342292, 1347736, 1381603, 1389802, 1396678, 1411666, 1412026, 1417793, 1422457, 1422823, 1427492, 1428647, 1430236, 1431741, 1436885, 1438105, 1438766, 1439657, 1446699, 1446878, 1449862, 1452276, 1453132, 1453168, 1453669, 1457206, 1457799, 1459331, 1459338, 1465739,
<mup> 1465743, 1469666, 1470401, 1481118, 1487227, 1510100, 1516173, 1517129, 1523988
<mup> Bug # changed: 1313550, 1372982, 1423457, 1436438, 1440994, 1444154, 1452154, 1452957, 1456329, 1461639, 1466151, 1467584, 1469846, 1470013, 1494449, 1505029, 1505034, 1508695, 1508754, 1510891, 1512832, 1515498
<mup> Bug # opened: 1313550, 1372982, 1423457, 1436438, 1440994, 1444154, 1452154, 1452957, 1456329, 1461639, 1466151, 1467584, 1469846, 1470013, 1494449, 1505029, 1505034, 1508695, 1508754, 1510891, 1512832, 1515498
<mup> Bug # changed: 1313550, 1372982, 1423457, 1436438, 1440994, 1444154, 1452154, 1452957, 1456329, 1461639, 1466151, 1467584, 1469846, 1470013, 1494449, 1505029, 1505034, 1508695, 1508754, 1510891, 1512832, 1515498
<donu7> hello, i'm trying to learn maas+openstack but i am having the hardest time setting up maas networking. my setup is using 3 nics, 2 onboard, 1 pci 10g nic. I have the region controller installed and it's using eth0. The issue is the other 2 nics aren't picked up by either maas dhcp or the public network's dhcp. If i set up static entries in /etc/network/interfaces all the ip routes show as failed
<donu7> the nics are enabled and set to auto dhcp in /etc/network/interfaces but i have them set up to provide dns/dhcp in the maas cluster controller
<donu7> is it sufficient to specify in maas web gui to use eth1 as dhcp/dns for the internal maas network?
<donu7> or, to take a step back, is there a recommended methodology when setting up maas on a box with 2+ nics?
<donu7> or, how is maas configured between 2 nics where maas (the region controller i assume) can perform NAT between the network attached to eth0 and eth1 ?
<donu7> does my questions even make sense?
<donu7> I've solved my issue. For posterity, here's my findings: 1) /etc/maas/maas_local_settings.py had the wrong IP for the region controller. A mistake I made during region-controller install.
<donu7> 2) my region-controller interfaces needed to be setup  before adding the cluster master. I was specifying too much static info in /etc/network/interfaces. All that i needed was static ip & netmask.
<rasel> hi
<rasel> hi
<rasel> hlw
<mup> Bug #1536963 changed: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:Invalid> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 opened: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:Invalid> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 changed: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:Invalid> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 opened: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:Invalid> <https://launchpad.net/bugs/1536963>
<mup> Bug #1536963 changed: Error occurred u'missing_packages' when adding VirtualBox power control <MAAS:Invalid> <https://launchpad.net/bugs/1536963>
<mup> Bug #1537257 opened: MAAS create extraneous fabrics when using multiple interfaces and VLANs <MAAS:New> <https://launchpad.net/bugs/1537257>
<mup> Bug #1537257 changed: MAAS create extraneous fabrics when using multiple interfaces and VLANs <MAAS:New> <https://launchpad.net/bugs/1537257>
<mup> Bug #1537257 opened: MAAS create extraneous fabrics when using multiple interfaces and VLANs <MAAS:New> <https://launchpad.net/bugs/1537257>
#maas 2016-01-23
<mup> Bug #1537257 changed: MAAS create extraneous fabrics when using multiple interfaces and VLANs <MAAS:Opinion> <MAAS 1.9:Opinion> <https://launchpad.net/bugs/1537257>
<mup> Bug #1449206 changed: maas installation fails because of missing AppCache module in django <MAAS:Expired> <https://launchpad.net/bugs/1449206>
 * D4RKS1D3 Hi
#maas 2017-01-16
<vmorris> why does MAAS sometimes hand out a reserved IP when I try to bootstrap or add a machine from Juju?
<vmorris> maas expects the machine to come up on a given available IP, but instead the machine's PXE boot picks up a reserved IP and then fails to bootstrap
#maas 2017-01-17
<mup> Bug #1657285 opened: [UI] When editing a commissioned interface, you need to do it twice for the changes to take effect. <MAAS:New> <https://launchpad.net/bugs/1657285>
<mup> Bug #1656350 changed: multi-homed host static routes formating <networking> <routes> <static> <curtin:New> <MAAS:Opinion> <https://launchpad.net/bugs/1656350>
#maas 2017-01-18
<rmcadams> With "Add Chassis" - with the type virsh - should it add all libvirt machines it finds on a host?
<rmcadams> I can't find anything that covers it via my google searches... or in the docs.
<mup> Bug #1657375 opened: RFE: DNS and DHCP <MAAS:New> <https://launchpad.net/bugs/1657375>
<mup> Bug #1657378 opened: RFE: SSH Port and Listen <MAAS:New> <https://launchpad.net/bugs/1657378>
<n8behavior> Anyone getting "failed to detect a valid IP address from -1"?  This is a fresh install of MaaS 2.1.1+bzr5544 on a fresh/update-to-date Ubuntu server 16.04.1.
<n8behavior> Also have more deets here: http://askubuntu.com/questions/873106/failed-to-detect-a-valid-ip-address-from-1
<n8behavior> Thought I'd run the table before filing a bug report
<mup> Bug #1657471 opened: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
<mup> Bug #1657471 changed: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
<mup> Bug #1657471 opened: [2.1] 400 BAD REQUEST: Unrecognised signature: method=GET op=is_registered <MAAS:New> <https://launchpad.net/bugs/1657471>
<mup> Bug #1657491 opened: Several IPs assigned to the same iface in the DB due to 'free' leases <sts> <MAAS:New> <https://launchpad.net/bugs/1657491>
<mup> Bug #1657520 opened: Cannot add device with static IP via the API <MAAS:New> <https://launchpad.net/bugs/1657520>
<mup> Bug #1657520 changed: Cannot add device with static IP via the API <MAAS:New> <https://launchpad.net/bugs/1657520>
<mup> Bug #1657520 opened: Cannot add device with static IP via the API <MAAS:Triaged> <https://launchpad.net/bugs/1657520>
<capncrunch4me> I have 400 servers to provision using MAAS, can I do this over a single L2 VLAN on a /22 network using MAAS?
<capncrunch4me> what am I going to need to scale out to accomodate this?
<pmatulis> capncrunch4me, i don't see any problem using maas for what you want to do
<capncrunch4me> normal 2-node HA install should do the trick?
<capncrunch4me> i mean, it strikes me that maas really is only hit hard is during provisioning a node
<capncrunch4me> im not suggesting massâing up 400 nodes at once, we would stagger provisioning
<pmatulis> capncrunch4me, there are docs for implementing HA in maas but, apart from that, i don't think you'll need anything special
<capncrunch4me> k cool, thanks
<capncrunch4me> just wanted to make sure it scaled out of the box
<capncrunch4me> 400 nodes is quite a bit different than 50
<pmatulis> capncrunch4me, i think you you should consider a 2nd rack controller after 1000 nodes
<capncrunch4me> ok
<n8behavior> Fresh install of MaaS on 14.04 does not work out-of-the-box.  Anyone able to successfully package install?
<mup> Bug #1657577 opened: 2.1.3: Dashboard page crashes <oil> <MAAS:New> <https://launchpad.net/bugs/1657577>
#maas 2017-01-19
<jjohnston> hi all looking for a little guidance from more experienced MaaS users if anyone has a moment.  I'm getting an error in MaaS on successfully commissioned hosts  {"network": ["Node must be configured to use a network"]} - I've searched for existing trackers and am not finding a work-around. Thanks for any guidance you can give in advance
<mup> Bug #1657851 opened: [2.2] CSS refers to image-background-paper.png, which no longer exists <MAAS:Triaged> <https://launchpad.net/bugs/1657851>
<spaok> hey all
<spaok> does anyone know how I can remove interfaces from a controller? the maas command won't let me do it
<spaok> ah nevermind it did i
#maas 2017-01-20
<shahaan> Hello All, I am having a problem in (no commissioning) but deploying node whilst resolving the hostname. The reason being that maas is not setting up the dns domain-search in /etc/resolv.conf, does anybody on the channel know how to fix this ??
<shahaan> Jan 19 06:37:15 rcstodc1r76-01 sudo[3688]:   ubuntu : unable to resolve host rcstodc1r76-01
<shahaan> Jan 19 06:37:15 rcstodc1r76-01 sudo[3688]:   ubuntu : TTY=pts/0 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/bin/systemctl status cloud-final.service
<mpontillo> shahaan: MAAS configures cloud-init to not manage /etc/hosts, due to a bug that came up with doing so. see https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1087183
<mpontillo> shahaan: the manage_etc_hosts flag is in /usr/lib/python3/dist-packages/maasserver/compose_preseed.py if you want to hack around with it
<mpontillo> shahaan: that is, a default Ubuntu install solves the "unable to resolve my local hostname" issue by adding the hostname in /etc/hosts, pointing to 127.0.0.1.
<mpontillo> shahaan: finally, I don't think MAAS supports specifying DNS search paths for deployed nodes. (lamont may know better than me, though.)
<shahaan> Thanks mpontillo, was good help..
<shahaan> Sorry to bother again, is there a way to specify MaaS to PXE boot only a specific whitelist of servers (either by their MAC or IP address) ??
<mpontillo> shahaan: if you know how to configure ISC DHCP to do that, you could use DHCP snippets. (see Settings > DHCP Snippets) -- this allows you to add your own custom DHCP configuratoins
<mpontillo> shahaan: that said, it should be relatively harmless for machines  you don't want in MAAS to PXE boot. if MAAS sees a machine PXE boot which is not in MAAS yet, it will give it a random name and add it to its database.
<mpontillo> shahaan: MAAS will not do anything with such a machine, unless you commission it first (and possibly specify the power parameters, if the IPMI magic didn't happen).
<mpontillo> shahaan: though I guess I can understand why you might want a whitelist, if turning on a node automatically causes it to enlist and change its IPMI settings automatically. but we want you to use MAAS on all your servers. ;-)
<shahaan> Hey mpontillo,  we have multiple teams deploying servers (some using vDisks) though they  are on the same vlan :(, so a whitelist could have been good. But DHCP snippets is a good workaround
<mpontillo> shahaan: I think the recommended way would be to get another VLAN so you can dedicate one to MAAS. that way you don't have clashes with more than one DHCP server running on the network (if that's the case)
<shahaan> So for machines, setup by third party vendors (won't name them) sometimes that causes a few unnecessary conversations...
<shahaan> Yeah, thanks for the tips mate!
<shahaan> much appreciated
<tdihp> mpontillo: Hi. I'm having trouble commissioning nodes
<tdihp> mpontillo: Would you please take a look at this? https://askubuntu.com/questions/873701/maas-node-unable-to-resolve-its-own-hostname
<tdihp> mpontillo:  Thanks very much!
<mpontillo> tdihp: in that post, what server is `golden-moose`? is that the one you're trying to commission?
<mpontillo> tdihp: also, just so you know, MAAS 2.1.3 is available now, so I would recommend you update to that first to fix any known issues before troubleshooting further.
<mpontillo> https://launchpad.net/ubuntu/+source/maas/2.1.3+bzr5573-0ubuntu1~16.04.1
<tdihp> mpontillo: Yes, the random-given name of the node.
<tdihp> mpontillo: Ahh so it's a known issue, thanks!
<mpontillo> tdihp: OK. are you using MAAS for your DNS? by default MAAS places machines in the .maas domain.
<tdihp> mpontillo: Yes, I'm able to resolve the region master with .maas domain from the node.
<mpontillo> tdihp: well, I'm not clear on the root cause of your particular problem, so I can't be certain 2.1.3 will fix the problem. but I still strongly recommend that you upgrade
<mpontillo> tdihp: the 'connection timed out' issue is interesting though. that seems to imply that your nodes cannot communicate with the DNS server for some reason. have you ensured that your iptables rules allow DNS traffic from the nodes?
<tdihp> mpontillo: I think so yes, I was able to dig and ping both .mass domain and external domains.
<tdihp> mpontillo: My guess is that the storage commissioning script is timed out due to the sudo calls and other calls that would invoke hostname resolving of the node's own hostname.
<mpontillo> shahaan: hm, interesting, it appears I was mistaken. I see "search <maas-domain>" in my /etc/resolv.conf on my commissioning node. so I would guess that, like tdihp, your issue is most likely with DNS connectivity.
<mpontillo> tdihp: but I can't explain why you are able to ping other nodes, but not the commissioning node
<mpontillo> tdihp: when you commission, there is an option to allow SSH and prevent the node from powering off. would you give that a try so you can troubleshoot more?
<mpontillo> tdihp: after you SSH into the commissioning node, I would check /etc/resolv.conf on the commissioning node to ensure it's pointing to the MAAS nameserver and has your search domain in it.
<mpontillo> tdihp: then use 'dig' to query the nameserver from the node for that hostname. dig will not consider search paths, so you'll need to add that manually
<tdihp> mpontillo: Yes it was using the MAAS server, I've checked. However yesterday I've not seen the DNS record of the commisioning node in the MAAS http server's "DNS" list.
<tdihp> mpontillo: But today it is. how strange. And the sudo lag went away.
<mpontillo> tdihp: does that mean you were able to successfully commission? did you update to 2.1.3?
<tdihp> mpontillo: I haven't upgraded yet. The /etc/resolv.conf points to the MAAS correctly. I'm able to resolve <hostname>.maas but not <hostname>
<mpontillo> tdihp: via what mechanism? because dig will not add the search path for you, but sudo and other tools should
<mpontillo> tdihp: for example `ping` would add the search path.
<tdihp> mpontillo: Yes I tried ping
<mpontillo> tdihp: ok, what was the result?
<mpontillo> tdihp: I would also try `grep named /var/log/syslog` on the MAAS server to see if everything looks okay with the DNS server
<tdihp> mpontillo: BTW, does MAAS add/keep DNS entry for commissioning nodes?
<mpontillo> tdihp: okay. I would try the commissioning again then. it seems like maybe the DNS issues are no longer in your way. I replied to your askubuntu post: http://askubuntu.com/a/874005/1269
<mpontillo> tdihp: but I've got to go now; good luck. I'll be around.
<mpontillo> tdihp: to answer your question: commissioning - yes. when the node is finished commissioning, I believe it will clear those out.
<mpontillo> tdihp: but while you're SSHed in, I don't think it'll remove the entries. I'm testing it now here and I see that it maintains them.
 * mpontillo goes to eat dinner
<tdihp> mpontillo: Thanks a lot :)
<shahaan> Thanks mpontillo, things are looking much better now after the 2.1.3 upgrade: search erc.monash.edu.au maas
<shahaan> That string is making a difference
<mup> Bug #1612039 changed: MAAS Cannot Commission <MAAS:Expired> <https://launchpad.net/bugs/1612039>
<Sandeep> Hello Guys
<Guest2907> Anybody there?
<Guest2907> Hello
<mup> Bug #1612039 opened: MAAS Cannot Commission <MAAS:Expired> <https://launchpad.net/bugs/1612039>
<mup> Bug #1612039 changed: MAAS Cannot Commission <MAAS:Expired> <https://launchpad.net/bugs/1612039>
<YooFy> hi, hello all
<YooFy> I search with google a great documentation for build custom image Ubuntu and windows. Do you have any links of tutorial for that
<YooFy> ?
<pmatulis> not to my knowledge
<IronCom> Hi
<IronCom> Someone here
<IronCom> ?
<IronCom> I would have a question to MAAS searcheing in Web but not sure about the right solution
<pmatulis> Iron...
#maas 2018-01-15
<Mutter> Can anyone here help me with MAAS Landscape OpenStack deployment?
<mup> Bug #1732442 changed: [2.3rc3, UI] In controller summary the overveview card shouls say MAAS version instead of version <2.3qa> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1732442>
<mup> Bug #1743400 opened: [2.3, UI] MAAS 'Containers' tab drops 'mac' address instead of hostname <MAAS:Triaged> <MAAS 2.3:Triaged> <https://launchpad.net/bugs/1743400>
#maas 2018-01-16
<mup> Bug #1728899 changed: when Comissioning a node, the grub command line apppear  <grub> <MAAS:Expired> <https://launchpad.net/bugs/1728899>
<mup> Bug #1743515 opened: [2.4, trunk 6518-gca32acf] dhcpd is never started on bionic container in xenial host, and MAAS doesn't show it as failure. <MAAS:Triaged> <https://launchpad.net/bugs/1743515>
<mup> Bug #1743515 changed: [2.4, trunk 6518-gca32acf] dhcpd is never started on bionic container in xenial host, and MAAS doesn't show it as failure. <MAAS:Triaged> <https://launchpad.net/bugs/1743515>
<mup> Bug #1743515 opened: [2.4, trunk 6518-gca32acf] dhcpd is never started on bionic container in xenial host, and MAAS doesn't show it as failure. <MAAS:Triaged> <https://launchpad.net/bugs/1743515>
<mup> Bug #1743595 opened: modprobing mlx5_core doesn't bring the interface up <MAAS:New> <linux (Ubuntu):New> <https://launchpad.net/bugs/1743595>
<McL0v1n> hello everyone! Anyone have a moment to assist?
<McL0v1n> anyone around?
<mup> Bug #1742808 changed: Creating bond via api ignores params <canonical-bootstack> <MAAS:Invalid> <https://launchpad.net/bugs/1742808>
<mup> Bug #1743648 opened: Image import fails <MAAS:New> <https://launchpad.net/bugs/1743648>
<mup> Bug #1743648 changed: Image import fails <MAAS:New> <https://launchpad.net/bugs/1743648>
<mup> Bug #1743648 opened: Image import fails <MAAS:New> <https://launchpad.net/bugs/1743648>
#maas 2018-01-17
<mup> Bug #1741179 opened: package maas-region-api 2.2.0+bzr6054-0ubuntu2~16.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 <amd64> <apport-package> <need-duplicate-check> <yakkety> <maas (Ubuntu):New> <https://launchpad.net/bugs/1741179>
<mup> Bug #1731293 changed: [2.3rc2, UI] Previous results should be sorted by most recent first <2.3qa> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1731293>
<mup> Bug #1731293 opened: [2.3rc2, UI] Previous results should be sorted by most recent first <2.3qa> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1731293>
<mup> Bug #1731293 changed: [2.3rc2, UI] Previous results should be sorted by most recent first <2.3qa> <ui> <MAAS:Expired> <https://launchpad.net/bugs/1731293>
<mup> Bug #1712680 changed: cloud-init re-generates network config every reboot overwriting manual admin changes on CentOS. <cloud-init:Fix Committed> <MAAS:Invalid> <maas-images:New for ltrager> <https://launchpad.net/bugs/1712680>
<mup> Bug #1743776 opened: [2.3, 2.4] Editing a custom repository doesn't allow you to modify distribution, component. <MAAS:New> <https://launchpad.net/bugs/1743776>
<mup> Bug #1736626 changed: [2.4] Cannot add device from dashboard <MAAS:Invalid> <https://launchpad.net/bugs/1736626>
* roaksoax changed the topic of #maas to: World's best bare-metal provisioning tool | MAAS 2.3.0 now released! | Docs: http://maas.io/docs | ML: https://lists.ubuntu.com/mailman/listinfo/maas-devel
<mup> Bug #1743776 changed: [UI, 2.3] Editing a custom repository doesn't allow you to modify distribution, component. <MAAS:Invalid by ack> <MAAS 2.3:Triaged by ack> <https://launchpad.net/bugs/1743776>
<ejsf> hi, just installed maas and commissioned my first nodes, im impressed, very nice product :) just one question, i added the first node by hand and now i want to rename it, is there a way to rename a machine or is it better to delete it and add again?
<ejsf> deleting and re-adding worked :)
<mup> Bug #1679322 opened: maas-dhcp upgrade to 1.9.5+bzr4599-0ubuntu1~14.04.1 fails to start installed isc-dhcp-server <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1679322>
<mup> Bug #1679322 changed: maas-dhcp upgrade to 1.9.5+bzr4599-0ubuntu1~14.04.1 fails to start installed isc-dhcp-server <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1679322>
<mup> Bug #1679322 opened: maas-dhcp upgrade to 1.9.5+bzr4599-0ubuntu1~14.04.1 fails to start installed isc-dhcp-server <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1679322>
<desigabri> hi
<desigabri> please just a little help
<desigabri> I read about Maas and I undertood that just the first machine need the ubuntu server plus maas...
<desigabri> the other machines have just to be connected in PXE boot
<desigabri> so I'll configure those machine from the primary node?
<desigabri> is it right?
<desigabri> so just more hardware power connecting and then bigger machine?
<desigabri> is it a way to upgrade hardware power just connecting more hardware?
<desigabri> connecting togheter
<gunix> how do i assing a subnet to a space?
<gunix> there is no button
<gunix> also how can i enable dhcp?
<gunix> found dhcp somewhere
<gunix> pxe doesn't work unless maas is the dhcp server, it seems
<gunix> i managed to get the vm to boot from maas, with the default image, but after that it rebooted and got stuck cause it doesn't find any bootable device
<gunix> the error i get is "failed to enlist system maas server"
<gunix> i figure this is where it is failing: https://github.com/cloudbase/maas/blob/master/contrib/preseeds_v2/enlist_userdata#L100-L130
<gunix> as i get exactly that echo
<gunix> on the screen
<gunix> found an IP that shouldn't be there. there was a bad entry in /etc/hosts on the maas controller
<gunix> ok, found the old IP in maas and bind9 settings files. changed that. rebooted once, machine popped in dashboard, rebooted again to scan hardware
<gunix> i have progress. now the error i get is that mass can't detect storage, which is a virtio device on qemu
<gunix> yep, hardware tests fail
<gunix> fixed with hwe kernel. i THINK that is what solved the issue
#maas 2018-01-18
<mup> Bug #1743966 opened: Trusty deployments fail when custom archives are configured <MAAS:Triaged> <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1743966>
<hkominos> Greetings all. I am facing a weird situation while using maas. I am using an opnfv-fuel deployment and although maas works fine it is veeeeeeery slow. It takes about 2 minutes to pass the initrd and kernels to the targets. Is that normal ? I would greatly appreciate any input
<roaksoax> hkominos: it could be a network issue
<roaksoax> hkominos: when did you start seeing this issue ?
<hkominos> Hi roaksoax. We have had this issue for a couple of months now. Although there were bigger issues in the beggining so we did not pay too much attention to the slow transfer time.
<hkominos> I should mention that we are talking about aarch64 system
<roaksoax> hkominos: i would normally think it is a network issue, but since you runnning aarch64... i wonder if that's related ?
<hkominos> In theory it should not (of course different images are serverd). In practice I have found that ppl mostly test onx86 systems and that has led to weird bugs
<roaksoax> yeah we mostly tet x86, we do test arm64
<hkominos> Roaksoax: The networking could be an issue but even when the Vms (target and MaasVM) are on the same physical machine connected by a simple linux bridge, the speed is really bad
<hkominos> 2 minutes to transfer 50 MB (kernel + initrd )
<hkominos> I will now repeat the experiment on a new server to verify
#maas 2018-01-19
<Chipaca> hello all
<Chipaca> is it known that the maas snap dumps core on install on 16.04?
<Chipaca> https://pastebin.ubuntu.com/26415649/
<roaksoax> Chipaca: did you install with --devmode ?
<Chipaca> roaksoax: no
<roaksoax> Chipaca: https://docs.ubuntu.com/maas/2.3/en/installconfig-snap-install
<Chipaca> why are we telling people to install stuff with --devmode :-(
<Chipaca> but, anyway, that answers my question; it's known broken. onwards.
<roaksoax> Chipaca: because otherwise maas woudldn't work
<roaksoax> there are blockers that prevent the maas snap (not in maas) from working in fully confined mode
<roaksoax> so we have to use devmode
<vogelc> roaksoax: We upgraded our prod to 2.3.0 last night and now we get out of memory errors on the region controller when someone restarts the region controller or does a refresh on the ui.  Thoughts?
<vogelc> roaksoax: builtins.OSError: [Errno 12] Cannot allocate memory
<roaksoax> vogelc: do you have more details than that ? e.g. regiond.log and process list, etc
<vogelc> roaksoax: sure, I will get them posted to a paste bin
<vogelc> roaksoax: https://pastebin.com/sBG42Grk
<vogelc> roaksoax: We increased the memory on the vm to 24GB and it would still consume all the memory and kill the process.
<roaksoax> vogelc: does a top or similar show what is utilizing cpu/memory ?
<vogelc> roaksoax: https://pastebin.com/97cchLQ8
<vogelc> roaksoax: that is top and syslog output.  I just issued a refresh in the web ui
<xygnal> roaksoax: would appreciate what actions we can take to debug why vogelc and I are seeing this.   It's as if the system is queueing up load until memory runs out.  How do we see what 'load' is going on internally?
<xygnal> roaksoax: listing nodes in webui takes a long time, and seems to stall at 500.  never finishes 'loading' status.
<xygnal> roaksoax: if i refresh the page,  shortly thereafter twistd3 consumes all memory and is killed by kernel.
<xygnal> within minutes
<bladernr> is there a way to query maas via cli and determine what kernel version is available for each option in maas? (something that does "Show me the kernel verision installed by 16.04-hwe")
<bladernr> ^^ I'd like to be able to easily determine exactly what version MAAS will install if I choose hwe vs hwe-edge (currently BOTH seem to be 4.13, but they often don't match up)
<gunix> bladernr: what is the difference between hwe and hwe edge?
<gunix> i know kvm vms work only with hwe ... but no idea what edge is
<bladernr> hwe is the current supported HWE kernel, -edge is the NEXT one coming
<ltrager> bladernr: there isn't a way to do it with MAAS however you could query apt which is where the kernel comes from
<ltrager> bladernr: e.g apt-cache policy linux-image-generic-hwe-16.04-edge shows its 4.13
<bladernr> ltrager, thanks, that'll work.  I was hoping for a MAAS Cli way to ask it about the things it's going to install, but that too works
<mup> Bug #1532286 changed: Postgresql-9.5 breaks MAAS <MAAS:Invalid> <https://launchpad.net/bugs/1532286>
<klj1218> I'm trying to create a custom curtin preseed file and I've noticed that if I include "system_id" for the {node} it fails to pick the file up... I have to use the "hostname" instead. This doesn't match the documentation.
<klj1218> fail --> curtin_userdata_centos_amd64_generic_centos70_q6g3hd
<klj1218> work --> curtin_userdata_centos_amd64_generic_centos70_dell01-srv01
<klj1218> The template naming doc is here: https://docs.ubuntu.com/maas/devel/en/nodes-custom
#maas 2018-01-20
<mup> Bug #1733420 changed: virsh power type check error <MAAS:Expired> <https://launchpad.net/bugs/1733420>
<mup> Bug #1744454 opened: [2.3] MAAS does not handle vips and real ips well <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1744454>
#maas 2018-01-21
<mup> Bug #1733285 changed: Unable to create pod with MAAS 2.3-rc2 on 17.10 <s390x> <MAAS:Expired> <https://launchpad.net/bugs/1733285>
<mup> Bug #1733600 changed: Custom images removed from Web UI still show up as an option during deploy in Web UI <cpe-onsite> <MAAS:Expired> <https://launchpad.net/bugs/1733600>
<mup> Bug #1744562 opened: feature: ability to enable IPMI protocol through SSH to BMC <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1744562>
<mup> Bug #1744606 opened: feature: please enable NTP check as a default hardware test on commissioning <cpe-onsite> <MAAS:New> <https://launchpad.net/bugs/1744606>
#maas 2020-01-15
<mup> Bug #1859849 opened: Can't create interfaces or bonds in the UI <ui> <MAAS:New> <https://launchpad.net/bugs/1859849>
<mup> Bug #1859849 changed: Can't create interfaces or bonds in the UI <ui> <MAAS:New> <https://launchpad.net/bugs/1859849>
<mup> Bug #1859849 opened: Can't create interfaces or bonds in the UI <ui> <MAAS:New> <https://launchpad.net/bugs/1859849>
#maas 2020-01-16
<stelucz> Hi, could someone help me with apt proxy which is configured by MAAS, please? MAAS populates file /etc/apt/apt.conf.d/90curtin-aptproxy with "10-238-132-0--22.maas-internal" as proxy, but it is of course can not be resolved. e.g. running apt update: "Err:1 http://archive.ubuntu.com/ubuntu xenial InRelease
<stelucz> '10-238-132-0--22.maas-internal'
#maas 2020-01-17
<mup> Bug #1860059 opened: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860059 changed: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860059 opened: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860059 changed: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860059 opened: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860059 changed: MAAS 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1) Web UI will not delete vlans in web ui <MAAS:New> <https://launchpad.net/bugs/1860059>
<mup> Bug #1860073 opened: Standard non-admin users dont have API restriction on spinning up new  vms.  Request for better security control <MAAS:New> <https://launchpad.net/bugs/1860073>
<mup> Bug #1860073 changed: Standard non-admin users dont have API restriction on spinning up new  vms.  Request for better security control <MAAS:New> <https://launchpad.net/bugs/1860073>
<mup> Bug #1860073 opened: Standard non-admin users dont have API restriction on spinning up new  vms.  Request for better security control <MAAS:New> <https://launchpad.net/bugs/1860073>
<mup> Bug #1860074 opened: package maas-region-controller 2.6.0-7802-g59416a869-0ubuntu1 failed to install/upgrade: installed maas-region-controller package post-installation script subprocess returned error exit status 1 <amd64> <apport-package> <eoan> <need-duplicate-check> <third-party-packages>
<mup> <uec-images> <maas (Ubuntu):New> <https://launchpad.net/bugs/1860074>
<mup> Bug #1860117 opened: Clone configuration of node with CLI error with destination field <MAAS:New> <https://launchpad.net/bugs/1860117>
<sdhd-sascha> hi, is there any effort to split MAAS snap-package into parts ? e.g. postgres / rack / region / cli ...
<mup> Bug #1860153 opened: Feature Request: Support for RedHat CoreOS <MAAS:New> <https://launchpad.net/bugs/1860153>
<mup> Bug #1860177 opened: access to boot-resources gone from 2.6.1 CLI <MAAS:Incomplete> <https://launchpad.net/bugs/1860177>
<mup> Bug #1860177 changed: access to boot-resources gone from 2.6.1 CLI <MAAS:Incomplete> <https://launchpad.net/bugs/1860177>
<mup> Bug #1860177 opened: access to boot-resources gone from 2.6.1 CLI <MAAS:Incomplete> <https://launchpad.net/bugs/1860177>
#maas 2020-01-18
<mup> Bug #1849320 changed: MAAS assigns wrong multipath NVMe device <sts> <curtin:Expired> <MAAS:Expired> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1849320>
<mup> Bug #1852593 changed: Cannot read Power Configuration of locked deployed Machines <MAAS:Expired> <https://launchpad.net/bugs/1852593>
<mup> Bug #1849320 changed: MAAS assigns wrong multipath NVMe device <sts> <curtin:Expired> <MAAS:Expired> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1849320>
<mup> Bug #1849320 opened: MAAS assigns wrong multipath NVMe device <sts> <curtin:Expired> <MAAS:Expired> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1849320>
<mup> Bug #1852593 opened: Cannot read Power Configuration of locked deployed Machines <MAAS:Expired> <https://launchpad.net/bugs/1852593>
<mup> Bug #1849320 changed: MAAS assigns wrong multipath NVMe device <sts> <curtin:Expired> <MAAS:Expired> <maas (Ubuntu):Expired> <https://launchpad.net/bugs/1849320>
<mup> Bug #1852593 changed: Cannot read Power Configuration of locked deployed Machines <MAAS:Expired> <https://launchpad.net/bugs/1852593>
